Pagos agénticos bajo política humana

Los pagos agénticos son pagos iniciados por software y no por una persona en un checkout. Un agente de IA posee credenciales, decide que debe hacerse una compra y mueve el dinero él mismo: paga una factura, renueva una suscripción, reserva un chárter, sin que un humano pulse el botón final. El hecho distintivo es quién inicia el pago. Una persona que pulsa comprar es un pago con tarjeta corriente con un chatbot delante; un pago agéntico es software que decide, autoriza y liquida en el momento en que el dinero se mueve. Todo lo difícil de esta categoría se deriva de esa propiedad: quien gasta no es una persona, y no se cansa, ni desconfía, ni se pone nervioso como lo haría una persona antes de transferir dinero a un desconocido.

Por eso la pregunta interesante nunca fue si los agentes gastarán dinero —ya pueden hacerlo—, sino quién fija las reglas bajo las que gastan y si esas reglas las hace cumplir la plataforma o simplemente las promete el agente.

El modo de fallo es evidente, y ese es el punto

Dale a un agente una credencial de pago activa y ningún tope, y habrás construido un incidente de fraude por transferencia que aún no ha ocurrido. La forma de fallar no es exótica. Una inyección de prompt oculta en una página web ordena al agente pagar a un atacante. Una descripción de herramienta mal formada dirige una compra legítima al destinatario equivocado. Un bucle de reintentos intenta el mismo cargo mil veces porque la señal de éxito nunca llegó. Nada de esto requiere un adversario ingenioso: son los errores habituales del software autónomo, salvo que el resultado es dinero saliendo de tu cuenta.

La solución tentadora es hacer al agente más cuidadoso: un mejor prompt de sistema, una instrucción más severa, un modelo que razone más sobre el gasto. Eso sitúa el control en el lugar menos fiable del sistema: el propio razonamiento del agente, justo lo que se le puede convencer de abandonar. Un presupuesto que un agente puede rebatir no es un presupuesto. El control tiene que vivir donde el agente no llegue, es decir, completamente fuera de él.

La política es el producto, no el prompt

El modelo de contención es una política que la plataforma aplica antes de que el dinero se mueva, no después de que el agente haya decidido. Cada agente tiene un tope por transacción y un límite diario —150,00 € por pago y 500,00 € al día en nuestra política de demo—, con un techo mensual de 6.000,00 € por encima. Son muros infranqueables que comprueba la plataforma, no promesas que cumple el agente. Cuando el bot de viajes de la demo intentó contratar un chárter por 640,00 €, el pago se denegó al instante: por encima del tope, antes de mover un solo céntimo. Un agente que se comporta perfectamente cada día sigue sin poder rebasar lo que permite el mes.

Un presupuesto dice cuánto; una lista de permitidos dice adónde. Los agentes solo pagan a los comercios que has nombrado de antemano. El Ops Agent de la demo conoce exactamente cuatro, y un intento de 180,00 € a un proveedor no incluido en la lista se rechazó por no figurar. Juntos, ambos trazan una caja: esta cantidad de dinero, solo a estos destinatarios. Dentro de la caja, el agente funciona a pleno rendimiento y nunca tiene que pedir permiso; la caja es lo que pertenece a una persona.

La cuestión nunca es si un agente de IA gastará dinero. Es quién escribió las reglas bajo las que gasta, y la respuesta debería ser siempre una persona, de antemano y por escrito.

Una persona por encima de la línea

Algunas decisiones son demasiado grandes para dejarlas a una caja. Por eso la política incluye un umbral: un importe a partir del cual una persona debe aprobar antes de que el pago se ejecute. En la demo, la línea está en 100,00 €. Cuando el Ops Agent marcó la factura #088 de Nord Logistics —120,00 €, holgadamente dentro de su presupuesto diario de 500,00 € pero por encima de la línea de aprobación—, no pagó. Hizo una pausa, puso la propuesta ante una persona y esperó. Una respuesta de una línea la desbloqueó; el pago se liquidó con la referencia 9F21-0716 y quedó en el registro de auditoría a las 09:41. Por debajo de la línea, el agente actúa por su cuenta; por encima, primero responde una persona.

La aprobación no es una casilla que se evapora. Registra quién aprobó, en qué dispositivo, a qué hora y con qué firma adjunta: aprobado en la app, clave del teléfono, 09:41:12. Cuando alguien pregunta después por qué se hizo un pago, la respuesta es una persona con nombre y una marca de tiempo, no un encogimiento de hombros.

