CDCF — Catholic Digital Commons Foundation

Gobernanza como Código para el Despliegue de Tecnología Católica

Tipo de documento Memo de investigación
Estado Borrador en trabajo — Discusión C-DART 1 de EE. UU.
Relación Investigación suplementaria que subyace a los Criterios de Evaluación de Proyectos del CDCF v0.2

Tabla de Contenidos

  1. El Argumento Central
  2. Qué es la Gobernanza como Código
  3. Por Qué las Instituciones Católicas lo Necesitan
  4. La Pila de Tres Capas
  5. La Decisión de Puerta como Artefacto Primario
  6. Aplicación al Despliegue de IA
  7. Aplicación a la Conformidad con Normas
  8. Evaluación Honesta de la Preparación Institucional
  9. Qué Pueden Hacer Ahora las Instituciones Católicas
  10. Relación con el CDCF
  11. Bibliografía

El Argumento Central

La gobernanza tecnológica en las instituciones católicas actualmente vive en PDFs y reuniones de comités. Cuando una diócesis, escuela u hospital católico despliega un sistema tecnológico —ya sea una herramienta de IA, una plataforma de gestión parroquial, una integración de intercambio de datos o un proyecto de software litúrgico— el proceso de gobernanza típicamente produce un documento que dice que el sistema está aprobado. Ese documento existe por separado del sistema que gobierna. No puede prevenir un despliegue no conforme. No puede ser validado automáticamente. Solo puede reaccionar después de que algo salga mal.

La gobernanza como código es la práctica de convertir esos documentos de política en especificaciones ejecutables por máquina conectadas directamente a las tuberías de despliegue. La gobernanza se convierte en parte de la infraestructura. Este cambio ya está ocurriendo en entornos empresariales regulados. La pregunta para las instituciones católicas es si participan en dar forma a lo que esas especificaciones codifican, o si heredan esquemas de gobernanza seculares diseñados sin referencia a la teología moral católica, la autoridad canónica o la preocupación preferencial de la Iglesia por los vulnerables.

El principio se aplica en dos dimensiones de la misión del CDCF. Para despliegues tecnológicos, la gobernanza como código aplica los criterios de evaluación como puertas estrictas antes de que cualquier proyecto llegue a producción. Para conformidad con normas, la gobernanza como código verifica que los proyectos se ajusten a los estándares de datos del CDCF —los identificadores y representaciones compartidas para celebraciones litúrgicas, documentos magisteriales, ediciones de las Escrituras y estructuras canónicas— de manera automática y continua.

Qué es la Gobernanza como Código

En una arquitectura de gobernanza como código, los requisitos de política se expresan como esquemas controlados por versiones (típicamente JSON o YAML) que definen exactamente lo que un sistema tecnológico debe demostrar antes de que pueda llegar a producción. Cuando un desarrollador intenta desplegar un proyecto, la tubería de despliegue llama a esos esquemas como puertas estrictas.

La lógica de la puerta es determinista. Pasar todas las puertas y el proyecto se despliega. Fallar cualquier puerta y no se despliega. Cada decisión, pasar o fallar, se registra en un rastro de auditoría inmutable que los reguladores, las autoridades diocesanas o el liderazgo institucional pueden examinar después del hecho.

Los esquemas en sí definen los criterios de gobernanza: qué evidencia de pruebas se requiere, qué dominios de datos el sistema está permitido tocar, qué nivel de supervisión humana opera, quién es la persona responsable nombrada, qué condiciones requieren escalación a una autoridad superior, y —para proyectos en dominios cubiertos por los estándares del CDCF— si las representaciones de datos del proyecto se ajustan a los esquemas canónicos. Estas son las mismas preguntas que los Criterios de Evaluación del CDCF plantean. La gobernanza como código es la arquitectura técnica que convierte esas preguntas en puertas exigibles en lugar de listas de verificación consultivas.

Esto es distinto de utilizar la IA para gobernar la tecnología. La decisión de la puerta en una arquitectura de gobernanza como código es determinista: un esquema o pasa o no pasa, basado en criterios explícitos definidos de antemano por autoridades humanas. La IA puede ayudar con la síntesis de evidencia y la identificación de riesgos dentro del proceso, pero la lógica de la puerta en sí misma permanece bajo control definido por humanos y aplicado por máquinas.

