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 auf Arweave 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 | Pseudonymisierung vor Weitergabe an die KI — serverseitig (Standard) oder client-seitig im optionalen Browser-ZK-Modus |
| 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): Steuert die client-seitig verschlüsselte Speicherung der Zuordnungstabelle.
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 6 Stunden 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) auf Arweave.
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 vier 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) 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 Betriebsmodi und ihre Zero-Knowledge-Eigenschaften
KI-Shield ist über mehrere Kanäle nutzbar, die sich in ihrer Zero-Knowledge-Eigenschaft unterscheiden. Kein Modus ist „der Server sieht nie etwas"; für jeden Kanal wird präzise benannt, was garantiert ist und was nicht.
| Kanal | Server sieht Klartext? | Persistiert wird | Schlüssel | Zero-Knowledge-Eigenschaft |
|---|---|---|---|---|
| Web-Chat / Proxy (Standard) | Ja — Millisekunden im Server-RAM zur Erkennung, danach verworfen | Nachricht und Zuordnungstabelle, AES-256-GCM unter dem Nutzer-DEK | Client (aus dem Passwort abgeleitet, pro Anfrage übergeben) | Zero-Knowledge at Rest — gespeicherte Daten ohne DEK nicht lesbar; kein Schutz während der aktiven Verarbeitung |
| Browser-ZK-Modus (optional) | Nein — die echten personenbezogenen Werte verlassen den Browser nie; der Server erhält nur pseudonymisierten Text | Pseudonymtext (serverseitig verschlüsselt); die Zuordnung nur als für den Server unlesbarer Block | Rück-Zuordnung ausschließlich im Browser (PBKDF2-SHA256, 600.000 Iter.) | Split-Zero-Knowledge — echte Werte erreichen den Server nicht (nur erkannte Entitäten; der pseudonymisierte Restsatz wird verarbeitet) |
| MCP-Server (KI-Agenten, schlüssellos) | Ja — Millisekunden im Engine-RAM zur Erkennung | Zuordnung AES-256-GCM unter dem Client-DEK; der MCP-Wrapper speichert nichts | Client (Per-Session-DEK, der Server persistiert ihn nie) | Zero-Knowledge at Rest — betreiber-blind im Ruhezustand; Klartext transient nur bei der Erkennung |
| B2B-REST-API (öffentlich) | Ja — kurz im RAM, nicht protokolliert, nicht persistiert | Nichts Umkehrbares — nur ein signiertes Nachweis-Zertifikat mit SHA-256-Hashes | Kein Server-Schlüssel; die Rück-Zuordnung behält allein der Aufrufer | No-Retention — der Server behält nichts Reidentifizierbares |
Im Standard-Web-Chat und beim MCP-Server erkennt und pseudonymisiert der Server die Daten — der Klartext ist dabei für Millisekunden im Arbeitsspeicher sichtbar und wird danach verworfen; gespeichert wird ausschließlich verschlüsselt, unter einem Schlüssel, den der Betreiber nicht hält (Zero-Knowledge at Rest). Nur der optionale Browser-ZK-Modus verlagert die Erkennung vollständig ins Endgerät: die echten personenbezogenen Werte verlassen den Browser nie (Split-Zero-Knowledge), er schützt jedoch nur erkannte Entitäten. Die öffentliche B2B-REST-API speichert nichts Umkehrbares (No-Retention).
5.2 Schlüsselableitung und Verschlüsselung
- Schlüsselableitung aus dem Nutzerpasswort mittels PBKDF2-SHA256 mit 600.000 Iterationen (Browser, Web-Crypto-API-Limit) bzw. Argon2id (t=3, m=64 MB, p=4) (Server, OWASP-konform), beide mit kryptografisch zufälligem 32-Byte-Salt.
- Verschlüsselung mit AES-256-GCM (Authenticated Encryption, zufälliger IV, Authentifizierungsanhang).
- Der Schlüssel bleibt in der Hoheit des Clients (aus dem Passwort abgeleitet bzw. Per-Session-DEK) und wird serverseitig nicht dauerhaft gespeichert.
Dadurch liegen persistierte Zuordnungen und Nachrichten in der Datenbank ausschließlich als verschlüsselter Block vor — der Betreiber kann sie im Ruhezustand nicht entschlüsseln. Im Browser-ZK-Modus verlässt der Rück-Zuordnungsschlüssel zusätzlich zu keinem Zeitpunkt den Browser.
5.3 Bereitstellung: Browser-Standards ohne Pflicht-Plugin
Die in diesem Whitepaper beschriebene Zero-Knowledge-Kernarchitektur (Proxy- und Browser-Modus) benötigt kein Browser-Plugin und keine Zusatzsoftware: Sie kommt ausschließlich mit standardisierten Browser-Schnittstellen aus — Web Crypto API, File API, Canvas API. Die Pseudonymisierung ist damit ohne Installation, Signaturprüfung oder erhöhte Berechtigungen nutzbar.
Ergänzend bietet KI-Shield eine optionale, eigenständige Browser-Erweiterung („KI-Shield Platzhalter", Manifest V3) an, die dieselbe deterministische Erkennungs-Engine direkt in gängigen KI-Oberflächen (ChatGPT, Claude, Gemini) einsetzt — für Nutzer, die ihre gewohnte Chat-Umgebung beibehalten möchten. Diese Erweiterung ist ein separates Zusatzprodukt und nicht Teil der oben beschriebenen Zero-Knowledge-Kernarchitektur; ihr Schutzniveau richtet sich nach dem jeweiligen Einsatzszenario.
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 Arweave-Verankerung
Alle 6 Stunden 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 permanenter Arweave-Upload. Der Eintrag ist über tx_hash und arweave.net ö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/certificate — öffentliche Zertifikats-/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 druckbares HTML; Signaturnachweis mit SHA-256-Dokument-Hash und Ed25519+ML-DSA-Hybrid-Signatur
- 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 — Standardmäßig die letzten 500 Audit-Chain-Einträge (1–2000 konfigurierbar; Hashes + Metadaten + Signatur-Präsenz, kein Klartext)
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 Gegenstand folgender deutscher Gebrauchsmuster bzw. Gebrauchsmusteranmeldungen (Inhaber/Anmelder: René Bringezu, Greußen):
| Schutzrecht | Gegenstand | Status |
|---|---|---|
| DE 20 2026 001 147 U1 | Proxy-System mit hybrider PQ-Audit-Kette und Zero-Knowledge-Verschlüsselung | Eingetragenes Gebrauchsmuster · Anmeldetag 13.03.2026 |
| 20 2026 001 595.0 | Zero-Knowledge-Browser-System mit flüchtiger Zuordnungstabelle | Angemeldetes Gebrauchsmuster (Eintragungsverfahren läuft) · Anmeldetag 09.04.2026 |
Rechte & Zweck: © 2026 René Bringezu / KI-Shield UG. Alle Rechte vorbehalten. Dieses Dokument dient ausschließlich der Information und als Defensive Publication: Die hierin offengelegten, nicht durch die genannten Gebrauchsmuster geschützten Verfahren und Konzepte werden mit dem Veröffentlichungsdatum öffentlich zugänglich gemacht und damit dem Stand der Technik zugerechnet — eine spätere Monopolisierung durch Dritte ist ausgeschlossen. Eine Lizenz zur Nutzung, Vervielfältigung oder Nachbildung wird dadurch nicht gewährt.
Nachbauhinweis: Die Implementierung der durch die oben genannten Gebrauchsmuster geschützten bzw. zur Eintragung angemeldeten Verfahren erfordert eine Lizenz des Schutzrechtsinhabers René Bringezu. 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.
Zeitstempel-Nachweis (Defensive Publication): Die PDF-Fassung dieses Whitepapers ist als SHA-256-Hash-Manifest auf Arweave verankert; maßgeblich ist jeweils die Arweave-Blockzeit. Aktuelle PDF (Stand 18.08.2026): SHA-256 d3d63f2fcb4fb6886c8ee34fa18f3e0cd89033360ffd6662a19bdd197f254c66, Arweave-TX h-nYVYonRUlWPkCw6mn55KSuhMX0yrotH-OGOgQRHTs. Vorherige PDF (23.07.2026): SHA-256 91fd22db95292fac830370ed234c53dd9d12fd6231ba9a6bd809885661c9e3db, Arweave-TX aBjK0Q9fC9G2PDoNjIWQKjcvS3-qOvY2pg6zQgGNT-E.
Ende des Whitepapers Version 1.1
KI-Shield UG (haftungsbeschränkt) · HRB 524511 Amtsgericht Jena · Greußen, Thüringen
info@ki-shield.de · ki-shield.de · ki-shield.eu
Erstveröffentlicht am 17. April 2026 · Revision 1.1 vom 8. Juli 2026