AI Red Teaming: cómo evaluar la seguridad de modelos de IA y LLMs

El AI red teaming es la evaluación ofensiva sistemática de modelos de inteligencia artificial y aplicaciones basadas en LLM frente a adversarios reales, con el objetivo de descubrir comportamientos inseguros, fugas de información, eludir alineamientos y abusos de herramientas antes de que lo haga un atacante. A diferencia del pentesting tradicional, que se centra en vulnerabilidades de software y configuración, el AI red teaming trabaja sobre una superficie compuesta por prompts, embeddings, contextos recuperados por RAG, herramientas conectadas al modelo y, en algunos casos, los propios datos de entrenamiento. Las técnicas adversariales son distintas, los criterios de éxito también, y la disciplina exige perfiles que combinen seguridad ofensiva clásica con conocimientos de machine learning aplicado.

Lo esencial

• El AI red teaming evalúa modelos y aplicaciones LLM contra técnicas adversariales, no solo bugs de código.
• Cubre prompt injection directa e indirecta, jailbreaking, abuso de tools, extracción de system prompt, model extraction y data poisoning.
• Se apoya en frameworks como MITRE ATLAS, NIST AI RMF, OWASP Top 10 for LLM Applications y guías de UK AISI.
• El EU AI Act y DORA están empujando el testing adversarial obligatorio para sistemas de alto riesgo y servicios financieros críticos.
• Un programa serio combina red team interno continuo, red team externo independiente y vendor evaluation antes de adopción.

Qué distingue AI red teaming del pentesting tradicional

El pentesting tradicional asume un sistema de software con código, dependencias, configuración y, en su caso, infraestructura. El atacante busca vulnerabilidades técnicas conocidas, errores lógicos en la aplicación o fallos de hardening. El AI red teaming amplía esa superficie en tres direcciones.

La primera dirección es la superficie de entrada. Los modelos reciben prompts de usuario, pero también consumen contexto adicional: documentos recuperados por sistemas RAG, contenido de páginas web cargadas por agentes, salidas de herramientas externas y, en arquitecturas multi-agente, mensajes de otros modelos. Cualquiera de esos canales puede vehicular instrucciones adversariales que el modelo trata como legítimas.

La segunda dirección son las técnicas. El AI red teamer no busca un buffer overflow, busca formulaciones que cambien el comportamiento del modelo: perturbaciones adversariales, role playing, codificaciones que evaden filtros, gradientes en ataques white-box contra modelos open weights y permutaciones automatizadas en black-box. La frontera entre input legítimo e input malicioso es difusa, y los filtros basados en lista negra suelen ceder ante variantes léxicas.

La tercera dirección es el criterio de éxito. En un pentest tradicional el objetivo suele ser RCE, escalada de privilegios o exfiltración de datos vía vulnerabilidades. En AI red teaming los objetivos incluyen extraer información que el modelo debería rechazar (datos PII memorizados, system prompts, propiedad intelectual), saltarse el alignment para producir contenido prohibido, manipular la salida hacia decisiones sesgadas en sistemas que afectan a personas y forzar consumo desproporcionado de recursos. El daño no siempre es técnico: puede ser reputacional, regulatorio o de confianza.

Una organización que solo audita la capa de aplicación por encima del modelo deja sin cubrir la mayor parte del riesgo introducido por la IA generativa.

Frameworks y referencias

La disciplina ha madurado lo suficiente como para apoyarse en marcos públicos. Conviene conocerlos para que el alcance del ejercicio sea trazable y los hallazgos comparables.

MITRE ATLAS es la adaptación de MITRE ATT&CK al ámbito de sistemas de IA. Cataloga tácticas y técnicas adversariales contra modelos de machine learning, con casos reales documentados. Su valor principal es servir como taxonomía común al describir hallazgos y construir matrices de cobertura.

NIST AI Risk Management Framework propone un proceso de gestión de riesgo de IA con cuatro funciones: Govern, Map, Measure y Manage. El red teaming entra en Measure como mecanismo de evaluación adversarial. El perfil específico para IA generativa publicado en 2024 desarrolla controles concretos.

