KI-Systeme in der EU: DSGVO-konformes Design von Anfang an

Die Compliance-Wand, vor der dich niemand warnt

Mal ehrlich: Die meisten KI-Architekturen sind in der EU technisch gesehen illegal, sobald sie Kundendaten anfassen.

Nicht weil die Teams es nicht besser wissen wollen. Das Problem ist simpler und brutaler: Die Standard-Architektur jedes KI-Tutorials, jedes RAG-Quickstarts, jedes Agent-Frameworks schickt rohe Kundendaten direkt an einen externen Model-Provider. Namen, E-Mails, Kundennummern, Bestellreferenzen, Zahlungsdaten. Alles landet auf Infrastruktur, die du nicht kontrollierst. In der EU ist das unter DSGVO Artikel 44-49 ein Datenschutzverstoß, noch bevor du überhaupt zu den spannenden Teilen kommst.

Wir sind selbst gegen diese Wand gelaufen. Wir haben ein KI-gestütztes Kundenkommunikationssystem für einen Enterprise-Kunden in Deutschland gebaut. Die Demo war brillant: personalisiert, kontextbewusst, korrektes formelles Deutsch mit richtiger geschlechtsspezifischer Anrede. Dann hat die Rechtsabteilung das Architekturdiagramm geprüft und eine einzige Frage gestellt:

"Wo genau verlässt der Name des Kunden unsere Infrastruktur?"

Drei Wochen Stillstand. Die Antwort der Entwickler ("OpenAIs API, aber die trainieren nicht mit unseren Daten") hat niemanden überzeugt. Nicht den DSB, nicht die Rechtsabteilung, nicht das Einkaufsteam des Kunden.

Die Branche gibt dir eine falsche Wahl: Entweder nutzt du KI unsicher mit Rohdaten, oder du entfernst so viele Daten, dass die KI nutzlos wird. Wir haben Monate damit verbracht, einen dritten Weg zu bauen. Daraus wurde das Fundament für OGuardAI, unsere Open-Source Semantic Data Protection Runtime. Dieser Artikel enthält alles, was wir dabei gelernt haben.

Warum das über den rechtlichen Aspekt hinausgeht

Bevor wir in die Architektur einsteigen: Das ist nicht nur ein Compliance-Problem. Es ist gleichzeitig ein Business-Blocker, ein Sicherheitsrisiko und eine Engineering-Herausforderung. Wie wir bei Oronts an Enterprise-Projekte herangehen, siehst du auf unserer Methodik-Seite und in unserer Leistungsübersicht.

Wenn auch nur eine dieser Personen nein sagt, ist dein KI-Projekt tot. Deshalb muss diese Architektur alle gleichzeitig überzeugen.

Das Vertrauensgrenzen-Modell

Das wichtigste Konzept in einer DSGVO-konformen KI-Architektur ist die Vertrauensgrenze (Trust Boundary). Das ist keine Library. Das ist kein Config-Flag. Es ist eine Architekturentscheidung darüber, welche Daten Systeme erreichen, die du nicht vollständig kontrollierst. Wenn du neu in unserem Ansatz zur Systemarchitektur bei Oronts bist, bietet dieser Leitfaden nützlichen Kontext.

┌──────────────────────────────────────────────────────────────────┐
│                      TRUSTED ZONE                                │
│                  (Your Infrastructure)                            │
│                                                                  │
│  ┌────────────┐    ┌────────────┐    ┌──────────────────────┐   │
│  │  Raw PII   │───▶│  Detect    │───▶│  Session Mapping     │   │
│  │  Input     │    │  Engine    │    │  (AES-256-GCM        │   │
│  │            │    │            │    │   encrypted)         │   │
│  └────────────┘    └─────┬──────┘    └──────────────────────┘   │
│                          │                                       │
│                          ▼                                       │
│                ┌──────────────────┐                               │
│                │  Tokenized Text  │                               │
│                │  + entity_context│                               │
│                └────────┬─────────┘                               │
│ ════════════════════════╪════════════════════════════════════════ │
│            TRUST        │       BOUNDARY                         │
│ ════════════════════════╪════════════════════════════════════════ │
│                         ▼                                        │
│     ┌───────────────────────────────────────────┐               │
│     │            UNTRUSTED ZONE                  │               │
│     │     (LLM Provider / External API)          │               │
│     │                                            │               │
│     │  Sees: {{person:p_001}}, {{email:e_001}}   │               │
│     │  + metadata: gender=female, formality=     │               │
│     │    formal, language=de                     │               │
│     │  Never sees: "Sara Mustermann",                 │               │
│     │    "sara.mustermann@beispiel.de"              │               │
│     └──────────────────────┬─────────────────────┘               │
│                            │                                     │
│                            ▼                                     │
│     ┌──────────────┐  ┌──────────────┐  ┌──────────────────┐   │
│     │ Token Repair  │─▶│ Output Guard │─▶│  Rehydrate       │   │
│     │ (3-stage)     │  │ (catch new   │  │  (policy-driven  │   │
│     │               │  │  PII)        │  │   restore)       │   │
│     └──────────────┘  └──────────────┘  └──────────────────┘   │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