Una preocupación estructural en toda la gobernanza tecnológica es la brecha de cumplimiento entre la intención regulatoria y la práctica de implementación. Los marcos de gobernanza actuales comparten tres brechas recurrentes: ambigüedad en el alcance al definir los sistemas cubiertos, requisitos de cumplimiento en un momento dado que no abordan sistemas que evolucionan después de la aprobación inicial, y asimetrías de información entre reguladores e instituciones que implementan.1 La gobernanza como código aborda directamente las tres: las definiciones de esquema establecen el alcance con precisión, los esquemas controlados por versiones evolucionan con el sistema que gobiernan, y las auditorías inmutables cierran la brecha de información.

La Comisión de las Conferencias Episcopales de la Unión Europea (COMECE) afirma que evaluar la tecnología desde una perspectiva ética “requiere principios de control interno y evaluación de riesgos además de la legislación.”2 La gobernanza como código es la instanciación directa de esos principios de control interno mandados, traduciendo la evaluación ética de una actividad de revisión periódica a un requisito de infraestructura continuo y aplicable.

Por qué las Instituciones Católicas lo Necesitan

El problema de fragmentación documentado en el memorando complementario sobre gobernanza digital católica a gran escala es fundamentalmente un problema de codificación de gobernanza — tanto en la implementación de tecnología como en la infraestructura digital.

Implementación de tecnología. Cada diócesis está expresando sus valores de gobernanza tecnológica católica en un formato diferente, a un nivel diferente de especificidad, para diferentes audiencias. Orange escribió una carta del consejo. Biloxi escribió un decreto. Arlington escribió una política escolar. Ninguno de esos instrumentos es legible por máquina. Ninguno de ellos puede ser validado automáticamente. Un proveedor puede reconocer los tres documentos y desplegar un sistema no conforme de todos modos, porque los documentos no tienen un mecanismo de aplicación técnica.

Cumplimiento de estándares. El mismo problema se aplica a los estándares digitales. Incluso cuando existen identificadores canónicos compartidos para celebraciones litúrgicas, documentos Magisteriales o ediciones de las Escrituras, un proyecto puede reclamar cumplimiento sin ser verificado. Sin esquemas aplicables por máquina que definan cómo es la conformidad con un estándar de CDCF, la adopción de estándares depende de la disciplina voluntaria en lugar de la aplicación arquitectónica.

La gobernanza como código cambia ambas relaciones estructurales. Un esquema de gobernanza canónica compartida — un conjunto base de políticas ejecutables por máquina que codifican los principios de Antiqua et Nova,3 los principios de la USCCB,4 las Directrices Éticas y Religiosas, y los estándares de datos de CDCF en especificaciones reutilizables controladas por versiones — permitiría a cualquier diócesis adoptar la base compartida y extenderla con requisitos locales. La subsidiariedad se preserva porque la autoridad local aún gobierna las decisiones locales. La solidaridad se logra porque cada institución que opera en la base compartida es interoperable.

Un proveedor que sirva a escuelas católicas se enfrentaría a un esquema canónico con extensiones diocesanas opcionales en lugar de docenas de listas de verificación incompatibles. Un sistema hospitalario católico que opere a través de líneas diocesanas podría desplegarse uniformemente porque la infraestructura de gobernanza es compatible entre jurisdicciones. Un proyecto de software litúrgico podría verificar su conformidad con los identificadores de calendario de CDCF como parte de cada compilación. La gobernanza se vuelve tan portátil como las herramientas que gobierna.

La Convocatoria de Roma para la Ética de la IA exige que los principios y valores se inculquen en un marco que “actúe como un punto de referencia para la ética digital, guiando nuestras acciones y promoviendo el uso de la tecnología en beneficio de la humanidad.”5 La capa de plataforma de gobernanza de esta arquitectura responde directamente a ese llamado, creando un punto de referencia compartido y tangible para la ética digital que es aplicable a través de las fronteras institucionales católicas en lugar de ser aspiracional.

La Pilas de Tres Capas

