Automatisch geschwärzt? Vier Wege, auf denen personenbezogene Daten trotzdem beim Anbieter landen, kirchliche-ki.de

Jedes KI-Projekt in einem Träger kommt irgendwann an dieselbe Frage: Was passiert mit den Namen? Mit den Namen von Mitarbeitenden, Gemeindegliedern und Klienten, mit Geburtsdaten, Anschriften, Aktenzeichen, Diagnosen. Ohne eine belastbare Antwort darauf wird kein Vorhaben beschlossen, und die Antwort, die am häufigsten gegeben wird, lautet: Das System erkennt personenbezogene Daten selbst und entfernt sie, bevor irgendetwas an den Anbieter geht.

Vorgeführt wird das dann so. Jemand tippt einen Namen und ein Geburtsdatum in die Eingabezeile und drückt Enter. Daneben läuft die Aufzeichnung dessen, was das System tatsächlich an den Anbieter geschickt hat, und dort steht statt des Namens ein Platzhalter. Die Runde ist zufrieden, und im Sitzungsprotokoll steht, dass die Schwärzung geprüft wurde.

Gezeigt wurde damit ein Weg. Ein KI-Arbeitsplatz, der im Alltag eines Trägers tatsächlich nützlich ist, hat vier, und die Eingabezeile ist der einzige, den eine Vorführung bequem zeigen kann. Die anderen drei sind unauffälliger und tragen deutlich mehr personenbezogene Daten, allen voran die aus den eigenen Akten.

Diese Ausgabe beschreibt die vier Wege und schließt mit zehn Fragen, die sich einem Anbieter stellen und in eine Leistungsbeschreibung übernehmen lassen. Die Befunde stammen nicht aus Herstellerangaben, sondern aus dem Quelltext einer verbreiteten Software; die Belege dafür stehen am Ende in einem eigenen Abschnitt und sind für den Rest der Ausgabe nicht erforderlich.

Weg 1: was jemand tippt

Das ist der Weg aus der Vorführung, und hier stimmt sie. Die Eingabe geht durch eine Prüfstelle, bevor daraus eine Anfrage an das Modell wird. Was dort erkannt wird, kann ersetzt werden.

Bis hierhin ist alles in Ordnung. Der Fehler entsteht erst daraus, was aus diesem einen Beweis geschlossen wird.

Weg 2: was die eigenen Akten beisteuern

Der Grund, warum ein Träger überhaupt ein solches System einführt, ist selten die Eingabezeile. Es ist die Aussicht, dass die Software die eigenen Bestände kennt: Protokolle, Satzungen, Handbücher, Aktenvermerke, Vorgänge. Eine Frage in der Eingabezeile löst dann eine Suche in diesen Beständen aus, die Treffer werden an die Frage angehängt, und erst dieses Paket geht an das Modell.

Das Anhängen geschieht nach der Prüfung. Die Prüfstelle sieht die Frage, aber nicht die Antwortbausteine, die das System selbst dazulegt. Dasselbe gilt für Ergebnisse einer Websuche und für Rückgaben aus angebundenen Fachverfahren.

Das ist kein Versehen und auch kein Mangel eines einzelnen Herstellers. Die Reihenfolge hat einen guten Grund: Die Prüfstelle soll die Frage verändern können, bevor daraus eine Suchanfrage wird. Nur folgt daraus eben, dass sie den Rückweg nicht kontrolliert.

Das Ergebnis ist unangenehm klar. Der Bestand mit den meisten personenbezogenen Daten, nämlich die eigenen Akten, ist genau der, den eine Prüfung an der Eingabezeile grundsätzlich nicht erfasst.

