Cómo auditar la seguridad de un asistente de IA en producción

Escrito por:  Juan Holgado

Desplegar un asistente de IA lleva hoy una tarde. Una API, un prompt de sistema razonable, unas pruebas con preguntas amables y ya está atendiendo en la web.

En los proyectos que revisamos, el recorrido se repite con pocas variaciones. El proyecto nace en marketing o en atención al cliente, se lanza rápido por la presión de tener algo de IA en producción, y no pasa por el filtro de seguridad que se aplica a cualquier otro sistema expuesto a internet.

De ahí sale una pregunta que conviene hacerse antes de que la haga un cliente o un auditor. Si alguien te pidiera mañana el informe de seguridad de ese asistente, ¿existiría? En la mayoría de las organizaciones con las que trabajamos, la respuesta es que no: sin análisis de riesgos, sin pruebas de seguridad y, en una parte de los casos, sin registro de las conversaciones. El asistente sigue ahí, disponible las 24 horas, contestando a desconocidos y conectado a sistemas internos.

Instrucciones y datos comparten canal en un chatbot 

En una aplicación web convencional, las instrucciones del programa y los datos del usuario viven en espacios separados. En un chatbot llegan al modelo como texto, por la misma vía. El modelo carece de una forma fiable de distinguir qué escribió el desarrollador y qué escribe alguien que intenta manipularlo. Casi todos los demás problemas derivan de esa característica.

El sistema tampoco es determinista. La misma pregunta puede recibir respuestas distintas hoy y mañana, así que un test superado garantiza poco a medio plazo. Un ajuste en el prompt reduce la probabilidad del fallo y deja abierta la vía que lo permite.

Tampoco existe un CVE que avise. Nadie publica un boletín cuando un asistente empieza a revelar información de otros clientes.

Del asistente que responde al agente que ejecuta acciones

El riesgo ha crecido en el último año, porque estos asistentes ya ejecutan acciones además de conversar. Consultan bases documentales, llaman a APIs internas, abren tickets y tramitan devoluciones. Cada conexión convierte una conversación en una acción con consecuencias. 

Esas conexiones tampoco se programan una a una. Con agentes y protocolos como MCP, un asistente descubre herramientas en tiempo de ejecución, encadena varias llamadas para cumplir un objetivo y arrastra memoria entre sesiones. Ha pasado de componente que responde a actor que toma decisiones.

OWASP ha reflejado ese cambio separando el Top 10 de aplicaciones LLM del Top 10 de aplicaciones agénticas, porque describen dos superficies de ataque distintas. En los despliegues empresariales que hemos revisado, ambas suelen estar presentes al mismo tiempo.

Cuatro incidentes públicos y qué demostró cada uno

En 2023 se conoció que empleados de Samsung habían pegado código interno en un asistente de IA público para pedir ayuda con su trabajo. Información confidencial saliendo por un canal que nadie había clasificado como canal de salida (CNBC; AI Incident Database, 768).

En diciembre de ese año circularon capturas del asistente de un concesionario de Chevrolet aceptando vender un coche por 1 dólar (AI Incident Database, 622). Un mes más tarde, en enero de 2024, el bot de atención al cliente de DPD en el Reino Unido terminó respondiendo con palabras malsonantes y criticando a su propia empresa (ITV News; AI Incident Database, 631).

El caso que cambió el marco es el cuarto. En febrero de 2024, el Civil Resolution Tribunal de Columbia Británica resolvió que Air Canada debía compensar a un pasajero por la información errónea que su chatbot le había dado sobre las tarifas reducidas por fallecimiento de un familiar. La aerolínea defendió que el chatbot constituía una entidad separada de la compañía, y el tribunal rechazó ese argumento (Moffatt v. Air Canada, 2024 BCCRT 149).

Los cuatro casos produjeron consecuencias distintas: fuga de datos, manipulación de la lógica de negocio, daño reputacional y responsabilidad legal. Todos se ejecutaron escribiendo, sin una sola herramienta de ataque.

Los dos fallos de configuración más frecuentes 

Esos son los casos que cita el sector con más frecuencia y, por esa misma razón, los menos representativos: son los que alguien capturó. Lo que encontramos habitualmente en las auditorías no es espectacular.

Permisos que se quedan en la interfaz. Un asistente de consulta documental montado sobre el gestor documental de la empresa necesita leer el repositorio, así que recibe una cuenta de servicio. Los permisos del usuario que pregunta llegan hasta el chat y se detienen antes de la búsqueda: la persona se autentica contra el asistente y la consulta la ejecuta la cuenta de servicio. El sistema funciona durante meses porque nadie pregunta por lo que no le corresponde. El día que alguien lo hace, y suele tratarse de un empleado curioso antes que de un atacante, el asistente le devuelve el contenido de una carpeta de recursos humanos o la documentación de otro cliente, bien redactado y con tono servicial. Sin exploit, sin herramienta y con una entrada de registro idéntica a la de una consulta legítima, en los casos donde existe registro.