Una arquitectura madura de gobernanza como código para el despliegue de tecnología católica opera en tres capas, cada una sirviendo a una función institucional distinta.

Capa Función Usuarios Primarios Rol de CDCF
Infraestructura Ganchos de pipeline CI/CD, controladores de admisión de Kubernetes, lógica de puerta de despliegue, verificaciones de validación de estándares. Donde los esquemas se ejecutan como puertas estrictas y se generan auditorías. Desarrolladores y equipos de DevOps Contribuye a las especificaciones de esquemas
Plataforma de Gobernanza Biblioteca de esquemas: especificaciones de políticas controladas por versiones, lógica de clasificación de riesgos, línea base de gobernanza católica canónica, esquemas de conformidad a los estándares de CDCF. Donde la teología moral católica y los requisitos canónicos están codificados como criterios legibles por máquina. Oficinas de TI diocesanas y líderes de gobernanza Administra la línea base canónica compartida
Aplicación Herramientas orientadas a la institución: flujos de trabajo de incorporación, paneles de riesgos, informes de cumplimiento de estándares, artefactos de auditoría para el liderazgo diocesano y reguladores externos. Administradores de parroquias y escuelas Proporciona plantillas y herramientas

Estas tres capas corresponden directamente a los tres niveles de capacidad institucional que las organizaciones católicas realmente tienen. Una pequeña parroquia o escuela opera principalmente en la capa de aplicación, utilizando herramientas de gobernanza sin necesidad de entender la infraestructura subyacente. Una oficina de TI diocesana opera en la capa de plataforma de gobernanza, adoptando y extendiendo esquemas canónicos para el contexto local. Un gran sistema de salud católico o universidad opera en la capa de infraestructura, integrando puertas de gobernanza en sus propios pipelines CI/CD.

La Decisión de Puerta como Artefacto Primario

El principio de diseño más significativo en este marco es que la decisión de puerta en sí, la decisión de proceder, proceder condicionalmente, no proceder, o diferir, se trata como un artefacto de primera clase en lugar de un subproducto del proceso de revisión.

Un artefacto de decisión de puerta captura la evidencia específica reunida, los niveles de confianza asignados, las brechas identificadas, el propietario humano de la decisión nombrado, la justificación del resultado y las condiciones bajo las cuales se tomó la decisión. Es inmutable una vez registrado. Es el documento que responde a la pregunta del regulador, la pregunta del obispo y la pregunta de la persona afectada: ¿por qué se desplegó este sistema, bajo cuya autoridad y sobre qué base?

Este diseño refleja directamente el estándar canónico establecido en el Canon 1609, que requiere que los procesos deliberativos produzcan conclusiones escritas con razones en derecho y en hecho, y que se preserve la capacidad de revisión y apelación.6 Un artefacto de decisión de puerta es la implementación técnica de ese requisito canónico.

La inmutabilidad de la auditoría también sirve a una preocupación institucional específicamente católica. La USCCB advierte que la tecnología puede ser mal utilizada para “socavar la dignidad de las personas y el respeto por la verdad” a través de la manipulación de la información.7 Un registro de decisión de puerta inmutable asegura que si un sistema desplegado se comporta de manera contraria a su especificación de gobernanza, la responsabilidad institucional sea clara, rastreable y preservada para revisión. La consecuencia práctica de las auditorías no gobernadas está documentada en los despliegues empresariales: cuando un sistema de producción recupera un documento de política sustituido sin un origen capturado, la organización no puede reconstruir lo que el sistema vio o por qué, convirtiendo la respuesta a incidentes en una conjetura forense en lugar de una responsabilidad basada en evidencia.8

Los cuatro estados de decisión tienen implicaciones distintas.

Estado de Decisión Significado Requisito de Documentación
Adelante Todos los criterios de gobernanza satisfechos; despliegue autorizado Evidencia completa de criterios registrada
Condicional-adelante Despliegue autorizado sujeto a condiciones específicas dentro de un plazo definido Condiciones y cronograma especificados; típicamente utilizado cuando se espera validación independiente
No-adelante Uno o más criterios no cumplidos; despliegue bloqueado Criterios específicos y brechas de evidencia documentadas
Deferir Se requiere escalamiento a una autoridad superior antes de proceder Autoridad identificada y razón especificada