Die Datenschutzkonferenz, das gemeinsame Gremium der staatlichen Datenschutzaufsichtsbehörden, beschreibt genau diesen Bauplan in einer Orientierungshilfe vom Oktober 2025 zu KI-Systemen, die auf eigene Dokumentenbestände zugreifen. Sie zieht daraus die richtige Konsequenz und verlangt die Bereinigung nicht an der Eingabe, sondern bei der Aufbereitung der Dokumente: „Soweit personenbezogene Daten nicht erforderlich sind, sind personenbezogene Daten zu entfernen oder zu anonymisieren.” Das steht dort an der Stelle, an der die Akten in Textabschnitte zerlegt werden, und nicht im Abschnitt über die Eingabe.

Weg 3: was das System nebenbei erledigt

Der Weg, den niemand für einen Modellaufruf hält, ist der Komfort. Eine moderne Oberfläche macht im Hintergrund eine Reihe kleiner Dinge, und jedes davon ist ein eigener Modellaufruf:

Sie gibt dem Gespräch eine Überschrift, damit es in der Liste wiederzufinden ist.
Sie schlägt Schlagworte vor.
Sie formuliert Folgefragen.
Sie leitet aus der Frage eine Suchanfrage ab.
Sie vervollständigt, was gerade getippt wird.

Diese Aufrufe laufen nicht über den Weg aus der Vorführung. Sie sind eigene Aufrufe an eigenen Stellen, und die im Haus eingerichtete Prüfstelle liegt nicht auf ihrer Strecke. Wer die Erkennung dort eingebaut hat, wo sie vorgeführt wird, hat die Überschrift des Gesprächs nicht abgedeckt. Und die Überschrift entsteht aus dem Inhalt der ersten Nachricht.

Am deutlichsten wird es bei der Vervollständigung. Sie greift auf den Text zu, der gerade im Eingabefeld steht, und schickt ihn an ein Modell, damit ein Vorschlag zurückkommt. Das geschieht, bevor jemand auf Senden gedrückt hat. Eine Prüfung, die am Senden hängt, kann diesen Aufruf konstruktionsbedingt nicht sehen.

Ein Gedankenexperiment, das in dieser Branche kein Gedankenexperiment bleibt: Jemand beginnt einen Satz über einen Personalvorgang, überlegt es sich anders und löscht ihn wieder. Abgeschickt wurde nichts. An ein Modell gegangen ist er trotzdem.

Weg 4: was schon beim Hochladen passiert

Der vierte Weg ist der folgenreichste, weil er dauerhaft ist. Damit ein System die eigenen Akten kennt, müssen diese Akten einmal eingelesen werden. Dabei geschehen zwei Dinge, die getrennt zu betrachten sind.

Erstens wird jeder Textabschnitt an ein zweites Modell übergeben. Dieses übersetzt ihn in eine lange Zahlenreihe, und mit diesen Zahlenreihen sucht die Software später, statt mit Wörtern. Ob dieses zweite Modell im eigenen Haus läuft oder bei einem Anbieter, ist eine Einstellung, und in den Voreinstellungen verbreiteter Software sind entfernte Anbieter zulässige Werte. Wo das so eingestellt ist, ist der Upload selbst bereits eine Übermittlung, und zwar eine, die stattfindet, lange bevor jemand eine Frage stellt.

Zweitens wird der Text im Klartext gespeichert. Der Suchindex ist keine verschlüsselte Ableitung, aus der sich nichts zurückgewinnen ließe, sondern eine zweite Volltextkopie des Bestands, die neben der Originaldatei liegt.

Daraus folgt etwas, das im Betrieb regelmäßig überrascht: Eine Nachbesserung wirkt nicht rückwärts. Wird die Erkennung ein halbes Jahr später verschärft oder ein Dokument nachträglich bereinigt, ändert das an den bereits eingelesenen Abschnitten nichts. Sie bleiben stehen, sie werden weiter gefunden, und sie werden weiter an das Modell geschickt. Wer den Index bereinigen will, muss ihn neu aufbauen, und das ist eine Aufgabe mit Aufwand und Termin, keine Einstellung.

Die Datenschutzkonferenz behandelt den Suchindex konsequenterweise als eigenen Bestand, an dem Betroffenenrechte bestehen, ausdrücklich neben Eingabe, Ausgabe und Referenzdokumenten.

