Kanzleien, Rechtsabteilungen, Versicherer und Inkassodienstleister verarbeiten mit DEPLAW hochsensible, mandatsbezogene Daten – Namen und Anschriften von Mandanten und Gegnern, Vertragsinhalte, Prozessstrategien, finanzielle Verhältnisse und nicht selten besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO (z. B. Gesundheitsdaten oder Angaben zu strafrechtlichen Verurteilungen). Als Berufsgeheimnisträger unterliegen Sie dabei der anwaltlichen Verschwiegenheitspflicht (§ 43a BRAO) und dem strafbewehrten Schutz von Privatgeheimnissen (§ 203 StGB). Diese Seite erklärt, wie die DEPLAW-Architektur Sie dabei unterstützt, diese Pflichten beim Einsatz von Sprachmodellen (LLMs) technisch zuverlässig einzuhalten.
Das Kernproblem cloudbasierter LLM-Dienste
Sobald Inhalte an einen externen, in der Cloud betriebenen Dienst übertragen werden, verlassen sie die kontrollierte Umgebung und werden auf fremder Infrastruktur verarbeitet. Daraus ergeben sich mehrere kritische Risiken:
Leitprinzip: lokale und On-Premise-LLMs
DEPLAW setzt deshalb bevorzugt auf lokal betriebene Sprachmodelle – im On-Premise-Betrieb oder in einer dedizierten, kontrollierten Umgebung. Die Modelle werden innerhalb dieser Umgebung ausgeführt; die zu verarbeitenden Daten verlassen sie zu keinem Zeitpunkt.
| Grund | Bedeutung |
|---|---|
| Datenhoheit und Kontrolle | Eingaben, Zwischenergebnisse und Ausgaben bleiben vollständig in der Verfügungsgewalt des Verantwortlichen – die gesamte Risikoklasse um Auftragsverarbeitung, Drittlandtransfer und intransparente Weiterverwendung entfällt. |
| Nachweisbare Compliance | Weil die gesamte Verarbeitungskette selbst betrieben wird, lassen sich die technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO belastbar dokumentieren. |
| Vereinbarkeit mit der Verschwiegenheitspflicht | Da keine Daten an Dritte übermittelt werden, findet keine „Offenbarung“ im Sinne des § 203 StGB statt. |
| Keine Trainingsnutzung | Lokal betriebene Modelle werden nicht mit Kundendaten weitertrainiert; Eingaben dienen ausschließlich der Verarbeitung der jeweiligen Anfrage. |
| Verfügbarkeit und Unabhängigkeit | Der Betrieb ist unabhängig von Verfügbarkeit, Preisänderungen und Nutzungsbedingungen externer Dienste. |
Wie Sie ein lokales bzw. selbst gehostetes Modell technisch anbinden, beschreibt KI-Konnektoren – die URL des Konnektors zeigt dabei einfach auf Ihren eigenen Endpunkt statt auf einen Cloud-Anbieter.
Der Pseudonymisierungsservice
Ergänzend zur Anbindung lokaler Modelle stellt DEPLAW einen Pseudonymisierungsservice bereit. Er nutzt die in der Akte hinterlegten Stammdaten – Namen, Anschriften und weitere identifizierende Angaben der Beteiligten – und ersetzt deren Vorkommen in einem Dokument durch Pseudonyme bzw. Platzhalter, bevor es an ein externes Modell geht.
Kein alleiniger Einsatz bei sensiblen Dokumenten
| Grenze | Bedeutung |
|---|---|
| Begrenzte Abdeckung | Nur als Stammdaten bekannte Angaben werden erfasst. Personen oder Details, die im Dokument vorkommen, aber nicht in der Akte hinterlegt sind, bleiben im Klartext erhalten – wie „Dr. A. Weber“ im Beispiel oben. |
| Verbleibende sensible Inhalte | Besondere Kategorien nach Art. 9 DSGVO und kontextbezogene Angaben ermöglichen häufig auch nach dem Ersetzen der Namen noch einen Personenbezug. |
| Restrisiko der Re-Identifikation | Ein Zusammenführen mit weiteren Informationen kann zur Re-Identifikation führen; bei besonders schützenswerten Inhalten wiegt dies schwerer. |
Best Practice: Workflows mit mehreren LLM-Modellen (Multi-LLM-Betrieb)
Manche Mandate sind so komplex und sachverhaltsintensiv, dass die höchstmögliche Modellqualität gewünscht ist – eine Qualität, die im Einzelfall nur besonders leistungsstarke externe Modelle erreichen. Daraus entsteht ein Zielkonflikt zwischen Verarbeitungsqualität und Vertraulichkeit. DEPLAW löst ihn über den Multi-LLM-Betrieb mit lokalem Sanitize-Roundtrip: Ein lokales Modell bereitet die Daten datensparsam auf, ein externes Modell verarbeitet ausschließlich die pseudonymisierte Fassung, und die Rückschlüsselung erfolgt wieder vollständig lokal.
Technisch ist die KI-Verarbeitung dabei ein ganz normaler Schritt im BPMN-Workflow – ein ServiceTask mit definiertem Ein- und Ausgang und vollständiger Protokollierung. Die eingesetzten externen Modelle sind herstellerunabhängig austauschbar (u. a. OpenAI, Anthropic, Google), ohne dass sich am Schutzmechanismus etwas ändert.
Der Ablauf
- Lokales Sanitizing
Ein lokales LLM pseudonymisiert die Eingabe innerhalb der kontrollierten Umgebung und entfernt bzw. ersetzt identifizierende Merkmale.
- State speichern
Die Zuordnung Klartext ↔ Pseudonym wird als State in der Akte bzw. im Workflow gespeichert. Diese Zuordnungstabelle verlässt die kontrollierte Umgebung zu keinem Zeitpunkt.
- Externe Verarbeitung
Nur der pseudonymisierte Prompt wird an das externe Modell übermittelt. Über die Vertrauensgrenze gelangen ausschließlich pseudonymisierte Inhalte – kein Klartext, keine Stammdaten.
- Antwort entgegennehmen
Die ebenfalls pseudonymisierte Antwort des externen Modells wird zurück in die kontrollierte Umgebung geführt.
- Lokale Rückschlüsselung
Über die gespeicherten States wird die Antwort de-pseudonymisiert und das re-identifizierte Ergebnis in der Akte abgelegt.
State-Handling in Akte und Workflow
Die Zuordnung wird pro Akte bzw. Vorgang verschlüsselt persistiert und ist an den jeweiligen Workflow-Schritt gebunden. So bleiben mehrstufige Verarbeitungen konsistent, Pseudonyme über mehrere Anfragen hinweg stabil und Ergebnisse deterministisch rückschlüsselbar. Die States unterliegen denselben Schutzmaßnahmen wie die übrige Akte (Verschlüsselung, Least Privilege, Löschkonzept) und werden ausschließlich lokal aufgelöst.
Betriebsmodi im Vergleich
| Modus A – rein lokal | Modus B – Multi-LLM-Roundtrip | |
|---|---|---|
| Daten verlassen die Umgebung | Nein – vollständig lokal | Nur pseudonymisiert; Mapping bleibt lokal |
| Modellqualität | Durch lokales Modell begrenzt | Externe Spitzenmodelle nutzbar |
| Restrisiko | Minimal | Abhängig von Pseudonymisierungsqualität |
| Empfohlen für | Höchster Schutzbedarf, Art.-9-Daten | Komplexe, gut pseudonymisierbare Mandate |
Einsatzszenarien
So stellen Sie es in DEPLAW ein
Der Schutzmechanismus ist kein separates Bauteil, sondern in die KI-ServiceTasks selbst eingebaut: Felder wie _enablePseudonymization (Standard: aktiviert) an Tasks wie PromptToLLM oder LlmExtractionTemplateRun steuern, ob die Eingabe vor der Übergabe pseudonymisiert wird. Für den Multi-LLM-Betrieb legen Sie zusätzlich einen lokalen KI-Konnektor an, den Sie für das Sanitizing verwenden, sowie einen zweiten Konnektor für das externe Spitzenmodell – welcher Konnektor für welchen Workflow-Schritt greift, entscheiden Sie pro ServiceTask.
Zusammenfassung
- Lokale/On-Premise-Modelle sind die datenschutzfreundlichste und für sensible Mandatsdaten die maßgebliche Betriebsform.
- Der Pseudonymisierungsservice ist eine ergänzende Schutzschicht – keine Anonymisierung und kein alleiniger Schutz für hochsensible Dokumente.
- Der Multi-LLM-Betrieb mit lokalem Sanitize-Roundtrip erschließt externe Spitzenmodelle für komplexe Mandate, ohne dass Klartext oder die Zuordnungstabelle die kontrollierte Umgebung je verlassen.
- Je höher der Schutzbedarf eines Dokuments, desto eher gilt: rein lokal statt Roundtrip.