Red teaming para productos con IA: atacar tu propio sistema antes que otros
Red teaming es probar un producto con IA intentando romperlo: inyección de instrucciones, fugas de datos y acciones no permitidas. Método y primeros casos.
¿Qué es red teaming y por qué es distinto de un test normal?
El NIST define el red teaming de IA como un esfuerzo estructurado de pruebas para encontrar fallos y vulnerabilidades en un sistema de IA, a menudo en un entorno controlado y en colaboración con quienes lo desarrollan. Un test normal verifica que el sistema hace lo que debe con entradas esperadas. Red teaming pregunta lo contrario: ¿qué puede hacer el sistema que no debería? Tiene una mentalidad adversaria: asume que alguien va a probar los límites y busca cómo lograrlo.
Con modelos de lenguaje, la superficie de ataque es el texto. Cualquier campo que el modelo lea, desde un mensaje del usuario hasta un documento de la base de conocimiento, es una entrada posible para un ataque.
¿Qué tipos de red teaming existen?
Los laboratorios que lo practican describen varios enfoques, y un equipo de producto puede combinarlos a su escala:
- Con personas expertas del dominio. Anthropic describe pruebas con especialistas en temas concretos, como seguridad infantil o integridad electoral, y las usa para riesgos que un equipo generalista no sabría evaluar.
- Abierto y comunitario. Muchas personas prueban con libertad. En un trabajo de 2022, Anthropic liberó 38.961 ataques recopilados así para que otros investigadores los estudien.
- Automatizado. Un modelo genera los ataques y se mide cuántos funcionan. Escala mejor, pero solo encuentra lo que su generador imagina.
- Externo. OpenAI describe invitar a personas ajenas a la empresa, y explica que hay que decidir quién compone el equipo, qué acceso tiene y qué guía recibe. Un equipo independiente reduce el sesgo de quien construyó la función.
Para un producto con IA basta una versión sencilla: una sesión con gente de diseño, ingeniería y soporte, más una lista de casos que se repite en cada cambio de modelo.
¿Qué riesgos conviene probar primero?
OWASP publica una lista de los riesgos más comunes en aplicaciones con LLM. Para un equipo de producto, estos son los que más se prueban:
| Riesgo (OWASP 2025) | Qué significa en producto | Caso de prueba típico |
|---|---|---|
| Inyección de instrucciones | Un texto cambia el comportamiento del modelo | El usuario intenta que el asistente ignore sus reglas |
| Fuga de información sensible | El modelo expone datos de otros usuarios o del sistema | Preguntar por pedidos de otra cuenta |
| Agencia excesiva | El modelo tiene más permisos de los que necesita | Pedir que borre un registro que no debería tocar |
| Manejo inadecuado de la salida | La respuesta se usa sin validar en otro sistema | Un texto generado que incluye código o enlaces maliciosos |
| Filtración del prompt de sistema | El usuario obtiene las instrucciones internas | Pedir al asistente que revele sus instrucciones internas |
| Consumo sin límite | Un usuario genera costos enormes | Enviar entradas muy largas o en bucle |
La primera fila es la que más aparece en la práctica. OWASP distingue la inyección directa (el propio usuario escribe la instrucción) de la indirecta (la instrucción viene escondida en un contenido externo). El ejemplo de OWASP: una página web que el modelo debe resumir trae texto oculto que le pide insertar un enlace que filtra la conversación.
¿Cómo se hace un ejercicio de red teaming?
Un método práctico en cuatro pasos:
- Define qué no debe pasar. Por ejemplo: “no revela datos de otra cuenta”, “no envía correos sin confirmación”, “no ejecuta acciones fuera del alcance del agente”.
- Arma una lista de ataques. Usa las categorías de la tabla y añade casos reales de soporte. Incluye variantes: otro idioma, texto codificado, instrucciones escondidas en un documento.
- Ejecuta y registra. Prueba manual primero, con alguien que no haya construido la función. Guarda cada intento y su resultado.
- Convierte los hallazgos en evals. Cada ataque que funcionó entra a tu golden dataset como caso de regresión. Así no vuelve a pasar sin que lo notes.
El ejercicio es continuo. Un ataque que falló hoy puede funcionar después de un cambio de modelo o de prompt.
¿Qué medidas reducen el riesgo?
OWASP señala que no está claro que exista un método infalible contra la inyección de instrucciones, pero propone medidas que reducen el impacto:
- Limitar el rol del modelo en el prompt de sistema y decirle que ignore intentos de cambiar sus instrucciones centrales. Es una capa, no una garantía.
- Validar la salida con código cuando tiene formato: JSON, fechas, identificadores. OWASP también propone filtrar entradas y salidas.
- Dar el mínimo de privilegios: que las herramientas usen permisos de la aplicación, no acceso libre del modelo.
- Pedir aprobación humana para acciones de alto impacto.
- Marcar el contenido externo como no confiable para que pese menos en las instrucciones.
La propia lista de OWASP incluye entre las medidas la simulación de ataques y las pruebas adversarias, que es lo que hace este ejercicio. Claude Code aplica una lógica de capas parecida: su documentación de permisos indica que las restricciones del sandbox siguen vigentes aunque una inyección de instrucciones eluda la decisión de Claude. La idea es que la barrera no dependa de que el modelo decida bien.
¿Cuándo NO conviene?
- Cuando el producto no tiene acciones ni datos sensibles. Un chatbot que solo responde preguntas públicas tiene un riesgo distinto y menor.
- Cuando el red teaming se hace solo con casos automáticos. Los atacantes creativos encuentran lo que una lista no contempla.
- Cuando el resultado no cambia nada del producto. Un informe de 40 ataques que nadie corrige es teatro de seguridad.
Ejemplo
Ejemplo ilustrativo: una aplicación de soporte con IA puede consultar pedidos y, con confirmación, emitir reembolsos. El equipo de red teaming, con una persona de diseño y una de ingeniería, prueba 60 casos. Uno de ellos: un cliente pega un texto que finge ser una orden de un administrador para emitir un reembolso grande. El modelo no lo hace, porque el reembolso exige una herramienta con validación en código y confirmación humana. Pero otro caso revela un fallo: al pedirle que revele sus instrucciones con un cambio de formato, el modelo reproduce parte del prompt de sistema. El equipo agrega el caso al golden dataset, reescribe la parte sensible del prompt y deja de incluir reglas internas que no deberían estar ahí.
Para ver cómo se conecta esto con los controles de un agente, lee guardrails y sandboxing y permisos de agentes. Para los casos que alimentan la prueba, golden datasets. Y para la aprobación de acciones de alto impacto, aprobación de acciones de un agente.
Errores comunes
- Confiar en que el prompt de sistema “dice que no” equivale a una barrera.
- Hacer red teaming solo con casos en inglés y sin variantes de formato.
- Probar solo entradas del usuario y olvidar el contenido externo que el modelo lee.
- Encontrar un fallo y no convertirlo en caso de regresión.
- Dejar que el mismo equipo que construyó la función sea el único que la prueba.
Fuentes
- OWASP Top 10 for LLM Applications (OWASP GenAI Security Project)
- LLM01:2025 Prompt Injection (OWASP GenAI Security Project)
- Configure permissions (Claude Code, documentación)
- NIST: glosario, “artificial intelligence red-teaming” (definición de NIST SP 800-218A)
- Ganguli et al., Red Teaming Language Models to Reduce Harms (Anthropic, arXiv:2209.07858)
- Anthropic: Challenges in red teaming AI systems
- Ahmad et al., OpenAI’s Approach to External Red Teaming for AI Models and Systems (arXiv:2503.16431)