La gobernanza de la IA necesita arquitectura, no otra lista de verificación

La mayor parte de la gobernanza de la IA empieza cerca del final del sistema. Se redacta una política, se abre un registro de riesgos, se reúne un comité y una lista de verificación anota lo que el sistema debería hacer. Cada uno de esos artefactos tiene su función. Ninguno responde a la pregunta que la arquitectura tiene que responder tarde o temprano: ¿qué propiedad del sistema hace verdadera la afirmación de gobernanza?

Una política puede decir que los resultados inciertos pasan por revisión humana. En algún lugar del código, algo decide qué cuenta como incierto, y otra cosa decide si un resultado incierto puede seguir adelante de todos modos. Si esas decisiones no se diseñan, existen igual; simplemente se toman por accidente. La gobernanza pasa a ser algo más que documentación cuando la arquitectura puede imponerla.

Tres afirmaciones aparecen en casi cualquier documento de gobernanza de la IA.

"Las personas deben revisar los resultados inciertos." Como política, es una intención. Como arquitectura, necesita un lugar donde la incertidumbre esté representada de forma explícita, un límite que los resultados inciertos no puedan cruzar, una persona definida que decida y un registro de esa decisión que permanezca unido al resultado. Sin el límite, la revisión es una cortesía que la tubería concede cuando no está ocupada.

"La trazabilidad está asegurada." Como política, suele significar que existen registros de log. Como arquitectura, significa que el sistema conserva las relaciones necesarias para reconstruir cómo llegó a existir una salida concreta: en qué evidencia se apoya, qué pasos la tocaron, qué decisiones se tomaron sobre ella y quién las tomó. Los logs que nunca se diseñaron para volver a unirse son almacenamiento, no trazabilidad.

"El modelo no debe hacer X." Como política, es una petición dirigida a un componente probabilístico. Como arquitectura, es un límite determinista que no depende de la colaboración del modelo: X es inalcanzable desde donde está el modelo, o lo comprueba un componente capaz de rechazarlo. Una regla dirigida a un modelo es una esperanza. Un límite alrededor de un modelo es una restricción.

Una afirmación en un documento puede ser verdadera o falsa respecto de un sistema, y leer el documento no dice cuál de las dos. Una restricción en la arquitectura se puede inspeccionar, probar y, cuando se rompe, advertir.

COADF, el Compliance-Oriented AI Development Framework, es un marco de desarrollo documentado públicamente para sistemas de IA que tienen que sostenerse ante la regulación. Surgió del trabajo de arquitectura del proyecto de investigación y desarrollo AnyLAI y de su demostración de pasaportes de producto AnyDPP, pero su propósito va más allá de un producto, una regulación o una implementación concretos.

Enuncia ocho principios de arquitectura, cada uno atado a la obligación para la que fue escrito, con plantillas de gobernanza, entre ellas una escala de autonomía para agentes de IA que escriben código de producción, y un modelo legible por máquina para informar qué controles ejercita realmente un proyecto. Su objeto son los límites entre el procesamiento determinista, la IA probabilística, la evidencia, la confianza, la revisión humana, las reglas, la trazabilidad, las normas externas y lo que el sistema publica.

El nombre describe una orientación, no un resultado. El método de desarrollo se orienta hacia los requisitos regulatorios; el nombre nunca afirma que un sistema construido con él los cumpla.

Cada principio responde a una forma concreta en que los sistemas de IA dejan de ser gobernables.

P-1 · Primero determinista, lo probabilístico en cuarentena. Todo lo que llega a una persona, a un documento o a otro sistema es determinista por defecto. Un componente probabilístico se limita a una tarea acotada y devuelve un valor, una confianza y el método con que se extrajo el valor, nunca un valor desnudo, porque un valor desnudo no se puede controlar, declarar ni revisar.

P-2 · Salida controlada por confianza. La confianza se adhiere a un único atributo, no a un documento entero, porque una sola puntuación para un archivo oculta qué hecho de su interior está débilmente respaldado. La confianza baja nunca llega a una salida publicada. Sin evidencia no hay valor: ni un valor por defecto ni una estimación.

P-3 · Revisión humana por arquitectura. La revisión la dispara la confianza, no un calendario. Quien revisa ve un hecho junto al pasaje de la fuente de la que procede y decide sobre ese hecho; un valor rechazado deja el atributo vacío en lugar de invitar a una segunda conjetura.