Aplicación al Despliegue de IA

El despliegue de IA es el ámbito donde la gobernanza como código es más urgente y técnicamente madura.

Investigadores que estudian fallos en sistemas multi-agente han identificado 14 modos de fallo distintos en tres categorías (problemas de diseño del sistema, desalineación entre agentes y fallos en la verificación de tareas) subrayando la importancia estructural de la lógica de compuerta determinista en lugar de la revisión de cumplimiento mediada por agentes.9 Datos de encuestas empíricas de 306 profesionales de IA en 26 dominios confirman que la fiabilidad sigue siendo el principal desafío de despliegue, con un 68 por ciento de los agentes de producción ejecutando diez pasos o menos antes de que se requiera intervención humana.10 Estos hallazgos abogan por arquitecturas de gobernanza en las que las compuertas definidas por humanos y aplicadas por máquinas son el mecanismo de control principal en lugar del juicio de los agentes.

La presión regulatoria agrava la urgencia. La Ley de IA de la UE, con obligaciones clave para sistemas de IA de alto riesgo que entran en vigor en 2026, crea una demanda estructural de gobernanza de despliegue auditable en categorías de IA de alto riesgo.11 La atención médica católica, la educación y los servicios sociales operan directamente en esas categorías.

Marco Jurisdicción Brecha Clave
California SB 53 EE. UU. (California) Ambigüedad de alcance para los sistemas cubiertos
Ley RAISE de Nueva York EE. UU. (Nueva York) Cumplimiento puntual, sin seguimiento posterior a la aprobación
AIREA de EE. UU. Federal Asimetría de información entre reguladores y desplegadores
Obligaciones GPAI de la Ley de IA de la UE Unión Europea Las tres brechas presentes a gran escala

Una implementación de gobernanza como código específica de IA codifica las extensiones del dominio de IA de los Criterios de Evaluación de la CDCF — divulgación de datos de entrenamiento, análisis de rendimiento de subgrupos, condiciones de frontera canónicas — como esquemas aplicables por máquina dentro de la línea base canónica compartida. Esto es distinto de usar IA para gobernar IA: la lógica de compuerta sigue siendo determinista, y un pipeline gobernado por IA requeriría gobernanza propia, creando una regresión que la aplicación de esquemas deterministas evita.

Aplicación al Cumplimiento de Normas

La arquitectura de gobernanza como código se extiende naturalmente al cumplimiento de estándares de datos de la CDCF.

Cuando la CDCF define identificadores canónicos para celebraciones litúrgicas (CLEDR), documentos magisteriales (CMDDR) o ediciones del Misal Romano (CRMETDR), esos estándares pueden expresarse como esquemas de validación legibles por máquina. Un proyecto de software litúrgico que afirme conformidad con CLEDR puede tener esa afirmación verificada automáticamente en su canal de construcción. Una plataforma catequética que haga referencia a documentos magisteriales puede validar sus identificadores contra el esquema CMDDR en el momento de la implementación.

Esto traslada el cumplimiento de estándares de una afirmación documental (“seguimos los estándares de la CDCF”) a un hecho arquitectónico (“nuestro canal verifica los estándares de la CDCF en cada construcción”). La capa de plataforma de gobernanza mantiene los esquemas canónicos, y la capa de infraestructura los hace cumplir: la misma arquitectura que rige la ética de implementación también rige la interoperabilidad de datos.

Para las instituciones católicas, esta integración es significativa. Un proyecto que pasa tanto las puertas de criterios de evaluación como las puertas de conformidad con los estándares lleva un nivel de garantía que ningún documento de política por sí solo puede proporcionar: ha sido validado contra los requisitos de gobernanza católica y opera con la infraestructura digital compartida de la Iglesia, ambos verificados por evidencia que puede ser exigida por máquina en lugar de auto-certificación.

Evaluación Honesta de la Preparación Institucional

