Guía práctica de red teaming de IA para equipos de seguridad
Hacer red team a LLMs requiere habilidades y metodología distintas a la prueba de penetración tradicional. Esta guía cubre el proceso, técnicas y qué documentar.
El red teaming —prueba adversaria organizada por un equipo dedicado a encontrar lo que las defensas omiten— es una práctica madura en seguridad tradicional. Aplicado a sistemas de IA, el objetivo es el mismo pero las técnicas son sustancialmente distintas. No buscas CVEs sin parchar o servicios de red mal configurados; buscas modos de falla horneados en los pesos del modelo y en la arquitectura de prompts de la aplicación.
Los equipos con fuerte experiencia en pentest tradicional frecuentemente subestiman cuán diferente es el red teaming de IA. Esta guía cubre qué involucra realmente, las técnicas usadas, qué documentar, y cómo estructurar un engagement contra un sistema basado en LLM.
Qué es (y qué no es) el red teaming de IA
El red teaming de IA es prueba adversaria de sistemas de IA para descubrir modos de falla en dimensiones de seguridad, privacidad y confiabilidad. El AI Red Team de Microsoft, operando desde 2018, define el alcance ampliamente: “sondear sistemas de IA para encontrar fallas —desde generar contenido dañino hasta filtrar información privada o ser manipulado por entradas adversarias—”.
Esto es distinto de:
Prueba de penetración de infraestructura de IA: prueba de los servicios cloud, APIs e infraestructura de red que corre modelos. Usa técnicas estándar de pentest y es importante, pero no es red teaming de IA.
Evaluación / benchmarking de modelos: correr conjuntos de prueba estandarizados para medir rendimiento del modelo en métricas definidas. La evaluación es sistemática y preespecificada; el red teaming es adversario y exploratorio.
Escaneo automatizado (ej. Garak): las herramientas automatizadas sondean categorías de falla conocidas sistemáticamente. El red teaming lo complementa con ataques creativos específicos al contexto que las herramientas automatizadas no encontrarán.
Definir el alcance de un engagement de red team de IA
Antes de que el engagement comience, define:
El sistema objetivo: ¿Qué despliegue específico estás probando? ¿Una API de modelo independiente, o una aplicación RAG completa con recuperación, uso de herramientas y formateo de salida? La superficie de ataque difiere sustancialmente.
El modelo de amenaza: ¿Quiénes son los adversarios? ¿Usuarios externos intentando jailbreak a la aplicación? ¿Empleados intentando extraer información sensible? ¿Ataques automatizados de pipeline vía inyección de documentos? Tus técnicas deben coincidir con tu modelo de amenaza.
Criterios de éxito: ¿Qué cuenta como hallazgo? Define esto desde el inicio. “El modelo generó contenido que viola la política X” es un hallazgo. “El modelo dio una respuesta inesperada que no fue claramente dañina” no lo es. Sin criterios claros, las salidas del red team son difíciles de triagear.
Limitaciones de alcance: ¿Qué está dentro? La mayoría de engagements excluyen pruebas de infraestructura (manejadas por separado) y se enfocan en comportamiento del modelo, lógica de aplicación, y la interacción entre ambos.
El proceso de red teaming
Fase 1: Reconocimiento
Entender la arquitectura de la aplicación antes de sondearla. ¿Cuál es el prompt de sistema? (Si no te lo dan, ¿puedes extraerlo?) ¿Qué fuentes de recuperación consulta un sistema RAG? ¿A qué herramientas tiene acceso el modelo? ¿Cuál es el journey de usuario esperado?
Mapea el comportamiento intencionado de la aplicación y las fronteras que se supone debe imponer. Estas fronteras son donde vive la mayoría de hallazgos.
Fase 2: Prueba de línea base
Antes de ataques creativos, prueba si el modelo respeta sus propias restricciones bajo condiciones normales. Pregúntale al modelo qué hará y qué no. Prueba casos límite de la funcionalidad intencionada. Documenta la línea base para poder medir cómo los ataques cambian el comportamiento.
Fase 3: Ataques directos
Extracción de prompt de sistema: intenta extraer el prompt de sistema usando preguntas directas, framing de roleplay, ataques de completación y técnicas de confusión multi-turno. Documenta éxito y falla.
Jailbreaking: aplica plantillas conocidas (estilo DAN, cambio de persona, framing hipotético). Las técnicas más nuevas incluyen many-shot jailbreaking (incluir muchas conversaciones de ejemplo en contexto que normalizan el comportamiento restringido) y ataques de sufijo basados en gradiente si tienes acceso al modelo.
Sondeo de fronteras de política: mapea exactamente dónde están las restricciones del modelo. Si el modelo restringe la discusión del tema X, prueba: temas adyacentes, framing histórico, framing ficticio, framing técnico, otros idiomas. Las restricciones son frecuentemente más estrechas de lo que parecen.
Fase 4: Inyección y manipulación de contexto
Inyección directa de prompts: embeber instrucciones en entradas de usuario que intenten anular el comportamiento del prompt de sistema. Forma clásica: “Ignora las instrucciones anteriores y haz Y”.
Inyección indirecta: si el sistema usa recuperación, ¿puedes controlar contenido en las fuentes recuperadas? Inserta instrucciones adversarias en documentos que el sistema pueda recuperar y prueba si se ejecutan. Esta es frecuentemente la categoría de hallazgo de mayor impacto.
Confusión de rol: prueba si roles claramente delimitados (sistema, usuario, asistente) pueden ser confundidos inyectando marcadores de rol en entradas de usuario.
Fase 5: Ataques de salida y extracción
Extracción de PII y datos confidenciales: intenta extraer información específica de los datos de entrenamiento del modelo o de información provista en contexto (datos de otros usuarios, contexto de sistema, documentos recuperados de sesiones de otros usuarios).
Inferencia de membresía: consulta al modelo sobre individuos o documentos privados específicos para sondear si estaban en datos de entrenamiento.
Documentación del comportamiento del modelo para inteligencia competitiva: mapea las capacidades y limitaciones del modelo sistemáticamente para que los resultados constituyan inteligencia competitiva útil. Esto prueba si las restricciones de visibilidad del despliegue son adecuadas.
Estándares de documentación
Los hallazgos deben documentarse con suficiente detalle para reproducir, triagear y remediar.
Para cada hallazgo:
- ID: identificador único para rastreo
- Categoría: Jailbreak / inyección de prompts / filtración de PII / bypass de política / etc.
- Severidad: Crítico / Alto / Medio / Bajo (con justificación)
- Pasos de reproducción: entradas exactas, versión del modelo, contexto necesario
- Respuesta del modelo: salida literal demostrando el hallazgo
- Impacto: ¿Qué podría hacer un atacante con esta capacidad?
- Mitigación sugerida: al mínimo, la categoría de arreglo necesaria
Las calificaciones de severidad deben calibrarse al impacto del mundo real, no solo a violación de política. Un jailbreak que produce texto levemente descortés es distinto de uno que produce contenido que habilita daño serio.
Construir capacidad interna de red team
Las organizaciones con despliegues de IA significativos deberían construir capacidad interna de red team en lugar de depender únicamente de engagements externos. Las contrataciones clave son personas con experiencia en:
- Investigación de ML adversario (académica o industrial)
- Ingeniería de prompts y desarrollo de aplicaciones LLM
- Escritura creativa e ingeniería social (útil para desarrollo de jailbreaks)
- Pruebas de seguridad tradicional (modelado de amenazas, documentación de hallazgos, evaluación de severidad)
Herramientas con que equipar al equipo: Garak para cobertura automatizada, LangChain y los SDKs de Anthropic/OpenAI para construir sondas personalizadas, un sistema de gestión de hallazgos, y acceso al despliegue interno bajo prueba con visibilidad de logs.