Maria by EDN
Die Datenschutzschicht für KI in der Sozialen Arbeit.
Maria sitzt zwischen SAJA und einem Spitzen-KI-Modell und entscheidet pro Aufgabe, was das Modell überhaupt sehen darf, und was in EDN bleibt.
Die zwei üblichen Antworten reichen nicht.
Wer KI in der Sozialen Arbeit einsetzen will, hört zwei Antworten. Beide klingen vernünftig. Beide haben in der Praxis Schwächen, die sich nicht wegerklären lassen.
Lokales Modell
„Wenn das Modell auf eigener Hardware läuft, ist alles sicher."
In der Praxis bedeutet das: schwächere Qualität, höhere Kosten, ständige Wartung, und am Ende eine Fachassistenz, die der Fachkraft nicht hilft.
Cloud-Modell mit Pseudonymisierung
„Ein großes Cloud-Modell, dazu Auftragsverarbeitungsverträge und Pseudonymisierung der Namen."
Hält juristisch nicht überall stand und schützt fachlich kaum. Pseudonymisierte Namen bleiben Teil eines Falls, der durch viele andere Merkmale identifizierbar ist.
Wir haben eine dritte Antwort gebaut. Sie heißt Maria.
Maria ist die Datenschutzschicht von EDN.
SAJA ist die KI-Fachassistenz für die stationäre Jugendhilfe. EDN ist die Plattform, auf der SAJA läuft.
Maria ist die Schicht zwischen SAJA und einem externen KI-Modell. Sie entscheidet pro Aufgabe, welche Informationen das Modell überhaupt sehen darf, kontrolliert, mit welchen Daten das Modell auf Tools zugreift, und prüft, was das Modell zurückgibt, bevor die Fachkraft es liest.
Maria ist nicht das Versprechen, dass jedes Risiko verschwindet. Maria ist das Versprechen, dass personenbezogene Daten die Plattform nicht unkontrolliert verlassen.
SAJA arbeitet. Maria schützt.
Vier Schutzwirkungen.
Maria ist mehr als das Ersetzen von Namen. Sie wirkt in vier Schichten gleichzeitig.
Kontrollierte Datenflüsse
Maria entscheidet pro Aufgabe, welche Daten das externe Modell überhaupt sehen darf. Klarnamen werden zu Arbeitsreferenzen, Diagnosen zu Klassen, konkrete Orte zu Regionen. Was nicht gebraucht wird, verlässt die Plattform nicht.
Tool Boundary
Wenn das Modell auf Daten zugreifen will, läuft der Zugriff über EDN, nicht über das Modell. Tools arbeiten mit geschützten Referenzen, nicht mit Klarnamen. Echte Datenbankoperationen bleiben innerhalb der Plattform.
Output Governance
Maria prüft jede Modellantwort, bevor sie zur Fachkraft geht. Halluzinationen, erfundene Klarnamen, pädagogische Bewertungen oder Handlungsempfehlungen werden erkannt und blockiert oder zur Regenerierung zurückgegeben.
Risiko-Bewertung von Merkmals-Kombinationen
Nicht nur einzelne Namen sind identifizierend. Die Kombination aus Alter, Stadtteil, Diagnose und Schule kann ein Kind eindeutig machen, auch ohne Namen. Maria erkennt solche Konstellationen und generalisiert oder unterdrückt sie.
Wie Maria arbeitet.
Vereinfachte Architektur, ohne Marketing-Vereinfachung.
Wenn die Fachkraft mit SAJA arbeitet, läuft jede Anfrage an ein externes Modell durch Maria. Maria erzeugt eine Arbeitsansicht, in der personenbezogene Daten durch geschützte Referenzen ersetzt sind. Tool-Aufrufe vom Modell laufen zurück über Maria und werden gefiltert, bevor das Modell sie weiterverarbeitet. Modellantworten werden erneut durch Maria geprüft, bevor sie der Fachkraft angezeigt werden.
Das gesamte Verfahren ist auditierbar, mandantengetrennt und folgt einem definierten Operating Model, das wir D-POM nennen.
Mehr zu D-POM →Ein konkretes Beispiel.
Eine Fachkraft schreibt eine Verlaufsnotiz. SAJA hilft beim Formulieren. Was sieht das externe KI-Modell?
Was die Fachkraft schreibt
Lina hat heute Morgen das Frühstück verweigert. Um 10 Uhr hat sie heimlich Kekse von ihrer Großmutter gegessen. Sie nimmt aktuell Ritalin und ist in der Grundschule am Stadtteilrand.
Was das externe Modell sieht
[KLIENT_A] hat heute Morgen das Frühstück verweigert. Am Vormittag hat [KLIENT_A] heimlich Süßigkeiten von [BEZUGSPERSON_A] gegessen. Aktuelle Medikation: [MEDIKATION_KLASSE_A]. Schulkontext: [SCHULE_REGION_A].
In diesem Beispiel sind sieben Schutzwirkungen gleichzeitig aktiv:
- Klarname Lina wird zur Arbeitsreferenz [KLIENT_A].
- Bezugsperson Großmutter wird zur Arbeitsreferenz [BEZUGSPERSON_A].
- Konkretes Medikament wird zur Klasse, weil das Modell die exakte Bezeichnung für die Doku-Hilfe nicht braucht.
- Konkrete Schule wird zur Region, weil die Schule selbst kein fachliches Detail ist.
- Die exakte Uhrzeit wird zu „am Vormittag", weil eine Minutenangabe in dieser Notiz nicht aktenrelevant ist.
- Die Referenzen sind innerhalb dieses Arbeitskontexts stabil, aber nicht global gültig: in einem anderen Fall, einem anderen Mandanten oder am nächsten Tag werden neue Referenzen vergeben.
- Die Modellantwort wird vor der Anzeige geprüft. Wenn das Modell einen Klarnamen erfindet, wird die Antwort blockiert oder neu generiert.
Hinter Maria
D-POM. Data Protection Operating Model.
Maria ist die technische Komponente. D-POM ist die Strategie dahinter.
D-POM ist nicht Pseudonymisierung mit anderem Namen.
Pseudonymisierung ersetzt Klarnamen durch Platzhalter und liefert den Rest unverändert. D-POM ist mehr: ein Verfahren, das vor jedem Modellaufruf entscheidet, welche Datenklassen erlaubt sind, welche Tools verwendet werden dürfen, welche Generalisierung anliegt, und welche Antworten überhaupt zurückgegeben werden.
D-POM ist sektorspezifisch für die Soziale Arbeit.
Allgemeine Datenschutz-Werkzeuge sind für E-Commerce, Werbung oder Healthcare gebaut. Sie kennen die Strukturen der Sozialen Arbeit nicht, weder das Vokabular der Jugendhilfe noch die Logik von Hilfeplanung, ASD-Kontakten oder § 8a-Verfahren. D-POM ist auf diese Strukturen zugeschnitten.
D-POM ist technisch und organisatorisch.
Ein Schutzverfahren, das nur in Code lebt, ist nicht prüfbar. D-POM verbindet technische Maßnahmen mit dokumentierten Prozessen, Auftragsverarbeitungsverträgen, technischen und organisatorischen Maßnahmen sowie auditierbaren Logs.
Für Datenschutzbeauftragte und IT-Verantwortliche
Was Sie konkret prüfen können.
Diese Sektion geht in die technische Tiefe. Sie ist für DSB, IT-Leitungen und externe Prüfer geschrieben, nicht für Fachkräfte.
Trust Boundary
EDN ist die Trust Boundary. Datenbank, Mandantentrennung, Rollen und Tools liegen innerhalb. Externe Modelle liegen außerhalb. Maria ist die Schicht, an der entschieden wird, was nach außen darf.
Kontextlokale Arbeitsreferenzen
Maria erzeugt pro Aufgabe einen Arbeitskontext. Innerhalb dieses Kontexts sind Referenzen wie [KLIENT_A] stabil, damit Mehrturn-Gespräche kohärent bleiben. Über Aufgaben, Mandanten und Sessions hinweg sind die Referenzen nicht stabil. Damit wird ein neues Korrelationsrisiko vermieden, das globale Pseudonymisierungstabellen mit sich bringen würden.
Tool Boundary
Tool-Aufrufe vom Modell durchlaufen Maria. Das Modell sieht keine DB-IDs und keine Klarnamen, sondern nur Referenzen und Kategorien. Die echte Datenbankoperation läuft in EDN. Tool-Ergebnisse werden gefiltert, bevor das Modell sie weiterverarbeitet.
Output Governance
Modellantworten durchlaufen eine Pipeline aus Schema-Validierung, Referenz-Prüfung, Erkennung erfundener Namen, Risiko-Bewertung von Merkmals-Kombinationen, Erkennung pädagogischer Empfehlungen und deterministischer Rehydration nur für explizite Referenzen. Aktionen reichen von „passieren lassen“ über „warnen“ bis „blocken oder regenerieren“.
Quasi-Identifier Risk Pass
Maria bewertet nicht nur einzelne Merkmale, sondern Kombinationen. Alter, Stadtteil, seltene Diagnose und konkrete Schule können ein Kind auch ohne Namen identifizierbar machen. Der Risk Pass markiert solche Konstellationen, generalisiert oder unterdrückt einzelne Merkmale, oder fordert eine Fachkraft-Bestätigung.
Provider und Datenstandort
EDN ist Provider-unabhängig gebaut. Im Entwicklungs- und MVP-Stand arbeitet EDN mit der OpenAI API mit dokumentierter Nicht-Trainings-Konfiguration. Für Pilot- und Produktionsbetrieb unter strikten EU-Anforderungen ist Azure OpenAI in einer DataZone EU vorgesehen. Welcher Provider in einem konkreten Deployment genutzt wird, ist in einer Architecture Decision Record (ADR) dokumentiert und vertraglich abgebildet.
Logging und Audit
Logs enthalten keine Rohtexte und keine Rehydration-Mappings. Logging ist auf strukturierte Ereignisse beschränkt: welche Schutzentscheidung getroffen wurde, welche Risiko-Klasse erkannt wurde, welche Aktion ausgelöst wurde. Damit bleibt Maria auditierbar, ohne selbst zur Datensenke zu werden.
Beispielhafter Audit-Log-Eintrag
Eine ausführliche TOM-Dokumentation und ein DSFA-Baustein sind in Vorbereitung und auf Anfrage verfügbar.
Was wir nicht behaupten.
Datenschutz-Marketing neigt zu Versprechen, die im Detail nicht halten. Wir machen es anders.
Wir behaupten nicht
- Re-Identifikation ist unmöglich.
- Anonymisierung im juristischen Sinn liegt vor.
- Jeder Edge Case ist abgedeckt.
- Externe Modellanbieter bergen kein Risiko.
- Maria ist eine vollständige DSGVO-Konformitätsgarantie.
Wir behaupten und belegen
- Personenbezogene Klardaten verlassen die Plattform nicht unkontrolliert.
- Tool-Zugriffe laufen über EDN.
- Modellantworten werden geprüft.
- Technische und organisatorische Maßnahmen sind dokumentiert.
- Risiken werden reduziert, klassifiziert und auditierbar gemacht.
Häufige Fragen.
Pseudonymisierung ersetzt Namen durch Platzhalter und gibt den Rest unverändert weiter. Maria ist eine vollständige Sicht-Steuerung. Sie entscheidet pro Aufgabe, welche Datenklassen das Modell sehen darf, welche Tools es nutzen darf, welche Antworten es geben darf, und in welcher Detailtiefe. Pseudonymisierung ist ein Schritt von vielen.
Maria ist Provider-unabhängig. Der konkrete Modellanbieter wird pro Deployment festgelegt und dokumentiert. Für Entwicklungs- und MVP-Zwecke arbeitet EDN aktuell mit der OpenAI API in Nicht-Trainings-Konfiguration. Für Pilot- und Produktionsbetriebe unter strikten EU-Anforderungen ist Azure OpenAI in einer DataZone EU vorgesehen.
Die EDN-Plattform läuft auf europäischen Servern. Welche Daten welchem Modellanbieter unter welchen vertraglichen Bedingungen sichtbar sind, ist im jeweiligen Deployment dokumentiert. Maria sorgt zusätzlich dafür, dass nur eine kontrollierte Arbeitsansicht das Modell erreicht, nicht die Rohdaten.
Datenschutz ist kein Schalter, der umgelegt wird, sondern ein Prozess. Maria reduziert Risiken technisch und organisatorisch, folgt den Grundsätzen der Datenminimierung und der Zweckbindung, und stellt für jede Verarbeitung dokumentierbare Schutzmaßnahmen bereit. Ob ein konkreter Einsatz im jeweiligen Trägerkontext zulässig ist, klären Sie mit Ihrer oder Ihrem Datenschutzbeauftragten. Wir liefern dafür eine Technical-and-Organizational-Measures-Dokumentation und einen DSFA-Baustein, beides in Vorbereitung.
KDG und DSG-EKD haben mit der DSGVO eine Überlappung von über 95 Prozent. Marias Architektur erfüllt die zentralen Anforderungen aller drei Regelwerke. Spezifische Anforderungen einzelner Träger werden im Pilot-Setup geklärt.
Maria ist eine Architektur-Komponente von EDN, nicht ein eigenständiges API-Produkt. Wer EDN als Plattform nutzt, profitiert automatisch von Maria. Ein Standalone-Vertrieb von Maria außerhalb der EDN-Plattform ist aktuell nicht vorgesehen.
Maria prüft jede Modellantwort vor der Anzeige. Wenn das Modell einen Klarnamen erfindet, der nicht aus den Daten kommt, oder eine Referenz produziert, die in der aktuellen Aufgabe nicht existiert, wird die Antwort blockiert oder zur Regenerierung zurückgegeben. Pädagogische Bewertungen und Handlungsempfehlungen werden ebenfalls erkannt und blockiert, weil das nicht die Aufgabe von SAJA ist.
Wir richten ein Test-Setup mit Beispiel-Daten ein, in dem Sie und Ihre oder Ihr Datenschutzbeauftragte Maria gegen Ihre eigenen Anforderungen prüfen können. Schreiben Sie uns kurz, welcher Trägerkontext und welche Anwendungsbereiche relevant sind.
Sie wollen Maria im eigenen Trägerkontext prüfen?
Wir öffnen aktuell ein begrenztes Pilot-Programm für freie und öffentliche Träger der Jugendhilfe sowie für Jugendämter.