CDCF — Catholic Digital Commons Foundation

Governance-as-Code für den Einsatz katholischer Technologie

Dokumenttyp Forschungsnotiz
Status Arbeitsentwurf — U.S.A. C-DART 1 Diskussion
Beziehung Ergänzende Forschung, die den CDCF-Projektprüfungsrichtlinien v0.2 zugrunde liegt

Inhaltsverzeichnis

  1. Das Kernargument
  2. Was Governance-as-Code ist
  3. Warum katholische Institutionen es benötigen
  4. Der Drei-Schichten-Stack
  5. Die Gate-Entscheidung als primäres Artefakt
  6. Anwendung auf den Einsatz von KI
  7. Anwendung auf die Einhaltung von Standards
  8. Ehrliche Bewertung der institutionellen Bereitschaft
  9. Was katholische Institutionen jetzt tun können
  10. Beziehung zur CDCF
  11. Bibliographie

Das Kernargument

Die Technologie-Governance in katholischen Institutionen existiert derzeit in PDFs und Ausschusssitzungen. Wenn eine Diözese, Schule oder katholisches Krankenhaus ein Technologiesystem einführt — sei es ein KI-Tool, eine Plattform für das Pfarrmanagement, eine Datenintegrationslösung oder ein liturgisches Softwareprojekt — produziert der Governance-Prozess typischerweise ein Dokument, das besagt, dass das System genehmigt ist. Dieses Dokument existiert unabhängig von dem System, das es regiert. Es kann eine nicht konforme Einführung nicht verhindern. Es kann nicht automatisch validiert werden. Es kann nur reagieren, nachdem etwas schiefgegangen ist.

Governance-as-Code ist die Praxis, diese Richtliniendokumente in maschinenlesbare Spezifikationen umzuwandeln, die direkt in die Bereitstellungspipelines integriert sind. Die Governance wird Teil der Infrastruktur. Dieser Wandel findet bereits in regulierten Unternehmensumgebungen statt. Die Frage für katholische Institutionen ist, ob sie daran teilnehmen, was diese Spezifikationen kodieren, oder ob sie weltliche Governance-Schemata übernehmen, die ohne Bezug auf katholische Morallehre, kanonische Autorität oder das bevorzugte Anliegen der Kirche für die Verwundbaren entworfen wurden.

Das Prinzip gilt in zwei Dimensionen der Mission der CDCF. Für Technologieeinsätze setzt Governance-as-Code die Prüfungsrichtlinien als harte Tore durch, bevor ein Projekt die Produktion erreicht. Für Standards Compliance überprüft Governance-as-Code, dass Projekte den CDCF-Datenstandards entsprechen — den gemeinsamen Identifikatoren und Darstellungen für liturgische Feiern, magisteriale Dokumente, Schriftversionen und kanonische Strukturen — automatisch und kontinuierlich.

Was Governance-as-Code ist

In einer Governance-as-Code-Architektur werden die Anforderungen an die Richtlinien als versionskontrollierte Schemata (typischerweise JSON oder YAML) ausgedrückt, die genau definieren, was ein Technologiesystem nachweisen muss, bevor es in die Produktion gehen kann. Wenn ein Entwickler versucht, ein Projekt bereitzustellen, ruft die Bereitstellungspipeline diese Schemata als harte Tore auf.

Die Torlogik ist deterministisch. Alle Tore bestehen und das Projekt wird bereitgestellt. Ein Tor nicht bestanden und es wird nicht bereitgestellt. Jede Entscheidung, bestehen oder nicht bestehen, wird in einem unveränderlichen Prüfprotokoll festgehalten, das von Regulierungsbehörden, diözesanen Behörden oder der institutionellen Leitung nachträglich überprüft werden kann.

Die Schemata selbst definieren die Governance-Kriterien: welche Nachweise für Tests erforderlich sind, welche Datenbereiche das System berühren darf, unter welchem Maß an menschlicher Aufsicht es betrieben wird, wer die benannte verantwortliche Person ist, welche Bedingungen eine Eskalation an eine höhere Autorität erfordern und — für Projekte in Bereichen, die von CDCF-Standards abgedeckt werden — ob die Datenrepräsentationen des Projekts den kanonischen Schemata entsprechen. Dies sind die gleichen Fragen, die die CDCF-Prüfungsrichtlinien stellen. Governance-as-Code ist die technische Architektur, die diese Fragen in durchsetzbare Tore anstelle von beratenden Checklisten verwandelt.

