CDCF — Catholic Digital Commons Foundation

Governance-as-Code per il Deployment Tecnologico Cattolico

Tipo di documento Memo di ricerca
Stato Bozza di lavoro — Discussione C-DART 1 U.S.A.
Relazione Ricerca supplementare alla base dei Criteri di Valutazione dei Progetti CDCF v0.2

Indice

  1. L’Argomento Centrale
  2. Cos’è il Governance-as-Code
  3. Perché le Istituzioni Cattoliche Ne Hanno Bisogno
  4. Lo Stack a Tre Livelli
  5. La Decisione di Accesso come Artefatto Primario
  6. Applicazione al Deployment dell’IA
  7. Applicazione alla Conformità agli Standard
  8. Valutazione Onesta della Prontezza Istituzionale
  9. Cosa Possono Fare Ora le Istituzioni Cattoliche
  10. Relazione con il CDCF
  11. Bibliografia

L’Argomento Centrale

La governance tecnologica nelle istituzioni cattoliche attualmente vive in PDF e riunioni di comitato. Quando una diocesi, una scuola o un ospedale cattolico implementa un sistema tecnologico — sia esso uno strumento di IA, una piattaforma di gestione parrocchiale, un’integrazione per la condivisione dei dati o un progetto software liturgico — il processo di governance produce tipicamente un documento che attesta che il sistema è approvato. Quel documento esiste separatamente dal sistema che governa. Non può prevenire un’implementazione non conforme. Non può essere validato automaticamente. Può solo reagire dopo che qualcosa è andato storto.

Il governance-as-code è la pratica di trasformare quei documenti politici in specifiche eseguibili da macchina collegate direttamente alle pipeline di deployment. La governance diventa parte dell’infrastruttura. Questo cambiamento è già in corso in ambienti aziendali regolamentati. La domanda per le istituzioni cattoliche è se partecipano a plasmare ciò che quelle specifiche codificano, o se ereditano schemi di governance secolari progettati senza riferimento alla teologia morale cattolica, all’autorità canonica o alla preoccupazione preferenziale della Chiesa per i vulnerabili.

Il principio si applica su due dimensioni della missione del CDCF. Per i deployment tecnologici, il governance-as-code applica i criteri di valutazione come porte rigide prima che qualsiasi progetto raggiunga la produzione. Per la conformità agli standard, il governance-as-code verifica che i progetti siano conformi agli standard di dati del CDCF — gli identificatori e le rappresentazioni condivise per le celebrazioni liturgiche, i documenti magisteriali, le edizioni scritturali e le strutture canoniche — in modo automatico e continuo.

Cos’è il Governance-as-Code

In un’architettura governance-as-code, i requisiti politici sono espressi come schemi controllati da versione (tipicamente JSON o YAML) che definiscono esattamente cosa deve dimostrare un sistema tecnologico prima di poter raggiungere la produzione. Quando uno sviluppatore tenta di implementare un progetto, la pipeline di deployment richiama quegli schemi come porte rigide.

La logica delle porte è deterministica. Supera tutte le porte e il progetto viene implementato. Fallisce qualsiasi porta e non viene implementato. Ogni decisione, passare o fallire, è registrata in una traccia di audit immutabile che i regolatori, le autorità diocesane o la leadership istituzionale possono esaminare successivamente.

Gli schemi stessi definiscono i criteri di governance: quali prove di test sono richieste, quali domini di dati il sistema è autorizzato a toccare, quale livello di supervisione umana opera, chi è la persona responsabile nominata, quali condizioni richiedono un’escalation a un’autorità superiore e — per i progetti in domini coperti dagli standard CDCF — se le rappresentazioni dei dati del progetto sono conformi agli schemi canonici. Queste sono le stesse domande che pongono i Criteri di Valutazione del CDCF. Il governance-as-code è l’architettura tecnica che trasforma quelle domande in porte applicabili piuttosto che in elenchi di controllo consultivi.

Questo è distinto dall’uso dell’IA per governare la tecnologia. La decisione di gate in un’architettura governance-as-code è deterministica: uno schema o passa o non passa, in base a criteri espliciti definiti in anticipo da autorità umane. L’IA può assistere nella sintesi delle prove e nell’emergere dei rischi all’interno della pipeline, ma la logica del gate rimane sotto il controllo definito dall’uomo e applicato dalla macchina.