P-4 · Una traza, de extremo a extremo. Un identificador, creado cuando se recibe un documento, recorre cada paso de procesamiento, cada evaluación de confianza y cada decisión humana hasta la salida publicada, sobre un rastro al que solo se añaden entradas.

P-5 · Declaración de la extracción automática. Una salida con datos extraídos por máquina lo dice de forma visible, en la propia salida, y nombra los atributos afectados.

P-6 · El sistema de fences. Una barrera que vive en un documento es un consejo. Una barrera que se ejecuta en la tubería y bloquea una entrega es un fence.

P-7 · Aislamiento de dependencias de normas. Los sistemas de clasificación, las bases de datos terminológicas y los servicios externos de validación viven en adaptadores fuera del modelo de datos central. Un servicio externo puede elevar la confianza. Ninguno puede bloquear una salida.

P-8 · Reglas como datos, con autonomía graduada. Las reglas con las que se mide una decisión son datos versionados, el motor no cambia cuando cambia una regla y cada decisión queda atada a la versión de reglas que la produjo. Cuánto puede hacer el sistema sin una persona se fija en esas reglas, nunca por encima del límite que fija la ley.

Por separado, varios de estos principios parecen higiene de ingeniería corriente. Juntos forman una disciplina en la que cada uno cubre una debilidad que los demás dejarían abierta. La confianza sin traza no se puede auditar; una traza sin control registra fielmente valores que nadie revisó; un control sin declaración oculta lo que aportó la máquina. Nada de eso sobrevive a la siguiente refactorización si la compilación no advierte cuándo se rompe.

Nada de esto va contra el aprendizaje automático. Los componentes probabilísticos son valiosos donde hace falta interpretar: leer un documento no estructurado, reconocer una entidad en un texto con formato irregular, clasificar lo que ninguna regla previó. Los componentes deterministas son valiosos donde importan la repetibilidad, la imposición de límites y la validación reproducible. El error está en dejar implícito el reparto de responsabilidades entre ambos.

Para cada recorrido por el sistema, una arquitectura que se toma en serio el límite puede decir qué componente puede inferir, cuál decide, cuál comprueba, cuál puede bloquear y qué estado o qué salida se vuelve visible hacia fuera. Cuando esas respuestas viven en el código y no en un diagrama, quien revisa puede verificarlas, y un cambio que desplaza una decisión al otro lado del límite se nota en la revisión.

Un valor de confianza describe con qué fuerza está respaldado algo. No hace verdadero nada. Un modelo muy seguro de un valor que leyó del documento equivocado ha hecho una afirmación precisa sobre lo equivocado.

La consecuencia arquitectónica es que la confianza debería cambiar lo que el sistema puede hacer, no solo lo que muestra. En COADF, la confianza pertenece a un atributo y a la evidencia que lo respalda, y la confianza baja se convierte en una pregunta para una persona en lugar de en un valor publicado. El marco trata además un hecho como portador de varias lecturas a la vez, por ejemplo si su fuente es genuina y qué cubre realmente, y nunca las funde en un único número. Una puntuación en un panel informa. Una puntuación que decide adónde puede ir un valor gobierna.

"Hay una persona en el circuito" es la forma más débil de una afirmación de supervisión, porque deja abiertas todas las preguntas que importan. El Reglamento de IA sitúa el requisito en el propio diseño: su artículo 14 exige que los sistemas de IA de alto riesgo se diseñen y desarrollen de modo que personas físicas puedan supervisarlos de manera efectiva mientras están en uso.

Desde la arquitectura, la supervisión tiene que responder a cuatro preguntas. ¿Qué dispara la necesidad de una persona? ¿Qué decide esa persona: un caso entero, o un hecho frente a su fuente? ¿Qué no puede avanzar hasta que exista la decisión? ¿Y cómo pasa la decisión, con quién la tomó y por qué, a formar parte de la misma traza que el valor al que se refiere? Un paso de revisión que la tubería puede saltarse bajo carga no es supervisión. Es una cola.

La trazabilidad suele auditarse como la existencia de logs. Una prueba más útil es si una única salida publicada puede seguirse hacia atrás: del resultado visible desde fuera a la decisión que la liberó, al procesamiento que la produjo y a la evidencia en la que se apoya. Evidencia, procesamiento, decisión, resultado. Si algún eslabón de ese recorrido tiene que reconstruirse a base de conjeturas, el sistema no es trazable, por mucho que registre.

