Von Shield zu Maria.

Werkstattnotiz · April 2026

Maria ist die Sicherheitsschicht in EDN. Sie sitzt nicht als fremdes Produkt neben SAJA, sondern innerhalb der Plattform. Wenn SAJA ein externes Sprachmodell nutzt, sorgt Maria dafür, dass dieses Modell nicht einfach die volle Fallrealität sieht. Stattdessen erzeugt Maria eine kontrollierte Arbeitsansicht: bekannte Personen werden durch Arbeitsreferenzen ersetzt, sensible Angaben je nach Aufgabe generalisiert oder zurückgehalten, Tool-Aufrufe über EDN geführt und Modellantworten geprüft, bevor sie zur Fachkraft zurückgehen.

Das klingt heute klar. Es war aber nicht der erste Entwurf. Der Weg zu Maria führte über Shield v0.3, eine kaputte Namensliste, ein verworfenes Shield-v2-Experiment mit synthetischen Parallelwelten und die Erkenntnis, dass Datenschutz in einer echten Fachanwendung nicht nur vor dem Modellcall passiert, sondern davor, darin und danach.

Das hier ist die Werkstattversion dieser Geschichte.

Shield v0.3, der erste Schutz war ein Filter

Die erste Version von Shield hatte eine einfache Aufgabe. Wenn eine Fachkraft in SAJA schreibt: „Max hatte heute Probleme in der Schule." sollte ein externes Sprachmodell nicht „Max" sehen, sondern einen geschützten Platzhalter wie: „Kind-1 hatte heute Probleme in der Schule." Beim Rückweg wurde der Platzhalter wieder durch den echten Namen ersetzt.

Für eine erste Version war das sinnvoll. Bekannte Klienten, Kontakte und Mitarbeitende aus der Datenbank wurden erkannt und durch stabile Pseudonyme ersetzt. Das war der erste Schutz. Aber es war noch keine Architektur. Denn Shield v0.3 arbeitete stark textbasiert: Namen erkennen, ersetzen, zurückersetzen. Für bekannte Personen funktionierte das oft gut. Schwieriger wurde es bei unbekannten Namen, Kontexten über mehrere Nachrichten und Begriffen, die zwar wie Namen aussehen, aber keine sind.

Was eine Namensliste nicht versteht

Eine Fachkraft schreibt: „Um 11 Uhr war Max im Haus." Eine Namensliste kann „Um" als Namen missverstehen. Selten, aber möglich. Dann wird aus einer Uhrzeit plötzlich eine Person. Der Satz kippt. Das Modell bekommt einen beschädigten Kontext. SAJA kann daraus falsche Schlüsse ziehen.

Oder: „Nur U4. Routine." Wenn „Nur" als Vorname erkannt wird, maskiert das System ein normales Wort als Person. Wieder entsteht ein Schutzereignis, wo gar keins war.

Solche Fehler wirken klein. Aber in einer Fachsoftware sind sie gefährlich, weil sie die Bedeutung des Satzes verändern. Das Problem war nicht nur ein Bug, das Problem war die Methode.

Eine Liste sieht Wörter. Eine Fachsoftware braucht Kontext.

Pseudonymisierung schützt nicht alles

Selbst wenn jeder Name richtig ersetzt wird, bleibt ein zweites Problem: ein Text kann auch ohne Namen erkennbar sein. Wenn ein Modell über mehrere Nachrichten hinweg liest, dass Kind-1 in einem bestimmten Stadtteil lebt, acht Jahre alt ist, eine konkrete Schule besucht, eine seltene Diagnose hat, ein bestimmtes Medikament nimmt und letzte Woche einen besonderen Vorfall hatte, dann kennt das Modell zwar keinen Klarnamen. Aber es sieht eine dichte Fallkonstellation.

Das nennt man Quasi-Identifikatoren: einzelne Angaben, die für sich genommen harmlos wirken, aber in Kombination eine Person wiedererkennbar machen können. Shield v0.3 entfernte Namen. Es entfernte aber nicht zuverlässig die Struktur, aus der Wiedererkennbarkeit entstehen kann. Genau hier begann die Suche nach einem stärkeren Ansatz.

Shield v2, die Idee einer synthetischen Parallelwelt

Shield v2 war der Versuch, radikaler zu denken. Die Idee: nicht nur Namen ersetzen, den gesamten Kontext verändern. Aus „Lisa lebt mit ihrer Mutter in Hannover. Sie hat ADHS und nimmt Ritalin." sollte nicht nur „Kind-1 lebt mit Kontakt-1 in Ort-1." werden, sondern eher: „Moritz lebt mit seinem Vater in Frankfurt. Er hat eine andere Belastung und eine andere Behandlung."