Dies unterscheidet sich von der Verwendung von KI zur Steuerung von Technologie. Die Entscheidung über das Tor in einer Governance-as-Code-Architektur ist deterministisch: Ein Schema besteht entweder oder es besteht nicht, basierend auf expliziten Kriterien, die im Voraus von menschlichen Autoritäten definiert wurden. KI kann bei der Synthese von Beweisen und der Identifizierung von Risiken innerhalb der Pipeline helfen, aber die Torlogik selbst bleibt unter menschlich definiertem, maschinenunterstütztem Kontroll.

Ein strukturelles Anliegen in der gesamten Technologie-Governance ist die Compliance-Lücke zwischen regulatorischer Absicht und praktischer Umsetzung. Aktuelle Governance-Rahmenwerke weisen drei wiederkehrende Lücken auf: Unklarheit im Umfang bei der Definition der abgedeckten Systeme, zeitpunktbezogene Compliance-Anforderungen, die Systeme nicht berücksichtigen, die sich nach der ursprünglichen Genehmigung weiterentwickeln, und Informationsasymmetrien zwischen Regulierungsbehörden und umsetzenden Institutionen.1 Governance-as-Code adressiert direkt alle drei: Schema-Definitionen legen den Umfang präzise fest, versionskontrollierte Schemata entwickeln sich mit dem System, das sie steuern, und unveränderliche Prüfpfade schließen die Informationslücke.

Die Kommission der Bischofskonferenzen der Europäischen Union (COMECE) bekräftigt, dass die Bewertung von Technologie aus einer ethischen Perspektive „interne Kontrollprinzipien und Risikobewertungen zusätzlich zur Gesetzgebung erfordert.“2 Governance-as-Code ist die direkte Umsetzung dieser vorgeschriebenen internen Kontrollprinzipien, die die ethische Bewertung von einer periodischen Überprüfungsaktivität in eine kontinuierliche, durchsetzbare Infrastruktur-Anforderung übersetzt.

Warum katholische Institutionen es benötigen

Das Fragmentierungsproblem, das im begleitenden Memo zu katholischer digitaler Governance im großen Maßstab dokumentiert ist, ist im Wesentlichen ein Problem der Governance-Codierung — sowohl bei der Technologieumsetzung als auch bei der digitalen Infrastruktur.

Technologieumsetzung. Jede Diözese drückt ihre Werte der katholischen Technologie-Governance in einem anderen Format, auf einem anderen Detaillierungsgrad und für unterschiedliche Zielgruppen aus. Orange hat eine Ratscharta verfasst. Biloxi hat ein Dekret erlassen. Arlington hat eine Schulrichtlinie geschrieben. Keines dieser Instrumente ist maschinenlesbar. Keines von ihnen kann automatisch validiert werden. Ein Anbieter kann alle drei Dokumente anerkennen und dennoch ein nicht konformes System bereitstellen, da die Dokumente keinen technischen Durchsetzungsmechanismus haben.

Standards-Compliance. Dasselbe Problem gilt für digitale Standards. Selbst wenn gemeinsame kanonische Identifikatoren für liturgische Feiern, magisterielle Dokumente oder Schrifteditionen existieren, kann ein Projekt die Compliance beanspruchen, ohne verifiziert zu werden. Ohne maschinendurchsetzbare Schemata, die definieren, wie die Konformität zu einem CDCF-Standard aussieht, hängt die Annahme von Standards von freiwilliger Disziplin statt von architektonischer Durchsetzung ab.

Governance-as-Code verändert beide strukturellen Beziehungen. Ein gemeinsames kanonisches Governance-Schema — ein Basisset von maschinenexekutierbaren Richtlinien, die die Prinzipien von Antiqua et Nova,3 den USCCB-Prinzipien,4 den ethischen und religiösen Richtlinien und den CDCF-Datenstandards in versionskontrollierte, wiederverwendbare Spezifikationen kodieren — würde es jeder Diözese ermöglichen, die gemeinsame Basis zu übernehmen und sie mit lokalen Anforderungen zu erweitern. Subsidiarität wird gewahrt, da die lokale Autorität weiterhin lokale Entscheidungen trifft. Solidarität wird erreicht, weil jede Institution, die auf der gemeinsamen Basis operiert, interoperabel ist.

