El salt d'un agent d'intel·ligència artificial funcional en un entorn de laboratori a un sistema fiable en producció no és un problema d'ajust de models, sinó d'arquitectura de govern. A Q2BSTUDIO, on desenvolupem aplicacions a mida i solucions d'IA, hem après que un prototip que 'funciona' pot amagar riscos greus: identitats no auditades, eines sense control, costos disparats o fallades sense recuperació. Aquest article proposa una checklist de producció original, pensada per a equips tècnics i directius que volen desplegar agents d'IA amb garanties empresarials.
Què distingeix un prototip d'un sistema llest per a producció? La diferència no està en el prompt, sinó en els plans de control que envolten el model. Un prototip demostra que un agent pot completar una tasca; un sistema productiu ha de poder explicar qui va actuar, quin estat es va retenir, quines eines es van utilitzar, com es va avaluar el comportament, quina telemetria es va capturar, on es va interrompre per aprovació, com es va limitar el cost, com es van contenir les fallades i qui és el responsable del servei. Són vuit eixos que s'han de tractar com a plans de control separats, no com a pedaços posteriors.
Identitat: qui actua realment En producció, un agent opera amb almenys tres identitats: la del sol·licitant (persona, aplicació o esdeveniment), la del mateix agent (identitat de càrrega de treball no humana) i la identitat delegada que es presenta a l'eina o font de dades. No es poden col·lapsar en un únic compte de servei. A Q2BSTUDIO, en integrar agents amb cloud AWS/Azure, exigim que cada identitat tingui un abast clar, tokens de curta durada, rotació automàtica i registre d'auditoria. Sense aquesta separació, qualsevol fallada de seguretat és impossible de rastrejar.
Estat: dissenyat, no acumulat L'estat en un prototip sol ser un historial de conversa que creix sense control. En producció, cal separar l'estat de conversa, l'estat del flux de treball, la memòria duradora, les evidències, les aprovacions i els artefactes. Cada tipus necessita un esquema, propietari, política de retenció i xifratge. El model només ha de veure una vista temporal de l'estat necessari per al pas actual, no el magatzem autoritatiu. La capacitat de pausar un agent, inspeccionar el seu estat i reprendre'l exactament una vegada sense efectes secundaris duplicats és un indicador de maduresa.
Eines: API de producció, no funcions de joguina Cada eina que l'agent invoca ha de tenir un registre de capacitat que defineixi el seu propòsit, classificació de dades, mètode d'autenticació, esquemes d'entrada/sortida, timeouts, límits de reintents, idempotència i requisits d'aprovació. A Q2BSTUDIO classifiquem les eines per conseqüència: lectura, proposta, canvi reversible, canvi d'alt impacte. Com més autoritat tingui l'eina, menys discreció ha de tenir el model. Els arguments de l'eina s'han de validar amb codi determinista, i els resultats s'han de tractar com a dades no fiables, perquè un document extern pot contenir instruccions malicioses.
Avaluacions: del prompt al flux complet Un benchmark de model no diu si l'agent va triar l'eina correcta, va respectar els límits d'aprovació, es va recuperar d'un timeout o es va mantenir dins del pressupost. Les avaluacions de producció han de mesurar el flux complet: proves deterministes de comportament a nivell de codi, avaluacions offline amb tasques representatives, avaluacions de traça que inspeccionin el camí (no només la resposta final), avaluacions adversarials (injecció de prompts, enverinament de memòria) i avaluacions online amb mostres reals. Els llindars de release han de ser específics: zero violacions de polítiques crítiques, zero crides a eines d'alt impacte incorrectes, èxit de tasca per sobre del 95%.
Observabilitat: reconstruir cada execució La monitorització tradicional veu la petició externa i potser una crida al model. Un agent pot tenir diverses crides al model, recuperacions, lectures de memòria, decisions de política, crides a eines, reintents, aprovacions i traspàsos. La unitat observable és l'execució completa de l'agent. Recomanem un span arrel per invocació, amb fills per a cada operació. La captura de contingut ha d'estar deshabilitada per defecte i habilitar-se només amb polítiques de redacció i xifratge. Els registres de baixa cardinalitat (versió de l'agent, model, política, eina, entorn, resultat) permeten a un enginyer de guàrdia diagnosticar amb un sol identificador d'execució.
Seguretat: control en temps d'execució Les instruccions al prompt no són controls de seguretat. El model d'amenaces ha de cobrir tota la ruta de l'agent: entrada d'usuari, documents recuperats, contingut web, memòria, sortida del model, metadades d'eines, arguments i resultats, missatges entre agents, execució en sandbox, egress de xarxa, magatzems d'estat i registres. A Q2BSTUDIO, en implementar ciberseguretat en sistemes d'IA, apliquem controls com validació d'esquemes, límits d'egress, escaneig de secrets, xifratge en trànsit i repòs, i proves de tall (shutdown path). Un agent manipulat amb accés de sola lectura a documentació pública és un risc menor que un amb accés a shell i credencials de producció.
Cost: pressupost per execució El cost d'un agent no és el cost d'una crida al model, sinó el cost de tota l'execució: instruccions, historial, context recuperat, esquemes d'eines, reintents, crides de validació, raonament, generació de sortida i traspàsos. Cal posar un pressupost al límit de l'execució: nombre màxim de crides al model, eines, reintents, temps transcorregut, branques paral·leles, consum d'API externes. La mètrica principal ha de ser el cost per tasca exitosa. Un model barat que provoca reintents o accions incorrectes surt més car. L'enrutament de models, la memòria cau de prefixos, la compactació de context i les regles de parada han de ser part del runtime, no bones pràctiques opcionals.
Aprovacions: màquina d'estats La intervenció humana ha de dependre de la conseqüència, reversibilitat, autoritat i confiança. Les accions de sola lectura poden ser automàtiques; les propostes s'han de marcar clarament com a esborranys; els canvis reversibles requereixen aprovació només quan l'evidència d'avaluació no és sòlida; les accions d'alt impacte (financeres, destructives, externes) necessiten aprovació obligatòria amb separació de funcions. El flux s'ha de pausar sense perdre estat, i en reprendre's ha de revalidar autorització, política i termini de l'aprovació.
Gestió de fallades: seguretat i intenció Les fallades d'un agent no són només fallades del model. Poden ser degudes a estructura invàlida, recuperació obsoleta, estat corrupte, timeout d'eina, aprovació caducada, dependència no disponible, pressupost esgotat o política bloquejada. La resposta ha de dependre de la classe de fallada: reintentar només fallades transitòries conegudes amb backoff exponencial, utilitzar claus d'idempotència, detectar bucles d'estat, utilitzar circuit breakers, preservar checkpoints abans d'operacions d'alt impacte, i desviar treball irrecuperable a una cua manual amb evidència completa. Les rutes de fallback no han de canviar el model de seguretat sense el mateix disseny rigorós.
Propietat: més enllà del desenvolupador original El primer incident en producció revelarà ràpidament qui no està assignat. Un agent creua diversos dominis: negoci, producte, plataforma, identitat, dades, eines, model, observabilitat, cost i governança. Cada domini necessita un propietari accountable, i un propietari del servei global ha de rendir comptes del resultat final. La documentació de lliurament ha d'incloure arquitectura, inventari, resultats d'avaluacions, dashboards, runbooks, contactes d'escalat i procediments d'apagada.
Desplegament per fases No s'ha de concedir autoritat total en la primera release. Un desplegament disciplinat expandeix trànsit i autoritat per etapes: mode ombra (sense exposar sortida ni executar efectes secundaris), pilot de sola lectura, canari amb aprovacions, automatització acotada i escala controlada. Cada expansió canvia el model de dades, identitat, eines, fallades, cost i propietat. La pregunta de release no és 'segueix funcionant la demo?' sinó 'quina nova autoritat estem atorgant, quina evidència la recolza i amb quina rapidesa podem contenir-la si l'evidència és errònia?'.
A Q2BSTUDIO ajudem empreses a construir aquests plans de control sobre BI/Power BI, cloud i automatització, integrant agents d'IA que no només funcionen, sinó que poden governar-se, explicar-se i recuperar-se. La producció no és el final del prototip: és l'inici d'un sistema que mereix confiança empresarial.
