Notes de camp

Pagaments agèntics sota política humana

Els pagaments agèntics són pagaments iniciats per programari i no per una persona en un checkout. Un agent d'IA té credencials, decideix que s'ha de fer una compra i mou ell mateix els diners: paga una factura, renova una subscripció, reserva un xàrter, sense que cap humà premi el botó final. El fet diferencial és qui l'inicia. Una persona que clica comprar és un pagament amb targeta ordinari amb un xatbot al davant; un pagament agèntic és programari que decideix, autoritza i liquida en el moment en què els diners es mouen de debò. Tot el que és difícil en aquesta categoria se segueix d'aquesta única propietat: qui gasta no és una persona, i no es cansa, no desconfia ni s'inquieta com ho faria una persona abans de fer una transferència a un desconegut.

Per això la pregunta interessant mai no va ser si els agents gastaran diners —ja ho poden fer—. La pregunta és qui fixa les regles sota les quals gasten, i si aquestes regles les fa complir la plataforma o simplement les promet l'agent.

El mode de fallada és evident, i aquest és el punt

Doneu a un agent una credencial de pagament activa i cap límit, i haureu construït un incident de frau per transferència que encara no ha passat. La manera com es torça no és exòtica. Una injecció de prompt amagada en una pàgina web diu a l'agent que pagui un atacant. Una descripció d'eina mal formada dirigeix una compra legítima al destinatari equivocat. Un bucle de reintents intenta el mateix càrrec mil vegades perquè el senyal d'èxit no va tornar mai. Cap d'aquests casos requereix un adversari enginyós: són els errors ordinaris del programari autònom, tret que el resultat són diners que surten del vostre compte.

La solució temptadora és fer l'agent més cautelós: un millor prompt de sistema, una instrucció més severa, un model que raoni més a fons sobre la despesa. Això posa el control al lloc menys fiable del sistema: el raonament de l'agent, justament el que el pot fer canviar d'idea. Un pressupost que un agent pot esquivar amb arguments no és un pressupost. El control ha de viure en un lloc que l'agent no pugui abastar, és a dir, completament fora de l'agent.

La política és el producte, no el prompt

El model de contenció és una política que la plataforma fa complir abans que els diners es moguin, no després que l'agent hagi decidit. Cada agent té un topall per transacció i un límit diari —€150.00 per pagament, €500.00 al dia a la nostra política de demo—, amb un sostre mensual de €6,000.00 per sobre. Són parets dures que verifica la plataforma, no promeses que compleix l'agent. Quan el bot de viatges de la demo va intentar contractar un xàrter per €640.00, el pagament es va denegar a l'acte: per sobre del topall, abans que es mogués ni un cèntim. Un agent que es comporta perfectament cada dia continua sense poder desviar-se de l'import que el mes permet.

Un pressupost diu quant; una llista de permesos diu on. Els agents només paguen els comerços que heu indicat per endavant. L'Ops Agent de la demo en coneix exactament quatre, i un intent de €180.00 a un proveïdor no inclòs es va rebutjar com a no llistat. Junts dibuixen una caixa: aquests diners, només a aquests destinataris. Dins la caixa l'agent va a tota velocitat i no ha de demanar mai res; la caixa és el que posseeix un humà.

La pregunta mai no és si un agent d'IA gastarà diners. És qui ha escrit les regles sota les quals gasta, i la resposta hauria de ser sempre un humà, per endavant i per escrit.
— Protocore · Enginyeria d'Agents

Un humà per sobre de la línia

Algunes decisions són massa grans per deixar-les a una caixa. Per això la política porta un llindar: un import a partir del qual un humà ha d'aprovar abans que el pagament es faci. A la demo la línia és a €100.00. Quan l'Ops Agent va marcar la factura #088 de Nord Logistics —€120.00, còmodament dins del seu pressupost diari de €500.00 però per sobre de la línia d'aprovació—, no la va pagar. Es va aturar, va posar la proposta davant d'una persona i va esperar. Una resposta d'una línia la va desbloquejar; el pagament es va liquidar amb la referència 9F21-0716 i va quedar al registre d'auditoria a les 09:41. Per sota de la línia l'agent actua pel seu compte; per sobre, primer respon una persona.

L'aprovació no és una casella que s'esvaeix. Registra qui ha aprovat, des de quin dispositiu, a quina hora i amb quina signatura: aprovat a l'app, clau del telèfon, 09:41:12. Quan algú pregunta més endavant per què s'ha fet un pagament, la resposta és una persona amb nom i una marca de temps, no una arronsada d'espatlles.

Un interruptor d'aturada i un registre que no es pot editar d'amagat

