Què revisem abans de posar en marxa un agent d'IA

Cada agent d'IA que llancem obté accés a alguna cosa que val la pena protegir: una agenda, un CRM, de vegades una fitxa de pacient. La conversa del sector sobre agents d'IA parla molt del que poden fer i molt poc del que poden veure, i de què passa si aquest accés s'utilitza malament, es filtra o simplement està sobredimensionat des del primer dia.

Tractem cada nou agent com una nova superfície d'atac, no només com una nova funció. Abans que res arribi a producció, passa per la mateixa revisió que aplicaríem si un client ens demanés auditar la seva.

Tres comprovacions abans del llançament.

Primera, l'accés. Mapegem exactament què pot llegir i escriure l'agent, i el retallem al mínim que realment necessita — cap agent té accés permanent a una base de dades completa quan només fa servir tres camps. L'accés amb privilegis excessius és la troballa més habitual en les auditories d'agents, incloses les nostres.

Segona, l'abús. Sotmetem l'agent als mateixos intents d'injecció de prompts i jailbreak que provaria un atacant — instruccions ocultes dins d'un missatge, intents de fer-lo cridar eines que no hauria, intents d'extreure el seu propi prompt de sistema o context. Tot el que funciona es corregeix abans del llançament, no després que ho trobi un client.

Tercera, la governança. Comprovem el desplegament davant els marcs que s'estan convertint en l'estàndard real d'això — ISO/IEC 42001, NIST AI RMF i els requisits de l'EU AI Act per a usos de més risc. No perquè quedi bé marcar una casella, sinó perquè un regulador o l'equip de seguretat d'un client enterprise acabarà preguntant, i «no ho vam pensar» no és una resposta que estiguem disposats a donar.

Res d'això és exclusiu nostre — hauria de ser pràctica estàndard per a qualsevol que llanci un agent amb accés real. La majoria del sector s'ho salta perquè alenteix una demo. Creiem que l'alternativa és pitjor.