Technisches Whitepaper

DSGVO- und AI-Act-konforme KI-Nutzung durch automatische Pseudonymisierung mit Zero-Knowledge-Architektur

40 PII-Kategorien • Argon2id-basierte Verschlüsselung • Per-User Data Encryption Keys • 10+ KI-Provider • Kryptografischer Audit-Trail • Made in Germany

40
PII-Kategorien
39
Custom Recognizer
ZK
Zero Knowledge
10+
KI-Provider
ki-shield.de Version 5.1 Stand: März 2026

Inhaltsverzeichnis

  1. Executive Summary
  2. Problemstellung: KI und Datenschutz
  3. Die Lösung: KI-Shield
  4. Zero-Knowledge-Architektur (USP)
  5. — Argon2id Key Derivation • Per-User DEK • Recovery Key
  6. Systemarchitektur und Datenfluss
  7. — Request-Lifecycle • Technologie-Stack • Architekturdiagramm
  8. PII-Erkennung im Detail (40 Kategorien)
  9. — 4 Erkennungsgruppen • 39 Custom Recognizer • Pipeline
  10. Sicherheitsarchitektur
  11. — Defense-in-Depth • Verschlüsselung • Audit-Trail
  12. Compliance-Framework (DSGVO & AI Act)
  13. Deployment-Optionen
  14. Preismodell
  15. Anwendungsszenarien
  16. Zusammenfassung und Ausblick

1. Executive Summary

Künstliche Intelligenz revolutioniert Geschäftsprozesse — von der juristischen Recherche über medizinische Dokumentation bis zur Finanzanalyse. Doch die Nutzung externer KI-Dienste birgt ein fundamentales Datenschutzrisiko: Personenbezogene Daten verlassen unkontrolliert die Unternehmensinfrastruktur und werden an Server in Drittländern übermittelt.

KI-Shield löst dieses Problem als intelligente Middleware mit einer weltweit einzigartigen Kombination: Automatische PII-Pseudonymisierung (40 Kategorien, 39 Custom Recognizer) gepaart mit einer Zero-Knowledge-Architektur, bei der selbst der Betreiber keinen Zugriff auf Nutzerdaten hat.

40
PII-Kategorien
39
Custom Recognizer
10+
KI-Provider
ZK
Zero Knowledge
🔒 Kernversprechen KI-Shield ermöglicht Unternehmen die volle Leistung moderner KI-Modelle — ohne personenbezogene Daten preiszugeben. Selbst der Betreiber von KI-Shield kann Ihre Daten kryptografisch nicht lesen. Das ist keine Policy, sondern Mathematik.

2. Problemstellung: KI und Datenschutz

2.1 Die Realität der KI-Nutzung

Laut Bitkom Digital Office Index 2025 nutzen 68% der Unternehmen bereits KI-Tools — aber nur 23% haben eine Datenschutz-Strategie dafür. Die eingegebenen Daten enthalten häufig:

2.2 Regulatorische Anforderungen

RegelwerkAnforderungBußgeld
DSGVO Art. 5Datenminimierung & VertraulichkeitBis 20 Mio. € oder 4% Jahresumsatz
DSGVO Art. 9Besondere Kategorien (Gesundheit, Religion, Genetik, etc.) — Verarbeitungsverbot
DSGVO Art. 25Privacy by Design & Default
DSGVO Art. 44-49Drittlandtransfer nur mit Schutzmaßnahmen—
EU AI ActTransparenz, Risikomanagement, Audit-TrailBis 35 Mio. €
§ 203 StGBÄrztliche Schweigepflicht / AnwaltsgeheimnisFreiheitsstrafe bis 1 Jahr
⚠ Das Dilemma KI ist ein Wettbewerbsfaktor — aber Datenschutz verbietet die Weitergabe personenbezogener Daten an externe Dienste. Bisherige Lösungen (KI-Verzicht, On-Premise-Modelle, manuelle Anonymisierung) sind unpraktikabel oder nicht skalierbar.

3. Die Lösung: KI-Shield