Una preoccupazione strutturale in tutta la governance tecnologica è il divario di conformità tra l’intento normativo e la pratica di implementazione. Gli attuali quadri di governance presentano tre gap ricorrenti: ambiguità di ambito nella definizione dei sistemi coperti, requisiti di conformità a un determinato momento che non affrontano i sistemi che evolvono dopo l’approvazione iniziale e asimmetrie informative tra i regolatori e le istituzioni che implementano.1 La governance-as-code affronta direttamente tutti e tre: le definizioni degli schemi stabiliscono l’ambito con precisione, gli schemi controllati per versione evolvono con il sistema che governano e le tracce di audit immutabili chiudono il divario informativo.

La Commissione delle Conferenze Episcopali dell’Unione Europea (COMECE) afferma che valutare la tecnologia da una prospettiva etica “richiede principi di controllo interno e valutazione del rischio oltre alla legislazione.”2 La governance-as-code è l’istanza diretta di quei principi di controllo interno obbligatori, traducendo la valutazione etica da un’attività di revisione periodica in un requisito infrastrutturale continuo e applicabile.

Perché le Istituzioni Cattoliche Ne Hanno Bisogno

Il problema della frammentazione documentato nella nota di accompagnamento su governance digitale cattolica su larga scala è fondamentalmente un problema di codifica della governance — sia per quanto riguarda l’implementazione della tecnologia che l’infrastruttura digitale.

Implementazione della tecnologia. Ogni diocesi esprime i propri valori di governance tecnologica cattolica in un formato diverso, a un diverso livello di specificità, per diversi pubblici. Orange ha scritto una carta del consiglio. Biloxi ha scritto un decreto. Arlington ha scritto una politica scolastica. Nessuno di questi strumenti è leggibile dalla macchina. Nessuno di essi può essere validato automaticamente. Un fornitore può riconoscere tutti e tre i documenti e implementare comunque un sistema non conforme, perché i documenti non hanno un meccanismo di applicazione tecnica.

Conformità agli standard. Lo stesso problema si applica agli standard digitali. Anche quando esistono identificatori canonici condivisi per celebrazioni liturgiche, documenti magisteriali o edizioni della Scrittura, un progetto può dichiarare di essere conforme senza essere verificato. Senza schemi applicabili dalla macchina che definiscano come appare la conformità a uno standard CDCF, l’adozione degli standard dipende dalla disciplina volontaria piuttosto che dall’applicazione architettonica.

La governance-as-code cambia entrambe le relazioni strutturali. Uno schema di governance canonico condiviso — un insieme di politiche eseguibili dalla macchina che codificano i principi di Antiqua et Nova,3 i principi della USCCB,4 le Direttive Etiche e Religiose e gli standard di dati CDCF in specifiche riutilizzabili controllate per versione — consentirebbe a qualsiasi diocesi di adottare la base condivisa e ampliarla con requisiti locali. La sussidiarietà è preservata perché l’autorità locale governa ancora le decisioni locali. La solidarietà è raggiunta perché ogni istituzione che opera sulla base condivisa è interoperabile.

Un fornitore che serve le scuole cattoliche si troverebbe di fronte a uno schema canonico con estensioni diocesane opzionali piuttosto che a dozzine di checklist incompatibili. Un sistema ospedaliero cattolico che opera oltre i confini diocesani potrebbe implementare uniformemente perché l’infrastruttura di governance è compatibile tra le giurisdizioni. Un progetto di software liturgico potrebbe verificare la propria conformità agli identificatori del calendario CDCF come parte di ogni build. La governance diventa portatile quanto gli strumenti che governa.

Il Rome Call for AI Ethics richiede che principi e valori siano inseriti in un quadro che “funziona come punto di riferimento per l’etica digitale, guidando le nostre azioni e promuovendo l’uso della tecnologia a beneficio dell’umanità.”5 Il livello della piattaforma di governance di questa architettura risponde direttamente a tale richiesta, creando un punto di riferimento condiviso e tangibile per l’etica digitale che è applicabile oltre i confini istituzionali cattolici piuttosto che aspirazionale.

