Split-Knowledge-Architektur: Identität und KI-Verarbeitung konsequent trennen

Die zentrale Invariante

Keine einzelne Sandbox verfügt über ausreichend Informationen, um eine Person gleichzeitig zu identifizieren und Rückschlüsse auf ihr Verhalten, ihre Präferenzen oder ihre Eigenschaften zu ziehen. Jede Designentscheidung leitet sich aus dieser Einschränkung ab.

Sandbox A kennt das WER: Klarname, E-Mail-Adresse, Personalausweisnummer, Kontonummern, Rechnungsdaten, physische Adresse, biometrische Referenzen. Sandbox B kennt das WAS: Verhaltensmuster, KI-Modellergebnisse, Präferenzvektoren, Risikoscores, Empfehlungen, Klassifikationslabels, Interaktionsprotokolle. Es gibt keinen gemeinsamen Netzwerkpfad. Die ID Bridge — eine separate, isolierte Komponente — ist das einzige System, das beide Seiten über opake pseudonyme Token korrelieren kann.

Dies ist keine Zugriffskontrolle. Zugriffskontrolle ist eine Richtlinie, die falsch konfiguriert, umgangen oder durch Social Engineering ausgehebelt werden kann. Split-Knowledge ist eine Durchsetzung auf Infrastrukturebene: Kubernetes NetworkPolicies und Docker-Netzwerksegmentierung verhindern, dass Sandbox A und Sandbox B direkt miteinander kommunizieren. Das KI-Modell in Sandbox B kann die Identitätsdatenbank schlicht nicht abfragen, weil keine Route existiert.

Datenfluss: Acht Schritte von der Anfrage zur Antwort

Ein Benutzer stellt eine Anfrage — „Zeige mir meine Empfehlungen." Folgendes geschieht:

1. Die Anfrage erreicht das Gateway (dsa-edge), den einzigen extern erreichbaren Dienst.
2. Das Gateway entfernt Identitätsdaten und leitet eine Authentifizierungsanfrage an Sandbox A (dsa-identity) weiter.
3. Sandbox A authentifiziert den Benutzer und stellt über die ID Bridge (dsa-bridge) ein opakes Token aus (z. B. tok_a7f2x9k4). Das Token hat keine ableitbare Beziehung zur realen Identität — es wird über HMAC-SHA256(master_key, identity_id || purpose || rotation_epoch) generiert.
4. Das Gateway leitet die Anfrage an Sandbox B (dsa-ai) weiter — ausschließlich mit dem Token und einem Kontext-Payload. Der Payload enthält Verhaltensattribute. Niemals Identitätsdaten.
5. Sandbox B führt die KI-Inferenz auf Token und Kontext durch. Das Modell kann nicht feststellen, dass es sich um „Marc aus Fürth" handelt — es sieht tok_a7f2x9k4 und einen Satz von Verhaltensmerkmalen.
6. Sandbox B gibt das Ergebnis zurück, getaggt mit dem Token.
7. Das Gateway nutzt die ID Bridge, um das Token der Benutzersitzung zuzuordnen.
8. Der Benutzer sieht ein personalisiertes Ergebnis.

Das Gateway ist der einzige Dienst, der sowohl die Identität des Benutzers als auch das Inferenz-Token sieht — leitet aber niemals beides an denselben nachgelagerten Dienst weiter. Dies wird in der Middleware durchgesetzt: PII-Stripping läuft, bevor eine Inferenzanfrage das Gateway verlässt.

Token-Design: Fünf Eigenschaften, die zählen

Token sind das Bindegewebe der Architektur. Sie müssen fünf Eigenschaften gleichzeitig erfüllen:

• Opak: Ein Token trägt keinerlei Information über die zugrunde liegende Identität. Keine codierten Namen, keine sequenziellen IDs, keine Zeitstempel. Aus tok_a7f2x9k4 lässt sich nichts über die dahinterstehende Person ableiten.
• Nicht umkehrbar ohne die Bridge: Die Ableitung der realen Identität aus einem Token erfordert Zugriff auf die Mapping-Tabelle der Bridge, die im Ruhezustand mit HSM-geschützten Schlüsseln verschlüsselt ist und Quorum-Zugriff (2-von-3-Schlüsselverwahrern) für administrative Operationen erfordert.
• Rotierbar: Token werden nach einem Zeitplan (täglich, wöchentlich) oder auf Anforderung rotiert. Nach der Rotation werden alte Token ungültig. Dies begrenzt das Fenster für Korrelationsangriffe — ein Angreifer, der heute ein Token abfängt, kann es nicht nutzen, um Daten der nächsten Woche zu korrelieren.
• Zweckgebunden: Unterschiedliche Token für unterschiedliche Zwecke. Dieselbe Person erhält ein Token für Empfehlungen (tok_a7f2x9k4, Zweck: reco) und ein anderes für Betrugserkennung (tok_m2p8q1r7, Zweck: fraud). Zwischen ihnen besteht keine mathematische Beziehung. Dies verhindert zweckübergreifendes Profiling innerhalb von Sandbox B.
• Widerrufbar: Wenn ein Benutzer sein Recht auf Löschung ausübt (DSGVO Art. 17), werden alle Token dieser Identität in der Bridge widerrufen. Daten in Sandbox B werden verwaist — Verhaltenseinträge, die an Token geknüpft sind, die sich zu nichts mehr auflösen.

Datenklassifikationsmatrix

Quasi-Identifikatoren verdienen besondere Aufmerksamkeit. Geburtsdatum, Postleitzahl, Geschlecht und Beruf — einzeln harmlos — können in Kombination statistische Re-Identifikation ermöglichen. Sandbox B erzwingt k-Anonymität bei der Datenaufnahme: Wenn eine Kombination von Quasi-Identifikatoren weniger als fünf Personen beschreibt (k<5), werden Attribute verallgemeinert (Alter wird zur Altersgruppe, Postleitzahl zur Region) oder vollständig unterdrückt.

Breach-Szenarioanalyse: Was ein Angreifer erhält

Breach von Sandbox A: Der Angreifer erhält Identitätsdaten — Namen, E-Mail-Adressen, Kontonummern. Schädlich, aber er bekommt keinerlei Verhaltensdaten, keine KI-gestützten Erkenntnisse, keine Risikoscores. Er weiß, WER Ihre Kunden sind, aber nichts darüber, WAS sie tun oder wie die KI sie charakterisiert. Standardverfahren für Identitäts-Breaches greifen.

Breach von Sandbox B: Der Angreifer erhält Verhaltensmuster, Modellergebnisse, Risikoscores — alles getaggt mit opaken Token. Er weiß, WAS passiert ist, aber nicht, WEM es passiert ist. Ein Transaktionsrisikoscore von 0,87 für tok_a7f2x9k4 ist ohne das Bridge-Mapping wertlos. Gemäß DSGVO Art. 33–34 ändert sich die Risikobewertung des Breach wesentlich: Pseudonymisierte Daten mit angemessenen Schutzmaßnahmen erfordern unter Umständen keine individuelle Benachrichtigung (Erwägungsgrund 26).

Breach der ID Bridge: Der schlimmste Fall. Der Angreifer erhält die Mapping-Tabelle und kann Sandbox-A-Identitäten mit Sandbox-B-Token korrelieren. Sofortmaßnahme: alle Token rotieren und damit alte Korrelationen ungültig machen. Die HSM-geschützte Verschlüsselung der Bridge, das Mehr-Parteien-Schlüsselmanagement und die Netzwerkisolation (kein Internet-Zugang, keine direkten Verbindungen von A oder B) machen dies zur am schwersten erreichbaren Komponente.

Vergleich mit monolithischer Architektur: Ein einzelner Breach liefert alles — Namen, E-Mail-Adressen, Transaktionshistorien, KI-Risikoscores, Verhaltensprofile, Empfehlungen — vollständig verknüpft, vollständig identifizierbar. Jeder Breach ist der schlimmste Fall.

Ein wachsender Markt für Datenschutz auf Infrastrukturebene

Die Nachfrage nach diesem Ansatz ist nicht theoretisch. Gartner prognostiziert den Markt für KI-Governance-Plattformen auf 492 Mio. USD in 2026 und über 1 Mrd. USD bis 2030. In einer Umfrage unter 360 Organisationen im Jahr 2025 nannten 52 % die Offenlegung sensibler Daten als ihr größtes KI-Risiko. Der Markt für Confidential Computing — hardwaregestützter Datenschutz während der Verarbeitung — wird auf 59,4 Mrd. USD bis 2028 prognostiziert.

