KI-Shield Security Architecture
Datenschutzkonforme Nutzung generativer KI mit Zero-Knowledge-Pseudonymisierung, Post-Quantum-signierter Audit-Kette und Blockchain-verankerter Beweisführung.
Executive Summary
KI-Shield ist eine kryptografische Sicherheitsarchitektur, die Unternehmen die datenschutzkonforme Nutzung generativer KI-Sprachmodelle (ChatGPT, Claude, Gemini, Mistral AI, Llama und weitere) ermöglicht. Kern des Systems ist ein mehrschichtiges Pseudonymisierungsverfahren, das personenbezogene Daten bereits auf dem Endgerät des Nutzers im Webbrowser erkennt und durch typerhaltende Stellvertreterzeichenketten ersetzt, bevor sie an einen externen Sprachverarbeitungsdienst übertragen werden.
Ergänzend implementiert KI-Shield eine manipulationssichere Audit-Kette mit hybrider Signatur-Architektur: jeder Audit-Eintrag wird gleichzeitig mit einem klassischen Ed25519-Schlüssel und mit dem NIST-standardisierten Post-Quantum-Verfahren ML-DSA-65 (FIPS 204) signiert und vor dem Speichern unmittelbar gegen-verifiziert (Write-Time-Verifikation). Eine tägliche Verankerung in der Polygon-Blockchain sichert die Beweiskraft öffentlich ab.
1. Regulatorischer Kontext
KI-Shield adressiert die folgenden Rahmenwerke durch seine Architektur — nicht durch vertragliche Zusagen:
| Rahmen | Pflicht | KI-Shield-Antwort |
|---|---|---|
| DSGVO Art. 25 | Datenschutz durch Technikgestaltung | Client-seitige Pseudonymisierung vor jeder Datenübertragung |
| DSGVO Art. 32 | Angemessene technische Maßnahmen | Zero-Knowledge, AES-256-GCM, Server: Argon2id (t=3, m=64MB, p=4) · Browser: PBKDF2-SHA256 600.000 Iter |
| DSGVO Art. 9 | Besondere Kategorien (Gesundheit etc.) | Dedizierte Erkennungsschicht für medizinische Begriffe |
| § 203 StGB | Schweigepflicht für Berufsgeheimnisträger | Kein Klartext verlässt den Nutzer-Rechner |
| EU AI Act | Transparenz + Governance bei KI-Einsatz | Vollständig protokollierter, signierter Audit-Trail |
| eIDAS 2.0 | Qualifizierte Zeitstempel / PQC-Pflicht | RFC-3161 + ML-DSA-65 |
| BSI IT-Grundschutz | Basisschutz kritischer Prozesse | EU-Hosting, mTLS zwischen Diensten, Step-CA-PKI |
| NIST FIPS 204 | Standard für quantensichere Signaturen | ML-DSA-65 (Dilithium) in jeder Audit-Signatur |
2. Architektur-Übersicht
KI-Shield besteht aus zwei strikt getrennten Domänen: einer Nutzer-Domäne (Webbrowser auf dem Endgerät) und einer Betreiber-Domäne (Server-Infrastruktur). Zwischen beiden Domänen wird zu keinem Zeitpunkt unverschlüsselter personenbezogener Inhalt übertragen.
2.1 Module in der Nutzer-Domäne (Webbrowser, lokal)
- Dokumentenextraktionsmodul (10): PDF, DOCX, OCR (WebAssembly). Dokumente verlassen das Endgerät nicht.
- Mustererkennungsmodul (20): vier parallele Erkennungsschichten (siehe §3).
- Substitutionsmodul (30): Ersetzt Tokens durch typerhaltende Stellvertreter; verwaltet die bidirektionale Zuordnungstabelle ausschließlich im flüchtigen RAM.
- Kryptografisches Sicherungsmodul (40): Web-Crypto-API. PBKDF2-SHA256 mit 600.000 Iterationen (Web-Crypto-API-Limit), AES-256-GCM.
- Re-Substitutionsmodul (70): Ersetzt Stellvertreter in der KI-Antwort zurück durch die Originaltokens.
- Orchestrierungsmodul (80): Wählt zwischen Nur-RAM und verschlüsseltem Chiffretext-Storage.
2.2 Module in der Betreiber-Domäne
- Empfangsschnittstelle (51): Nimmt ausschließlich den substituierten Anfragetext und Metadaten entgegen.
- Weiterleitung an externen Sprachverarbeitungsdienst (60): HTTPS-Routing (BYOK: ChatGPT, Claude, Gemini, Mistral, Llama).
- Speichereinheit (53): Speichert nur Chiffretextblöcke — ohne Entschlüsselungsmittel.
- Audit-Kette: Ed25519 + ML-DSA-65 dual-signiert, Write-Time-verifiziert.
- Aktivitätsbasierte Blockchain-Verankerung: Alle 5 Minuten bei neuen Audit-Einträgen, zusätzlich täglicher Sicherheits-Anchor um 02:00 UTC. Verankert wird der SHA-256-Hash des aktuellen Chain-Status (anchor_hash über letzten Chain-Hash + Chain-Länge + Zeitstempel) in der Polygon-Blockchain.
3. Vier-Schichten-PII-Erkennung
Das Mustererkennungsmodul kombiniert vier parallele Erkennungsschichten. Konfliktauflösung nach dem Prinzip der längsten Übereinstimmung sowie kontextbasierter Unterscheidung.
3.1 Namensbasierte Erkennungsschicht
Prüfung gegen Eigennamen-Sammlung mittels Set-basierter Hash-Suche in konstanter Zeit. Kontextuelle Hinweise (Anreden, akademische Titel) erhöhen die Präzision bei Mehrdeutigkeiten.
3.2 Musterbasierte Erkennungsschicht mit Prüfziffer-Validierung
- MOD-97 für IBAN (ISO 13616)
- Luhn für Kreditkartennummern (ISO/IEC 7812)
- ISO/IEC 7064 Mod-11,10 für deutsche Steuer-IDs (11-stellig)
- ICAO 9303 für maschinenlesbare Identitätsdokumente
Die Prüfziffer-Validierung reduziert Fehlalarme gegen Null: nur Tokens mit mathematisch korrekter Prüfziffer werden als PII-Kandidaten markiert.
3.3 Schlüsselwortbasierte Erkennungsschicht
Kuratierte Schlüsselwortlisten für 42 PII-Kategorien (Gesundheitsdaten, Religion, politische Meinung, biometrische Daten etc.). Kontextuelle Auswertung zur Vermeidung von Fehltreffern in unbeteiligten Nennungen.
3.4 Kontextbasierte Konfliktauflösung
Bei mehrdeutigen Erkennungen (Geräteseriennummer vs. Telefonnummer, Kreditkartennummer vs. anderer Identifikator) entscheidet eine kontextbasierte Analyse des umgebenden Textes.
3.5 Neuronale Erkennungsschicht (Server-Variante)
Die Server-Variante (KI-Shield Proxy) ergänzt die drei Browser-Schichten durch eine neuronale NER mit spaCy. Die reine Browser-Variante arbeitet ohne ML-Inferenz — komplett deterministisch.
3.6 Custom-Pattern-Engine
Über die REST-Endpunkte GET/POST/DELETE /pii/patterns können Kunden eigene PII-Erkennungsmuster (Regex + Score + Kontextwörter) hinzufügen, ohne den Quellcode anzupassen. Die kundeneigenen Muster werden zur Laufzeit als zusätzliche fünfte Erkennungsschicht eingehängt und gemeinsam mit den vier System-Schichten ausgewertet. Anwendungsfall: Kanzleien hinterlegen interne Aktenzeichen-Formate, Praxen interne Patienten-IDs, Unternehmen interne Mitarbeiternummern.
4. Substitution und Zuordnungstabelle
4.1 Typerhaltende Pseudonyme
Erkannte Tokens werden nicht durch einen generischen Platzhalter ersetzt, sondern durch typspezifische Stellvertreterketten:
Müller → [PERSON_001] 15.03.1978 → [GEBURT_001] DE89 3704... → [IBAN_001] Diabetes Typ 2 → [DIAGNOSE_001]
Der Typerhalt sichert die semantische Kohärenz: die KI behandelt [IBAN_001] weiterhin als Bankkontonummer.
4.2 Initialisierungsoffset gegen Informationslecks
Zu Beginn jeder Sitzung wählt das Substitutionsmodul einen pseudozufälligen Initialisierungsoffset. Die Nummerierung der Pseudonyme startet nicht bei 001, sondern bei einer zufälligen Zahl — aus dem numerischen Anteil einer Stellvertreterkette kann nicht auf die Token-Anzahl der Sitzung geschlossen werden.
4.3 Bidirektionale Zuordnungstabelle
Die Zuordnungstabelle hält die Beziehung zwischen Originaltoken und Pseudonym. Sie ist die Voraussetzung dafür, dass die KI-Antwort beim Eintreffen wieder in Klartext übersetzt werden kann. Wo und wie sie gehalten wird, hängt vom gewählten Betriebsmodus ab — siehe Abschnitt 5.
5. Web-Crypto-Flow und Betriebsmodi
5.1 Modus A — Nur-RAM (maximaler Zero-Knowledge-Schutz)
Die Zuordnungstabelle existiert ausschließlich im flüchtigen Arbeitsspeicher und wird mit dem Tab-Schließen vernichtet. Keine Persistenz.
5.2 Modus B — Verschlüsselter Chiffretext-Storage
- Schlüsselableitung aus dem Nutzerpasswort mittels PBKDF2-SHA256 mit 600.000 Iterationen (Browser-Modus, Web-Crypto-API-Limit) bzw. Argon2id (t=3, m=64MB, p=4) (Server-Modus, OWASP-konform), beide mit kryptografisch zufälligem 32-Byte-Salt.
- Verschlüsselung der Zuordnungstabelle mit AES-256-GCM (Authenticated Encryption, zufälliger IV, Authentifizierungsanhang).
- Übermittlung des Chiffretextblocks an die Speichereinheit des Servers.
- In späterer Sitzung: Abruf, Entschlüsselung im Browser mit dem erneut aus dem Passwort abgeleiteten Schlüssel.
Der Server sieht ausschließlich den verschlüsselten Block. Der Entschlüsselungsschlüssel verlässt zu keinem Zeitpunkt den Browser.
5.3 Browser-Standards, kein Plugin
Das System verwendet ausschließlich standardisierte Browser-Schnittstellen — Web Crypto API, File API, Canvas API. Kein Browser-Plugin, keine Zusatzsoftware.
6. Hybride Post-Quantum-Audit-Kette
6.1 Warum hybrid?
Klassische Signaturverfahren (ECDSA, RSA, Ed25519) sind gegen Quantencomputer verwundbar. Post-Quantum-Verfahren (ML-DSA-65) sind quantensicher, haben aber weniger langjährige Analyseerfahrung. KI-Shield signiert daher jeden Audit-Eintrag gleichzeitig mit beiden Verfahren. Ein Angreifer müsste beide gleichzeitig brechen.
6.2 Write-Time-Verifikation
Nach Erzeugung der beiden Signaturen und vor dem Schreiben in die Audit-Kette werden beide gegen den gerade signierten Payload und die Public Keys verifiziert. Schlägt die Verifikation fehl, wird der Eintrag nicht geschrieben.
6.3 Hash-Chain mit öffentlich prüfbarer Integrität
Jeder Eintrag enthält den Hash des vorherigen Eintrags sowie seinen Chain-Index. Die kryptografische Integritätskette bleibt im Klartext, während die Nutzlasten verschlüsselt sind. Ein Auditor kann die Integrität der Kette verifizieren, ohne die Inhalte zu sehen.
6.4 RFC-3161-Zeitstempel (KI-Shield-eigene TSA)
Der SHA-256-Content-Hash jedes Audit-Eintrags wird durch die KI-Shield-eigene RFC-3161 Time-Stamp Authority versiegelt. Der TSR-Token (TimeStampResp gemäß RFC 3161) wird im Audit-Eintrag als BYTEA-Feld rfc3161_token persistiert und ist unabhängig durch jeden Verifier mit openssl ts -verify gegen das KI-Shield-CA-Zertifikat prüfbar. Eigene Policy-OID: 1.3.6.1.4.1.99999.1.1.1. Bei TSA-Nichtverfügbarkeit greift Graceful Degradation — der Hash-Chain-Eintrag wird trotzdem geschrieben, das Token-Feld bleibt NULL.
6.5 Aktivitätsbasierte Polygon-Verankerung
Alle 5 Minuten prüft ein Smart-Anchor-Cron, ob seit der letzten Verankerung neue Audit-Einträge entstanden sind, und stößt nur dann eine Verankerung an. Zusätzlich läuft ein täglicher Sicherheits-Anchor um 02:00 UTC. Verankert wird der anchor_hash — ein SHA-256 über letzten Chain-Hash, Chain-Länge und Zeitstempel — als Polygon-Transaktion. Der Eintrag ist über tx_hash und Polygonscan öffentlich nachvollziehbar (dritte, unabhängige Beweisebene).
6.6 Public Chain-Explorer
Über öffentlich zugängliche REST-Endpunkte können Dritte die Integrität der Audit-Kette unabhängig prüfen — ohne Account, ohne Klartext-Zugriff:
- GET /verify/chain-status — aktueller Chain-Hash, Chain-Länge, letzter Anchor
- GET /verify/chain-explorer — durchsuchbare Hash-Kette mit Sequenznummern
- POST /verify/chain-entry — Verifikation eines einzelnen Eintrags gegen Hash + Signaturen
- POST /verify-hash — externe Hash-Verifikation gegen Chain
- GET /verify/{certificate_id} — eIDAS-konformer Verifikations-Endpunkt
Die Public-API liefert ausschließlich Hashes, Signaturen und Anker-Metadaten — niemals Klartext-Inhalte. Damit kann jeder Dritte die mathematische Integrität der Kette prüfen, ohne Zugriff auf Nutzerdaten zu erhalten.
7. Compliance-Mapping
| Anforderung | Quelle | KI-Shield-Maßnahme |
|---|---|---|
| Datensparsamkeit | DSGVO Art. 5(1)(c) | Server erhält nur substituierte Pseudonyme |
| Privacy by Design | DSGVO Art. 25 | Pseudonymisierung architektonisch erzwungen |
| Technische Sicherheit | DSGVO Art. 32 | AES-256-GCM, PBKDF2 600k (Browser) / Argon2id (Server), Ed25519 + ML-DSA-65 |
| Besondere Kategorien | DSGVO Art. 9 | Dedizierte Erkennung für Gesundheit/Biometrie |
| Löschpflicht | DSGVO Art. 17 | Chiffretext-Löschung = kryptografische Vernichtung |
| Berufsgeheimnis | § 203 StGB | Kein Klartext verlässt Nutzer-Rechner |
| AI-Act-Transparenz | EU AI Act Art. 13/14 | Lückenlose Audit-Kette mit math. Integrität |
| eIDAS 2.0 PQC | eIDAS 2.0 | ML-DSA-65 (FIPS 204) für zukünftige PQC-Pflicht |
8. Sicherheitsbetrachtungen
Angriffsfläche des Betreibers: Selbst bei vollständiger Kompromittierung des KI-Shield-Servers besitzt der Angreifer ausschließlich verschlüsselte Chiffretextblöcke und Hashes. Ohne das Nutzerpasswort sind diese Daten kryptografisch unbrauchbar. Ein erfolgreicher Angriff auf den Server leckt keine personenbezogenen Daten.
Angriffsfläche des LLM-Anbieters: Der externe Sprachverarbeitungsdienst erhält ausschließlich den substituierten Anfragetext mit Pseudonymen. Auch ein US-Cloud-Act-Zugriff auf OpenAI, Anthropic oder Google liefert keine identifizierenden Nutzerdaten.
Post-Quantum-Widerstandsfähigkeit: Die gleichzeitige Signatur mit Ed25519 und ML-DSA-65 gewährleistet, dass beim Auftreten kryptografisch relevanter Quantencomputer die ML-DSA-65-Signatur die Beweiskraft der Audit-Kette fortführt.
Restrisiko Nutzer-Endgerät: Die Zero-Knowledge-Architektur verlagert einen Teil des Vertrauens auf die Integrität des Nutzer-Endgeräts. Ein kompromittiertes Endgerät kann den Schutz unterlaufen.
9. Bewusste Grenzen
- AVV bleibt erforderlich. Die Zero-Knowledge-Architektur reduziert die Eingriffsintensität, hebt aber nicht die AVV-Pflicht nach Art. 28 DSGVO auf.
- Erkennungsrate ist nicht 100%. Kein PII-Erkennungssystem ist perfekt. Bei hochsensiblen Inhalten zusätzlich manuell prüfen.
- Sprachabhängigkeit. Primär auf deutsche und englische Texte kalibriert.
- Externe LLM-Qualität. Wir haben keinen Einfluss darauf, ob ChatGPT zufällig personenbezogene Phantasie-Antworten generiert. Unser Re-PII-Check der Antwort filtert erkennbare Fälle.
10. B2B-PII-API
Neben der interaktiven Chat-Oberfläche stellt KI-Shield eine RESTful B2B-API bereit, die die PII-Erkennung und -Verarbeitung als eigenständigen Service nutzbar macht — für Software-Hersteller, die KI-Shield in eigene Workflows integrieren wollen. Alle Endpunkte sind durch API-Keys mit Plan-Gating und Rate-Limiting gesichert.
10.1 Detection & Analyse
- POST /detect — PII-Erkennung mit Spans, Typen, Scores
- POST /analyze — Erweiterte Analyse mit Statistik
- POST /classify — Risikokategorie eines Texts (none / low / medium / high)
- POST /risk-score — Numerischer Risiko-Score über alle erkannten PII
10.2 Verarbeitung
- POST /pseudonymize — Reversible Substitution mit typerhaltenden Pseudonymen
- POST /tokenize — Irreversible Hash-Substitution (Einweg)
- POST /sanitize — Schwärzung & Bereinigung (Output ohne Pseudonyme)
- POST /redact — Redaktion mit Markierungen
- POST /redact/stream — Server-Sent-Events Live-Redaktion für lange Texte
- POST /diff — Vergleich der PII-Landschaft zweier Texte
- POST /batch — Batch-Verarbeitung mehrerer Texte
11. AVV-Self-Service
Die Auftragsverarbeitungs-Vereinbarung nach DSGVO Art. 28 ist als Self-Service-Modul integriert. Verantwortliche können den AVV-Vertrag direkt aus der Anwendung heraus signieren und herunterladen — ohne manuellen Vertragsversand.
- GET /avv — aktuelle AVV-Vorlage (HTML/PDF)
- POST /avv/sign — elektronische Signatur durch den Verantwortlichen
- GET /avv/download — signierte AVV als PDF mit Hash-Anker zur Audit-Kette
- GET /avv/my-signature — Status der eigenen AVV-Signatur
- GET /avv/admin/signatures + GET /avv/admin/export — Admin-Übersicht aller AVV-Signaturen für Compliance-Reporting
Der KI-Shield-Chat-Endpunkt prüft vor jeder Anfrage den AVV-Status des aufrufenden Verantwortlichen und blockt Anfragen ohne gültige AVV (Compliance-by-Default).
12. Externe Prüfung — Auditor-API
KI-Shield stellt einen dedizierten API-Pfad für externe Datenschutzbeauftragte (DSB), Compliance-Auditoren und Aufsichtsbehörden bereit. Der Verantwortliche generiert einen zeitlich begrenzten, schreibgeschützten Auditor-Token, der dem Prüfer ausschließlich Zugriff auf Compliance-Reports gibt — nie auf Klartext-Inhalte (Zero-Knowledge bleibt gewahrt).
12.1 Token-Verwaltung
- POST /verify/auditor-token — Token erstellen (Verantwortlicher, Business-Plan)
- GET /verify/auditor-tokens — Liste aktiver Tokens
- PATCH /verify/auditor-token/{id}/revoke — Token vorzeitig widerrufen
12.2 Compliance-Reports (Token-Auth, Read-Only)
- GET /verify/auditor/report — Übergreifender Compliance-Report
- GET /verify/auditor/dpia — Datenschutz-Folgenabschätzung (DSGVO Art. 35)
- GET /verify/auditor/art30 — Verzeichnis der Verarbeitungstätigkeiten (DSGVO Art. 30)
- GET /verify/auditor/ai-act — AI-Act-spezifischer Konformitätsnachweis
- GET /verify/auditor/avv-status — AVV-Status pro Unterauftragsverarbeiter
- GET /verify/auditor/sub-processors — Liste aller eingesetzten Subdienstleister
- GET /verify/auditor/incidents — Sicherheitsvorfälle und Meldungen
- GET /verify/auditor/access-log — Zugriffsprotokoll des Verantwortlichen
- GET /verify/auditor/crypto — Aktueller Krypto-Zustand (Schlüssel-Rotation, Cert-Ablauf)
- GET /verify/auditor/chain — Letzte 100 Audit-Chain-Einträge (nur Hashes + Signaturen)
Zero-Knowledge bleibt erhalten: Auch der Auditor sieht keine personenbezogenen Klartext-Inhalte — nur Hashes, Signaturen, Anker-Metadaten und aggregierte Compliance-Kennzahlen. Damit ist eine vollständige externe Prüfung nach DSGVO und EU AI Act möglich, ohne dass der Auditor Zugriff auf die geschützten Inhalte des Verantwortlichen erhält.
13. Referenzen
NIST FIPS 204 ML-DSA (2024) · FIPS 180-4 SHA-256 · NIST SP 800-38D AES-GCM · RFC 3161 Time-Stamp Protocol · RFC 8032 Ed25519 · RFC 9106 Argon2 · ISO 13616 IBAN · ISO/IEC 7812 Luhn · ISO/IEC 7064 Mod-11,10 · ICAO 9303 MRTD · DSGVO EU 2016/679 · EU AI Act EU 2024/1689 · eIDAS 2.0 EU 2024/1183 · § 203 StGB · BSI IT-Grundschutz
Anhang: Prior-Art-Statement und Lizenzierung
Die in diesem Dokument beschriebene Kernarchitektur ist in folgenden deutschen Gebrauchsmustern geschützt (eingetragen) bzw. angemeldet (Anmeldetag gesichert):
| Schutzrecht | Gegenstand | Status |
|---|---|---|
| DE 20 2026 ___ ___ U1 | Proxy-System mit hybrider PQ-Audit-Kette und Zero-Knowledge-Verschlüsselung | eingetragen 13.03.2026 |
| DE 20 2026 ___ ___ U1 | Zero-Knowledge-Browser-System mit flüchtiger Zuordnungstabelle | eingereicht 09.04.2026 (Anmeldetag gesichert) |
Lizenzierung: Die zusätzlich in diesem Dokument beschriebenen Architektur-Elemente, die nicht Gegenstand der oben genannten Gebrauchsmuster sind (insb. regulatorische Interpretationen, Compliance-Mappings, ergänzende Erkennungsalgorithmen), werden unter der Creative Commons Attribution 4.0 International (CC BY 4.0) veröffentlicht.
Nachbauhinweis: Die Implementierung der durch die oben genannten Gebrauchsmuster geschützten Verfahren erfordert eine Lizenz der Schutzrechtsinhaberin KI-Shield UG. Die Beschreibung in diesem Whitepaper dient der Transparenz gegenüber Kunden, Auditoren und der wissenschaftlichen Öffentlichkeit und stellt keine Lizenzgewährung dar.
Zweck der Veröffentlichung: Technische Dokumentation gegenüber Geschäftskunden, Datenschutzbeauftragten und Auditoren. Ergänzt — nicht ersetzt — die amtliche Gebrauchsmuster-Beschreibung.
Ende des Whitepapers Version 1.0
KI-Shield UG (haftungsbeschränkt) · HRB 524511 Amtsgericht Jena · Greußen, Thüringen
info@ki-shield.de · ki-shield.de · ki-shield.eu
Veröffentlicht am 17. April 2026