KI-Shield ist eine transparente, DSGVO-konforme Middleware zwischen Anwender und KI-Dienst. Das System arbeitet vollständig automatisch und erfordert keine Änderung am Nutzerverhalten.

3.1 Request-Lifecycle

👤 NutzerEingabe mit echten Daten
→
🔍 PII-Scan40 Kategorien erkennen
→
🔐 PseudonymisierungPII → [PERSON_001]
→
🤖 KI-ProviderErhält nur Pseudonyme
→
🔄 Re-IdentifikationPseudonyme → Original
→
👤 NutzerSieht echte Antwort

Beispiel: Anwaltliche Mandatsanfrage

PhaseText
👤 NutzereingabePrüfe den Fall von Dr. Thomas Weber (weber@kanzlei.de), geb. 15.03.1978, wohnhaft München, Leopoldstr. 42. Zahlung auf DE89 3704 0044 0532 0130 00.
🤖 KI siehtPrüfe den Fall von PERSON_001 (EMAIL_001), geb. GEBURT_001, wohnhaft ADRESSE_001. Zahlung auf IBAN_001.
🤖 KI antwortetSehr geehrter PERSON_001, bezüglich Ihrer Zahlung auf IBAN_001 ...
👤 Nutzer siehtSehr geehrter Dr. Thomas Weber, bezüglich Ihrer Zahlung auf DE89 3704 0044 0532 0130 00 ...

4. Zero-Knowledge-Architektur (USP)

Die Zero-Knowledge-Architektur ist das zentrale Alleinstellungsmerkmal von KI-Shield. Im Gegensatz zu herkömmlichen SaaS-Produkten hat selbst der Betreiber kryptografisch keinen Zugriff auf Nutzerdaten. Dies wird nicht durch Policies, sondern durch mathematische Garantien sichergestellt.

4.1 Schlüsselableitung (Key Derivation)

zero-knowledge ~ key-derivation
# 1. Nutzer gibt Passwort ein (Client-Side) password = "s3cureP@ssw0rd!" # 2. Server generiert kryptografisch sicheren Salt (32 Bytes) salt = os.urandom(32) # pro User einzigartig, in DB gespeichert # 3. Argon2id leitet 256-bit Data Encryption Key (DEK) ab DEK = argon2id( password = password, salt = salt, time_cost = 3, # 3 Iterationen memory = 65536, # 64 MB RAM-Kosten (Anti-GPU/ASIC) parallelism = 4, # 4 Threads hash_len = 32 # 256-bit Output ) # → b'\x8a\x3f\x12...' (32 Bytes) # 4. DEK wird NUR in Redis-RAM gespeichert (flüchtig) redis.setex( f"zk:dek:{session_id}", ttl = 86400, # 24h, dann automatisch gelöscht value = DEK ) # 5. Alle Daten werden mit dem DEK verschlüsselt (AES-256-Fernet) encrypted_msg = Fernet(DEK).encrypt(plaintext) # → gAAAAABm...xQ== (in PostgreSQL gespeichert) # ⚠ DEK existiert NIE auf Festplatte, NIE in der Datenbank # ⚠ Ohne Passwort: DEK nicht rekonstruierbar → Daten unlesbar

4.2 Was wird verschlüsselt?

DatenkategorieVerschlüsselungSchlüssel
Chat-Nachrichten (User & Assistant)AES-256-FernetPer-User DEK
KonversationstitelAES-256-Fernet + title_encrypted FlagPer-User DEK
Audit-Log BodiesAES-256-Fernet (encrypted_body)Per-User DEK
BYOK API-KeysAES-256-FernetPer-User DEK
PII-MappingsAES-256-FernetPer-User DEK
Passwörterbcrypt (12 Rounds)Einweg-Hash

4.3 DEK-Lebenszyklus

🔑 LoginPasswort eingeben
→
Argon2idDEK ableiten
→
Redis RAMDEK temporär speichern
→
AES-256Daten ver-/entschlüsseln
→
Logout/TTLDEK aus RAM gelöscht

