La intel·ligència artificial basada en agents autònoms està transformant la manera com les empreses automatitzen processos, però amb aquesta autonomia arriba un risc real: un agent mal configurat pot causar danys que es propaguen ràpidament. El concepte de 'radi d'explosió' (blast radius) aplicat a agents IA permet mesurar l'abast de les accions no desitjades. Tanmateix, la teoria només és útil quan s'operacionalitza. En aquest article explorem com convertir aquest model en controls pràctics, integrant polítiques executables, contractes d'eines estrets i mecanismes de reversió, tot des d'una perspectiva empresarial i tècnica original.
A Q2BSTUDIO, com a empresa especialitzada en desenvolupament de programari i tecnologia, hem vist com moltes organitzacions despleguen agents amb instruccions vagues i permisos amplis. El resultat: incidències de seguretat, pèrdua de dades i desconfiança en l'adopció d'IA. Operacionalitzar el radi d'explosió no és només un exercici de documentació; és un canvi de paradigma que afecta des de l'arquitectura de programari fins a la governança de TI. A continuació, presentem una guia per implementar aquest model sense caure en les pràctiques insegures que tant hem advertit.
Primer pas: inventari d'accions a nivell granular
L'error més comú és tractar un agent com una unitat monolítica. En lloc d'això, cal descompondre cada agent en accions específiques. Per exemple, un agent de suport tècnic pot resumir tiquets, redactar respostes, afegir notes internes o sol·licitar aprovacions per restablir contrasenyes. Cada acció té un nivell d'autonomia diferent i, per tant, un radi d'explosió diferent. En catalogar cada operació, es poden assignar polítiques de control personalitzades. Aquest inventari ha d'incloure el tipus d'eina, el recurs objectiu, la classe de dades, la necessitat d'aprovació i la capacitat de reversió. Només així es pot planificar la seguretat de manera precisa.
A Q2BSTUDIO recomanem començar amb una matriu que creui aquestes variables. Per això, oferim serveis de desenvolupament d'aplicacions a mida que permeten crear agents amb límits clars des del disseny. No es tracta de restringir la innovació, sinó de canalitzar-la dins d'un perímetre controlat.
Segon pas: contractes d'eines estrets i predictibles
Una eina genèrica com executa_ordre(ordre) dona a l'agent un poder gairebé il·limitat per improvisar. En lloc seu, cal dissenyar eines específiques com reinicia_servei_aprovat(nom_servei, host_id). Això força els desenvolupadors a decidir per endavant quines accions estan permeses, reduint la superfície d'atac. En termes pràctics, un contracte d'eina ha de definir el seu propòsit, l'invocador permès, els paràmetres amb esquema i valors permesos, l'abast de recursos, els efectes secundaris, els límits de taxa, la identitat que executa, els requisits d'aprovació, la ruta de reversió i l'evidència que s'ha de registrar.
Aquesta aproximació és clau en projectes d'intel·ligència artificial que desenvolupem a Q2BSTUDIO. En integrar contractes estrictes, els agents es converteixen en eines governables, no en caixes negres. La governança de la IA no és un afegit; és part de l'arquitectura des de l'inici.
Tercer pas: polítiques fora del prompt, dins del motor de decisió
Confiar que un prompt ben redactat evitarà comportaments no desitjats és una il·lusió perillosa. Les instruccions en llenguatge natural són útils per orientar el comportament, però no constitueixen un control d'autorització. La política de seguretat s'ha d'executar abans que l'agent invoqui qualsevol eina. Per això, es necessita un 'policy gate' (porta de polítiques) que avaluï dades estructurades —identitat de l'agent, usuari sol·licitant, acció, recurs, entorn, classe de dades, impacte, classe de reversió, artifacte d'aprovació, límits d'execució— i retorni una decisió clara: permetre, permetre amb restriccions, només esborrany, requerir aprovació, escalar o denegar. El valor per defecte ha de ser denegar.
Implementar aquesta porta requereix orquestrar serveis d'identitat (IAM), passarel·les d'API i registres d'auditoria. A Q2BSTUDIO tenim experiència en serveis cloud a AWS i Azure, on aquestes polítiques es materialitzen mitjançant Azure Policy, AWS IAM i motors de decisió personalitzats. El núvol ofereix les eines, però l'arquitectura del control la defineix l'equip.
Quart pas: l'aprovació com a artifacte, no com a sensació
L'aprovació humana no pot ser un simple clic. Ha d'incloure qui va aprovar, quina acció específica es va aprovar, per què, quan expira, què va canviar i quina reversió s'aplicarà. Sense aquests detalls, l'aprovació és un mer tràmit. En entorns amb agents, recomanem que l'aprovador vegi exactament l'eina, l'objectiu, l'entorn i la ruta de reversió. Això converteix el 'human-in-the-loop' en un control real, no en una ficció.
La ciberseguretat és un pilar fonamental en aquest procés. A Q2BSTUDIO oferim serveis de ciberseguretat i pentesting per validar que aquests fluxos d'aprovació no siguin vulnerables a atacs d'injecció o suplantació d'identitat. Un agent que pot enganyar un humà per obtenir aprovació és tan perillós com un sense restriccions.
Cinquè pas: reversió classificada i obligatòria
No s'ha de descobrir com revertir una acció després que ocorri. Cada acció ha de tenir una classe de reversió definida abans de ser executada. Les classes poden ser: descartable, reversible per versió, acció compensatòria, recuperació manual o irreversible. Les accions irreversibles s'han de denegar completament per a execució autònoma. Les reversibles per compensació requereixen aprovació i un runbook associat. Aquest enfocament no només protegeix contra errors, sinó que també accelera la recuperació davant incidents.
L'analítica de negoci (BI) té un paper important en la monitorització d'aquests esdeveniments. Amb eines com Power BI, a Q2BSTUDIO ajudem les empreses a visualitzar en temps real l'estat dels seus agents, les decisions de política i els intents de violació. El Business Intelligence amb Power BI permet convertir els registres d'auditoria en dashboards accionables per als equips d'operacions i seguretat.
Límits de taxa i lots: controls d'escalat
Un error petit pot convertir-se en una catàstrofe si no hi ha límits de taxa. Un agent que actualitza tiquets mal etiquetats pot generar milers de canvis incorrectes en minuts. Per això, cada acció ha de tenir límits per petició, per hora, per entorn i per recurs sensible. També és necessari establir límits de reintents i finestres de temps. Aquests controls actuen com a fusibles que contenen el radi d'explosió abans que s'expandeixi.
Seqüència d'implantació gradual
No s'ha de desplegar primer l'agent més impressionant. Cal començar pel flux de treball el fallada del qual es pugui explicar clarament. La seqüència recomanada és: inventariar, classificar, restringir eines, aplicar porta de polítiques, observar, provar i només llavors expandir autonomia. L'autonomia s'ha de guanyar amb evidència operativa.
A Q2BSTUDIO apliquem aquesta metodologia en tots els nostres projectes d'automatització. El nostre enfocament combina automatització de processos de programari amb controls de seguretat des del disseny, garantint que els agents IA siguin productius sense convertir-se en un risc.
Integració amb l'arquitectura empresarial existent
Aquest patró no reemplaça els controls actuals; els connecta. La gestió d'identitats (IAM), l'accés privilegiat (PAM), les passarel·les d'API, la gestió de canvis, l'observabilitat i la governança de dades s'integren en una capa de control unificada. L'agent actua a través de sistemes empresarials, per tant la governança ha de ser igualment empresarial.
El resultat és un ecosistema on la IA no depèn de la bona voluntat del prompt, sinó d'un disseny executable. Operacionalitzar el radi d'explosió de l'agent no és un luxe; és un requisit per escalar la IA amb confiança.