La implementación técnica completa de la gobernanza como código en la capa de infraestructura está más allá de la capacidad actual de la mayoría de las instituciones católicas, y exagerar esa capacidad produciría el tipo de brecha de credibilidad en la gobernanza que este marco está diseñado para prevenir. La mayoría de las instituciones católicas, incluidas las diócesis y sistemas de salud bien dotados, actualmente operan en la capa de aplicación, en el mejor de los casos. Tienen documentos de política. Algunas tienen comités de revisión. Muy pocas tienen esquemas de gobernanza controlados por versiones. Ninguna, hasta donde llega este estudio, tiene esquemas de gobernanza católica canónicos incrustados como puertas duras en los canales de implementación CI/CD.

Esa brecha es la oportunidad, y es la razón por la cual los Criterios de Evaluación de la CDCF están estructurados como lo están. El Criterio 6 requiere una especificación de gobernanza escrita y revisable y compatibilidad arquitectónica con la futura aplicación. La implementación completa en la capa de infraestructura es aspiracional en la etapa de incubación. La especificación de gobernanza escrita hoy se convierte en el esquema codificado mañana. Los criterios están diseñados para construir la capacidad institucional de manera progresiva, encontrando a las instituciones en su madurez actual en lugar de requerir capacidades que aún deben desarrollarse.

Una crítica planteada en las discusiones de la sesión C-DART 1 merece ser reconocida directamente: la gobernanza de la salud en las instituciones católicas es principalmente un problema legal y regulatorio en lugar de un problema de ingeniería. HIPAA, FDA, CMS y la ley estatal establecen el mínimo. Esa crítica es precisa, y este marco la acepta. La gobernanza como código opera como la capa técnica que hace que el cumplimiento de esos marcos sea auditable, reproducible e interoperable a través de las fronteras institucionales católicas. La distinción entre reemplazar la regulación y hacer que el cumplimiento sea técnicamente exigible es la distinción que hace que este enfoque sea creíble en lugar de excesivo.

Lo Que Pueden Hacer Ahora las Instituciones Católicas

Dada la evaluación honesta de la preparación institucional actual, la contribución a corto plazo de esta investigación es un estándar de evaluación escrito que funciona como el precursor de un canal de gobernanza CI/CD de producción en lugar del canal en sí.

Los Criterios de Evaluación de la CDCF representan ese estándar de evaluación. El Criterio 6 pide a los remitentes que especifiquen niveles de autoridad de decisión, condiciones de escalamiento, desencadenantes de revisión humana y procesos de apelación en un documento escrito y revisable. Esa especificación es el primer paso hacia un esquema ejecutable por máquina. Una institución que ha escrito una especificación de gobernanza rigurosa para un proyecto ha realizado la mayor parte del trabajo intelectual requerido para codificar esa especificación como un esquema de gobernanza reutilizable.

La CDCF está posicionada para mantener la biblioteca de esquemas canónicos que las instituciones individuales extienden en lugar de construir de forma independiente. Esa es la capa de solidaridad descrita en el memorando de fragmentación: una base compartida que preserva la autoridad local mientras hace que la gobernanza de la tecnología católica sea interoperable a gran escala.

Tres acciones concretas siguen de esta investigación para las instituciones católicas en cualquier nivel de madurez técnica.

  1. Requerir especificaciones de gobernanza por escrito para cada proyecto tecnológico en evaluación. El formato de especificación en el Criterio 6 de los Criterios de Evaluación de Proyectos de la CDCF proporciona una plantilla inicial.
  2. Controlar las versiones de esas especificaciones. Incluso un documento de Word en una unidad compartida con un número de versión y un propietario nombrado es un paso significativo hacia la disciplina de gobernanza como código.
  3. Evaluar proyectos tecnológicos por compatibilidad de esquema: ¿la arquitectura del proyecto soporta la integración de puertas de gobernanza y la validación de estándares, o requiere anular los controles de gobernanza para funcionar?

Relación con la CDCF

La gobernanza como código sirve como la arquitectura de aplicación para ambos pilares de la misión de la CDCF.