Die Regel ist absolut: Rohe PII bleibt in der Trusted Zone. Nur semantische Tokens überqueren die Untrusted Zone. Das LLM sieht nie einen echten Namen, eine echte E-Mail, eine echte Telefonnummer, eine echte IBAN. Es sieht {{person:p_001}}, {{email:e_001}}, {{phone:ph_001}}.

Das ist es, was Enterprise-Deals abschließt. Nicht Features. Nachweisbare Vertrauensgrenzen.

Warum naives Masking die KI-Ausgabe zerstört

Das Erste, was jedes Team versucht, ist String-Replacement: "Sara Mustermann" durch [NAME] ersetzen, ans Model schicken, [NAME] zurücksetzen.

Das scheitert in der Produktion katastrophal:

Allein das Problem mit der deutschen formellen Anrede hat unseren ersten Ansatz zerstört. In deutscher Geschäftskommunikation brauchst du:

• Geschlecht: "Herr" oder "Frau". Falsches Geschlecht ist ein schwerer professioneller Fehler
• Korrekten grammatischen Kasus: "Sehr geehrter Herr" vs "Sehr geehrte Frau" (unterschiedliche Endung je nach Geschlecht)
• Titel-Bewusstsein: "Dr." oder "Prof." als Präfix, wenn zutreffend
• Konsistenz: Dieselbe Person muss über ein 3-seitiges Dokument hinweg gleich angesprochen werden

Wenn dein Model nur [NAME] sieht, kann es buchstäblich keinen korrekten deutschen formellen Brief erzeugen. Die Ausgabe ist entweder grammatisch falsch, kulturell unangemessen oder so generisch, dass sie wie eine Vorlage klingt. Und generische E-Mails konvertieren nicht. Das ist genau die Art von KI-Fehlermodus, die Enterprise-Adoption scheitern lässt.

Semantische Tokenisierung: Die Architektur, die funktioniert

Semantische Tokenisierung unterscheidet sich grundlegend von Masking. Statt Informationen zu entfernen, ersetzt sie Rohwerte durch Tokens, die genug Metadaten tragen, damit das LLM korrekte Ausgaben erzeugt, ohne je die tatsächlichen Daten zu sehen.

Token-Format und Metadaten

{{type:id}}

• type: einer von 12+ registrierten Entity-Typen (person, email, phone, company, customer_id, order, address, iban, ssn, ip, passport, health_id)
• id: Session-bezogener deterministischer Identifier (Präfix + Zähler: p_001, e_001, ph_001)

Jeder Token trägt strukturierte Metadaten. Das ist es, was ihn semantisch macht, nicht nur einen Platzhalter:

Diese Metadaten werden als entity_context ans LLM gesendet. Sichere, typisierte Informationen ohne jegliche Rohwerte:

{
  "entity_context": [
    {
      "token": "{{person:p_001}}",
      "type": "person",
      "gender": "female",
      "formality": "formal",
      "language": "de",
      "role": "recipient"
    },
    {
      "token": "{{email:e_001}}",
      "type": "email",
      "belongs_to": "p_001"
    },
    {
      "token": "{{customer_id:cid_001}}",
      "type": "customer_id"
    }
  ]
}

Das Model weiß, dass es an eine formelle, deutschsprachige, weibliche Empfängerin schreibt. Es kennt ihren Namen nicht.

Die Detection-Pipeline

