Red teaming de IA: auditoría de seguridad de chatbots y agentes de IA

El red teaming de IA es una auditoría de seguridad ofensiva hecha a medida de los sistemas de inteligencia artificial: un equipo autorizado intenta engañar, manipular y abusar de tu chatbot o tu agente de IA para descubrir qué puede salir mal antes de que ocurra en producción. Si tu empresa ya tiene un asistente en la web, un agente conectado al CRM o un buscador interno sobre documentos, esta es la prueba que te dice si aguanta un uso malintencionado.

Qué es el red teaming de sistemas de IA

El red teaming de IA es un ejercicio de pruebas estructurado para encontrar fallos y vulnerabilidades en un sistema de IA, normalmente en un entorno controlado y en colaboración con quien lo desarrolla. Así lo define el perfil de IA generativa del NIST, el NIST AI 600-1, que lo recomienda como parte de la gestión de riesgos, tanto antes como después de poner el sistema a disposición del público.

En la práctica, en una empresa se usa con dos sentidos que conviene distinguir:

• Red teaming del modelo: comprobar si el modelo genera contenido dañino, sesgado o falso. Lo hacen sobre todo los fabricantes de modelos.
• Red teaming de la aplicación: comprobar la seguridad del sistema completo que has construido: el prompt de sistema, los datos a los que accede, las herramientas que puede usar, los permisos y las integraciones. Es lo que más le importa a una empresa que usa Claude, OpenAI o un modelo abierto dentro de sus procesos.

La guía de red teaming de OWASP GenAI propone abordarlo en cuatro áreas: evaluación del modelo, pruebas de la implementación, evaluación de la infraestructura y análisis del comportamiento en ejecución.

En qué se diferencia de un pentest clásico

Un pentest clásico y un red teaming de IA comparten mentalidad, pero no técnicas. Estas son las diferencias principales:

Por eso un sistema de IA necesita las dos cosas: el pentest clásico de la API, la web y la infraestructura que lo rodean, y pruebas específicas del comportamiento del modelo dentro de tu aplicación. Hablamos de la parte clásica en nuestros servicios de ciberseguridad.

Qué se prueba en una auditoría de seguridad de chatbots y agentes

Una auditoría de seguridad de un chatbot o agente de IA prueba cómo se puede manipular el sistema y qué daño puede causar si se consigue. Las familias de pruebas coinciden en buena parte con el OWASP Top 10 para aplicaciones LLM.

Prompt injection directa e indirecta

La prompt injection es el riesgo número uno de la lista de OWASP de 2025. La directa ocurre cuando el propio usuario escribe instrucciones que alteran el comportamiento del modelo. La indirecta llega a través de contenido externo que el sistema lee: una web, un PDF, un correo, un ticket o un documento indexado. La indirecta es la más peligrosa en agentes, porque el atacante no necesita hablar con el chatbot: le basta con dejar el texto donde el agente lo vaya a leer. La explicamos a fondo en qué es la prompt injection y cómo defenderse.

Jailbreaks

Un jailbreak es una forma de prompt injection cuyo objetivo es que el modelo abandone sus reglas de seguridad por completo: juegos de rol, instrucciones fragmentadas, idiomas o codificaciones poco habituales, conversaciones largas que van desplazando el contexto. Se prueba si el asistente acaba diciendo o haciendo algo contrario a su política de uso.

Fuga del prompt de sistema y de datos

Se intenta que el sistema revele su prompt de sistema, sus reglas internas o datos a los que tiene acceso: documentos de otros usuarios, datos personales, información de la base de conocimiento que no debería mostrar a ese perfil. En sistemas RAG se prueba además si los permisos de los documentos se respetan al recuperar información, un punto que tratamos en seguridad en sistemas RAG.

Abuso de herramientas y permisos del agente

En un agente de IA el riesgo grande no es lo que dice, sino lo que hace. Se prueba si se le puede convencer de usar sus herramientas para algo no previsto: enviar correos, modificar registros del CRM, ejecutar código, leer archivos fuera de su ámbito o encadenar acciones. OWASP lo llama «agencia excesiva». Aquí se revisan los permisos de cada herramienta, las credenciales que usa el agente, los servidores MCP conectados (ver seguridad en MCP) y los controles del entorno de ejecución que describimos en el harness de agentes de IA.

Exfiltración

Se comprueba si un atacante puede sacar datos fuera combinando inyección y herramientas: por ejemplo, haciendo que el agente incluya información sensible en una URL, en una imagen que se carga desde un servidor externo, en un correo o en una llamada a una API.

Salidas inseguras que acaban en otros sistemas

Lo que genera el modelo a menudo no se queda en pantalla: se inserta en una web, se ejecuta como consulta SQL, se pasa a un intérprete o se guarda en el ERP. Se prueba si esa salida se valida y escapa como cualquier otra entrada no confiable, o si permite ataques clásicos como XSS o inyección a través del modelo.

Denegación por coste