Il Stack a Tre Livelli

Un’architettura matura di governance-as-code per il deployment tecnologico cattolico opera su tre livelli, ciascuno dei quali svolge una funzione istituzionale distinta.

Livello Funzione Utenti Primari Ruolo del CDCF
Infrastruttura Hook della pipeline CI/CD, controllori di ammissione Kubernetes, logica di gate di deployment, controlli di validazione degli standard. Dove gli schemi vengono eseguiti come gate rigidi e vengono generati audit trail. Sviluppatori e team DevOps Contribuisce alle specifiche degli schemi
Piattaforma di Governance Biblioteca di schemi: specifiche politiche controllate in versione, logica di classificazione del rischio, baseline di governance cattolica canonica, schemi di conformità agli standard CDCF. Dove la teologia morale cattolica e i requisiti canonici sono codificati come criteri leggibili dalla macchina. Uffici IT diocesani e responsabili della governance Amministra la baseline canonica condivisa
Applicazione Strumenti rivolti alle istituzioni: flussi di lavoro di onboarding, dashboard di rischio, rapporti di conformità agli standard, artefatti di audit per la leadership diocesana e i regolatori esterni. Amministratori parrocchiali e scolastici Fornisce modelli e strumenti

Questi tre livelli corrispondono direttamente ai tre livelli di capacità istituzionale che le organizzazioni cattoliche hanno effettivamente. Una piccola parrocchia o scuola opera principalmente a livello di applicazione, utilizzando strumenti di governance senza bisogno di comprendere l’infrastruttura sottostante. Un ufficio IT diocesano opera a livello di piattaforma di governance, adottando ed estendendo schemi canonici per il contesto locale. Un grande sistema sanitario cattolico o un’università opera a livello di infrastruttura, integrando gate di governance nelle proprie pipeline CI/CD.

La Decisione del Gate come Artefatto Primario

Il principio di design più significativo in questo framework è che la decisione del gate stessa, il via, il via condizionato, il no-go o la determinazione di rinvio, è trattata come un artefatto di prima classe piuttosto che come un sottoprodotto del processo di revisione.

Un artefatto di decisione del gate cattura le prove specifiche assemblate, i livelli di fiducia assegnati, le lacune identificate, il proprietario della decisione umana nominato, la motivazione per il risultato e le condizioni sotto le quali è stata presa la decisione. È immutabile una volta registrato. È il documento che risponde alla domanda del regolatore, alla domanda del vescovo e alla domanda della persona interessata: perché è stato implementato questo sistema, sotto quale autorità e su quale base.

Questo design riflette direttamente lo standard canonico stabilito nel Canone 1609, che richiede che i processi deliberativi producano conclusioni scritte con motivazioni in diritto e in fatto, e che la capacità di revisione e appello sia preservata.6 Un artefatto di decisione del gate è l’implementazione tecnica di quel requisito canonico.

L’immutabilità dell’audit trail serve anche a una preoccupazione istituzionale specificamente cattolica. La USCCB avverte che la tecnologia può essere abusata per “minare la dignità delle persone e il rispetto per la verità” attraverso la manipolazione delle informazioni.7 Un record di decisione del gate immutabile garantisce che se un sistema implementato si comporta in modo contrario alla sua specifica di governance, la responsabilità istituzionale sia chiara, tracciabile e preservata per la revisione. La conseguenza pratica di audit trail non governati è documentata nei deployment aziendali: quando un sistema di produzione recupera un documento di politica superato senza provenienza catturata, l’organizzazione non può ricostruire cosa ha visto il sistema o perché, trasformando la risposta agli incidenti in un lavoro forense piuttosto che in una responsabilità basata su prove.8

Gli stati decisionali portano implicazioni distinte.

Stato della Decisione Significato Requisito di Documentazione
Procedere Tutti i criteri di governance soddisfatti; distribuzione autorizzata Evidenza completa dei criteri registrata
Procedere con Condizioni Distribuzione autorizzata a condizione di specifiche condizioni entro un termine definito Condizioni e tempistiche specificate; tipicamente utilizzato quando la validazione indipendente è in attesa
Non Procedere Uno o più criteri non soddisfatti; distribuzione bloccata Criteri specifici e lacune di evidenza documentate
Rimandare Richiesta di escalation a un’autorità superiore prima di procedere Autorità identificata e motivo specificato

