Nicht klassifiziert heißt Klasse III: Was § 9 KDG-DVO über die Architektur eines KI-Projekts entscheidet

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? 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 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 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)
• 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)
• 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)
• Datenschutzgesetz der Evangelischen Kirche in Deutschland (DSG-EKD), für § 27 (technische und organisatorische Maßnahmen, risikobasiert statt klassifizierend): kirchenrecht-ekm.de