Esta página forma parte de la infraestructura del Protocolo . Define la brecha probatoria que la mayoría de los programas de gobernanza de IA deja aún sin resolver: la distancia entre el control declarado y la prueba demostrable.
Explora la infraestructura del protocolo:
→ El Protocolo
→ De la decisión a la estructura defendible: cuando la supervisión se convierte en evidencia
→ Consulta la especificación técnica pública
→ Verifica un código CWC en el registro público
→ EVIDE – Registro probatorio para contenidos y decisiones digitales
→ Política del registro CWC
→ Solicita un código oficial de verificación CWC
→ Framework documental para la gobernanza de IA
→ Guía de implementación: supervisión de IA verificable
→ Sesgo de supervisión: por qué el control humano puede fallar en sistemas de IA
→ Decision Attestation Layer: el nivel probatorio faltante en la gobernanza de IA
→ AI Evidence Officer: cómo demostrar la supervisión humana en sistemas de inteligencia artificial
→ El nivel probatorio en la gobernanza de IA
→ FAQ sobre el protocolo : preguntas y respuestas sobre el framework
Lecturas relacionadas:
→ AI Data Poisoning: el ataque que ningún antivirus puede detener
→ Human in the loop: por qué decir que existe supervisión humana no es suficiente
→ Casos reales de fallos en la gobernanza de IA y lo que debería haberse demostrado
Trabaja con nosotros:
La gobernanza de IA no falla al nivel del control. Falla al nivel probatorio.
La mayoría de las organizaciones comprende ya que los sistemas de inteligencia artificial requieren gobernanza. Crean políticas. Definen cadenas de aprobación. Introducen reglas de supervisión, rutas de escalada y controles internos. En algunos casos construyen sofisticadas capas de orquestación capaces de aplicar restricciones antes de la ejecución.
Todo esto es importante. Pero cuando una decisión se impugna, la pregunta cambia.
El problema ya no es si la gobernanza existía. El problema es si la gobernanza puede probarse.
Este es el problema del nivel probatorio en la gobernanza de IA.
En síntesis
- El problema: la mayoría de los frameworks de gobernanza de IA define controles, pero no produce pruebas verificables de forma independiente de que esos controles estaban efectivamente activos en el momento en que se tomó una decisión.
- El riesgo: cuando una decisión se impugna, los logs y las declaraciones de política suelen ser insuficientes porque dependen de la confianza en el sistema de origen.
- El nivel faltante: una estructura probatoria capaz de demostrar quién era responsable, qué fue examinado, bajo qué reglas, en qué momento y con qué garantías de integridad.
- La respuesta: el Protocolo define cómo la gobernanza de IA se vuelve atribuible, anclada en el tiempo, verificable externamente y defendible.
Por qué el control no es suficiente
Muchas arquitecturas de gobernanza están diseñadas para reducir el riesgo operativo antes de la ejecución. Separan los datos de la intención. Aplican restricciones. Compilan reglas en estructuras ejecutables. Bloquean acciones no autorizadas y limitan lo que el sistema está autorizado a hacer.
Estas son funciones importantes. Afrontan la ejecución no autorizada.
Pero la ejecución contestada es un problema distinto.
En auditorías, disputas legales, revisiones regulatorias y crisis reputacionales, el reto no es simplemente decir que existía un control. El reto es demostrar, de un modo que resista el escrutinio, que:
- un contexto decisional específico existía en una forma concreta
- un conjunto definido de reglas estaba vigente en ese momento
- una identidad humana específica era responsable del nivel de supervisión relevante
- el contexto exacto de inputs y outputs puede reconstruirse
- la unidad probatoria estaba fijada en el tiempo y no puede alterarse silenciosamente con posterioridad
Sin estos elementos, la gobernanza sigue siendo operativamente útil pero probatoriamente frágil.
Esto ilustra un punto estructural: cuando la gobernanza no está respaldada por evidencia verificable, la responsabilidad se atribuye por presunción, no se demuestra.
El fallo central: la coherencia interna no es prueba externa
Distinción importante
El nivel probatorio no es un sistema de logging. No sustituye ni extiende los logs del sistema.
Los logs registran qué ha ocurrido dentro de un sistema. El nivel probatorio define qué debe capturarse y anclarse externamente para que un tercero – que no tiene motivo para confiar en el sistema de origen – pueda verificar de forma independiente que condiciones específicas se cumplían en un momento específico.
Un log responde a la pregunta: ¿qué ha registrado el sistema? El nivel probatorio responde a una pregunta distinta: ¿qué puede demostrarse a alguien que no confía en el sistema?
Es aquí donde muchos sistemas fallan.
Un log de auditoría interno puede ser coherente. Un motor de gobernanza puede ser determinista. Un objeto de regla puede estar correctamente versionado. Una plataforma puede incluso usar hash chaining para detectar mutaciones silenciosas en sus propios registros internos.
Pero nada de esto crea automáticamente una prueba independiente.
La coherencia interna no equivale a la autenticidad externa.
Un sistema puede ser capaz de mostrar que sus registros son coherentes. Esto no responde todavía a la pregunta que una parte externa tiene derecho a plantear:
¿Por qué debería confiar en el sistema que generó el registro para validar el registro sobre sí mismo?
Es precisamente aquí donde el nivel probatorio se vuelve necesario.
Principio clave
El problema no es si la gobernanza existe. El problema es si puede probarse.
El Protocolo se articula en cuatro componentes distintos y complementarios:
| Componente | Función |
|---|---|
| Etiqueta | Declaración pública de supervisión humana |
| Código CWC | Identificador único verificable en el registro público |
| Registro público | Transparencia y control externo independiente |
| FEDIS | Prueba legal independiente con hash SHA-256 y sello de tiempo cualificado eIDAS |
Implicaciones técnicas y legales
✔ El protocolo no depende de una autoridad central – el registro es útil, pero no necesario para la validez probatoria.
✔ La prueba es autosuficiente – cualquiera puede verificar hash y sello de tiempo sin confiar en la plataforma.
✔ Compatible con las normativas europeas – eIDAS es el estándar más sólido en Europa para la prueba digital.
✔ Resiliente – aunque el registro desapareciera, la prueba sigue siendo válida.
Con FEDIS, el Protocolo no es solo robusto: es de grado forense. Es un sistema de atestación, prueba y accountability diseñado para auditorías, verificación y reconstrucción post-evento. Esto lo sitúa en una categoría muy más avanzada que las simples “etiquetas de transparencia de IA”.
Qué debe hacer demostrable el nivel probatorio
Para que la gobernanza de IA se vuelva defendible, un sistema debe ser capaz de producir algo más que simples logs y descripciones de proceso. Debe ser capaz de producir una unidad probatoria estructurada.
Como mínimo, esa unidad debe hacer demostrable:
- Atribución de identidad: quién era responsable del nivel de supervisión o del contexto decisional relevante
- Integridad del input: qué input exacto fue recibido y evaluado
- Contexto de las reglas: qué reglas, versiones y referencias documentales estaban vigentes
- Límites de la decisión: qué estaba autorizado a hacer el sistema en ese momento
- Integridad temporal: cuándo se completó la unidad probatoria
- Verificabilidad externa: cómo un tercero puede verificar existencia e integridad sin confiar en el sistema de origen
Cuando estos elementos están ausentes, la responsabilidad se infiere en lugar de demostrarse. Puede seguir asignándose, pero ya no es defendible con certeza.
En ausencia de esta estructura, una decisión sigue siendo formalmente válida pero se vuelve sustancialmente indefendible.
Por qué los logs, la blockchain y el monitoreo no resuelven el problema por sí solos
Esta página no argumenta en contra del logging, la orquestación, el monitoreo o el anclaje en blockchain. Todos pueden ser útiles. Todos pueden formar parte de una arquitectura de gobernanza seria.
Pero ninguno de ellos, por sí solo, resuelve el problema probatorio.
Un log puede registrar un evento. Una blockchain puede hacer un hash inmutable. Una capa de monitoreo puede mostrar el comportamiento del sistema a lo largo del tiempo.
Lo que no proporcionan automáticamente es un esquema probatorio defendible capaz de responder a:
- qué exactamente se está probando
- si la unidad probatoria está completa
- cómo la atribución está vinculada a una identidad verificada
- cómo el contexto decisional puede reconstruirse por un tercero
- si el registro resiste el escrutinio fuera del entorno que lo produjo
Anclar algo inmutable no equivale a definir algo defendible.
El rol del Protocolo
El Protocolo opera exactamente en este nivel.
No define quién debe tener autoridad. No prescribe un único modelo de gobernanza. No sustituye el compliance, la orquestación ni los servicios de asesoría legal.
El protocolo no valida la autoridad. Hace verificables los eventos.
Su propósito es definir la estructura probatoria necesaria para que las decisiones asistidas por IA, los outputs supervisados y los eventos de gobernanza sean evaluables de forma independiente.
Esto incluye:
- Human Oversight Event (HOE): el registro estructurado de un acto de supervisión humana
- Decision Attestation Layer: el nivel probatorio que eleva un evento de gobernanza a contexto decisional demostrable
- AI Evidence Officer: el rol profesional responsable del mantenimiento de las pruebas técnicas verificables de la supervisión humana
- Registro público de verificación: el nivel de referencia externa que permite a terceros verificar existencia, integridad y contexto de referencia independientemente del sistema de origen – verifica un código CWC
Juntos, estos elementos transforman la gobernanza de declaración interna en estructura defendible, verificable externamente y anclada a un registro público independiente.
El registro público no es el protocolo. Es el nivel de verificación.
Un malentendido frecuente es reducir el problema probatorio al mero almacenamiento o al anclaje.
Esta no es la función del registro público.
El registro no genera la decisión. No interpreta el contenido. No decide qué es verdad. No sustituye al sistema de origen.
Su rol es más acotado y más importante:
- hacer que la unidad probatoria sea referenciable externamente
- preservar un punto de control público de la integridad
- permitir la verificación independiente de existencia, integridad y coherencia de las referencias
- impedir que las mutaciones silenciosas pasen inadvertidas
El registro es una capa habilitadora, no la capa central.
La pregunta real es siempre la misma: ¿qué debe capturarse para que una decisión impugnada sea demostrable? Una vez que esa estructura existe, el registro la hace verificable de forma independiente.
Perímetro del protocolo
El Protocolo no define quién ostenta la autoridad ni cómo deben estructurarse los procesos de decisión previos. Estos aspectos pertenecen a los modelos de gobernanza, las políticas organizativas y los frameworks de decisión.
El protocolo opera aguas abajo. No valida la autoridad. Hace verificables los eventos.
Tres niveles distintos en la accountability de IA
La accountability de IA se vuelve más clara cuando se separan tres niveles distintos.
- Nivel de gobernanza: define quién puede decidir, bajo qué reglas, restricciones y estructuras organizativas
- Nivel probatorio: define qué debe capturarse y probarse para que esas decisiones sigan siendo defendibles bajo escrutinio
- Nivel de reconstrucción: analiza los fallos a posteriori cuando la cadena probatoria era inexistente, incompleta o impugnada
El Protocolo pertenece al segundo nivel.
Esta distinción es importante porque muchos debates sobre gobernanza de IA confunden el control operativo con la defendibilidad probatoria. Están relacionados, pero no son el mismo problema.
El modelo de tres niveles en la práctica
Una capa de gobernanza que aplica restricciones antes de la ejecución afronta la ejecución no autorizada. Una capa probatoria que cristaliza qué ha ocurrido y en qué condiciones afronta la ejecución contestada. Una capa de reconstrucción que analiza los fallos a posteriori afronta la brecha dejada cuando ninguna de las dos primeras capas existía.
Las tres son necesarias. Ninguna sustituye a las demás.
Por qué esto importa ahora
A medida que los sistemas de IA se convierten en parte integrante de las decisiones públicas, los sectores regulados, los flujos de trabajo empresariales y las operaciones orientadas a clientes, el modo de fallo se está desplazando.
La próxima oleada de disputas no se limitará a si un modelo de IA estaba sesgado o si un flujo de trabajo estaba automatizado.
La próxima oleada preguntará:
- quién examinó este output
- qué restricciones estaban efectivamente vigentes
- qué estaba exactamente autorizado a hacer el sistema
- qué pruebas existen de que esas condiciones se cumplían antes de que la acción tuviera lugar
Las organizaciones que no puedan responder a estas preguntas se encontrarán ante el mismo problema de forma recurrente: puede que hayan tenido gobernanza, pero no podrán probarla.
La consecuencia real
Cuando el nivel probatorio está ausente, la responsabilidad no desaparece. Se atribuye por presunción.
Este es uno de los riesgos estructurales más importantes en la gobernanza de IA.
Una organización puede actuar de buena fe. Puede incluso construir controles razonables. Pero en ausencia de pruebas verificables de forma independiente, la decisión sigue siendo vulnerable.
Una decisión formalmente válida puede seguir volviéndose sustancialmente indefendible.
La sección de casos reales de este sitio documenta exactamente esta dinámica a través de sentencias, decisiones regulatorias e incidentes operativos: Gobernanza de IA: casos reales y responsabilidad demostrable.
Qué define esta página
Esta página define una posición simple pero fundamental:
La gobernanza de IA requiere un nivel probatorio.
No porque los sistemas deban desconfiarse por defecto, sino porque los sistemas serios deben seguir siendo defendibles cuando se cuestionan.
Este es el nivel que el Protocolo formaliza.
Preguntas frecuentes
¿El nivel probatorio equivale a la gobernanza?
No. La gobernanza define autoridad, reglas y restricciones. El nivel probatorio define qué debe capturarse y probarse para que esas acciones de gobernanza sigan siendo defendibles cuando se impugnan.
¿Se trata solo de un registro o de un servicio de anclaje?
No. El registro es solo una parte de la estructura. El problema central es el esquema probatorio en sí: qué debe capturarse, cómo se atribuye, cuándo se completa y cómo puede verificarse de forma independiente.
¿Los logs internos resuelven el problema?
No por sí solos. Los logs internos pueden mostrar coherencia dentro del sistema, pero no proporcionan automáticamente pruebas independientes a terceros que tengan motivos para no confiar en el sistema de origen.
¿El protocolo sustituye a los frameworks de gobernanza de IA?
No. El protocolo los complementa. No define estructuras de autoridad previas. Hace que los eventos de gobernanza sean verificables y defendibles a posteriori.
¿Por qué es necesaria la verificación externa?
Porque en el momento en que una decisión se impugna, los registros del propio sistema podrían no ser ya suficientes. La verificación externa permite evaluar la unidad probatoria independientemente del sistema que la generó.
¿Cuál es la diferencia entre ejecución no autorizada y ejecución contestada?
La ejecución no autorizada significa que un sistema ha actuado fuera de sus límites permitidos. La ejecución contestada significa que un sistema ha actuado dentro de sus límites, pero no existe una prueba independiente de cuáles eran esos límites, o de que las condiciones para la acción autorizada se cumplían efectivamente. Son modos de fallo distintos que requieren niveles distintos para afrontarse.