Das externe Modell hätte dann keinen echten Fall gesehen, sondern eine plausible fiktive Parallelwelt. Ein Märchen, aber fachlich ähnlich genug, damit das Modell noch arbeiten kann. Theoretisch war das reizvoll. Wenn ein Modell nur noch eine fiktive Fallwelt sieht, reduziert sich das Risiko, dass aus dem Modellkontext ein realer Mensch rekonstruiert werden kann. Für isolierte Texte ist diese Idee stark.

Aber SAJA ist kein isolierter Text. SAJA ist ein Gespräch. SAJA stellt Rückfragen. SAJA nutzt Tools. SAJA sucht in Dokumenten. SAJA erkennt Muster. SAJA legt Termine und Kontakte an. SAJA arbeitet in einer echten Umgebung. Und genau daran ist Shield v2 als Standardpfad zerbrochen.

Warum die Märchenwelt nicht getragen hat

Wenn Lisa in Nachricht 1 zu Moritz wird, muss sie in Nachricht 5 immer noch Moritz sein. Wenn die Mutter in Nachricht 2 zum Vater wird, muss diese neue Familienkonstellation konsistent bleiben. Dafür braucht man ein Mapping über mehrere Turns. Dieses Mapping wird selbst wieder sensibel. Es muss gespeichert, geschützt, verstanden und rückübersetzt werden. Damit entsteht ein neues Problem, statt das alte zu lösen.

Wenn eine Fachkraft „Ritalin" dokumentiert, darf am Ende nicht „Medikation zur Aufmerksamkeitsregulation" stehen, wenn die Akte die konkrete Medikation braucht. Wenn ein Kind beim Kuchenbacken geholfen hat, darf daraus in der finalen Doku kein Bastelprojekt werden. Für maximale Verschleierung ist Kontextveränderung gut. Für aktenrelevante Dokumentation ist sie gefährlich. Eine Doku muss fachlich stimmen.

Außerdem wurde Tool-Use zu schwer. SAJA arbeitet nicht nur mit Text, SAJA nutzt EDN. Eine zwischengeschaltete Märchenwelt müsste Tool-Aufrufe übersetzen, Datenbankergebnisse synthetisieren, Antworten zurückübersetzen und trotzdem fachlich korrekt bleiben. Das wurde zu fragil.

Die Korrektur, EDN bleibt die Trust Boundary

Die wichtigste Erkenntnis war: nicht eine externe Shield-API ist die Sicherheitsgrenze. EDN selbst ist die Sicherheitsgrenze. EDN kennt die Daten, kennt den Mandanten, kennt die Rollen, kennt Klienten, Kontakte, Dokumente, Termine, Diagnosen, Medikamente und Statistik. EDN kann entscheiden, was eine Aufgabe wirklich braucht.

Darum muss der Schutz nicht außerhalb von SAJA in einer fremden Übersetzungswelt entstehen, sondern innerhalb der Plattform. Maria ist diese Schicht. Nicht als Märchenmaschine. Nicht als reine Platzhalterlogik. Sondern als kontrollierte Arbeitsansicht der EDN-Datenwelt.

Maria, ehrlicher als ein Märchen

Maria macht nicht aus einem echten Fall einen anderen Fall. Maria entscheidet, welche Teile des echten Falls ein externes Modell für eine konkrete Aufgabe sehen darf. Wenn SAJA eine Dokumentation formulieren soll, braucht das Modell vielleicht den Ablauf, aber nicht den echten Namen. Wenn SAJA nach ähnlichen Vorfällen sucht, braucht das Modell vielleicht eine Kategorie und einen Zeitraum, aber keine Rohdokumente. Wenn SAJA Statistik erklärt, braucht das Modell aggregierte Muster, aber keine vollständige Aktenrealität.

Maria arbeitet deshalb aufgabenbezogen. Aus „Lukas hat heute beim Frühstück geweint. Seine Mutter war beim Abholen sehr angespannt. Im März gab es schon einmal einen ähnlichen Vorfall mit Tobias." kann für das Modell werden: „[KLIENT_A] hat heute beim Frühstück geweint. [BEZUGSPERSON_A] wirkte beim Abholen angespannt. Im Vormonat gab es einen ähnlichen Eintrag mit [KLIENT_B]."

Das Modell sieht keine Klarnamen. Die Zuordnung bleibt innerhalb von EDN. Die fachliche Wahrheit bleibt erhalten.

D-POM, das Verfahren hinter Maria