4.4 Recovery Key

Bei der Registrierung erhält jeder Nutzer einen Recovery Key (Base58-codiert, 256-bit). Dieser ermöglicht die Wiederherstellung des DEK bei Passwortverlust:

recovery-key ~ mechanism
# Bei Registrierung: recovery_key = base58_encode(os.urandom(32)) # → "5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ" # DEK wird mit Recovery Key verschlüsselt (Fernet-Wrapping) wrapped_dek = Fernet(recovery_key).encrypt(DEK) # wrapped_dek wird in DB gespeichert (verschlüsselt!) # Bei Passwort-Reset: DEK = Fernet(recovery_key).decrypt(wrapped_dek) # → DEK wiederhergestellt, neues Passwort, neuer Salt

4.5 Vergleich: Klassisch vs. Zero Knowledge

🚫 Klassische SaaS-Architektur

  • Betreiber hat Master-Key für alle Daten
  • Datenbank-Dump = alle Daten kompromittiert
  • Behördenanfrage = Herausgabe möglich
  • Insider-Threat = voller Datenzugriff
  • Sicherheitsmodell: „Vertrauen Sie uns“

🔒 KI-Shield Zero Knowledge

  • Kein Master-Key — jeder User hat eigenen DEK
  • Datenbank-Dump = wertlose Ciphertexte
  • Behördenanfrage = nichts Lesbares vorhanden
  • Insider-Threat = kein Zugriff ohne Passwort
  • Sicherheitsmodell: Kryptografie statt Vertrauen
💡 Warum Argon2id? Argon2id ist der Gewinner des Password Hashing Competition (2015) und kombiniert Schutz gegen GPU-Angriffe (memory-hard) mit Schutz gegen Side-Channel-Angriffe. Die Konfiguration (64 MB RAM, 3 Iterationen) macht Brute-Force-Angriffe auch mit spezialisierter Hardware unwirtschaftlich.

5. Systemarchitektur und Datenfluss

5.1 Architekturübersicht

👤 Endnutzer (Browser / API-Client)
↓ HTTPS (TLS 1.3)
🌐 Caddy Reverse ProxyAuto-TLS, HSTS, CSP
↓
🛡 KI-Shield Core (FastAPI Async, Python 3.12)
↓
🔐 Security LayerRate Limiting, CORS, CSP
🔑 Dual AuthJWT + API-Key
📦 Zero KnowledgeArgon2id → DEK
↓
🔍 PII-EnginePresidio + spaCy + 39 Recognizer
🔄 PseudonymizerMapping + Re-ID
📋 Audit EngineEd25519 + SHA-256 Chain
↓
🤖 Provider Registry10 KI-Anbieter, Retry + Backoff
↓
💾 PostgreSQL 16AES-256 at-rest
⚡ Redis 7DEK (RAM-only), Rate Limits
🌐 KI-APIsOpenAI, Anthropic, Google, ...

5.2 Technologie-Stack