Ein Anbieter, der katholische Schulen bedient, würde mit einem kanonischen Schema mit optionalen diözesanen Erweiterungen konfrontiert, anstatt mit Dutzenden inkompatibler Checklisten. Ein katholisches Krankenhaus-System, das über diözesane Grenzen hinweg operiert, könnte einheitlich bereitstellen, da die Governance-Infrastruktur über die Zuständigkeiten hinweg kompatibel ist. Ein liturgisches Softwareprojekt könnte seine Konformität zu CDCF-Kalenderidentifikatoren als Teil jedes Builds überprüfen. Die Governance wird so portabel wie die Werkzeuge, die sie steuert.

Der Rome Call for AI Ethics fordert, dass Prinzipien und Werte in einen Rahmen integriert werden, der „als Bezugspunkt für digitale Ethik fungiert, unsere Handlungen leitet und die Nutzung von Technologie zum Nutzen der Menschheit fördert.“5 Die Governance-Plattformschicht dieser Architektur antwortet direkt auf diesen Aufruf und schafft einen gemeinsamen, greifbaren Bezugspunkt für digitale Ethik, der über die Grenzen katholischer Institutionen hinweg durchsetzbar ist, anstatt nur aspirational zu sein.

Der Drei-Schichten-Stack

Eine ausgereifte Governance-as-Code-Architektur für den Einsatz katholischer Technologien funktioniert auf drei Ebenen, die jeweils eine distinct institutionelle Funktion erfüllen.

Ebene Funktion Primäre Nutzer CDCF-Rolle
Infrastruktur CI/CD-Pipeline-Hooks, Kubernetes-Zulassungscontroller, Bereitstellungs-Gate-Logik, Standardsvalidierungsprüfungen. Wo Schemata als harte Tore fungieren und Prüfprotokolle erstellt werden. Entwickler und DevOps-Teams Trägt zu den Schema-Spezifikationen bei
Governance-Plattform Schema-Bibliothek: versionskontrollierte Richtlinenspezifikationen, Risikoklassifizierungslogik, kanonische katholische Governance-Baseline, CDCF-Standardskonformitätsschemata. Wo katholische moralische Theologie und kanonische Anforderungen als maschinenlesbare Kriterien kodiert sind. Diözesane IT-Büros und Governance-Leiter Verwaltet die gemeinsame kanonische Basislinie
Anwendung Institutionen zugewandte Werkzeuge: Onboarding-Workflows, Risikodashboards, Berichte zur Standardskonformität, Prüfungsartefakte für die diözesane Führung und externe Regulierungsbehörden. Pfarr- und Schuladministratoren Stellt Vorlagen und Werkzeuge bereit

Diese drei Ebenen entsprechen direkt den drei Ebenen institutioneller Kapazität, die katholische Organisationen tatsächlich haben. Eine kleine Pfarrei oder Schule operiert hauptsächlich auf der Anwendungsebene und nutzt Governance-Tools, ohne die zugrunde liegende Infrastruktur verstehen zu müssen. Ein diözesanes IT-Büro arbeitet auf der Governance-Plattform-Ebene und übernimmt und erweitert kanonische Schemata für den lokalen Kontext. Ein großes katholisches Gesundheitssystem oder eine Universität operiert auf der Infrastruktur-Ebene und integriert Governance-Tore in ihre eigenen CI/CD-Pipelines.

Die Gate-Entscheidung als primäres Artefakt

Das bedeutendste Entwurfsprinzip in diesem Rahmen ist, dass die Gate-Entscheidung selbst, die Genehmigung, bedingte Genehmigung, Ablehnung oder Verschiebung, als erstklassiges Artefakt behandelt wird, anstatt als Nebenprodukt des Überprüfungsprozesses.

Ein Gate-Entscheidungsartefakt erfasst die spezifischen Beweise, die gesammelt wurden, die zugewiesenen Vertrauensniveaus, die identifizierten Lücken, den benannten menschlichen Entscheidungsinhaber, die Begründung für das Ergebnis und die Bedingungen, unter denen die Entscheidung getroffen wurde. Es ist unveränderlich, sobald es aufgezeichnet ist. Es ist das Dokument, das die Frage des Regulators, die Frage des Bischofs und die Frage der betroffenen Person beantwortet: Warum wurde dieses System bereitgestellt, unter wessen Autorität und auf welcher Grundlage.