Los modelos se pagan por uso. OWASP describe como «Denial of Wallet» el abuso del modelo de pago por uso para generar costes desproporcionados. Se prueban límites de tamaño de entrada y salida, número de peticiones, bucles de herramientas en agentes y cuotas por usuario.

Metodología de un red teaming de IA

Un red teaming de IA serio sigue un proceso parecido al de cualquier auditoría ofensiva, adaptado a las particularidades de la IA.

1. Alcance y autorización

Se define por escrito qué sistemas se prueban (entorno de pruebas o producción), qué herramientas y datos están en juego, qué está fuera de alcance, las ventanas de prueba y quién autoriza. Conviene acordar también límites de gasto en las API del modelo y cómo se tratarán los datos que aparezcan durante las pruebas.

2. Modelado de amenazas

Antes de lanzar ataques se dibuja el sistema: quién puede hablar con él, qué fuentes lee, qué herramientas tiene, con qué permisos y qué es lo peor que podría pasar. De ahí salen los escenarios prioritarios. MITRE ATLAS ayuda en esta fase: es una base de conocimiento abierta de tácticas y técnicas de ataque contra sistemas de IA, construida a partir de ataques reales y demostraciones de equipos de red teaming, con filtros para IA predictiva, generativa y agéntica.

3. Pruebas manuales y automatizadas

Las pruebas se combinan:

• Manuales, por especialistas que adaptan los ataques al contexto del negocio: el lenguaje del sector, los documentos reales, los flujos del agente. Es donde aparecen los fallos más graves.
• Automatizadas, con baterías de ataques conocidos que se repiten muchas veces para medir con qué frecuencia funciona cada uno, algo imprescindible por el comportamiento probabilístico de los modelos.

El NIST AI 600-1 contempla también ejercicios mixtos en los que la propia IA generativa ayuda a generar ataques junto a equipos humanos.

4. Informe con evidencias y correcciones

El informe recoge cada hallazgo con su evidencia reproducible (conversación, documento usado, acción provocada), su impacto, la frecuencia con la que se reproduce y una corrección concreta. Las correcciones rara vez son «mejorar el prompt»: suelen ser reducir permisos, separar datos de instrucciones, añadir confirmación humana en acciones sensibles, validar salidas, filtrar fuentes o limitar consumo.

5. Re-test

Tras aplicar las correcciones se repiten las pruebas que fallaron, y las automatizadas se incorporan al ciclo de desarrollo para detectar regresiones.

Marcos de referencia

Estos tres marcos dan estructura y lenguaje común a un red teaming de IA:

• OWASP GenAI Security Project: el Top 10 para aplicaciones LLM 2025 (prompt injection, divulgación de información sensible, cadena de suministro, envenenamiento de datos y modelos, gestión inadecuada de salidas, agencia excesiva, fuga del prompt de sistema, debilidades en vectores y embeddings, desinformación y consumo ilimitado) y la guía específica de red teaming.
• MITRE ATLAS: el equivalente para IA del conocido MITRE ATT&CK, útil para modelar amenazas y clasificar hallazgos.
• NIST AI 600-1: el perfil de IA generativa del marco de gestión de riesgos del NIST. Entre sus acciones sugeridas incluye hacer red teaming para evaluar la resistencia frente a ataques como la prompt injection y frente a la revelación de información personal, confidencial o protegida.

Ninguno es obligatorio para una empresa española, pero usarlos facilita comparar resultados entre auditorías y demostrar diligencia ante clientes, auditores o, en su caso, autoridades.

Cada cuánto hacer red teaming de IA

El red teaming de IA no es un trámite único, porque el sistema cambia aunque tu código no lo haga. Recomendamos hacerlo:

• Antes de pasar a producción cualquier chatbot o agente expuesto a clientes o con acceso a datos o herramientas internas.
• Tras cambiar de modelo o de versión, porque cada modelo reacciona distinto a los mismos ataques.
• Tras añadir herramientas, permisos, servidores MCP o fuentes de datos, que amplían lo que el agente puede hacer.
• Tras cambios importantes en el prompt de sistema o en los flujos del agente.
• De forma periódica, con una batería automatizada en cada despliegue y un ejercicio manual al menos una vez al año en los sistemas críticos.

Cómo te ayudamos en Hive Mind Solutions

En Hive Mind Solutions combinamos experiencia en ciberseguridad y en desarrollo de agentes de IA, RAG e integraciones con MCP, así que sabemos dónde suelen fallar estos sistemas. Hacemos red teaming de chatbots y agentes con alcance y autorización por escrito, pruebas manuales y automatizadas alineadas con OWASP, MITRE ATLAS y NIST, un informe con evidencias y correcciones priorizadas, y el re-test posterior. Trabajamos en remoto con empresas de toda España, con precios muy difíciles de batir.

Conoce nuestro servicio de seguridad y cumplimiento en IA y nuestros servicios de ciberseguridad y pentesting, o cuéntanos qué sistema de IA quieres auditar.