KomponenteTechnologieBegründung
BackendPython 3.12 + FastAPIAsync I/O, OpenAPI-Docs, hohe Performance
PII-ErkennungMicrosoft Presidio + spaCy (de_core_news_lg)Enterprise-erprobte NER + 39 Custom Recognizer
Key DerivationArgon2id (64 MB, 3 Iter.)Sieger Password Hashing Competition, memory-hard
VerschlüsselungAES-256-Fernet (Per-User DEK)Zero Knowledge — Betreiber hat keinen Schlüssel
Audit-SignaturenEd25519 + SHA-256 ChainKryptografisch verkettete, manipulationssichere Logs
AuthentifizierungJWT HS256 + bcrypt + API-KeysDual-Auth: Web-Sessions und M2M-Zugriff
DatenbankPostgreSQL 16ACID-konform, bewährt im Enterprise-Umfeld
Cache / DEK-StoreRedis 7 (RAM-only)Flüchtiger DEK-Speicher, Rate Limiting
Reverse ProxyCaddyAutomatisches TLS (Let's Encrypt), HTTP/2
FrontendAlpine.js + Tailwind CSSKein Build-Schritt, schnelle Ladezeiten
ContainerDocker + Docker ComposeMulti-Stage Builds, non-root User

5.3 Request-Lifecycle (Detail)

  1. Eingang: Nutzeranfrage über Web-Chat oder API (HTTPS/TLS 1.3)
  2. Authentifizierung: JWT-Cookie (Web) oder X-API-Key (API) — timing-safe Vergleich
  3. DEK laden: Per-User Data Encryption Key aus Redis-RAM laden (Zero Knowledge)
  4. Unicode-Normalisierung: NFKC-Normalisierung gegen Unicode-Bypass-Angriffe
  5. PII-Scan: Presidio + spaCy + 39 Custom Recognizer analysieren den Text
  6. Overlap-Resolution: Überlappende Erkennungen werden aufgelöst (höchster Score gewinnt)
  7. Type-Conflict-Resolution: Typ-Konflikte bei gleichen Spans (z.B. CREDIT_CARD vs. IMEI) per Kontext
  8. False-Positive-Filter: spaCy-NER-Fehlerkennungen werden heuristisch gefiltert
  9. Pseudonymisierung: PII → Session-konsistente Platzhalter (PERSON_001, IBAN_001, ...)
  10. KI-Weiterleitung: Pseudonymisierter Text an gewählten Provider (mit Retry + Exponential Backoff)
  11. Re-Identifikation: Pseudonyme in KI-Antwort durch Originale ersetzen
  12. Verschlüsselung: Nachricht + Mapping AES-256-verschlüsselt mit DEK in DB
  13. Audit-Log: Transaktion Ed25519-signiert, SHA-256-verkettet
  14. Antwort: Re-identifizierte Antwort an Nutzer

6. PII-Erkennung im Detail (40 Kategorien)

KI-Shield erkennt 40 Kategorien personenbezogener Daten mithilfe von 39 Custom Recognizern, dem spaCy-NER-Modell de_core_news_lg und Microsoft Presidio als Orchestrierungs-Engine. Die Recognizer sind in 4 Gruppen organisiert:

6.1 Erkennungspipeline

EingabetextUnicode NFKC
→
spaCy NERML-basiert
→
14 PatternRegex-Recognizer
→
10 RegexTechn. Formate
→
15 KeywordArt. 9/10 DSGVO
→
Post-FilterOverlap + FP

6.2 Gruppe 1: Basis-Erkennung (16 Typen, 14 Custom Recognizer)

Pattern-basierte und NER-gestützte Recognizer für grundlegende PII:

👤
PERSON
spaCy + 15 Titel-Patterns
✉
EMAIL
Regex + TLD-Validierung
☎
PHONE_NUMBER
7 Regex-Patterns (DE)
🏦
IBAN
5 Patterns + Prüfziffer
📋
TAX_ID
4 Patterns (USt/StNr/TIN)
🎂
DATE_OF_BIRTH
5 Datumsformate
📅
DATE_TIME
Regex + Kontext
🚗
LICENSE_PLATE
Regex (DE-Format)
💳
SOCIAL_SECURITY
Regex (12-stellig)
🏠
ADDRESS
4 Regex-Patterns (PLZ/Str)
⚕
HEALTH_DATA
706 Keywords (ICD, Medikamente)
📍
LOCATION
80 Städte + 16 BL + 45 Länder
🏢
ORGANIZATION
13 Rechtsform-Patterns
💳
CREDIT_CARD
12 Patterns + Luhn
📇
ID_DOCUMENT
4 Patterns + ICAO 9303
🌍
NRP
162 Keywords (Nat./Rel./Pol.)

6.3 Gruppe 2: Technische Identifikatoren (10 Typen, 10 Regex-Recognizer)

💻
IP_ADDRESS
IPv4 + IPv6 Regex
🏦
BIC_SWIFT
8/11-stellig Regex
🚘
VIN_NUMBER
17-stellige FIN Regex
📍
GPS_COORDINATES
DD + DMS Format
📄
DRIVERS_LICENSE
DE-Format Regex
🏥
HEALTH_INS_NR
KVNR (10-stellig)
🏢
HANDELSREGISTER
HRB/HRA Regex
⚖
AKTENZEICHEN
Gerichtliches AZ Regex
📶
MAC_ADDRESS
AA:BB:CC:DD:EE:FF
📱
IMEI_NUMBER
15-stellig + Kontext

6.4 Gruppe 3: Art. 9 DSGVO — Besondere Kategorien (7 Typen, 700 Keywords)

⚠ Art. 9 DSGVO — Verarbeitungsverbot Die Verarbeitung besonderer Kategorien personenbezogener Daten ist grundsätzlich untersagt. KI-Shield erkennt diese Daten mit spezialisierten Keyword-Recognizern und verhindert ihre Übermittlung an KI-Provider.
🧬
GENETIC_DATA
101 Keywords
🤚
BIOMETRIC_DATA
79 Keywords
🌍
ETHNIC_ORIGIN
114 Keywords
🗳
POLITICAL_OPINION
103 Keywords
🕌
RELIGIOUS_BELIEF
114 Keywords
✊
UNION_MEMBERSHIP
92 Keywords
🌈
SEXUAL_ORIENT.
97 Keywords
KategorieKeywordsAbdeckung (Beispiele)
GENETIC_DATA101DNA, Gentest, BRCA1/2, PCR, CRISPR, Trisomie 21, Karyogramm, Biobank
BIOMETRIC_DATA79Fingerabdruck, Gesichtserkennung, Irisscan, Stimmbiometrie, Touch ID, ePass
ETHNIC_ORIGIN114Ethnie, Roma/Sinti, Einbürgerung, Asylverfahren, Duldung, AGG, Racial Profiling
POLITICAL_OPINION103Parteimitgliedschaft, CDU/SPD/Grüne, Demonstration, Verfassungsschutzakte
RELIGIOUS_BELIEF114Konfession, Kirchensteuer, Ramadan, Bar Mizwa, Schabbat, Imam, Pfarrer
UNION_MEMBERSHIP92ver.di, IG Metall, DGB, Betriebsrat, Streik, Tarifvertrag, Urabstimmung
SEXUAL_ORIENT.97Homosexuell, Transgender, Coming Out, CSD, Lebenspartnerschaft, Konversionstherapie

6.5 Gruppe 4: Art. 10 + Lebensbereiche (7 Typen, 868 Keywords)

👮
CRIMINAL_DATA
116 Keywords
👶
CHILD_DATA
107 Keywords
💰
FINANCIAL_DATA
131 Keywords
💼
EMPLOYMENT_DATA
146 Keywords
🎓
EDUCATION_DATA
126 Keywords
🏥
SOCIAL_BENEFITS
125 Keywords
🛡
INSURANCE_DATA
117 Keywords
KategorieKeywordsAbdeckung (Beispiele)
CRIMINAL_DATA116Strafverfahren, Führungszeugnis, JVA, Bewährung, BtM-Verstoß, Vorstrafe
CHILD_DATA107Sorgerecht, Jugendamt, Inobhutnahme, Kita, Schulakte, Adoption, Cybermobbing
FINANCIAL_DATA131Gehalt, Schufa, Pfändung, Insolvenz, Kontoauszug, Kreditvertrag, Steuerbescheid
EMPLOYMENT_DATA146Arbeitsvertrag, Kündigung, Abmahnung, Arbeitszeugnis, Kurzarbeit, Elternzeit, BEM
EDUCATION_DATA126Matrikelnummer, BAföG, Abiturnote, Promotion, Gesellenprüfung, Stipendium
SOCIAL_BENEFITS125Bürgergeld, ALG I/II, Wohngeld, Kindergeld, Pflegegrad, Grundsicherung, Jobcenter
INSURANCE_DATA117Police, Kaskoversicherung, Schadensfreiheitsklasse, BU, Gesundheitsfragen, Prämie

6.6 Erkennungsmethoden im Detail

MethodeRecognizerBesonderheiten
spaCy NER
(Machine Learning)		 Basis für PERSON, LOCATION, ORG Kontextverständnis; Custom Recognizer überschreiben spaCy bei höherem Score
Pattern Recognizer
(Regex + Kontext)		 14 Recognizer (Basis) + 10 (Regex) Deutsche Formate; Kontext-Wörter boosten Score um ~0.35; case-sensitive für Eigennamen
Keyword Recognizer
(Wortlisten)		 15 Recognizer (1.730 Keywords) Case-insensitive (?i)\b(?:kw1|kw2|...)\b; Art. 9/10 DSGVO + NRP
Validierungs-Methoden Luhn, ICAO 9303, Prüfziffern Kreditkarten: Luhn-Algorithmus; Ausweise: ICAO 9303 (Gewichte 7-3-1); IBAN: Prüfziffer

6.7 Post-Processing-Pipeline

SchrittFunktionBeispiel
Unicode NFKCNormalisierung gegen Bypass-AngriffeFullwidth ０１２３ → 0123
Overlap ResolutionBei überlappenden Erkennungen gewinnt höchster Score„80331 München“ > „München“ (ADDRESS > LOCATION)
Type ConflictKontext-basierte Auflösung gleicher Spans15-Ziffern + „IMEI“-Kontext → IMEI statt CREDIT_CARD
FP-FilterspaCy-NER False Positives entfernen„Mandatsanfrage“ wird nicht als PERSON erkannt

7. Sicherheitsarchitektur

Defense-in-Depth mit mehreren unabhängigen Schutzebenen:

7.1 Verschlüsselung

🔐 AES-256-Fernet (Per-User DEK)

Alle PII-Mappings, Chat-Nachrichten, BYOK-Keys, Titel und Audit-Bodies sind mit dem nutzereigenen Schlüssel verschlüsselt. Zero Knowledge.

🌐 TLS 1.3 In-Transit

Sämtliche Kommunikation ist TLS 1.3 verschlüsselt (Let's Encrypt via Caddy, automatische Erneuerung).

🔑 Argon2id Passwort-Hashing

Passwörter werden mit Argon2id gehasht (64 MB, 3 Iterationen). Zusätzlich bcrypt (12 Rounds) für Auth-Kompatibilität.

✍ Ed25519 Audit-Signaturen

Jeder Audit-Log-Eintrag wird digital signiert und kryptografisch mit dem vorherigen verkettet (SHA-256 Hash-Chain).

7.2 Authentifizierung

MechanismusEinsatzDetails
JWT httpOnly CookieWeb-FrontendHS256, 7 Tage Gültigkeit, Secure + SameSite=Lax
X-API-Key HeaderAPI (M2M)SHA-256 Hash in DB, HMAC timing-safe Vergleich
Google OAuthSocial LoginDownload-Key-Modell (ZK-kompatibel)
BYOK API-KeysKI-Provider-KeysAES-256 verschlüsselt, nur UUID-Referenz im Frontend

7.3 Infrastruktur-Sicherheit

MaßnahmeImplementation
Rate LimitingRedis Sliding-Window (30 req/s API, 10 req/s Chat, 5 req/s Auth)
Security HeadersCSP, HSTS (max-age=31536000), X-Frame-Options, X-Content-Type-Options, Permissions-Policy
CORSStrikte Whitelist (nur Produktions-Domain)
PII in LogsStructlog PII-Scrubber filtert personenbezogene Daten aus Server-Logs
API-Key-SanitizerMaskiert API-Keys in Fehlermeldungen automatisch
Multi-Tenantuser_id Filter auf allen Datenbank-Queries
FirewallUFW (nur SSH, HTTP, HTTPS offen)
SSH-SchutzFail2Ban (3 Versuche, 2h Sperre)
ContainerMulti-Stage Build, non-root User, minimales Image
Retry-SicherheitExponential Backoff (1s, 2s, 4s) für Provider-Anfragen
Unicode-SchutzNFKC-Normalisierung verhindert Homoglyph- und Fullwidth-Bypass

7.4 Kryptografischer Audit-Trail

audit-chain ~ ed25519
# Jeder Audit-Eintrag enthält: { "id": 42, "timestamp": "2026-03-01T14:23:17Z", "user_id": 7, "action": "chat_completion", "encrypted_body": "gAAAAABm...xQ==", # AES-256 mit User-DEK "content_hash": "sha256:a3f8c2...", # SHA-256 des Klartexts "signature": "ed25519:7b2e9f...", # Ed25519 Signatur "prev_hash": "sha256:f1d4b7..." # Hash des vorherigen Eintrags } # Manipulation erkennen: GET /api/v1/audit/verify → {"valid": true, "entries_checked": 1847, "chain_intact": true}

8. Compliance-Framework (DSGVO & AI Act)

8.1 DSGVO-Konformität

DSGVO-ArtikelAnforderungKI-Shield Umsetzung
Art. 5 (1c)DatenminimierungNur pseudonymisierte Daten verlassen das System
Art. 5 (1f)Integrität & VertraulichkeitAES-256 + TLS 1.3 + Ed25519 + Zero Knowledge
Art. 9Besondere Kategorien7 spezialisierte Recognizer mit 700 Keywords erkennen Genetik, Biometrie, Religion, Politik, Ethnie, Gewerkschaft, Sexualität
Art. 10Strafrechtliche Daten116 Keywords für Strafverfahren, Führungszeugnis, JVA etc.
Art. 25Privacy by DesignPseudonymisierung + Zero Knowledge als Kernarchitektur
Art. 30VerarbeitungsverzeichnisVollständiger, Ed25519-signierter Audit-Trail
Art. 32Technische Maßnahmen54 Sicherheitsmaßnahmen, Per-User DEK, Multi-Tenant
Art. 44-49DrittlandtransferKeine echten PII verlassen EU-Serverstandort

8.2 AI Act Konformität

AnforderungKI-Shield Umsetzung
TransparenzPII-Shield-Badge, Dashboard mit PII-Statistiken, Export als JSON/CSV
RisikomanagementConfidence-Scores pro Erkennung, Feedback-System
Audit-TrailEd25519-signierte, SHA-256-verkettete Audit-Kette
Menschliche AufsichtDashboard mit Echtzeit-KPIs und Provider-Status

8.3 Branchenspezifischer Schutz

⚕ Gesundheitswesen 706 medizinische Keywords (ICD-10-Codes, Medikamente, Diagnosen, Symptome, Laborwerte, Operationen, psychische Störungen, Infektionskrankheiten). Schutz gemäß § 203 StGB + Art. 9 DSGVO.
⚖ Rechtsbranche Aktenzeichen-Erkennung (gerichtliche Formate), Mandantendaten-Schutz, Personalausweis/Reisepass mit ICAO-9303-Prüfziffervalidierung. Schutz der anwaltlichen Verschwiegenheitspflicht.

9. Deployment-Optionen

9.1 SaaS-Plattform (Managed)

EigenschaftDetails
URLhttps://ki-shield.de
HostingHetzner Cloud, Nürnberg (Deutschland, EU)
StackCaddy + FastAPI + PostgreSQL 16 + Redis 7
TLSLet's Encrypt (TLS 1.3, automatische Erneuerung)
BackupTägliches automatisches Backup (14 Tage)

9.2 Self-Hosted (Docker)

EditionContainerDatenbankGeeignet für
Community1 (API + SQLite)SQLiteEvaluierung, Einzelentwickler
Professional1 (API + SQLite)SQLiteFreelancer, kleine Teams
Enterprise3 (API + PostgreSQL + Redis)PostgreSQL 16Unternehmen, regulierte Branchen
installation ~ docker
# Interaktiver Installer (Edition wählen, Env konfigurieren, Container starten) $ curl -sSL https://ki-shield.de/install.sh | bash # Oder manuell: $ git clone https://github.com/ki-shield/ki-shield.git $ cd ki-shield $ bash install.sh → Edition wählen: [1] Community [2] Professional [3] Enterprise

10. Preismodell

10.1 SaaS-Plattform

Free
0 €
pro Monat
  • 50 Anfragen / Monat
  • 2 Provider (OpenAI + Groq)
  • Volle PII-Erkennung (40 Kat.)
  • Zero Knowledge Architektur
  • 7 Tage Nachrichtenspeicher
  • BYOK (eigene API-Keys)
Pro
49 €
pro Monat (netto)
  • Unbegrenzte Anfragen
  • Alle 10+ KI-Provider
  • Volle PII-Erkennung (40 Kat.)
  • Zero Knowledge Architektur
  • Echtzeit-Streaming (SSE)
  • Audit-Export (JSON/CSV)
  • E-Mail-Support
Business
99 €
pro Monat (netto)
  • Alles aus Pro
  • Bis zu 5 Team-Mitglieder
  • Team-Verwaltung
  • Compliance-Reports
  • Prioritäts-Support
  • DPIA-Dokumentation

Alle Preise netto zzgl. MwSt. • Monatlich kündbar • BYOK: Sie zahlen nur die Compliance-Schicht, KI-Kosten direkt beim Provider.

11. Anwendungsszenarien

⚖ Kanzleien & Rechtsabteilungen

Vertragsprüfung, Rechtsprechungsrecherche, Schriftsatz-Entwürfe — ohne Mandantendaten preiszugeben. Erkennt Aktenzeichen, Personalausweis/Reisepass (ICAO-validiert).

🏥 Ärzte, Praxen & Kliniken

Arztbriefe, Befund-Zusammenfassungen, medizinische Dokumentation. 706 medizinische Keywords, Schutz gem. § 203 StGB.

📊 Steuerberater & WP

Steuererklärungen, Bilanzanalysen, Gutachten. Erkennt Steuer-IDs, IBANs, Finanzdaten (131 Keywords).

🏢 Unternehmen & HR

Bewerbungsfilter, Kunden-E-Mails, interne Reports. Erkennt Arbeitsverträge, Beurteilungen (146 Keywords).

🛡 Datenschutzbeauftragte

DPIA-fähige Dokumentation, revisionssicheres Audit-Log, TOM-Nachweis. 40 PII-Kategorien inkl. Art. 9/10.

💻 Software-Integration (API)

OpenAI-kompatible REST-API. Drop-in-Replacement: Nur URL ändern + X-API-Key hinzufügen.

🔄 Universelle Kompatibilität POST /api/v1/chat/completions folgt dem OpenAI-API-Standard. Jede Anwendung, die OpenAI unterstützt, kann ohne Code-Änderung auf KI-Shield umgestellt werden.

12. Zusammenfassung und Ausblick

12.1 Zusammenfassung

KI-Shield schließt die Lücke zwischen der wachsenden Nachfrage nach KI-Diensten und den strengen europäischen Datenschutzanforderungen. Die Kombination aus automatischer Echtzeit-Pseudonymisierung (40 Kategorien, 39 Custom Recognizer) und Zero-Knowledge-Architektur ist einzigartig am Markt.

40
PII-Kategorien
39
Custom Recognizer
~2.400
Keywords total
54
Sicherheitsmaßnahmen

Die Kernstärken:

12.2 Ausblick

12.3 Kontakt

KanalDetails
Websitehttps://ki-shield.de
E-Mailinfo@bringeful.de
Telefon+49 175 648 66 34 (Johanna Bringezu)
HostingHetzner Cloud, Nürnberg (Deutschland, EU)

KI-Shield — DSGVO- & AI-Act-konforme KI-Nutzung mit Zero-Knowledge-Architektur

https://ki-shield.de • Ein Produkt von BRINGEFUL • Version 5.1 • Stand: März 2026

© 2024–2026 KI-Shield by BRINGEFUL. Alle Rechte vorbehalten. Dieses Whitepaper dient ausschließlich zu Informationszwecken.