Fins i tot dins de bones parets, els agents es porten malament i les polítiques resulten errònies. Dos controls s'hi encarreguen. El primer és un interruptor d'aturada: un toc atura un agent i bloqueja a l'instant tots els pagaments que pugui iniciar. Les claus continuen sent vàlides perquè res més no es trenqui: l'agent simplement no pot gastar fins que un humà el torni a activar, i les seves propostes pendents queden congelades al lloc en comptes de desaparèixer. A la flota de la demo, el bot de viatges està en pausa amb €0.00 gastats i la cua intacta.

El segon és un registre d'auditoria append-only. Cada decisió hi queda anotada: què ha intentat l'agent, quina comprovació de política s'ha superat o ha fallat, qui ha aprovat què, fins i tot les rotacions de claus. Un sol registre permet reconstruir un pagament sencer — la decisió DEC-4471 mostra la sol·licitud, cada comprovació de política amb el seu resultat (llista de permesos superada, límit superat, llindar escalat), la signatura humana i l'import liquidat amb la seva via i referència. Cada entrada porta el seu propi hash, el de l'entrada anterior i la seva posició a la cadena — la #4,471 a la demo — de manera que editar qualsevol camp invalida tots els registres posteriors. El registre s'exporta en JSON, hash inclòs: és teu per lliurar-lo a un auditor, no nostre per guardar-lo.

Que la liquidació sigui avorrida; la novetat, a l'autorització

Hi ha la temptació de fer que els pagaments d'agents siguin nous de dalt a baix — una via nova, un instrument nou, una manera nova de moure els diners. Resisteix-te. La part realment nova és l'autorització: com demostra un agent que té permís per pagar, sota quina política i amb quina aprovació. Quan un pagament supera aquesta porta, ha de liquidar-se per vies que fa anys que són avorrides. A la demo, una proposta aprovada de 120,00 € es converteix en una transferència SEPA ordinària — liquidada per SEPA Instant minuts després de l'aprovació — indistingible, aigües avall, d'un pagament fet per una persona. El banc no sap ni li importa que l'hagi iniciat un agent.

Aquesta separació és deliberada. Les vies avorrides són previsibles, reversibles quan l'esquema ho permet, i les entén qualsevol tresoreria i qualsevol auditor amb qui tractaràs mai. Posar la novetat a la política i el pagament en una via ja consolidada vol dir que la part arriscada i canviant és la que controles del tot, i que la part que toca els bancs dels altres és la que ningú ha de tornar a aprendre. Els agents gasten del mateix nucli sobre el qual funciona la resta de la família de pagaments — descrit a /products/pay — no d'un univers paral·lel construït per a robots.

El panorama dels protocols encara no s'ha assentat: construeix-hi pensant

Com ha de presentar un agent la seva identitat i el seu mandat a un comerç és una qüestió oberta. Diverses propostes competeixen sobre com demostra un agent qui és, què té autorització per comprar i com ho verifica el comerç abans d'acceptar els diners. Cap no ha guanyat, i apostar-ho tot a una de sola avui seria prematur. La postura defensiva és tractar el protocol d'autorització com a intercanviable i mantenir estable tot el que hi ha al darrere: el motor de polítiques, el model d'auditoria i la via de liquidació no canvien quan canvia el format de transmissió de la façana.

A la pràctica, això vol dir una superfície d'integració petita i avorrida. Els agents es connecten per MCP a mcp.protocore.io/agents; qualsevol framework que parli el protocol pot tenir una cartera. La interfície és deliberadament estreta — proposar un pagament, rebre una decisió — perquè la lògica interessant viu a la plataforma, no al prompt. Quan la indústria es posi d'acord sobre com es demostren els agents davant dels comerços, canviarà la façana i els murs del darrere es quedaran exactament on eren.

On encaixa tot plegat

Els pagaments d'agents no són una aposta perquè el programari autònom gasti sense límit. Són el contrari: una aposta que el programari gastarà, i per tant els límits més val que siguin reals, externs i llegibles. Els pressupostos i les llistes de permesos dibuixen la caixa, un llindar envia les decisions grans a una persona, un interruptor d'emergència ho atura tot, i un registre append-only permet reconstruir més endavant cada pagament. La pàgina de producte a /products/agents recorre tot el cicle amb les dades de demostració d'aquí — crear un agent, definir-ne la política, veure com un pagament s'escala i es liquida — i /products/pay és el nucli sobre el qual funcionen aquests pagaments. L'autonomia és real; la corretja també, i la té una persona.

Tens un sistema per construir?

Explica'ns el problema. Et respondrem amb una arquitectura i un pla.