Dieses Design spiegelt direkt den kanonischen Standard wider, der in Kanon 1609 festgelegt ist, der verlangt, dass deliberative Prozesse schriftliche Schlussfolgerungen mit Gründen in Recht und Tatsache produzieren und dass die Möglichkeit zur Überprüfung und Berufung erhalten bleibt.6 Ein Gate-Entscheidungsartefakt ist die technische Umsetzung dieser kanonischen Anforderung.

Die Unveränderlichkeit des Prüfpfades dient auch einem spezifisch katholischen institutionellen Anliegen. Die USCCB warnt, dass Technologie missbraucht werden kann, um “die Würde der Personen und den Respekt vor der Wahrheit zu untergraben” durch die Manipulation von Informationen.7 Ein unveränderlicher Gate-Entscheidungsnachweis stellt sicher, dass, wenn ein bereitgestelltes System entgegen seiner Governance-Spezifikation funktioniert, die institutionelle Verantwortlichkeit klar, nachvollziehbar und für eine Überprüfung erhalten bleibt. Die praktischen Konsequenzen unregulierter Prüfpfade sind in Unternehmensbereitstellungen dokumentiert: Wenn ein Produktionssystem ein überholtes Richtliniendokument ohne erfasste Herkunft abruft, kann die Organisation nicht rekonstruieren, was das System gesehen hat oder warum, was die Reaktion auf Vorfälle in forensisches Rätselraten anstelle von evidenzbasierter Verantwortlichkeit verwandelt.8

Die vier Entscheidungszustände haben unterschiedliche Implikationen.

Entscheidungsstatus Bedeutung Dokumentationsanforderung
Go Alle Governance-Kriterien erfüllt; Bereitstellung autorisiert Vollständige Nachweise der Kriterien dokumentiert
Conditional-go Bereitstellung autorisiert, vorbehaltlich spezifischer Bedingungen innerhalb eines definierten Zeitrahmens Bedingungen und Zeitrahmen spezifiziert; typischerweise verwendet, wenn eine unabhängige Validierung aussteht
No-go Eines oder mehrere Kriterien wurden nicht erfüllt; Bereitstellung blockiert Spezifische Kriterien und Nachweislücken dokumentiert
Defer Eskalation an eine höhere Autorität erforderlich, bevor fortgefahren werden kann Behörde identifiziert und Grund spezifiziert

Anwendung auf KI-Bereitstellung

Die Bereitstellung von KI ist der Bereich, in dem Governance-as-Code am dringendsten und technisch am weitesten fortgeschritten ist.

Forscher, die Misserfolge von Multi-Agenten-Systemen untersuchen, haben 14 verschiedene Fehlermodi in drei Kategorien identifiziert (Systemdesignprobleme, Fehlanpassung zwischen Agenten und Aufgabenverifikationsfehler), was die strukturelle Bedeutung deterministischer Gate-Logik gegenüber agentenvermittelter Compliance-Überprüfung unterstreicht.9 Empirische Umfragedaten von 306 KI-Praktikern aus 26 Bereichen bestätigen, dass Zuverlässigkeit die größte Herausforderung bei der Bereitstellung bleibt, wobei 68 Prozent der Produktionsagenten zehn oder weniger Schritte ausführen, bevor menschliches Eingreifen erforderlich ist.10 Diese Ergebnisse plädieren für Governance-Architekturen, in denen menschlich definierte, maschinell durchgesetzte Gates das primäre Kontrollmechanismus sind, anstelle von Urteilen der Agenten.

Der regulatorische Druck verstärkt die Dringlichkeit. Der EU-KI-Gesetz, mit wichtigen Verpflichtungen für Hochrisiko-KI-Systeme, die 2026 in Kraft treten, schafft strukturelle Nachfrage nach prüfbarer Bereitstellungs-Governance in Hochrisiko-KI-Kategorien.11 Katholische Gesundheitsversorgung, Bildung und soziale Dienste operieren genau in diesen Kategorien.