Evaluación de proyectos. El Criterio 6 de los Criterios de Evaluación de Proyectos de la CDCF es la expresión operativa directa de esta investigación. Requiere una especificación de gobernanza de implementación como condición para la aceptación de incubación, con el modelo de decisión de cuatro estados (ir, ir condicional, no ir, diferir) como el marco estructural para esa especificación. El Criterio 8 extiende el principio a la arquitectura de implementación de los propios proyectos, requiriendo que los proyectos sean implementables al nivel apropiado de autoridad eclesial sin anular su diseño de gobernanza central. Juntos, los Criterios 6 y 8 establecen los requisitos de especificación de gobernanza que posicionan a las instituciones católicas para adoptar una implementación más completa de gobernanza como código a medida que se desarrolla la capacidad institucional.

Cumplimiento de estándares. El programa de Estándares de la CDCF define los identificadores canónicos y las representaciones de datos que los proyectos de software católicos deben adoptar. La gobernanza como código proporciona el mecanismo de aplicación: los estándares expresados como esquemas legibles por máquina pueden ser validados automáticamente, trasladando el cumplimiento de la auto-certificación a la verificación arquitectónica.

Bibliografía

  1. Joe Kwon y Stephen Casper, “Gaps de Implementación Interna en la Regulación de IA,” arXiv:2601.08005, enviado el 12 de enero de 2026, revisado el 14 de febrero de 2026, https://arxiv.org/abs/2601.08005.↩︎

  2. Comisión de las Conferencias Episcopales de la Unión Europea (COMECE), “Declaración sobre la Ley de Inteligencia Artificial de la UE,” COMECE, 2024, https://church.mt/comece-on-the-artificial-intelligence-act-it-does-justice-to-the-ethical-foundations-of-the-eu/.↩︎

  3. Dicasterio para la Doctrina de la Fe y Dicasterio para la Cultura y la Educación, Antiqua et Nova: Nota sobre la Relación entre la Inteligencia Artificial y la Inteligencia Humana (Ciudad del Vaticano: Dicasterio para la Doctrina de la Fe, 28 de enero de 2025), https://www.vatican.va/roman_curia/congregations/cfaith/documents/rc_ddf_doc_20250128_antiqua-et-nova_en.html.↩︎

  4. Conferencia de Obispos Católicos de los Estados Unidos, Carta Conjunta sobre los Principios y Prioridades de la Inteligencia Artificial, 9 de junio de 2025, https://www.usccb.org/resources/joint-letter-artificial-intelligence-principles-and-priorities.↩︎

  5. Papa Francisco, “Discurso en la Firma de la Llamada de Roma por la Ética de la IA,” Ciudad del Vaticano, 28 de febrero de 2020, https://www.vatican.va/content/francesco/en/speeches/2020/february/documents/papa-francesco_20200228_eticaartificiale.html.↩︎

  6. Código de Derecho Canónico, Canon 1609 (Ciudad del Vaticano: Librería Editrice Vaticana, 1983), https://www.vatican.va/archive/cod-iuris-canonici/eng/documents/cic_lib7-cann1501-1670_en.html.↩︎

  7. Conferencia de Obispos Católicos de los Estados Unidos, Carta Conjunta sobre los Principios y Prioridades de la Inteligencia Artificial, 9 de junio de 2025, https://www.usccb.org/resources/joint-letter-artificial-intelligence-principles-and-priorities.↩︎

  8. Rick Hamilton, “La Gobernanza de Datos para la IA Debe Ser Ejecutable,” 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 y Percy Liang, “¿Por qué fallan los sistemas LLM de múltiples agentes?” arXiv:2503.13657, enviado el 17 de marzo de 2025, https://arxiv.org/abs/2503.13657.↩︎

  10. Melissa Z. Pan, Mert Cemri, Lingjiao Chen, Matei Zaharia, James Zou y Percy Liang, “Midiendo Agentes en Producción,” arXiv:2512.04123, enviado el 2 de diciembre de 2025, revisado el 3 de febrero de 2026, https://arxiv.org/abs/2512.04123.↩︎

  11. Parlamento Europeo y Consejo de la Unión Europea, Reglamento (UE) 2024/1689 del Parlamento Europeo y del Consejo que establece Normas Armonizadas sobre Inteligencia Artificial (Ley de Inteligencia Artificial), Diario Oficial de la Unión Europea, 12 de agosto de 2024, https://artificialintelligenceact.eu.↩︎