Wo eine Prüfung stehen müsste

Vier Wege lassen sich nicht sinnvoll mit vier Prüfstellen absichern, denn die nächste Programmversion bringt einen fünften. Es gibt aber zwei Stellen, an denen alles zusammenläuft, und beide liegen nicht in der Oberfläche, sondern an der Grenze zum Anbieter.

Die erste Tür ist die zum Sprachmodell. Jeder der vier Wege endet dort, ob als getippte Frage, als Überschrift, als Vervollständigung oder als angereichertes Paket aus Frage und Aktenausschnitten. Wer an dieser Tür prüft, sieht ausnahmslos alles, was das Haus in Richtung Modell verlässt.

Die zweite Tür sieht kaum jemand. Das Einlesen der Akten endet nicht am Sprachmodell, sondern an dem zweiten Modell, das die Zahlenreihen berechnet. Wer nur die erste Tür absichert, lässt den gesamten Aufbau des Aktenindex ungeprüft.

Diese Verschiebung von der Eingabemaske zur Tür ist der eigentliche Befund. Sie hat einen ehrlichen Preis, der genannt gehört: An der Tür kommt ein fertig zusammengesetztes Paket an, und es ist dort nicht mehr zu erkennen, welcher Teil aus der Tastatur und welcher aus der Akte stammt. Unterschiedlich streng zu behandeln, was unterschiedlich sensibel ist, wird damit schwerer.

Und der Index bleibt außen vor. Er verlässt das Haus nie, er ist trotzdem ein Bestand. Für ihn ist die Bereinigung vor dem Einlesen die einzige Maßnahme, die wirkt. Nach § 9 Absatz 2 KDG-DVO ist bei der Einordnung von Daten in eine Datenschutzklasse ausdrücklich auch der Zusammenhang mit anderen gespeicherten Daten zu berücksichtigen. Genau diesen Zusammenhang stellt ein Suchindex her, der Textabschnitte aus verschiedenen Akten in einem Bestand zusammenführt.

Was eine Schwärzung rechtlich leistet und was nicht

Hier lohnt Genauigkeit, weil in Angeboten regelmäßig zu viel behauptet wird.

Das katholische Recht unterscheidet zwei Dinge, die im Sprachgebrauch verschwimmen. Pseudonymisierung ist nach § 4 Nummer 6 KDG die Verarbeitung so, dass die Daten „ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können, sofern diese zusätzlichen Informationen gesondert aufbewahrt werden”. Anonymisierung ist nach § 4 Nummer 7 die Verarbeitung derart, dass eine Zuordnung „nicht mehr oder nur mit einem unverhältnismäßig großen Aufwand an Zeit, Kosten und Arbeitskraft” möglich ist.

Eine Schwärzung erzeugt fast immer das Erste. Die zusätzliche Information, also das Originaldokument und die Zuordnung, bleibt im Haus, sonst wäre das System unbrauchbar. Damit bleiben die Daten personenbezogen, und die Verarbeitung bleibt vollständig im Anwendungsbereich des Datenschutzrechts. Daraus folgen drei nüchterne Sätze:

Eine Schwärzung ist eine Schutzmaßnahme, keine Rechtsgrundlage. § 26 Absatz 1 Buchstabe a KDG nennt Pseudonymisierung, Anonymisierung und Verschlüsselung ausdrücklich als technische und organisatorische Maßnahmen. Als solche ist sie nützlich und häufig geboten. Sie ersetzt aber keine Befugnis zur Verarbeitung.
Eine Schwärzung senkt keine Datenschutzklasse. Die Einordnung nimmt nach § 9 KDG-DVO der Verantwortliche vor. Eine abweichende Einordnung ist nach Absatz 4 zu begründen und zu dokumentieren, und eine Einordnung in eine niedrigere Klasse setzt die vorherige Anhörung der oder des betrieblichen Datenschutzbeauftragten voraus. Unterbleibt eine Einordnung ganz, gilt nach Absatz 5 automatisch die Klasse III.
Eine Schwärzung beseitigt die Übermittlung nicht. § 12 Absatz 2 Buchstabe e KDG-DVO rechnet Übermittlungen „auch über automatisierte Schnittstellen” ausdrücklich mit und verlangt für sie außerhalb geschlossener Netze Verschlüsselung nach dem Stand der Technik. Was übermittelt wird, bestimmt die Schwärzung. Dass übermittelt wird, nicht.

