Compromisos verificables de agentes de IA: demo de un agente de reembolsos
Los logs de tu agente de IA te dicen qué hizo. No te dicen qué prometió.
Parece una diferencia pequeña hasta que hay dinero de por medio. Un agente le dice a un cliente «te devolvemos tus 750 €». ¿Quién lo autorizó? ¿Esa promesa sigue siendo válida? Y si alguien edita la base de datos la semana que viene, ¿se daría cuenta alguien?
Si estás:
- poniendo agentes de IA delante de clientes,
- dejando que los agentes muevan dinero o hagan ofertas,
- o eres responsable de auditar lo que hacen esos agentes,
este es el primer problema con el que te vas a encontrar.
He construido una pequeña demo para hacerlo tangible: un agente de soporte con IA cuyas promesas de reembolso se convierten en compromisos verificables. Es el ejemplo del reembolso de 750 € de mi serie sobre SITP, convertido en algo que puedes recorrer con clics.
Los logs registran acciones. Los compromisos necesitan recibos.
Una línea de log se ve así:
2026-11-03 11:41:54 refund-agent called offer_refund(order=88231, amount=750)
Responde a una sola pregunta: ¿qué pasó?
No responde a las preguntas que importan cuando un cliente, un auditor o tu equipo de finanzas viene a preguntar:
- ¿Quién es responsable de cumplir esta promesa?
- ¿Bajo la autoridad de quién la hizo el agente?
- ¿En qué estado está ahora: ofrecida, aceptada, pagada, en disputa?
- ¿Alguien ha tocado el registro desde que se escribió?
Los logs se pueden modificar, son privados y los escribe el mismo sistema que intentas auditar.
Eso no es un recibo. Es un diario.
El cambio de enfoque: tratar cada promesa como un objeto
SITP (el protocolo de Staplit) trata un compromiso como un objeto de primer nivel llamado Staple. Un Staple tiene:
- un owner (quien lo debe) y una contraparte (a quien se le debe),
- la autoridad bajo la que se hizo,
- un ciclo de vida con estados definidos,
- y un historial firmado y encadenado por hashes que cualquiera puede verificar.
La demo aplica esa idea a un trabajo concreto: gestionar tickets de reembolso de una tienda online ficticia, Northwind Gear.
Una nota sobre el alcance. Es una demo educativa. El comportamiento de SITP se ejecuta en una pequeña simulación local que escribí para ella, no en el relay oficial de Staplit. Usa los nombres de estado oficiales de SITP (
ISSUED,ACTIVE,RETURNED,DISPUTED,RESOLVED...), pero las reglas de transición son propias de la demo.
Cómo funcionan los compromisos verificables de un agente de IA en la demo
La regla central es simple: el agente nunca escribe directamente en el ledger. Pregunta, y el ledger decide.
Cada vez que el agente intenta crear o cambiar un compromiso:
- El agente llama a una herramienta, por ejemplo
offer_refund. - El ledger comprueba el certificado del agente: sponsor humano, operaciones permitidas, límite de gasto, dominio y caducidad.
- Comprueba que el cambio de estado es legal y que lo está haciendo la parte correcta.
- Solo entonces añade una entrada, firmada por la parte que la envió y por el relay, y encadenada al hash de la entrada anterior.
Las acciones rechazadas nunca se escriben. La legalidad se impone en el momento de escribir, no se reconstruye después.
👉 ¿Quieres ver cómo enfoca Staplit los compromisos de los agentes de IA? Empieza en staplit.ai.
El agente toma prestada su autoridad de una persona
El agente no tiene autoridad propia. La toma prestada de una persona con nombre: Laura Gómez, responsable de Finance Ops.
Este es el certificado con el que trabaja el agente:
{
"id": "cert_refunds-02",
"agent": "agent:refunds-02",
"sponsor": "human:laura.gomez",
"operations": ["commitments.read", "refund.offer", "review.offer"],
"fiscalCap": { "perAction": 1000, "currency": "EUR" },
"domain": { "counterpartyPrefix": "customer:", "regions": ["EU"] },
"expires": "2027-02-01"
}
Emitirlo es una entrada del ledger firmada por Laura. Revocarlo, también. Si es válido o no se calcula siempre a partir del ledger, nunca a partir de un flag que alguien pueda cambiar en una base de datos.
Las herramientas del agente
El agente en sí es corriente. Puede funcionar con Claude usando tool use o como un script fijo, y tiene cuatro herramientas:
lookup_order // store data: item, amount, delivery status
list_customer_commitments // existing Staples for this customer (needs a valid certificate)
offer_refund // creates a Staple. Rejected above the fiscal cap
offer_human_review // commits to a human review instead. Moves no money
Lo interesante no es el agente.
Es lo que pasa entre el agente y el ledger.
El recorrido: 6 escenarios en 5 minutos
1. El agente ofrece un reembolso de 750 €
Tom ha devuelto su portátil y quiere su dinero. El agente busca el pedido, revisa los compromisos que ya existen para no reembolsar dos veces y ofrece el reembolso.
Se crea un Staple en estado ISSUED:
El compromiso también se expresa en una sola línea de operadores SITP:
Refund €750 for order 88231 &refunds-02(2026-11-08) &&laura.gomez &$750 ^2 *support-refunds
Leído en voz alta: refunds-02 es responsable de «Refund €750 for order 88231» antes del 2026-11-08, moviendo 750 EUR, con urgencia 2, en el flujo de trabajo support-refunds. laura.gomez observa cada evento.
| Operador | Significado |
|---|---|
| &party(deadline) | Quién lo debe, y para cuándo |
| &&party | Observador: recibe cada evento |
| &$amount | El dinero se mueve con el compromiso |
| ^1–5 | Urgencia |
| *tag | Flujo de trabajo |
2. El agente intenta aceptar en nombre del cliente
¿Y si el agente, «para ayudar», acepta su propia oferta?
Rechazado. Solo la contraparte puede aceptar un compromiso que se ha hecho con ella. Nada llega al ledger.
Este es el tipo de error que se cuela cuando la regla vive en un prompt. Aquí vive en el camino de escritura.
Cuando Tom acepta, el Staple pasa de ISSUED a ACTIVE, la tienda paga y el agente registra ACTIVE → RETURNED. Cada paso es su propia entrada firmada, hecha por la parte que tiene permiso para hacerla:
3. Un reembolso de 1.800 € choca con el límite
El sofá de Amira nunca llegó. Quiere que le devuelvan 1.800 €.
El agente intenta offer_refund. El ledger lo rechaza: 1.800 € supera el límite de 1.000 € fijado en el certificado.
El agente no discute, y no divide el reembolso en dos más pequeños. Hace lo único que tiene autorizado: comprometerse a una revisión humana en 24 horas. Esa promesa también es un Staple, con su propio owner, plazo y estado.
El cliente recibe una respuesta honesta. Finanzas recibe un compromiso que puede seguir.
4. Cualquiera puede verificar, sin iniciar sesión
Cada Staple tiene una página de verificación pública. Sin cuenta, sin credenciales.
Muestra tres cosas:
- que el compromiso existe,
- que su registro está intacto (los hashes y las firmas cuadran),
- y su estado actual.
No muestra los términos. El importe, el pedido y el motivo solo los pueden leer las partes.
El sello es público. El contenido, no.
5. Alguien edita la base de datos
Ahora la prueba incómoda. Alguien con acceso a la base de datos cambia en silencio el reembolso de 750 € a 75 €, sin tocar los hashes ni las firmas (no puede volver a firmar como si fuera otra persona).
Abre otra vez el mismo enlace de verificación:
El registro ya no coincide con su cadena de hashes. La verificación falla justo en la entrada editada. Con una tabla de logs normal, esta edición habría sido invisible.
6. La revocación tiene efecto inmediato
Último escenario. Laura pausa el agente revocando su certificado. La revocación es en sí misma una entrada firmada del ledger.
Entonces Jonas abre un ticket porque las zapatillas no son de su talla:
El agente ya no puede crear compromisos, y ni siquiera puede leer los que existen. Le dice al cliente que un compañero se encargará.
Sin accesos fantasma. Sin «el token seguía en caché en algún sitio».
Ideas clave
- Un log dice qué hizo un agente. Un compromiso dice qué prometió, bajo la autoridad de quién, y permite a cualquiera comprobar que no ha cambiado.
- Pon las reglas en el camino de escritura, no en el prompt. Los límites, los roles y la revocación funcionan porque el ledger rechaza las acciones ilegales antes de escribirlas.
- La verificación no debería depender de la colaboración de nadie. Integridad pública, términos privados.
Reflexión final
Los agentes de IA van a hacer promesas en nuestro nombre: reembolsos, compras, plazos, reservas.
La pregunta no es si se van a equivocar.
Es si vamos a poder demostrar a qué se comprometieron.
Esta es la primera de cinco demos que estoy construyendo alrededor de SITP. La siguiente: un agente que compra en nombre de una empresa, y qué pasa con su acceso cuando se le retira la autoridad.
Si tus agentes ya hacen promesas a clientes, proveedores o socios, merece la pena saber cómo se les va a pedir cuentas. Descubre más sobre Staplit y SITP en staplit.ai.
Preguntas frecuentes
❓ ¿Qué es un compromiso verificable de un agente de IA?
✅ Es una promesa hecha por un agente de IA que se registra como un objeto estructurado con un owner, una contraparte, la autoridad bajo la que se hizo y un ciclo de vida. Cada cambio se firma y se encadena, así que cualquiera puede comprobar que el registro existe, está intacto y en qué estado se encuentra.
❓ ¿En qué se diferencia un compromiso de un log de un agente de IA?
✅ Un log registra lo que hizo el agente, suele ser privado y lo puede editar quien gestiona el sistema. Un compromiso registra lo que el agente prometió y bajo la autoridad de quién, y un tercero puede comprobar su integridad sin acceso a tus sistemas.
❓ ¿Qué es SITP?
✅ SITP es el protocolo de Staplit para registrar compromisos entre personas, empresas y agentes de IA. Cada compromiso es un Staple con estados definidos como ISSUED, ACTIVE, RETURNED, DISPUTED y RESOLVED. Puedes leer más en staplit.ai.
❓ ¿Cómo evitas que un agente de IA haga promesas que no tiene permitidas?
✅ Dale al agente un certificado prestado por un sponsor humano con nombre, con operaciones permitidas, un límite de gasto, un dominio y una caducidad, y compruébalo antes de escribir nada. En la demo, un reembolso de 1.800 € se rechaza porque el límite es de 1.000 €, y el agente se compromete a una revisión humana.
❓ ¿Qué pasa cuando revocas el acceso de un agente de IA?
✅ En la demo, la revocación es en sí misma una entrada firmada del ledger y tiene efecto inmediato. El agente ya no puede crear compromisos ni leer los existentes, así que no queda ningún acceso residual.
❓ ¿Esta demo es la implementación oficial de Staplit?
✅ No. Es una demo educativa que simula el comportamiento de SITP en local. Usa los nombres de estado oficiales de SITP, pero las reglas de transición se escribieron para esta demo.
¿Buscas contenido técnico para tu empresa? Escribo artículos y demos prácticas como esta para herramientas y APIs para desarrolladores. Escríbeme.