Herramientas que nadie ha revisado. El asistente tiene seis o siete herramientas disponibles porque venían con el framework, y en producción utiliza dos. Las otras cinco siguen ahí, sin revisión y sin vigilancia, y en ocasiones sin que nadie del equipo recuerde su existencia. Permanecen inertes mientras nadie las invoque, aunque el modelo conoce que están disponibles: basta conducir la conversación hacia un objetivo que las necesite para que las use por iniciativa propia. Es exceso de capacidad de acción en estado puro, y se corrige borrando líneas de configuración.

Estos dos patrones no generan titulares, porque no dejan una captura que compartir. Aparecen cuando alguien va a buscarlos.

Respuestas desiguales según quién pregunta 

Que el asistente responda con un comentario racista, machista o despectivo hacia un colectivo es lo que estalla más rápido. Los modelos actuales incorporan bastantes más filtros de fábrica que los de hace unos años, aunque esos filtros ceden bajo presión, y la conversación de varios turnos es el terreno donde ceden antes. Una tarde de intentos y una grabación de pantalla bastan para documentarlo.

Existe una versión más silenciosa del mismo problema, y en nuestra experiencia resulta la más peligrosa. El asistente responde con un tono, un nivel de detalle o una disposición a ayudar distintos según cómo escriba la persona, qué nombre dé o en qué idioma pregunte. En un caso aislado nadie lo percibe. Se percibe en el agregado, y a esas alturas la organización lleva meses atendiendo peor a un grupo concreto de clientes sin haberlo decidido en ningún momento.

Las consecuencias siguen dos caminos. El reputacional actúa de inmediato: una captura circula en horas, el contexto se pierde por el camino y la marca queda asociada a esa frase mucho más tiempo del que cuesta corregir el prompt.

El jurídico avanza más despacio y cuesta más. En España, la Ley 15/2022, de 12 de julio, integral para la igualdad de trato y la no discriminación incluye la inteligencia artificial en su ámbito de aplicación y dedica su artículo 23 a los algoritmos y a los mecanismos de decisión automatizada. El Reglamento (UE) 2024/1689, conocido como Reglamento Europeo de Inteligencia Artificial, clasifica como de alto riesgo determinados usos vinculados al empleo o al acceso a servicios esenciales. Y el precedente de Air Canada marca una dirección clara para cualquier organización con un asistente público: los tribunales tratan al asistente como parte de la empresa que lo despliega.

Este riesgo tiene una particularidad incómoda. Ningún escáner lo detecta, así que hay que ir a buscarlo a propósito y con método.

La exposición del usuario final 

Casi todo el debate sobre este tema gira alrededor del daño a la empresa, lo cual resulta comprensible, porque la empresa paga la auditoría. Cuando el asistente atiende a pacientes, ciudadanos, clientes o empleados, la exposición mayor recae sobre la persona que está al otro lado.

Esa persona envía sus datos personales a un chat sin saber dónde se guardan, cuánto tiempo ni quién los consulta después. Si el aislamiento del contexto falla, puede recibir información que pertenece a otro usuario. Sin registro de la conversación, carece de manera de demostrar qué se le prometió. Y recibe respuestas escritas con seguridad impecable sobre asuntos serios, sin ninguna pista sobre su exactitud.

Ese último punto es el que más nos preocupa. Un modelo que desconoce algo rara vez lo admite: rellena el hueco, y bien redactado. Un profesional del sector identifica el error con relativa facilidad. Una persona mayor preguntando por un trámite, o alguien consultando una duda de salud a las tres de la mañana, se queda con la respuesta.

OWASP ha llegado por la vía de los datos a una conclusión parecida. En la edición 2026 del Top 10 para aplicaciones LLM, la desinformación asciende posiciones y presenta el mayor desajuste de toda la lista entre la percepción de los profesionales encuestados y el registro de incidentes reales. El cambio relevante afecta al encuadre más que al puesto: una respuesta segura y equivocada ha pasado a tratarse como problema de seguridad y ya no solo como problema de calidad.

Los límites del pentest tradicional 

Auditar la aplicación que aloja el chatbot sigue siendo necesario: autenticación, gestión de sesión, exposición de la API, transporte. Todo eso hay que hacerlo, y todo eso deja intacto el comportamiento del modelo, que es donde reside el riesgo nuevo.

El objeto de la prueba cambia. Aquí se comprueba si el asistente respeta sus propios límites, y el resultado se expresa como una tasa de éxito por categoría.

Ese formato tiene una implicación práctica. Una técnica que funciona en una fracción pequeña de los intentos sigue siendo explotable por cualquiera con paciencia, porque el coste de reintentar es cero. Y la medición caduca rápido: un cambio de versión del modelo o un retoque en el prompt puede reabrir lo que estaba cerrado.

Auditar esto una vez al año equivale a escanear vulnerabilidades una vez al año.

Las dos mitades de una auditoría de asistentes de IA 

El trabajo tiene dos mitades, y el marco de referencia es público.