Detection ist kein simples Regex. Es ist ein mehrschichtiges System, das Geschwindigkeit mit Genauigkeit kombiniert:

In der Produktion läuft zuerst Regex (schnell, hohe Präzision für strukturierte Daten), dann NER für unstrukturierte Entities. Der schichtweise Ansatz bedeutet, dass strukturierte PII wie E-Mails und IBANs bei nahezu null Latenz erkannt werden, während Namen und Adressen die volle NER-Behandlung bekommen. Für die Überwachung der Performance über die Zeit, siehe unseren Leitfaden zur KI-Observability.

// Detection-Konfigurationsbeispiel
const config = {
  detectors: ["builtin_regex", "ner_spacy"],
  entity_types: ["person", "email", "phone", "customer_id", "iban"],
  threshold: 0.7,  // Minimale Konfidenz für Tokenisierung
  language: "de"   // Hinweis für das NER-Modell
};

Vollständiges Produktionsszenario: Deutscher Kundensupport

Lass uns einen kompletten Produktionszyklus durchgehen. Kein vereinfachtes Beispiel, sondern was in einem echten Kundenkommunikationssystem tatsächlich passiert.

Input (Kundensupport-Ticket):

Hallo, ich bin Sara Mustermann. Meine Kundennummer ist 948221.
Ich warte seit 5 Tagen auf meine Rückzahlung.
Meine E-Mail ist sara.mustermann@beispiel.de, bitte schickt mir eine Bestätigung.

Schritt 1: Detection

Schritt 2: Tokenisierter sicherer Text (wird ans LLM gesendet)

Hallo, ich bin {{person:p_001}}. Meine Kundennummer ist {{customer_id:cid_001}}.
Ich warte seit 5 Tagen auf meine Rückzahlung.
Meine E-Mail ist {{email:e_001}}, bitte schickt mir eine Bestätigung.

Schritt 3: LLM generiert Antwort (Model-Output)

Sehr geehrte {{person:p_001}},

vielen Dank für Ihre Nachricht. Es tut uns leid, dass Sie bereits seit
5 Tagen auf Ihre Rückzahlung warten.

Wir haben Ihren Fall unter der Kundennummer {{customer_id:cid_001}}
überprüft und die Rückzahlung wurde heute angewiesen. Sie erhalten
eine Bestätigung an {{email:e_001}} innerhalb der nächsten 24 Stunden.

Mit freundlichen Grüßen,
Ihr Support-Team

Schritt 4: Rehydrierung (Output-Channel: customer_email, Restore: formatted)

Sehr geehrte Frau Sara Mustermann,

vielen Dank für Ihre Nachricht. Es tut uns leid, dass Sie bereits seit
5 Tagen auf Ihre Rückzahlung warten.

Wir haben Ihren Fall unter der Kundennummer 948221 überprüft und die
Rückzahlung wurde heute angewiesen. Sie erhalten eine Bestätigung
an sara.mustermann@beispiel.de innerhalb der nächsten 24 Stunden.

Mit freundlichen Grüßen,
Ihr Support-Team

Was passiert ist:

• Das LLM hat korrektes formelles Deutsch geschrieben: "Sehr geehrte" (nicht "Sehr geehrter"), weil es wusste, dass die Empfängerin weiblich ist
• "Frau" wurde automatisch beim formatted-Restore vorangestellt. Das Model hat diese Entscheidung nie getroffen
• Kundennummer wiederhergestellt, weil die Policy es für kundengerichtete E-Mails erlaubt
• E-Mail wiederhergestellt, weil die Kundin ausdrücklich eine Bestätigung dorthin angefordert hat
• Das Model hat nie "Sara Mustermann", "948221" oder "sara.mustermann@beispiel.de" gesehen

Drei Schutzstufen für unterschiedliche Daten

Nicht alle Daten sind gleich sensibel. Ein dreistufiges Modell bildet diese Realität ab. Dieser Policy-gesteuerte Ansatz ist zentral für die Art, wie wir KI-Systeme und KI-Workflow-Pipelines bei Oronts entwerfen.

Stufe 1: Hard Masking (nie umkehrbar)

Gilt für: iban, ssn, passport, health_id

