Contracte mínim per a un agent IA en producció (4 condicions no-negociables)

La majoria d’implementacions d’agents IA no fallen per la tecnologia. Fallen perquè no hi havia contracte d’inici.

Amb “contracte” no volem dir un document legal. Volem dir: un conjunt de condicions concretes que han de ser certes abans d’activar l’agent sobre dades i processos reals d’un negoci. Sense aquestes condicions, el que es posa en marxa no és un agent en producció. És un experiment a càrrec del client.

A serpixel (Clever European Business, S.L.) tenim quatre condicions no-negociables que verifiquem abans de signar qualsevol implementació. No les posem per protegir-nos: les posem perquè és l’única manera de garantir que el que lliurem funciona quan importa i es pot aturar quan falla.

Condició 1: un agent, un workflow, una mètrica

El primer punt de fallada de gairebé totes les implementacions és el scope. No la tecnologia, no el model, no les integracions: el scope.

Quan un projecte comença amb “volem un agent per a l’atenció al client” sense especificar molt més, el que tenim és una intenció, no un projecte. Un procés vague no es pot implementar de manera productiva. I, el que és pitjor, no es pot fallar de manera detectada: un agent amb scope difús falla silenciosament, i ningú sap quan.

La pregunta de filtre és concreta: quina mètrica canviarà la setmana quatre?

Si la resposta és “millorar l’atenció al client” o “ser més eficients”, no és una resposta: és una aspiració. La resposta que acceptem és d’un altre tipus: “el percentatge d’esborranys de comanda acceptats sense edició humana passarà del 0% actual al 70% en quatre setmanes.” O: “el temps mig de primera resposta a correus de suport passarà de 6 hores a menys de 30 minuts.”

Amb una mètrica d’aquest tipus, el projecte té forma. Podem definir casos d’èxit, casos límit i condicions de fallada. Podem dissenyar un harness d’avaluació. Podem saber si l’agent funciona o no.

Sense ella, estem fent un projecte de recerca, i ningú ha explicat al client que ell paga per la recerca.

Condició 2: interoperabilitat verificable via MCP

Un agent que no toca les eines del negoci no és un agent. És un chatbot car.

La distinció és funcional. Un chatbot conversa. Un agent executa accions reals: llegir un correu, identificar el client al CRM, consultar l’estoc al ERP, crear un esborrany de comanda, derivar a una persona quan el cas és ambigu. Si l’agent no fa cap d’aquestes accions, no redueix hores de feina mecànica. Redueix temps de resposta a preguntes, que és un problema diferent.

Avui, l’estàndard que permet verificar aquesta interoperabilitat de manera auditable és el Model Context Protocol (MCP). Un agent amb integracions documentades via MCP permet saber exactament: amb quants sistemes parla, com parla, i amb quins permisos. Si un proveïdor no pot descriure les integracions del seu agent en termes d’eines, mètodes i permisos, la governança del sistema és difícil d’establir.

La pregunta de filtre: amb quants sistemes interns parla l’agent via MCP, i quins mètodes exposa cada un?

No cal que el client entengui el protocol en detall. Ha d’entendre la llista: “l’agent llegeix del CRM, escriu esborranys de comanda al ERP, no escriu al CRM, no envia correus autònomament.” Amb aquesta llista, el client sap exactament on pot fallar l’agent i quin abast té un error.

Condició 3: kill-switch efectiu en menys de cinc minuts

El mecanisme per apagar l’agent és la primera peça que es dissenya, no l’última.

L’argument és operatiu. Un agent que toca dades reals pot fer mal ràpid. Si un agent processa comandes de WhatsApp i comença a generar entrades incorrectes al ERP, el dany és proporcional al nombre de comandes que passen fins que algú ho detecta i atura el sistema. Si arribar al proveïdor triga dues hores, el dany pot ser de dues hores de comandes incorrectes.

El kill-switch correcte compleix tres condicions:

1. Accionable pel client. No cal trucar al proveïdor. Pot ser una variable d’entorn, un botó al panell d’administració, una crida API documentada, o una configuració a l’eina interna del client. El que no és un kill-switch és dir “envia un correu a l’equip de serpixel i responem en dues hores”.

2. SLA d’efectivitat inferior a cinc minuts. Des del moment en que el client el prem fins que l’agent deixa de processar nous casos. No des que el client envia la sol·licitud: des que prem el botó.

3. Fallback humà documentat. El kill-switch no és complet sense saber qui agafa el procés quan l’agent és apagat. Si l’agent processa 200 comandes al mes i s’apaga, algú les ha de processar. Aquesta persona, amb quines eines i en quin temps, ha d’estar documentat al SOW i testejat, no pensat de pressa mentre el procés s’acumula.

La pregunta de filtre: en quants minuts puc aturar l’agent si comença a fer mal, i sense trucar a ningú?

Condició 4: harness d’avaluació en producció

La diferència entre un agent que s’implementa i un agent que funciona a llarg termini és l’avaluació contínua.

Un harness d’avaluació offline és un conjunt de casos de prova estàtics: 50 missatges representatius amb les respostes esperades, que passen automàticament contra el model i marquen pass/fail. Serveix per verificar comportament inicial, per detectar regressions quan canvies una versió del model. Però no és avaluació de producció.

Un harness de producció avalua l’agent sobre tràfic real. Casos reals, amb les distribucions d’entrades que el negoci genera cada dia: missatges en l’idioma del client real, amb els errors ortogràfics dels clients reals, amb les referències a productes amb noms no estàndard que posen els clients reals. Mesura quatre coses:

• Precisió. Quin percentatge de casos processa l’agent correctament?
• Latència. Quant de temps triga a processar cada cas?
• Cost per acció. Quin és el cost d’inferència per cas processat?
• Deriva de comportament. La qualitat d’avui és la mateixa que fa un mes?

La deriva importa. Els models de llenguatge canvien (versions noves, fine-tunings del proveïdor), les dades del negoci canvien (productes nous, processos nous, nous tipus de client), i el comportament de l’agent pot degradar-se sense que ningú ho noti fins que ho nota el client.

La pregunta de filtre: qui llegirà les dades d’avaluació cada setmana, i quina decisió estarà associada a la lectura?

Si no hi ha una persona designada i una decisió associada (si la precisió baixa del llindar X, es fa Y), el harness és un instrument sense ningú al volant.

El contracte és la mínima garantia

Quatre condicions. Scoping acotat, interoperabilitat verificable, kill-switch efectiu, avaluació contínua. Cap de les quatre és sofisticada: totes es poden explicar en cinc minuts a un director d’operacions sense formació tècnica.

El que fa que siguin difícils no és la comprensió: és que demanen feina prèvia. Documentar el procés pas a pas és incòmode. Definir una mètrica de resultat amb baseline és difícil quan no hi ha dades prèvies. Dissenyar el kill-switch i el fallback humà requereix imaginar un fracàs que ningú vol que passi. Muntar el harness de producció des del primer dia és més car que no tenir-lo.

Però el cost d’ometre qualsevol de les quatre no cau sobre el proveïdor. Cau sobre el negoci del client.

Aquesta és la raó per la qual no signem implementacions que no compleixin les quatre. No és una postura comercial. És la única manera que coneixem de garantir que el que posem en producció funciona quan importa i es pot aturar quan falla.

Si tens una idea de procés i vols saber si passa aquest filtre, parlem 30 minuts. Portem el procés sobre la taula i en sortim sabent si hi ha un agent que té sentit implementar, i si el té, quines serien les quatre condicions aplicades al teu cas.