Red team LLM/RAG para copilotos internos: pruebas antes de produccion

Los copilotos internos crean una nueva superficie de ataque

Un copiloto sobre politicas, contratos, tickets o procedimientos solo es util si la organizacion entiende como falla. El riesgo no se limita a alucinacion. Un sistema RAG puede recuperar la fuente equivocada, revelar informacion al usuario incorrecto, obedecer instrucciones maliciosas embebidas en un documento, llamar una herramienta fuera de alcance o producir una respuesta autoritativa que salta una politica.

El objetivo del red team

La meta no es demostrar que el sistema esta roto. La meta es identificar modos de falla antes de que los usuarios dependan de el. Un red team util produce evidencia: que ataques funcionaron, que controles los bloquearon, que riesgos residuales quedan y que debe cambiar antes de produccion.

Clases centrales de prueba

• Prompt injection: directo, indirecto, embebido en documentos recuperados u oculto en formato.
• Fuga de informacion sensible: leakage entre usuarios, citacion excesiva y falla de permisos.
• RAG poisoning: documentos maliciosos o desactualizados que sesgan recuperacion o respuesta.
• Abuso de herramientas: llamadas inseguras, falta de aprobaciones, parametros inesperados y escalamiento de privilegios.
• Exceso de autonomia: el sistema actua cuando solo deberia recomendar o dejar una decision preparada.
• Manejo inseguro de outputs: contenido generado copiado a sistemas aguas abajo sin validacion.
• Sobreconfianza: usuarios creen outputs plausibles pese a fuentes debiles o checks fallidos.

Como se ve una buena evidencia

Cada prueba debe producir un caso reproducible: input, fuentes recuperadas, version de prompt, version de modelo, comportamiento esperado, comportamiento observado, severidad y control recomendado. Una prueba fallida sirve cuando es suficientemente precisa para corregir y volver a correr.

Controles que suelen importar

• Permisos a nivel de fuente y recuperacion consciente del usuario.
• Aislamiento de instrucciones de sistema, contenido recuperado, input de usuario y mensajes de herramientas.
• Herramientas permitidas con parametros tipados y gates de aprobacion.
• Citas, senales de confianza e indicadores de frescura de fuente.
• Telemetria de prompts, recuperacion, outputs, llamadas a herramientas, decisiones de revisores e incidentes.

Umbral de produccion

Un copiloto no deberia salir a produccion porque se siente util en una demo. Deberia salir cuando los modos de falla criticos son conocidos, las mitigaciones estan implementadas y los riesgos residuales estan aceptados por el responsable del proceso. El red team es un instrumento de decision, no un ejercicio teatral.