Architektur im Detail

So funktioniert The Veil

The Veil teilt jeden KI-Workflow in zwei netzwerkisolierte Sandboxes auf. Sandbox A speichert Identitätsdaten. Sandbox B führt KI-Inferenz aus. Sie können nicht direkt kommunizieren — eine opake Token-Bridge ist die einzige Verbindung. Das KI-Modell erfährt nie, wem die Daten gehören.

Zuletzt aktualisiert: April 2026

Die zentrale Invariante

Keine einzelne Komponente kennt gleichzeitig Identität undKI-Erkenntnisse. Das ist keine Richtlinie — es ist eine Infrastrukturbeschränkung.

ASandbox A kennt das WER — Namen, E-Mails, Kontonummern, Authentifizierungsdaten. Sie hat keinerlei Einblick in KI-Modell-Outputs oder Verhaltens-Inferenzen.
BSandbox B kennt das WAS— Risiko-Scores, Sentiment-Analyse, klinische Vorhersagen. Sie empfängt ausschließlich opake pseudonyme Token. Sie kann diese Token nicht zu Identitäten auflösen.

Kubernetes NetworkPolicies und Docker-Netzwerksegmentierung erzwingen diese Grenze. Ein kompromittierter Anwendungsprozess in Sandbox B kann keine TCP-Verbindung zu Sandbox A öffnen. Die Netzwerkschicht verwirft die Pakete.

Warum nicht einfach schwärzen?

Schwärzung ist ein Software-Versprechen. Ein einzelner Regex-Fehler, eine übersehene Zeichenkodierung oder ein vergessener Log-Eintrag leakt PII in die KI-Pipeline. Das System ist nur so stark wie jede einzelne Zeile Schwärzungs-Code über alle Releases hinweg.

The Veil ersetzt dieses Software-Versprechen durch eine Infrastruktur-Garantie:

Ansatz	Fehlermodus	Schadensradius
Schwärzung	Bug in Regex / Serializer	Vollständige PII für das KI-Modell sichtbar
The Veil	Fehler auf Anwendungsebene	Netzwerk blockiert die Verbindung — KI kann den Identitätsspeicher weiterhin nicht erreichen

Dieser Unterschied ist besonders relevant, wenn die KI ein externer Cloud-Anbieter ist, wenn mehrere Parteien Zugriff benötigen (Prüfer, Berater) oder wenn Regulierung architektonische Durchsetzung verlangt — wie DSGVO Artikel 25 und KI-Verordnung Artikel 10.

Der Datenfluss

Jede Anfrage folgt demselben Acht-Schritte-Pfad. Identität und Inferenz teilen sich nie einen Netzwerk-Hop.

1Benutzer sendet eine Anfrage an das Gateway (der einzige öffentliche Endpunkt).
2Die PII-Firewall des Gateways entfernt Identitätsfelder aus dem Payload, bevor dieser weitergeleitet wird.
3Sandbox A authentifiziert den Benutzer via OIDC, validiert die Autorisierung und stellt über die ID Bridge einen opaken pseudonymen Token aus.
4Das Gateway leitet die Anfrage an Sandbox B weiter — ausschließlich mit dem opaken Token und dem Kontext-Payload. Keine Namen, keine E-Mails, keine Kontonummern.
5Sandbox B führt die Inferenz aus (LLM, Scoring-Modell, Klassifikator). Sie verarbeitet den Kontext gegen den Token. Sie kann niemanden identifizieren.
6Sandbox B gibt ihr Ergebnis zurück, getaggt mit dem pseudonymen Token.
7Das Gateway ordnet den Token über die ID Bridge der authentifizierten Benutzersitzung zu. Dies ist der einzige Punkt, an dem Token und Identität koexistieren — im Arbeitsspeicher, nie gemeinsam persistiert.
8Der Benutzer sieht das Endergebnis. Das KI-Modell hat nie erfahren, wer er ist.

Komponenten

Gateway`dsa-edge`

REST-Edge-Service und PII-Firewall. Die einzige Komponente, die sowohl die Benutzersitzung als auch den Inferenzpfad berührt — aber sie leitet nie gleichzeitig Identität und Token an denselben Downstream-Service weiter. In-Memory Session-Cache, Wait-Polling für asynchrone Ergebnisse, Graceful Shutdown.

Sandbox A — Identity Vault`dsa-identity`

Speichert und schützt Identitätsdaten. PostgreSQL mit Row-Level Security, Column-Level Encryption, OIDC-Provider für Authentifizierung und DSAR-/Löschendpunkte für DSGVO-Compliance. Hat keine Netzwerkroute zu Sandbox B.

ID Bridge`dsa-bridge`

Erzeugt opake pseudonyme Token (HMAC-SHA256 mit zufälligem Nonce) ohne ableitbare Beziehung zu realen Identitäten. Verwaltet epochenbasierte Token-Rotation (konfigurierbar, Standard 7 Tage) mit 14-tägiger Übergangsphase für unterbrechungsfreien Betrieb. Master Keys integrieren sich mit HashiCorp Vault, AWS KMS oder Azure Key Vault.

Re-Linkage — die Rückverknüpfung eines Tokens mit einer realen Identität — ist die sensibelste Operation der Plattform. Jede Re-Linkage-Anfrage muss eine siebenstufige Governance-Kette durchlaufen:

1Rechtsgrundlage — der Antragsteller muss die Rechtsgrundlage angeben (z. B. DSGVO Art. 6(1)(c), klinischer Notfall).
2Fallreferenz — eine nachvollziehbare Fall-ID, die den Antrag mit einem konkreten Geschäftsbedarf verknüpft.
3Rollenvalidierung — nur festgelegte Rollen können Re-Linkage initiieren.
4Jurisdiktionsprüfung — Re-Linkage kann nach Rechtsordnung eingeschränkt werden, um Datensouveränität durchzusetzen.
5Vier-Augen-Freigabe — eine zweite unabhängig autorisierte Person muss genehmigen.
6Zeitlich begrenzter Zugriff — Re-Linkage gewährt Zugriff auf bestimmte Attribute für ein konfigurierbares Zeitfenster, keinen permanenten Zugriff.
7Verpflichtende Nachprüfung — innerhalb eines konfigurierbaren Zeitraums (Standard 7 Tage) muss das Zugriffsereignis geprüft und abgezeichnet werden.

Ein Break-Glass-Mechanismus existiert für klinische oder betriebliche Notfälle. Break-Glass umgeht das Vier-Augen-Prinzip, löst aber aus: erhöhtes Audit-Logging, automatische Benachrichtigung des Datenschutzbeauftragten und verpflichtende Nachprüfung innerhalb von 24 Stunden.

Sandbox B — KI-Verarbeitung`dsa-ai`

Asynchrone Inferenz-Engine mit austauschbaren LLM-Adaptern — Anthropic Claude, OpenAI, Mistral oder lokale Modelle via Ollama. Redis Job Queue für asynchrone Workloads. Empfängt ausschließlich opake Token und Kontext. Hat keine Netzwerkroute zu Sandbox A oder zur Identitätsdatenbank.

Audit Service`dsa-audit`

Entscheidungsdatensätze werden an eine kryptographische Hash-Chain angehängt. Die Anwendungsrolle hat nur INSERT- und SELECT-Rechte. Löschungen sind ausschließlich für DSGVO-Art.-17-Löschanträge und Retention-Ablauf zulässig und werden über auditierte SECURITY-DEFINER-Funktionen ausgeführt, die neben jeder Löschung einen signierten Löschnachweis in ein separates Append-only-Log schreiben. Auditoren können die vollständige Nachweiskette — einschließlich der Löschnachweise — unabhängig verifizieren.

Compliance-Mapping

The Veil wurde gezielt für spezifische regulatorische Anforderungen entwickelt — nicht nachträglich angepasst.

Regulierung	Anforderung	The Veil Mechanismus
DSGVO Art. 25	Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen	Pseudonymisierung ist der Standard-Verarbeitungsmodus. Identitätsisolierung wird auf Netzwerkebene erzwungen. Datenminimierung ist strukturell — Sandbox B kann nicht auf mehr Daten zugreifen als nötig.
DSGVO Art. 32	Sicherheit der Verarbeitung	Column-Level Encryption in Sandbox A. Netzwerkisolierung via Kubernetes NetworkPolicies (16 Policies über 7 Namespaces). Append-only Audit-Hash-Chain. Token-Rotation mit konfigurierbaren Richtlinien.
KI-Verordnung Art. 10	Daten-Governance für Hochrisiko-KI-Systeme	Trainings- und Inferenzdaten durchlaufen die Gateway-PII-Firewall. Sandbox B empfängt ausschließlich pseudonymisierten Kontext. Vollständige Daten-Lineage über die Audit-Hash-Chain. KI-Anbieter-agnostisch — Modelle wechseln ohne Änderung der Datenschutzposition.
KI-Verordnung Art. 15	Genauigkeit, Robustheit und Cybersicherheit	Isolierung auf Infrastrukturebene begrenzt die Angriffsfläche für adversariale Eingaben. Austauschbare LLM-Adapter ermöglichen Modellvalidierung ohne Architekturänderungen. Append-only Logs unterstützen Post-Deployment-Monitoring und Anomalieerkennung.

Breach-Szenario: Was ein Angreifer erhält

Angenommen, eine einzelne Sandbox wird vollständig kompromittiert. Was kann der Angreifer erbeuten?

Kompromittierte Komponente	Angreifer erhält	Angreifer kann nicht erhalten
Sandbox A	Namen, E-Mails, Kontonummern, Authentifizierungsdaten	KI-Outputs, Risiko-Scores, Verhaltens-Inferenzen, Modellparameter — nichts davon existiert in Sandbox A
Sandbox B	KI-Outputs, pseudonyme Token, Modellantworten	Reale Identitäten — Token sind opak und ohne die ID Bridge nicht umkehrbar
ID Bridge	Token-zu-Identität-Mappings	KI-Outputs oder Inferenzergebnisse — die Bridge empfängt diese nie. Ein Angreifer benötigt zusätzlich Sandbox B-Daten, um ein verknüpftes Profil zu erstellen.

Keine einzelne kompromittierte Komponente ergibt ein verknüpftes Profil von „Person X hat Risiko-Score Y.“ Ein Angreifer muss mehrere isolierte Systeme über separate Netzwerkgrenzen hinweg kompromittieren, jeweils mit unabhängigen Zugangsdaten, um diese Verknüpfung herzustellen.