Diese unterliegen regulatorischen Verpflichtungen (DSGVO Art. 9 besondere Kategorien, PCI-DSS, HIPAA). Ihre Rohwerte werden nie in umkehrbarer Form gespeichert.

Stufe 2: Umkehrbare Tokenisierung (Policy-gesteuert)

Gilt für: person, email, phone, company, customer_id, order, address, ip, url

Diese werden mit semantischen Metadaten tokenisiert und basierend auf der Output-Channel-Policy wiederhergestellt. Dieselbe Tokenisierung erzeugt unterschiedliche Ausgaben für verschiedene Zielgruppen:

Dieselben tokenisierten Daten, verschiedene Policies pro Channel:

Das ist die zentrale Erkenntnis: Einmal tokenisieren, pro Channel unterschiedlich wiederherstellen. Der Kunde bekommt "Frau Sara Mustermann" in seiner E-Mail. Das interne Team sieht "Sara Mustermann" mit allen Details. Der Analytics-Export sieht "(weibliche Kundin)". Das Audit-Log enthält keinerlei PII.

Stufe 3: Semantische Abstraktion (nur Metadaten)

Gilt für: Geschlecht, Förmlichkeit, VIP-Status, Abteilung

Kein Rohwert wird gespeichert. Nur semantische Metadaten fließen durch das System. Das LLM weiß, dass die Empfängerin weiblich und formell ist. Genug für korrekte Grammatik, ohne dass irgendwelche Rohdaten involviert sind.

Agentische Workflows: Wo es exponentiell schwieriger wird

Einzelne LLM-Aufrufe sind der einfache Fall. Agentische KI-Systeme, bei denen ein KI-Agent mehrere Schritte mit Tools ausführt, vervielfachen die Leak-Oberfläche exponentiell. Wir behandeln die Agent-Architektur ausführlich in unserem Multi-Agent-Architektur-Leitfaden, aber hier konzentrieren wir uns speziell auf die Datenschutz-Herausforderung.

Betrachte einen Support-Agent-Workflow:

Step 1: Read ticket           → PII in ticket text
Step 2: Look up customer      → PII in CRM response
Step 3: Check billing         → PII in billing data
Step 4: Draft response        → PII in prompt + output
Step 5: Trigger refund        → PII in API call

Fünf Schritte = fünf potenzielle Leak-Punkte. Ohne Schutz sickern Daten in den Model-Kontext, Tool-Call-Argumente, Zwischenschritt-Reasoning-Chains, Agent-Memory und Logs. Jeder Schritt potenziert das Risiko.

Die Lösung: Jedes Trust-Boundary-Crossing wrappen, nicht nur den letzten LLM-Aufruf.

Step 1: Read ticket
  → Raw ticket with PII
  → TRANSFORM → Agent sees tokenized ticket

Step 2: Look up customer (tool call)
  Agent requests: get_customer({{customer_id:cid_001}})
  → Runtime intercepts → real ID used for lookup (inside trust boundary)
  → Tool response TRANSFORMED before returning to agent

Step 3: Check billing (tool call)
  Agent requests: check_billing({{customer_id:cid_001}})
  → Same pattern: real ID used internally, response tokenized

Step 4: Draft response
  Agent has: tokenized ticket + tokenized customer info + tokenized billing
  → Generates response with tokens
  → REHYDRATE for customer_email channel

Step 5: Trigger refund (tool call)
  Agent requests: issue_refund({{customer_id:cid_001}}, {{order:o_001}})
  → Runtime passes real values to refund API (inside trust boundary)
  → Confirmation tokenized before returning to agent

Der Agent sieht nie rohe PII in irgendeinem Schritt. Tool-Payloads werden pro Schritt gesteuert. Jedes Überqueren der Vertrauensgrenze ist geschützt. Der Audit-Trail zeigt exakt, welche Entities bei jedem Schritt erkannt, tokenisiert und wiederhergestellt wurden, ohne selbst PII zu enthalten. Für die Freigabe-Gates, die Agent-Entscheidungen sicher machen, siehe unseren Leitfaden zu Human-in-the-Loop-KI-Systemen.

RAG-Pipeline-Schutz