OWASP Top 10 for LLM Applications lista las diez categorías de riesgo más relevantes en aplicaciones que integran modelos. Es una referencia operativa para definir baseline de cobertura en un primer ejercicio: prompt injection, insecure output handling, training data poisoning, model denial of service, supply chain vulnerabilities, sensitive information disclosure, insecure plugin design, excessive agency, overreliance y model theft.

Las evaluaciones publicadas por UK AI Safety Institute y los Responsible Scaling Policies de Anthropic ofrecen ejemplos públicos de cómo laboratorios y reguladores estructuran pruebas pre-deployment. Aunque están pensadas para modelos frontera, varias metodologías son aplicables a entornos empresariales que integran modelos comerciales.

Técnicas de ataque comunes

Cada técnica se trabaja con objetivos, indicadores de éxito y prerrequisitos diferentes. Estas son las más habituales en un ejercicio empresarial.

Direct prompt injection

El usuario envía instrucciones que intentan sobrescribir las directrices del sistema. Las primeras variantes (DAN, role play como personajes que ignoran restricciones, prompts en idiomas con menos cobertura en alineamiento) son hoy mayoritariamente bloqueadas por modelos comerciales actualizados, pero variantes más sutiles siguen siendo viables. Un red teamer prueba reformulaciones, encadenamientos por turnos, codificaciones (base64, leet, traducciones), prompts adversariales generados con métodos como GCG y combinaciones con contexto que justifique la transgresión. El objetivo no es siempre la generación de contenido vetado: a menudo basta con que el modelo revele su prompt de sistema, ignore un filtro de privacidad o cambie de tono en un dominio crítico.

Indirect prompt injection

Aquí el atacante no interactúa directamente con el modelo. Inyecta instrucciones en contenido que el modelo o un agente termina consumiendo: una página web indexada por un buscador conectado, un PDF cargado en un sistema RAG, una incidencia de Jira leída por un asistente, un correo procesado por un copiloto. Cuando el modelo lee ese contenido, lo trata como contexto y, si no hay separación estricta de privilegios entre instrucciones del sistema y datos del usuario, sigue las órdenes embebidas. RAG poisoning es la variante específica que consiste en colocar documentos manipulados en la base vectorial. Es una de las clases de ataque más peligrosas en arquitecturas con agentes porque el usuario final puede ser víctima sin interactuar nunca con el atacante.

System prompt extraction

Las aplicaciones definen comportamiento mediante prompts de sistema que contienen instrucciones, identidad del asistente, restricciones y, a veces, secretos como API keys mal colocadas o nombres de herramientas internas. Extraer ese prompt revela la arquitectura, facilita ataques posteriores y, en muchos casos, expone propiedad intelectual del producto. Las técnicas incluyen peticiones directas en distintos idiomas, simulación de modos debug, juegos de roles que pidan repetir todo el contexto previo y ataques side channel basados en longitud o latencia.

Tool abuse y excessive agency

Los modelos modernos no se limitan a generar texto: ejecutan herramientas, hacen llamadas a APIs, consultan bases de datos, envían correos y, en arquitecturas agénticas, encadenan acciones autónomas. Cuando un atacante consigue influir en las decisiones del modelo, puede convertirlo en proxy ejecutor. El red teamer evalúa si las herramientas tienen scopes mínimos, si existen confirmaciones humanas en acciones sensibles, si el agente puede ser dirigido a invocar funciones no previstas y si la información devuelta por una herramienta puede contener instrucciones que cambien el comportamiento. La categoría OWASP de excessive agency cubre exactamente este riesgo: permisos amplios convierten un agente comprometido en una pieza de malware con credenciales legítimas.

Embedding inversion y membership inference

