## La verificación de presupuesto está dentro del modelo ¿Le daría su tarjeta de crédito a una IA? Yo lo hice, para este episodio. Lo interesante no es que funcionara, sino el protocolo y la capa de gobernanza que impidieron que gastara demasiado. Este es el problema con el que me encuentro constantemente. La mayoría de los enfoques de pago basados en agentes integran la verificación de presupuesto dentro del LLM: un prompt del sistema que dice "no gastes más de $X". Esto es estructuralmente lo mismo que pedirle a alguien que haga cumplir su propio límite de gasto. El modelo que decide comprar es el modelo que verifica si debe hacerlo. Cuando esos son el mismo componente, no hay un control. Hay una sugerencia. Ahora existe un protocolo abierto dirigido exactamente a este problema: **AP2, el Agent Payments Protocol v0.2**, creado por el equipo A2A de Google y donado a la FIDO Alliance. La acción principal es simple: el mandato reside fuera del agente. Es externo, firmado criptográficamente, y el agente no puede anularlo. El agente opera dentro de un límite que no estableció y no puede modificar. AP2 define una cadena de mandatos, y la cadena es el punto clave: Agente de Compras, Checkout Mandate, Agente del Comerciante, Payment Mandate, Proveedor de Credenciales, Procesador de Pagos. Cada salto es verificable. Ningún salto puede omitirse. Un pago solo ocurre cuando toda la cadena se verifica. ## El escenario: entradas para los cuartos de final de la FIFA 2026 Los protocolos abstractos necesitan una compra concreta, por lo que la demostración es un concierge de compras para el consumidor con un encargo estricto. El usuario firma un mandato: 2 entradas de Categoría 3 para un cuarto de final de la FIFA 2026, por menos de $1,500 cada una, con un límite estricto de $3,200 en total. El agente monitorea TicketVault, un mercado de entradas simulado, durante la noche. No hay presencia humana. Cuando el precio baja, una política de gasto DMN evalúa el carrito en una Tarea de Regla de Negocio de Camunda. Esa evaluación ocurre fuera del modelo, nativamente en Camunda, y su resultado determina todo lo que sigue. Construí tres rutas a través de la misma capa de gobernanza: | Ruta | Disparador | Resultado DMN | Resultado | |---|---|---|---| | Dorada | El precio baja a $1,350, carrito $2,700 | APPROVE | Recibo por $2,700, totalmente autónomo | | HITL | El precio baja a $1,560, carrito $3,120 (97.5% del límite) | HITL_REQUIRED | Aprobación del Departamento de Pagos antes de finalizar la compra | | Incumplimiento del mandato | Compra pendiente de $3,500 excede el límite de $3,200 | DECLINE | Rechazado automáticamente antes de que llegue al procesador | La ruta dorada es la demostración que todos quieren ver: el precio baja a las 3 a.m., el agente compra, un recibo espera por la mañana. Las otras dos rutas son el producto. Un carrito al 97.5% del límite no se aprueba por un tecnicismo; activa a un humano en el Departamento de Pagos. Y una compra por encima del límite no se negocia a la baja con un prompt inteligente; es rechazada por una tabla de reglas antes de que el procesador de pagos se entere. ## La capa de gobernanza La política de gasto DMN consta de cinco reglas, y me gusta que sea aburrida: una verificación de límite, un disparador de límite cercano que dirige cualquier cosa por encima del 95% del mandato a revisión humana, una lista blanca de instrumentos de pago, un límite de velocidad y una aprobación general. Se ejecuta en Camunda como una Tarea de Regla de Negocio, no dentro del LLM. El agente nunca ve la política como texto que podría racionalizar. Ve un resultado de decisión. La tercera capa es el registro de auditoría, y viene de serie con la arquitectura. Cada salto de autorización reside en Camunda Operate: mandato emitido, precio capturado, DMN evaluado, credenciales emitidas, recibo almacenado. Cada decisión, permanentemente, como una instancia de proceso que se puede abrir y reproducir. Nadie escribió código de registro para obtener esto. > El LLM propone. El DMN dispone. Si su política de gasto puede ser modificada por un párrafo bien elaborado, no es una política de gasto. ## Mandatos, no confianza AP2 v0.2 define dos tipos de mandato, y cada uno tiene una etapa abierta y una etapa cerrada. Abierta significa que el usuario pre-firma las restricciones. Cerrada significa que el agente firma la transacción específica que ocurrió dentro de ellas. **El Checkout Mandate.** El usuario pre-firma el alcance del artículo, el precio máximo, un TTL y una lista de comerciantes permitidos. En el momento de la compra, el agente lo cierra con el carrito específico: SKU, precio, hash de checkout. El comerciante verifica el mandato cerrado antes de procesar cualquier cosa. **El Payment Mandate.** El usuario pre-autoriza el instrumento de financiación: el origen, el importe máximo, las restricciones de categoría. El agente lo cierra con el importe exacto y el hash de checkout. El Proveedor de Credenciales verifica ambos mandatos antes de emitir el token de pago. El paso de cierre es donde la criptografía demuestra su valía. Cada mandato está vinculado a una transacción específica mediante una firma ECDSA P-256. Ningún mandato puede ser reutilizado. Ninguno puede ser falsificado. Y cualquier parte en la cadena puede verificar de forma independiente, sin necesidad de una autoridad central. Esa última propiedad es lo que hace de la cadena un protocolo en lugar de una plataforma. Este episodio tiene una pieza complementaria que profundiza mucho más en la mecánica del protocolo, el modelo de amenazas y los modos de fallo: la [AP2 Field Guide](/es/guides/ap2-field-guide/). Si este artículo es el episodio, la guía de campo es el manual. ## Lo que no llegó a la publicación de LinkedIn Este episodio todavía está en desarrollo, por lo que las notas honestas importan más de lo habitual. La demostración simula varios componentes de AP2. El Proveedor de Credenciales y el transporte A2A completo están simulados para fines de demostración; TicketVault es un mercado falso. Lo que es fiel a AP2 v0.2 es la parte que importa para evaluar el protocolo: la estructura del mandato, la lógica de firma (SD-JWT real a través de jose, firmas ECDSA P-256 reales) y las interacciones entre partes. Y la capa de gobernanza no está simulada en absoluto: el BPMN, la política de gasto DMN y el Departamento de Pagos HITL son Camunda 8 real ejecutándose en un clúster SaaS en vivo. Los patrones de mandato también son deliberadamente agnósticos a la pila tecnológica. Camunda es mi motor, pero el mismo flujo de mandato de abrir-luego-cerrar funciona en Temporal, LangGraph, n8n o Node.js puro. El repositorio incluye un documento MAKE_IT_REAL con una ruta de actualización de 5 pasos de esta demostración a AP2 de producción, que cubre exactamente qué componentes simulados se reemplazan y en qué orden. Una nota honesta más: el repositorio es privado hasta que se lance el episodio. Se hará público con el episodio, junto con el video de demostración. La guía de campo ya está disponible, porque el análisis del protocolo no necesita esperar mi cronograma de producción. ## Registro de lanzamiento - **Protocolo:** AP2 v0.2 (Protocolo de Pagos de Agentes, equipo A2A de Google, donado a la FIDO Alliance) - **Motor:** Camunda 8 (clúster SaaS en vivo): orquestación BPMN, política de gasto DMN, Departamento de Pagos HITL - **Modelo:** Claude Sonnet como agente de compras - **Criptografía:** SD-JWT a través de jose, firmas de mandato ECDSA P-256 - **Política:** Tabla de decisión DMN de 5 reglas (límite, HITL por límite cercano del 95%, lista blanca de instrumentos, velocidad, general) - **Frontend:** React con AG-UI sobre SSE, heredado del EP 02 - **Backend:** Node.js - **Complemento:** [AP2 Field Guide](/es/guides/ap2-field-guide/) - **Repositorio:** público cuando se lance el episodio