Die Schutzstrategie hinter Maria heißt D-POM, Data Protection Operating Model. D-POM ist kein einzelner Filter. Es ist ein Betriebsmodell für KI-Verarbeitung in EDN. Dazu gehören kontrollierte Arbeitsansichten, aufgabenbezogene Datenminimierung, geschützte Arbeitsreferenzen, Erkennung bekannter Personen aus der EDN-Datenbank, Generalisierung sensibler Attribute, Prüfung von Quasi-Identifikatoren, kontrollierte Tool-Aufrufe, gefilterte Tool-Ergebnisse, Prüfung von Modellantworten, Logging-Beschränkungen, Mandantentrennung, Rollen und Rechte sowie die Dokumentation der Datenflüsse.

Maria ist die technische Schicht, die D-POM in EDN umsetzt. Kurz: D-POM ist das Schutzverfahren. Maria ist die Sicherheitsschicht.

Arbeitsreferenzen statt globaler Pseudonyme

Ein wichtiger Unterschied zu Shield v0.3 ist der Umgang mit Referenzen. In Shield v0.3 waren Pseudonyme oft dauerhaft stabil. Ein Klient konnte über längere Zeit immer als Kind-1 erscheinen. Das ist praktisch, kann aber selbst zu einem Korrelationsrisiko werden.

Maria arbeitet anders, mit kontextlokalen Arbeitsreferenzen. [KLIENT_A] gilt innerhalb eines konkreten Arbeitskontexts, zum Beispiel während einer Doku-Erstellung oder eines Gesprächsabschnitts. Es ist keine globale Identität, die über alle Aufgaben, alle Tage und alle Modellcalls hinweg gleich bleibt. EDN weiß intern, wer gemeint ist. Das externe Modell sieht nur die Arbeitsreferenz. Das reduziert das Risiko, dass über viele Modellaufrufe hinweg ein wiedererkennbares Schattenprofil entsteht.

Maria schützt nicht nur den Input

Ein häufiger Fehler bei KI-Datenschutz ist, nur auf die Eingabe zu schauen. Was geht an das Modell? Aber bei generativer KI entsteht Risiko auch im Output. Ein Modell kann neue Namen erfinden, zu konkrete Details erzeugen, pädagogische Bewertungen formulieren, Handlungsempfehlungen geben, riskante Kombinationen verdichten oder falsche Zusammenhänge herstellen.

Darum prüft Maria nicht nur die Anfrage, sondern auch die Antwort. Diese Schicht nennen wir Output Governance. Maria kann eine Antwort freigeben, markieren, neu erzeugen lassen oder blockieren. SAJA speichert aktenrelevante Inhalte nicht automatisch. Die Fachkraft prüft den Entwurf.

Das Modell formuliert. EDN kontrolliert. Die Fachkraft entscheidet.

Tool Boundary, das Modell spricht nicht direkt mit der Datenbank

SAJA kann mehr als schreiben. SAJA kann suchen, alte Einträge finden, Termine strukturieren und Muster sichtbar machen. Aber ein externes Modell soll nicht direkt mit Rohdaten arbeiten. Darum gibt es in Maria eine Tool Boundary.

Wenn ein Modell nach alten Einträgen fragt, passiert nicht: „Suche in der Akte von Lukas nach Streit mit Tobias und Mutter im März." Sondern das Modell arbeitet mit Referenzen: „Suche für [KLIENT_A] ähnliche Einträge der Kategorie Konflikt im Zeitraum der letzten Monate."

EDN führt die echte Suche intern aus. Maria filtert das Ergebnis. Das Modell bekommt eine geschützte, aufgabenbezogene Antwort, zum Beispiel: „Für [KLIENT_A] liegt ein früherer Eintrag mit ähnlicher Konfliktstruktur vor. Es gab dabei eine beteiligte weitere Person und eine Bezugsperson im Anschluss." Das Modell braucht die Rohdaten nicht, um der Fachkraft beim Formulieren oder Einordnen zu helfen.

Warum Maria nicht „Anonymisierung" verspricht

Maria ist keine magische Anonymisierung. EDN behauptet nicht, dass Re-Identifikation unmöglich ist, dass jedes Risiko ausgeschlossen ist, dass natürliche Sprache vollständig kontrollierbar ist, oder dass externe Modellanbieter risikofrei sind. Das wäre unehrlich.

Maria verfolgt einen anderen Anspruch: Datenflüsse werden kontrolliert. Klardaten werden reduziert. Sensible Details werden geschützt. Tool-Zugriffe laufen über EDN. Modellantworten werden geprüft. Fachkräfte behalten die finale Kontrolle. Technische und organisatorische Maßnahmen werden dokumentiert.