Los sistemas RAG y muchas aplicaciones modernas almacenan embeddings, representaciones vectoriales de texto. Investigación reciente ha mostrado que es posible reconstruir parcialmente el texto original a partir de embeddings, sobre todo con modelos populares y textos cortos. Membership inference va un paso más allá: determinar si un texto concreto formó parte del corpus de entrenamiento, lo que tiene implicaciones de privacidad evidentes en modelos entrenados con datos sensibles. Ambos vectores se prueban cuando el alcance incluye la base vectorial o el modelo base.

Model extraction e IP theft

Mediante un volumen elevado de consultas dirigidas a un modelo cerrado, un atacante puede entrenar un modelo aproximado que replique el comportamiento del original. En modelos especializados (clasificadores propietarios, modelos fine-tuned con datos exclusivos), esto equivale a robo de propiedad intelectual. El red teamer evalúa límites de rate, detección de patrones de consulta sistemática y, en casos avanzados, marcas de agua incorporadas a las respuestas.

Data poisoning

Existe en dos momentos. Training-time poisoning ocurre cuando se contamina el corpus durante el entrenamiento o el fine-tuning, introduciendo backdoors que se activan ante triggers específicos. Es relevante para organizaciones que entrenan modelos propios o aplican fine-tuning con datos de terceros. Inference-time poisoning afecta a sistemas con aprendizaje continuo o feedback loops sin moderación: si el modelo aprende de interacciones de usuarios sin filtrado, un atacante puede empujar gradualmente su comportamiento.

Hallucination weaponization

Los modelos producen contenido plausible pero falso. Un atacante puede explotar esta tendencia para varios objetivos: convencer a un agente de instalar paquetes que no existen y que el atacante registra justo a tiempo (slopsquatting), inducir referencias jurídicas falsas en flujos legales automatizados o forzar al modelo a respaldar afirmaciones controvertidas con citas inventadas. El red teamer mide tasas de alucinación en dominios críticos y prueba prompts adversariales diseñados para maximizarlas.

Adversarial perturbation

En modelos de visión, audio o clasificadores específicos, cambios imperceptibles en la entrada pueden alterar la salida. En el contexto LLM, técnicas como GCG generan sufijos aparentemente aleatorios que disparan comportamientos prohibidos con tasas no despreciables. White-box, cuando el equipo tiene acceso a los pesos y puede usar gradientes. Black-box, cuando solo dispone de acceso vía API y debe usar técnicas de búsqueda y transferencia desde modelos abiertos.

Metodología de un ejercicio AI red team

Un ejercicio serio sigue una secuencia ordenada en lugar de aplicar técnicas al azar.

Fase 1: alcance. Definir qué se evalúa, qué queda fuera, qué entornos son válidos (producción, staging, modelo aislado), qué tipos de cuentas se utilizan y qué reglas de engagement aplican. Si el modelo está conectado a sistemas reales, hay que decidir hasta dónde llega la prueba antes de pararse.

Fase 2: threat model. Identificar adversarios plausibles (usuario malicioso, empleado interno, atacante externo con acceso a contenido indirecto, competidor que extrae IP), objetivos creíbles y activos críticos. Una aplicación médica y un asistente de marketing tienen modelos de amenaza muy distintos.

Fase 3: reconocimiento. Mapear superficie: prompts visibles, parámetros configurables, herramientas conectadas, fuentes RAG, integraciones, controles previos, telemetría disponible. Documentar la arquitectura antes de atacar.

Fase 4: testing. Ejecutar técnicas priorizadas por relevancia para el threat model. Combinar prompts manuales con suites automatizadas. Documentar cada hallazgo con prompt completo, salida obtenida, criterio de impacto y reproducibilidad.

Fase 5: reporting. Entregable con resumen ejecutivo, matriz de cobertura sobre framework elegido (ATLAS, OWASP LLM), hallazgos con severidad, recomendaciones técnicas (filtros, guardrails, separación de privilegios, monitorización) y, cuando aplica, recomendaciones de proceso (revisión de prompts, gestión de modelos, política de uso).

