← Compliance-Paket (Übersicht)

Saklam Bridge — Technisches Datenschutz-Whitepaper

Für die Datenschutz-Dokumentation regulierter Anwender (Kanzleien, Steuerberatung, Arzt-/Zahnarztpraxen, Gesundheits-Publishing).

Stand: 14. Juli 2026 · Version: 1.0 · Aussteller: Portalix UG (haftungsbeschränkt), München

Geltung & Grenzen (RDG): Dieses Dokument ist kein Rechtsrat und ersetzt kein Gutachten. Es beschreibt die technische Architektur von Saklam Bridge und zitiert öffentliche Quellen. Die rechtliche Würdigung für den konkreten Einsatz trifft der Datenschutzbeauftragte bzw. Rechtsberater des Anwenders. Saklam gibt nach außen keine Rechtszusage.

1. Zweck

Regulierte Berufe wollen Frontier-KI (Claude, GPT, Gemini, Mistral) nutzen, ohne dass Mandanten-, Patienten- oder sonstige besonders geschützte Daten den Anbieter im Klartext erreichen. Saklam Bridge ist die technische Schicht, die genau das leistet: Personenbezogene Stellen werden durch Platzhalter ersetzt, bevor der Request die eigene Infrastruktur verlässt. Das Modell arbeitet mit den Platzhaltern; die Rückübersetzung geschieht ausschließlich lokal.

2. Was die Bridge tut (Architektur)

Anwendung / Workflow (in Ihrer Infrastruktur)
        │  Klartext
        ▼
┌─ Saklam Bridge (Docker-Container, Ihre Infrastruktur) ──────┐
│  1. PII-Erkennung (Regex + NER, DE-optimiert)                │
│  2. Ersetzung durch Platzhalter  [PER_…]/[IBA_…]/[ICD_…]     │
│  3. Mapping (Platzhalter → Klartext) bleibt LOKAL            │
│  4. Weiterleitung an den Provider mit Ihrem API-Key (BYOK)   │
│  5. Antwort wird LOKAL wieder demaskiert                     │
└──────────────────────────────────────────────────────────────┘
        │  nur Platzhalter + entkernter Kontext
        ▼
LLM-Provider (Anthropic / OpenAI / Google / Mistral)
  • On-Premises: Der Container läuft in der Infrastruktur des Anwenders. Es gibt keinen Saklam-Server im Datenpfad.
  • Zero-Knowledge gegenüber Saklam: Der Hersteller (Portalix UG) empfängt zu keinem Zeitpunkt Klartext, Prompts oder das Mapping. Verifizierbar, weil self-hosted.
  • BYOK: Der Anwender nutzt seine eigenen Provider-Verträge und -Schlüssel.

3. Was das Haus verlässt — und was nicht

Verlässt die Perimeter Bleibt lokal
Klartext-PII (Namen, Adressen, IBANs, Diagnosen …) nein ja
Mapping Platzhalter ↔ Klartext nein ja
Platzhalter-Tokens + entkernter Fachkontext ja (zum Provider) —
Prompt-/Antwort-Klartext bei Saklam nie — (Saklam sieht nichts)

Der Provider erhält den Fachkontext (Sachverhalt, Frage, Struktur), aber nicht die Identitäten.

4. Zwei Compliance-Säulen (Architektur + Quellen)

Säule 1 — Berufsgeheimnis, § 203 StGB

Quelle: BRAK-Stellungnahme 32/2025 (Juli 2025); BStBK-FAQ KI (11.02.2026).

Die BRAK beschreibt, dass eine automatisierte Verarbeitung ohne Klartext-Zugriffsmöglichkeit durch Provider-Personal regelmäßig kein „Offenbaren" i. S. d. § 203 StGB darstellt. Verlassen nur Platzhalter die Perimeter, gibt es kein Geheimnis zu offenbaren. Als zusätzliche Absicherung sieht § 203 Abs. 3/4 StGB eine Verschwiegenheitsverpflichtung in Textform vor, die nachgelagerte Dienstleister einbezieht (siehe Baustein „Mitwirkenden-Vertrag"). Saklam legt Maskierung über den Vertrag — Gürtel plus Hosenträger.

Säule 2 — DSGVO / Drittstaaten-Transfer

Quelle: EuGH C-413/23 P (EDPS ./. SRB), Urteil 04.09.2025.

Die Mask/Unmask-Funktion ist reversibel — das Mapping bleibt lokal —, rechtlich also Pseudonymisierung. Für den Anwender bleiben die Daten personenbezogen (on-prem zulässig). Der EuGH bestätigt den relativen/kontextbezogenen Personenbezugs-Begriff: Dieselben Daten können für den Schlüssel-Halter personenbezogen und für einen Empfänger, der mit „vernünftigerweise wahrscheinlichen Mitteln" nicht re-identifizieren kann, nicht personenbezogen sein. Für den Provider, der nur Platzhalter + entkernten Kontext sieht, ist eine solche Bewertung dokumentierbar.

Beide Säulen beschreiben eine rechtlich existierende, gut abgesicherte Risiko-Position — keine Garantie. Die Würdigung trifft Ihr DSB/Anwalt.

5. Technisch-organisatorische Maßnahmen (Auszug für Art. 32 DSGVO)

  • Verarbeitung ausschließlich on-prem, kein Hersteller-Zugriff (Zero-Knowledge).
  • Datenminimierung by design (Art. 5 Abs. 1 lit. c): dem Provider werden nur die für die Aufgabe nötigen Nicht-Identitäts-Daten übermittelt.
  • Kein Klartext-Logging im Datenpfad; optionaler manipulationssicherer Audit-Trail (Mask-Ereignisse ohne Klartext, siehe separates Audit-Log-Feature).
  • Transport zum Provider über TLS; Container-Zugriff im LAN nur mit Master-Key + TLS-Reverse-Proxy.

6. Ehrliche Restrisiken (und wie sie adressiert werden)

  1. Erkennungsqualität / False Negatives. Kein Muster-/NER-System erreicht 100 % Recall. → Laufende Pattern-Pflege (300+ geprüfte Muster, EU-27), DE-optimiertes NER, Sliding-Window für lange Dokumente. Restrisiko wird in der DSFA dokumentiert (Baustein liegt bei).
  2. Re-Identifikation über Quasi-Identifikatoren. Geburtsdatum + Ort + seltenes Merkmal kann auch ohne Namen eingrenzen (Art. 9-Relevanz im Gesundheitskontext). → Saklam maskiert auch Datum/Ort/seltene Merkmale, nicht nur Namen; die Rest-Risikobewertung gehört in die DSFA.
  3. Relativität von C-413/23. Der kontextbezogene Ansatz ist kein Freifahrtschein; eine dokumentierte Re-Identifikations-Risikobewertung ist Teil der Sorgfalt (Baustein liegt bei).

7. Was Sie mit diesem Dokument tun

  • Als Anlage zu Ihrer Datenschutz-Dokumentation / Ihrem Verarbeitungsverzeichnis führen.
  • Zusammen mit dem DSFA-Baustein und der Verschwiegenheitsverpflichtung/Mitwirkenden-Vertrag-Vorlage Ihrem DSB/Rechtsberater zur Prüfung und Anpassung vorlegen.

Fragen zur Architektur: support@saklam.com