El red teaming manual tiene un límite conocido: caduca. El ejercicio encuentra doce problemas, el equipo corrige ocho, y al mes siguiente alguien conecta una herramienta nueva o el proveedor actualiza el modelo y nadie sabe si esos ocho siguen corregidos. Volver a convocar al equipo completo cada vez que cambia una línea del prompt no es viable, y esperar al próximo ejercicio anual significa operar a ciegas durante once meses.
La salida es tratar las pruebas adversariales como se trata cualquier otra prueba: un conjunto de casos versionado en el repositorio, junto al código que evalúa, que se ejecuta automáticamente cuando algo cambia. No reemplaza al ejercicio manual —la creatividad humana sigue siendo la que encuentra lo nuevo— pero se queda con lo que ya se encontró y evita que vuelva.
Qué casos incluir
La tentación inicial es descargar una colección grande de prompts adversariales de internet y ejecutarla. Sirve poco: esos casos prueban al modelo, y a tu organización le importa su sistema. Un conjunto de cuarenta casos propios vale más que dos mil genéricos.
Las cuatro familias que recomendamos incluir desde el primer día:
- Los hallazgos de tu propio red teaming. Cada problema encontrado se convierte en un caso, con la secuencia exacta que lo provocó. Es el núcleo de la suite y el que más rápido paga: son fallos que ya ocurrieron en tu sistema, no hipótesis.
- Inyección indirecta desde fuentes que el sistema consume. No basta con probar lo que escribe el usuario. Prepara documentos, tickets, páginas o correos de prueba que contengan instrucciones dirigidas al modelo, y verifica qué hace el sistema cuando los procesa. Aquí es donde aparecen los fallos que importan, como explicamos en nuestro artículo sobre inyección de prompts.
- Escalada de permisos por vía de herramientas. Casos que intentan que el agente invoque una herramienta fuera de su tarea, con parámetros fuera de rango, o que actúe sobre datos de otro usuario o de otro cliente. La aislación entre inquilinos se rompe con una frecuencia incómoda y casi nunca se prueba.
- Casos de comportamiento correcto que no deben romperse. La mitad de la suite debería verificar que el sistema sigue haciendo bien su trabajo. Sin este contrapeso, cada endurecimiento del prompt mejora las pruebas de seguridad y degrada el producto, y nadie lo nota hasta que lo reporta un cliente.
Cómo puntuar respuestas que no son deterministas
Este es el problema real de ingeniería. La misma entrada produce salidas distintas, así que la comparación exacta contra una respuesta esperada no funciona. Hay tres estrategias, y conviene usarlas en este orden de preferencia.
Verificar el efecto, no el texto
Siempre que sea posible, no evalúes lo que el modelo dijo sino lo que el sistema hizo. ¿Se invocó la herramienta de borrado? ¿Se ejecutó una acción irreversible sin pasar por aprobación humana? ¿La consulta a base de datos incluyó el filtro de inquilino? Son aserciones binarias y sin ambigüedad: o el efecto ocurrió o no ocurrió. Casi todo lo que de verdad importa en seguridad se puede expresar así, y conviene llevar cada caso a esta forma antes de rendirse a las otras dos.
Aserciones sobre propiedades de la salida
Cuando el efecto no basta, evalúa propiedades verificables del texto en lugar de su contenido completo: que no aparezca ningún identificador que no pertenezca al usuario de la sesión, que el formato de salida siga siendo el esperado, que no se incluya el contenido literal del prompt de sistema, que no haya enlaces a dominios fuera de la lista permitida. Son reglas simples y no fallan de forma silenciosa.
Un modelo como juez, con disciplina
Para lo que queda —tono, si una respuesta constituye consejo que el sistema no debería dar, si el modelo cedió a una manipulación sutil— se puede usar otro modelo como evaluador. Funciona, pero solo si se trata como lo que es: un componente falible que también hay que probar.
En la práctica eso significa tres cosas. Fija la versión del modelo juez y trátala como dependencia versionada, porque si cambia, cambian tus resultados sin que cambie tu sistema. Pídele una clasificación en pocas categorías y una justificación breve, nunca un puntaje del uno al diez, que es ruido con apariencia de precisión. Y mantén un conjunto pequeño de casos con veredicto humano acordado, para medir si el juez sigue coincidiendo con tu criterio.
El umbral de aprobación
Como las salidas varían, un caso que falla una vez de veinte no es necesariamente una regresión. Ejecuta cada caso varias veces y define el criterio por tasa. Nuestra recomendación es separar en dos niveles: los casos de seguridad crítica —acciones irreversibles, fuga de datos entre clientes— exigen cero fallos y bloquean el despliegue; el resto se mide contra una tasa de referencia y alerta cuando empeora respecto de la ejecución anterior, sin frenar el trabajo.
Cuando el proveedor cambia el modelo bajo tus pies
Esta es la razón principal por la que la suite existe. Tu sistema puede degradarse sin que nadie de tu organización haya tocado nada, y el aviso puede llegar tarde o no llegar.
En un sistema de IA, "no cambió nada" no significa que nada cambió. Significa que nadie de tu lado hizo el cambio.
Cuatro medidas concretas. Fija la versión del modelo de forma explícita en la configuración siempre que el proveedor lo permita, en lugar de apuntar al alias que se mueve solo. Ejecuta la suite completa de forma programada, no únicamente cuando hay un despliegue, porque los cambios del proveedor no pasan por tu pipeline. Guarda los resultados históricos con la versión del modelo, del prompt y de la suite, para poder decir con evidencia cuándo empezó la desviación. Y ten definido de antemano un procedimiento de reversión: a qué versión vuelves y quién lo autoriza, porque esa decisión con el incidente en curso se toma mal.
Empieza pequeño y en serio. Diez casos que corren en cada cambio, con umbrales claros y un dueño que revisa los resultados, valen más que doscientos que nadie mira. Conecta la suite a las mismas señales que ya recoges en tu instrumentación de producción, y trata cada incidente real como lo que es: el caso de prueba que faltaba.