Rahmenwerk Rechtsgebiet Wichtigste Lücke
Kalifornien SB 53 U.S. (Kalifornien) Unklarheit des Anwendungsbereichs für abgedeckte Systeme
New York RAISE Act U.S. (New York) Zeitpunkt-Compliance, keine Nachverfolgung nach Genehmigung
U.S. AIREA Bundesebene Informationsasymmetrie zwischen Regulierungsbehörden und Bereitstellern
EU KI-Gesetz GPAI-Verpflichtungen Europäische Union Alle drei Lücken sind in großem Maßstab vorhanden

Eine KI-spezifische Governance-as-Code-Implementierung kodiert die KI-Bereichserweiterungen aus den CDCF-Vorprüfungsrichtlinien – Offenlegung von Trainingsdaten, Leistungsanalyse von Untergruppen, kanonische Randbedingungen – als maschinell durchsetzbare Schemata innerhalb der gemeinsamen kanonischen Basislinie. Dies unterscheidet sich von der Verwendung von KI zur Steuerung von KI: Die Gate-Logik bleibt deterministisch, und eine von KI gesteuerte Pipeline würde eine eigene Governance erfordern, was eine Rückschritt erzeugt, die die deterministische Schema-Durchsetzung vermeidet.

Anwendung auf die Einhaltung von Standards

Die Governance-as-Code-Architektur erstreckt sich natürlich auf die Einhaltung der CDCF-Datenstandards.

Wenn die CDCF kanonische Identifikatoren für liturgische Feiern (CLEDR), magisteriale Dokumente (CMDDR) oder Ausgaben des römischen Messbuchs (CRMETDR) definiert, können diese Standards als maschinenlesbare Validierungsschemata ausgedrückt werden. Ein liturgisches Softwareprojekt, das die Konformität zu CLEDR beansprucht, kann diese Behauptung automatisch in seiner Build-Pipeline verifizieren lassen. Eine katechetische Plattform, die auf magisteriale Dokumente verweist, kann ihre Identifikatoren zum Zeitpunkt der Bereitstellung gegen das CMDDR-Schema validieren.

Dies verlagert die Einhaltung von Standards von einer Dokumentationsbehauptung („wir folgen den CDCF-Standards“) zu einer architektonischen Tatsache („unsere Pipeline verifiziert die CDCF-Standards bei jedem Build“). Die Governance-Plattformschicht verwaltet die kanonischen Schemata, und die Infrastrukturschicht setzt sie durch – dieselbe Architektur, die die Ethik der Bereitstellung regelt, regelt auch die Dateninteroperabilität.

Für katholische Institutionen ist diese Integration von Bedeutung. Ein Projekt, das sowohl die Kriterien für die Überprüfung als auch die Standards für die Konformität besteht, trägt ein Maß an Sicherheit, das kein Politikdokument allein bieten kann: Es wurde gegen die Anforderungen der katholischen Governance validiert und interoperiert mit der gemeinsamen digitalen Infrastruktur der Kirche, beides verifiziert durch maschinenverbindliche Beweise anstelle von Selbstattestierungen.

Ehrliche Bewertung der institutionellen Bereitschaft

Die vollständige technische Implementierung von Governance-as-Code auf der Infrastrukturebene übersteigt die derzeitige Kapazität der meisten katholischen Institutionen, und eine Überbewertung dieser Kapazität würde die Art von Glaubwürdigkeitslücke in der Governance erzeugen, die dieses Framework zu verhindern versucht. Die meisten katholischen Institutionen, einschließlich gut ausgestatteter Diözesen und Gesundheitssysteme, operieren derzeit bestenfalls auf der Anwendungsebene. Sie haben Politikdokumente. Einige haben Prüfungsausschüsse. Sehr wenige haben versionskontrollierte Governance-Schemata. Keines, nach dem Wissen dieser Forschung, hat kanonische katholische Governance-Schemata als harte Tore in CI/CD-Bereitstellungspipelines eingebettet.

Diese Lücke ist die Gelegenheit, und sie ist der Grund, warum die CDCF-Vetting-Kriterien so strukturiert sind, wie sie sind. Kriterium 6 erfordert eine schriftliche, überprüfbare Governance-Spezifikation und architektonische Kompatibilität mit zukünftiger Durchsetzung. Die vollständige Implementierung auf der Infrastrukturebene ist in der Inkubationsphase erstrebenswert. Die heute geschriebene Governance-Spezifikation wird morgen zum kodierten Schema. Die Kriterien sind darauf ausgelegt, die institutionelle Kapazität schrittweise aufzubauen und die Institutionen dort abzuholen, wo sie sich derzeit befinden, anstatt Fähigkeiten zu verlangen, die noch entwickelt werden müssen.