En tooling, los marcos más utilizados en 2026 son Garak (suite de probes con cientos de tests prefabricados, mantenida por NVIDIA), PyRIT (framework de Microsoft orientado a equipos red, soporta orquestación multi-turno), Promptfoo (más enfocado a evaluación pero útil en regresión de defensas) y Counterfit (cobertura más amplia de modelos clásicos de ML, no solo LLM). Para ataques específicos hay implementaciones de referencia en GitHub de GCG, AutoDAN y técnicas relacionadas.

Encaje regulatorio EU AI Act y DORA

El EU AI Act introduce obligaciones explícitas de testing adversarial para sistemas clasificados como de alto riesgo. Los proveedores deben documentar evaluaciones de robustez, exactitud y ciberseguridad, y los modelos de propósito general con riesgo sistémico tienen requisitos adicionales que incluyen red teaming como mecanismo de descubrimiento de riesgos. El régimen es escalonado, con plazos que ya están vigentes para prácticas prohibidas y modelos GPAI, y otros que entran en aplicación en 2026 y 2027.

DORA, ya en vigor para entidades financieras en la UE, no menciona IA explícitamente, pero su exigencia de pruebas de penetración dirigidas por amenazas (TLPT) cada tres años para entidades significativas alcanza a los sistemas críticos para servicios financieros. Cuando esos sistemas integran modelos de IA en flujos materiales (scoring, detección de fraude, atención automatizada), el TLPT debe incorporar técnicas adversariales contra los componentes de IA. Lo mismo aplica al testing de proveedores TIC bajo el marco de gestión de riesgo de terceros.

Para organizaciones sujetas a NIS2 que utilicen IA en procesos críticos, el principio es equivalente: las medidas técnicas y organizativas obligatorias incluyen evaluaciones periódicas de seguridad, y omitir el componente de IA no es defendible si afecta a la disponibilidad o integridad del servicio esencial.

AI red team interno, externo y vendor evaluation

Las tres modalidades cumplen funciones distintas y no son intercambiables.

El red team interno trabaja de forma continua, conoce la arquitectura, participa en el diseño de guardrails y aporta retroalimentación rápida a equipos de producto. Es ideal para regresión, evaluación de cada cambio relevante y construcción de catálogos propios de probes adaptados a los casos de uso de la organización. Su limitación natural es el sesgo: quien construye el sistema rara vez encuentra todos sus puntos ciegos.

El red team externo aporta perspectiva independiente, técnicas que el equipo interno no domina y credibilidad en informes destinados a reguladores, auditores y clientes. Su cadencia típica es anual o semestral, con ejercicios de duración acotada (cuatro a ocho semanas en la mayoría de programas serios). Es la modalidad exigida implícitamente cuando hay obligaciones regulatorias o auditorías externas.

La vendor evaluation se realiza antes de adoptar un modelo o servicio de IA de tercero. Cubre dos preguntas: hasta dónde llega la seguridad inherente del proveedor y cómo se comporta cuando se integra con datos y contexto propios. Modelos comerciales aprueban regularmente evaluaciones genéricas pero pueden fallar con datos sensibles del cliente o instrucciones de sistema mal diseñadas. La evaluación de proveedor incluye revisión documental, pruebas funcionales y un mini ejercicio adversarial con datos representativos del entorno real.

La gobernanza recomendable combina las tres: interno continuo, externo periódico, vendor evaluation antes de cada adopción material.

Casos públicos

Los casos publicados en los últimos años ilustran categorías de ataque sin necesidad de inventar detalles.

Durante 2023 y 2024 la comunidad documentó numerosos jailbreaks contra ChatGPT (DAN y sus variantes, prompts en idiomas con menor cobertura de alineamiento, juegos de roles). OpenAI fue cerrando muchas de las variantes específicas, pero el patrón muestra que el alineamiento no es robusto frente a esfuerzo adversarial sostenido.

En 2024 se publicaron varios escenarios de prompt injection indirecto contra Microsoft Copilot, en los que contenido externo (correos, documentos compartidos) inducía comportamientos no previstos cuando el asistente lo procesaba. Microsoft introdujo mitigaciones a través de guardrails reforzados y avisos explícitos al usuario.