Umgekehrt ist sie auch nicht folgenlos, und das ist die Seite, die in Diskussionen gern untergeht. § 7 Absatz 1 Buchstabe c KDG verlangt unter der Überschrift Datenminimierung, personenbezogene Daten „zu anonymisieren oder zu pseudonymisieren, soweit dies nach dem Verwendungszweck möglich ist und der Aufwand nicht außer Verhältnis zum angestrebten Schutzzweck steht”. Wo eine Vorfilterung technisch zur Verfügung steht und die Aufgabe sie zulässt, ist ihr Weglassen begründungsbedürftig. Die Vorschrift verlangt sie nur nicht dort, wo sie vorgeführt wird, sondern dort, wo die Daten tatsächlich fließen.

Im evangelischen Bereich ist die Lage inhaltlich gleich und im Maßstab anders. Die Begriffe stehen wortgleich in § 4 Nummern 6 und 7 DSG-EKD, die Datenminimierung in § 5 Nummer 3, die Schutzmaßnahmen in § 27. Es gibt dort aber keine Datenschutzklassen mit festen Mindestmaßnahmen, sondern eine reine Risikobetrachtung, die in § 27 Absatz 3 ausdrücklich die Verhältnismäßigkeit aufnimmt. Das gibt mehr Spielraum bei der Wahl der Maßnahme und weniger Rückhalt, wenn später zu begründen ist, warum die gewählte Maßnahme genügte. Die Frage nach dem Weg stellt sich unverändert, sie beantwortet sich nur nicht über eine Klassentabelle, sondern über die eigene Risikoanalyse.

Was die Erkennung selbst leisten kann

Über der Frage nach dem Weg wird leicht übersehen, wie gut eine Erkennung überhaupt sein kann. Die Antwort zerfällt in zwei Teile.

Wo Daten ein festes Format haben, ist die Erkennung stark. IBAN, Steuernummer, Versichertennummer, Telefonnummer, E-Mail-Adresse und Aktenzeichen mit fester Syntax werden zuverlässig gefunden, und die Fehler gehen dabei überwiegend in die harmlosere Richtung, also zu viel statt zu wenig.

Namen haben kein Format. Sie werden von einem Modell erkannt, das an Beispieltexten gelernt hat, und das ist eine Schätzung mit Fehlerquote. Die veröffentlichten Werte für deutsche Texte liegen bei guten Modellen im Bereich von acht Prozent Fehlern, gemessen allerdings an Zeitungstexten. Aktenvermerke, Protokolle, Pflegedokumentation und eingescannte Schreiben sind schwerer: Namen im Genitiv, Abkürzungen, Kürzel statt Namen, Zeilenumbrüche mitten im Wort, Erkennungsfehler aus dem Scan. Der veröffentlichte Wert ist also eine Obergrenze für leichteres Material, nicht eine Zusage für das eigene.

Die Hersteller sagen das, wenn man nachliest. Microsoft schreibt in die Projektbeschreibung seines verbreiteten Erkennungswerkzeugs eine ausdrückliche Warnung: „because it is using automated detection mechanisms, there is no guarantee that Presidio will find all sensitive information. Consequently, additional systems and protections should be employed.” Ein Anbieter, der diese Einschränkung nicht von sich aus nennt, hat sie entweder nicht gelesen oder verspricht mehr, als er hat.

