LLM red teaming

El LLM red teaming aplica la mentalidad de un pentesting a una aplicación con modelo detrás. El equipo sondea la superficie entera: si al modelo se le puede hacer un jailbreak que se salte su política, si la aplicación se puede secuestrar con prompt injection, si se pueden extraer datos sensibles (datos de entrenamiento, el prompt de sistema, contenido de otros usuarios) y si el modelo produce salidas dañinas o accionables contra el negocio. Las pruebas son estructuradas pero exploratorias: el operador itera, encadena éxitos parciales y sigue el comportamiento del modelo en vez de recorrer una lista fija, porque las respuestas del modelo no son deterministas y los fallos interesantes emergen de esa aplicación concreta, no de un prompt genérico.

El paso en falso habitual es acotar el ejercicio al modelo aislado, como si el riesgo fuera una respuesta mala. El riesgo que importa es la aplicación: un modelo con herramientas, con memoria y con acceso a datos, desplegado con permisos que dan por hecho que siempre va a ser servicial. A un atacante le da igual si el modelo «entiende» que lo están manipulando; le importa qué tiene permitido hacer una vez obedece. En la práctica, los hallazgos de mayor impacto son arquitectónicos, y un red team que solo cuenta prompts rechazados frente a prompts respondidos se los pierde enteros. El valor está en demostrar un camino completo desde una entrada preparada hasta un resultado real y no deseado.

Entregamos un informe a nivel de aplicación mapeado contra un marco reconocido, el OWASP Top 10 for LLM Applications, con cada hallazgo atado a su reproducción: la entrada, el comportamiento del modelo y el impacto aguas abajo. Los guardrails existentes se anotan con su tasa de esquiva, y la severidad la fija a qué llega un ataque que funciona, no si funcionó un prompt suelto. Esto es cómo hacemos un encargo de red team de IA, acotado al sistema desplegado y no al modelo a solas.