Applicazione al Deployment di AI

Il deployment di AI è il dominio in cui la governance come codice è più urgente e tecnicamente matura.

I ricercatori che studiano i fallimenti dei sistemi multi-agente hanno identificato 14 modalità di fallimento distinte in tre categorie (problemi di design del sistema, disallineamento tra agenti e rotture nella verifica dei compiti) sottolineando l’importanza strutturale della logica dei gate deterministica piuttosto che della revisione della conformità mediata dagli agenti.9 I dati di indagine empirica provenienti da 306 professionisti dell’AI in 26 domini confermano che l’affidabilità rimane la principale sfida del deployment, con il 68% degli agenti in produzione che eseguono dieci o meno passaggi prima che sia necessaria l’intervento umano.10 Questi risultati sostengono architetture di governance in cui i gate definiti dall’uomo e applicati dalla macchina sono il principale meccanismo di controllo piuttosto che il giudizio degli agenti.

La pressione normativa amplifica l’urgenza. Il Regolamento AI dell’UE, con obblighi chiave per i sistemi di AI ad alto rischio che entreranno in vigore nel 2026, crea una domanda strutturale per una governance del deployment auditabile nelle categorie di AI ad alto rischio.11 I servizi sanitari, educativi e sociali cattolici operano pienamente in queste categorie.

Quadro Normativo Giurisdizione Lacuna Chiave
California SB 53 U.S. (California) Ambiguità di ambito per i sistemi coperti
New York RAISE Act U.S. (New York) Conformità al punto nel tempo, nessun tracciamento post-approvazione
U.S. AIREA Federale Asimmetria informativa tra regolatori e distributori
Obblighi GPAI del Regolamento AI dell’UE Unione Europea Tutte e tre le lacune presenti su larga scala

Un’implementazione della governance come codice specifica per l’AI codifica le estensioni del dominio AI dai Criteri di Verifica del CDCF — divulgazione dei dati di addestramento, analisi delle prestazioni dei sottogruppi, condizioni di confine canoniche — come schemi applicabili dalla macchina all’interno della baseline canonica condivisa. Questo è distinto dall’uso dell’AI per governare l’AI: la logica dei gate rimane deterministica, e un pipeline governato dall’AI richiederebbe una governance propria, creando una regressione che l’applicazione di schemi deterministici evita.

Applicazione alla Conformità agli Standard

L’architettura della governance come codice si estende naturalmente alla conformità agli standard di dati del CDCF.

Quando il CDCF definisce identificatori canonici per celebrazioni liturgiche (CLEDR), documenti Magisteriali (CMDDR) o edizioni del Messale Romano (CRMETDR), quegli standard possono essere espressi come schemi di validazione leggibili dalla macchina. Un progetto software liturgico che afferma di conformarsi a CLEDR può avere tale affermazione verificata automaticamente nel suo pipeline di build. Una piattaforma catechetica che fa riferimento a documenti Magisteriali può convalidare i suoi identificatori rispetto allo schema CMDDR al momento del deployment.

Questo sposta la conformità agli standard da un’affermazione documentale (“seguiamo gli standard del CDCF”) a un fatto architettonico (“il nostro pipeline verifica gli standard del CDCF ad ogni build”). Il livello della piattaforma di governance mantiene gli schemi canonici, e il livello dell’infrastruttura li applica — la stessa architettura che governa l’etica del deployment governa anche l’interoperabilità dei dati.

Per le istituzioni cattoliche, questa integrazione è significativa. Un progetto che supera sia i criteri di valutazione che i criteri di conformità agli standard porta un livello di garanzia che nessun documento di policy può fornire da solo: è stato convalidato rispetto ai requisiti di governance cattolica e interopera con l’infrastruttura digitale condivisa della Chiesa, entrambi verificati da prove applicabili dalla macchina piuttosto che da auto-attestazione.

Valutazione Onesta della Prontezza Istituzionale

