Exit-Strategie für ein KI-System: Was § 18 KDG-DVO verlangt und warum der Vektorindex nicht mitwandert, kirchliche-ki.de

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 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:

Die Quelldokumente in der Ablage des Dienstes. Portabel, weil sie das Format behalten, in dem sie hochgeladen wurden.
Den Vektorindex, also die Einbettungen der zerlegten Dokumente. Nicht portabel, siehe unten.
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.
Die Konfiguration: Systemprompts, Assistenten, Wissensbasen-Zuschnitte, Rollen- und Rechtemodell. Formal proprietär, inhaltlich das eigentliche Projektergebnis.
Eine etwaige Feinabstimmung, also trainierte Gewichte auf Basis eigener Daten.
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), 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). 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.

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.
Das Inventar aufnehmen, nicht den Dienst bewerten. Sechs Bestände, sechs getrennte Antworten auf die Frage nach Rückgabe und Löschung.
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.
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.
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.
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.
Das Löschwahlrecht nach § 29 Absatz 4 Buchst. g KDG vor Vertragsschluss ausüben und den Nachweisweg nach § 9 Absatz 7 gleich mit vereinbaren.
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)
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)
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)
Datenschutzgesetz der Evangelischen Kirche in Deutschland (DSG-EKD), für § 30 Absatz 3 (Vertragsinhalte der Auftragsverarbeitung, Rückgabe und Löschung): kirchenrecht-ekm.de
IT-Sicherheitsverordnung der EKD (ITSVO-EKD) vom 29. Mai 2015, für § 1 Absatz 3 (Orientierung am BSI): kirchenrecht-ekd.de
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
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
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
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