Un kill-switch y un registro que no se puede editar en silencio

Incluso con buenos muros, los agentes se portan mal y las políticas resultan erróneas. Dos controles se ocupan de ello. El primero es un kill-switch: un toque pausa a un agente y detiene al instante todos los pagos que pueda iniciar. Las claves siguen siendo válidas para que nada más se rompa: el agente simplemente no puede gastar hasta que una persona lo reactive, y sus propuestas pendientes quedan congeladas en lugar de desaparecer. En la flota de la demo, el bot de viajes está en pausa con 0,00 € gastados y su cola intacta.

El segundo es un registro de auditoría de solo anexado. Cada decisión queda registrada: qué intentó el agente, qué control de política se superó o falló, quién aprobó qué, hasta las rotaciones de claves. Un solo registro reconstruye un pago completo: la decisión DEC-4471 muestra la solicitud, cada control de política con su resultado (lista de permitidos superada, límite superado, umbral con escalado), la firma humana y el importe liquidado con su rail y su referencia. Cada entrada lleva su propio hash, el hash de la entrada anterior y su posición en la cadena (la n.º 4,471 en la demo), de modo que modificar cualquier campo rompe todos los registros posteriores. El registro se exporta en JSON, con el hash incluido: es tuyo para entregárselo a un auditor, no nuestro para guardarlo.

Liquidación aburrida; la novedad, en la autorización

Existe la tentación de que los pagos agénticos sean nuevos de arriba abajo: un rail nuevo, un instrumento nuevo, una forma nueva de mover el dinero. Resístela. Lo realmente nuevo es la autorización: cómo demuestra un agente que puede pagar, bajo la política de quién y con qué aprobación. Una vez que un pago supera esa puerta, debe liquidarse en rails que llevan años siendo aburridos. En la demo, una propuesta aprobada de 120,00 € se convierte en una transferencia SEPA ordinaria, liquidada por SEPA Instant minutos después de la aprobación, e indistinguible aguas abajo de un pago hecho por una persona. Al banco no le consta ni le importa que lo haya iniciado un agente.

Esta separación es deliberada. Los rails aburridos son predecibles, reversibles cuando el esquema lo permite y los entiende cualquier tesorería y cualquier auditor con quien vayas a tratar. Poner la novedad en la política y el pago en un rail consolidado significa que la parte arriesgada y cambiante es la que controlas por completo, y la parte que toca los bancos de otros es la que nadie tiene que volver a aprender. Los agentes gastan desde el mismo core sobre el que funciona el resto de la familia de pagos, descrito en /products/pay, y no desde un universo paralelo construido para robots.

El panorama de protocolos no está definido: construye pensando en ello

Cómo debe presentar un agente su identidad y su mandato ante un comercio es una cuestión abierta. Varias propuestas compiten por definir cómo demuestra un agente quién es, qué está autorizado a comprar y cómo lo verifica el comercio antes de aceptar el dinero. Ninguna se ha impuesto, y apostarlo todo a una sola hoy sería prematuro. La postura defensiva es tratar el protocolo de autorización como intercambiable y mantener estable todo lo que hay detrás: el motor de políticas, el modelo de auditoría y el rail de liquidación no cambian cuando cambia el formato de intercambio del frontal.

En la práctica, eso significa una superficie de integración pequeña y aburrida. Los agentes se conectan por MCP en mcp.protocore.io/agents; cualquier framework que hable el protocolo puede tener un wallet. La interfaz es deliberadamente estrecha (proponer un pago, recibir una decisión) porque la lógica interesante vive en la plataforma, no en el prompt. Cuando el sector se ponga de acuerdo sobre cómo se acreditan los agentes ante los comercios, cambiará el frontal y los muros de detrás seguirán exactamente donde estaban.

Dónde encaja esto

Los pagos agénticos no son la apuesta de que el software autónomo deba gastar sin límite. Son lo contrario: la apuesta de que el software gastará, así que más vale que los límites sean reales, externos y legibles. Los presupuestos y las listas de permitidos dibujan el perímetro, un umbral deriva las decisiones importantes a una persona, un kill switch lo detiene todo y un registro de solo anexado permite reconstruir cualquier pago después. La página de producto /products/agents recorre todo el ciclo con los datos de demo usados aquí (crear un agente, fijar su política, ver cómo un pago escala y se liquida) y /products/pay es el core sobre el que se ejecutan esos pagos. La autonomía es real; también lo es la correa, y la sujeta una persona.