No donis idees a la IA
“No donis idees a la IA” comença a sonar menys com una broma quan veiem agents accedint a sistemes…
Cerca
“No donis idees a la IA” comença a sonar menys com una broma quan veiem agents accedint a sistemes…
Durant anys, gran part del disseny d’interacció ha partit d’una premissa força simple: l’usuari…
Entres en un perfil d'Instagram. Hi ha foto, biografia, centenars de seguidors i comptes seguits…
“No donis idees a la IA” comença a sonar menys com una broma quan veiem agents accedint a sistemes inesperats, IA utilitzada per automatitzar ciberatacs, credencials robades o eines instal·lades dins d’infraestructures compromeses.
El problema és que tendim a posar-ho tot al mateix sac.
No és el mateix que una IA dugui a terme una acció no prevista, que una persona utilitzi una IA per atacar, o que un tercer robi accessos i utilitzi aquesta infraestructura per executar les seves pròpies accions.
Des de fora, els tres casos poden semblar el mateix. Fins i tot poden deixar noms semblants als logs.
Però la diferència és fonamental.
Quan veiem una IA fent alguna cosa que no hauria de fer, sabem realment qui està actuant?
El canvi no rau només en el fet que els models siguin més capaços. Rau en tot allò que ara poden tocar.
Un agent pot tenir accés a una terminal, un navegador, repositoris, API, arxius, serveis al núvol, correu electrònic, eines internes o credencials. Pot consultar informació, executar ordres i encadenar accions sense que una persona intervingui en cada pas.
Aquí canvia la naturalesa del risc.
Una resposta equivocada pot quedar-se en una mala recomanació. Una decisió equivocada dins d’un sistema amb accés real pot convertir-se en una acció: modificar un arxiu, crear un recurs, enviar informació o executar una ordre.
El risc no augmenta només amb la intel·ligència del model. Augmenta amb l’accés que li donem.
El juliol de 2026, diversos models d’ OpenAI van aconseguir eludir controls d’aïllament durant avaluacions internes de ciberseguretat, obtenir accés a Internet i arribar a sistemes de tercers, entre ells Hugging Face. OpenAI va reconèixer després que algunes d’aquelles accions s’allunyaven del propòsit original de les tasques assignades.
Anthropic ha documentat incidents similars durant les seves pròpies avaluacions, en què models Claude van aconseguir accés no autoritzat a sistemes reals de tercers.
Però descriure aquests casos com una IA que “volia escapar” simplifica massa el que va passar.
El problema és més interessant: el sistema va trobar una estratègia vàlida per avançar cap al seu objectiu, però invàlida per a les restriccions que crèiem haver establert.
Podem definir molt bé què volem que faci un agent i, alhora, definir malament fins on pot arribar per aconseguir-ho.
El segon escenari és diferent: la IA no s’equivoca. Pot estar funcionant exactament tal com va ser dissenyada.
El problema és qui l’està utilitzant i per a què.
En el seu últim informe d’amenaces, Anthropic descriu operacions en què Claude va ser utilitzat per a reconeixement, creació d’infraestructura de pesca electrònica, execució d’ordres, robatori de credencials, moviment lateral i exfiltració de dades. En alguns casos, els agents van arribar a executar gran part d’aquestes tasques de manera autònoma i sobre diversos objectius en paral·lel.
La diferència respecte de les eines anteriors no rau només en el que poden fer, sinó en la velocitat, l’escala i el grau d’autonomia amb què ho poden fer.
La IA no necessita tenir una intenció maliciosa per multiplicar una intenció maliciosa.
També hi ha un tercer escenari: que el problema no sigui en l’agent, sinó en qui ha aconseguit accés a ell.
Claus d’API, tokens de sessió, credencials al núvol, comptes de desenvolupador o servidors poden convertir-se en la porta d’entrada per utilitzar eines d’IA dins d’una infraestructura compromesa.
Això obliga a ser especialment curosos amb l’atribució. Que en una màquina aparegui Claude, OpenAI o qualsevol altra eina d’IA no significa que aquella IA hagi iniciat l’atac.
Podem trobar recursos o eines que ningú de l’equip recorda haver desplegat, processos inesperats o serveis associats a agents dins d’un compte compromès. Tot plegat pot ser una pista, però no explica per si sol qui hi va accedir, com ho va fer ni amb quin objectiu.
L’agent, en aquest cas, pot formar part de la mateixa superfície compromesa.
La IA no sempre és l’atacant. De vegades és una eina que algú ha aconseguit utilitzar dins de l’atac.
El prompt injection introdueix un problema diferent: l’agent pot rebre instruccions des del mateix contingut que està processant.
Un web, un correu, un document, una incidència de GitHub o un arxiu poden contenir text pensat no per a una persona, sinó per influir en el comportament de l’agent que l’està llegint.
És l’equivalent, per a una màquina, de bona part de l’enginyeria social que coneixem en ciberseguretat. Abans intentàvem ensenyar una persona a desconfiar d’un “fes clic aquí”. Ara també necessitem dissenyar agents capaços de desconfiar d’un “ignora les instruccions anteriors”.
OpenAI descriu precisament aquest risc en sistemes capaços de navegar, llegir contingut extern i utilitzar eines.
La conseqüència és important: el contingut deixa de ser únicament informació i també pot convertir-se en una instrucció.
I com més accés tingui l’agent, més gran pot ser l’impacte d’obeir-la.
Quan té lloc un incident amb un agent, reconstruir el que ha passat pot ser més difícil del que sembla.
L’acció va partir del mateix agent? La va provocar una instrucció externa? La va demanar un usuari? Es van utilitzar credencials robades? Va ser una automatització legítima que va seguir un camí inesperat? Hi havia un altre agent al darrere?
En la seguretat tradicional intentem respondre una pregunta relativament directa: qui va fer què.
Amb els sistemes agèntics apareix una altra capa: qui va demanar què a qui, amb quins permisos i a través de quina eina.
Aquesta cadena pot incloure persones, models, API, eines externes i automatitzacions. I com més llarga sigui, més difícil serà reconstruir responsabilitats, intencions i punts de fallada.
Per això, en aquest context, els logs ja no s’haurien de limitar a registrar accions. També ens haurien d’ajudar a entendre com s’hi va arribar.
Un xatbot sense accés extern i un agent connectat a deu eines no tenen la mateixa superfície de risc.
Com més capacitats hi afegim, més important és dissenyar què pot assolir realment el sistema: quines credencials utilitza, a quins entorns accedeix, quines accions pot executar, quins límits econòmics té i com podem revocar aquest accés si alguna cosa surt malament.
Aquí entren principis coneguts com el mínim privilegi, l’ aïllament d’entorns, els permisos limitats, les credencials temporals, la traçabilitat o la supervisió d’accions crítiques.
No es tracta de fer l’agent menys capaç. Es tracta d’evitar que una capacitat útil es converteixi en accés innecessari.
No hem de limitar el que la IA sap. Hem de limitar allò a què pot arribar.
Potser la por estava mal plantejada.
El problema no és que una IA tingui una idea que nosaltres no havíem tingut. De fet, precisament per això la utilitzem: per trobar patrons, alternatives i camins que no sempre veiem.
El risc apareix quan aquesta capacitat es combina amb accés, eines, credencials i límits mal definits. Aleshores una idea deixa de ser només una possibilitat i pot convertir-se en una acció real.
Per això, dissenyar sistemes agèntics no consisteix únicament a decidir què poden fer, sinó també a establir amb claredat fins on poden arribar, quins accessos necessiten, què han de registrar i com podem intervenir si alguna cosa es desvia.
Tornem així al títol: no es tracta de no donar idees a la IA. Es tracta de dissenyar bé què pot fer amb elles.
Si un agent troba una manera de fer alguna cosa que nosaltres mai no imaginem, hem dissenyat també una manera d’impedir-li fer allò que mai no hauríem autoritzat?
Comentaris