La piena implementazione tecnica della governance come codice a livello di infrastruttura va oltre la capacità attuale della maggior parte delle istituzioni cattoliche, e sovrastimare tale capacità produrrebbe il tipo di gap di credibilità nella governance che questo framework è progettato per prevenire. La maggior parte delle istituzioni cattoliche, comprese le diocesi e i sistemi sanitari ben finanziati, attualmente operano al massimo a livello applicativo. Hanno documenti di policy. Alcuni hanno comitati di revisione. Molto pochi hanno schemi di governance controllati da versioni. Nessuno, a conoscenza di questa ricerca, ha schemi di governance cattolica canonica incorporati come gate rigidi nei pipeline di deployment CI/CD.

Quel gap è l’opportunità, ed è il motivo per cui i Criteri di Valutazione del CDCF sono strutturati come sono. Il Criterio 6 richiede una specifica di governance scritta e revisionabile e compatibilità architettonica con future applicazioni. La piena implementazione a livello di infrastruttura è aspirazionale nella fase di incubazione. La specifica di governance scritta oggi diventa lo schema codificato domani. I criteri sono progettati per costruire progressivamente la capacità istituzionale, incontrando le istituzioni al loro attuale livello di maturità piuttosto che richiedere capacità ancora da sviluppare.

Una critica sollevata nelle discussioni della sessione C-DART 1 merita di essere riconosciuta direttamente: la governance sanitaria nelle istituzioni cattoliche è principalmente un problema legale e normativo piuttosto che un problema ingegneristico. HIPAA, FDA, CMS e la legge statale stabiliscono il minimo. Quella critica è accurata, e questo framework la accetta. La governance come codice opera come il livello tecnico che rende la conformità a quei framework auditabile, riproducibile e interoperabile oltre i confini istituzionali cattolici. La distinzione tra sostituire la regolamentazione e rendere la conformità tecnicamente applicabile è la distinzione che rende questo approccio credibile piuttosto che eccessivo.

Cosa Possono Fare Ora le Istituzioni Cattoliche

Data la valutazione onesta dell’attuale prontezza istituzionale, il contributo a breve termine di questa ricerca è uno standard di valutazione scritto che funge da precursore a un pipeline di governance CI/CD di produzione piuttosto che il pipeline stesso.

I Criteri di Valutazione del CDCF rappresentano quel standard di valutazione. Il Criterio 6 chiede ai presentatori di specificare i livelli di autorità decisionale, le condizioni di escalation, i trigger di revisione umana e i processi di appello in un documento scritto e revisionabile. Quella specifica è il primo passo verso uno schema eseguibile dalla macchina. Un’istituzione che ha scritto una rigorosa specifica di governance per un progetto ha svolto gran parte del lavoro intellettuale necessario per codificare quella specifica come uno schema di governance riutilizzabile.

Il CDCF è posizionato per mantenere la libreria di schemi canonici che le singole istituzioni estendono piuttosto che costruire in modo indipendente. Questo è il livello di solidarietà descritto nel memorandum sulla frammentazione: una base condivisa che preserva l’autorità locale mentre rende la governance tecnologica cattolica interoperabile su larga scala.

Tre azioni concrete seguono da questa ricerca per le istituzioni cattoliche a qualsiasi livello di maturità tecnica.

  1. Richiedere specifiche di governance scritte per ogni progetto tecnologico in fase di valutazione. Il formato delle specifiche nel Criterio 6 dei Criteri di Valutazione del CDCF fornisce un modello iniziale.
  2. Controllare le versioni di quelle specifiche. Anche un documento Word in un’unità condivisa con un numero di versione e un proprietario nominato è un passo significativo verso la disciplina della governance come codice.
  3. Valutare i progetti tecnologici per la compatibilità degli schemi: l’architettura del progetto supporta l’integrazione dei gate di governance e la validazione degli standard, o richiede di sovrascrivere i controlli di governance per funzionare?

Relazione con il CDCF

La governance come codice funge da architettura di enforcement per entrambi i pilastri della missione del CDCF.