Eine in den Diskussionen der C-DART 1-Sitzungen geäußerte Kritik ist es wert, direkt anerkannt zu werden: Die Governance im Gesundheitswesen in katholischen Institutionen ist in erster Linie ein rechtliches und regulatorisches Problem und kein Ingenieurproblem. HIPAA, FDA, CMS und staatliches Recht setzen die Mindestanforderungen. Diese Kritik ist zutreffend, und dieses Framework akzeptiert sie. Governance-as-Code fungiert als die technische Schicht, die die Einhaltung dieser Rahmenbedingungen prüfbar, reproduzierbar und interoperabel über katholische institutionelle Grenzen hinweg macht. Der Unterschied zwischen der Ersetzung von Regulierung und der technischen Durchsetzbarkeit von Compliance ist der Unterschied, der diesen Ansatz glaubwürdig und nicht übergriffig macht.

Was katholische Institutionen jetzt tun können

Angesichts der ehrlichen Bewertung der aktuellen institutionellen Bereitschaft ist der kurzfristige Beitrag dieser Forschung ein schriftlicher Bewertungsstandard, der als Vorläufer einer Produktions-CI/CD-Governance-Pipeline dient und nicht als die Pipeline selbst.

Die CDCF-Vetting-Kriterien stellen diesen Bewertungsstandard dar. Kriterium 6 fordert die Einreicher auf, Entscheidungsmachtstufen, Eskalationsbedingungen, menschliche Überprüfungsanlässe und Beschwerdeprozesse in einem schriftlichen, überprüfbaren Dokument zu spezifizieren. Diese Spezifikation ist der erste Schritt zu einem maschinenexecutable Schema. Eine Institution, die eine rigorose Governance-Spezifikation für ein Projekt verfasst hat, hat den Großteil der intellektuellen Arbeit geleistet, die erforderlich ist, um diese Spezifikation als wiederverwendbares Governance-Schema zu kodieren.

Die CDCF ist in der Lage, die Bibliothek der kanonischen Schemata zu pflegen, die einzelne Institutionen erweitern, anstatt sie unabhängig zu erstellen. Das ist die Solidarschicht, die im Fragmentierungsmemo beschrieben wird: eine gemeinsame Basislinie, die die lokale Autorität bewahrt und gleichzeitig die katholische Technologie-Governance in großem Maßstab interoperabel macht.

Drei konkrete Maßnahmen ergeben sich aus dieser Forschung für katholische Institutionen auf jedem Niveau technischer Reife.

  1. Schriftliche Governance-Spezifikationen verlangen für jedes Technologieprojekt, das evaluiert wird. Das Spezifikationsformat in Kriterium 6 der CDCF-Vorprüfungsrichtlinien bietet eine Ausgangsvorlage.
  2. Versionierung dieser Spezifikationen. Selbst ein Word-Dokument in einem gemeinsamen Laufwerk mit einer Versionsnummer und einem benannten Eigentümer ist ein bedeutender Schritt in Richtung Governance-as-Code-Disziplin.
  3. Technologieprojekte auf Schema-Kompatibilität bewerten: Unterstützt die Architektur des Projekts die Integration von Governance-Gates und die Validierung von Standards, oder erfordert sie das Übersteuern von Governance-Kontrollen, um zu funktionieren?

Beziehung zur CDCF

Governance-as-Code dient als Durchsetzungsarchitektur für beide Säulen der Mission der CDCF.

Projektprüfung. Kriterium 6 der CDCF-Projektprüfungsrichtlinien ist der direkte operationale Ausdruck dieser Forschung. Es erfordert eine Spezifikation zur Bereitstellungsgovernance als Bedingung für die Annahme in die Inkubation, mit dem vierstufigen Entscheidungsmodell (go, conditional-go, no-go, defer) als strukturellen Rahmen für diese Spezifikation. Kriterium 8 erweitert das Prinzip auf die Bereitstellungsarchitektur der Projekte selbst und verlangt, dass Projekte auf der angemessenen Ebene der kirchlichen Autorität bereitgestellt werden können, ohne ihr Kerngovernance-Design zu übersteuern. Zusammen legen die Kriterien 6 und 8 die Anforderungen an die Governance-Spezifikationen fest, die katholische Institutionen in die Lage versetzen, eine umfassendere Implementierung von Governance-as-Code zu übernehmen, während sich die institutionelle Kapazität entwickelt.