Retrieval-Augmented Generation bringt einen zweiten Leak-Vektor mit: deinen Vector Store. Wenn du Dokumente mit roher PII einbettest, wird deine gesamte Retrieval-Pipeline zu einem DSGVO-regulierten System. Für einen tieferen Blick auf RAG-Architektur selbst, siehe unseren Enterprise-RAG-Systeme-Leitfaden und unseren Vector-Search-Architektur-Leitfaden.

Zwei Ansätze:

A. Tokenisierung bei der Ingestion

Dokumente werden vor dem Chunking und Embedding tokenisiert:

• Chunks enthalten {{person:p_001}} statt echter Namen
• Embeddings werden auf tokenisiertem Text aufgebaut
• Der Vector Store enthält nie rohe PII
• Trade-off: leicht geringere Retrieval-Qualität bei namenbasierten Abfragen

B. Tokenisierung zur Abfragezeit (empfohlen)

Dokumente werden roh in einer kontrollierten Umgebung gespeichert. Zur Abfragezeit:

User: "What is the status of Sara Mustermann's refund?"

→ TRANSFORM query: "What is the status of {{person:p_001}}'s refund?"
→ RETRIEVE: chunks about refund policies (may contain PII)
→ TRANSFORM retrieved chunks: replace PII with tokens
→ LLM: generates answer using only tokens
→ REHYDRATE: restore per output channel policy
→ User sees: personalized answer with real names where allowed

Der Abfragezeit-Ansatz bewahrt die Retrieval-Qualität (Embeddings matchen auf echten Begriffen), während die LLM-Grenze geschützt bleibt. Der Vector Store befindet sich innerhalb der Trusted Zone; nur das LLM ist außerhalb.

Session-Architektur: Zustandslose Sicherheit

Ein Produktionssystem kann sich keinen serverseitigen Session-State für jeden Request leisten. Wir haben Sealed Sessions entworfen: AES-256-GCM-verschlüsselte Blobs, die mit dem Request mitreisen.

Transform request → runtime creates token map
                  → serializes + encrypts with AES-256-GCM
                  → returns encrypted blob as session_state
                  → client stores blob (opaque, tamper-proof)

Rehydrate request → client sends session_state blob back
                  → runtime verifies GCM authentication tag
                  → decrypts → resolves tokens → restores values
                  → no server-side state required

Warum das architektonisch wichtig ist:

Der Sealed-Session-Envelope enthält Session-ID, Tenant-ID, Policy-Version, Ablauf-Zeitstempel und die verschlüsselte Token-Map. Alles verifiziert durch den GCM-Authentication-Tag. Wenn sich ein einziges Bit ändert, wird der gesamte Blob abgelehnt. Fail closed, immer.

Token-Reparatur: Umgang mit LLM-Ungenauigkeiten

LLMs sind keine perfekten Textprozessoren. Wenn du {{person:p_001}} sendest, könnte das Model zurückgeben:

Ein Produktionssystem braucht eine dreistufige Reparatur-Pipeline:

1. Striktes Parsing: kanonisches {{type:id}}-Regex. Behandelt ~97% der Fälle.
2. Deterministische Reparatur: bekannte Mutationsmuster (fehlende Klammern, Case-Normalisierung, Whitespace-Collapse). Fängt ~2.5% ab.
3. Fuzzy-Auflösung: Levenshtein-Distanz gegen bekannte Tokens in der Session. Letzter Ausweg für die verbleibenden ~0.5%.

Ohne Token-Reparatur enthalten deine kundengerichteten E-Mails {{person:p_001}} statt eines Namens. Wir haben das bei einer Rate von ~2-5% über verschiedene Model-Provider beobachtet. Einige Modelle (GPT-4o, Claude) bewahren Tokens gut; kleinere oder lokale Modelle sind schlechter.

Output Guard: Halluzinierte PII abfangen

Hier liegt ein Risiko, das die meisten Teams übersehen: Das LLM könnte PII halluzinieren, die gar nicht im ursprünglichen Input war. Wir behandeln weitere KI-Fehlermodi in einem eigenen Leitfaden, aber dieser verdient besondere Aufmerksamkeit.

Wenn du das Model bittest, eine Antwort an {{person:p_001}} zu schreiben, könnte es eine Telefonnummer, eine Adresse oder den Namen eines Kollegen aus seinen Trainingsdaten erfinden. Diese halluzinierte PII wird nicht durch deine Tokenisierung geschützt, weil sie nie tokenisiert wurde.