Valutazione dei progetti. Il Criterio 6 dei Criteri di Valutazione dei Progetti del CDCF è l’espressione operativa diretta di questa ricerca. Richiede una specifica di governance per il deployment come condizione di accettazione dell’incubazione, con il modello decisionale a quattro stati (go, conditional-go, no-go, defer) come struttura per quella specifica. Il Criterio 8 estende il principio all’architettura di deployment dei progetti stessi, richiedendo che i progetti siano deployabili al livello appropriato di autorità ecclesiale senza sovrascrivere il loro design di governance fondamentale. Insieme, i Criteri 6 e 8 stabiliscono i requisiti di specifica di governance che posizionano le istituzioni cattoliche per adottare un’implementazione più completa della governance come codice man mano che si sviluppa la capacità istituzionale.

Conformità agli standard. Il programma di Standard del CDCF definisce gli identificatori canonici e le rappresentazioni dei dati che i progetti software cattolici dovrebbero adottare. La governance come codice fornisce il meccanismo di enforcement: gli standard espressi come schemi leggibili dalle macchine possono essere convalidati automaticamente, spostando la conformità dall’auto-attestazione alla verifica architettonica.

Bibliografia

  1. Joe Kwon e Stephen Casper, “Gaps di Deployment Interni nella Regolamentazione dell’IA,” arXiv:2601.08005, inviato il 12 gennaio 2026, rivisto il 14 febbraio 2026, https://arxiv.org/abs/2601.08005.↩︎

  2. Commissione delle Conferenze Episcopali dell’Unione Europea (COMECE), “Dichiarazione sulla Legge dell’Intelligenza Artificiale dell’UE,” COMECE, 2024, https://church.mt/comece-on-the-artificial-intelligence-act-it-does-justice-to-the-ethical-foundations-of-the-eu/.↩︎

  3. Dicastero per la Dottrina della Fede e Dicastero per la Cultura e l’Istruzione, Antiqua et Nova: Nota sul Rapporto tra Intelligenza Artificiale e Intelligenza Umana (Città del Vaticano: Dicastero per la Dottrina della Fede, 28 gennaio 2025), https://www.vatican.va/roman_curia/congregations/cfaith/documents/rc_ddf_doc_20250128_antiqua-et-nova_en.html.↩︎

  4. Conferenza degli Stati Uniti dei Vescovi Cattolici, Lettera Congiunta sui Principi e le Priorità dell’Intelligenza Artificiale, 9 giugno 2025, https://www.usccb.org/resources/joint-letter-artificial-intelligence-principles-and-priorities.↩︎

  5. Papa Francesco, “Discorso alla Firma della Chiamata di Roma per l’Etica dell’IA,” Città del Vaticano, 28 febbraio 2020, https://www.vatican.va/content/francesco/en/speeches/2020/february/documents/papa-francesco_20200228_eticaartificiale.html.↩︎

  6. Codice di Diritto Canonico, Canone 1609 (Città del Vaticano: Libreria Editrice Vaticana, 1983), https://www.vatican.va/archive/cod-iuris-canonici/eng/documents/cic_lib7-cann1501-1670_en.html.↩︎

  7. Conferenza degli Stati Uniti dei Vescovi Cattolici, Lettera Congiunta sui Principi e le Priorità dell’Intelligenza Artificiale, 9 giugno 2025, https://www.usccb.org/resources/joint-letter-artificial-intelligence-principles-and-priorities.↩︎

  8. Rick Hamilton, “La Governance dei Dati per l’IA Deve Essere Eseguibile,” 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 e Percy Liang, “Perché i sistemi LLM multi-agente falliscono?” arXiv:2503.13657, inviato il 17 marzo 2025, https://arxiv.org/abs/2503.13657.↩︎

  10. Melissa Z. Pan, Mert Cemri, Lingjiao Chen, Matei Zaharia, James Zou e Percy Liang, “Misurare gli agenti in produzione,” arXiv:2512.04123, inviato il 2 dicembre 2025, rivisto il 3 febbraio 2026, https://arxiv.org/abs/2512.04123.↩︎

  11. Parlamento Europeo e Consiglio dell’Unione Europea, Regolamento (UE) 2024/1689 del Parlamento Europeo e del Consiglio che stabilisce norme armonizzate sull’intelligenza artificiale (Legge sull’intelligenza artificiale), Gazzetta Ufficiale dell’Unione Europea, 12 agosto 2024, https://artificialintelligenceact.eu.↩︎