Por eso COADF trata la traza como arquitectura y no como operación: un identificador desde la entrada hasta la salida, un rastro al que se añade y que nunca se reescribe, y una cadena que se exporta en una forma que puede leer alguien que no construyó el sistema. El artículo 12 del Reglamento de IA plantea la conservación de registros del mismo modo, como algo que un sistema de alto riesgo debe permitir técnicamente.

Una regla de gobernanza que nada comprueba se degrada al ritmo del código. Algunas reglas solo pueden juzgarlas personas. Muchas puede comprobarlas la compilación: una dependencia que no debe existir entre dos capas, una formulación que una superficie pública nunca debe usar, una entrega que no debe avanzar mientras falle una comprobación obligatoria. COADF trata esas reglas como condiciones ante las que una compilación o una entrega deberían poder fallar, y ordena sus fences en datos, arquitectura, texto y proceso.

Un fence también tiene que demostrar que funciona. COADF llama a esa práctica una prueba de dientes: se planta el defecto real en el archivo real, el fence salta y la plantación se retira. Un fence que nadie ha visto fallar nunca es un comentario con un ejecutor de pruebas al lado. Los informes siguen la misma regla: un control solo cuenta como impuesto cuando su evidencia se ejecutó en una ejecución identificada y terminó con éxito.

La regulación da forma a los requisitos; no es un diseño. Los textos legales se modifican y las normas técnicas se revisan en ciclos propios. Con el Reglamento de diseño ecológico para productos sostenibles, lo que debe contener un pasaporte digital de producto lo fijan actos delegados, grupo de productos por grupo de productos. Un diccionario semántico como ECLASS, o un modelo de gemelo digital como la Asset Administration Shell, sigue su propio calendario de versiones.

Un sistema que fija ese vocabulario en su lógica central se vuelve frágil justo donde se mueve la regulación. COADF mantiene las normas externas en adaptadores que pueden aportar confianza pero no decidir, y las reglas en datos versionados, de modo que un cambio de regla deja intacto el motor y las decisiones anteriores siguen nombrando la versión de reglas bajo la que se tomaron. Vincular un principio al artículo al que responde explica por qué existe el principio. Si ese artículo se aplica a un sistema concreto sigue siendo una cuestión jurídica.

COADF es un marco de desarrollo documentado públicamente. No es una certificación, no es una norma de auditoría y no es un esquema de evaluación de la conformidad. No es una aprobación regulatoria, ni una garantía de cumplimiento, ni asesoramiento jurídico. Ninguna autoridad lo ha evaluado, auditado ni respaldado. Aquí nadie emite, concede ni retira nada, y aplicarlo no produce sello ni marca de ningún tipo.

El trabajo de arquitectura se vuelve más útil cuando sus supuestos y sus límites pueden inspeccionarse. Un marco privado solo puede describirse; uno publicado puede leerse, compararse y discutirse.

La publicación da a las ideas un vocabulario estable, de modo que una conversación sobre controles de confianza o fences no tenga que empezar redefiniendo los términos. Hace inspeccionables las decisiones de diseño, también las que puedan resultar equivocadas. Da a otros arquitectos algo concreto que cuestionar, y a las implementaciones una referencia frente a la cual explicar dónde coinciden y dónde se apartan a propósito. Y deja un registro técnico público y fechado de lo que se dijo, y de cuándo.

Un marco de arquitectura público no necesita publicar cada mecanismo de implementación. COADF documenta los principios y las prácticas destinados a la inspección pública, mientras que determinados mecanismos propios de la implementación quedan fuera de la edición pública. Sus páginas dicen, principio por principio, qué partes se enuncian completas y cuáles solo como principio, de modo que el propio límite es visible aunque el detalle no lo sea.

COADF versión 2.2 está documentado públicamente en inglés, alemán, español, francés y portugués de Brasil: los ocho principios, las plantillas de gobernanza, el informe de controles y un mapa regulatorio leído en fuentes primarias, además del marco completo en ediciones descargables. La respuesta más útil a un marco de arquitectura no es el acuerdo. Es una lectura atenta y una objeción concreta.