Die Lösung: Ein Second-Pass Output Guard, der die Detection-Pipeline auf die Antwort des Models anwendet. Wenn er PII findet, die keinem bekannten Token in der Session entspricht, flagged oder entfernt er sie.

┌───────────────┐     ┌───────────────┐     ┌───────────────┐
│  LLM Response │────▶│  Token Repair  │────▶│  Output Guard  │
│  (with tokens)│     │  (3-stage)     │     │  (detect NEW   │
│               │     │               │     │   PII in output)│
└───────────────┘     └───────────────┘     └────────┬───────┘
                                                      │
                                              ┌───────▼───────┐
                                              │   Rehydrate    │
                                              │  (restore known│
                                              │   tokens only) │
                                              └───────────────┘

Das Model hat eine Telefonnummer erfunden? Erwischt. Einen echten Personennamen aus Trainingsdaten erwähnt? Erwischt. Ein echtes Unternehmen referenziert, das nicht im Input war? Zur Überprüfung markiert.

Sprachbewusste Rehydrierung

Deutsch ist erst der Anfang. Jede Sprache hat grammatische Regeln, die mit personenbezogenen Daten interagieren:

Die Token-Metadaten (gender, formality, language) ermöglichen korrekte Rehydrierung in jeder Sprache. Der formatted-Restore-Modus wendet sprachspezifische Regeln an:

• Deutsch formal weiblich: "Frau" + vollständiger Name → "Frau Sara Mustermann"
• Deutsch formal männlich: "Herr" + vollständiger Name → "Herr Refaat K."
• Arabisch formal weiblich: Ehrenpräfix in RTL → "السيدة موسترمان"
• Französisch formal weiblich: "Madame" + Familienname → "Madame Mustermann"

Das LLM erzeugt die richtige grammatische Struktur, weil es weiß, dass der Token eine formelle weibliche Empfängerin repräsentiert. Es kennt ihren Namen nicht, aber die Ausgabe ist grammatisch perfekt.

Audit-Trails, die keine neuen Haftungsrisiken schaffen

Deine Logging-Infrastruktur wird zur DSGVO-Haftung, sobald du rohe Prompts loggst. Dein Datadog, CloudWatch, Elasticsearch: alles wird zu Systemen, die personenbezogene Daten verarbeiten, jedes mit eigener DSGVO-Dokumentation, Aufbewahrungsrichtlinien und Betroffenenrechte-Verfahren.

Die Regel: Logge Tokens, niemals Werte.

// Korrekt: audit-sicheres strukturiertes Log
{
  "event": "transform_complete",
  "session_id": "ses_a8f3c2",
  "entities_detected": 3,
  "entity_types": ["person", "email", "customer_id"],
  "token_ids": ["p_001", "e_001", "cid_001"],
  "policy_applied": "german-support",
  "protection_levels": [2, 2, 2],
  "detection_time_ms": 8,
  "transform_time_ms": 12
}

// Falsch: PII in Logs. Jetzt ist deine gesamte Log-Pipeline DSGVO-reguliert
{
  "event": "transform_complete",
  "original_name": "Sara Mustermann",           // PII in Logs!
  "original_email": "sara.mustermann@beispiel.de",   // PII in Logs!
  "prompt": "Hallo, ich bin Sara Mustermann..."  // PII in Logs!
}

Jeder Vorgang ist vollständig auditierbar: Du kannst nachverfolgen, dass p_001 von ner_spacy mit Konfidenz 0.95 erkannt, unter der german-support-Policy tokenisiert und mit formatted-Modus auf dem customer_email-Channel wiederhergestellt wurde. Du kannst die komplette Kette rekonstruieren. Aber der Audit-Trail selbst enthält null PII.

Das erfüllt:

• DSGVO Art. 30: Verzeichnis von Verarbeitungstätigkeiten. Du kannst exakt nachweisen, was mit personenbezogenen Daten passiert
• DSGVO Art. 35: Datenschutz-Folgenabschätzung. Dein Audit-Trail beweist, dass die Architektur funktioniert, ohne selbst ein Datenrisiko zu sein
• DSGVO Art. 5(1)(c): Datenminimierung. Nur notwendige Daten werden verarbeitet, und nur in tokenisierter Form außerhalb der Vertrauensgrenze