Standardskonformität. Das CDCF-Standardsprogramm definiert die kanonischen Identifikatoren und Datenrepräsentationen, die katholische Softwareprojekte übernehmen sollten. Governance-as-Code bietet den Durchsetzungsmechanismus: Standards, die als maschinenlesbare Schemata ausgedrückt werden, können automatisch validiert werden, wodurch die Konformität von der Selbstattestation zur architektonischen Verifizierung verschoben wird.

Bibliographie

  1. Joe Kwon und Stephen Casper, „Interne Bereitstellungslücken in der KI-Regulierung“, arXiv:2601.08005, eingereicht am 12. Januar 2026, überarbeitet am 14. Februar 2026, https://arxiv.org/abs/2601.08005.↩︎

  2. Kommission der Bischofskonferenzen der Europäischen Union (COMECE), „Erklärung zum EU-Gesetz über Künstliche Intelligenz“, COMECE, 2024, https://church.mt/comece-on-the-artificial-intelligence-act-it-does-justice-to-the-ethical-foundations-of-the-eu/.↩︎

  3. Dicasterium für die Glaubenslehre und Dicasterium für Kultur und Bildung, Antiqua et Nova: Hinweis auf die Beziehung zwischen Künstlicher Intelligenz und menschlicher Intelligenz (Vatikanstadt: Dicasterium für die Glaubenslehre, 28. Januar 2025), https://www.vatican.va/roman_curia/congregations/cfaith/documents/rc_ddf_doc_20250128_antiqua-et-nova_en.html.↩︎

  4. Vereinigte Staaten Konferenz der katholischen Bischöfe, Gemeinsame Erklärung zu den Prinzipien und Prioritäten der Künstlichen Intelligenz, 9. Juni 2025, https://www.usccb.org/resources/joint-letter-artificial-intelligence-principles-and-priorities.↩︎

  5. Papst Franziskus, „Ansprache bei der Unterzeichnung des Rom-Aufrufs zur KI-Ethischen“, Vatikanstadt, 28. Februar 2020, https://www.vatican.va/content/francesco/en/speeches/2020/february/documents/papa-francesco_20200228_eticaartificiale.html.↩︎

  6. Codex Iuris Canonici, Canon 1609 (Vatikanstadt: Libreria Editrice Vaticana, 1983), https://www.vatican.va/archive/cod-iuris-canonici/eng/documents/cic_lib7-cann1501-1670_en.html.↩︎

  7. Vereinigte Staaten Konferenz der katholischen Bischöfe, Gemeinsame Erklärung zu den Prinzipien und Prioritäten der Künstlichen Intelligenz, 9. Juni 2025, https://www.usccb.org/resources/joint-letter-artificial-intelligence-principles-and-priorities.↩︎

  8. Rick Hamilton, „Daten-Governance für KI muss ausführbar sein“, hamiltonandboss.com (Substack), 2025, https://substack.com/@rickwritesai/p-189861656.↩︎

  9. Mert Cemri, Melissa Z. Pan, Yapei Yang, Aditya Agrawal, Tatsunori Hashimoto, Diyi Yang, Qian Yang und Percy Liang, „Warum scheitern Multi-Agenten-LLM-Systeme?“ arXiv:2503.13657, eingereicht am 17. März 2025, https://arxiv.org/abs/2503.13657.↩︎

  10. Melissa Z. Pan, Mert Cemri, Lingjiao Chen, Matei Zaharia, James Zou und Percy Liang, „Messung von Agenten in der Produktion,“ arXiv:2512.04123, eingereicht am 2. Dezember 2025, überarbeitet am 3. Februar 2026, https://arxiv.org/abs/2512.04123.↩︎

  11. Europäisches Parlament und Rat der Europäischen Union, Verordnung (EU) 2024/1689 des Europäischen Parlaments und des Rates über harmonisierte Vorschriften für Künstliche Intelligenz (Gesetz über Künstliche Intelligenz), Amtsblatt der Europäischen Union, 12. August 2024, https://artificialintelligenceact.eu.↩︎