Das ist kein absolutes Sicherheitsversprechen. Es ist eine belastbare Schutzarchitektur.

Was aus Shield bleibt

Shield v0.3 war nicht falsch. Es war der erste Schritt. Aus Shield bleiben: Erkennung bekannter Klienten, Erkennung bekannter Kontakte, Schutz von Telefonnummern, E-Mails und Adressen, Erfahrung mit Pseudonymisierung, Tests und Fehlerfälle, und das Bewusstsein, dass Namen allein nicht das ganze Problem sind.

Was sich ändert: Die Datenbank wird wichtiger als Namenslisten. Die Namenstabelle wird nur noch ein schwaches Signal. Quasi-Identifikatoren werden explizit geprüft. Tool-Use wird Teil der Schutzarchitektur. Output wird genauso geprüft wie Input. Schutz wird pro Aufgabe entschieden, nicht pauschal. Maria ist also nicht einfach ein neuer Name für Shield. Maria ist Shield nach den Erfahrungen aus v0.3 und dem verworfenen Shield-v2-Experiment.

Was aus Shield v2 bleibt

Auch Shield v2 war nicht umsonst. Es hat gezeigt, dass reine Pseudonymisierung nicht die ganze Antwort ist. Es hat sichtbar gemacht, wie stark Kontext selbst identifizierend werden kann. Und es hat gezeigt, dass maximale Verschleierung mit fachlich wahrer Dokumentation in Konflikt geraten kann.

Die Idee der synthetischen Parallelwelt bleibt als Forschungspfad interessant. Vielleicht wird es später einen Spezialmodus geben, in dem isolierte Texte stärker verfremdet werden, etwa für bestimmte Freestyle- oder Hochschutz-Szenarien. Aber für SAJAs Kernworkflow gilt jetzt: nicht Märchenwelt, kontrollierte Arbeitsansicht.

Was ich daraus gelernt habe

Erstens: Listen sind keine Architektur. Eine Namensliste kann helfen. Aber sie versteht keinen Kontext. Sie weiß nicht, ob „Um" ein Name, ein Wort oder Teil einer Uhrzeit ist. Sie weiß nicht, ob „Nur" ein Vorname oder ein normales Wort ist. Sie kann nicht entscheiden, ob ein Satz fachlich, medizinisch oder organisatorisch relevant ist. Maria muss deshalb datenbankgestützt und kontextbewusst arbeiten.

Zweitens: Die stärkste Idee ist nicht immer die tragfähigste. Die synthetische Parallelwelt war radikal. Sie war spannend. Sie war theoretisch schön. Aber SAJA ist keine Demo, SAJA ist eine Fachanwendung. Fachanwendungen brauchen stabile Werkzeuge, stabile Datenflüsse und fachlich wahre Ergebnisse.

Drittens: Die ehrlichste Architektur ist die beste. Maria behauptet nicht, dass jedes Risiko verschwindet. Maria sagt: Wir zeigen dem Modell nicht die volle Fallrealität. Wir geben ihm eine kontrollierte Arbeitsansicht. Wir prüfen, was zurückkommt. Und wir dokumentieren, wie das passiert. Das ist weniger spektakulär als ein Märchen. Aber es ist ehrlicher. Und wahrscheinlich genau deshalb belastbarer.

Wo Maria heute steht

Maria ist ein technischer Prototyp und Architekturpfad innerhalb von EDN. Die nächsten Schritte sind: Integration in den SAJA-Kernworkflow, Ausbau des ersten Dokumentationsprofils, Absicherung der Tool Boundary, Output Governance für aktenrelevante Entwürfe, Golden Tests für bekannte Fehlerfälle, Datenschutzdokumentation für Pilotpartner und rechtliche Prüfung mit Datenschutzbeauftragten und Fachjuristen.

Maria ist noch nicht das Ende der Datenschutzfrage. Maria ist der Punkt, an dem EDN beginnt, KI-Verarbeitung nicht nur als Prompting-Problem zu behandeln, sondern als Plattformaufgabe.

Schluss

SAJA soll Fachkräfte entlasten. Dafür braucht SAJA Sprachmodelle. Aber Sprachmodelle dürfen nicht einfach unkontrolliert in sensible Fallrealitäten schauen. Maria ist die Antwort, die aus den ersten beiden Versuchen entstanden ist. Nicht als perfekte Anonymisierung. Nicht als Märchenwelt. Sondern als kontrollierte Arbeitsansicht innerhalb einer Plattform, die weiß, welche Daten sie schützt.