CRM-Copilot: Gleiche Daten, verschiedene Channels

Schauen wir uns ein CRM-Szenario an, in dem derselbe Input unterschiedliche Ausgaben pro Channel erzeugt. Das ist die Art von individueller Software-Architektur, die wir regelmäßig für Enterprise-Kunden bauen.

CRM-Datensatz-Input:

{
  "contact_name": "Refaat K.",
  "email": "r.k@oronts.com",
  "company": "Oronts GmbH",
  "deal_value": "€125,000",
  "quote_id": "Q-2026-0847",
  "last_interaction": "Discussed pricing, needs board approval"
}

Tokenisierter Prompt ans LLM:

Draft a follow-up email to {{person:p_001}} at {{company:c_001}}.
Context: discussed pricing, needs board approval.
Deal reference: {{order:o_001}}.
Tone: professional, friendly, not pushy.

Das LLM sieht nie "Refaat K.", "Oronts GmbH", "€125.000" oder die Angebotsnummer. Es verfasst eine Follow-up-E-Mail mit Tokens.

Policy-Entscheidungen pro Entity und Output-Channel:

Dieselbe Tokenisierung. Drei komplett unterschiedliche Ausgaben. Die Kunden-E-Mail enthält den Namen und die Angebotsreferenz, aber nie den Deal-Wert. Die interne Zusammenfassung enthält alles. Der Analytics-Export enthält nur anonymisierte Aggregate.

Implementierungs-Roadmap

Wenn sich das nach viel anfühlt, um es alleine umzusetzen: Unser Consulting-Team hat bereits mehrere Enterprise-Kunden durch genau diesen Prozess begleitet. Du kannst auch ein Angebot anfordern für ein Review deiner Trust-Boundary-Architektur.

Phase 1: Datenflüsse kartieren

• Inventarisiere jeden Ort, an dem PII in deine KI-Pipeline gelangt (Prompts, RAG-Chunks, Tool-Calls, Agent-Memory, Fehlermeldungen, Logs)
• Identifiziere, welche Daten das LLM tatsächlich braucht vs was es aktuell erhält
• Zeichne die Vertrauensgrenze: Was bleibt drinnen, was überquert sie

Phase 2: Detection aufbauen

• Starte mit Regex für strukturierte PII (E-Mails, Telefonnummern, IBANs). Das ist schnell und hochpräzise
• Füge NER für Namen und Adressen hinzu. Nutze spaCy oder Transformers mit sprachspezifischen Modellen
• Setze Konfidenz-Schwellenwerte: 0.95+ für Regex, 0.70+ für NER
• Teste die False-Negative-Rate. Übersehene PII ist schlimmer als False Positives

Phase 3: Tokenisierung implementieren

• Definiere dein Token-Format ({{type:id}}) und Metadaten-Schema
• Baue das Session-Mapping mit Sealed Encryption (AES-256-GCM)
• Implementiere Schutzstufen pro Entity-Typ
• Erstelle Policies pro Output-Channel

Phase 4: Rehydrierungs-Pipeline

• Token-Reparatur (strikt → deterministisch → fuzzy)
• Output Guard (halluzinierte PII in Model-Antworten erkennen)
• Policy-gesteuerte Restore-Modi pro Channel
• Sprachbewusste Formatierung (geschlechtsspezifische Anrede, Ehrentitel)

Phase 5: Compliance-Integration

• Strukturiertes Audit-Logging (Token-IDs, niemals Werte)
• DSGVO Art. 30 Verarbeitungsverzeichnis
• DSGVO Art. 35 Datenschutz-Folgenabschätzung mit Architektur-Nachweis
• Integration in den Prüfprozess deines DSB
• Siehe unsere Übersicht zu Vertrauen und Compliance für die Art, wie wir diese Garantien für Kunden dokumentieren

Häufige Fallstricke