Bleibt die Kategorie, die keine Erkennung je abdecken wird: die identifizierende Kombination ohne Namen. Eine Anfrage, die eine Funktion, einen Ort, einen Zeitraum und einen Sachverhalt nennt, kann eine Person eindeutig bezeichnen, ohne ein einziges Merkmal zu enthalten, das ein Filter als Merkmal erkennen könnte. In einer Kirchengemeinde mit einer Handvoll Hauptamtlicher ist das kein Randfall, sondern der Normalfall.

Zehn Fragen an den Anbieter

Die folgenden Fragen sind so formuliert, dass sie sich in eine Leistungsbeschreibung oder in die Anlage zum Auftragsverarbeitungsvertrag übernehmen lassen. Sie sind produktunabhängig, und sie sind mit Nachweisen zu beantworten, nicht mit einer Vorführung.

An welcher Stelle steht die Erkennung? Verlangt wird eine Darstellung des Wegs vom Eingabefeld bis zum Anbieter, nicht eine Produktaussage. Die brauchbare Antwort nennt eine Tür zum Anbieter. Die schwache Antwort nennt eine Eingabemaske.
Welche Aufrufe gehen an ihr vorbei? Ausdrücklich abzufragen sind Gesprächsüberschrift, Schlagworte, Folgefragen, abgeleitete Suchanfragen und die Vervollständigung während des Tippens.
Gilt sie auch beim Einlesen von Dokumenten? Wenn nicht: Läuft das zweite Modell, das die Akten für die Suche aufbereitet, nachweislich im eigenen Haus, oder geht der Klartext an einen Anbieter?
Was geschieht mit Treffern aus den eigenen Akten, aus Fachverfahren und aus der Websuche? Werden sie geprüft, bevor sie an die Frage angehängt werden, danach oder gar nicht?
Was steht im Suchindex? Liegt der Text der Abschnitte dort im Klartext, und wie wird er entfernt, wenn das zugehörige Dokument gelöscht wird?
Wirkt eine Nachbesserung rückwirkend? Wenn die Erkennung verschärft wird, was geschieht mit dem bereits aufgebauten Index? Gibt es einen Neuaufbau, wer führt ihn durch, und was kostet er?
Welche Kategorien werden erkannt und welche nicht? Verlangt wird eine Liste, kein Sammelbegriff, und dazu die Aussage, was mit identifizierenden Kombinationen ohne Namen geschieht.
Welche Trefferquote wird zugesagt, gemessen woran? Ein Wert ohne Datengrundlage ist keine Zusage. Sinnvoll ist eine Messung an eigenem Material, mit getrennter Angabe für formatgebundene Daten und für Namen.
Was passiert bei einem Treffer? Ersetzen, blockieren, protokollieren oder melden? Und wenn protokolliert wird: Steht der erkannte Wert dann im Protokoll, und wer sieht dieses Protokoll?
Wo ist das alles dokumentiert? Die Antworten gehören in die Anlage über die technischen und organisatorischen Maßnahmen. Nur dann sind sie später Gegenstand der Pflicht aus § 9 Absatz 7 KDG-DVO, sich vom Schutzniveau eines Auftragsverarbeiters zu überzeugen, und zwar durch persönliche Überprüfung oder durch Vorlage von Nachweisen.

Die zehnte Frage zeigt am schnellsten, wie belastbar die ersten neun beantwortet wurden. Eine Zusicherung, die nicht in die Vertragsanlage geschrieben werden soll, war eine Broschürenaussage.

Belege im Quelltext

Dieser Abschnitt weist die vier Wege an einem konkreten System nach. Er ist für den Rest der Ausgabe nicht erforderlich.

Geprüft wurde Open WebUI in der Fassung v0.11.0. Die Software ist quelloffen und die verbreitete Oberfläche hinter einem großen Teil der selbst betriebenen und EU-gehosteten KI-Arbeitsplätze. Das Muster ist damit nicht bewiesenermaßen produktunabhängig, aber jede Oberfläche mit Dateien, Wissenssammlungen, Websuche und Werkzeugen hat dieselbe Bauform, und die Prüffragen oben lassen sich an jede stellen.

