Multi-Tenant-KI: Prüfprotokoll und Mandantentrennung

Kernrisiko: Multi-Tenant-Daten-Leakage. Customer A sieht Daten von Customer B durch DB-Query-Bug, Logging-Leak oder LLM-Cross-Contamination. DSGVO-Bußgeld bei Data-Breach: 4% Welt-Umsatz oder 20 Mio €.

Layer-1: DB-Schema-Isolation per Customer-Slug

DripBack-Pattern: jeder Customer hat eigenen DB-Schema-Prefix:

customers/test_hausarzt_detmold/m18_audit.jsonl
customers/test_reha_lippe/m22_audit.jsonl
customers/test_hotel_owl/m58_audit.jsonl

Plus DB-Connection-Pool ist pro Customer separat. Kein Cross-Customer-JOIN möglich auf API-Ebene.

Layer-2: SHA1-Pseudonymisierung im Prüfprotokoll

Das Prüfprotokoll enthält NIEMALS Klartext-Body. Stattdessen SHA1-Hash:

{
  "timestamp": "2026-05-08T22:30:00Z",
  "customer": "test_hausarzt_detmold",
  "module": "Telefonassistent",
  "intent": "termin_anfrage",
  "body_hash": "sha1:a3f5...8b2c",  <-- KEIN Klartext
  "confidence": 0.92,
  "auto_reply": true,
  "reply_hash": "sha1:c7e2...1d4a"
}

Effekt: bei Audit kann das BfDI / Customer-DSB das Prüfprotokoll einsehen ohne dass Klartext-Mandanten-Daten exposed werden. Nur Customer selbst kennt das Mapping body_hash → original (re-identifizierbar nur mit Customer-DB-Zugriff).

Layer-3: AVV erweiterte TOMs

Auftragsverarbeitungs-Vertrag (AVV nach DSGVO Art. 28) ist Standard. Für Branchen mit Berufsgeheimnis (Anwalt §43a, Arzt §203 StGB, Steuerberater §57 StBerG) brauchen wir erweiterte TOMs:

On-Premise-Option (Hardware in Customer-Rack)
VPN-Tunneling für alle externen API-Calls
Quarterly Pen-Test mit Customer-Zugriff auf Report
Daten-Lokalisierung Deutschland (Serverstandort Deutschland, kein US-Cloud-Routing)
Backup-Lokalisierung ebenfalls DE-only
RPO 24h, RTO 4h vertraglich zugesichert

Layer-4: LLM-Cross-Contamination-Filter

Heikles Thema bei LLMs: zwei Customer-Prompts in derselben Session können kontaminieren. DripBack-Pattern:

Pro Customer-Request: neuer Ollama-Connection-Slot (kein Session-State zwischen Customers)
System-Prompt enthält nie Customer-Daten anderer Customer
Prompt-Template hat customer={slug}-Marker für Audit, aber LLM sieht nur diesen einen Customer
Bei Cloud-LLM-Routing: eigene Schwärzungsphase für personenbezogene Daten BEVOR die Cloud angefragt wird (Customer-Slug raus, Klartext-Daten redacted oder pseudonymisiert)

DripBack-Cloud-Routing-Regel: Kunden- und personenbezogene Daten gehen NIE ungeschwärzt in die Cloud. Ollama lokal ist Default. Cloud nur für Edge-Cases (komplexe Reasoning) und nur nach ausdrücklicher Schwärzung personenbezogener Daten.

Layer-5: Multi-Tenant-Quota-Enforcement

KI-SDR (Cold-Outreach SaaS) hat per-Customer-Quotas:

Max 50 Connection-Requests/Tag pro Customer (LinkedIn-Limit)
Max 1.000 Outreach-Mails/Tag pro Customer (SMTP-Reputation)
Per-Customer SMTP-Account-Pool (kein Shared-IP)
Bounce-Rate-Monitor pro Customer (>5% → Cap automatisch)

EU AI-Act-Compliance (ab Aug. 2026)

SaaS-KI fällt unter EU AI-Act. DSGVO-KI-Audit-Suite prüft pro Customer:

Risk-Klassifikation (Limited/High-Risk je nach Anwendungsfall)
Conformity-Assessment für High-Risk (z.B. medical, public-services)
Doku-Anforderungen Art. 11 + 18
Bias-Test (Art. 10 Daten-Qualität)
Human-Oversight-Hooks (Art. 14)

Förderung

Multi-Tenant-SaaS-Aufbau ist FZulG-fähig wenn die Architektur Forschungs-Charakter hat (eigene Isolation-Pattern, eigene Audit-Methodik, neue Cross-Tenant-Filter). Plus EU AI-Act-Compliance-Programme.

Multi-Tenant SaaS-KI mit DSGVO-Hash-Prüfprotokoll