Der Ansatz auf Infrastrukturebene zieht ernsthafte Investitionen an. Unternehmen, die hardware- und netzwerkbasierte Datenisolation aufbauen, schließen signifikante Finanzierungsrunden ab — darunter eine 90-Mio.-USD-Serie-C für einen führenden Anbieter im Bereich Confidential Computing mit über 150 Unternehmenskunden in den Bereichen Banken, Behörden und Gesundheitswesen. Der Marktkonsens aus Cloud-Security-Teams und akademischer Literatur: Schwärzung und Infrastrukturisolation sind komplementäre Schichten. Nur eine davon einzusetzen, hinterlässt Lücken.

Split-Knowledge-Architektur kombiniert beides: PII-Stripping auf Anwendungsebene im Gateway, Netzwerkisolation auf Infrastrukturebene zwischen den Sandboxes und kryptografische Tokenisierung über die Bridge. Dieser mehrschichtige Ansatz ist das, was die Branchenforschung empfiehlt — und was Regulierungsbehörden zunehmend fordern, wenn die Durchsetzung von Art. 10 der KI-Verordnung am 2. August 2026 beginnt.

Monolithisch vs. Split-Knowledge: Der strukturelle Unterschied

In einem traditionellen monolithischen KI-System teilen sich Benutzerdatenbank, Feature Store, Model-Serving-Layer und Anwendungslogik ein Netzwerk. Ein Anwendungsserver, der eine Empfehlung rendert, kann in derselben Anfrage sowohl die Benutzertabelle (Identität) als auch die Modellausgabetabelle (KI-Erkenntnisse) abfragen. Das ist praktisch für Entwickler. Es ist auch der Grund, warum jeder Datenverlust in einem monolithischen System vollständig verknüpfte Profile offenlegt.

Split-Knowledge eliminiert dies konstruktionsbedingt. Das Empfehlungsmodell in Sandbox B gibt ein Ergebnis für tok_a7f2x9k4 zurück. Das Gateway ordnet dieses Token einer Sitzung zu. Der Benutzer sieht seine Empfehlung. Zu keinem Zeitpunkt hielt ein einzelner Dienst gleichzeitig den Namen des Benutzers und die Modellausgabe im Speicher — außer dem Gateway, das PII-Stripping vor der Weiterleitung durchsetzt.

Dies ist relevant für DSGVO Art. 25 (Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen). Ein monolithisches System kann DPDD durch Richtlinien beanspruchen. Die Split-Knowledge-Architektur *ist* die DPDD-Implementierung. Die Architektur ist der Nachweis.

Re-Linkage: Die kontrollierte Ausnahme

Manchmal müssen Identität und KI-Ergebnis zusammengeführt werden — ein Betrugsermittler muss wissen, wer tok_a7f2x9k4 ist. Das Re-Linkage-Protokoll regelt dies:

1. Eine autorisierte Person fordert explizit die Re-Linkage an und nennt eine Rechtsgrundlage (Betrugsermittlung, Fall FR-2026-0412).
2. Die Policy-Engine der Bridge verifiziert: Der Analyst hat die Rolle fraud_investigator, der Fall existiert im Fallmanagementsystem, das Token ist mit einem Risikoscore oberhalb des Schwellenwerts markiert, und die Freigabe des Datenschutzbeauftragten liegt vor.
3. Die Bridge gibt Identitätsinformationen mit einer 30-Minuten-Gültigkeitsdauer zurück.
4. Ein unveränderlicher Audit-Log-Eintrag dokumentiert, wer angefragt hat, warum, welche Token betroffen sind, die Freigabekette, den Zeitstempel und die Dauer.

Re-Linkage ist keine Hintertür. Es ist ein auditierter, zeitlich begrenzter, zweckgebundener und durch mehrere Parteien genehmigter Prozess. Er existiert, weil legitime Anwendungsfälle (regulatorische Meldepflichten, DSGVO-Auskunftsersuchen, Betrugsermittlungen) ihn erfordern. Die Architektur macht Re-Linkage zur bewussten Ausnahme, nicht zum Standardzustand.