Zu Weg 1 und 2. Eine abgeschickte Chatanfrage läuft durch process_chat_payload in backend/open_webui/utils/middleware.py. Dort werden zuerst die externen Pipelines und dann die im Haus geschriebenen Filterfunktionen mit filter_type='inlet' aufgerufen (um Zeile 2517). Erst danach folgen im selben Ablauf die Websuche (chat_web_search_handler, um Zeile 2554), die Werkzeuge (chat_completion_tools_handler, um Zeile 2917) und die Dateiverarbeitung mit dem Retrieval (chat_completion_files_handler, um Zeile 2929). Deren Ergebnisse werden anschließend über apply_source_context_to_messages in die Nachrichtenliste geschrieben (um Zeile 2954). Der Filter läuft also nachweislich vor der Anreicherung.

Zu Weg 3. Die Nebenaufgaben liegen in backend/open_webui/routers/tasks.py in acht eigenen Endpunkten: generate_title, generate_follow_ups, generate_chat_tags, generate_image_prompt, generate_queries, generate_autocompletion, generate_emoji und generate_moa_response. Jeder baut eine eigene Nutzlast, ruft process_pipeline_inlet_filter auf und übergibt direkt an generate_chat_completion. Der Unterschied ist entscheidend: Diese Endpunkte laufen durch die Pipelines, also durch extern betriebene Filter, aber nicht durch process_chat_payload und damit nicht durch die im Haus geschriebenen Filterfunktionen. In backend/open_webui/utils/chat.py ruft generate_chat_completion an keiner Stelle process_filter_functions mit filter_type='inlet' auf. Das dort vorhandene Kennzeichen bypass_filter betrifft die Zugriffskontrolle auf Modelle und nicht die Filterkette; die Namensähnlichkeit ist irreführend.

Wer eine Erkennung als Filterfunktion in der Oberfläche einrichtet, was der naheliegende und dokumentierte Weg ist, deckt diese acht Aufrufe also nicht ab. Wer stattdessen eine externe Pipeline betreibt, deckt sie ab. Diese Unterscheidung ist der Kern von Weg 3 und in Angeboten fast nie explizit.

Die Vervollständigung nimmt in generate_autocompletion ein Feld prompt entgegen, also den aktuellen Stand des Eingabefelds. Aufgerufen wird sie aus der Eingabekomponente selbst: In src/lib/components/common/RichTextInput.svelte wird generateAutoCompletion(text) mit dem gerade vorhandenen Text aufgerufen, verdrahtet in src/lib/components/chat/MessageInput.svelte.

Zu Weg 4. Ein Upload läuft über backend/open_webui/routers/files.py in process_file und save_docs_to_vector_db in backend/open_webui/routers/retrieval.py. In diesen Dateien gibt es keinen Aufruf der Filterkette. Der Abschnittstext wird im Klartext an die Einbettungsfunktion übergeben; welches Modell das ist, entscheidet die Einstellung RAG_EMBEDDING_ENGINE, deren zulässige Werte neben lokalen Modellen ausdrücklich openai, ollama und azure_openai umfassen. Der in die Vektordatenbank geschriebene Datensatz besteht aus einer Kennung, dem Feld text mit dem unveränderten Abschnitt, dem Vektor und den Metadaten.

Grenze dieser Prüfung. Die Befunde sind aus dem Quelltext hergeleitet, nicht an einer laufenden Installation gemessen. Für die Beschaffung ist das der schwächere von zwei möglichen Nachweisen. Die belastbare Prüfung besteht darin, im eigenen System eine Filterfunktion einzurichten, die jeden Aufruf protokolliert, und anschließend eine Datei hochzuladen, ein Gespräch zu beginnen und dabei die Zeilen zu zählen. Frage 2 des Prüfrasters lässt sich auf diesem Weg selbst beantworten, ohne den Anbieter zu fragen.

