Com auditar la seguretat d'un assistent d'IA en producció

Escrit per:  Juan Holgado

Desplegar un assistent d'IA avui dura una tarda. Una API, un prompt de sistema raonable, unes proves amb preguntes amables i ja atén al web.

En els projectes que revisem, el recorregut es repeteix amb poques variacions. El projecte neix a màrqueting o a atenció al client, es llança de pressa per la pressió de tenir alguna cosa d'IA en producció, i no passa pel filtre de seguretat que s'aplica a qualsevol altre sistema exposat a internet.

D'aquí surt una pregunta que convé fer-se abans que la faci un client o un auditor. Si algú et demanés demà l'informe de seguretat d'aquest assistent, existiria? En la majoria de les organitzacions amb què treballem, la resposta és que no: sense anàlisi de riscos, sense proves de seguretat i, en una part dels casos, sense registre de les converses. L'assistent continua allà, disponible 24 hores al dia, contestant a desconeguts i connectat a sistemes interns.

Instruccions i dades comparteixen canal en un chatbot

En una aplicació web convencional, les instruccions del programa i les dades de l'usuari viuen en espais separats. En un chatbot arriben al model com a text, per la mateixa via. El model no té cap manera fiable de distingir què va escriure el desenvolupador i què escriu algú que intenta manipular-lo. Gairebé tots els altres problemes deriven d'aquesta característica.

El sistema tampoc no és determinista. La mateixa pregunta pot rebre respostes diferents avui i demà, de manera que un test superat garanteix poc a mitjà termini. Un ajust en el prompt redueix la probabilitat de la fallada i deixa oberta la via que la permet.

Tampoc no hi ha cap CVE que avisi. Ningú no publica un butlletí quan un assistent comença a revelar informació d'altres clients.

De l'assistent que respon a l'agent que executa accions

El risc ha crescut durant l'últim any, perquè aquests assistents ja executen accions a més de conversar. Consulten bases documentals, criden APIs internes, obren tiquets i tramiten devolucions. Cada connexió converteix una conversa en una acció amb conseqüències.

Aquestes connexions tampoc no es programen una a una. Amb agents i protocols com MCP, un assistent descobreix eines en temps d'execució, encadena diverses crides per complir un objectiu i arrossega memòria entre sessions. Ha passat de ser un component que respon a ser un actor que pren decisions.

OWASP ha reflectit aquest canvi separant el Top 10 d'aplicacions LLM del Top 10 d'aplicacions agèntiques, perquè descriuen dues superfícies d'atac diferents. En els desplegaments empresarials que hem revisat, totes dues solen ser presents al mateix temps.

Quatre incidents públics i què va demostrar cadascun

El 2023 es va saber que treballadors de Samsung havien enganxat codi intern en un assistent d'IA públic per demanar ajuda amb la seva feina. Informació confidencial sortint per un canal que ningú no havia classificat com a canal de sortida (CNBC; AI Incident Database, 768).

El desembre d'aquell any van circular captures de l'assistent d'un concessionari de Chevrolet acceptant vendre un cotxe per 1 dòlar (AI Incident Database, 622). Un mes més tard, el gener de 2024, el bot d'atenció al client de DPD al Regne Unit va acabar responent amb paraules malsonants i criticant la seva pròpia empresa (ITV News; AI Incident Database, 631).

El cas que va canviar el marc és el quart. El febrer de 2024, el Civil Resolution Tribunal de la Colúmbia Britànica va resoldre que Air Canada havia de compensar un passatger per la informació errònia que el seu chatbot li havia donat sobre les tarifes reduïdes per defunció d'un familiar. L'aerolínia va defensar que el chatbot constituïa una entitat separada de la companyia, i el tribunal va rebutjar aquest argument (Moffatt v. Air Canada, 2024 BCCRT 149).

Els quatre casos van produir conseqüències diferents: fuita de dades, manipulació de la lògica de negoci, dany reputacional i responsabilitat legal. Tots es van executar escrivint, sense ni una sola eina d'atac.

Les dues fallades de configuració més freqüents

Aquests són els casos que el sector cita amb més freqüència i, per aquesta mateixa raó, els menys representatius: són els que algú va capturar. El que trobem habitualment a les auditories no és espectacular.

Permisos que es queden a la interfície. Un assistent de consulta documental muntat sobre el gestor documental de l'empresa necessita llegir el repositori, de manera que rep un compte de servei. Els permisos de l'usuari que pregunta arriben fins al xat i s'aturen abans de la cerca: la persona s'autentica contra l'assistent i la consulta l'executa el compte de servei. El sistema funciona durant mesos perquè ningú no pregunta per allò que no li correspon. El dia que algú ho fa, i acostuma a tractar-se d'un treballador curiós abans que d'un atacant, l'assistent li retorna el contingut d'una carpeta de recursos humans o la documentació d'un altre client, ben redactat i amb to servicial. Sense exploit, sense eina i amb una entrada de registre idèntica a la d'una consulta legítima, en els casos en què hi ha registre.