La mitad adversarial. Se ataca el asistente en condiciones controladas y se mide una tasa de éxito por categoría, siguiendo el Top 10 de OWASP para aplicaciones LLM: inyección de instrucciones directa e indirecta (LLM01), fuga de información sensible (LLM02), exposición del contexto oculto (LLM08), que en la edición anterior se denominaba fuga del prompt de sistema, y tratamiento inseguro de la salida del modelo (LLM10). A eso se añade el abuso de la lógica de negocio concreta de cada cliente, que no figura en ninguna lista. Una parte del trabajo se automatiza con baterías amplias de ataques. Otra parte exige ejecución manual, porque las cadenas de varios turnos y el abuso del contexto específico de un negocio se escapan a las herramientas.

La mitad de arquitectura. Suele dar los hallazgos más graves, y se ordena con 4 preguntas:

• ¿Los permisos del usuario que pregunta se propagan hasta la búsqueda documental, o el servicio consulta con permisos de servicio?

• ¿Se valida lo que el modelo devuelve antes de ejecutar una acción con ese dato?

• ¿Qué puede invocar el asistente y qué necesitaría invocar realmente?

• ¿Queda registro de la conversación?

Con agentes de por medio se suman las preguntas del Top 10 agéntico: identidad y privilegios del agente, contención en tiempo de ejecución y envenenamiento de la memoria entre sesiones.

Buena parte de los hallazgos se corrige recortando lo que el asistente puede hacer, y los guardrails apenas los tocan. El exceso de capacidad de acción (LLM03) ha ganado posiciones en la lista de OWASP de este año por ese motivo.

El inventario previo. Antes de todo lo anterior hay una fase que parece burocrática y rara vez lo es: enumerar los asistentes que existen realmente en la organización, con responsable, datos accesibles y acciones permitidas. En varios proyectos, esa hoja de cálculo ha sido el primer hallazgo, porque aparecen dos o tres asistentes que nadie había declarado.

Obligaciones legales exigibles desde agosto de 2026 

Desde el 2 de agosto de 2026 resultan exigibles las obligaciones de transparencia del artículo 50 del Reglamento (UE) 2024/1689, que incluyen informar a la persona de que está interactuando con una máquina, con multas de hasta 15 millones de euros o el 3 % de la facturación global.

El Reglamento (UE) 2026/1744, conocido como Ómnibus digital sobre IA y en vigor desde el 27 de julio de 2026, ha retrasado buena parte de las obligaciones de los sistemas de alto riesgo al 2 de diciembre de 2027 para los sistemas del Anexo III y al 2 de agosto de 2028 para los del Anexo I. También ha flexibilizado la obligación de alfabetización del artículo 4 y ha introducido un periodo transitorio de 4 meses para el marcado de los sistemas comercializados antes del 2 de agosto de 2026. La transparencia del artículo 50 mantiene su fecha: quien opere un chatbot público ya está dentro del ámbito de aplicación.

El RGPD nunca dejó de aplicarse a los datos personales que entran por el chat. Y para las organizaciones sujetas al ENS o a NIS2, un asistente conectado a sistemas internos entra de lleno en el alcance.

Para ordenar el gobierno de todo esto, la referencia certificable es hoy la ISO/IEC 42001:2023.

Tres comprobaciones inmediatas 

Si el asistente ya está en producción y la auditoría no es inmediata, hay margen para reducir exposición sin obras mayores.

1. Verifica que avisa de que es una IA. Desde el 2 de agosto es obligatorio informar a la persona al inicio de la interacción. La comprobación lleva 30 segundos y es el único punto de esta lista que puede estar en incumplimiento hoy.

2. Levanta el inventario. Qué asistentes existen, quién los mantiene, a qué datos llegan y qué acciones pueden ejecutar. Se resuelve en media mañana de trabajo.

3. Asume que el prompt de sistema es público. Si contiene credenciales, reglas de precios o lógica de negocio sensible, conviene retirarla de ahí cuanto antes.

El asistente como sistema en producción 

Descrito con precisión, un chatbot de IA reúne las condiciones de un empleado recién incorporado: sin formación en seguridad, con acceso a sistemas internos, sin supervisor asignado y hablando con desconocidos a todas horas. Puesta así, la pregunta relevante deja de ser si merece una auditoría y pasa a ser cómo hemos llegado a tener varios en producción sin haberla hecho.

La parte útil de la respuesta es que el trabajo se conoce. Existe el marco público de OWASP, existe el criterio para separar lo que se corrige escribiendo de lo que exige decisiones de arquitectura, y existen las 4 preguntas del apartado anterior, que cualquier equipo puede responder esta semana sin ayuda externa. Los permisos que se aplican en la interfaz y se pierden en la capa de recuperación, las herramientas expuestas de más y la ausencia de registro exigen decisiones de arquitectura y de permisos, y su corrección rara vez implica rehacer el proyecto.

En Aktios hacemos red teaming de asistentes de IA en producción y dejamos el sistema documentado para una auditoría de ISO/IEC 42001. Si tienes un asistente atendiendo a clientes y no sabrías decir qué contesta ante una instrucción malintencionada, conviene averiguarlo en un entorno controlado antes de verlo en una captura de pantalla.

Solicita un Pentest