Quellen

Alle Quellen am 19. August 2026 an der Primärquelle geprüft. Der Quelltext wurde am Versions-Tag v0.11.0 über das Rohdatei-Verzeichnis von GitHub geladen, da die Dokumentationsseite automatisierte Abrufe abweist. Die Zeilenangaben beziehen sich auf diesen Stand und verschieben sich mit jeder Version; die Funktionsnamen sind der stabilere Anker. Die kirchlichen Vorschriften liegen in amtlichen Lesefassungen vor, die Inkraftsetzung der KDG-Novelle erfolgt diözesan und das Datum kann je Bistum abweichen.

Open WebUI v0.11.0, backend/open_webui/utils/middleware.py, für die Reihenfolge in process_chat_payload: raw.githubusercontent.com
Open WebUI v0.11.0, backend/open_webui/routers/tasks.py, für die acht Nebenaufgaben-Endpunkte und ihren Aufruf von process_pipeline_inlet_filter: raw.githubusercontent.com
Open WebUI v0.11.0, backend/open_webui/utils/chat.py, für generate_chat_completion und die Bedeutung von bypass_filter: raw.githubusercontent.com
Open WebUI v0.11.0, backend/open_webui/routers/retrieval.py, für save_docs_to_vector_db und die zulässigen Werte von RAG_EMBEDDING_ENGINE: raw.githubusercontent.com
Open WebUI v0.11.0, src/lib/components/common/RichTextInput.svelte, für den Aufruf von generateAutoCompletion aus der Eingabekomponente: raw.githubusercontent.com
Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder, „Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode”, Version 1.0, Stand Oktober 2025, für die Bereinigung bei der Datenaufbereitung (Abschnitt 3.1) und die Betroffenenrechte an der Vektordatenbank (Abschnitt 3.7): datenschutzkonferenz-online.de (PDF)
Gesetz über den Kirchlichen Datenschutz (KDG) in der Fassung des Beschlusses der Vollversammlung des Verbandes der Diözesen Deutschlands vom 24. November 2025, für § 4 Nummern 6 und 7, § 7 Absatz 1 Buchstabe c und § 26 Absatz 1 Buchstabe a: dbk.de (Lesefassung, PDF)
Durchführungsverordnung zum Gesetz über den Kirchlichen Datenschutz (KDG-DVO) vom 10. Januar 2019, geändert am 20. Januar 2026, amtliche Lesefassung des Erzbistums Hamburg, für § 9 Absätze 2, 4, 5 und 7 sowie § 12 Absatz 2 Buchstabe e: erzbistum-hamburg.de (PDF)
Verordnung zur Änderung der KDG-DVO aufgrund des Beschlusses der Vollversammlung des Verbandes der Diözesen Deutschlands vom 24. November 2025, Anlage zum Amtsblatt des Erzbistums Berlin 03/2026, in Kraft zum 1. März 2026. Geprüft wurden dort Ziffer 9 (Neufassung des § 9, inhaltlich unverändert gegenüber der zitierten Lesefassung) und Ziffer 12 (Änderung des § 12, die Buchstabe e nicht berührt): erzbistumberlin.de (PDF)
Kirchengesetz über den Datenschutz der Evangelischen Kirche in Deutschland (DSG-EKD) in der Bekanntgabe der Neufassung vom 15. Januar 2025 (ABl. EKD S. 1), für § 4 Nummern 6 und 7, § 5 Nummer 3 und § 27: kirchenrecht-ekm.de
Microsoft, Presidio, Projektbeschreibung im Quellrepository, für die Einschränkung „there is no guarantee that Presidio will find all sensitive information”: github.com/microsoft/presidio
Modellkarte flair/ner-german-large, für den zitierten Bereich der Fehlerquote (F1 92,31 auf CoNLL-03 German revised, einem Zeitungskorpus): huggingface.co