Eines que ningú no ha revisat. L'assistent té sis o set eines disponibles perquè venien amb el framework, i en producció fa servir dues. Les altres cinc continuen allà, sense revisió i sense vigilància, i de vegades sense que ningú de l'equip recordi que hi són. Es mantenen inertes mentre ningú no les invoqui, tot i que el model sap que estan disponibles: n'hi ha prou amb conduir la conversa cap a un objectiu que les necessiti perquè les faci servir per iniciativa pròpia. És excés de capacitat d'acció en estat pur, i es corregeix esborrant línies de configuració.

Aquests dos patrons no generen titulars, perquè no deixen cap captura per compartir. Apareixen quan algú els va a buscar.

Respostes desiguals segons qui pregunta

Que l'assistent respongui amb un comentari racista, masclista o menyspreador cap a un col·lectiu és el que esclata més ràpid. Els models actuals incorporen força més filtres de sèrie que els de fa uns anys, tot i que aquests filtres cedeixen sota pressió, i la conversa de diversos torns és el terreny on cedeixen abans. Una tarda d'intents i una gravació de pantalla són prou per documentar-ho.

Hi ha una versió més silenciosa del mateix problema, i segons la nostra experiència resulta la més perillosa. L'assistent respon amb un to, un nivell de detall o una disposició a ajudar diferents segons com escrigui la persona, quin nom doni o en quina llengua pregunti. En un cas aïllat, ningú no ho percep. Es percep en l'agregat, i arribats a aquest punt l'organització porta mesos atenent pitjor un grup concret de clients sense haver-ho decidit en cap moment.

Les conseqüències segueixen dos camins. El reputacional actua de manera immediata: una captura circula en hores, el context es perd pel camí i la marca queda associada a aquella frase molt més temps del que costa corregir el prompt.

El jurídic avança més a poc a poc i surt més car. A Espanya, la Llei 15/2022, de 12 de juliol, integral per a la igualtat de tracte i la no-discriminació inclou la intel·ligència artificial en el seu àmbit d'aplicació i dedica l'article 23 als algorismes i als mecanismes de decisió automatitzada. El Reglament (UE) 2024/1689, conegut com a Reglament Europeu d'Intel·ligència Artificial, classifica com d'alt risc determinats usos vinculats a l'ocupació o a l'accés a serveis essencials. I el precedent d'Air Canada marca una direcció clara per a qualsevol organització amb un assistent públic: els tribunals tracten l'assistent com a part de l'empresa que el desplega.

Aquest risc té una particularitat incòmoda. Cap escàner no el detecta, de manera que cal anar-lo a buscar expressament i amb mètode.

L'exposició de l'usuari final

Gairebé tot el debat sobre aquest tema gira al voltant del dany a l'empresa, cosa comprensible, perquè l'empresa paga l'auditoria. Quan l'assistent atén pacients, ciutadans, clients o treballadors, l'exposició més gran recau sobre la persona que hi ha a l'altra banda.

Aquesta persona envia les seves dades personals a un xat sense saber on es guarden, quant de temps ni qui les consulta després. Si l'aïllament del context falla, pot rebre informació que pertany a un altre usuari. Sense registre de la conversa, no té manera de demostrar què se li va prometre. I rep respostes escrites amb seguretat impecable sobre assumptes seriosos, sense cap pista sobre la seva exactitud.

Aquest últim punt és el que més ens preocupa. Un model que desconeix alguna cosa poques vegades ho admet: omple el buit, i ben redactat. Un professional del sector identifica l'error amb relativa facilitat. Una persona gran preguntant per un tràmit, o algú consultant un dubte de salut a les tres de la matinada, es queda amb la resposta.

OWASP ha arribat per la via de les dades a una conclusió semblant. En l'edició 2026 del Top 10 per a aplicacions LLM, la desinformació puja posicions i presenta el desajust més gran de tota la llista entre la percepció dels professionals enquestats i el registre d'incidents reals. El canvi rellevant afecta l'enquadrament més que la posició: una resposta segura i equivocada ha passat a tractar-se com un problema de seguretat i ja no només com un problema de qualitat.

Els límits del pentest tradicional

Auditar l'aplicació que allotja el chatbot continua sent necessari: autenticació, gestió de sessió, exposició de l'API, transport. Tot això cal fer-ho, i tot això deixa intacte el comportament del model, que és on resideix el risc nou.

L'objecte de la prova canvia. Aquí es comprova si l'assistent respecta els seus propis límits, i el resultat s'expressa com una taxa d'èxit per categoria.

Aquest format té una implicació pràctica. Una tècnica que funciona en una fracció petita dels intents continua sent explotable per qualsevol persona amb paciència, perquè el cost de reintentar és zero. I la mesura caduca de pressa: un canvi de versió del model o un retoc en el prompt pot reobrir allò que estava tancat.

Auditar això una vegada l'any equival a escanejar vulnerabilitats una vegada l'any.

Les dues meitats d'una auditoria d'assistents d'IA

La feina té dues meitats, i el marc de referència és públic.

