Antes, hacer red team a un agente de IA era trabajo artesanal. Un humano
experto, pensando como atacante, probando payloads, observando comportamiento,
iterando. Caro, lento, no escalable.
Microsoft sacó el AI Red Teaming Agent en Foundry para cambiar eso. La
promesa: red team automatizado, escalable, repetible. La realidad: útil, no
sustituto.
Lo probé en serio este trimestre, contra dos agentes de Copilot Studio
que tengo en producción ligera. Voy a contar lo que vi.
Qué hace
El agente toma tu agente bajo prueba y le tira payloads adversarios desde
una librería curada. Cubre
prompt injection directa, indirecta, jailbreak, content harms, tool abuse,
agent hijack. La librería se actualiza. También permite cargar payloads
custom, así que si tienes tu propio dominio (financiero, salud, legal), puedes
meter ataques específicos.
Te entrega un reporte: qué payload pasó, qué se bloqueó, qué generó
respuestas problemáticas. Métricas, severidades, sugerencias de mitigación.
Lo bueno
Velocidad. Mil ataques en una hora. Un humano hace cien en un día bueno.
La cobertura amplia es donde brilla. Si tu agente tiene un patrón de fallo
conocido, casi seguro lo encuentra.
Repetibilidad. Cada nueva versión de tu agente la pasas por la misma
batería. Detectas regresiones. CI/CD para seguridad de IA. Esto es lo que más
me cambió: meter el red teaming en el pipeline, no como ejercicio anual.
Integración con Foundry. El reporting fluye al mismo lugar donde llevas
el resto de tus pruebas y safety evaluations. Vista única.
Lo no tan bueno
Encuentra ataques conocidos. Brilla menos con ataques nuevos, sutiles,
específicos a tu dominio. Si tienes un caso de negocio peculiar, los payloads
genéricos no van a detectar todos los caminos. Necesitas un humano experto que
escriba payloads específicos a lo tuyo. El agente automatiza lo conocido, no lo
creativo.
La interpretación de resultados sigue requiriendo expertise. Reporte que
te dice “12 ataques pasaron, 88 bloqueados”. OK. ¿Cuáles son los 12? ¿Cuáles
importan más? Eso lo tienes que entender tú o alguien con criterio.
Falsos positivos pasan. A veces el agente clasifica un comportamiento
como problemático cuando es esperado en tu caso. La triangulación con un humano
es necesaria.
Cómo lo uso
Para regresiones: parte del pipeline. Cada cambio de prompt, cada nuevo
conector, cada update del modelo, batería completa. Si la baseline empeora,
alerta antes de promover a producción.
Para baseline en agentes nuevos: antes de meter un agente nuevo a
producción, ejercicio completo. Si pasa los ataques conocidos, listo el primer
filtro. Después le sigo con red team manual sobre lo específico de mi dominio.
Para auditoría: el reporte automatizado es excelente evidencia para
auditores externos. “Aquí está el resultado de la batería de pruebas
adversarias contra cada agente, ejecutada cada N días”. Antes esto era difícil
de producir. Ahora es un export.
Lo que me gustaría que tuviera
Más payloads en español. La librería está fuerte en inglés y los modelos
modernos transfieren razonablemente, pero los ataques en español tienen
sutilezas. Espero que la librería se siga internacionalizando.
Soporte mejor para agentes multi-step complejos. Los ataques que se
desarrollan a lo largo de varios turnos, con planificación, son más difíciles
de automatizar. Hoy detecta lo turn-by-turn bien, lo multi-turno con menos
profundidad.
Integración nativa con MCP. La capacidad de probar agentes que usan MCP
servers externos. Esto es un gap. Hoy si tu agente usa MCP, la cobertura del
red team baja porque no entiende del todo las superficies extra. Espero ver
mejoras en los próximos meses.
¿Es suficiente? No. Es parte del programa de seguridad, no el programa
entero. Pero es un avance gigante respecto a hace dos años, donde literalmente
no existía esta categoría de herramienta.
Si tienes agentes en producción y no estás haciendo red teaming
sistemático sobre ellos, es la pieza que más rápido te baja el riesgo. Hazlo
ahora.
