Cuando se habla de inteligencia artificial supervisada, muchas organizaciones declaran tener control humano sobre el proceso. El problema, en la práctica, no es declararlo. El problema es demostrarlo de manera verificable, coherente y defendible incluso fuera del sistema que generó la decisión.
Por este motivo hemos reunido en esta página las preguntas más frecuentes sobre el framework THE PROTOCOL, con respuestas claras, técnicas y orientadas a la realidad operativa de auditoría, gobernanza, verificación documental y posible litigio.
Índice de preguntas
A. El protocolo: definición y propósito
→ ¿Qué es el Protocolo ?
→ ¿El protocolo certifica que la decisión de IA era correcta?
→ ¿Qué problema resuelve frente a la gobernanza de IA tradicional?
→ ¿Es lo mismo que un registro gestionado por el vendor?
→ ¿Qué diferencia hay entre supervisión declarada y supervisión demostrable?
B. El modelo técnico
→ ¿Qué se entiende por “decision context”?
→ ¿El protocolo asume procesos aún abiertos o en evolución?
→ ¿Cuál es el papel de la identidad humana en el protocolo?
→ ¿Cómo se gestionan los timestamps y las referencias temporales?
→ ¿Cómo se protege la integridad del output o de la decisión?
→ ¿Qué es el hash de intake y cómo se distingue del hash de origen?
→ ¿Qué significa “cierre declarado”?
C. Compatibilidad e integración
→ ¿El protocolo funciona solo con ChatGPT, Claude o Gemini?
→ ¿Se necesita una integración API para usar el framework?
→ ¿Es compatible con los frameworks de gobernanza ya adoptados?
→ ¿Es compatible con el AI Act europeo?
D. Valor probatorio y defendibilidad
→ ¿Puede ser útil en auditorías, verificaciones o litigios?
→ ¿Qué tipo de prueba o documentación produce el sistema?
→ ¿Protege frente al riesgo de revisión posterior de los logs?
→ ¿Qué sucede si la autoridad declarada en el cierre es posteriormente disputada?
→ ¿El protocolo cubre el “momento cero”, es decir, el instante de la decisión real?
E. A quién va dirigido
→ ¿Quién debería interesarse por este framework?
→ ¿Es relevante para despachos legales y consultores?
→ ¿Qué valor tiene para una empresa que ya usa IA en sus procesos?
F. Cadena de evidencias y gestión multi-organización
→ ¿Qué es la cadena de evidencias verificables?
→ ¿El vínculo entre intakes altera la integridad de cada elemento?
→ ¿En qué escenarios es útil la cadena de evidencias?
→ ¿Puede un profesional gestionar varias organizaciones con un solo acceso?
→ ¿Cómo funciona la facturación en un contexto multi-organización?
→ ¿Qué roles existen dentro de una organización?
G. Contexto y riesgos emergentes
→ ¿Los agentes de IA representan realmente un riesgo para las organizaciones?
→ ¿Es mejor limitar a los agentes de IA o hacer verificables sus decisiones?
→ ¿Qué ocurre si un sistema de IA se comporta de forma imprevisible?
→ ¿Quién es responsable si un sistema de IA genera errores?
→ ¿El sistema impide declaraciones falsas o abusos?
H. Estado del proyecto y próximos pasos
→ ¿En qué punto se encuentra el proyecto?
→ ¿Dónde encontrar más información?
¿Qué es el Protocolo </AI>?
El Protocolo </AI> es un framework operativo pensado para transformar una supervisión humana declarada en una supervisión humana demostrable. La idea de fondo es simple: no basta con decir que un ser humano estaba “in the loop”. Hay que poder demostrar, de forma estructurada, quién era el sujeto responsable, qué decisión fue cerrada, en qué contexto, con qué integridad y en qué momento.
El framework no nace para sustituir los sistemas de gobernanza ya existentes. Nace para cubrir un vacío muy específico: el paso de un control interno declarado a una unidad probatoria verificable también por terceros.
¿El protocolo certifica que la decisión de IA era correcta?
No. Este es uno de los puntos más importantes que hay que aclarar.
El protocolo no certifica que el proceso de decisión fuera correcto, justo, conforme o legítimo en cuanto al fondo. No entra en el núcleo lógico del sistema de origen y no sustituye el juicio jurídico, ético u organizativo sobre el proceso que condujo a la decisión.
Su propósito es distinto: crear un punto externo, estructurado y verificable que acredite que una determinada unidad de decisión fue recibida en un estado definido, con una cierta estructura, con determinadas referencias de contexto y con una integridad precisa en el momento del intake.
Dicho de forma más directa: el sistema no promete la verdad sustancial de la decisión, sino la fijación verificable del estado declarado en el momento del intake.
¿Qué problema resuelve frente a la gobernanza de IA tradicional?
La gobernanza tradicional se ocupa de reglas, roles, procesos, aprobaciones, responsabilidades y controles internos. Todo esto es necesario. Pero a menudo no basta cuando una decisión es cuestionada o debe demostrarse fuera del sistema que la generó.
En ese momento la pregunta cambia. Ya no es solo “¿existía un procedimiento de control?”. Pasa a ser “¿podemos demostrar de manera independiente qué ocurrió realmente, quién asumió la responsabilidad, qué estado tenía el objeto de decisión y cuándo entró en la cadena de custodia?”.
El protocolo interviene precisamente aquí, en ese espacio. No sustituye la gobernanza. Añade una capa probatoria externa.
¿Es lo mismo que un registro gestionado por el vendor?
No. La diferencia es arquitectónica.
Un registro gestionado por el vendor permanece normalmente dentro del perímetro de confianza del sistema que produjo la decisión. En otras palabras, el sujeto que genera el dato a menudo controla también el lugar donde ese dato se registra, se conserva, se expone o se vuelve a exponer.
El Protocolo , en cambio, está pensado como una capa externa de intake evidenciario. El valor no consiste en decir “confíen en lo que declara el sistema”. El valor consiste en separar la decisión de su entorno original y fijarla en un punto externo, con una toma en carga estructurada y verificable, que no depende de la supervivencia ni de la corrección del sistema que la produjo.
¿Qué diferencia hay entre supervisión declarada y supervisión demostrable?
La supervisión declarada es una afirmación. La supervisión demostrable es una estructura.
En el primer caso se dice que un ser humano vio, aprobó, controló o cerró algo. En el segundo caso existe una unidad en la que esa responsabilidad, ese contexto, esa referencia temporal y esa integridad quedan registradas de tal forma que puedan verificarse posteriormente, también por sujetos que no estaban presentes y no tienen motivos para confiar en el sistema originario.
La distancia entre estas dos condiciones es exactamente el vacío que el protocolo intenta cubrir.
¿Qué se entiende por “decision context”?
Por “decision context” entendemos una unidad de decisión suficientemente cerrada e interpretable como para poder entrar en una cadena probatoria externa. No se trata de un archivo genérico ni de un JSON cualquiera. Se trata de un objeto que representa una decisión ya suficientemente madura como para poder ser tomada en carga sin ambigüedades.
Este contexto puede incluir, por ejemplo, la identidad declarada de la autoridad humana, el resultado de la decisión, el estado de cierre, la versión de las reglas aplicadas, la referencia contextual, los timestamps relevantes y los elementos de integridad. El objetivo no es acumular la mayor cantidad posible de datos, sino fijar el conjunto estructural mínimo necesario para hacer la unidad interpretable y defendible también fuera del sistema originario.
¿El protocolo asume procesos aún abiertos o en evolución?
No. El framework ha sido pensado precisamente para evitar la entrada de objetos todavía fluidos o en fase de elaboración.
La idea central es que la unidad debe estar ya lo bastante cerrada como para poder ser recibida como unidad evidenciaria lista para su toma en carga. Si un proceso sigue abierto, es negociable, modificable o no está ratificado, todavía no estamos ante un objeto estable que anclar externamente.
Este principio también es importante para evitar ambigüedades, conflictos interpretativos y falsos puntos de anclaje. El cierre no se verifica en el fondo, se exige como condición de admisibilidad de entrada.
¿Cuál es el papel de la identidad humana en el protocolo?
La identidad del supervisor o de la autoridad humana es uno de los elementos clave del framework. No porque el sistema deba validar todos los aspectos del proceso interno, sino porque una supervisión demostrable requiere una referencia humana declarada, reconocible y estructurada.
En el modelo operativo, la identidad está vinculada al certificado DAPI, un sistema de identificación verificada que permite asociar la responsabilidad declarada a un sujeto humano identificado de forma coherente a lo largo del tiempo. Este punto es esencial para distinguir una simple declaración narrativa de una responsabilidad documentable.
El framework no intenta reconstruir ni certificar el recorrido interno de intervención humana. Captura el punto en que una decisión se vuelve atribuible: quién asume la responsabilidad del resultado en el momento en que se declara cerrada.
¿Cómo se gestionan los timestamps y las referencias temporales?
El framework está construido en torno a una lógica rigurosa de coherencia temporal. Todas las referencias se expresan en UTC, para evitar ambigüedades, reconversiones no controladas o discrepancias entre sistemas distintos.
En particular, el modelo distingue claramente entre dos momentos diferentes:
- el timestamp declarado por el sistema de origen, es decir, el momento en que la decisión se considera cerrada o ratificada en el contexto originario;
- el timestamp de intake, es decir, el momento en que la unidad es recibida por la capa externa y se convierte en un punto de custodia verificable.
Esta distinción es fundamental. El segundo no sustituye al primero. Pero crea el primer punto de toma en carga externa verificable, independiente del sistema de origen.
¿Cómo se protege la integridad del output o de la decisión?
La integridad se aborda con un enfoque técnico claro. El objetivo es hacer que la unidad recibida pueda vincularse a una huella verificable, para reducir el riesgo de alteraciones no detectadas después del intake.
En el caso de objetos estructurados, el modelo prevé la normalización determinista del payload antes del cálculo del hash, para evitar problemas debidos, por ejemplo, al simple orden de las claves en un JSON. Dos payloads semánticamente iguales no deben producir resultados incoherentes solo por diferencias formales.
Cuando el sistema de origen proporciona su propio hash declarado, el framework prevé una distinción neta entre hash de origen y hash de intake. Los dos valores no son lo mismo y no deben confundirse.
¿Qué es el hash de intake y cómo se distingue del hash de origen?
Son dos elementos distintos con funciones diferentes.
El hash de intake es calculado por el sistema en el momento de la recepción de la unidad de decisión. Es el valor autoritativo dentro del workflow de certificación: acredita que esa estructura, en ese preciso momento, entró en la capa externa con esa forma. A partir de ese momento, cualquier alteración es detectable.
El hash de origen, cuando existe, es un valor declarado por el sistema que generó la decisión. Si se proporciona, se compara con el resultado del cálculo sobre el payload recibido. Si ambos valores no coinciden, el intake no se considera válido y la solicitud se suspende a la espera de integración.
La presencia del hash de origen no es obligatoria, pero refuerza significativamente la cadena de integridad, extendiendo la garantía también al tránsito pre-intake.
¿Qué significa “cierre declarado”?
El framework distingue entre dos niveles que no deben superponerse.
El cierre declarado es el estado comunicado por el sistema de origen: la decisión ha sido ratificada, aprobada, finalizada o cerrada según la lógica interna de ese sistema. La capa de intake no verifica que esta condición sea sustancialmente verdadera. La trata como un requisito previo de admisibilidad.
La verificación de integridad en el intake es, en cambio, responsabilidad de la capa externa. Garantiza que el payload recibido corresponde a lo declarado y que no ha sido alterado entre la generación y la toma en carga.
Estos dos niveles no se sustituyen entre sí. Sirven para cosas distintas y deben mantenerse separados también en la comunicación hacia terceros.
¿El protocolo funciona solo con ChatGPT, Claude o Gemini?
No. Y precisamente este es uno de sus puntos fuertes.
El protocolo no nace como una integración específica para un único modelo de IA. No está ligado a un vendor, una plataforma o una marca concreta. Está pensado para funcionar a un nivel distinto, es decir, aguas abajo del modelo, cuando una decisión, un output o un cierre de contexto deben tomarse en carga y hacerse verificables.
Este enfoque permite seguir siendo agnóstico respecto al sistema y adaptarse, con el tiempo, a escenarios distintos, médicos, financieros, HR, legales, logísticos, sin depender de una sola tecnología propietaria ni tener que reescribir la arquitectura para cada contexto aplicativo.
¿Se necesita una integración API para usar el framework?
No. La plataforma es accesible directamente a través del navegador sin necesidad de integración técnica.
El workflow operativo, desde la creación del intake hasta la solicitud FEDIS, desde la publicación en el registro EVIDE hasta la gestión de la cadena de evidencias, puede gestionarse por completo a través de la interfaz web de la plataforma, accesible para los titulares de certificado DAPI.
En una fase posterior el modelo podrá evolucionar hacia intakes estructurados vía API para integraciones machine-to-machine. Pero el punto central no cambia: el objetivo sigue siendo crear una unidad interpretable, cerrada y verificable desde el exterior.
¿Es compatible con los frameworks de gobernanza ya adoptados?
Sí. El protocolo no compite con los frameworks de gobernanza existentes.
La gobernanza define quién puede decidir, bajo qué reglas, con qué restricciones y mediante qué estructuras organizativas. El Protocolo opera en un nivel distinto: define qué debe capturarse y hacerse verificable para que esas decisiones sigan siendo defendibles cuando se cuestionan.
Las dos capas son complementarias. Una construye el proceso. La otra lo hace demostrable cuando ese proceso es impugnado.
¿Es compatible con el AI Act europeo?
El framework está pensado en coherencia con los principios del AI Act europeo, en particular en lo relativo a la trazabilidad de las decisiones de alto impacto, la supervisión humana verificable y la documentación defendible.
El AI Act desplaza progresivamente la carga de la prueba hacia quienes desarrollan y utilizan sistemas de IA en contextos regulados. Ya no basta con declarar que existen controles. Hay que poder demostrar que esos controles estaban activos, documentados y eran reconstruibles. El Protocolo está diseñado precisamente para responder a esta necesidad.
¿Puede ser útil en auditorías, verificaciones o litigios?
Sí, precisamente porque su valor principal no reside en la narrativa interna del sistema, sino en la posibilidad de crear una base verificable también por sujetos externos.
Esto puede ser útil en escenarios de auditoría técnica, control documental, accountability interna, verificación de procesos, relación con órganos de control o situaciones en las que una decisión automatizada o semiautomatizada deba explicarse de manera más sólida.
Naturalmente, el protocolo no sustituye por sí solo la valoración jurídica ni la prueba completa del fondo, pero puede convertirse en una pieza técnica muy fuerte cuando sea necesario demostrar el estado de una decisión y su toma en carga externa.
¿Qué tipo de prueba o documentación produce el sistema?
El objetivo no es producir un simple log o una captura para mostrar. El objetivo es llegar a una unidad evidenciaria estructurada, con elementos suficientes para ser leída, comprendida y verificada también fuera del sistema de origen.
Una unidad de este tipo incluye: identidad declarada del sujeto responsable mediante certificado DAPI, hash SHA-256 del contenido calculado en el momento del intake, timestamp UTC independiente, estado de decisión formalizado, eventual certificación FEDIS con código CWC, y publicación en el registro público EVIDE con identificador único en formato EVIDE-YYYYMMDD-XXXX.
La cuestión no es acumular la mayor cantidad posible de datos. La cuestión es fijar la unidad correcta con el conjunto estructural mínimo necesario para hacerla interpretable y defendible.
¿Protege frente al riesgo de modificación o reconstrucción posterior de los logs?
Sí. Este es uno de los valores más concretos del framework, a menudo subestimado.
El riesgo principal en los sistemas de IA no es solo el “momento cero”. El riesgo más frecuente y operativamente relevante es el del revisionismo post-evento: la posibilidad de que, después de un incidente o de una impugnación, los logs internos sean modificados, reconstruidos o reformulados de forma que hagan parecer que hubo una supervisión que en realidad no existió, o para ocultar lo que realmente ocurrió.
La capa externa crea un punto de no retorno: una vez que la unidad de decisión ha sido capturada con su hash y su timestamp UTC, el sistema de origen ya no puede modificar silenciosamente lo que se había declarado. Esta garantía tiene un valor directo en auditorías y litigios.
¿Qué sucede si la autoridad declarada en el cierre es posteriormente disputada?
Si la autoridad declarada en un punto de cierre es posteriormente impugnada, el sistema no intenta resolver esa disputa internamente.
Lo que el objeto probatorio protege no es la corrección de la autoridad, sino la integridad de la declaración.
En otras palabras, garantiza que:
- una autoridad específica fue declarada
- en un momento preciso en el tiempo
- bajo un estado decisional y una estructura definidos
- y que dicha declaración no ha sido alterada desde entonces
Esto sigue siendo válido incluso si la propia autoridad es posteriormente cuestionada.
La estructura se mantiene de forma independiente, pero únicamente a nivel de atribución e integridad, no a nivel de legitimidad.
Si la disputa se refiere a si esa autoridad era válida, habilitada o legítima, la resolución se produce necesariamente fuera del sistema:
- a través de las normas de gobernanza
- los registros organizativos
- los marcos legales o contractuales
Lo que EVIDE y FEDIS impiden es una clase diferente de fallo:
- la reescritura retroactiva de “quién decidió”
- la ambigüedad sobre cuándo se tomó la decisión
- la pérdida de las condiciones estructurales bajo las cuales fue declarada
En la práctica, esto se vuelve crítico en los litigios. En lugar de debatir sobre narrativas reconstruidas, la discusión se desplaza hacia un punto probatorio fijo: qué fue declarado, por quién y bajo qué condiciones, en ese momento preciso.
En ese punto, la pregunta ya no es qué sucedió, sino si esa autoridad declarada era válida. Y esa es una pregunta legal o de gobernanza, no técnica.
Esta distinción es fundamental: el protocolo no resuelve las disputas de autoridad, pero impide que dichas disputas se expandan hasta involucrar la interpretación de la propia prueba.
¿El protocolo cubre el instante originario de la decisión, es decir, el instante de la decisión real?
No completamente, y es importante decirlo con claridad.
Siempre existe un lapso temporal entre el momento en que se toma una decisión en el sistema de origen y el momento en que esa decisión es capturada por la capa externa. El protocolo no elimina este intervalo.
Lo que sí hace el protocolo es crear el primer punto de custodia verificable e independiente: a partir de ese momento, la integridad queda garantizada. Antes de ese momento, la responsabilidad sigue estando en el sistema de origen y en su cadena interna de control.
Esta limitación se declara, no se oculta. Y puede gestionarse combinando la capa externa con un hash de origen proporcionado por el sistema originario, que extiende la garantía también al tránsito pre-intake.
¿Quién debería interesarse por este framework?
El framework puede interesar a quienes trabajan en AI governance, compliance, auditoría, responsabilidad digital, procesos de decisión asistidos por IA, human oversight, documentación técnica, gestión de riesgos y sistemas de alto impacto donde la simple declaración de control humano ya no es suficiente.
También puede ser relevante para quienes están construyendo sistemas de supervisión y se dan cuenta de que el verdadero problema no es solo organizar el proceso, sino hacerlo demostrable cuando se pone en cuestión.
¿Es relevante para despachos legales y consultores?
Sí, de forma directa.
Quien asiste a clientes expuestos a riesgos de gobernanza de IA, litigios sobre decisiones automatizadas o verificaciones regulatorias necesita una herramienta técnica que traduzca la supervisión declarada en algo estructuralmente verificable. El protocolo responde exactamente a esta necesidad: no es un documento de policy, sino una capa operativa que produce unidades evidenciarias defendibles.
La plataforma admite la gestión multi-organización: un despacho legal puede operar con una sola identidad DAPI sobre varios clientes, manteniendo separadas las solicitudes, las cadenas de evidencias y la facturación para cada mandato.
Para profundizar en la colaboración con despachos legales y consultores existe una sección específica: Partner Kit para despachos legales y consultores.
¿Qué valor tiene para una empresa que ya usa IA en sus procesos?
El valor principal es la defendibilidad externa de las decisiones ya tomadas.
Una empresa que usa IA en sus procesos puede tener una gobernanza interna sólida, procesos documentados y audit trails internos. Pero cuando alguien impugna una decisión desde el exterior, el valor de esa documentación depende de que el sujeto que la cuestiona tenga motivos para confiar en el sistema que la produjo.
La capa externa resuelve estructuralmente este problema: la decisión ya no se defiende solo con los propios logs internos, sino con un punto de anclaje independiente que el sistema de origen no puede controlar ni modificar retroactivamente.
Cadena de evidencias y gestión multi-organización
¿Qué es la cadena de evidencias verificables?
La cadena de evidencias es una funcionalidad operativa de la plataforma EVIDE que permite vincular varios intakes en secuencia, documentando de forma verificable la evolución de un contenido, una decisión o una versión a lo largo del tiempo.
Cada intake permanece independiente e inmutable: tiene su propio hash SHA-256 y su propio timestamp UTC. El vínculo con el anterior es opcional y no modifica la integridad de cada elemento individual. La cadena se construye de forma declarada, no retroactiva.
La estructura típica es:
- Intake #1 – documento original, primera versión, decisión inicial
- Intake #2 – revisión, actualización, integración
- Intake #3 – versión definitiva, con eventual solicitud FEDIS y publicación EVIDE
En sede legal o de auditoría, no basta con demostrar la decisión final. A menudo es necesario reconstruir el recorrido: qué cambios se introdujeron, cuándo y en qué orden. La cadena de evidencias EVIDE responde exactamente a esta necesidad.
No estás archivando un archivo. Estás documentando la responsabilidad profesional a lo largo del tiempo.
¿El vínculo entre intakes altera la integridad de cada elemento?
No. Este es un punto arquitectónico fundamental.
Cada intake tiene su propio hash calculado de forma independiente en el momento de la recepción. El vínculo a la cadena es una referencia lógica que no modifica ni el contenido ni la huella de cada intake.
En la práctica: si el intake #2 declara estar vinculado al intake #1, esta información se registra en el sistema pero no altera el hash de ninguno de los dos elementos. Cada uno sigue siendo verificable de forma autónoma.
Este principio es esencial para garantizar que la cadena no se convierta en un punto de vulnerabilidad: un eslabón cuestionado no invalida los demás.
¿En qué escenarios es útil la cadena de evidencias?
La cadena de evidencias es útil en todos los casos en que es necesario documentar una evolución en el tiempo de forma verificable:
- Contratos en negociación: cada versión queda certificada, la secuencia es reconstruible e inatacable
- Policies empresariales y procedimientos: las revisiones sucesivas quedan vinculadas a la versión original, con fecha cierta
- Outputs de sistemas de IA: cada actualización del modelo, de la respuesta o de la decisión queda trazada en secuencia
- Decisiones médicas o legales: el iter decisional queda documentado paso a paso con identidad y timestamp
- Compliance regulatoria: las versiones de policies y procedimientos son verificables en el tiempo sin depender de logs internos
- Litigios sobre versiones de documentos: la secuencia cronológica puede demostrarse de forma independiente
¿Puede un profesional gestionar varias organizaciones con un solo acceso?
Sí. Esta es una de las características operativas de la plataforma, pensada específicamente para abogados, DPO, consultores y firmas profesionales que gestionan varios clientes o mandatos al mismo tiempo.
El modelo se basa en dos niveles distintos:
- DAPI – identifica a la persona física de manera única y verificada. Es personal e intransferible.
- Organización – define el perímetro operativo. El mismo profesional puede estar asociado a varias organizaciones con roles distintos.
Ejemplos concretos:
- Abogado – gestiona su despacho, tres empresas clientes y un ente público con un único acceso DAPI, manteniendo separadas las solicitudes, cadenas y facturación de cada mandato
- DPO externo – opera sobre veinte empresas como responsable de protección de datos, con logs y certificaciones separadas por organización
- Consultor de governance AI – certifica outputs y decisiones para clientes distintos, con perímetros operativos estancos
- Firma profesional – los colaboradores operan bajo la misma estructura pero sobre perímetros de cliente distintos, con roles y accesos diferenciados
Cada solicitud nace dentro de un perímetro organizativo específico. Las solicitudes, cadenas y certificaciones permanecen siempre separadas por organización.
¿Cómo funciona la facturación en un contexto multi-organización?
La facturación está asociada a la organización, no al usuario individual. Esto refleja la realidad operativa: el profesional actúa por cuenta de un cliente, y el coste de la certificación debe imputarse al perímetro correcto.
Cada organización tiene su propia ficha de facturación, introducida y confirmada por un usuario con rol owner o admin. Los usuarios con rol member pueden crear solicitudes en nombre de la organización pero no gestionan los datos de facturación.
Antes de poder enviar una nueva solicitud de certificación, el sistema verifica que exista una ficha de facturación válida y confirmada para el perímetro organizativo seleccionado. Este bloqueo es intencional: garantiza que cada solicitud quede asociada a un perímetro económico claro y verificable desde el inicio.
¿Qué roles existen dentro de una organización?
La plataforma prevé tres roles distintos dentro de cada organización:
- Owner – titular de la organización. Gestiona los datos de facturación, puede añadir o eliminar usuarios y tiene control operativo total. Típicamente el responsable legal o el fundador del despacho.
- Admin – administrador delegado. Tiene los mismos poderes operativos que el owner sobre la gestión de certificaciones y facturación, pero no es el titular formal. Típicamente un colaborador de confianza con plenos poderes operativos.
- Member – miembro ordinario. Puede crear solicitudes de certificación en nombre de la organización y consultar sus propias solicitudes, pero no gestiona billing ni configuraciones organizativas.
El mismo usuario DAPI puede tener roles distintos en organizaciones distintas: owner en su propio despacho y member en una organización cliente, por ejemplo.
Contexto y riesgos emergentes
¿Los agentes de IA representan realmente un riesgo para las organizaciones?
En los últimos meses el debate sobre los agentes de IA se ha intensificado, sobre todo en relación con el nivel de acceso operativo que estos sistemas requieren para funcionar eficazmente.
En muchos escenarios aplicativos, los agentes pueden interactuar con sistemas empresariales, correo, documentos, calendarios u otros entornos sensibles. Esto implica un aumento del nivel de autonomía operativa y, en consecuencia, una mayor exposición a riesgos ligados a errores, uso indebido o pérdida de control.
Sin embargo, el punto central no es solo cuánto acceso tiene un agente de IA.
El problema real surge en el momento en que se toma una decisión. En ese punto, en la mayoría de los sistemas, no existe una prueba independiente y verificable que permita reconstruir de forma fiable:
- qué decisión se produjo realmente;
- en qué estado se encontraba en el momento del cierre;
- quién asumió la responsabilidad de su validación;
- cuál era el contexto decisional asociado.
El debate actual se centra principalmente en el control de accesos y en la autonomía de los agentes. El Protocolo </AI> aborda, en cambio, un nivel distinto y complementario: la demostrabilidad de la decisión una vez que esta ha sido considerada cerrada.
Dicho de otro modo, no interviene sobre lo que el agente puede o no puede hacer, sino sobre lo que debe ser demostrable después de que la acción se haya realizado.
Este paso es fundamental en contextos de auditoría, responsabilidad y litigio, donde no basta con saber que un sistema estaba bajo control, sino que es necesario poder demostrar qué ocurrió de manera verificable también fuera del sistema que generó la decisión.
¿Es mejor limitar a los agentes de IA o hacer verificables sus decisiones?
En los últimos meses están surgiendo diversas iniciativas orientadas a limitar el acceso y el comportamiento de los agentes de IA, por ejemplo definiendo qué contenidos pueden leer, qué acciones pueden ejecutar o qué contextos deben seguir reservados a los seres humanos.
Este enfoque es importante y responde a una necesidad real: reducir el riesgo antes de que el sistema actúe.
Sin embargo, existe un segundo problema, igualmente crítico, que estas medidas no resuelven.
En el momento en que se toma una decisión, la pregunta pasa a ser:
- qué se decidió exactamente;
- en qué estado se encontraba la decisión en el momento del cierre;
- quién asumió la responsabilidad;
- si existe una prueba independiente y verificable de ese evento.
Limitar lo que un agente puede hacer reduce el riesgo ex ante. Pero no elimina la necesidad de demostrar ex post lo que ocurrió.
El Protocolo se sitúa en este segundo nivel. No interviene sobre el control de acceso o sobre el comportamiento de los agentes, sino sobre la transformación de la decisión en un evento verificable, dotado de identidad, contexto, integridad y referencias temporales.
Los dos enfoques no son alternativos. Son complementarios. El primero reduce la probabilidad de error o abuso. El segundo permite demostrar de forma defendible lo que ocurrió cuando una decisión ya ha sido tomada. En contextos regulados o de alto impacto, ambos se vuelven necesarios.
¿Qué ocurre si un sistema de IA se comporta de forma imprevisible o no alineada?
En los últimos meses han surgido evidencias de que algunos sistemas de IA, en contextos reales, pueden producir comportamientos inesperados, no alineados o difíciles de interpretar. Esto incluye casos en los que el output no refleja las instrucciones recibidas o en los que el sistema adopta estrategias no previstas por el modelo de gobernanza.
Estos escenarios plantean un problema concreto: ya no basta con asumir que el sistema operará siempre de manera previsible o completamente controlable.
En este contexto, la pregunta central cambia. Ya no es solo “¿cómo evitar que el sistema se comporte de forma errónea?”, sino:
- qué se decidió realmente;
- en qué estado se encontraba la decisión en el momento del cierre;
- quién asumió la responsabilidad de su validación;
- si existe una prueba independiente y verificable de todo ello.
El Protocolo no interviene para hacer infalible al sistema de IA o para impedir comportamientos no previstos. Su función es distinta y complementaria: crear un punto externo de toma en carga que haga la decisión demostrable, independientemente del comportamiento interno del sistema que la generó.
¿Quién es responsable si un sistema de IA genera errores o código dañino?
El uso de sistemas de inteligencia artificial no transfiere automáticamente la responsabilidad a la herramienta.
En el ámbito profesional, la responsabilidad sigue recayendo en el sujeto humano que utiliza, valida o aprueba el output generado. Esto también vale en los casos en que la IA produzca resultados inesperados, erróneos o potencialmente dañinos.
El problema, sin embargo, no es solo identificar quién es responsable, sino demostrarlo de manera verificable.
En muchos contextos operativos falta una traza clara que permita reconstruir:
- quién validó el output;
- en qué momento se tomó la decisión;
- en qué estado se encontraba el sistema en el momento de la validación;
- si existe una prueba independiente de la integridad del contenido.
El Protocolo interviene en este punto. A través de un proceso de intake verificable, cada decisión se ancla a: una identidad humana declarada mediante certificado DAPI, un timestamp UTC independiente, una referencia inmutable (hash SHA-256) del contenido y un estado de decisión formalizado.
De este modo, incluso en presencia de errores o comportamientos imprevistos del sistema de IA, es posible demostrar de forma clara y defendible quién asumió la responsabilidad de la decisión final.
¿El sistema impide declaraciones falsas o abusos?
No.
El sistema no nace para impedir declaraciones falsas, sino para hacerlas trazables, verificables e imputables a lo largo del tiempo.
Quien utiliza el sistema puede declarar un contenido, un output o una decisión. Sin embargo, cada declaración queda anclada a elementos objetivos:
- identidad declarada mediante certificado DAPI;
- timestamp UTC independiente;
- huella criptográfica (hash SHA-256) del contenido;
- estado de decisión formalizado;
- eventual certificación FEDIS con código CWC.
Esto significa que una declaración no puede modificarse o negarse posteriormente sin dejar rastro. Si un sujeto declara falsamente algo, y otras evidencias demuestran lo contrario, esa declaración se convierte en un elemento perjudicial para quien la emitió.
En otras palabras, el sistema no impide comportamientos incorrectos, pero los vuelve arriesgados y verificables. Una declaración no verificable puede ser ignorada. Una declaración registrada, identificada y anclada temporalmente puede ser analizada, comparada y, si es necesario, impugnada.
¿En qué punto se encuentra el proyecto?
El framework conceptual y técnico está definido y documentado públicamente. La plataforma aplicativa está operativa y accesible para los titulares de certificado DAPI.
El workflow activo incluye:
- Intake probatorio con hash SHA-256 y timestamp UTC para FILE, ZIP, URL y TEXT
- Solicitud y gestión FEDIS con workflow de aprobación y presupuesto
- Publicación en el registro público EVIDE con identificador único
- Cadena de evidencias verificables entre intakes vinculados
- Gestión multi-organización con perímetros operativos separados
- Facturación por organización con roles owner, admin y member
- Registro público consultable sin autenticación
¿Dónde encontrar más información?
Para un encuadre general del proyecto y de la lógica de IA supervisada puede consultarse la página dedicada al framework:
→ El Protocolo
→ El nivel probatorio en la gobernanza de IA
→ Casos reales de gobernanza de IA
→ Partner Kit para despachos legales y consultores
→ EVIDE – Registro probatorio para contenidos y decisiones digitales