La meitat adversarial. S'ataca l'assistent en condicions controlades i es mesura una taxa d'èxit per categoria, seguint el Top 10 d'OWASP per a aplicacions LLM: injecció d'instruccions directa i indirecta (LLM01), fuita d'informació sensible (LLM02), exposició del context ocult (LLM08), que en l'edició anterior s'anomenava fuita del prompt de sistema, i tractament insegur de la sortida del model (LLM10). A això s'hi afegeix l'abús de la lògica de negoci concreta de cada client, que no figura en cap llista. Una part de la feina s'automatitza amb bateries àmplies d'atacs. Una altra part exigeix execució manual, perquè les cadenes de diversos torns i l'abús del context específic d'un negoci escapen a les eines.

La meitat d'arquitectura. Acostuma a donar les troballes més greus, i s'ordena amb 4 preguntes:

• Els permisos de l'usuari que pregunta es propaguen fins a la cerca documental, o el servei consulta amb permisos de servei?

• Es valida allò que el model retorna abans d'executar una acció amb aquella dada?

• Què pot invocar l'assistent i què necessitaria invocar realment?

• Queda registre de la conversa?

Amb agents pel mig s'hi sumen les preguntes del Top 10 agèntic: identitat i privilegis de l'agent, contenció en temps d'execució i enverinament de la memòria entre sessions.

Bona part de les troballes es corregeix retallant allò que l'assistent pot fer, i els guardrails amb prou feines les toquen. L'excés de capacitat d'acció (LLM03) ha guanyat posicions en la llista d'OWASP d'aquest any per aquest motiu.

L'inventari previ. Abans de tot això hi ha una fase que sembla burocràtica i poques vegades ho és: enumerar els assistents que existeixen realment a l'organització, amb responsable, dades accessibles i accions permeses. En diversos projectes, aquell full de càlcul ha estat la primera troballa, perquè apareixen dos o tres assistents que ningú no havia declarat.

Obligacions legals exigibles des de l'agost de 2026

Des del 2 d'agost de 2026 són exigibles les obligacions de transparència de l'article 50 del Reglament (UE) 2024/1689, que inclouen informar la persona que està interactuant amb una màquina, amb multes de fins a 15 milions d'euros o el 3 % de la facturació global.

El Reglament (UE) 2026/1744, conegut com a Òmnibus digital sobre IA i en vigor des del 27 de juliol de 2026, ha endarrerit bona part de les obligacions dels sistemes d'alt risc al 2 de desembre de 2027 per als sistemes de l'annex III i al 2 d'agost de 2028 per als de l'annex I. També ha flexibilitzat l'obligació d'alfabetització de l'article 4 i ha introduït un període transitori de 4 mesos per al marcatge dels sistemes comercialitzats abans del 2 d'agost de 2026. La transparència de l'article 50 manté la seva data: qui operi un chatbot públic ja és dins de l'àmbit d'aplicació.

El RGPD no ha deixat mai d'aplicar-se a les dades personals que entren pel xat. I per a les organitzacions subjectes a l'ENS o a la NIS2, un assistent connectat a sistemes interns entra de ple en l'abast.

Per ordenar la governança de tot això, la referència certificable és avui la ISO/IEC 42001:2023.

Tres comprovacions immediates

Si l'assistent ja és en producció i l'auditoria no és immediata, hi ha marge per reduir l'exposició sense grans obres.

1. Verifica que avisa que és una IA. Des del 2 d'agost és obligatori informar la persona a l'inici de la interacció. La comprovació dura 30 segons i és l'únic punt d'aquesta llista que pot estar en situació d'incompliment avui.

2. Fes l'inventari. Quins assistents existeixen, qui els manté, a quines dades arriben i quines accions poden executar. Es resol en mig matí de feina.

3. Dona per fet que el prompt de sistema és públic. Si conté credencials, regles de preus o lògica de negoci sensible, convé retirar-la d'allà com més aviat millor.

L'assistent com a sistema en producció

Descrit amb precisió, un chatbot d'IA reuneix les condicions d'un treballador acabat d'incorporar: sense formació en seguretat, amb accés a sistemes interns, sense supervisor assignat i parlant amb desconeguts a totes hores. Plantejada així, la pregunta rellevant deixa de ser si mereix una auditoria i passa a ser com hem arribat a tenir-ne uns quants en producció sense auditar-los.

La part útil de la resposta és que la feina es coneix. Hi ha el marc públic d'OWASP, hi ha el criteri per separar allò que es corregeix escrivint d'allò que exigeix decisions d'arquitectura, i hi ha les 4 preguntes de l'apartat anterior, que qualsevol equip pot respondre aquesta setmana sense ajuda externa. Els permisos que s'apliquen a la interfície i es perden a la capa de recuperació, les eines exposades de més i l'absència de registre exigeixen decisions d'arquitectura i de permisos, i corregir-ho poques vegades implica refer el projecte.

A Aktios fem red teaming d'assistents d'IA en producció i deixem el sistema documentat per a una auditoria d'ISO/IEC 42001. Si tens un assistent atenent clients i no sabries dir què contesta davant d'una instrucció malintencionada, convé esbrinar-ho en un entorn controlat abans de veure-ho en una captura de pantalla.

Sol·licita un Pentest