Red-team en LLMs busca encontrar fallas antes de que usuarios malintencionados las encuentren. Pero debe hacerse con límites éticos, alcance definido y cuidado por datos reales.
El resultado no es una lista de prompts curiosos, sino un mapa de riesgos y mitigaciones verificables.
Definir alcance y reglas
Antes de probar, hay que acordar qué sistemas entran, qué datos pueden usarse, qué técnicas están permitidas y cómo se detiene una prueba si aparece riesgo real.
Sin alcance, el red-team puede dañar producción o generar hallazgos imposibles de usar.
Probar categorías de riesgo
Las pruebas deben cubrir jailbreaks, extracción de información, instrucciones contradictorias, abuso de herramientas, sesgos, datos sensibles y manipulación de salidas.
También conviene probar cadenas completas, no solo el modelo aislado. Muchas fallas aparecen cuando el modelo puede llamar herramientas o consultar datos internos.
- Intentos de revelar instrucciones internas.
- Acceso indebido a datos entre usuarios o tenants.
- Uso inseguro de herramientas conectadas.
- Respuestas dañinas, sesgadas o fuera de política.
Medir impacto y reproducibilidad
Un hallazgo útil debe ser reproducible o al menos estadísticamente consistente. También debe explicar impacto, precondiciones y probabilidad.
No todos los fallos tienen la misma urgencia. Priorizar evita que el equipo se pierda en rarezas de baja relevancia.
Cerrar el ciclo con mitigaciones
La prueba termina cuando existe una acción: cambio de prompt, filtro, permisos, evaluación, entrenamiento, UX o proceso humano.
Después hay que repetir la prueba para verificar que la mitigación funciona y no introduce otro problema.
Checklist para aplicar
- Alcance firmado antes de probar.
- Ambiente seguro o datos sintéticos cuando corresponda.
- Registro de prompts, resultados e impacto.
- Re-test después de cada mitigación importante.
El red-team ético no busca avergonzar al sistema. Busca convertir fallas posibles en mejoras concretas antes de que lleguen a usuarios reales.