Google ha gestionado divulgaciones de vulnerabilidades en Gemini relacionadas con manejo de contexto y filtros de salida, integradas progresivamente en su programa de bug bounty extendido a IA.

Estos casos comparten un patrón: ninguna de las grandes plataformas pretende ofrecer un modelo inmune a abusos, y todas han establecido programas formales de red teaming, bug bounty específico y divulgación responsable como parte de su ciclo de vida.

Preguntas frecuentes

¿AI red teaming es legal en producción?

Solo con autorización explícita por contrato. Probar modelos comerciales más allá de los términos de uso es problemático y, en algunos casos, vulnera ToS. Para sistemas propios, conviene firmar reglas de engagement antes del ejercicio, con franja horaria, criterios de parada y notificación inmediata si se descubren incidentes en curso no relacionados con la prueba.

¿Cambia el enfoque entre modelos open source y APIs cerradas?

Sí. Con modelos open weights se puede hacer testing white-box: gradientes, fine-tuning adversarial, análisis interno. Con APIs cerradas el ejercicio es black-box, basado en consultas y transferencia de ataques generados sobre modelos abiertos similares. Ambos escenarios son legítimos y útiles, pero las técnicas y el coste computacional cambian.

¿Hay AI red teaming automatizado?

Parcialmente. Garak, PyRIT y herramientas similares automatizan una parte significativa del trabajo repetitivo (catálogos de probes, generación de variantes, evaluación de salidas). Sin embargo, los hallazgos de mayor impacto siguen requiriendo creatividad humana, especialmente en encadenamientos multi-turno, abuso específico de herramientas y prompt injection contextual. La práctica madura combina ambas vías.

¿Quién contrata AI red team?

En 2026 el comprador típico es CISO, director de IA o responsable de gobernanza de IA. En entidades financieras, también participa la función de riesgo operativo. En organizaciones reguladas por EU AI Act como proveedores de alto riesgo, la decisión suele estar formalizada en el sistema de gestión de calidad y firmada al nivel ejecutivo correspondiente.

¿Cuánto tarda un ejercicio típico?

Entre cuatro y ocho semanas para un programa empresarial estándar. Una aplicación LLM con RAG y dos o tres herramientas suele cubrirse en cuatro a cinco semanas: una de scoping y threat modeling, dos a tres de testing efectivo y una de reporting. Sistemas multi-agente complejos o entornos con varios modelos integrados requieren más tiempo.

¿Qué entregables se obtienen?

Informe técnico con hallazgos clasificados por severidad, matriz de cobertura contra el framework elegido, evidencias reproducibles, recomendaciones priorizadas (técnicas y de proceso) y, opcionalmente, una sesión de transferencia con el equipo de ingeniería. Un buen ejercicio deja a la organización con un baseline medible y un plan de mitigación accionable.

Recursos relacionados

• Qué es prompt injection y cómo se ataca a aplicaciones LLM
• OWASP Top 10 para LLM explicado
• Qué es red team: guía para empresas
• Pentesting vs red team: diferencias clave
• Qué es MITRE ATT&CK: tácticas y técnicas

AI red teaming con Secra

En Secra ejecutamos programas de AI red teaming adversarial de cuatro a ocho semanas, con tooling propio integrado con Garak y PyRIT, threat models específicos por sector (financiero, salud, industrial, sector público) y entregables alineados con MITRE ATLAS, OWASP Top 10 for LLM Applications y los requisitos del EU AI Act. Trabajamos tanto sobre aplicaciones LLM en producción como sobre vendor evaluation antes de adopción y sobre sistemas agénticos con herramientas conectadas.

Si su organización está desplegando IA generativa en flujos materiales y necesita un ejercicio adversarial serio antes del go-live o como parte de su programa anual, puede contactarnos en secra.es/contacto para una conversación inicial y definir alcance.