# kirchliche-ki.de, Gesamtausgabe für KI-Systeme > Alle Newsletter-Ausgaben in voller Länge. Kontext und Zitierhinweise: /llms.txt und /fuer-ki/. Fachinformation, keine Rechtsberatung. Autor: Nils Peters. --- # Sonderausgabe: Zwei Zeilen Sicherheitsmaßnahmen sind keine vereinbarten Maßnahmen > In jeder Dienstvereinbarung über ein KI-System steht ein Abschnitt zu den Sicherheitsmaßnahmen, und er besteht fast immer aus Überschriften. Diese Ausgabe füllt ihn aus: 25 Prüfpositionen für beide Rechtskreise, mit Nachweis und Fundstelle, kostenlos und als PDF. Kanonische URL: https://kirchliche-ki.de/newsletter/sonderausgabe-anlage-tom-ki/ · Veröffentlicht: 2026-09-16 Am 12. August erschien hier ein Muster für eine Dienstvereinbarung über den Einsatz KI-gestützter Systeme, am 1. September die katholische Fassung dazu. Beide führen in der Anlage zur Systembeschreibung einen Punkt „Sicherheitsmaßnahmen" auf und beschreiben ihn in zwei Zeilen: Authentifizierung, Trennung der Nutzerbereiche, Verschlüsselung, Sicherung, Löschverfahren. Als Gliederungspunkt ist das richtig. Als Arbeitsgrundlage ist es zu wenig. Wer eine Dienstvereinbarung unterschreibt, in der dieser Punkt aus zwei Zeilen besteht, hat die Maßnahmen nicht vereinbart, sondern nur ihre Überschriften. Fragt später jemand nach, steht in der Vereinbarung nichts, woran sich eine Antwort messen ließe. Diese Ausgabe füllt diesen einen Abschnitt aus, mit einem Prüfraster aus 25 Positionen für beide Rechtskreise. **[Anlage 2: Technische und organisatorische Maßnahmen für KI-Systeme](/anlage-tom-ki/)** Neun Seiten, 25 Prüfpositionen, je Position der verlangte Nachweis und die Fundstelle im katholischen wie im evangelischen Recht. [PDF direkt herunterladen](/muster/anlage-tom-ki-v1-0.pdf) · kostenlos, frei verwendbar, anpassbar und weitergebbar, mit Quellenangabe. Wer nur das Dokument braucht, ist hier fertig. Der Rest dieser Ausgabe begründet es und nennt die Stellen, an denen solche Prüfungen regelmäßig auseinanderfallen. Es ist zugleich die Einlösung eines Verweises: Die Ausgabe vom 20. August endete mit zehn Fragen an einen Anbieter und dem Satz, die Antworten gehörten in die Anlage über die technischen und organisatorischen Maßnahmen. Diese Anlage gab es damals nicht. Jetzt gibt es sie. ## Die Pflichtfrage Sie lautet nicht: Welche Sicherheitsmaßnahmen hat unser Anbieter? Sondern: **Woran lässt sich überprüfen, dass die Maßnahmen, die wir vereinbart haben, in der laufenden Installation auch wirken?** Beide Kirchen verlangen die Antwort, und zwar vom Verantwortlichen, nicht vom Anbieter. Im katholischen Bereich steht die Pflicht in § 26 KDG und wird durch die Durchführungsverordnung im Einzelnen ausgeformt. Im evangelischen Bereich steht sie in § 27 DSG-EKD. Keine dieser Vorschriften ist für KI geschrieben worden, und keine macht dafür eine Ausnahme. Sie sind anzuwenden wie auf jedes andere Verfahren auch, nur trifft ihr Wortlaut hier auf einen anderen Sachverhalt. ## Warum die vorhandene Maßnahmenliste hier nicht genügt Jede Einrichtung, die Datenschutz ernst betreibt, hat bereits eine Liste technischer und organisatorischer Maßnahmen. Diese Listen sind nicht falsch. Bei einem KI-gestützten System greifen sie an drei Stellen ins Leere, und alle drei sind der Grund, warum eine eigene Anlage nötig ist. **Erstens verlässt die Verarbeitung mit jedem einzelnen Aufruf das Haus.** Bei einer Fachanwendung im eigenen Rechenzentrum ist die Frage nach dem Übertragungsweg einmal zu beantworten. Bei einem System mit externer Modellanbindung ist jede Eingabe eine Übermittlung nach außen, und was dabei übermittelt wird, entscheidet nicht die Nutzerin, sondern die Software: Sie stellt selbständig einen Zusammenhang her, lädt Dokumente nach und ruft Zusatzdienste auf. Die Frage, an welche Stellen tatsächlich übermittelt wird, ist aus der Produktbeschreibung deshalb nicht zu beantworten. Sie ist nur an der laufenden Installation zu beantworten. **Zweitens entsteht mit dem durchsuchbaren Bestand eine neue Datensammlung.** Wer Akten, Protokolle und Postfächer für ein KI-System erschließt, erzeugt einen zweiten Bestand neben der Quelle. Er ist keine Kopie: Die Texte werden zerlegt, neu abgelegt und in eine maschinell durchsuchbare Form gebracht, und in diesem Bestand liegt nebeneinander, was vorher in getrennten Verfahren lag. Für den katholischen Bereich ist die Folge ausdrücklich geregelt. Bei der Einordnung in eine Datenschutzklasse ist „auch der Zusammenhang mit anderen gespeicherten Daten" zu berücksichtigen (§ 9 Abs. 2 KDG-DVO). Genau dieser Zusammenhang entsteht beim Erschließen, und genau er wird in der Regel nicht eingeordnet. **Drittens sind die Voreinstellungen des Anbieters Teil der Maßnahme.** Ob ein Dienst Eingaben aufbewahrt, wie lange und wer darauf zugreifen kann, hängt bei den meisten Angeboten nicht vom Vertrag ab, sondern von einer Einstellung im Konto und von der Art des technischen Zugangs. Beide Rechtskreise verlangen ausdrücklich, dass durch Voreinstellung nur die erforderlichen Daten verarbeitet werden, und nennen die Speicherfrist und die Zugänglichkeit dabei beim Namen (§ 27 Abs. 2 KDG, § 28 Abs. 2 DSG-EKD). Eine Maßnahme, die im Vertrag steht und nicht in der Einstellung, erfüllt diese Anforderung nicht. ## Derselbe Maßstab, zwei Wege dorthin Die Maßnahmen sind in beiden Kirchen dieselben. Ihre Herleitung ist es nicht, und daraus folgt ein Unterschied, der die Reihenfolge der Arbeit bestimmt. **Katholisch stehen die Maßnahmen im Recht.** Die KDG-DVO benennt in § 6 Abs. 2 elf Maßnahmenbereiche, ordnet Daten über § 9 in drei Datenschutzklassen ein und hängt an jede Klasse in den §§ 11 bis 13 feste Mindestmaßnahmen. Dazu kommen Sondervorschriften, die ein KI-System unmittelbar treffen: § 18 zur Nutzung von Cloud-Diensten, § 19 zu autorisierten Programmen, § 22 zu externen Zugriffen. Eine Anlage lässt sich hier gegen einen Katalog abgleichen. Wer keine Einordnung vornimmt, bekommt sie kraft Gesetzes: Dann gilt automatisch Klasse III, sofern nicht die Voraussetzungen des § 14 vorliegen (§ 9 Abs. 5 KDG-DVO). Für Beicht- und Seelsorgegeheimnis kennt die Verordnung eine Stufe oberhalb der drei Klassen; das war das Thema der Ausgabe vom 30. Juli. **Evangelisch stehen die Maßnahmen im eigenen Konzept.** § 27 Abs. 6 DSG-EKD verpflichtet zur IT-Sicherheit und verweist für das Nähere auf eine Rechtsverordnung. Diese Verordnung, die ITSVO-EKD, nennt keine einzelne Maßnahme. Sie verlangt ein IT-Sicherheitskonzept, das fortgeschrieben wird, sich an den Empfehlungen des Bundesamtes für Sicherheit in der Informationstechnik orientiert und den Schutzbedarf der Daten berücksichtigt (§ 1 Abs. 2 und 3 ITSVO-EKD). Es gibt also keinen Katalog, an dem sich die Untergrenze ablesen ließe. Die Einrichtung muss ihre Maßnahmen selbst herleiten und begründen. Daraus folgt nicht, dass der evangelische Strang die schwächeren Pflichten hätte. Bei der Auftragsverarbeitung ist er im Zeitpunkt sogar strenger: § 30 Abs. 3 Sätze 3 und 4 DSG-EKD verlangt, sich vor Beginn der Datenverarbeitung und danach regelmäßig von den Maßnahmen des Auftragsverarbeiters zu überzeugen und das Ergebnis zu dokumentieren. ## Der Zeitpunkt entscheidet über den Wert der Prüfung Dies ist der Punkt, der in der Praxis am häufigsten verloren geht, und er kostet nichts außer Aufmerksamkeit. Wird ein KI-System erst nach Vertragsschluss vorgelegt, ist die Prüfung eine Bestandsaufnahme und keine Auswahlentscheidung. Fast alle Feststellungen, die sich aus einer Anlage wie dieser ergeben, sind dann nicht mehr verhandelbar: der Speicherort, die Aufbewahrungsfrist, die Beteiligten in der Kette, die Frage, ob eine feste Modellversion zugesichert wird. Hier lohnt es, zwei Zeitpunkte auseinanderzuhalten, weil die Vorschriften das auch tun. **Vor der Inbetriebnahme** verlangen beide Rechtskreise die Prüfung ausdrücklich. Katholisch darf die Verarbeitung erst erfolgen, wenn die erforderlichen Maßnahmen getroffen sind (§ 5 Abs. 2 KDG-DVO), und ein Cloud-Dienst, der nicht bereits geprüft und freigegeben ist, ist „vor der Nutzung" anhand von neun Risikoaspekten zu bewerten (§ 18 Abs. 1 und 2 KDG-DVO). Evangelisch ist Mindestvoraussetzung, dass „die Systeme vor ihrem Einsatz getestet wurden" (§ 2 Abs. 1 Nr. 3 ITSVO-EKD). **Vor der Auswahlentscheidung**, also vor der Unterschrift, wird es nur in einem Rechtskreis ausdrücklich: § 3 ITSVO-EKD verlangt, die Beauftragten für den Datenschutz „bei der Entscheidung zur Auswahl" frühzeitig zu beteiligen. Wer evangelisch erst nach dem Vertragsschluss vorlegt, hat deshalb nicht nur eine Prüfung spät gemacht, sondern eine Vorschrift verletzt, unabhängig davon, wie die Prüfung ausgefallen wäre. Katholisch gibt es keine gleichlautende Vorschrift; dort gibt es nur die Soll-Vorschrift, die oder den betrieblichen Datenschutzbeauftragten bei der Einordnung anzuhören (§ 9 Abs. 3 Satz 2 KDG-DVO), und die praktische Einsicht, dass eine Bewertung vor der Nutzung nach einem unterschriebenen Vertrag folgenlos bleibt. Wer katholisch Verbindlichkeit will, muss den Zeitpunkt selbst in die Dienstvereinbarung oder in eine Handreichung schreiben. ## Vier Positionen, an denen Prüfungen regelmäßig auseinanderfallen Das Raster hat 25 Positionen. Vier davon lohnen den Vorabblick, weil sie in der Regel weder im Angebot des Anbieters noch in der vorhandenen Maßnahmenliste vorkommen. **Die Aufbewahrung zur Missbrauchserkennung.** Anbieter speichern Eingaben und Antworten, um missbräuchliche Nutzung zu erkennen, und unterziehen sie dabei auch einer Prüfung durch Menschen. Das geschieht unabhängig davon, ob ein Trainingsausschluss vereinbart ist, und der Trainingsausschluss sagt darüber nichts. Microsoft beschreibt das für seine Modelldienste in der eigenen Dokumentation offen und nennt zugleich den Ausweg: Kunden, die „hoch sensible oder streng vertrauliche Daten" verarbeiten, können eine Änderung dieser Überwachung beantragen, wenn sie zusätzliche Zugangskriterien erfüllen. Beantragen, nicht abschalten, und die Entscheidung liegt beim Anbieter. Zu klären sind deshalb Dauer, Speicherort, Zugriffsberechtigte und die Frage, ob die Einrichtung diesen Antrag stellen kann und ob ihm stattgegeben wurde. **Die Zusatzdienste.** Ein KI-Arbeitsplatz ruft je nach Funktion weitere Dienste auf, etwa für eine Websuche, für die Erschließung eines Dokuments, für Sprache oder für Bilder. Sie springen nur bei bestimmten Funktionen an und fehlen deshalb regelmäßig in der Liste der Beteiligten. Jede dieser Stellen ist eine Stelle in der Kette. Katholisch darf der Auftragsverarbeiter eine weitere Stelle nur mit Genehmigung hinzuziehen und muss jede Änderung mitteilen (§ 29 Abs. 2 KDG), und dieser weiteren Stelle sind dieselben Datenschutzpflichten aufzuerlegen (§ 29 Abs. 5 KDG). Evangelisch gehören die Bedingungen von Unterauftragsverhältnissen in den Auftrag selbst (§ 30 Abs. 3 Satz 2 Nr. 6 DSG-EKD). **Die Protokollierung, zwischen Pflicht und Verbot.** Im katholischen Bereich ist grundsätzlich sicherzustellen, dass nachträglich feststellbar ist, ob und von wem Daten verarbeitet wurden, und diese Eingabekontrolle umfasst mindestens sechs Monate (§ 6 Abs. 2 Buchstabe f KDG-DVO). Zugleich untersagen beide Muster-Dienstvereinbarungen die Verhaltens- und Leistungskontrolle ausdrücklich. Das ist kein Widerspruch, sondern eine Konstruktionsaufgabe: Beides zusammen geht nur mit einer Zweckbindung, einer abschließenden Liste zulässiger Auswertungen und einer Zugriffsbeschränkung auf die Protokolle. Wer die Protokollierung ganz weglässt, um die Mitarbeitervertretung zu beruhigen, muss das Wort „grundsätzlich" in der Vorschrift begründen können. Wer sie ohne diese drei Elemente einrichtet, verletzt die Vereinbarung. **Der Nachweis statt der Zusicherung.** Für den katholischen Bereich steht der Maßstab im Verordnungstext: Der Verantwortliche hat sich vom Schutzniveau des Auftragsverarbeiters „in geeigneter Weise, insbesondere durch persönliche Überprüfung oder Vorlage von Nachweisen" zu überzeugen (§ 9 Abs. 7 KDG-DVO). Eine Angabe im Angebot ist danach kein Nachweis. Das ist die Vorschrift, die aus einer Papierprüfung eine echte macht, und sie wird selten zitiert. ## Was daraus folgt **Für die Leitungsebene**, also für Bistümer, Ordinariate, Generalvikariate und Landeskirchen: Der Abschnitt „Sicherheitsmaßnahmen" ist die Stelle, an der eine Handreichung oder eine Rahmenvereinbarung tatsächlich steuern kann, ohne ein einzelnes Produkt vorzuschreiben. Ein Raster, das Nachweis und Fundstelle nennt, lässt sich einer Einrichtung an die Hand geben und gegenüber einem Anbieter verwenden, ohne dass für jedes Haus neu verhandelt wird. Der zweite Hebel ist der Zeitpunkt: Eine Vorgabe, dass die Datenschutzbeauftragten vor dem Vertragsschluss zu beteiligen sind, wiederholt evangelisch nur geltendes Recht (§ 3 ITSVO-EKD) und schließt katholisch eine Lücke, die die Verordnung offen lässt. **Für die Trägerebene**, also für Verbände, Kliniken, Jugendhilfe und Sozialunternehmen: Die Anlage ist auch ohne Dienstvereinbarung verwendbar, nämlich als Fragenkatalog gegenüber dem Anbieter, solange die Fragen noch etwas bewirken. Drei Regeln für das Ausfüllen: Nur eintragen, was in der laufenden Installation überprüft wurde. „Nicht erfüllt" ist ein zulässiges Ergebnis, „nicht geprüft" ist keines. Und jede Antwort bekommt ein Datum und einen Bezug auf die Version des Systems, weil ein Modellwechsel oder eine geänderte Voreinstellung beim Anbieter einzelne Antworten ungültig macht. ## Das Dokument Die Anlage enthält Anwendungshinweise, 25 Prüfpositionen in sechs Blöcken, einen Prüfungsabschluss zum Unterschreiben, eine Liste der sechs Fehler, die bei solchen Prüfungen erfahrungsgemäß passieren, und die Fundstellen, an denen sich jede Angabe nachprüfen lässt. Jede Position nennt die Maßnahme, ihre Besonderheit im KI-Zusammenhang, den verlangten Nachweis und die Fundstelle in beiden Rechtskreisen. **[Zur Anlage](/anlage-tom-ki/)** · **[PDF herunterladen](/muster/anlage-tom-ki-v1-0.pdf)** Sie gehört zu den beiden Mustern, die hier bereits stehen: [katholische Fassung](/muster-dienstvereinbarung-ki-katholisch/) und [evangelische Fassung](/muster-dienstvereinbarung-ki/). Alles drei ist kostenlos, frei verwendbar, anpassbar und weitergebbar, mit Quellenangabe. ## Fundstellen und die Grenze dieser Prüfung *Dieser Abschnitt ist für alle gedacht, die die Belege selbst nachschlagen wollen. Wer das Dokument benutzen will, braucht ihn nicht und kann hier aufhören.* Die Anlage ist an den Vorschriften geprüft, nicht an einem Produkt. Sie sagt, welche Fragen zu stellen sind und woran sich die Antwort überprüfen lässt. Sie sagt nicht, welches System diese Antworten gibt, und sie trifft keine Aussage über einzelne Anbieter. Drei Einschränkungen sind offen zu benennen, und sie stehen auch im Dokument. **Erstens** setzt die Prüfung dreier Positionen den Zugang zur laufenden Installation voraus: die Zugriffskontrolle bei der Suche im Bestand, die Zwischenspeicher und Fehlerprotokolle und die Weitergabekontrolle. Wo der Betrieb vollständig beim Anbieter liegt, bleibt nur die schriftliche Auskunft, und das ist ein schwächerer Nachweis. Diese Grenze ist nicht durch eine bessere Liste zu beheben. **Zweitens** ist die MAVO diözesanes Recht. Die Angaben zur Mitbestimmung folgen der Rahmenordnung; einzelne Diözesen können abweichen. **Drittens** hat die KDG-DVO durch Beschluss der Vollversammlung des Verbandes der Diözesen Deutschlands vom 24. November 2025 Änderungen erfahren. Ob und wann sie in das eigene Diözesanrecht übernommen wurden, ist im Amtsblatt des eigenen Bistums zu prüfen; das Datum des Inkrafttretens weicht ab. Zur Zählung: Die Anlage nennt für § 6 Abs. 2 KDG-DVO elf Maßnahmenbereiche und für § 18 Abs. 2 KDG-DVO neun Risikoaspekte. Beides ist an der Beschlussfassung vom November 2025 ausgezählt und nicht aus einer Sekundärquelle übernommen. ## Quellen Alle Vorschriften wurden am 1. September 2026 an der jeweiligen Primärquelle geprüft, die Erreichbarkeit der Fundstellen am 16. September 2026 erneut. Die vollständige Liste mit den herangezogenen Paragrafen steht in Teil E des Dokuments. - **Gesetz über den Kirchlichen Datenschutz (KDG)**, Lesefassung des Verbandes der Diözesen Deutschlands, veröffentlicht durch das Sekretariat der Deutschen Bischofskonferenz: [dbk.de (PDF)](https://www.dbk.de/fileadmin/redaktion/diverse_downloads/VDD/2025_KDG_neu_Lesefassung.pdf) - **Durchführungsverordnung zum KDG (KDG-DVO)**, in der Fassung des Beschlusses der Vollversammlung des Verbandes der Diözesen Deutschlands vom 19. November 2018, geändert durch Beschluss vom 24. November 2025: [katholisches-datenschutzzentrum.de (PDF)](https://www.katholisches-datenschutzzentrum.de/wp-content/uploads/2025/12/kdg-dvo-dbk-beschlussfassung-nov-2025.pdf) - **Kirchengesetz über den Datenschutz der EKD (DSG-EKD)**, in der Fassung der Bekanntmachung vom 15. Januar 2025 (ABl. EKD 2025 S. 1 Nr. 1), berichtigt am 20. Februar 2025 (ABl. EKD 2025 S. 42 Nr. 7): [kirchenrecht-ekhn.de (PDF)](https://www.kirchenrecht-ekhn.de/pdf/57715.pdf) - **Verordnung zur Sicherheit der Informationstechnik (ITSVO-EKD)** vom 29. Mai 2015 (ABl. EKD 2015 S. 146): [kirchenrecht-ekvw.de (PDF)](https://www.kirchenrecht-ekvw.de/pdf/33288.pdf) - **Missbrauchsüberwachung**, Dokumentation von Microsoft zu den über Azure angebotenen Modelldiensten, für die Speicherung von Eingaben und Antworten zur Missbrauchserkennung, die Prüfung durch Menschen und das Antragsverfahren für eine geänderte Überwachung. Am 16. September 2026 abgerufen: [learn.microsoft.com](https://learn.microsoft.com/de-de/azure/ai-foundry/openai/concepts/abuse-monitoring) und [learn.microsoft.com (Datenschutz)](https://learn.microsoft.com/de-de/azure/ai-foundry/responsible-ai/openai/data-privacy) --- # Sonderausgabe: Muster-Dienstvereinbarung KI für katholische Einrichtungen (MAVO, KDG) > Das evangelische Muster lässt sich nicht auf MAVO umschreiben. Drei tragende Unterschiede stehen dagegen. Jetzt gibt es eine eigene katholische Fassung, kostenlos. Kanonische URL: https://kirchliche-ki.de/newsletter/sonderausgabe-muster-dienstvereinbarung-katholisch/ · Veröffentlicht: 2026-09-01 Am 12. August erschien hier ein Muster für eine Dienstvereinbarung über den Einsatz KI-gestützter Systeme, für den evangelischen Bereich. Der häufigste Rückschluss darauf war der naheliegende: Man nehme den Text, ersetze MVG durch MAVO und DSG-EKD durch KDG, fertig sei die katholische Fassung. Das funktioniert nicht, und zwar nicht wegen einer Formalie, sondern weil die beiden Rechtskreise an drei tragenden Stellen auseinanderlaufen. Diese Ausgabe benennt sie. Am Ende steht eine eigene katholische Fassung, kostenlos und frei verwendbar. ## 1. Die Dienstvereinbarung ist im katholischen Recht keine Rechtsgrundlage Das ist der Unterschied, der die gesamte Konstruktion trägt, und der Fehler, der am schwersten zu reparieren ist, wenn er einmal drin steht. § 49 Absatz 1 DSG-EKD nennt die Dienstvereinbarung **ausdrücklich als Erlaubnistatbestand** für die Verarbeitung von Beschäftigtendaten, neben Rechtsvorschrift und Tarifvertrag. Im evangelischen Bereich ist die Dienstvereinbarung deshalb Pflicht und Werkzeug in einem: Sie erfüllt die Mitbestimmung, und sie macht die Verarbeitung überhaupt erst zulässig. Das KDG kennt diese Konstruktion nicht. § 53 Absatz 1 KDG erlaubt die Verarbeitung von Beschäftigtendaten, wenn sie für die Begründung, Durchführung oder Beendigung des Beschäftigungsverhältnisses **erforderlich** ist. Eine Kollektivvereinbarung wird nicht genannt. § 53 Absatz 4 KDG stellt lediglich klar: „Die Beteiligungsrechte nach der jeweils geltenden Mitarbeitervertretungsordnung bleiben unberührt." Auch der Katalog der Erlaubnistatbestände in § 6 Absatz 1 KDG führt keine Dienstvereinbarung auf. Ob eine Dienstvereinbarung als „andere kirchliche Rechtsvorschrift" im Sinne des § 6 Absatz 1 Buchstabe a KDG gelten kann, ist eine offene Auslegungsfrage. Das Muster entscheidet sie nicht und setzt sie nicht voraus. **Die praktische Folge ist keine Schwächung, sondern eine Verschiebung der Funktion.** Rechtsgrundlage ist § 53 Absatz 1 KDG. Die Dienstvereinbarung begründet diese Erlaubnis nicht, sie **begrenzt** sie. Und genau darin liegt ihr Wert: Indem die Vereinbarung und ihre Anlage den zugelassenen Umfang abschließend beschreiben, wird aus dem unbestimmten Rechtsbegriff der Erforderlichkeit ein prüfbarer Maßstab. Alles darüber hinaus ist erkennbar nicht mehr erforderlich. Wer diesen Paragrafen umformuliert und die Dienstvereinbarung doch zur Rechtsgrundlage erklärt, macht eine ungeklärte Rechtsfrage zur Grundlage der gesamten Verarbeitung. ## 2. „Bestimmt" statt „geeignet", und warum der Unterschied vor Gericht verschwindet Das evangelische Recht lässt in § 40 Buchstabe k MVG-EKD genügen, dass eine technische Einrichtung zur Überwachung von Verhalten oder Leistung **geeignet** ist. Auf eine Absicht kommt es nicht an. Das ist ein weiter Auslöser, und die Ausgabe vom 19. Juli hat sich damit befasst. § 36 Absatz 1 Nummer 9 MAVO verlangt, dass die Einrichtung dazu **bestimmt** ist. Das ist derselbe Wortlaut wie im weltlichen Betriebsverfassungsrecht und dem Wortlaut nach enger. Wer daraus schließt, ein KI-Arbeitsplatz sei mitbestimmungsfrei, solange niemand überwachen will, hat die Rechtsprechung gegen sich. Der Kirchliche Arbeitsgerichtshof hat das Merkmal entschieden. Im Urteil vom 15. Mai 2020 (M 20/2019, zur MAVO des Bistums Fulda) heißt es: „Zur Überwachung ‚bestimmt' sind technische Einrichtungen dann, wenn sie objektiv geeignet sind, Verhaltens- oder Leistungsdaten über den Arbeitnehmer zu erheben und aufzuzeichnen, auf die subjektive Überwachungsabsicht des Arbeitgebers kommt es nicht an." Der Gerichtshof übernimmt damit ausdrücklich die ständige Rechtsprechung des Bundesarbeitsgerichts zur inhaltsgleichen Vorschrift des § 87 Absatz 1 Nummer 6 BetrVG. Im Ergebnis stehen beide Kirchen an derselben Stelle: Es zählt, was das System kann, nicht, was der Dienstgeber damit vorhat. Für KI-Arbeitsplätze ist ein zweiter Satz aus demselben Urteil ebenso wichtig. Der Dienstgeber wendet ein Überwachungssystem auch dann an, wenn ein Dritter es betreibt und der Dienstgeber selbst keinen Zugriff auf die erfassten Daten hat. Es genügt, dass er die Entscheidung trifft, seine Mitarbeiterinnen und Mitarbeiter ein solches System nutzen zu lassen. Im entschiedenen Fall war das eine Online-Schulung, die Lernergebnisse, Klickverhalten, Anmeldungen und Verweildauer speicherte. Ein KI-Dienst bei einem Anbieter, der Eingaben, Zeitpunkte und Nutzerkennungen protokolliert, ist davon nicht zu unterscheiden. Das Argument, die Protokolle lägen ja beim Anbieter und nicht beim Dienstgeber, trägt nach dieser Entscheidung nicht. Für die Praxis heißt das: Bei einem KI-Arbeitsplatz mit personenbezogenen Zugängen ist die Zustimmungsbedürftigkeit nach § 36 Absatz 1 Nummer 9 MAVO der Regelfall, und § 38 Absatz 1 Nummer 11 MAVO erlaubt die Dienstvereinbarung in dieser Angelegenheit ausdrücklich. Wer die Zustimmungsbedürftigkeit bestreiten will, muss darlegen, dass das System keine Verhaltens- oder Leistungsdaten erhebt und aufzeichnet. Diese Darlegung ist an der Anlage überprüfbar, und sie wird bei einem System mit Nutzerkonten selten gelingen. ## 3. Die katholische Vereinbarung wirkt nach Im evangelischen Recht ist die Nachwirkung einer Dienstvereinbarung grundsätzlich ausgeschlossen, soweit sie nicht ausdrücklich festgeschrieben wird. Deshalb steht im evangelischen Muster das Verwertungsverbot ausdrücklich im Text und nicht als Selbstverständlichkeit daneben. Im katholischen Recht ist es umgekehrt. § 38 Absatz 5 Satz 1 MAVO ordnet die Nachwirkung für die Angelegenheiten des § 38 Absatz 1 Nummern 2 bis 13 an, und die technischen Einrichtungen stehen dort unter Nummer 11. Nach einer Kündigung gelten die Regelungen also fort, bis eine neue Vereinbarung sie ersetzt. Für die Mitarbeitervertretung ist das eine deutlich stärkere Position als im evangelischen Bereich. Es ist ein Argument, das in der Verhandlung auf den Tisch gehört, und es wird selten genutzt. ## Zwei Vorschriften ohne evangelische Entsprechung **Die Datenschutzklassen.** § 9 KDG-DVO verlangt die Einordnung der Daten in eine von drei Klassen, an denen fest beschriebene Mindestmaßnahmen hängen. Vier Absätze davon treffen ein KI-System unmittelbar: Absatz 2 verlangt, den Zusammenhang mit anderen gespeicherten Daten zu berücksichtigen, was jeden durchsuchbaren Index über mehrere Aktenbestände betrifft. Absatz 4 lässt eine Einordnung in eine niedrigere Klasse nur nach Anhörung der oder des betrieblichen Datenschutzbeauftragten zu. Absatz 5 setzt bei fehlender Einordnung automatisch die strengste Klasse III. Absatz 7 verlangt, sich vom Schutzniveau eines Auftragsverarbeiters zu überzeugen, durch Überprüfung oder Nachweise, nicht durch eine Zusicherung im Angebot. Das katholische Muster hat deshalb einen eigenen Paragrafen zur Datenschutzklasse, den die evangelische Fassung nicht kennt. **Beicht- und Seelsorgegeheimnis.** § 14 Absatz 2 KDG-DVO verbietet die Verarbeitung von Daten, die dem Beichtgeheimnis unterliegen, ohne Abwägung und ohne Ausweg über Schutzmaßnahmen. § 14 Absatz 3 lässt Daten des Seelsorgegeheimnisses nur zu, wenn erforderlichenfalls über das Schutzniveau der Klasse III hinausgehende Maßnahmen ergriffen werden; Absatz 4 nennt als Beispiel einen eigenen Server in einem Netzwerk ohne externe Datenverbindung. Für ein System, das über eine Schnittstelle mit einem Modell bei einem Anbieter spricht, heißt das im Regelfall: Diese Daten gehören nicht hinein. Deshalb steht dieser Ausschluss im Muster an erster Stelle und nicht in einer Aufzählung weiter unten. ## Zwei Gruppen, die aus der Vereinbarung herausfallen § 3 MAVO zieht den Kreis der Mitarbeiterinnen und Mitarbeiter anders als das MVG-EKD. Zwei Ausnahmen haben unmittelbare Folgen, und beide werden regelmäßig übersehen: **Überlassene Personen.** § 3 Absatz 1 Satz 2 MAVO stellt ausdrücklich klar, dass Personen, die nach dem Arbeitnehmerüberlassungsgesetz zur Arbeitsleistung überlassen werden, keine Mitarbeiterinnen und Mitarbeiter im Sinne der Ordnung sind. **Leitungen.** Nach § 3 Absatz 2 MAVO gelten Mitglieder des zur gesetzlichen Vertretung berufenen Organs und Leiterinnen und Leiter von Einrichtungen nicht als Mitarbeiterinnen und Mitarbeiter. Erhalten diese Personen Systemzugänge, sind sie von der Dienstvereinbarung nicht erfasst. Das ist keine Erlaubnis, sondern eine Lücke, denn das KDG schützt ihre Daten unverändert. Praktisch relevant ist besonders der zweite Fall, weil gerade Leitungszugänge häufig die weitesten Rechte haben. Das Muster sieht dafür eine gesonderte Regelung vor. ## Das Muster Die katholische Fassung enthält einen vollständigen Vertragstext mit achtzehn Paragrafen, eine Gliederung für die Anlage zur Systembeschreibung mit vierzehn Abschnitten, Anwendungshinweise und die Fundstellen, an denen sich jede Angabe nachprüfen lässt. **[Zur katholischen Fassung](/muster-dienstvereinbarung-ki-katholisch/)**, mit PDF zum Herunterladen. Die evangelische Fassung steht unverändert [hier](/muster-dienstvereinbarung-ki/). Beide sind kostenlos, frei verwendbar, anpassbar und weitergebbar, mit Quellenangabe. ## Was vor der Verwendung zu prüfen ist Die MAVO ist **diözesanes Recht**. Der Verband der Diözesen Deutschlands beschließt eine Rahmenordnung, jedes Bistum setzt sie für seinen Bereich in Kraft, und dabei sind Abweichungen möglich. Die hier verwendeten Fundstellen wurden an zwei übereinstimmenden Quellen geprüft, an der Rahmenordnung und an der Lesefassung eines Bistums von 2025. Das ist ein starkes Indiz, aber keine Garantie für jede Diözese. Das Dokument nennt gleich zu Beginn die drei Fundstellen, die mit der eigenen MAVO abzugleichen sind. Dasselbe gilt für das KDG. Die Novelle der Durchführungsverordnung beruht auf einem Beschluss der Vollversammlung des Verbandes der Diözesen Deutschlands vom 24. November 2025, das Datum des Inkrafttretens kann je Bistum abweichen. Das Muster ist ein Formularwerk und ersetzt keine Prüfung des Einzelfalls. Die Anpassung an die konkrete Einrichtung, die rechtliche Bewertung und die Freigabe gehören zur oder zum betrieblichen Datenschutzbeauftragten beziehungsweise zur anwaltlichen Beratung der Einrichtung. ## Quellen Alle am 19. August 2026 an der Primärquelle geprüft, die Fundstellen und ihre Zählung am 25. August 2026 erneut an den PDF-Fassungen. Die vollständige Quellenliste steht in Teil E des Dokuments. - **Rahmenordnung für eine Mitarbeitervertretungsordnung (Rahmen-MAVO)** des Verbandes der Diözesen Deutschlands sowie eine diözesane Lesefassung von 2025, für § 3, § 36 Absatz 1 Nummer 9, § 38 Absatz 1 Nummer 11 und § 38 Absätze 3, 3a, 4 und 5. Beide Quellen stimmen in der Nummerierung überein. - **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 § 6 Absatz 1, § 29, § 35 und § 53: [dbk.de (Lesefassung, PDF)](https://www.dbk.de/fileadmin/redaktion/diverse_downloads/VDD/2025_KDG_neu_Lesefassung.pdf) - **Durchführungsverordnung zum KDG (KDG-DVO)** vom 10. Januar 2019, geändert am 20. Januar 2026, amtliche Lesefassung des Erzbistums Hamburg, für § 9, §§ 11 bis 13, § 14 und § 18: [erzbistum-hamburg.de (PDF)](https://erzbistum-hamburg.de/pdf/Abteilung_Recht/Datenschutz/KDG-DVO.pdf?m=1587546982) - **Verordnung zur Änderung der KDG-DVO**, Anlage zum Amtsblatt des Erzbistums Berlin 03/2026, in Kraft zum 1. März 2026: [erzbistumberlin.de (PDF)](https://www.erzbistumberlin.de/fileadmin/user_mount/Dokumentencenter/extern/Amtsblaetter/aktuelles_Jahr_Monatsausgaben/2026-03_Amtsblatt_Anlage_Verordnung_zur_AEnderung_der_KDG-DVO.pdf) - **Kirchengesetz über den Datenschutz der EKD (DSG-EKD)** in der Bekanntgabe der Neufassung vom 15. Januar 2025 (ABl. EKD S. 1), für den Vergleich in Abschnitt 1: [kirchenrecht-ekm.de](https://www.kirchenrecht-ekm.de/document/58341) - **Kirchlicher Arbeitsgerichtshof, Urteil vom 15. Mai 2020, M 20/2019**, Revision gegen das Urteil des Kirchlichen Arbeitsgerichts Fulda vom 19. November 2019 (M 7/19), anonymisierte Fassung, Randnummern 22 und 24, für die Auslegung des Merkmals „bestimmt" in § 36 Absatz 1 Nummer 9 MAVO und für die Anwendung durch Dritte: [dbk.de (PDF)](https://www.dbk.de/fileadmin/user_upload/Urteil_M_20_2019_15.05.2020_Anonymisierte_Fassung.docx.pdf) --- # Automatisch geschwärzt? Vier Wege, auf denen personenbezogene Daten trotzdem beim Anbieter landen > Die Zusage, dass ein KI-System Namen und andere personenbezogene Daten selbst entfernt, wird an der Eingabezeile vorgeführt. Drei weitere Wege bleiben ungeprüft. Kanonische URL: https://kirchliche-ki.de/newsletter/pii-filter-im-aufrufpfad/ · Veröffentlicht: 2026-08-20 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. 1. **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. 2. **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. 3. **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? 4. **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? 5. **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? 6. **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? 7. **Welche Kategorien werden erkannt und welche nicht?** Verlangt wird eine Liste, kein Sammelbegriff, und dazu die Aussage, was mit identifizierenden Kombinationen ohne Namen geschieht. 8. **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. 9. **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? 10. **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](https://raw.githubusercontent.com/open-webui/open-webui/v0.11.0/backend/open_webui/utils/middleware.py) - 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](https://raw.githubusercontent.com/open-webui/open-webui/v0.11.0/backend/open_webui/routers/tasks.py) - 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](https://raw.githubusercontent.com/open-webui/open-webui/v0.11.0/backend/open_webui/utils/chat.py) - 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](https://raw.githubusercontent.com/open-webui/open-webui/v0.11.0/backend/open_webui/routers/retrieval.py) - Open WebUI v0.11.0, `src/lib/components/common/RichTextInput.svelte`, für den Aufruf von `generateAutoCompletion` aus der Eingabekomponente: [raw.githubusercontent.com](https://raw.githubusercontent.com/open-webui/open-webui/v0.11.0/src/lib/components/common/RichTextInput.svelte) - 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)](https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.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)](https://www.dbk.de/fileadmin/redaktion/diverse_downloads/VDD/2025_KDG_neu_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)](https://erzbistum-hamburg.de/pdf/Abteilung_Recht/Datenschutz/KDG-DVO.pdf?m=1587546982) - 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)](https://www.erzbistumberlin.de/fileadmin/user_mount/Dokumentencenter/extern/Amtsblaetter/aktuelles_Jahr_Monatsausgaben/2026-03_Amtsblatt_Anlage_Verordnung_zur_AEnderung_der_KDG-DVO.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](https://www.kirchenrecht-ekm.de/document/58341) - 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](https://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](https://huggingface.co/flair/ner-german-large) --- # Sonderausgabe: Muster-Dienstvereinbarung für KI-Systeme (MVG-EKD, DSG-EKD) > Wer ein KI-System einführt, in dem Mitarbeitende mit eigenen Zugängen arbeiten, braucht eine Dienstvereinbarung. Für den kirchlichen Bereich gab es dafür bisher kein Muster. Ab heute gibt es eines, kostenlos und frei verwendbar. Kanonische URL: https://kirchliche-ki.de/newsletter/sonderausgabe-muster-dienstvereinbarung/ · Veröffentlicht: 2026-08-12 > **Korrektur vom 13. August 2026.** Die Vorschrift wird hier jetzt als § 40 Buchstabe k > MVG-EKD zitiert, zuvor stand hier „Nr. 11". Der Mitbestimmungskatalog des § 40 ist mit > Buchstaben gegliedert. Wortlaut und Aussage sind unverändert. Das Muster und die > PDF-Fassung sind entsprechend angepasst. Liebe Leserinnen und Leser, diese Ausgabe ist keine Ausgabe, sondern ein Dokument. Wer in einer evangelischen Dienststelle ein KI-System einführt, in dem Mitarbeitende mit eigenen Zugängen arbeiten, braucht dafür eine Dienstvereinbarung. § 40 Buchstabe k MVG-EKD knüpft die Mitbestimmung daran, dass eine technische Einrichtung zur Überwachung von Verhalten oder Leistung **geeignet** ist. Auf eine entsprechende Absicht kommt es nicht an, und die Pflicht greift bereits bei der Einführung, nicht erst bei einer Auswertung. Ein Muster dafür gab es im kirchlichen Bereich bisher nicht. Weder der Gesamtausschuss der Mitarbeitendenvertretungen noch die Infothek des Beauftragten für den Datenschutz der EKD führen eines, und die verfügbaren weltlichen Muster kennen weder MVG-EKD noch DSG-EKD. Ab heute gibt es eines, kostenlos: **[Muster-Dienstvereinbarung über den Einsatz KI-gestützter Systeme](https://kirchliche-ki.de/muster-dienstvereinbarung-ki/)** Darin steht ein vollständiger Vertragstext mit sechzehn Paragrafen, von der ausgeschlossenen Nutzung über die Protokollierung und den Zugriff der Administration bis zu der Frage, was bei Beendigung mit den Daten geschieht. Dazu eine Gliederung für die Anlage, in der das konkrete System beschrieben wird, denn was dort nicht steht, ist nicht vereinbart. Dazu Anwendungshinweise, eine Liste der Fehler, die in der Praxis am häufigsten passieren, und zu jeder Angabe die Fundstelle. ## Zwei Hinweise, die im Alltag den Unterschied machen **Prüfen Sie zuerst, welches Mitarbeitendenvertretungsrecht bei Ihnen überhaupt gilt.** Das MVG-EKD gilt in den Gliedkirchen nicht unmittelbar, sondern über deren Übernahme- oder Anwendungsgesetze. Einzelne Gliedkirchen haben stattdessen ein eigenes Gesetz, und für Niedersachsen kursiert vielfach noch eines, das außer Kraft ist. Diese Prüfung gehört an den Anfang der Arbeit, nicht an ihr Ende. **Die KI-Richtlinie der Leitung ersetzt die Dienstvereinbarung nicht.** Das eine ist das einseitige Dokument des Dienstgebers und regelt, wie gearbeitet werden soll. Das andere ist das Dokument der Mitbestimmung und regelt, was mit den Daten der Mitarbeitenden geschieht. Beide müssen zueinander passen, und das prüft niemand von allein. ## Zur Verwendung Das Muster darf frei verwendet, an die eigene Einrichtung angepasst und weitergegeben werden. Wenn es in Ihrem Haus jemandem hilft, geben Sie es weiter. Es ist ein Formularwerk und ersetzt keine Prüfung des Einzelfalls. Die Anpassung an die konkrete Einrichtung, die rechtliche Bewertung und die Freigabe gehören zur oder zum örtlich Beauftragten für den Datenschutz beziehungsweise zur anwaltlichen Beratung der Dienststelle. Über Hinweise auf Fehler, Rechtsänderungen oder fehlende Punkte freue ich mich ausdrücklich. --- # Exit-Strategie für ein KI-System: Was § 18 KDG-DVO verlangt und warum der Vektorindex nicht mitwandert > Die novellierte KDG-DVO hat mit § 18 erstmals eine eigene Vorschrift für Cloud-Dienste. Sie verlangt vor der Nutzung eine Exit-Strategie. Bei einem KI-System trifft diese Pflicht auf einen Bestand, der sich technisch nicht mitnehmen lässt, und auf eine Uhr, die der Risikokatalog nicht kennt. Kanonische URL: https://kirchliche-ki.de/newsletter/exit-strategie-ki-paragraf-18-kdg-dvo/ · Veröffentlicht: 2026-08-06 Die Novelle des katholischen Datenschutzrechts hat der Durchführungsverordnung einen Paragrafen hinzugefügt, den es vorher nicht gab. § 18 KDG-DVO regelt die Nutzung von Cloud-Diensten, steht im neuen Kapitel 5 („Besondere Gefahrenlagen“), und der bis dahin unter dieser Nummer geführte Paragraf über autorisierte Programme ist zu § 19 gerückt. Der Zusatz ist kurz, drei Absätze, und sein letzter Absatz enthält die Anforderung, an der die meisten KI-Projekte im Träger unvorbereitet sind: > „Vor der Nutzung des Cloud-Dienstes ist in Abhängigkeit von der Risikoanalyse eine > Exit-Strategie zu definieren (z. B. Datenlöschung, Datenübertragung)." Zwei Wörter tragen das: **vor** der Nutzung, und **Strategie**. Nicht nach dem Pilotbetrieb, nicht als Klausel im Vertragsanhang, sondern als Bedingung der Inbetriebnahme. Diese Ausgabe liest die Vorschrift so, wie die Ausgabe [Nicht klassifiziert heißt Klasse III](/newsletter/klassifizierung-kdg-dvo-datenschutzklassen/) den § 9 gelesen hat: als Architekturvorgabe, nicht als Formular. ## Was § 18 tatsächlich verlangt Absatz 1 setzt eine Rangfolge: „Es sind primär bereits geprüfte und freigegebene Cloud-Dienste zu nutzen." Wer prüft und freigibt, lässt die Vorschrift offen. Für die Nachweisebene hilft § 7 Absatz 2 KDG-DVO weiter, der ein anerkanntes Zertifikat nach § 26 Absatz 4 KDG ausdrücklich als Nachweis zulässt, orientiert an Veröffentlichungen des BSI oder ersatzweise an vergleichbaren Regelwerken, insbesondere ISO/IEC 27001. Absatz 2 ist der eigentliche Prüfauftrag. Vor der Nutzung anderer Dienste ist anhand eines Katalogs zu prüfen, ob die Sicherheitsanforderungen erfüllt sind. Neun Aspekte „können ein erhöhtes Risiko darstellen", darunter die ungeplante vorzeitige Vertragsbeendigung durch den Anbieter (Buchst. a), mangelnde Portabilität von Daten und IT-Systemen (Buchst. c), generelle Abhängigkeit mangels Wechselmöglichkeit (Buchst. d), Gefährdung der Integrität „aufgrund herstellerspezifischer Datenformate" (Buchst. e), Unkenntnis über den Speicherort (Buchst. g) und unbefugter Zugriff, etwa durch Administrationspersonal des Anbieters (Buchst. i). Absatz 3 knüpft die Exit-Strategie ausdrücklich an die Risikoanalyse, also an § 10 KDG-DVO. Die Tiefe der Ausstiegsplanung ist damit keine Geschmacksfrage: Sie skaliert mit dem festgestellten Risiko, und das Risiko hängt an der Datenschutzklasse. Für einen Bestand, der mangels Einordnung nach § 9 Absatz 5 in Klasse III fällt, ist eine Exit-Strategie im Umfang von drei Sätzen keine Erfüllung der Vorschrift. ## Der Katalog ist für Dateiablagen geschrieben Liest man Absatz 2 mit einem klassischen Cloud-Speicher im Kopf, ist er vollständig. Dokumente liegen in Dateiformaten, die Formate sind bekannt, der Export ist eine Frage von Bandbreite und Zeit. Vier Buchstaben des Katalogs treffen einen KI-Arbeitsplatz allerdings härter, als sie klingen, weil dort etwas gespeichert wird, das im Ausgangsbestand nicht vorkam. Ein KI-System über eigenen Dokumenten hält typischerweise sechs Bestände, und sie haben sehr unterschiedliche Exit-Eigenschaften: 1. **Die Quelldokumente** in der Ablage des Dienstes. Portabel, weil sie das Format behalten, in dem sie hochgeladen wurden. 2. **Den Vektorindex**, also die Einbettungen der zerlegten Dokumente. Nicht portabel, siehe unten. 3. **Die Chatverläufe.** Export meist als JSON möglich, inhaltlich aber der heikelste Bestand, weil dort Fallbezüge stehen, die in keiner Akte vorgesehen waren. 4. **Die Konfiguration**: Systemprompts, Assistenten, Wissensbasen-Zuschnitte, Rollen- und Rechtemodell. Formal proprietär, inhaltlich das eigentliche Projektergebnis. 5. **Eine etwaige Feinabstimmung**, also trainierte Gewichte auf Basis eigener Daten. 6. **Die Protokolle**, die § 6 Absatz 2 Buchst. e und f KDG-DVO für Weitergabe- und Eingabekontrolle ohnehin verlangen, letztere für mindestens sechs Monate. Eine Exit-Strategie, die „die Daten" sagt und die Dateiablage meint, deckt davon einen von sechs Beständen ab. Die Prüfung nach Absatz 2 muss das Inventar durchgehen, nicht den Dienst als Ganzes bewerten. ## Warum der Index nicht mitwandert Buchstabe c fragt nach Portabilität, Buchstabe e nach herstellerspezifischen Formaten. Beim Vektorindex fallen beide zusammen, und zwar nicht wegen einer Geschäftspolitik, sondern aus der Sache heraus. Die Dokumentation von Open WebUI, der quelloffenen Oberfläche, die hinter vielen dieser Arbeitsplätze steht (siehe die Ausgabe [Open WebUI unter der Lupe](/newsletter/open-webui-unter-der-lupe/)), formuliert es für den Fall des Modellwechsels unmissverständlich: Ein Wechsel des Einbettungsmodells „requires a re-index of all knowledge base documents. Embeddings from different models exist in different vector spaces and are not compatible with each other." Das ist die technische Kernaussage, und sie gilt über das Produkt hinaus. Ein Einbettungsvektor ist nur innerhalb des Modells sinnvoll, das ihn erzeugt hat. Vektoren eines anderen Modells liegen in einem anderen Raum, oft schon in einer anderen Dimensionszahl. Ein Index lässt sich exportieren, aber der Export ist beim Nachfolgedienst wertlos, sofern dieser nicht exakt dasselbe Einbettungsmodell betreibt. Daraus folgt eine Regel, die in jede Exit-Strategie gehört: **Portabel sind die Quelldokumente, nie der Index.** Das Prüfkriterium gegenüber einem Anbieter lautet deshalb nicht „können wir den Index exportieren", sondern „bekommen wir das Korpus in seiner Ausgangsform vollständig zurück, samt der Zuordnung, welches Dokument in welcher Wissensbasis lag". Der Wiederaufbau beim Nachfolger ist dann Rechenzeit, kein Datenverlust. Wer die Neuindizierung von Anfang an einplant, kann den Ausstieg realistisch beziffern. Dieselbe Dokumentation nennt nebenbei ein Löschproblem. Dateien, die direkt in einen Chat hochgeladen wurden statt in eine Wissensbasis, führen „their own per-file vector collections", die von einem Reindex nicht erfasst werden. Ob die Löschroutine eines Anbieters solche Streubestände erfasst, ist deshalb eine eigene Prüffrage, und genau hier trennt sich eine geprüfte Löschung von einer zugesicherten. ## Die Uhr, die im Katalog fehlt Buchstabe a nennt die ungeplante vorzeitige Vertragsbeendigung durch den Anbieter. Im KI-Stack endet aber selten der Vertrag. Es endet das Modell, und zwar planmäßig, angekündigt und ohne Zutun des Trägers. Microsoft dokumentiert den Lebenszyklus seiner Modellplattform mit konkreten Fristen: Allgemein verfügbare Modelle bekommen ihr Abkündigungsdatum bereits beim Start gesetzt, 18 Monate im Voraus. Nach 12 Monaten gilt das Modell als „deprecated", neue Kunden können es nicht mehr belegen. Zum Stichtag beantwortet der Dienst jede Anfrage mit `410 Gone`. Die aktive Benachrichtigung erfolgt mindestens 60 Tage vor der Abschaltung, bei Vorschauversionen mindestens 30 Tage, und auf die Frage nach einer Verlängerung antwortet die Dokumentation ohne Umschweife: „Retirement dates aren't extendable." Bei Sicherheits- oder Compliance-Problemen behält sich der Anbieter eine Notfall-Abkündigung mit verkürzter Frist vor. Modelle einiger Anbieter im selben Katalog laufen auf 12 statt 18 Monaten. Feinabgestimmte Modelle folgen einem eigenen Fahrplan mit getrennten Terminen für Training und Bereitstellung. Das ist kein Argument gegen eine Plattform, sondern eine Eigenschaft der Betriebsform. Für die Exit-Strategie folgen daraus zwei Dinge. Erstens ist die Wechselfrist nicht frei wählbar, sondern von außen getaktet, und ein Vorlauf von 60 Tagen ist knapp bemessen, wenn der Umstieg im eigenen Haus erneute Prüfungen anstößt, unter Umständen bis zu der Frage, ob die Mitarbeitendenvertretung zu beteiligen ist (siehe [Geeignet, nicht bestimmt](/newsletter/mitbestimmung-geeignet-mvg-ekd/)). Zweitens sind Systemprompts, Assistenten und Auswertungslogiken auf ein bestimmtes Modell kalibriert. Der Wechsel auf den Nachfolger ist deshalb kein Konfigurationsschritt, sondern ein Abnahmevorgang mit erneuter fachlicher Prüfung. Wer das erst am Stichtag bemerkt, betreibt den Umzug ungeplant, und genau das wollte Buchstabe a verhindern. Ein automatischer Versionswechsel entschärft das nicht, er verlagert es. Ein System, das ohne Zutun auf ein Nachfolgemodell gehoben wird, verändert sein Verhalten zu einem Zeitpunkt, den der Verantwortliche nicht bestimmt hat, während er nach § 7 Absatz 1 KDG-DVO mindestens alle zwei Jahre die Wirksamkeit seiner Maßnahmen zu überprüfen und das Ergebnis zu dokumentieren hat. ## Derselbe Begriff im weltlichen Recht Kirchliches Recht verpflichtet den Träger, nicht den Anbieter. Für die Gegenseite gibt es seit dem 12. September 2025 ein unmittelbar geltendes Instrument: die EU-Datenverordnung, Verordnung (EU) 2023/2854. Ihr Kapitel VI regelt den Wechsel zwischen Datenverarbeitungsdiensten, und Artikel 25 Absatz 2 Buchstabe b verpflichtet den Anbieter, „die für die vertraglich vereinbarten Dienste relevante Ausstiegsstrategie des Kunden zu unterstützen, unter anderem durch Bereitstellung aller einschlägigen Informationen". Zwei getrennte Rechtskreise, kirchlicher und europäischer, benutzen damit denselben Begriff. Was § 18 Absatz 3 KDG-DVO dem Träger aufgibt, kann er nach Artikel 25 vom Anbieter verlangen. Der Artikel liefert die Fristen gleich mit: eine maximale Kündigungsfrist von zwei Monaten für die Einleitung des Wechsels (Buchst. d), eine verbindliche Übergangsfrist von höchstens 30 Kalendertagen für die Übertragung (Buchst. a), einen Abrufzeitraum von mindestens 30 Kalendertagen danach (Buchst. g) und die garantierte vollständige Löschung nach Ablauf dieses Zeitraums (Buchst. h). Ist die Frist technisch nicht durchführbar, muss der Anbieter das binnen 14 Arbeitstagen begründen und darf höchstens sieben Monate ansetzen. Nach Artikel 29 dürfen ab dem 12. Januar 2027 keine Wechselentgelte mehr erhoben werden, bis dahin nur ermäßigte, die die tatsächlichen Kosten nicht übersteigen. Bei den Grenzen ist Genauigkeit angebracht, denn hier wird in Verkaufsgesprächen gern zu viel behauptet. Drei Einschränkungen tragen das Gewicht: - **Funktionsäquivalenz gibt es nur für Infrastruktur.** Die Wiederherstellung vergleichbarer Funktionalität beim neuen Anbieter schuldet Artikel 30 Absatz 1 nur für Dienste, die auf Infrastrukturelemente beschränkt sind. Für den KI-Arbeitsplatz bleiben offene Schnittstellen und, mangels veröffentlichter gemeinsamer Spezifikationen, der Export aller exportierbaren Daten „in einem strukturierten, gängigen und maschinenlesbaren Format" (Absätze 2 und 5). - **Interna bleiben beim Anbieter.** Digitale Vermögenswerte, die durch Rechte des geistigen Eigentums geschützt sind oder ein Geschäftsgeheimnis darstellen, muss kein Anbieter offenlegen (Artikel 30 Absatz 6). Der Vertrag darf zudem nach Artikel 25 Absatz 2 Buchstabe f Datenkategorien vom Export ausnehmen, die für die interne Funktionsweise des Dienstes spezifisch sind. Durch diese Tür verlassen Indexstrukturen und Modellinterna den Exportumfang. - **Die Modell-Schnittstelle ist ein offener Fall.** Ob ein reiner Modellzugang unter den Begriff des Datenverarbeitungsdienstes nach Artikel 2 Nummer 8 fällt, ist ungeklärt. Für die Plattformebene, auf der Dateien, Index und Verläufe liegen, stellt sich diese Frage nicht. Praktisch heißt das: Der Data Act verschafft eine Frist, einen Anspruch auf Export in einem gängigen Format und ab 2027 die Entgeltfreiheit. Er verschafft keinen Anspruch darauf, dass das System beim Nachfolger genauso antwortet. ## Löschung ist der schwierigere Teil des Ausstiegs § 18 Absatz 3 nennt Datenlöschung und Datenübertragung in einem Atemzug, aber die Löschung ist der Teil, der sich schlechter belegen lässt. Das KDG stellt in § 29 Absatz 4 Buchstabe g klar, wem die Entscheidung gehört: Der Auftragsverarbeiter hat nach Abschluss der Leistung alle personenbezogenen Daten „nach Wahl des Verantwortlichen entweder" zu löschen „oder zurückzugeben", vorbehaltlich gesetzlicher Aufbewahrungspflichten. Das Wahlrecht liegt beim Träger, nicht beim Anbieter, und es ist vor Vertragsschluss auszuüben, nicht danach. Wie streng der Maßstab gemeint ist, zeigt die KDG-DVO an anderer Stelle. § 23 verlangt bei der Vernichtung von IT-Systemen Maßnahmen, „die die Lesbarkeit oder Wiederherstellbarkeit der Daten zuverlässig ausschließen". Für die Kontrolle gilt § 9 Absatz 7: Bei Verarbeitung durch einen Auftragsverarbeiter muss der Verantwortliche sich „insbesondere durch persönliche Überprüfung oder Vorlage von Nachweisen" vom Schutzniveau überzeugen. Eine Bestätigungsmail über eine erfolgte Löschung ist eine Zusicherung, kein Nachweis. Die Löschliste eines KI-Systems ist deshalb länger als die Ablage. Sie umfasst den Vektorindex einschließlich der Chat-Sammlungen, die eine Sammelroutine übersieht, die Chatverläufe, hochgeladene Dateien außerhalb der Wissensbasen, Zwischenspeicher, Sicherungen mitsamt ihrer Aufbewahrungsdauer, die Protokolle mit ihrer eigenen Mindestfrist aus § 6 Absatz 2 Buchst. f, und, sofern feinabgestimmt wurde, die trainierten Gewichte, denn die wörtliche Extraktion einzelner Trainingsinhalte aus einem Sprachmodell ist nachgewiesen. Für jeden dieser Bestände gehört in die Exit-Strategie, wer löscht, woran das belegt wird und wann. ## Die evangelische Gegenprobe Wie schon bei den Datenschutzklassen lohnt der Blick auf die evangelische Seite, weil er zeigt, was an § 18 katholisches Sonderrecht ist und was allgemeiner Sorgfaltsmaßstab. Das DSG-EKD kennt keine Entsprechung: Das Wort Cloud kommt im Gesetz nicht vor, und eine Pflicht, vor der Nutzung eines Dienstes eine Exit-Strategie zu definieren, gibt es nicht. Was es gibt, ist die Vertragsebene der Auftragsverarbeitung. § 30 Absatz 3 verlangt, im Auftrag unter anderem „die Rückgabe überlassener Datenträger und die Löschung beim Auftragsverarbeiter gespeicherter Daten nach Beendigung des Auftrags" festzulegen. Die Wortwahl verrät das Alter des Bildes: Die Norm denkt an überlassene Datenträger, nicht an Bestände wie Index, Verläufe und Protokolle, die erst beim Anbieter entstehen. Die IT-Sicherheitsverordnung der EKD stammt vom 29. Mai 2015, kennt das Wort Cloud ebenfalls nicht und verweist für den Sicherheitsstandard auf die Empfehlungen des BSI, also auf denselben Maßstab, den § 7 Absatz 2 KDG-DVO für die Nachweisebene nennt. Für evangelische Träger heißt das, wie schon bei der Klassifizierung: nicht weniger geschuldet, aber die Begründungslast liegt beim Haus. Der Katalog des § 18 Absatz 2 und das folgende Prüfraster sind dort als Orientierung brauchbar, ohne rechtlich zu binden, und die Lösch- und Rückgaberegelung, die § 30 DSG-EKD für den Auftrag verlangt, deckt den letzten Schritt gleichsinnig ab. ## Ein Prüfraster für die Beschaffung Aus § 18 in Verbindung mit § 10 und § 9 Absatz 7 ergibt sich eine Reihenfolge, die vor der Auswahl steht, nicht nach dem Pilotbetrieb. 1. **Risiko feststellen, dann Ausstiegstiefe festlegen.** Absatz 3 macht die Exit-Strategie von der Risikoanalyse abhängig. Klasse III und die Sonderfälle des § 14 verlangen eine belastbare Planung, nicht einen Satz im Vertragsanhang. 2. **Das Inventar aufnehmen, nicht den Dienst bewerten.** Sechs Bestände, sechs getrennte Antworten auf die Frage nach Rückgabe und Löschung. 3. **Die Rückgabe am Korpus prüfen, nicht am Index.** Verlangt wird der vollständige Rückerhalt der Quelldokumente samt Zuordnung zur jeweiligen Wissensbasis. Indexübernahme ist über Anbietergrenzen hinweg nicht zu erwarten. 4. **Den Wiederaufbau beziffern.** Rechenzeit und Kosten für die Neuindizierung des gesamten Bestands gehören in die Entscheidung, weil sie beim Wechsel und beim Modellwechsel gleichermaßen anfallen. 5. **Die Modelluhr in den Vertrag holen.** Zusagen zur Mindestverfügbarkeit einer Modellversion, zur Vorwarnzeit und dazu, ob automatisch auf Nachfolger gewechselt wird. Ohne diese Angaben ist Buchstabe a nicht bewertbar. 6. **Die Rechte aus Kapitel VI der Datenverordnung schriftlich abbilden.** Kündigungsfrist, Übergangsfrist, Abrufzeitraum, Exportformat, Löschung nach Ablauf und die Liste der vom Export ausgenommenen Kategorien nach Artikel 25 Absatz 2 Buchstabe f. Diese Ausnahmeliste ist die aufschlussreichste Angabe im ganzen Vertrag. 7. **Das Löschwahlrecht nach § 29 Absatz 4 Buchst. g KDG vor Vertragsschluss ausüben** und den Nachweisweg nach § 9 Absatz 7 gleich mit vereinbaren. 8. **Den Ausstieg einmal proben**, wenigstens als Testexport eines abgegrenzten Bestands. Eine Exit-Strategie, die nie ausgeführt wurde, ist eine Vermutung. Der Ertrag dieser Reihenfolge liegt nicht im Ausstieg selbst, der in den meisten Projekten nie stattfindet. Er liegt darin, dass die Fragen nach Portabilität, Abhängigkeit und Löschbarkeit zu einem Zeitpunkt gestellt werden, zu dem sie noch Verhandlungsgewicht haben. Wer sie erst nach der Inbetriebnahme stellt, bekommt dieselben Antworten, kann aber nichts mehr davon abhängig machen. § 18 Absatz 3 verlangt sie deshalb vorher. ## Quellen Alle Quellen am 06.08.2026 an der Primärquelle geprüft. Die KDG-DVO in einer amtlichen Lesefassung, die Änderungsverordnung im diözesanen Amtsblatt, die Datenverordnung im Amtsblatt der EU, die evangelischen Vorschriften in den kirchlichen Online-Nachschlagewerken. Die Inkraftsetzung der KDG-Novelle erfolgt diözesan, das Datum kann je Bistum abweichen. - 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 §§ 6, 7, 9, 10, 18, 19 und 23: [erzbistum-hamburg.de (PDF)](https://erzbistum-hamburg.de/pdf/Abteilung_Recht/Datenschutz/KDG-DVO.pdf?m=1587546982) - 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, dort Ziffer 17 (Einfügung des neuen § 18) und Ziffer 18 (bisheriger § 18 wird § 19): [erzbistumberlin.de (PDF)](https://www.erzbistumberlin.de/fileadmin/user_mount/Dokumentencenter/extern/Amtsblaetter/aktuelles_Jahr_Monatsausgaben/2026-03_Amtsblatt_Anlage_Verordnung_zur_AEnderung_der_KDG-DVO.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 § 29 Absatz 4 Buchst. g: [dbk.de (Lesefassung, PDF)](https://www.dbk.de/fileadmin/redaktion/diverse_downloads/VDD/2025_KDG_neu_Lesefassung.pdf) - Datenschutzgesetz der Evangelischen Kirche in Deutschland (DSG-EKD), für § 30 Absatz 3 (Vertragsinhalte der Auftragsverarbeitung, Rückgabe und Löschung): [kirchenrecht-ekm.de](https://www.kirchenrecht-ekm.de/document/58341) - IT-Sicherheitsverordnung der EKD (ITSVO-EKD) vom 29. Mai 2015, für § 1 Absatz 3 (Orientierung am BSI): [kirchenrecht-ekd.de](https://www.kirchenrecht-ekd.de/document/32147) - Verordnung (EU) 2023/2854 (Datenverordnung) vom 13. Dezember 2023, Amtsblatt vom 22. Dezember 2023, geltend ab dem 12. September 2025, für Artikel 2 Nummern 8, 34, 37 und 38 sowie Kapitel VI, Artikel 23, 25, 29, 30 und 31: [eur-lex.europa.eu](https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=OJ:L_202302854) - Open WebUI, Dokumentation zu Retrieval Augmented Generation, Abschnitte „Changing the Embedding Model" und „Re-indexing does not cover chat files", für die Unvereinbarkeit von Einbettungen verschiedener Modelle: [docs.openwebui.com](https://docs.openwebui.com/features/chat-conversations/rag/) - Microsoft, „Foundry Models lifecycle and support policy", Stand 24. Juli 2026, für die Abkündigungsfristen (18 Monate, Deprecation nach 12 Monaten, 60 Tage Vorwarnzeit, `410 Gone`, keine Verlängerung, Notfall-Abkündigung, getrennter Fahrplan für feinabgestimmte Modelle): [learn.microsoft.com](https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-retirements) - Nicholas Carlini u. a., „Extracting Training Data from Large Language Models" (2020/2021), für den Nachweis, dass sich einzelne Trainingsinhalte wörtlich aus einem Sprachmodell extrahieren lassen: [arxiv.org/abs/2012.07805](https://arxiv.org/abs/2012.07805) --- # Nicht klassifiziert heißt Klasse III: Was § 9 KDG-DVO über die Architektur eines KI-Projekts entscheidet > Das katholische Datenschutzrecht kennt drei Datenschutzklassen mit fest beschriebenen Mindestmaßnahmen. Wer nicht einordnet, landet automatisch in der strengsten. Was daraus für Modellzugriffe, RAG-Bestände und Auftragsverarbeiter folgt, gelesen als Architekturvorgabe. Kanonische URL: https://kirchliche-ki.de/newsletter/klassifizierung-kdg-dvo-datenschutzklassen/ · Veröffentlicht: 2026-07-30 > **Korrektur vom 13. August 2026.** Zwei Zitate aus § 14 KDG-DVO stehen jetzt im > Wortlaut der Verordnung, statt an den Satzbau dieses Textes angepasst. Der Inhalt der > Vorschrift ändert sich dadurch nicht. In der Ausgabe [Cloud oder eigener Server?](/newsletter/cloud-oder-eigener-server/) stand die These, dass nicht das Modell die erste Entscheidung ist, sondern der Ort der Verarbeitung, und dass diese Entscheidung an der Schutzklasse der Daten hängt. Diese Ausgabe holt nach, was dort offen blieb: wie die Schutzklasse eigentlich bestimmt wird, jedenfalls auf katholischer Seite. Die Antwort steht in der Durchführungsverordnung zum Gesetz über den Kirchlichen Datenschutz, kurz KDG-DVO. Sie ist für ein KI-Projekt aus einem Grund interessanter als die meisten Datenschutzvorschriften: Sie beschreibt nicht nur Grundsätze, sondern benennt Mindestmaßnahmen, und zwar technisch konkret genug, dass sich daraus Architekturentscheidungen ableiten lassen. Wer die Einordnung überspringt, trifft diese Entscheidungen trotzdem, nur unbewusst und regelmäßig zu seinen Ungunsten. Ein Hinweis zur Fassung vorweg: Die KDG-DVO wurde durch Beschluss der Vollversammlung des Verbandes der Diözesen Deutschlands vom 24. November 2025 geändert. In Kraft gesetzt wird sie diözesan, weshalb das genaue Datum je nach Bistum abweicht. Die hier zitierte amtliche Lesefassung stammt aus dem Erzbistum Hamburg (geändert am 20. Januar 2026), die Änderungsverordnung des Erzbistums Berlin trat zum 1. März 2026 in Kraft. Für die eigene Einrichtung gilt das Amtsblatt des eigenen Bistums. ## Die Kaskade in § 9 Die Norm, um die es geht, ist § 9 KDG-DVO, „Einordnung in Datenschutzklassen und Datenschutzniveau". Sie liest sich unspektakulär und hat es in sich. Sieben Absätze, von denen fünf unmittelbar auf die Systemgestaltung durchschlagen. **Absatz 1** verlangt die Einordnung in eine der drei Klassen der §§ 11 bis 13, „unter Berücksichtigung der Art der zu verarbeitenden personenbezogenen Daten und des Ausmaßes der möglichen Gefährdung". **Absatz 2** ist der für KI-Vorhaben wichtigste Satz der ganzen Verordnung: > „Bei der Einordnung personenbezogener Daten in eine Datenschutzklasse sind auch der > Zusammenhang mit anderen gespeicherten Daten, der Zweck ihrer Verarbeitung und das > anzunehmende Interesse an einer missbräuchlichen Verwendung der Daten zu > berücksichtigen." Die Einordnung bemisst sich also nicht am einzelnen Datum, sondern am Zusammenhang. Für ein Retrieval-System über eigene Bestände heißt das etwas Unbequemes: Ein Index ist mehr als die Summe seiner Dokumente. Adressliste, Protokoll und Vermerk mögen einzeln in Klasse I oder II fallen. Zusammengeführt in einem durchsuchbaren Bestand, der auf eine Frage hin genau die zusammengehörigen Stellen ausgibt, steigen sowohl der Zusammenhang als auch das „anzunehmende Interesse an einer missbräuchlichen Verwendung". Wer den Index nach dem niedrigsten enthaltenen Dokument einordnet, hat Absatz 2 nicht angewendet. **Absatz 3** regelt die Zuständigkeit: Die Einordnung erfolgt durch den Verantwortlichen und „soll in der Regel bei Erstellung des Verzeichnisses von Verarbeitungstätigkeiten vorgenommen werden"; die oder der betriebliche Datenschutzbeauftragte soll angehört werden. Praktisch bedeutet das, dass die Klassifizierung an das Verarbeitungsverzeichnis gekoppelt ist. Ein KI-Vorhaben, das dort noch nicht steht, ist auch nicht klassifiziert, und was das heißt, steht in Absatz 5. **Absatz 4** erlaubt Abweichungen „in begründeten Einzelfällen", verlangt aber die Dokumentation der Gründe. Und er zieht eine asymmetrische Schranke ein: Eine Einordnung in eine *niedrigere* Klasse setzt voraus, dass die oder der betriebliche Datenschutzbeauftragte zuvor angehört wurde. Nach oben abweichen darf man ohne diesen Schritt. Wer im Projekt also argumentiert, ein Bestand sei doch weniger heikel als er aussieht, löst damit eine Anhörungspflicht aus. **Absatz 5** ist die Vorschrift, um die es in der Überschrift geht: > „Erfolgt keine Einordnung, gilt automatisch die Datenschutzklasse III, sofern nicht > die Voraussetzungen des § 14 vorliegen." Das ist ein Fail-Safe-Default, wie man ihn aus der Systemsicherheit kennt: Der Ausfall der Entscheidung führt nicht in den laxen, sondern in den strengsten Zustand. Der Satz hat eine Konsequenz, die in Projekten regelmäßig unterschätzt wird. Eine Einrichtung, die ihre Verarbeitungstätigkeiten nie klassifiziert hat, ist nicht etwa „noch nicht so weit". Sie schuldet für sämtliche betroffenen Verarbeitungen bereits das Schutzniveau III, mit allen Mindestmaßnahmen der §§ 11 bis 13 kumulativ. Der Verweis auf § 14 macht es nicht milder, sondern strenger, dazu unten mehr. **Absatz 6** stellt klar, dass die Einordnung „die Einhaltung des dieser Datenschutzklasse entsprechenden Schutzniveaus und die Einhaltung der dort beschriebenen Mindestmaßnahmen" erfordert. Die Niveaus bauen aufeinander auf: Schutzniveau II gilt „neben dem Schutzniveau I", Schutzniveau III „neben dem Schutzniveau II". Klasse III bedeutet also die Summe aller drei Maßnahmenkataloge. **Absatz 7** betrifft Auftragsverarbeiter und ist die Vorschrift, an der sich jeder externe KI-Dienst messen lassen muss. Dazu gleich ein eigener Abschnitt. ## Was in welche Klasse fällt Die drei Klassen sind über die mögliche Beeinträchtigung der betroffenen Person definiert und jeweils mit Regelbeispielen unterlegt. | Klasse | Kriterium | Regelbeispiele aus der Verordnung | |---|---|---| | I (§ 11) | keine besonders schwerwiegende Beeinträchtigung zu erwarten | Namens- und Adressangaben ohne Sperrvermerke, Berufs-, Branchen- oder Geschäftsbezeichnungen | | II (§ 12) | Beeinträchtigung in gesellschaftlicher Stellung oder wirtschaftlichen Verhältnissen möglich | Daten über Mietverhältnisse, Geschäftsbeziehungen, Geburts- und Jubiläumsdaten | | III (§ 13) | erhebliche Beeinträchtigung möglich | besondere Kategorien nach § 4 Nr. 2 KDG, Daten über strafbare Handlungen, arbeitsrechtliche Rechtsverhältnisse, Disziplinarentscheidungen, Namens- und Adressangaben mit Sperrvermerken | Die Aufzählung in Klasse III verdient einen zweiten Blick, weil sie die typischen Bestände einer Verwaltung trifft. „Arbeitsrechtliche Rechtsverhältnisse" ist keine Randkategorie, sondern die Personalakte. Wer ein Sprachmodell auf Personalvorgänge ansetzt, arbeitet ohne weitere Prüfung in Klasse III. Dasselbe gilt für Gesundheitsdaten, die nach § 4 Nr. 2 KDG zu den besonderen Kategorien zählen, und damit für weite Teile der Arbeit in Pflege, Beratung und Eingliederungshilfe. Bemerkenswert ist der Schlusssatz von § 4 Nr. 2 KDG, der die kirchliche Perspektive sichtbar macht: „Die Zugehörigkeit zu einer Kirche oder Religionsgemeinschaft ist keine besondere Kategorie personenbezogener Daten." Was im weltlichen Recht ein sensibles Datum ist, ist im kirchlichen Kontext das Normalfalldatum der Mitgliederverwaltung. Das ist einer der Punkte, an denen ein aus der DSGVO übertragenes Klassifizierungsschema falsche Ergebnisse liefert. ## Die Vorschrift, die den Modellzugriff betrifft Interessant wird es bei den Mindestmaßnahmen. Zwei davon sind für KI-Architekturen unmittelbar einschlägig, und beide stehen schon in Klasse II, also unterhalb der Stufe, in der man ohne Einordnung ohnehin landet. Die erste ist § 12 Absatz 2 Buchstabe e: > „Die Übermittlung personenbezogener Daten außerhalb eines geschlossenen und > gesicherten Netzwerks (auch über automatisierte Schnittstellen) hat verschlüsselt zu > erfolgen. Das Verschlüsselungsverfahren ist dem aktuellen Stand der Technik und dem > jeweiligen Sicherheitsbedarf entsprechend angemessen auszuwählen." Der Klammerzusatz „auch über automatisierte Schnittstellen" ist der Punkt. Jeder Aufruf einer Modell-API ist eine Übermittlung außerhalb des geschlossenen Netzwerks über eine automatisierte Schnittstelle. Transportverschlüsselung ist dafür heute Selbstverständlichkeit, die Vorschrift ist insoweit leicht erfüllt. Die eigentliche Wirkung liegt woanders: Sie qualifiziert den API-Aufruf ausdrücklich als Übermittlung. Damit ist die Frage, ob ein externer Modellzugriff eine datenschutzrechtlich relevante Weitergabe darstellt, für den Anwendungsbereich der KDG-DVO nicht mehr diskutabel. Die zweite ist § 12 Absatz 2 Buchstabe d, der für Klasse II die Speicherung „auf zentralen Systemen in besonders gegen unbefugten Zutritt gesicherten Räumen" verlangt, „sofern keine begründeten Ausnahmefälle gegeben sind", und diese Ausnahmefälle „schriftlich dem oder der betrieblichen Datenschutzbeauftragten zu melden" sind. Für ein KI-System heißt das: Wo der Vektorindex, der Cache und die Protokolle physisch liegen, ist eine dokumentationspflichtige Entscheidung, keine Betriebsdetailfrage. Wichtig für die Zuordnung ist außerdem, dass die Verordnung den Begriff des IT-Systems weit fasst. Nach § 4 Absatz 2 sind IT-Systeme nicht nur Hardware, sondern auch „Softwarelösungen (lokal installierte oder netzwerkgestützte Programme und Anwendungen einschließlich betriebssystemnaher Software und Anwendungssoftware, die unmittelbar oder mittelbar an der Verarbeitung personenbezogener Daten beteiligt sind)". Eine KI-Anwendung ist damit ein IT-System im Sinne der Verordnung, und die Mindestmaßnahmen gelten für sie. ## Absatz 7: Warum die Anbieterbroschüre nicht reicht Wer einen externen Dienst einsetzt, muss § 9 Absatz 7 erfüllen: > „Erfolgt die Verarbeitung durch einen Auftragsverarbeiter, ist der Verantwortliche > verpflichtet, sich in geeigneter Weise, insbesondere durch persönliche Überprüfung > oder Vorlage von Nachweisen, von dem Bestehen des der jeweiligen Datenschutzklasse > entsprechenden Schutzniveaus zu überzeugen." Das ist eine aktive Überzeugungspflicht mit benannten Mitteln: persönliche Überprüfung oder Vorlage von Nachweisen. Eine Zusicherung im Vertrag erfüllt sie für sich genommen nicht, eine Produktbeschreibung erst recht nicht. Verlangt ist, dass der Verantwortliche das Bestehen des Schutzniveaus feststellt. Für die Auswahl eines KI-Dienstes ergibt sich daraus eine brauchbare Prüfliste, die sich direkt aus den Mindestmaßnahmen ableitet und nicht aus dem Marketingmaterial: Welche Nachweise gibt es für den Zutrittsschutz der Rechenzentren, für die Verschlüsselung im Transport und in der Ablage, für die Löschung bei Weitergabe oder Außerbetriebnahme von Systemen, für die Trennung der Sicherungskopien? Lassen sich diese Nachweise vorlegen, oder wird auf eine allgemeine Zertifizierung verwiesen, die zu den konkreten Mindestmaßnahmen nichts sagt? Ein Anbieter, der die Frage nach konkreten Nachweisen als unüblich behandelt, ist für eine Verarbeitung ab Klasse II schwer einsetzbar, unabhängig davon, wie überzeugend seine Datenschutzseite klingt. ## § 14: die Klasse oberhalb von Klasse III Der Verweis in § 9 Absatz 5 auf § 14 führt zu der Vorschrift, die im kirchlichen Datenschutzrecht keine Entsprechung im weltlichen Recht hat, und die für KI-Projekte die härteste Grenze zieht. § 14 Absatz 1 stellt fest, dass Daten, die dem Beichtgeheimnis oder dem Seelsorgegeheimnis unterliegen, „in besonders hohem Maße schutzbedürftig" sind: „Ihre Ausspähung oder Verlautbarung würde dem Vertrauen in die Verschwiegenheit katholischer Dienststellen und Einrichtungen schweren Schaden zufügen." Für das Beichtgeheimnis ist die Rechtsfolge absolut. § 14 Absatz 2: > „Das Beichtgeheimnis nach cc. 983 ff. CIC ist zu wahren; personenbezogene Daten, die > dem Beichtgeheimnis unterliegen, dürfen nicht verarbeitet werden." Kein Schutzniveau, keine Abwägung, keine technische Maßnahme, die das heilt. Ein Verarbeitungsverbot. Für das Seelsorgegeheimnis erlaubt Absatz 3 eine Verarbeitung nur, wenn „dem besonderen Schutzniveau angepasste, erforderlichenfalls über das Schutzniveau der Datenschutzklasse III hinausgehende technische und organisatorische Maßnahmen ergriffen werden". Die Verordnung kennt an dieser Stelle also faktisch eine Stufe oberhalb ihrer höchsten Klasse. Und sie wird ungewöhnlich konkret, was eine solche Maßnahme sein kann. Absatz 4: > „Eine Maßnahme im Sinne des Absatzes 3 kann, wenn die Verarbeitung auf IT-Systemen > erfolgt, insbesondere die Unterhaltung eines eigenen Servers oder einer eigenen > Datenablage in einem Netzwerk ohne externe Datenverbindung sein." Das ist bemerkenswert. Das kirchliche Datenschutzrecht benennt für seine schutzbedürftigsten Bestände als Regelbeispiel eine Architektur, nämlich einen eigenen Server in einem Netzwerk ohne externe Datenverbindung. Übersetzt in die Sprache eines KI-Projekts: lokales Modell, lokaler Index, keine ausgehende Verbindung. Wer für Seelsorgebestände einen externen Dienst erwägt, argumentiert gegen ein ausdrückliches Regelbeispiel der Verordnung. Zwei Absätze erweitern das noch. Absatz 5 verlangt für Seelsorge „außerhalb eines geschlossenen Netzwerkes" geeignete, erforderlichenfalls über Klasse III hinausgehende Maßnahmen nach dem aktuellen Stand der Technik. Und Absatz 6 dehnt die Absätze 3 bis 5 auf personenbezogene Daten aus, „die in vergleichbarer Weise schutzbedürftig sind". Diese Öffnung ist praktisch wichtig, weil sie den Anwendungs bereich über die klassische Seelsorge hinaus trägt, etwa auf Beratungskontexte mit vergleichbarem Vertrauensverhältnis. Für [RAG-Bestände](/newsletter/rag-datenschutzkonform-dsk/) folgt daraus eine klare Konsequenz: Seelsorgliche Aufzeichnungen und vergleichbar schutzbedürftige Vorgänge gehören nicht in denselben Index wie die allgemeine Verwaltungsablage, und ihre Aussonderung muss vor der Indexierung stattfinden, nicht durch eine Filterregel bei der Ausgabe. Ein Berechtigungsfilter, der erst auf den Treffern arbeitet, setzt voraus, dass die Daten bereits verarbeitet und eingebettet wurden. Genau das ist beim Beichtgeheimnis untersagt. ## Die evangelische Gegenprobe Das Klassenschema ist katholisches Recht. Das DSG-EKD kennt keine Datenschutzklassen I bis III. Es formuliert die technischen und organisatorischen Maßnahmen stattdessen risikobasiert, also in der Struktur, die auch die DSGVO verwendet: geeignete Maßnahmen unter Berücksichtigung von Stand der Technik, Implementierungskosten, Art, Umfang, Umständen und Zwecken der Verarbeitung sowie der Eintrittswahrscheinlichkeit und Schwere der Risiken. Für die Praxis heißt das nicht, dass evangelische Träger weniger schulden, sondern dass die Begründungslast anders verteilt ist. Wo ein katholischer Träger auf einen Katalog verweisen kann und im Zweifel in Klasse III landet, muss ein evangelischer Träger die Angemessenheit seiner Maßnahmen selbst herleiten und dokumentieren. Der Katalog der KDG-DVO ist dabei als Orientierung brauchbar, ohne rechtlich zu binden. Und die Regel aus der Ausgabe [Geeignet, nicht bestimmt](/newsletter/mitbestimmung-geeignet-mvg-ekd/) gilt hier genauso: nicht konfessionsübergreifend argumentieren, sondern das jeweils geltende Recht anwenden. ## Eine Reihenfolge für das nächste Projekt Aus den Vorschriften ergibt sich eine Reihenfolge, die sich von der üblichen Projektpraxis unterscheidet, weil die Klassifizierung vor und nicht nach der Werkzeugauswahl steht. 1. **Bestand abgrenzen und im Verarbeitungsverzeichnis führen.** Ohne Eintrag keine Einordnung, und ohne Einordnung greift Klasse III nach § 9 Absatz 5. 2. **Auf § 14 prüfen, bevor irgendetwas anderes geprüft wird.** Enthält der Bestand Daten des Beichtgeheimnisses, ist die Verarbeitung untersagt. Enthält er Seelsorgedaten oder vergleichbar schutzbedürftige Daten, ist die Architektur nach Absatz 4 vorgezeichnet. 3. **Einordnen, und dabei Absatz 2 anwenden.** Nicht das einzelne Dokument bewerten, sondern den Zusammenhang, den ein durchsuchbarer Index herstellt. 4. **Betrieblich Datenschutzbeauftragte anhören.** Nach Absatz 3 ohnehin vorgesehen, nach Absatz 4 zwingend, wenn eine niedrigere Klasse angesetzt werden soll. 5. **Erst jetzt die Architektur wählen.** Das Schutzniveau ist die Anforderung, die Architektur die Antwort darauf, nicht umgekehrt. 6. **Bei externen Diensten die Nachweise nach Absatz 7 einholen**, entlang der konkreten Mindestmaßnahmen, nicht entlang allgemeiner Zusicherungen. 7. **Die Einordnung und die Gründe dokumentieren.** Nach Absatz 4 ausdrücklich verlangt, sobald vom Regelfall abgewichen wird, und im Übrigen die einzige Art, die Entscheidung später belegen zu können. Der Aufwand dieser Reihenfolge ist überschaubar, ihr Nutzen liegt darin, dass sie die teure Reihenfolge vermeidet: erst ein System bauen, dann feststellen, dass der Bestand ein Schutzniveau verlangt, das die gewählte Architektur nicht liefern kann. § 9 Absatz 5 sorgt dafür, dass diese Feststellung nie zugunsten des Projekts ausfällt. ## Quellen Alle Quellen am 29.07.2026 an der Primärquelle geprüft, die KDG-DVO in einer amtlichen Lesefassung und die Änderungsverordnung im diözesanen Amtsblatt. - 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 §§ 4, 9, 11, 12, 13 und 14: [erzbistum-hamburg.de (PDF)](https://erzbistum-hamburg.de/pdf/Abteilung_Recht/Datenschutz/KDG-DVO.pdf?m=1587546982) - 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: [erzbistumberlin.de (PDF)](https://www.erzbistumberlin.de/fileadmin/user_mount/Dokumentencenter/extern/Amtsblaetter/aktuelles_Jahr_Monatsausgaben/2026-03_Amtsblatt_Anlage_Verordnung_zur_AEnderung_der_KDG-DVO.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 Nr. 2: [dbk.de (Lesefassung, PDF)](https://www.dbk.de/fileadmin/redaktion/diverse_downloads/VDD/2025_KDG_neu_Lesefassung.pdf) - Datenschutzgesetz der Evangelischen Kirche in Deutschland (DSG-EKD), für § 27 (technische und organisatorische Maßnahmen, risikobasiert statt klassifizierend): [kirchenrecht-ekm.de](https://www.kirchenrecht-ekm.de/document/58341) --- # Der AI Act nach dem Digital Omnibus: Welche Fristen für kirchliche Träger jetzt gelten > Seit dem 27. Juli 2026 ist die Digital-Omnibus-Verordnung zur KI in Kraft. Sie verschiebt die Hochrisiko-Fristen um bis zu zwei Jahre und formuliert die KI-Kompetenzpflicht aus Artikel 4 neu. Eine Fristenübersicht aus der Betreiber-Perspektive, mit dem Wortlaut beider Fassungen. Kanonische URL: https://kirchliche-ki.de/newsletter/ai-act-nach-dem-digital-omnibus/ · Veröffentlicht: 2026-07-29 Wer in den vergangenen Monaten eine Planung für die KI-Verordnung aufgesetzt hat, arbeitet seit dieser Woche mit veralteten Daten. Am 24. Juli 2026 wurde die Digital-Omnibus-Verordnung zur KI im Amtsblatt veröffentlicht, am 27. Juli 2026 ist sie in Kraft getreten. Sie ändert über die KI-Verordnung hinaus zwei weitere Verordnungen, verschiebt zentrale Geltungstermine und formuliert ausgerechnet die Pflicht neu, die für Träger bisher am greifbarsten war: die KI-Kompetenz nach Artikel 4. Der in vielen Beiträgen genannte 2. August 2026 bleibt ein wichtiges Datum, ist aber nur noch ein Teil der Antwort. Dieser Text sortiert die Lage aus der Perspektive einer Einrichtung, die KI-Systeme betreibt statt sie herzustellen, also aus der Betreiber-Perspektive. Ein Ergebnis vorweg, weil die Schlagzeilen in eine andere Richtung zeigen: Für kirchliche und diakonische Einrichtungen ist die Änderung keine Entwarnung. Sie verschiebt Termine und lockert eine Formulierung, sie ändert aber nichts an den Pflichten, aus denen sich der Qualifizierungsbedarf in diesem Sektor tatsächlich ergibt. Warum das so ist, steht weiter unten unter „Warum die Schulungsfrage damit nicht erledigt ist". ## Was genau in Kraft getreten ist Die maßgebliche Rechtsquelle ist die Verordnung (EU) 2026/1744 des Europäischen Parlaments und des Rates vom 8. Juli 2026 zur Änderung der Verordnungen (EU) 2024/1689, (EU) 2018/1139 und (EU) 2023/1230 im Hinblick auf die Vereinfachung der Umsetzung harmonisierter Vorschriften für künstliche Intelligenz. Der Kurzname im Amtsblatt lautet Digital-Omnibus-Verordnung zur KI. Zwei Details der Schlussbestimmung sind für die Praxis wichtiger, als sie aussehen. Artikel 4 der Änderungsverordnung lautet: > „Diese Verordnung tritt am dritten Tag nach ihrer Veröffentlichung im Amtsblatt > der Europäischen Union in Kraft." Ein aufgeschobener Geltungsbeginn folgt nicht. Anders als bei der KI-Verordnung selbst, deren Bestimmungen gestaffelt anwendbar werden, gelten die Änderungen also unmittelbar seit dem 27. Juli 2026. Wer eine Bestandsaufnahme gegen den bisherigen Wortlaut geprüft hat, prüft seither gegen einen Text, den es so nicht mehr gibt. ## Artikel 4: von der Ergebnispflicht zur Förderpflicht Die auffälligste Änderung für Träger betrifft die KI-Kompetenz. Die Änderungsziffer 5 der Verordnung 2026/1744 lautet schlicht „Artikel 4 erhält folgende Fassung". Der Vergleich lohnt sich im Wortlaut. **Bisher (Verordnung (EU) 2024/1689, Artikel 4):** > „Die Anbieter und Betreiber von KI-Systemen ergreifen Maßnahmen, um nach besten > Kräften sicherzustellen, dass ihr Personal und andere Personen, die in ihrem > Auftrag mit dem Betrieb und der Nutzung von KI-Systemen befasst sind, über ein > ausreichendes Maß an KI-Kompetenz verfügen [...]" **Seit dem 27. Juli 2026 (Artikel 4 Absatz 1 neue Fassung):** > „Die Anbieter und Betreiber von KI-Systemen ergreifen Maßnahmen, um die > Entwicklung der KI-Kompetenz ihres Personals und anderer Personen zu unterstützen, > die in ihrem Auftrag mit dem Betrieb und der Nutzung von KI-Systemen befasst sind > [...] Diese Verpflichtung verpflichtet Anbieter oder Betreiber nicht, für > irgendeine Person ein bestimmtes Niveau an KI-Kompetenz zu garantieren." Der Unterschied liegt im Bezugspunkt. Die alte Fassung war auf ein Ergebnis gerichtet, nämlich darauf, dass die betroffenen Personen über ein ausreichendes Maß an Kompetenz verfügen. Die neue Fassung ist auf eine Tätigkeit gerichtet, nämlich darauf, die Entwicklung dieser Kompetenz zu unterstützen. Der angefügte Satz stellt zusätzlich klar, dass kein bestimmtes Kompetenzniveau geschuldet ist. Vor einer Überinterpretation sei gewarnt, in beide Richtungen. Die Pflicht ist nicht entfallen, sie steht weiterhin im verfügenden Teil der Verordnung und gilt unverändert seit dem 2. Februar 2025, denn die Kapitel I und II bleiben auch nach der Änderung ab diesem Datum anwendbar. Umgekehrt war die alte Fassung mit ihrem „nach besten Kräften" schon bisher keine strikte Erfolgshaftung. Verschoben hat sich also nicht das Ob, sondern der Maßstab, an dem eine Aufsicht die Erfüllung misst. Den Grund nennt der Verordnungsgeber selbst. Erwägungsgrund 8 der Änderungs verordnung hält fest, Erfahrungen der Interessenträger zeigten, dass strenge Verpflichtungen zur Sicherstellung eines ausreichenden Maßes an KI-Kompetenz „nicht für alle Arten von Anbietern und Betreibern geeignet" seien und insbesondere für kleinere Unternehmen zusätzlichen Befolgungsaufwand verursachten, während KI-Kompetenz „unabhängig von gesetzlichen Verpflichtungen und möglichen Sanktionen eine strategische Priorität sein sollte". ## Warum die Schulungsfrage damit nicht erledigt ist Für die Planung eines Trägers ist die entscheidende Frage nicht, wie streng Artikel 4 formuliert ist, sondern über welche Wege ein Kompetenzmangel überhaupt Folgen hat. Drei Wege sind zu unterscheiden, und nur einer davon ist vom Digital Omnibus berührt. **Erstens, das Bußgeldrecht der KI-Verordnung.** Hier ändert sich nichts, weil es nie einschlägig war. Der Bußgeldkatalog in Artikel 99 Absatz 4 zählt die sanktionierten Pflichten abschließend auf: die Pflichten der Anbieter nach Artikel 16, der Bevollmächtigten nach Artikel 22, der Einführer nach Artikel 23, der Händler nach Artikel 24, der Betreiber nach Artikel 26 sowie die Anforderungen an notifizierte Stellen. Artikel 4 steht nicht in dieser Liste, weder vorher noch nachher. Ein Verstoß gegen die KI-Kompetenzpflicht ist als solcher nicht bußgeld bewehrt. Wer für Schulungen mit drohenden Bußgeldern nach der KI-Verordnung argumentiert, argumentiert an der Norm vorbei. **Zweitens, die allgemeine Sorgfaltspflicht.** Die Bundesnetzagentur hat in ihrem Hinweispapier zu Artikel 4 vom Juni 2025 die praktisch wichtigste Formulierung geprägt: > „Ein Mangel an KI-Kompetenz kann als Verletzung der Sorgfaltspflicht angesehen > werden, insbesondere wenn dadurch ein Schaden entsteht. Daher empfiehlt die > Bundesnetzagentur, dass Organisationen ihre Maßnahmen zur Sicherstellung von > KI-Kompetenz gut dokumentieren." Dieser Weg führt nicht über die KI-Verordnung, sondern über die allgemeinen Regeln zur Organisationsverantwortung. Er hängt deshalb nur mittelbar am genauen Wortlaut von Artikel 4. Wenn in einer Einrichtung ein Schaden entsteht, weil eine Mitarbeiterin ein KI-System ohne die nötige Einweisung eingesetzt hat, ist die Frage, ob die Organisation zumutbare Vorkehrungen getroffen hat. Diese Frage stellt sich unabhängig davon, ob die Verordnung ein Kompetenzniveau garantiert sehen will oder dessen Entwicklung unterstützt. Ein Hinweis zur Aktualität dieser Quelle gehört dazu: Das Hinweispapier stammt vom Juni 2025 und bezieht sich ausdrücklich auf die alte Fassung von Artikel 4. Auch die zugehörige Informationsseite der Bundesnetzagentur zitierte am 29. Juli 2026, also zwei Tage nach Inkrafttreten der Änderung, noch den bisherigen Wortlaut. Das ist bei einer erst wenige Tage alten Verordnung wenig überraschend, sollte aber davon abhalten, behördliche Handreichungen derzeit ungeprüft als aktuellen Stand zu übernehmen. **Drittens, das kirchliche Datenschutzrecht.** Dieser Weg ist vom Digital Omnibus überhaupt nicht berührt, und für kirchliche und diakonische Einrichtungen ist er der belastbarste. Er verdient deshalb mehr als eine Randnotiz, denn hier stehen die Pflichten nicht im Konjunktiv. Beide Kirchengesetze verpflichten die bei der Datenverarbeitung tätigen Personen förmlich auf das Datengeheimnis, schriftlich und bei Aufnahme der Tätigkeit (§ 26 DSG-EKD, § 5 KDG). Beide kennen darüber hinaus eine ausdrückliche Unterrichtungs- und Schulungsaufgabe. Auf evangelischer Seite gehört es zu den Aufgaben der örtlich Beauftragten, „die bei der Verarbeitung personenbezogener Daten tätigen Personen zu informieren und zu schulen" (§ 38 Nr. 3 DSG-EKD); die verantwortliche Stelle hat ihnen dafür Fort- und Weiterbildung zu ermöglichen und die Kosten zu tragen (§ 37 Abs. 3 DSG-EKD). Auf katholischer Seite haben betriebliche Datenschutzbeauftragte „die bei der Verarbeitung personenbezogener Daten tätigen Personen durch geeignete Maßnahmen mit den Vorschriften dieses Gesetzes sowie anderer Vorschriften über den Datenschutz und mit den jeweiligen besonderen Erfordernissen des Datenschutzes vertraut zu machen" (§ 38 Buchst. c KDG). Diese Pflichten sind dauerhaft und nicht an ein Stichdatum gebunden. Sie greifen genau dann, wenn ein neues Werkzeug neue Anforderungen an den Umgang mit personenbezogenen Daten stellt, und ein KI-System, in das Mitarbeitende Texte, Akteninhalte oder Gesprächsnotizen eingeben, ist ein solches Werkzeug. Eine europäische Verordnung, die ihre eigene Kompetenzpflicht anders formuliert, ändert daran nichts. Für die Planung heißt das: Wer seinen Qualifizierungsbedarf allein an der KI-Verordnung aufgehängt hat, hat ihn am schwächeren der beiden Anker befestigt, und dieser Anker hat am 27. Juli 2026 nachgegeben. ### Was die Änderung also bedeutet, und was nicht Zusammengefasst, weil die Verkürzung „KI-Kompetenzpflicht gelockert" in Umlauf ist und in die Irre führt: - **Nicht entfallen** ist die Pflicht aus Artikel 4. Sie steht weiter im verfügenden Teil der Verordnung und gilt seit dem 2. Februar 2025. - **Nicht geändert** hat sich die Rechtslage beim Bußgeld, weil Artikel 4 dort nie erfasst war. Wer bisher mit Bußgeldern nach der KI-Verordnung argumentiert hat, lag schon vorher falsch. - **Nicht berührt** sind die Unterrichtungs-, Schulungs- und Verpflichtungstatbestände des kirchlichen Datenschutzrechts. Für Einrichtungen unter KDG oder DSG-EKD ist das der eigentlich maßgebliche Rahmen. - **Nicht aufgehoben** ist die Organisationsverantwortung, wenn aus einem unsachgemäßen KI-Einsatz ein Schaden entsteht. - **Geändert** hat sich der Maßstab innerhalb der KI-Verordnung: geschuldet ist die Unterstützung der Kompetenzentwicklung, nicht ein garantiertes Kompetenzniveau. Praktisch verschiebt das die Begründung, nicht den Bedarf. Wer die Änderung als Anlass nimmt, Qualifizierung zu streichen, streicht sie an einer Stelle, an der die KI-Verordnung ohnehin nie die tragende Pflicht war. ## Die verschobenen Hochrisiko-Fristen Der eigentliche Kern der Änderungsverordnung ist die neue Zeitachse für Hochrisiko-KI-Systeme. Die Begründung ist bemerkenswert offen: Der Verordnungsgeber benennt die verzögerte Verfügbarkeit von Normen und gemeinsamen Spezifikationen sowie die verzögerte Einrichtung der zuständigen nationalen Behörden und hält fest, es sei „nicht gerechtfertigt", den ursprünglichen Geltungsbeginn 2. August 2026 beizubehalten. Artikel 113 Absatz 3 Buchstabe c der KI-Verordnung lautet in der neuen Fassung, dass die Anforderungen an Hochrisiko-KI-Systeme aus Kapitel III Abschnitte 1, 2 und 3 gelten ab dem - **2. Dezember 2027** für Systeme, die nach Artikel 6 Absatz 2 und Anhang III als hochriskant eingestuft sind, und dem - **2. August 2028** für Systeme, die nach Artikel 6 Absatz 1 und Anhang I als hochriskant eingestuft sind, also für KI als Sicherheitsbauteil in Produkten, die bereits sektoralem Recht unterliegen. Für Träger ist der erste Termin der relevante. Anhang III erfasst unter Nummer 4 die Bereiche Beschäftigung und Personalmanagement, ausdrücklich einschließlich Systemen zur Sichtung und Filterung von Bewerbungen sowie zur Bewertung von Leistung und Verhalten Beschäftigter. Nummer 5 erfasst die Zugänglichkeit grundlegender privater und öffentlicher Dienste, darunter Systeme, mit denen Behörden oder Stellen in deren Namen den Anspruch auf Unterstützungsleistungen beurteilen. Wer solche Vorhaben in der Pipeline hat, gewinnt sechzehn Monate. Wer sie als erledigt abgehakt hatte, weil sie 2026 ohnehin nicht mehr zu schaffen waren, sollte neu rechnen. Zwei Einschränkungen sind wichtig. Die Verschiebung betrifft die Anforderungen und Pflichten aus Kapitel III, nicht die Verbote aus Artikel 5, und sie ist kein Freibrief für Bestandssysteme: Für Hochrisiko-KI-Systeme, die bestimmungsgemäß von Behörden verwendet werden, bleibt es dabei, dass Anbieter und Betreiber die erforderlichen Maßnahmen bis zum 2. August 2030 treffen. ## Was am 2. August 2026 dennoch beginnt Der allgemeine Geltungsbeginn der KI-Verordnung bleibt unangetastet. Drei Punkte werden für Betreiber jetzt praktisch. **Transparenzpflichten nach Artikel 50.** Betreiber eines KI-Systems, das Bild-, Ton- oder Videoinhalte erzeugt oder manipuliert, die ein Deepfake sind, müssen offenlegen, dass die Inhalte künstlich erzeugt oder manipuliert wurden. Für Texte gilt eine engere Regel: Wird ein KI-erzeugter Text veröffentlicht, um die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren, ist die künstliche Erzeugung offenzulegen, es sei denn, der Inhalt wurde einer menschlichen Überprüfung oder redaktionellen Kontrolle unterzogen und eine Person trägt die redaktionelle Verantwortung. Für die Öffentlichkeitsarbeit eines Trägers ist das die entscheidende Weiche: Eine dokumentierte redaktionelle Verantwortung löst die Kennzeichnungsfrage, ein unkontrollierter Automatismus nicht. Die Änderungsverordnung gewährt hier eine Übergangsfrist, allerdings nur auf der Anbieterseite: Anbieter generativer Systeme, die bereits vor dem 2. August 2026 in Verkehr gebracht wurden, müssen der maschinenlesbaren Kennzeichnungspflicht nach Artikel 50 Absatz 2 erst bis zum 2. Dezember 2026 nachkommen. **Neue Verbote mit eigenem Datum.** Die Änderungsverordnung fügt Artikel 5 zwei weitere verbotene Praktiken hinzu, die abweichend erst ab dem 2. Dezember 2026 gelten. Beide betreffen generative Systeme: die Erzeugung intimer oder sexualisierter Darstellungen bestimmbarer Personen ohne deren ausdrückliche Zustimmung sowie die Erzeugung von Material im Sinne der Richtlinie 2011/93/EU. Die seit dem 2. Februar 2025 geltenden Verbote bleiben unberührt, und für sie gilt weiterhin der schärfste Bußgeldrahmen der Verordnung von bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Jahresumsatzes. **Eine zuständige Behörde in Deutschland.** Der Bundestag hat am 11. Juni 2026 das Gesetz zur Durchführung der Verordnung (EU) 2024/1689 beschlossen (Bundestagsdrucksache 21/4594, angenommen in der Fassung der Beschlussempfehlung 21/6407); der Bundesrat hat am 10. Juli 2026 zugestimmt. Die Bundesnetzagentur wird zentrale Marktüberwachungsbehörde, richtet ein Koordinierungs- und Kompetenzzentrum sowie eine unabhängige KI-Marktüberwachungskammer ein und wird zentrale Anlauf- und Beschwerdestelle. Der letzte Punkt ist der praktisch folgenreichste: Ab August gibt es eine benannte Stelle, an die sich Betroffene wenden können. Bis dahin gab es Pflichten ohne Adressat für Beschwerden. ## Fristenübersicht aus der Betreiber-Perspektive | Datum | Was gilt | |---|---| | 2. Februar 2025 | Kapitel I und II: Begriffe, Verbote nach Artikel 5, KI-Kompetenz nach Artikel 4 (seit 27.07.2026 in neuer Fassung) | | 2. August 2025 | Pflichten der Anbieter von KI-Modellen mit allgemeinem Verwendungszweck; Sanktionsvorschriften | | 27. Juli 2026 | Digital-Omnibus-Verordnung in Kraft, neue Fassung von Artikel 4 | | 2. August 2026 | Allgemeiner Geltungsbeginn: Transparenzpflichten nach Artikel 50, Governance, nationale Marktüberwachung | | 2. Dezember 2026 | Neue Verbote nach Artikel 5; Ende der Übergangsfrist für die Kennzeichnung nach Artikel 50 Absatz 2 bei Bestandssystemen | | 2. Dezember 2027 | Hochrisiko-Pflichten für Systeme nach Anhang III (unter anderem Beschäftigung, Zugang zu grundlegenden Diensten) | | 2. August 2028 | Hochrisiko-Pflichten für Systeme nach Anhang I (Sicherheitsbauteile in regulierten Produkten) | | 2. August 2030 | Bestandssysteme, die bestimmungsgemäß von Behörden verwendet werden | ## Was das für die Planung bedeutet Vier Konsequenzen, die sich aus der neuen Lage ergeben. **Die Fristenlage nicht als Entwarnung lesen.** Verschoben wurden die Pflichten für Hochrisiko-Systeme, und zwar mit der Begründung, dass Normen und Behördenstrukturen fehlten. Die inhaltlichen Anforderungen an ein Personalauswahl- oder Leistungsbewertungssystem sind dieselben geblieben, sie sind nur später durchsetzbar. Wer die gewonnene Zeit für die Klassifizierung des eigenen Systembestands nutzt, steht 2027 anders da als jemand, der sie verstreichen lässt. **Die eigene Rolle sauber bestimmen.** Fast alle Pflichten hängen daran, ob eine Einrichtung Anbieter oder Betreiber ist. Ein Träger, der ein zugekauftes System lediglich einsetzt, ist Betreiber. Wer ein System jedoch unter eigenem Namen bereitstellt oder ein Bestandssystem wesentlich verändert, kann in die Anbieterrolle rutschen, und damit in den Bußgeldkatalog des Artikels 99 Absatz 4. Diese Abgrenzung gehört dokumentiert, bevor ein Projekt startet. **Kompetenzmaßnahmen dokumentieren, aber richtig begründet.** Die Empfehlung der Bundesnetzagentur, Maßnahmen zu dokumentieren, bleibt sinnvoll, und ihre vier Grundsteine sind eine brauchbare Struktur: individuellen Bedarf ermitteln, Maßnahmen rollengerecht ausgestalten, regelmäßig auffrischen, Art, Umfang und Teilnehmende dokumentieren. Die Begründung sollte sich allerdings nicht auf ein Bußgeld stützen, das es für Artikel 4 nicht gibt, sondern auf die Organisationsverantwortung und auf die Schulungs- und Sensibilisierungspflichten des kirchlichen Datenschutzrechts. **Behördliche Handreichungen mit Datum lesen.** Der Digital Omnibus ist wenige Tage alt. Leitfäden, Checklisten und Schulungsunterlagen, die vor dem 27. Juli 2026 entstanden sind, beschreiben in den hier behandelten Punkten den bisherigen Rechtsstand. Das gilt auch für Material von Aufsichtsbehörden. Vor der Übernahme einer Aussage lohnt der Blick auf das Datum des Dokuments. ## Quellen Alle Quellen am 29.07.2026 an der Primärquelle geprüft, der Verordnungstext im Amtsblatt in der deutschen Sprachfassung. - Verordnung (EU) 2026/1744 vom 8. Juli 2026 (Digital-Omnibus-Verordnung zur KI), ABl. L, 2026/1744, 24.7.2026: [data.europa.eu/eli/reg/2026/1744/oj](https://data.europa.eu/eli/reg/2026/1744/oj) - Verordnung (EU) 2024/1689 (KI-Verordnung), ABl. L, 2024/1689, 12.7.2024, für Artikel 4 alte Fassung, Artikel 50, Artikel 99, Artikel 113 und Anhang III: [data.europa.eu/eli/reg/2024/1689/oj](https://data.europa.eu/eli/reg/2024/1689/oj) - Bundesnetzagentur, Hinweispapier „KI-Kompetenzen nach Artikel 4 KI-Verordnung", Juni 2025: [bundesnetzagentur.de](https://www.bundesnetzagentur.de/DE/Fachthemen/Digitales/KI/_functions/Hinweispapier.pdf?__blob=publicationFile&v=2) - Bundesnetzagentur, Informationsseite zur KI-Kompetenz (Stand der Abfrage 29.07.2026, noch mit dem bisherigen Wortlaut des Artikels 4): [bundesnetzagentur.de](https://www.bundesnetzagentur.de/DE/Fachthemen/Digitales/KI/7_Kompetenz/start.html) - Deutscher Bundestag, Beschluss zum Gesetz zur Durchführung der Verordnung (EU) 2024/1689 am 11. Juni 2026, Drucksachen 21/4594 und 21/6407: [bundestag.de](https://www.bundestag.de/dokumente/textarchiv/2026/kw24-de-ki-1183820) - 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 § 5 und § 38 Buchst. c: [dbk.de (Lesefassung, PDF)](https://www.dbk.de/fileadmin/redaktion/diverse_downloads/VDD/2025_KDG_neu_Lesefassung.pdf) - Datenschutzgesetz der Evangelischen Kirche in Deutschland (DSG-EKD), für § 26, § 37 Abs. 3 und § 38 Nr. 3: [kirchenrecht-ekm.de](https://www.kirchenrecht-ekm.de/document/58341) --- # Open WebUI unter der Lupe: die Software hinter vielen datenschutzfreundlichen KI-Arbeitsplätzen > Ob eigener Server oder EU-Plattform: sehr oft ist die Oberfläche dieselbe quelloffene Software. Was Open WebUI mitbringt, warum die Voreinstellungen nicht die Empfehlungen sind und weshalb die Lizenzfrage ab 50 Nutzern interessant wird. Kanonische URL: https://kirchliche-ki.de/newsletter/open-webui-unter-der-lupe/ · Veröffentlicht: 2026-07-23 In den bisherigen Ausgaben ging es um die Architekturfrage: [Cloud oder eigener Server](/newsletter/cloud-oder-eigener-server/), und dazwischen der [EU-gehostete Mittelweg](/newsletter/eu-gehostete-ki-ohne-speicherung/). Wer einen dieser datenschutzfreundlichen Wege weiterverfolgt, stößt früher oder später auf immer dieselbe Software: **Open WebUI**. Sie ist der De-facto-Standard für selbst betriebene KI-Oberflächen und steckt auch hinter etlichen europäischen Plattform-Angeboten, mal sichtbar, mal umbenannt. Grund genug, sie sich einmal nüchtern anzusehen: was sie kann, wo die Arbeit liegt, und welche Lizenzfrage kaum jemand auf dem Zettel hat. ## Was Open WebUI ist Open WebUI ist eine quelloffene, selbst gehostete Weboberfläche für KI-Sprachmodelle, nach eigener Beschreibung „designed to operate entirely offline". Das Projekt gehört mit rund 146.000 Sternen auf GitHub (Stand 23.07.2026) zu den größten Open-Source-Projekten im KI-Umfeld und wird in hoher Schlagzahl weiterentwickelt. Der architektonische Kernpunkt: Die Oberfläche ist vom Modell getrennt. Open WebUI spricht wahlweise mit lokal laufenden Modellen (etwa über Ollama) oder mit jedem Dienst, der die verbreitete OpenAI-kompatible Schnittstelle anbietet, also auch mit europäischen Anbietern. Für die Schutzklassen-Logik aus der ersten Ausgabe heißt das: **Eine Oberfläche, verschiedene Backends.** Verwaltungstexte können über einen EU-Dienst laufen, sensiblere Verarbeitungen über ein Modell im eigenen Haus, ohne dass die Nutzenden die Oberfläche wechseln müssen. ## Was für Träger drinsteckt Vier eingebaute Funktionen sind für kirchliche Häuser und Sozialträger besonders relevant, alle ohne Zusatzsoftware: **Mehrbenutzerbetrieb mit Rollen und Gruppen.** Nutzerverwaltung, Rechtevergabe und Gruppen sind eingebaut. Wissensbestände und vorkonfigurierte Assistenten lassen sich gezielt einzelnen Gruppen freigeben, etwa der Verwaltung, dem Leitungskreis oder einer Einrichtung. **Wissensdatenbanken (RAG).** Dokumente lassen sich hochladen und als durchsuchbare Wissensbasis in Gespräche einbinden, vom Organisationshandbuch bis zur Dienstvereinbarung. Was dabei datenschutzrechtlich zu beachten ist, war Thema der Ausgabe zur [DSK-Orientierungshilfe](/newsletter/rag-datenschutzkonform-dsk/). **Vordefinierte Assistenten.** Aus einem Basismodell plus Systemanweisung entsteht ein wiederverwendbarer Assistent, etwa für Protokolle, Stellenausschreibungen oder Gemeindekommunikation. Das ist reine Konfiguration, kein Programmieren, und in der Praxis der schnellste Weg, aus einem „leeren Chatfenster" ein Werkzeug zu machen, das Mitarbeitende ohne Prompt-Erfahrung nutzen können. **Diktat und Transkription ohne Cloud.** Die Spracherkennung läuft standardmäßig lokal über Whisper, ohne API-Schlüssel und ohne externen Dienst. Aufnahmen von Sitzungen werden also im Haus transkribiert. In der Praxis lohnt für deutsche Aufnahmen der Wechsel vom voreingestellten kleinen auf ein größeres Whisper-Modell, was wiederum Rechenleistung kostet. Erwähnenswert ist außerdem das eingebaute **Audit-Log**: Wer nachvollziehen muss, wer das System wann genutzt hat, kann das über eine Einstellung aktivieren. Vorsicht bei der Gesprächigkeit dieser Protokollierung: In der höchsten Stufe landen komplette Ein- und Ausgaben im Protokoll, was ein eigenes Datenschutzthema schafft. Die Metadaten-Stufe ist für die meisten Häuser der vernünftige Kompromiss. ## Die Lizenzfrage, die ab 50 Nutzern interessant wird Open WebUI ist frei nutzbar, auch kommerziell. Aber es steht seit Version 0.6.6 (April 2025) nicht mehr unter der klassischen BSD-3-Lizenz, sondern unter einer eigenen „Open WebUI License" mit einer **Branding-Klausel**: Der Name und das Logo „Open WebUI" dürfen in einer Installation nur dann entfernt oder ersetzt werden, wenn höchstens 50 Personen innerhalb von 30 Tagen Zugriff haben, oder wenn eine schriftliche Erlaubnis beziehungsweise eine Enterprise-Lizenz des Herstellers vorliegt. Für die Praxis heißt das zweierlei. Erstens: Ein interner Einsatz mit mehr als 50 Nutzenden ist völlig in Ordnung, die Oberfläche trägt dann eben sichtbar den Namen Open WebUI. Wer eine Oberfläche im eigenen Erscheinungsbild will, muss die Enterprise-Lizenz einkalkulieren. Zweitens, und wichtiger: Wer von einem Dienstleister eine **umbenannte, im Anbieter-Design gestaltete Oberfläche** angeboten bekommt, die erkennbar auf Open WebUI basiert, sollte fragen, ob dafür eine entsprechende Lizenz besteht. Das ist keine Formalie, sondern ein brauchbarer Indikator dafür, wie sauber ein Anbieter generell mit Lizenz- und Vertragsfragen umgeht. Dies ist keine Rechtsberatung; der Lizenztext ist kurz und unten verlinkt. ## Wo die Arbeit liegt: Voreinstellungen sind keine Empfehlungen Die häufigste Enttäuschung nach der Installation lautet: „Die KI hat mein Dokument gar nicht richtig gelesen." Das ist in aller Regel kein Produktfehler, sondern Konfigurationsstand. Die eigene Dokumentation des Projekts sagt es offen: Die Voreinstellungen sind bewusst konservativ gewählt, damit die Software überall läuft, und deutlich bessere Ergebnisse erfordern Anpassung. Drei Punkte machen den Unterschied: 1. **Dokumenten-Extraktion.** Der eingebaute Standard-Parser kommt mit eingescannten PDFs und komplexen Office-Dateien schlecht zurecht; Tabellen und Textfelder gehen verloren. Die Projekt-Dokumentation empfiehlt selbst, eine robuste Extraktions-Engine wie Apache Tika oder Docling vorzuschalten, beides quelloffene Werkzeuge, die als eigener Dienst neben Open WebUI laufen und auch Texterkennung (OCR) für Scans mitbringen. 2. **Embedding-Modell.** Das Modell, das Dokumente für die semantische Suche aufbereitet, ist in der Voreinstellung ein kleines, englisch-lastiges Modell, das die Dokumentation ausdrücklich der Kategorie „getting started" zuordnet. Für deutsche Dokumentbestände gehört hier ein mehrsprachiges Modell hin, und nach dem Wechsel müssen alle Bestände neu indexiert werden. 3. **Ganze Dokumente statt Häppchen.** Für einzelne, überschaubare Dokumente (die Dokumentation nennt als Faustregel unter etwa 50 Seiten) liefert der „Full Context"-Modus, der das komplette Dokument einspeist, oft bessere Ergebnisse als die stückweise Suche. Nichts davon ist Hexenwerk. Aber es ist der Unterschied zwischen „installiert" und „brauchbar", und er sollte in jeder Projektplanung als eigener Posten auftauchen. ## Erweiterungen wie Browser-Add-ons behandeln Um Open WebUI existiert ein großer Marktplatz an Community-Erweiterungen: Werkzeuge, Filter, Exportfunktionen. Die Qualität reicht von gepflegten Projekten bis zu verwaisten Ein-Wochenend-Experimenten. Zwei Prüffragen vor jeder Installation: Wird die Erweiterung aktiv gepflegt, und lädt sie zur Laufzeit Ressourcen von externen Servern nach? Letzteres kommt vor und durchlöchert still das Versprechen „es verlässt nichts das Haus". Die vernünftige Linie ist dieselbe wie bei Browser-Erweiterungen im Unternehmenseinsatz: wenige, geprüfte, versionierte Erweiterungen statt eines bunten Baukastens. ## Betrieb bleibt Betrieb Die Software kostet nichts, der Betrieb schon. Wer Open WebUI selbst hostet, ist Betreiber mit allem, was dazugehört: zeitnahe Updates (das Projekt veröffentlicht in hoher Frequenz), Datensicherung, Benutzer-Lebenszyklus, technische und organisatorische Maßnahmen, und ein Auftragsverarbeitungsvertrag, sobald das Sprachmodell bei einem externen Anbieter läuft. Open WebUI ist ein sehr guter Baustein, aber kein Datenschutzkonzept. Wer den Betrieb nicht stemmen kann oder will, landet beim Mittelweg aus der [vorletzten Ausgabe](/newsletter/eu-gehostete-ki-ohne-speicherung/): dieselbe Software als verwalteter Dienst eines EU-Anbieters, und dann gelten die dort beschriebenen Vertragsfragen. Unter dem Strich: Open WebUI ist der seltene Fall einer quelloffenen Software, die für den kirchlichen und sozialwirtschaftlichen Einsatz nicht angepasst werden muss, sondern nur richtig konfiguriert. Die Datenschutz-Eigenschaften entstehen dabei nicht in der Oberfläche, sondern in der Architektur dahinter: wo das Modell läuft, wer die Dokumente sieht, was protokolliert wird. Die Oberfläche macht diese Architektur nur benutzbar, das allerdings ausgesprochen gut. ## Quellen Alle Quellen am 23.07.2026 an der Primärquelle geprüft. - Open WebUI, Projektbeschreibung und Funktionsübersicht (README): [GitHub](https://github.com/open-webui/open-webui) - Open WebUI License, Lizenztext mit Branding-Klausel: [LICENSE auf GitHub](https://github.com/open-webui/open-webui/blob/main/LICENSE) - Open WebUI Docs, Erläuterung der Lizenzänderung ab v0.6.6 (April 2025): [docs.openwebui.com/license](https://docs.openwebui.com/license/) - Open WebUI Docs, RAG-Troubleshooting (empfohlene Einstellungen, Tika/Docling, Full-Context-Modus, Embedding-Hinweise): [docs.openwebui.com/troubleshooting/rag](https://docs.openwebui.com/troubleshooting/rag/) - Open WebUI Docs, Dokumenten-Extraktion: [docs.openwebui.com/features/chat-conversations/rag/document-extraction](https://docs.openwebui.com/features/chat-conversations/rag/document-extraction/) - Open WebUI Docs, Speech-to-Text-Konfiguration (lokales Whisper als Standard): [docs.openwebui.com/features/chat-conversations/audio/speech-to-text/stt-config](https://docs.openwebui.com/features/chat-conversations/audio/speech-to-text/stt-config/) - Open WebUI Docs, Umgebungsvariablen-Referenz (Audit-Log-Stufen): [docs.openwebui.com/reference/env-configuration](https://docs.openwebui.com/reference/env-configuration/) --- # KI-Schulung für Diakonie, Caritas und kirchliche Träger: Warum die Standard-Fortbildung am falschen Gesetz vorbeischult > Die bayerische kirchliche Datenschutzaufsicht empfiehlt, Datenschutz- und KI-Kompetenz-Schulungen zu verknüpfen. Was hinter der Empfehlung steckt, warum generische KI-Kurse für kirchliche Einrichtungen zu kurz greifen und woran eine passende Schulung zu erkennen ist. Kanonische URL: https://kirchliche-ki.de/newsletter/ki-kompetenz-schulung-kirchliche-traeger/ · Veröffentlicht: 2026-07-21 > **Korrektur vom 13. August 2026.** Die Mitbestimmungsvorschrift wird hier jetzt als > § 40 Buchstabe k MVG-EKD zitiert, zuvor stand hier „Nr. 11". Der Katalog des § 40 ist > mit Buchstaben gegliedert. Wortlaut und Aussage sind unverändert. > **Aktualisierung vom 29. Juli 2026.** Seit dem 27. Juli 2026 gilt die > Digital-Omnibus-Verordnung zur KI (Verordnung (EU) 2026/1744). Sie hat Artikel 4 > der KI-Verordnung neu gefasst: Geschuldet ist seither, die Entwicklung der > KI-Kompetenz zu unterstützen, nicht mehr ein ausreichendes Maß an Kompetenz > sicherzustellen. Die Beschreibung von Artikel 4 im folgenden Abschnitt und die > Angabe zur Durchsetzung ab dem 2. August 2026 geben deshalb den Stand vor dieser > Änderung wieder. Am Kern dieses Artikels ändert sich nichts, im Gegenteil: Die > Schulungs- und Unterrichtungspflichten aus KDG und DSG-EKD sind von der Änderung > nicht berührt und damit noch deutlicher der maßgebliche Rahmen für kirchliche > Träger. Die Einzelheiten stehen in der Ausgabe > [Der AI Act nach dem Digital Omnibus](/newsletter/ai-act-nach-dem-digital-omnibus/). Das Katholische Datenschutzzentrum Bayern (KDSZ Bayern), die gemeinsame Datenschutzaufsicht der bayerischen (Erz-)Diözesen, hat im Juli 2026 seinen knapp 170 Seiten starken Tätigkeitsbericht 2025 vorgelegt. Neben Praxisbeispielen, Audits und einer Checkliste für Datenpannen widmet der Bericht der KI-Verordnung ein eigenes Kapitel, und dort steht ein Satz, den Träger ernst nehmen sollten: > „Eine der ersten unmittelbar geltenden Verpflichtungen betrifft seit Februar 2025 > die Sicherstellung einer angemessenen KI-Kompetenz." (Tätigkeitsbericht 2025, > S. 33) Gemeint ist Art. 4 der KI-Verordnung: Anbieter und Betreiber von KI-Systemen müssen geeignete Maßnahmen treffen, damit die mit Entwicklung, Betrieb oder Nutzung befassten Personen über ausreichende Kenntnisse und Fähigkeiten verfügen. Einheitliche Schulungen oder Zertifikate schreibt die Verordnung nicht vor; der Umfang richtet sich nach den Aufgaben der Mitarbeitenden. Die Aufsicht zieht daraus eine praktische Empfehlung: vorhandene Strukturen für Pflichtschulungen nutzen, bestehende Schulungs- und Sensibilisierungskonzepte weiterentwickeln, und dabei Datenschutz und KI-Kompetenz verzahnen: > „Im Rahmen der KI-Kompetenz sollten Mitarbeitende daher auch für > datenschutzrechtliche Fragestellungen sensibilisiert werden." (Tätigkeitsbericht > 2025, S. 34) Dazu passt der Zeitplan: Nach der offiziellen Timeline der EU-Kommission beginnt am 2. August 2026 die Durchsetzung der KI-Verordnung auf nationaler und EU-Ebene, ausdrücklich auch für die KI-Kompetenz-Pflicht. Die naheliegende Reaktion vieler Träger: eine KI-Schulung einkaufen. Davon gibt es inzwischen reichlich. Fast alle haben für kirchliche und diakonische Einrichtungen denselben blinden Fleck. ## Das falsche Gesetz Praktisch jede KI-Fortbildung am Markt erklärt den Rechtsrahmen mit der DSGVO. Für Diakonie, Caritas, kirchliche Krankenhäuser und Kitas ist das schlicht das falsche Gesetz. Diese Einrichtungen unterliegen dem kirchlichen Datenschutzrecht: dem KDG auf katholischer Seite (frisch novelliert; die neue Durchführungsverordnung KDG-DVO gilt seit dem 1. März 2026) und dem DSG-EKD auf evangelischer Seite. Das ist kein akademischer Unterschied. Drei Beispiele, die in eine Schulung gehören und in generischen Kursen fehlen: **1. Ohne Klassifizierung gilt automatisch die strengste Klasse.** Die KDG-DVO verlangt, dass Verarbeitungstätigkeiten einer Datenschutzklasse zugeordnet werden, und regelt den Unterlassensfall gleich mit: > „Erfolgt keine Einordnung, gilt automatisch die Datenschutzklasse III, sofern > nicht die Voraussetzungen des § 14 vorliegen." (§ 9 Abs. 5 KDG-DVO) Datenschutzklasse III ist die höchste reguläre Schutzklasse. Die meisten Einrichtungen haben nie klassifiziert. Damit behandeln sie, rechtlich gesehen, jede KI-Anwendung so, als ginge es um die sensibelsten Daten im Haus, mit entsprechenden Anforderungen an die technischen Maßnahmen. **2. Seelsorgedaten sind eine eigene Kategorie.** Für Daten unter dem Beichtgeheimnis ist die Rechtslage absolut: Sie „dürfen nicht verarbeitet werden" (§ 14 KDG-DVO). Für Daten unter dem Seelsorgegeheimnis verlangt dieselbe Vorschrift Maßnahmen oberhalb der höchsten Schutzklasse und nennt als Beispiel ausdrücklich „die Unterhaltung eines eigenen Servers bzw. einer eigenen Datenablage in einem Netzwerk ohne externe Datenverbindung". Wer einer Klinikseelsorge ein Cloud-KI-Tool empfiehlt, hat diese Vorschrift nicht gelesen. Welche Architektur zu welcher Datenklasse passt, behandelt die [Ausgabe zur Frage Cloud oder eigener Server](/newsletter/cloud-oder-eigener-server/). **3. Ohne die MAV geht es nicht.** KI-Werkzeuge, die geeignet sind, Verhalten oder Leistung von Mitarbeitenden auszuwerten, sind mitbestimmungspflichtig, im evangelischen Bereich schon nach dem Gesetzeswortlaut („geeignet", § 40 Buchstabe k MVG-EKD), und dazu reicht oft ein Protokoll- oder Statistik-Feature. Eine Schulung, die die Mitarbeitendenvertretung nicht mitdenkt, produziert Projekte, die in Monat zwei blockiert werden. Ausführlich in der [Ausgabe zur Mitbestimmung](/newsletter/mitbestimmung-geeignet-mvg-ekd/). Dazu kommt: Die kirchlichen Aufsichten schauen bereits hin. Der kirchenrechtliche Fachbeobachter Felix Neumann berichtet vom Katholikentag 2026 aus Gesprächen mit Aufsichtsvertretern über technische Prüfungen von KI-Systemen und über steigende Beschwerdezahlen durch KI-Unterstützung (KI-Werkzeuge senken die Hürde, eine Beschwerde zu formulieren, auch gegen die eigene Einrichtung). Eigene KI-Leitlinien einer kirchlichen Aufsicht gibt es dagegen bis heute nicht. Die Verantwortung, es richtig zu machen, liegt im Moment vollständig beim Träger. Die katholischen Aufsichten selbst bringen es auf ihrer gemeinsamen Infokarte zur KDG-Novelle auf die Formel: „Regelmäßige Qualifizierung der Mitarbeitenden bleibt das A + O." ## Was eine passende Schulung leisten muss Aus meiner Projektarbeit mit kirchlichen Einrichtungen hat sich für mich ein Aufbau bewährt, der vier Dinge verbindet: **Rechtsrahmen als Entscheidungswissen, nicht als Jurastudium.** In 45 Minuten: Welches Gesetz gilt für uns (KDG oder DSG-EKD, nicht DSGVO), was verlangt die KI-Verordnung wirklich und was davon ist für einen sozialen Träger relevant. Ziel ist nicht, Paragrafen zu zitieren, sondern die Frage „dürfen wir das?" für die eigenen Anwendungsfälle beantworten zu können. **Live-Demo statt Folien.** KI-Kompetenz entsteht nicht durch Definitionen, sondern durch Anfassen. Bei meinen Vorträgen kippt die Stimmung im Raum nie bei einer Folie, sondern immer in dem Moment, in dem ein echtes System live läuft: Textassistenz für Anträge und Berichte, interne Wissenssuche über eigene Dokumente, KI-Transkription von Gremiensitzungen. Für Letzteres hat der Landesdatenschutz- beauftragte Baden-Württemberg im Juni 2026 einen eigenen Leitfaden veröffentlicht (für kommunale Gemeinderäte, mit übertragbaren Grundsätzen: klare Rechtsgrundlage, keine Transkription der Wortbeiträge von Bürgern, Pausenfunktion bei Personalangelegenheiten). Entscheidend ist, dass die gezeigten Anwendungen im kirchlichen Kontext auch zulässig sind, sonst schult man Begeisterung für Dinge, die das eigene Haus gar nicht einsetzen darf. **Die Cloud-Frage ehrlich beantworten.** Welche Daten dürfen in welches System? Wann ist ein US-Cloud-Dienst vertretbar, wann braucht es eine europäische Alternative und wann ist ein eigener Server im Haus die einzig saubere Antwort? Gerade hier gibt das kirchliche Recht klarere Antworten als die DSGVO, und sie fallen öfter zugunsten selbst betriebener Systeme aus, als viele erwarten. **Spielregeln fürs eigene Haus.** Am Ende steht nicht ein Zertifikat, sondern ein Entwurf für eine KI-Richtlinie: welche Werkzeuge sind freigegeben, welche Daten sind tabu, wer entscheidet über neue Anwendungen und wie wird die MAV von Anfang an eingebunden. ## Woran Sie eine passende Schulung erkennen Wenn Ihr Haus eine solche Schulung plant, egal ob über das Beratungshaus, das Sie ohnehin schon begleitet, über einen externen Anbieter oder intern: Achten Sie auf drei Dinge. Erstens, dass der Rechtsteil auf KDG beziehungsweise DSG-EKD aufsetzt und nicht auf der DSGVO. Zweitens, dass echte Werkzeuge live gezeigt werden, nicht Folien über Werkzeuge. Drittens, dass die MAV von Anfang an als Beteiligte vorkommt und nicht als Hindernis. Erfahrungsgemäß reicht dafür ein halber Tag, und es lohnt sich, alle vier Rollen an einen Tisch zu holen: Leitung, Datenschutzbeauftragte, IT und Mitarbeitendenvertretung. Eine Schulung, die diese Punkte erfüllt, deckt die Empfehlung der Aufsicht und die Anforderung der KI-Verordnung in einem ab, statt zwei getrennte Pflichtveranstaltungen zu erzeugen. Die rechtliche Bewertung des Einzelfalls ersetzt sie nicht; die gehört zum Datenschutzbeauftragten und, wo nötig, zu einer fachkundigen rechtlichen Beratung. Der Tätigkeitsbericht des KDSZ Bayern liefert dafür die passende Begründung gleich mit: > „Digitale Souveränität entsteht nicht allein durch den Einsatz neuer > Technologien. Sie setzt vielmehr voraus, dass die Menschen, die diese > Technologien entwickeln, auswählen und einsetzen, deren Funktionsweise, Chancen > und Risiken verstehen und verantwortungsvoll mit ihnen umgehen." ## Quellen - KDSZ Bayern, Tätigkeitsbericht 2025 (Juli 2026), KI-Kapitel S. 33 ff.: [kdsz.bayern (PDF)](https://kdsz.bayern/wp-content/uploads/2026/07/TB_KDSZ_Bayern_TB_06_2025.pdf), Ankündigung: [kdsz.bayern](https://kdsz.bayern/taetigkeitsbericht-2025-von-krypto-trojanern-bis-zur-videokamera-auf-dem-friedhof/) - Felix Neumann, „Transparenzoffensive, Tätigkeitsbericht des KDSZ Bayern 2025", 15.07.2026: [artikel91.eu](https://artikel91.eu/2026/07/15/transparenzoffensive-taetigkeitsbericht-des-kdsz-bayern-2025/) - Art. 4 KI-Verordnung (VO (EU) 2024/1689): [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) · Offizielle Umsetzungs-Timeline (Durchsetzung ab 02.08.2026): [EU AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act) - § 9 KDG-DVO (Datenschutzklassen; Abs. 5): [kdg.info](https://kdg.info/kdgdvo/kapitel3/paragraf09/) - § 14 KDG-DVO (Beicht- und Seelsorgegeheimnis): [kdg.info](https://kdg.info/kdgdvo/kapitel3/paragraf14/) - § 40 MVG-EKD (Mitbestimmung, Fassung 20.01.2024): [kirchenrecht-evlka.de](https://kirchenrecht-evlka.de/document/45212) - LfDI Baden-Württemberg, „Datenschutz-Leitfaden für KI-Transkription von Gemeinderatssitzungen" (Version 1.0, 10.06.2026): [baden-wuerttemberg.datenschutz.de](https://www.baden-wuerttemberg.datenschutz.de/leitfaden-ki-transkription-von-gemeinderatssitzungen/) - Katholische Datenschutzaufsichten, Infokarte „TOP 10 der KDG-/KDG-DVO-Novellierung" (Katholikentag 2026): [kath-datenschutzzentrum-ffm.de (PDF)](https://www.kath-datenschutzzentrum-ffm.de/wp-content/uploads/Infokarte_KT-Wuerzburg-2026.pdf) - Felix Neumann, „38 Regalmeter Scientology, Wochenrückblick KW 25/2026", 19.06.2026 (Katholikentag, Beschwerden, KI-Prüfungen): [artikel91.eu](https://artikel91.eu/2026/06/19/38-regalmeter-scientology-wochenrueckblick-kw-25-2026/) --- # Kontext schlägt Modell: Warum datenschutzkonforme LLMs meist genügen > Die erste Frage bei einem KI-Projekt ist selten 'welches Modell', sondern 'wie gut ist der Kontext'. Für die Aufgaben eines Trägers entscheidet Datenaufbereitung, Retrieval und Prompt mehr als das jeweils neueste Spitzenmodell. Kanonische URL: https://kirchliche-ki.de/newsletter/kontext-schlaegt-modell/ · Veröffentlicht: 2026-07-19 Wer über KI im Träger nachdenkt, fragt reflexhaft zuerst nach dem Modell: GPT, Claude, ein offenes Modell? Wer zusätzlich Datenschutz ernst nimmt, spürt hier sofort einen Zielkonflikt, denn die stärksten Modelle stehen bei US-Anbietern. Die gute Nachricht: Diese Frage steht meist an der falschen Stelle. Für die Aufgaben, die im Alltag tatsächlich anfallen, ist selten das Modell der Engpass, sondern der Kontext, den man ihm gibt. ## Was „Kontext" konkret meint Kontext ist nicht das, worauf das Modell trainiert wurde, sondern das, was man ihm zur Laufzeit vorlegt: die passenden Textstellen aus den eigenen Dokumenten (per RAG, [siehe die vorige Ausgabe](/newsletter/rag-datenschutzkonform-dsk/)), die saubere Aufbereitung dieser Dokumente und der Prompt. Bei einer geerdeten Aufgabe, also einer, die aus vorgegebenen Unterlagen beantwortet wird, erfindet das Modell kein Wissen. Es arbeitet mit dem, was es bekommt. Die Qualität der Antwort hängt dann an der Qualität dieses Kontexts. ## Warum das mehr zählt als Modellgröße Genau so beschreibt es auch die Aufsicht. Die [DSK-Orientierungshilfe zu RAG-Systemen](https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf) (Oktober 2025) macht die Richtigkeit einer Antwort an mehreren Stellschrauben fest, und keine davon ist die Größe des Modells: an Qualität, Aktualität und Vollständigkeit der Referenzdokumente, an der Datenaufbereitung (Kopf- und Fußzeilen bereinigen, sinnvolle Chunk-Größe und Überlappung), an der Qualität des Embedding-Modells (für deutsche Texte ein deutschsprachig trainiertes) und an der Kontexttreue des Modells. Als wirksame Maßnahme nennt sie einen Systemprompt, der das System anweist, „ausschließlich mithilfe der referenzierten Quellen zu antworten." Bemerkenswert ist, wohin die Orientierungshilfe bei der Modellwahl zeigt: Sie empfiehlt ein eher **kleineres** Sprachmodell, das weniger Fakten auswendig speichert, und verlangt, die Eignung dieser Wahl zu prüfen und zu dokumentieren. Das ist das Gegenteil der Modelljagd. Die Guidance selbst legt nahe, das kleinste Modell zu nehmen, das die Aufgabe besteht. ## Die ehrliche Einordnung Das heißt nicht, dass alle Modelle gleich gut sind. Die großen Spitzenmodelle führen bei harten Aufgaben weiterhin: komplexes mehrstufiges Schließen, anspruchsvolle Programmierung, offene Synthese ohne Vorlage. Wo eine Aufgabe das wirklich braucht, kann der Abstand zählen. Nur ist das die Minderheit dessen, was ein Träger tatsächlich zu tun hat. Der Großteil ist geerdete, deutschsprachige Büro- und Wissensarbeit: aus Unterlagen antworten, zusammenfassen, aus einer Vorlage entwerfen, Informationen finden. Für diese Aufgaben schließt ein leistungsfähiges, in der EU betreibbares offenes Modell mit gutem Kontext den praktischen Abstand in der Regel. ## Der Preis der Modelljagd Immer das neueste Modell haben zu wollen, hat zwei Kosten. Entweder gehen die Daten an einen US-Spitzenanbieter, das ist der Datenschutz-Konflikt vom Anfang. Oder man baut das System bei jedem Modellwechsel neu an. Steckt man denselben Aufwand stattdessen in den Kontext, also in saubere Daten, gutes Retrieval, ein deutschsprachiges Embedding und präzise Prompts, zahlt sich das unabhängig vom Modell aus. Und es bleibt übertragbar: Wer auf offene Modelle setzt, kann dasselbe System in der EU-Cloud oder auf dem eigenen Server betreiben und das Modell später austauschen, ohne den Kontext wegzuwerfen. ## Was das praktisch heißt Die Reihenfolge der Investition kehrt sich um: 1. **Datenaufbereitung** zuerst. Schlechte Eingangsdaten kann kein Modell reparieren. 2. **Retrieval-Qualität**: deutschsprachiges Embedding, sinnvolles Chunking. 3. **Prompt und Kontextgestaltung**: das Modell an die Quellen binden. 4. **Erst dann die Modellwahl**, und unter den geeigneten das kleinste, das die Qualitätsschwelle erreicht. Und ein wichtiger Zusatz: Testen sollte man an den **eigenen** Aufgaben, nicht an öffentlichen Ranglisten. Die Leaderboards messen oft etwas anderes als die Arbeit, die im Haus anfällt. Die Frage „reicht ein datenschutzkonformes Modell?" beantwortet sich dann meist durch eine Gegenfrage: „ist der Kontext gut genug?" Dort gehört die Arbeit hin, und dieser Teil bleibt der eigene. ## Quellen - DSK, Orientierungshilfe „Datenschutzrechtliche Besonderheiten generativer KI-Systeme mit RAG-Methode", Oktober 2025: [PDF](https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf) - Lewis et al., „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", arXiv:2005.11401: [Link](https://arxiv.org/abs/2005.11401) - Gao et al., „Retrieval-Augmented Generation for Large Language Models: A Survey", arXiv:2312.10997: [Link](https://arxiv.org/pdf/2312.10997) - Fraunhofer IESE, Blog zu Retrieval-Augmented Generation: [Link](https://www.iese.fraunhofer.de/blog/retrieval-augmented-generation-rag/) --- # On-Premise-KI ohne teuren Server: Was auf CPU und kleinem Modell wirklich geht > Für interne Abfragen und Berichte braucht es keinen GPU-Server. Mit einem kleinen Modell, erzwungener strukturierter Ausgabe und engen Werkzeugen läuft nützliche Automatisierung auf gewöhnlicher Hardware, solange man die Grenze kennt. Kanonische URL: https://kirchliche-ki.de/newsletter/on-premise-ki-kleine-hardware/ · Veröffentlicht: 2026-07-19 Die Annahme, On-Premise-KI brauche einen teuren Server mit Grafikkarte, hält viele kleinere Träger davon ab, es überhaupt zu versuchen. Für einen häufigen und nützlichen Anwendungsfall stimmt sie nicht: eigene Systeme abfragen, Berichte ziehen, Daten im Haus behalten. Das läuft mit einem kleinen Modell auf einer gewöhnlichen Maschine, sogar ohne Grafikkarte, wenn die Architektur das ausgleicht. Es gibt aber eine klare Grenze, und die zu kennen ist die eigentliche Kompetenz. ## Was auf gewöhnlicher Hardware läuft Ohne Grafikkarte liegen Modellgewichte und Kontext im Arbeitsspeicher. Ein kleines Modell mit 7 bis 8 Milliarden Parametern, auf Q4 quantisiert, belegt rund 5 bis 6 GB. Damit läuft es auf einer 8-GB-Maschine knapp und auf 16 GB bequem. Ein 14B-Modell will etwa 10 GB und mehr Geduld. Beim Tempo auf reiner CPU sind für ein 7-bis-8B-Modell je nach Prozessor grob einige wenige bis rund 15 Token pro Sekunde realistisch. Wie lange eine Antwort dauert, hängt damit vor allem an ihrer Länge: eine kurze, strukturierte Ausgabe wie ein Werkzeugaufruf ist in wenigen Sekunden fertig, ein längerer Fließtext eher in Dutzenden Sekunden. Bei großem Kontext, etwa vielen RAG-Dokumenten, kommt die Zeit hinzu, die Eingabe zu verarbeiten, bevor das erste Token erscheint. Für eine Abfrage vom Typ „zieh mir den Bericht" ist das völlig ausreichend; für ein flüssiges Chat-Gespräch nicht. Genau diese asynchrone, nicht interaktive Nutzung ist der Sweet-Spot der kleinen Hardware. ## Der Trick, der ein kleines Modell zuverlässig macht Ein kleines Modell, das man frei formulieren lässt, produziert bei Werkzeugaufrufen regelmäßig fehlerhafte Ausgaben: ein Feld fehlt, das JSON ist kaputt, der Aufruf ist unbrauchbar. Die Lösung ist nicht ein größeres Modell, sondern **erzwungene strukturierte Ausgabe**. Ollama kann die Ausgabe an ein [JSON-Schema binden](https://ollama.com/blog/structured-outputs) (Feld `format`), und gibt selbst an, das sei „zuverlässiger und konsistenter als der reine JSON-Modus". Darunter arbeitet llama.cpp mit einer [grammatikgebundenen Dekodierung (GBNF)](https://github.com/ggml-org/llama.cpp/blob/master/grammars/README.md): Bei jedem Schritt werden alle Token, die die vorgegebene Struktur brechen würden, schon vor der Auswahl ausgeschlossen. Eine ungültige Ausgabe wird damit nicht unwahrscheinlicher, sondern unmöglich. Das erspart die Schleife aus Prüfen und Wiederholen und macht kleine Modelle für strukturierte Aufgaben erst brauchbar. Wie stark dieser Hebel wirkt, zeigt eine Untersuchung von NVIDIA (Mai 2026): Mit grammatikgebundener Dekodierung stieg die durchschnittliche Erfolgsquote kleiner Modelle von 62,5 auf 75,2 Prozent, ein sehr kleines Modell sprang um über 40 Punkte ([Quelle](https://developer.nvidia.com/blog/improving-bash-generation-in-small-language-models-with-grammar-constrained-decoding/)). Nicht die Hardware macht hier den Unterschied, sondern die Architektur. ## Das Muster: das Modell übersetzt, der Code handelt Ein tragfähiger Aufbau nutzt das Modell als Übersetzer, nicht als Steuermann. Man definiert dem Modell eine kleine Zahl klar beschriebener [Werkzeuge](https://ollama.com/blog/tool-support) (Funktionsdefinitionen mit JSON-Schema). Das Modell schlägt genau einen strukturierten Aufruf vor, der eigene, deterministische Code prüft ihn und führt ihn aus, etwa gegen die vorhandene ERP- oder Shop-Schnittstelle. Drei Regeln halten das robust: - **Wenige, einfache Werkzeuge.** Je enger die Aufgabe je Aufruf, desto zuverlässiger das kleine Modell. - **Zuerst nur lesen.** Berichte ziehen ist harmlos; eine falsche Antwort ist prüfbar. Schreibende Vorgänge (etwa eine Buchung anlegen) gehören hinter eine menschliche Bestätigung, nie in einen unbeaufsichtigten Automatismus. - **Temperatur 0** und festes Schema für reproduzierbare Ergebnisse. Die Planung mehrerer Schritte gehört in den Code, nicht in das Modell. ## Die Modellwahl Unter den kleinen Modellen eignen sich für Werkzeugaufrufe und deutschsprachige Aufgaben vor allem [Qwen3](https://qwen.readthedocs.io/en/latest/framework/function_call.html) (offen lizenziert, ausdrücklich für Function-Calling ausgelegt, über hundert Sprachen), **Llama 3.1 8B** und **Mistral**. Die Richtung deckt sich mit der [DSK-Orientierungshilfe zu RAG](https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf), die ohnehin ein eher kleineres Modell empfiehlt, das weniger Fakten auswendig speichert. Die Auswahlregel bleibt: das kleinste Modell nehmen, das die eigenen Aufgaben besteht, und an den eigenen Aufgaben testen, nicht an öffentlichen Ranglisten. ## Die Grenze, die man kennen muss Kleine Modelle sind beim Function-Calling messbar schwächer als große. Das [Berkeley Function-Calling Leaderboard](https://gorilla.cs.berkeley.edu/leaderboard.html) zeigt das innerhalb einer Modellfamilie deutlich: In der Llama-3.1-Reihe erreicht die 8B-Variante rund 0,76, die 70B-Variante rund 0,85 und die 405B-Variante rund 0,89. Der [begleitende Fachaufsatz](https://proceedings.mlr.press/v267/patil25a.html) benennt, wo die Schwäche liegt: Einzelne, klar spezifizierte Aufrufe gelingen zuverlässig, während „Gedächtnis, dynamische Entscheidungen und Schließen über lange Ketten" die offenen Probleme bleiben. Für die Praxis heißt das: Ein sauber umrissener Werkzeugaufruf nach dem anderen ist solide. Mehrstufige, parallele oder über viele Runden laufende Orchestrierung ist der Punkt, an dem ein kleines Modell abbaut. Wer dorthin muss, hat die Grenze erreicht und braucht entweder einen Menschen in der Schleife oder ein größeres Modell. ## Fazit On-Premise-KI auf bescheidener Hardware ist für eine klar abgegrenzte Klasse von Aufgaben kein Spielzeug, sondern brauchbar, und die Daten verlassen das Haus nicht. Der begrenzende Faktor ist nicht das Grafikkarten-Budget, sondern ob man das Modell strukturell zwingt und die Aufgaben einstufig hält. Das ist eine Architekturfrage, und sie ist bezahlbar. ## Quellen - Ollama, Structured outputs (JSON-Schema, `format`): [Link](https://ollama.com/blog/structured-outputs) - Ollama, Tool support (`tools`): [Link](https://ollama.com/blog/tool-support) - llama.cpp, GBNF-Grammatiken: [Link](https://github.com/ggml-org/llama.cpp/blob/master/grammars/README.md) - NVIDIA, Grammar-Constrained Decoding für kleine Modelle, Mai 2026: [Link](https://developer.nvidia.com/blog/improving-bash-generation-in-small-language-models-with-grammar-constrained-decoding/) - Berkeley Function-Calling Leaderboard: [Link](https://gorilla.cs.berkeley.edu/leaderboard.html) und [Fachaufsatz (PMLR 2025)](https://proceedings.mlr.press/v267/patil25a.html) - Qwen, Function Calling: [Link](https://qwen.readthedocs.io/en/latest/framework/function_call.html) - DSK, Orientierungshilfe zu RAG-Systemen, Oktober 2025: [PDF](https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf) --- # Geeignet, nicht bestimmt: Wann ein System die Mitarbeitendenvertretung auslöst > Im evangelischen Kirchenrecht genügt schon die bloße Eignung zur Überwachung, damit die MAV mitbestimmt, früher, als die weltliche Intuition erwarten lässt. Was das für die Planung eines Systems bedeutet. Kanonische URL: https://kirchliche-ki.de/newsletter/mitbestimmung-geeignet-mvg-ekd/ · Veröffentlicht: 2026-07-19 > **Korrektur vom 13. August 2026.** Die Vorschrift wird hier jetzt als § 40 Buchstabe k > MVG-EKD zitiert. Der Mitbestimmungskatalog des § 40 ist mit Buchstaben gegliedert, die > Überwachungsvorschrift ist der elfte Punkt. Zuvor stand hier „Nr. 11". Wortlaut und > Aussage sind unverändert. Ein häufiger Denkfehler bei der Planung eines IT-Systems lautet: „Wir bauen das nicht, um jemanden zu überwachen, also muss die Mitarbeitendenvertretung nicht beteiligt werden." Im kirchlichen Umfeld ist diese Logik falsch, und sie ist früher falsch als in einem weltlichen Unternehmen. Der Auslöser der Mitbestimmung ist nicht die Absicht, sondern die Eignung. ## „Geeignet" statt „bestimmt" Das Mitarbeitendenvertretungsgesetz der EKD (MVG-EKD) zählt in seinem Mitbestimmungskatalog unter Buchstabe k auf: > „Einführung und Anwendung von Maßnahmen oder technischen Einrichtungen, die dazu > **geeignet** sind, das Verhalten oder die Leistung der Mitarbeitenden zu überwachen" > (§ 40 Buchstabe k MVG-EKD, Fassung vom 20. Januar 2024). Das entscheidende Wort ist „geeignet". Zum Vergleich das weltliche Betriebsverfassungsgesetz: > „Einführung und Anwendung von technischen Einrichtungen, die dazu **bestimmt** sind, > das Verhalten oder die Leistung der Arbeitnehmer zu überwachen" (§ 87 Abs. 1 Nr. 6 > BetrVG). „Bestimmt" klingt enger, als es ist. Das Bundesarbeitsgericht liest „bestimmt" seit Langem im objektiv-finalen Sinn: Es genügt, dass die Einrichtung objektiv **geeignet** ist, Daten über Verhalten oder Leistung zu erheben. Weder eine tatsächliche Überwachung noch eine Überwachungsabsicht noch überhaupt die Speicherung personenbezogener Daten ist erforderlich (etwa BAG, Beschluss vom 16.11.2021, 1 ABR 20/21). Das weltliche Recht kommt also über die Rechtsprechung zum selben Ergebnis. Das evangelische Kirchenrecht hat den weiten Maßstab gleich in den Gesetzestext geschrieben. ## Was „geeignet" technisch bedeutet Die Schwelle ist niedrig. „Geeignet" ist ein System, sobald es Verhalten, Zeiten oder Leistung einzelnen Personen zuordnen kann. Das trifft auf sehr viel Alltägliches zu: Ticketsysteme, BI-Dashboards, Protokolle und Logdateien, Zeiterfassung, Auswertungen von Durchlaufzeiten. Zwei Klarstellungen, die sich unmittelbar aus dem Wortlaut ergeben: - **Es braucht keine KI.** Der Gesetzestext kennt keine Technologie-Bedingung. Eine schlichte, regelbasierte Auswertung ist genauso erfasst wie ein Modell (siehe die [Ausgabe zur Frage, was überhaupt KI ist](/newsletter/ist-das-ueberhaupt-ki/)). - **Es braucht keine Datenspeicherung.** Nach der Rechtsprechung genügt die Eignung, auch wenn keine personenbezogenen Daten dauerhaft abgelegt werden. Die richtige Frage bei der Planung ist deshalb nicht „ist das KI?" oder „speichern wir Daten?", sondern: **Kann das System einzelnen Menschen Verhalten oder Leistung zuordnen?** Wenn ja, ist die Mitbestimmung im Spiel. ## Die Konsequenz: die MAV früh einbinden Weil der Auslöser so früh und so breit greift, gehört die Mitarbeitendenvertretung an den Anfang eines Projekts, nicht ans Ende. Ein fertig gebautes System, das erst in der Einführung auf die Mitbestimmung trifft, ist der teure Weg. Der kirchenrechtliche Fachbeobachter Felix Neumann nennt die Zustimmung bei technischen Einrichtungen „das wohl schärfste Schwert der Mitbestimmung im Bereich des Datenschutzes" ([artikel91.eu, 19.11.2025](https://artikel91.eu/2025/11/19/datenschutz-und-mitbestimmung-welche-rechte-hat-die-mav/)). ## Die Dienstvereinbarung ist zugleich der Schlüssel Der wichtigste Punkt für die Architektur: Die Dienstvereinbarung, die die Mitbestimmung erzwingt, ist im evangelischen Recht zugleich eine tragende Rechtsgrundlage für die Verarbeitung der Beschäftigtendaten. § 49 Abs. 1 DSG-EKD erlaubt die Verarbeitung, soweit sie für das Beschäftigungsverhältnis erforderlich ist, > „oder eine Rechtsvorschrift, ein Tarifvertrag oder eine **Dienstvereinbarung** dies > vorsieht." Dasselbe Instrument, das der Mitbestimmung geschuldet ist, trägt also die Verarbeitung. Zu präzisieren ist dabei, dass eine Dienstvereinbarung keine Rechtsgrundlage aus dem Nichts schafft, sie ist ausdrücklich benannt und wiegt in der Erforderlichkeits- und Abwägungsprüfung schwer. Für die Praxis heißt das: die Dienstvereinbarung von vornherein mitdenken und mit Zweckbindung, einem klaren Auswertungskatalog und Löschfristen gestalten, statt sie als lästige Formalie nachzuschieben. ## „Kirchlich" ist nicht ein Recht Diese Konstruktion ist evangelisch. Im katholischen Datenschutzrecht ist die Dienstvereinbarung als allgemeine Verarbeitungsgrundlage **nicht** in gleicher Weise vorgesehen; § 53 KDG nennt sie nicht als generelle Grundlage. Neumann formuliert es so: > „Während Dienstvereinbarungen bereits in § 49 Abs. 1 DSG-EKD erwähnt werden, fehlt eine > entsprechende Regelung im KDG." Wer einen Aufbau von einem evangelischen Träger auf einen katholischen überträgt, kann sich also nicht darauf verlassen, dass die Dienstvereinbarung dort dieselbe rechtliche Rolle spielt. Der Auslöser der Mitbestimmung ähnelt sich, die Rechtsgrundlage nicht. ## Fazit Die technische Faustregel ist einfach: Sobald ein System Verhalten oder Leistung einer Person zuordnen kann, ist von Mitbestimmung auszugehen, unabhängig von KI und unabhängig davon, ob Daten gespeichert werden. Daraus folgt, die MAV früh einzubinden und die Dienstvereinbarung als Teil der Architektur zu entwerfen, nicht als Nachtrag. Die Bewertung des Einzelfalls, ob und in welchem Umfang die Mitbestimmung greift, gehört zur Mitarbeitendenvertretung und, wo nötig, zu einer fachkundigen rechtlichen Beratung. ## Quellen - § 40 MVG-EKD (Mitbestimmung, Fassung 20.01.2024): [kirchenrecht-evlka.de](https://kirchenrecht-evlka.de/document/45212) - § 87 BetrVG: [gesetze-im-internet.de](https://www.gesetze-im-internet.de/betrvg/__87.html) - BAG, Beschluss vom 16.11.2021, 1 ABR 20/21: [bundesarbeitsgericht.de](https://www.bundesarbeitsgericht.de/entscheidung/1-abr-20-21/) - § 49 DSG-EKD (Beschäftigtendatenschutz): [dsg-ekd.de](https://dsg-ekd.de/dsgekd/kapitel8/paragraf49/) - § 53 KDG (Beschäftigtendatenschutz): [kdg.info](https://kdg.info/kapitel8/paragraf53/) - Felix Neumann, „Datenschutz und Mitbestimmung, welche Rechte hat die MAV?", 19.11.2025: [artikel91.eu](https://artikel91.eu/2025/11/19/datenschutz-und-mitbestimmung-welche-rechte-hat-die-mav/) - Felix Neumann, Synopse Beschäftigtendatenschutz BDSG, KDG, DSG-EKD (PDF, 2023): [artikel91.eu](https://artikel91.eu/wp-content/uploads/2023/08/artikel91-Synopse-Beschaeftigtendatenschutz-bdsg-kdg-dsg-ekd.pdf) --- # Ist das überhaupt KI? Warum die Unterscheidung über das ganze Projekt entscheidet > Vieles, was als „KI“ verkauft wird, ist regelbasierte Auswertung. Die Unterscheidung ist kein Wortspiel, sie entscheidet über Recht, Mitbestimmung und Aufwand. Kanonische URL: https://kirchliche-ki.de/newsletter/ist-das-ueberhaupt-ki/ · Veröffentlicht: 2026-07-18 Ein Automatisierungsprojekt im kirchlichen Rechnungswesen kann so aussehen: vorhandene Zeitstempel aus dem Buchungssystem auswerten, um zu sehen, wie lange ein Vorgang dauert und wo er liegen bleibt. Nützlich, aber ist das „KI“? Meistens nicht. Es ist **regelbasierte Auswertung**: Das System lernt nichts und entscheidet nichts, es rechnet mit vorhandenen Daten nach festen Regeln. Diese Unterscheidung klingt akademisch, hat aber handfeste Folgen. ## Der AI Act Ein System, das kein maschinelles Lernen enthält, ist kein KI-System im Sinne der Definition, der AI Act greift dann schlicht nicht. Wer dasselbe Werkzeug als „KI“ etikettiert, importiert einen ganzen Regelrahmen, den er gar nicht braucht. ## Die Mitbestimmung Sobald ein System *geeignet* ist, Verhalten oder Leistung von Mitarbeitenden zu erfassen, ist die Mitarbeitervertretung zu beteiligen, unabhängig davon, ob KI im Spiel ist. Die kirchlichen Regelungen (MVG-EKD, MAVO) setzen hier früher an als das weltliche Betriebsverfassungsrecht. Eine Zeitstempel-Analyse, die einzelnen Personen Verzögerungen zuordnet, fällt darunter, ganz ohne „KI“. ## Die Akzeptanz „Wir setzen KI auf eure Arbeit an“ löst in einer Personalvertretung berechtigte Fragen aus. „Wir werten vorhandene Zeitstempel aus, das System lernt nichts und entscheidet nichts“ ist ehrlicher, und öffnet Türen, die das KI-Etikett verschließt. ## Für die Praxis Zuerst sauber benennen, was man baut. Ist maschinelles Lernen wirklich nötig, oder tut es eine deterministische Regel? Oft ist die Regel nicht nur rechtlich einfacher, sondern auch nachvollziehbarer und prüfbarer, im kirchlichen Umfeld ein Wert an sich. Und wo tatsächlich ein Modell nötig ist, lässt es sich gezielt einsetzen: als Assistenz für den Menschen, mit dem Menschen in der Schleife und klarer Zweckbindung, nicht als Automat, der unkontrolliert entscheidet. Die genaue rechtliche Einordnung, ob im Einzelfall ein KI-System vorliegt, was die MAV mitbestimmt, gehört zur Bewertung durch den Datenschutzbeauftragten und, wo nötig, eine Kanzlei. Die vorgelagerte Frage dagegen, ob überhaupt maschinelles Lernen nötig ist, ist eine technische, und sie lässt sich häufig mit Nein beantworten. --- # RAG datenschutzkonform aufbauen: Was die DSK-Orientierungshilfe für die Architektur bedeutet > Seit Oktober 2025 gibt es eine Orientierungshilfe der Datenschutzkonferenz speziell zu RAG-Systemen. Gelesen aus der Architektur-Perspektive: welche Entscheidungen sie beim Bau eines Systems über eigene Aktenbestände erzwingt. Kanonische URL: https://kirchliche-ki.de/newsletter/rag-datenschutzkonform-dsk/ · Veröffentlicht: 2026-07-18 Retrieval-Augmented Generation, kurz RAG, ist der praktische Weg, ein Sprachmodell über die eigenen Dokumente nützlich zu machen: Handbücher, Satzungen, Protokolle, Aktenbestände. Das Modell wird dabei nicht neu trainiert. Stattdessen sucht ein Retriever zur Laufzeit die passenden Textstellen aus einer Vektordatenbank und legt sie dem Modell als Kontext vor. Seit Oktober 2025 gibt es dazu eine eigene [Orientierungshilfe der Datenschutzkonferenz](https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf) (DSK), der gemeinsamen Runde der deutschen Datenschutzaufsichten. Sie ist kein juristischer Aufsatz, sondern eine Liste von Anforderungen, und jede davon ist zugleich eine Architekturentscheidung. Dieser Text liest sie von der Bauseite her. ## Das Grundszenario der DSK ist bereits on-premise Die Orientierungshilfe legt ausdrücklich ein RAG-System zugrunde, das vollständig im eigenen Haus betrieben wird, bestehend aus Retriever, Embedding-Modell, Vektordatenbank und generativem Sprachmodell: > „Es wird ein Einsatzszenario zugrundegelegt, in dem das gesamte RAG-System > on-premise bei einem Verantwortlichen betrieben wird." Für die Architektur heißt das: lokal betriebene Modelle (etwa über [Ollama](https://ollama.com/) für den Einstieg oder [vLLM](https://docs.vllm.ai/) für produktive Mehrbenutzerlast), eine lokale Vektordatenbank, kein externer Modellanbieter im Datenpfad. Sobald das System auf mehrere Betreiber verteilt wird, kommen Auftragsverarbeitung oder gemeinsame Verantwortlichkeit als zusätzliche Fragen hinzu. Der einfachste datenschutzrechtliche Aufbau ist zugleich der, der die Daten im Haus behält. ## RAG repariert kein schlecht trainiertes Modell Ein verbreitetes Missverständnis räumt die DSK direkt ab: > „Ein rechtswidrig trainiertes KI-Modell bleibt auch in einem RAG-System ein > rechtswidrig trainiertes KI-Modell." RAG verändert das Sprachmodell nicht. Die erweiterte Anfrage wird ihm nur vorgelegt, es findet kein Fine-Tuning und kein Nachtraining statt. Die Herkunft des Basismodells bleibt also getrennt zu bewerten. RAG kann die Risiken der laufenden Verarbeitung senken, aber es heilt nicht die Frage, auf welchen Daten das Modell ursprünglich trainiert wurde. Praktische Folge: ein Modell wählen, dessen Herkunft man vertreten kann, und die RAG-Schicht als das behandeln, was sie ist, eine risikomindernde Maßnahme, keine Absolution. ## Der entscheidende Punkt für den kirchlichen Kontext: besonders sensible Daten Kirchliche und diakonische Stellen verarbeiten Daten mit hohem Schutzbedarf: Seelsorge, Mitgliedschaft, Klientendaten der sozialen Arbeit, also Kategorien nach Art. 9 und Art. 10 DSGVO. Die zentrale Aussage der Orientierungshilfe dazu: > „Bei Erfüllung der datenschutzrechtlichen Anforderungen können daher auch > personenbezogene Daten mit höherem Schutzbedarf, z. B. Daten nach Art. 9 und 10 > DSGVO, verarbeitet werden, da diese nicht dauerhaft im LLM verbleiben, sofern kein > gezieltes Training oder Nachtraining stattfindet, sondern in den Referenzdokumenten > und der Vektordatenbank separat gespeichert sind." Daraus folgt eine klare Bauregel: Sensible Daten gehören ausschließlich in das kontrollierbare RAG-Subsystem, also in Referenzdokumente und Vektordatenbank, wo Rechte- und Rollenkonzept sowie Mandantentrennung greifen. Sie gehören niemals in ein Training des Modells, denn dort ist nicht mehr steuerbar, wer worauf zugreift. Diese Unterscheidung ist der Grund, warum sich ein sauber gebautes RAG für den kirchlichen Sektor überhaupt vertreten lässt. ## Der teuerste Fehler: Berechtigungen gehen beim Import verloren Hier liegt die häufigste stille Schwachstelle. Beim Import in die Vektordatenbank verlieren Dokumente ihre ursprünglichen Zugriffsrechte. Wenn der Retriever dann rein nach semantischer Ähnlichkeit sucht, liefert er auch Inhalte an Personen, die das Quelldokument nie hätten sehen dürfen. Zugriffskontrolle muss deshalb an der Retrieval- und Vektorebene sitzen, nicht erst in der Anwendung. Die DSK verlangt genau das über Mandantentrennung, funktionale Trennung und ein Rechte- und Rollenkonzept, das Bereiche der Vektordatenbank und der Referenzdokumente absichert. Technisch wird das über Metadaten-Filter im Retrieval umgesetzt, sodass eine Abfrage nur Chunks aus dem für die Rolle freigegebenen Bereich erhält (siehe etwa [Pinecone zu RAG mit Zugriffskontrolle](https://www.pinecone.io/learn/rag-access-control/) und [Zilliz zu permission-aware RAG](https://zilliz.com/blog/ensure-secure-and-permission-aware-rag-deployments)). Ein zweiter Fallstrick dabei: Auch Metadaten können verraten, was der Inhalt gerade verbirgt, etwa Dateipfade oder Abteilungsnamen. Die Rechtezuweisung an die Nutzenden muss vor der Abfrage stehen, nicht danach. ## Zweckbindung und die unsichtbare Verkettung RAG kann die Zweckbindung stärken, indem gezielt nur bestimmte Dokumente bereitgestellt werden. Es kann sie aber auch bedrohen. Wenn personenbezogene Daten aus der Vektordatenbank an das Sprachmodell übergeben werden, warnt die DSK vor > „eine[r] Verkettung [mit den im LLM enthaltenen Daten], die ggf. nicht in der > Ausgabe des RAG-Systems erkennbar ist." Das ist ein Entwurfsproblem, kein Betriebsdetail: Es gehört in die Konzeption, welche Daten überhaupt in den Kontext des Modells gelangen dürfen. ## Datenminimierung und der Löschvorteil Gegenüber einem reinen Sprachmodell hat RAG einen handfesten Vorteil: Referenzdokumente und Einträge der Vektordatenbank sind direkt adressierbar und gezielt löschbar, klassische Löschfristen sind also anwendbar. Was nicht gebraucht wird, wird schon beim Chunking entfernt oder anonymisiert. Das Problem bleibt nur beim Modell selbst: > „Ungeachtet der Vorteile bleiben die Probleme bei der Datenlöschung im Sprachmodell > bestehen." Deshalb die Empfehlung der DSK, ein eher kleineres Sprachmodell zu wählen, das weniger Fakten memoriert, und die Eignung dieser Wahl zu dokumentieren. ## Qualität ist eine Datenschutzfrage Richtigkeit personenbezogener Ausgaben ist eine Anforderung aus Art. 5 DSGVO, und RAG verbessert sie, garantiert sie aber nicht. Die konkreten Stellschrauben sind technisch: - **Deutschsprachiges Embedding-Modell.** Für deutsche Dokumente ein Embedding-Modell verwenden, das auf deutschsprachigen Texten trainiert wurde. Sonst leidet die Retrieval-Qualität. - **Saubere Aufbereitung.** Kopf- und Fußzeilen bereinigen, sinnvolle Chunk-Größe und Überlappung wählen. Schlechtes Chunking zerstört den Sinnzusammenhang. - **Systemprompt mit Quellenbindung.** Das System anweisen, „ausschließlich mithilfe der referenzierten Quellen zu antworten." Das reduziert Halluzinationen. - **Keine Websuche.** Zur Einbindung externer Quellen ist die DSK deutlich: Deren Anforderungen an Rechtmäßigkeit und Richtigkeit „werden regelmäßig bei Einbindung einer Websuche nicht erfüllt." ## Sicherheit und die Grenzen der Transparenz Die üblichen technisch-organisatorischen Maßnahmen gelten auch für die Vektordatenbank. Als Angriffsvektoren nennt die DSK ausdrücklich Membership-Inference-Angriffe und Data Poisoning und verweist dabei auf [PoisonedRAG](https://arxiv.org/abs/2402.07867) und die [OWASP-Risikoliste LLM04:2025](https://genai.owasp.org/llmrisk/llm042025-data-and-model-poisoning/). Umgekehrt kann ein kuratierter RAG-Bestand selbst gegen vergiftete Trainingsdaten wirken. Bei der Transparenz ist ehrlich zu bleiben: Die genutzten Quellen lassen sich dokumentieren, das macht den Input des Modells nachvollziehbar. Das Modell selbst wird dadurch nicht erklärbar: > „Eine Erhöhung der datenschutzrechtlichen Transparenz in Bezug auf das eingesetzte > LLM kann hingegen nicht erreicht werden." Ebenso sind Betroffenenrechte auf der Ebene von Prompt, Ausgabe, Referenzdokument und Vektordatenbank in der Regel umsetzbar, während sie gegenüber dem Modell selbst „weitgehend ungelöst" bleiben. ## Bezug zum kirchlichen Datenschutzrecht Für die katholischen und evangelischen Träger gelten mit KDG und DSG-EKD eigene, der DSGVO nachgebildete Datenschutzgesetze mit eigenen Aufsichten. Beide Aufsichten verweisen ihre Stellen auf die DSK-Orientierungshilfen als sachlichen Leitfaden, ohne sie förmlich für bindend zu erklären. Der EKD-Datenschutzbeauftragte etwa hält die KI-Orientierungshilfe für einen Leitfaden, der „auch in Kirche und Diakonie" dienen kann. Die Aussage der RAG-Orientierungshilfe zu Art.-9- und Art.-10-Daten stützt dabei genau das, was der Sektor ohnehin braucht: ein rein im Haus betriebenes RAG ohne externe Datenanbindung. Denn nur so greifen Rollenkonzept und Mandantentrennung, und nur so lässt sich, in den Worten der DSK, vermeiden, > „dass personenbezogene Daten an Online-Betreiber großer Sprachmodelle übertragen > werden." Die Orientierungshilfe macht RAG nicht komplizierter. Sie macht die Architekturentscheidungen explizit, die man ohnehin treffen muss. ## Quellen - DSK, Orientierungshilfe „Datenschutzrechtliche Besonderheiten generativer KI-Systeme mit RAG-Methode", Oktober 2025: [PDF](https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf) - DSK, Orientierungshilfe „Künstliche Intelligenz und Datenschutz", 06.05.2024: [PDF](https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf) - DSK, Orientierungshilfe zu TOMs bei KI-Systemen, Juni 2025: [PDF](https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf) - Lewis et al., „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", arXiv:2005.11401: [Link](https://arxiv.org/abs/2005.11401) - Pinecone, „RAG with Access Control": [Link](https://www.pinecone.io/learn/rag-access-control/) - OWASP GenAI, „LLM04:2025 Data and Model Poisoning": [Link](https://genai.owasp.org/llmrisk/llm042025-data-and-model-poisoning/) --- # Der Mittelweg: EU-gehostete KI ohne Datenspeicherung, und was daran zu prüfen ist > Zwischen US-Cloud und eigenem Server gibt es einen dritten Weg: europäische KI-Dienste, die keine Inhalte speichern. Das nimmt den Betriebsaufwand, ist aber eine vertragliche Zusage, keine Selbstverständlichkeit. Kanonische URL: https://kirchliche-ki.de/newsletter/eu-gehostete-ki-ohne-speicherung/ · Veröffentlicht: 2026-07-18 Ein eigener Server im Haus ist der sauberste Weg, KI über sensible Daten laufen zu lassen. Er ist aber auch der aufwändigste: Hardware, Betrieb, Updates, Fachpersonal. Viele Träger scheuen genau diesen Aufwand. Die bequeme Gegenrichtung, ein Modell direkt beim US-Anbieter, ist rechtlich heikel. Dazwischen liegt ein dritter Weg, über den zu wenig gesprochen wird: europäisch gehostete KI-Dienste, bei denen die eigenen Inhalte gar nicht erst gespeichert werden. Er nimmt den Betriebsaufwand ab, ohne die Daten in eine US-Cloud zu geben. Der Haken ist nur: „keine Speicherung" ist kein Naturgesetz, sondern eine Zusage, die man prüfen muss. ## Was „keine Speicherung" bei den großen Anbietern wirklich heißt Hier lohnt Genauigkeit, denn die Lage ist besser und zugleich verzwickter, als die Schlagworte vermuten lassen. **Training.** Die großen Anbieter trainieren ihre Modelle standardmäßig nicht mehr mit den Daten aus ihrer Programmierschnittstelle. Das ist heute die Regel, nicht die Ausnahme, und bei mehreren Anbietern ausdrücklich ein Opt-in, kein Opt-out. **Speicherung.** Hier trennen sich die Wege. Mancher Anbieter speichert die eigentlichen Inhalte der Anfragen von vornherein nicht. Ein anderer hält standardmäßig ein **Missbrauchs-Protokoll** vor, meist rund 30 Tage, um Missbrauch zu erkennen. Das ist der wahre Standardwert hinter der oft gehörten „30 Tage": nicht ein Inhaltsarchiv, sondern ein befristetes Sicherheits-Log. **Echte Null-Speicherung.** Dieses Log ganz abzuschalten, also eine verifizierbare Zero Data Retention, ist bei allen großen Anbietern eine **separate, freigabepflichtige Stufe**, gebunden an einen Unternehmensvertrag. Bei einem Anbieter lässt sich das Abschalten sogar technisch nachweisen, über ein Protokoll-Flag, das man im Portal einsehen kann. Der entscheidende Punkt: Null-Speicherung ist eine beantragte Vertrags­stufe, kein Häkchen im Standardtarif. **Und selbst dann bleiben Ausnahmen.** Auch unter einem Null-Speicher-Vertrag gibt es Rückausnahmen: Bestimmte Modelle sind ausgenommen und erzwingen weiterhin eine 30-Tage-Aufbewahrung. Als auffällig markierte Inhalte können deutlich länger vorgehalten werden, teils bis zu zwei Jahren. Und zustandsbehaftete Funktionen wie Dateiablagen, Agenten-Sitzungen oder Stapelverarbeitung fallen oft gar nicht unter die Null-Speicher-Zusage. Wer „keine Speicherung" hört, muss also fragen: keine Speicherung wovon, mit welchen Ausnahmen, ab welcher Vertragsstufe. ## Der Mittelweg als fertiges Produkt Genau hier setzen europäische KI-Arbeitsplätze und Gateways an. Sie bündeln drei Dinge in einen einzigen europäischen Vertrag: Betrieb auf EU-Servern, einen Auftragsverarbeitungsvertrag, und die Zusage, Inhalte weder zu speichern noch für Training zu nutzen. Im Hintergrund laufen dabei häufig dieselben bekannten Modelle, aber über deren EU-Residency- und Null-Speicher-Stufen, eingepackt in einen Anbieter, mit dem die Organisation direkt kontrahiert. Der praktische Reiz ist offensichtlich: Man bekommt einen großen Teil des On-Premise-Nutzens, ohne selbst einen Server zu betreiben. ## Woran man einen solchen Anbieter misst Die eigentliche Arbeit ist nicht die Auswahl eines Namens, sondern die Prüfung der Zusagen. Sieben Fragen, die vor einem Vertrag zu beantworten sind: 1. **Wo läuft das Modell wirklich?** Verarbeitung *und* Speicherung in der EU, nicht nur eine europäische Rechnungsadresse. Vorsicht bei „Global"-Betriebsarten, die den Datenverkehr still aus der EU herausführen können. 2. **Gibt es einen echten Auftragsverarbeitungsvertrag**, der die Unterauftragnehmer benennt, einschließlich des eigentlichen Modellanbieters? 3. **Ist „keine Speicherung" vertraglich und überprüfbar?** Bildet die Zusage die Null-Speicher-Stufe des zugrunde liegenden Anbieters ab, und lässt sie sich technisch nachweisen, nicht nur behaupten? 4. **Welche Ausnahmen gelten?** Missbrauchs-Log-Fenster, Aufbewahrung markierter Inhalte, zustandsbehaftete Funktionen. Genau dort leckt „Null-Speicherung". 5. **Kein Training auf Inhalten**, schriftlich, und zwar auch für die Unterauftragnehmer. 6. **Weiterleitung in Drittländer.** Fließen auch nur Metadaten oder Ausweichverkehr an eine US-Mutter? 7. **Zertifikate richtig einordnen.** ISO 27001, SOC 2 oder C5 belegen den sicheren Betrieb, nicht die Rechtsgrundlage für einen Datentransfer. Sie sind notwendig, aber nicht hinreichend. ## Warum der US-Bezug weiter ein Risiko bleibt Der Grund, warum der europäische Weg überhaupt attraktiv ist, liegt in der Geschichte des transatlantischen Datentransfers. Die Angemessenheitsgrundlage für die USA wurde in der Vergangenheit bereits zweimal gekippt (Safe Harbor 2015, Privacy Shield 2020). Der aktuelle Nachfolger, das Data Privacy Framework, gilt zwar weiter und wurde 2025 gerichtlich bestätigt, steht aber 2026 erneut unter juristischem Druck (siehe die Quellen unten). Wer auf einen EU-gehosteten Dienst ohne US-Datenfluss setzt, macht sich von diesem wackligen Mechanismus unabhängiger. Das ist der eigentliche, nüchterne Vorteil des Mittelwegs, jenseits des Marketings. ## Die Grenze für den kirchlichen Bereich Für einen großen Teil der Verwaltungs- und Büroarbeit ist dieser Mittelweg vertretbar, wenn die Zusagen stimmen und geprüft sind. Für **besonders sensible Daten** aber reicht er nicht: Seelsorge, Gesundheits- und Klientendaten der diakonischen oder caritativen Arbeit, alles, was einem Berufsgeheimnis unterliegt. Sobald man die volle Kontrolle über Rollen, Speicherung und Datenfluss braucht, führt kein Weg am eigenen Server vorbei. Die Auftragsverarbeitung ist im kirchlichen Datenschutzrecht (KDG und DSG-EKD) eigenständig geregelt, in der Sache aber vergleichbar streng; die Einordnung der Datenklasse steht auch hier am Anfang. Der Mittelweg ist damit keine Universallösung, sondern die richtige Antwort für eine bestimmte Datenklasse. „Keine Speicherung" ist ein guter Weg, solange die Zusage vertraglich verankert, auf die Datenklasse abgestimmt und nachprüfbar ist. Die Arbeit besteht darin, sie zu prüfen, nicht sie zu glauben. ## Quellen - DSK, Orientierungshilfe „Künstliche Intelligenz und Datenschutz", 06.05.2024: [PDF](https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf) - Europäischer Datenschutzausschuss, Stellungnahme 28/2024 zu KI-Modellen: [PDF](https://www.edpb.europa.eu/system/files/2025-05/edpb_opinion_202428_ai-models_de.pdf) - OpenAI, Data controls in the OpenAI platform: [Link](https://developers.openai.com/api/docs/guides/your-data) - Anthropic, API and data retention: [Link](https://platform.claude.com/docs/en/manage-claude/api-and-data-retention) - Microsoft, Data, privacy and security für Foundry Models (Azure OpenAI): [Link](https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy) - Zum Stand des Data Privacy Framework 2025/2026: [Freshfields (Urteil 2025)](https://www.freshfields.com/en/our-thinking/blogs/technology-quotient/eu-us-data-privacy-framework-survives-its-first-judicial-challenge-but-more-are-102l4m1), [activeMind (Druck 2026)](https://www.activemind.legal/guides/dpf-supreme-court/) --- # Cloud oder eigener Server? Die erste Architekturentscheidung für KI im kirchlichen Kontext > Nicht „welches Modell?“ ist die erste Frage, sondern „wo läuft es?“, und die Antwort hängt nicht am Bauchgefühl, sondern an der Schutzklasse der Daten. Kanonische URL: https://kirchliche-ki.de/newsletter/cloud-oder-eigener-server/ · Veröffentlicht: 2026-07-15 Wer im kirchlichen oder sozialwirtschaftlichen Umfeld über KI nachdenkt, fragt meist zuerst nach dem Modell: GPT, Claude, ein offenes Modell? Das ist die falsche erste Frage. Die erste Entscheidung ist die **Architektur**: *wo* läuft das System, und wer sieht dabei die Daten? Drei Wege, ehrlich gegenübergestellt. ## 1. EU-gehostete Managed-Plattform Eine Oberfläche wie Open WebUI, betrieben in der EU, mit quelloffenen Modellen (etwa Mistral, Llama oder Qwen), Auftragsverarbeitungsvertrag, Mandanten-Trennung und Rollenrechten. Für einen großen Teil der Büro- und Wissensarbeit, Protokolle, Recherche, Entwürfe, Gemeindekommunikation, ist das ein tragfähiger, kosteneffizienter Standard. Kein US-Cloud-Zwang, keine Abhängigkeit von einem einzelnen Modellanbieter. ## 2. Selbst betrieben Ein offenes Modell auf einem deutschen Server oder direkt im Haus (etwa mit Ollama oder vLLM). Kein externer Dienst sieht die Daten, keine laufenden Token-Kosten, volle Kontrolle. Der Preis dafür ist Betriebsaufwand: Hardware, Updates, Betrieb. Das ist der Weg für **besonders schützenswerte Daten**, Seelsorge, Gesundheit, alles unter § 203 StGB. ## 3. US-Cloud direkt GPT oder Claude direkt beim US-Anbieter. Im kirchlichen Kontext meist die schwierigste Option: Drittlandtransfer, Risikoabwägung, und die vom kirchlichen Recht geforderte Exit-Strategie lassen sich hier am schwersten sauber begründen. ## Woran man die Wahl festmacht, und woran nicht Nicht am Hype und nicht am Bauchgefühl, sondern an der **Schutzklasse der Daten**. Deshalb steht am Anfang jedes seriösen Projekts die Klassifizierung. Wo nicht klassifiziert wurde, gilt im Zweifel die strengste Klasse, das ist kein Detail, sondern der Ausgangspunkt. Öffentliche und interne Verwaltungstexte? Eine EU-Plattform reicht oft. Seelsorge- oder Gesundheitsdaten? Eigener Server, im Zweifel ohne externe Datenverbindung. Der häufigste Fehler ist, das zu vermischen. Einen Gemeindebrief über einen abgeschotteten Server laufen zu lassen, ist verschwendete Mühe. Seelsorgedaten über eine beliebige Cloud zu schicken, ist ein Datenschutzverstoß. Die eigentliche Architekturarbeit besteht darin, beides sauber zu trennen, und für unterschiedliche Datenklassen unterschiedliche Wege vorzusehen, statt einer Universallösung. ## Warum offene Modelle hier wichtig sind Wer auf quelloffene Modelle setzt, bleibt beweglich: dasselbe Modell kann in der EU-Cloud *oder* auf dem eigenen Server laufen. Man verwettet das Projekt nicht auf einen einzelnen US-Anbieter und dessen Preise, Verfügbarkeit und Rechtslage. Das kirchliche Datenschutzrecht, die geforderte Risikoabwägung, die verbindliche Exit-Strategie, die Voreinstufung nicht klassifizierter Verarbeitungen in die strengste Klasse, drängt genau auf diese Disziplin. Das ist eine **Randbedingung für die Architektur**. Die juristische Bewertung selbst gehört in die Hände des Datenschutzbeauftragten oder einer Kanzlei. Auf der technischen Seite besteht die Aufgabe darin, das System so zu bauen, dass es diese Bedingungen von vornherein erfüllt, statt sie später nachzurüsten.