El consenso llegó rápido. Hace un año, a la pregunta de cómo se audita un agente de IA se respondía con una tabla de base de datos que nadie podía avalar. Hoy el campo converge, por caminos independientes y en la dirección correcta, en algo mejor: firmar las acciones del agente. Se calcula el hash de cada una, se la encadena con la anterior, se sella la cadena con una firma y el auditor recibe un recibo. Ya aparecen protocolos abiertos para esto (por ejemplo, un borrador individual de la IETF), hay implementaciones de referencia (el Agent Governance Toolkit de Microsoft firma cada llamada a una herramienta MCP) y las piezas (una firma, SHA-256, una codificación canónica, un verificador offline) son las mismas en todos lados, aburridas y correctas, también acá. Es un avance, y nada de lo que sigue lo discute.
El problema es que a la palabra firmado se le carga demasiado. En la presentación comercial quiere decir "podés confiar en este registro". Cuando un auditor insiste, se separa en tres garantías distintas que se suelen nombrar como si fueran una sola. Las tres son reales y valen la pena, y cada una tiene su costo. Cuando se las confunde, un buen recibo termina vendido como algo que un evaluador desarma con una sola pregunta.
Las tres afirmaciones
Integridad: "este recibo no se modificó después de emitido, y lo emitió esta clave". Esto es lo que dan la firma y la cadena de hashes. Editar un evento pasado rompe la cadena justo en ese evento, borrar uno deja un hueco en la secuencia, insertar uno rompe el enlace, y una cadena recalculada sin la clave de firma deja de coincidir con los checkpoints firmados. Es una propiedad fuerte, y la mayoría de los sistemas de recibos la tiene. También es la que, sin que nadie lo note, se infla hasta cubrir las otras dos.
Trustlessness: "podés verificar esto sin confiar en quien lo produjo". Esto no sale de una firma. Una firma prueba que una clave firmó esos bytes; no dice nada sobre si quien tiene la clave merece confianza. Si la clave la tiene el proveedor, "firmado por el proveedor" y "confiá en el proveedor" dicen lo mismo con más vueltas. Que la clave la tenga el cliente acota el daño posible (el proveedor firma solo con el acceso que le diste y que podés revocar), pero el operador que tiene la clave igual puede, en principio, reescribir la historia y volver a firmarla. La trustlessness exige un firmante o un ancla que quien lleva el registro no controle: un ledger externo, una parte sin ningún interés en ayudarlo, o una autoridad de sellado de tiempo independiente, que impide antedatar pero detecta una reescritura solo para quien guardó el sello anterior. Mientras no haya algo así en el camino, "verificable" quiere decir "coherente con una clave que tiene el emisor", y quien desconfía del emisor no obtiene más que eso.
Veracidad: "este recibo refleja lo que el sistema hizo". Ninguna criptografía da esta garantía, y es justo la que el comprador suele dar por incluida. Un recibo es una afirmación sobre una acción. Firmarlo la vuelve tamper-evident, pero no la vuelve verdadera. Si el recibo se arma a partir de algo que no es la ejecución real (una observación, una descripción posterior, un resumen optimista), tenés un registro perfectamente firmado y verificable de algo que puede no coincidir con lo que pasó. La veracidad depende de a partir de qué se genera el recibo.
Una prueba para cualquier recibo
Cada afirmación tiene una prueba de una línea, y preguntar no cuesta nada.
Para la integridad: si alguien edita un registro pasado, ¿el verificador falla justo en ese registro, offline, en una máquina que controlás vos? Para la trustlessness: ¿quién tiene la clave, y quien produjo el registro puede volver a firmarlo? Si la tiene el emisor y puede volver a firmar, tenés integridad sin trustlessness, diga lo que diga el marketing. Para la veracidad: ¿el recibo lo escribe el sistema como parte de la acción misma, o algo que lo mira desde afuera?
La mayoría de los sistemas de recibos pasa la primera sin problemas. Los honestos te dicen claramente qué ofrecen en la segunda. La tercera casi nadie la nombra, y es la que decide si el registro es evidencia o una opinión firmada.
Observado en el borde, o escrito con la acción
La veracidad depende de una decisión de diseño fácil de pasar por alto, porque cualquiera de las dos opciones produce un recibo firmado válido.
Una registra el recibo en el borde de la llamada a la herramienta: un proxy o un hook entre el agente y sus herramientas que captura cada llamada al pasar. Es portable y no depende del agente: funciona con cualquier framework, cualquier modelo y cualquier runtime, porque observa la unión entre las piezas en vez de vivir dentro del motor. Un registro atado a un runtime no tiene esa ventaja. Lo que atestigua un recibo de borde, dicho con precisión, es que el borde vio pasar esta llamada.
La otra escribe el recibo como parte de la ejecución. Acá, el evento encadenado es el propio registro de transición de la máquina de estados, confirmado en la misma transacción de base de datos que el estado de la propia máquina: se escriben los dos o ninguno, así que el registro encadenado y el estado de la máquina no pueden contar dos historias distintas. El costo es el inverso de la ventaja del borde: este registro es propio del runtime que lo emite, y ningún otro agente puede producirlo.
Ninguna es mejor en todo. Una resigna fidelidad a cambio de portabilidad, y la otra, al revés. El error es dejar que un recibo de borde use el lenguaje del otro tipo y dé a entender que prueba lo que hizo el sistema. Prueba lo que vio el borde, y muchas veces con eso alcanza; la diferencia pesa cuando lo que está en discusión es justamente qué hizo el sistema.
Los límites, dichos con honestidad
La integridad es tamper-evident. Un operador con privilegios igual puede modificar una fila encadenada, y quien la verifique contra el checkpoint firmado que la cubre lo va a detectar, salvo que quien la modificó tenga también la clave de firma (el punto siguiente). Quien llama "inmutable" o "a prueba de manipulación" a un almacenamiento en el que un operador puede escribir está vendiendo de más.
La trustlessness depende de dónde está la clave, y lo decimos. Si operás el deployment vos, el operador sos vos: la clave de firma es una clave de KMS en tu propia cuenta de AWS, el proveedor no tiene ningún material de firma y "verificable sin confiar en el proveedor" es literal. (Ese deployment se lo ofrecemos a design partners; todavía no corrió en producción.) Si lo aloja un proveedor, la afirmación honesta se reduce a tamper-evident y verificable de forma independiente y offline, porque un operador con privilegios podría reescribir y volver a firmar antes de que un tercero guarde un checkpoint. Un deployment de producción además tiene que sellar sus checkpoints con una autoridad de sellado de tiempo RFC 3161 independiente, y el verificador informa si el bundle trae esa ancla; uno que no la trae aparece como "self-asserted time only" (hora autodeclarada). El ancla impide antedatar un registro, pero una reescritura solo queda expuesta para quien ya tenga un sello anterior, así que la brecha del modo alojado se achica y sigue abierta.
La veracidad sale de cómo se genera el registro, y llega hasta donde el sistema registró. Un registro escrito con la acción prueba que coincide con lo que el sistema hizo con esa acción. No puede dar fe de un evento que el sistema nunca emitió. Acá, una transición de la máquina de estados y su evento encadenado se confirman en una sola transacción; el evento de un paso de flow se escribe justo después de que el paso se confirma, así que puede perderse una escritura, y cuando pasa se cuenta y queda en el log (y, en los flows que declaran una restricción de audit trail, se informa); los rechazos y lo que rechaza un binding se registran fuera de la cadena. Es fidelidad entre registro y comportamiento, acotada a lo que el sistema emitió.
Lo que está en juego
Un recibo firmado alcanza para un cuestionario de compliance. Las tres preguntas son para un adversario, y el adversario tarde o temprano llega: un auditor que reconstruye un incidente, o tus propios abogados decidiendo si ponen el registro delante de un regulador. Si está firmado es lo de menos; lo que preguntan es alguna versión de las tres juntas: ¿puedo verificar esto sin confiar en vos, pudiste haberlo cambiado, y es lo que el sistema hizo? Un registro que mezcla las tres tiene una sola respuesta para tres preguntas y se cae en la primera repregunta. Uno que las separa (esto es integridad, esto depende de quién tiene la clave, esto sale de la ejecución) suena menos contundente de entrada y tiene respuesta para cada repregunta.
Los verificadores son open source, con licencia Apache-2.0, y están en npm (@zarel-ai/audit-chain, @zarel-ai/audit-tsa). En Cómo funciona están los comandos que un auditor corre contra el bundle de un deployment y los veredictos que pueden devolver. Todavía no hay un deployment público contra el cual correrlos.
Este artículo afina la parte de la prueba de un argumento más amplio: la comunicación y la propuesta pueden ser probabilísticas, pero la autoridad, la consecuencia, el compliance y el registro de las tres tienen que ser determinísticos, declarados y verificables. El argumento general está en No se combate el probabilismo con probabilismo; el de la aplicación estructural, en El agente propone; el runtime aprieta el botón; el del registro, en Una auditoría en la que no hace falta confiar. Este es sobre qué puede querer decir "verificable".
Nicolás Moreno construye Zarel: operaciones de IA gobernadas, donde la IA propone y el contrato dispone.