1. Rohe Prompts loggen. Dein Datadog wird über Nacht zum DSGVO-regulierten System. Logge Token-IDs, niemals Werte.
2. Token-Reparatur überspringen. 2-5% der LLM-Antworten haben kaputte Tokens. Dein Kunde sieht {{person:p_001}} statt eines Namens.
3. Kein Output Guard. Das Model halluziniert PII aus Trainingsdaten. Du hast gerade die echte Telefonnummer einer fremden Person geleakt.
4. Gleicher Restore-Modus überall. Kunden-E-Mails und Analytics-Dashboards brauchen grundlegend unterschiedliche Detailgrade.
5. Agent-Workflows ignorieren. Ein 5-Schritte-Agent hat 5+ Leak-Punkte. Nur den letzten LLM-Aufruf zu schützen ist wie die Haustür abzuschließen bei offenen Fenstern.
6. "Wir hosten einfach unser eigenes LLM." Kostet 10x mehr, dauert 6+ Monate, und du brauchst trotzdem Data Governance. Das Problem ist die Architektur, nicht das Hosting.
7. Compliance als Nachgedanken behandeln. Die Rechtsabteilung blockiert dein Deployment sechs Wochen vor Launch. Beziehe sie von Tag eins ein.
8. Keine Sealed Sessions. Serverseitiger Session-State bedeutet, dass dein Redis-Cluster zum Single Point of Failure für jeden KI-Request wird.
9. Sprachunbewusstes Masking. [NAME] in deutscher formeller Korrespondenz ist ein sofortiger Glaubwürdigkeitsverlust.
10. PII in Vektoren einbetten. Deine Vektordatenbank wird zum größten ungeprüften PII-Speicher in deiner Infrastruktur.

Zentrale Erkenntnisse

• Die Vertrauensgrenze ist eine Architekturentscheidung, keine Library. Zeichne sie, setze sie an jeder Überquerung durch, auditiere sie ohne PII in den Logs.
• Semantische Tokenisierung bewahrt die KI-Qualität, wo naives Masking sie zerstört. Das Model bekommt Geschlecht, Förmlichkeit, Sprach-Metadaten. Genug für korrekte Grammatik ohne Rohwerte.
• Drei Schutzstufen bilden reale Datensensibilität ab: Hard-Mask für Reguliertes, Tokenisierung für Nützliches, Abstraktion für Metadaten.
• Policy-gesteuerter Restore bedeutet, dass eine Tokenisierung alle Channels bedient: Kunden-E-Mails bekommen formatierte Namen, Analytics bekommt abstrakte Labels, Logs bekommen nichts.
• Agentische Workflows vervielfachen das Risiko exponentiell. Jeder Tool-Call, jeder Reasoning-Schritt, jeder Memory-Write ist ein potenzieller Leak-Punkt. Schütze jede Grenzüberquerung.
• Sealed Sessions eliminieren Server-State. AES-256-GCM-verschlüsselte Blobs reisen mit dem Request, skalieren horizontal und scheitern geschlossen bei Manipulation.
• Sprachbewusste Rehydrierung ist der Unterschied zwischen "Dear [NAME]" und "Sehr geehrte Frau Mustermann". Dieser Unterschied entscheidet, ob dein Enterprise-Kunde das System freigibt.

DSGVO-konforme KI-Systeme zu bauen, die gleichzeitig leistungsfähig sind, ist kein Widerspruch. Es ist ein Architekturproblem. Die Lösung liegt darin, die richtigen Vertrauensgrenzen zu ziehen, die richtigen Metadaten zu bewahren und die Wiederherstellung pro Output-Channel zu steuern.

Wir haben OGuardAI als Open-Source-Runtime für genau dieses Problem gebaut. Detect, Transform, Rehydrate mit semantischer Tokenisierung, Sealed Sessions und Policy-gesteuertem Restore. Es ist die in diesem Artikel beschriebene Architektur, paketiert als produktionsreifes System.

Wenn du KI-Architekturen für dein Unternehmen evaluierst, decken unsere KI-Services den gesamten Stack ab, vom Trust-Boundary-Design bis zum Produktions-Deployment. Du kannst auch unseren Ansatz für Datenschutz und Compliance erkunden oder mehr über Enterprise-KI-Orchestrierung und KI-Governance in der Produktion lesen.

Bereit, eine DSGVO-konforme KI-Architektur zu entwerfen? Sprich mit unserem Team oder fordere ein Angebot an. Wir haben das für Produktionssysteme ausgeliefert, die täglich Tausende von Kundeninteraktionen in Deutsch, Arabisch, Französisch und Englisch verarbeiten.