Cómo hacerlo con IA Riesgo, cumplimiento y gobierno
¿Cómo hacer red teaming automático a tus agentes de IA?
Escribes lo que cada agente no debe hacer nunca y lanzas una batería de ataques, en parte generada por otro modelo, para intentar que lo haga, puntuando cada intento de forma automática. La batería corre con cada cambio de instrucciones, herramientas o modelo, y bloquea las versiones que empeoran. La automatización da cobertura y repetición; el modelo de amenazas y los ataques nuevos siguen siendo cosa de personas.
Qué hace la IA
- Genera y varía ataques: inyecciones, jailbreaks, juegos de rol y manipulación en varios turnos.
- Esconde instrucciones maliciosas en los documentos, correos y respuestas de herramientas que lee el agente.
- Hace de atacante durante muchos turnos y se adapta a lo que contesta el agente.
- Puntúa cada intento según tus políticas: datos filtrados, herramienta prohibida usada, contenido inseguro.
- Repite toda la batería con cada cambio y avisa de lo que empeora.
Qué sigue siendo de las personas
- Construir el modelo de amenazas: a qué llega el agente, quién podría atacarlo y qué daño importa más.
- Decidir qué cuenta como fallo y qué fallos impiden publicar una versión.
- El red teaming manual y creativo, para encontrar ataques que la batería aún no cubre.
- Arreglar la causa: permisos, diseño de herramientas y aprobaciones, no solo parches en las instrucciones.
Cómo ponerlo en marcha
-
Dibuja el agente y su radio de daño
Haz la lista de herramientas, fuentes de datos, permisos y acciones que el agente puede hacer solo. Eso marca qué podría conseguir un atacante y dónde caería el daño.
-
Convierte las políticas en fallos comprobables
Escribe casos concretos: filtra datos personales, usa la herramienta de pagos sin aprobación, obedece una orden que viene en un correo, revela sus instrucciones de sistema. Cada caso necesita una comprobación clara de si pasa o falla.
-
Monta la biblioteca de ataques
Parte de las taxonomías públicas de ataques a modelos de lenguaje y agentes y añade casos propios de tu sector. Incluye ataques indirectos por documentos y respuestas de herramientas, no solo mensajes en el chat.
-
Automatiza atacantes y jueces
Usa un modelo atacante que genere y varíe ataques en varios turnos, y comprobaciones automáticas o un modelo juez que puntúe el resultado. Calibra el juez con una muestra revisada por personas para fiarte de su veredicto.
-
Mételo en el proceso de publicación
Lanza la batería con cada cambio de instrucciones, herramientas, modelo o fuentes, en un entorno aislado con datos falsos. Bloquea la publicación si hay fallos críticos y guarda los resultados de cada ejecución como evidencia.
-
Sigue probando en producción
Vigila el tráfico real en busca de patrones de ataque y llamadas raras a herramientas, y lleva lo que encuentres a la biblioteca. Repite el red teaming manual cada cierto tiempo y tras cambios grandes.
Qué necesitas
- Una copia aislada del agente con sus herramientas apuntando a sistemas de prueba y datos sintéticos.
- Una política escrita de lo que el agente puede y no puede hacer, por herramienta y por tipo de dato.
- Una biblioteca de ataques, un modelo atacante y una forma de puntuar los resultados sin intervención.
- Un pipeline de CI/CD donde la batería pueda correr y frenar una publicación.
- Registros de conversaciones y llamadas a herramientas del agente en producción.
- Una persona responsable que decida qué fallos se aceptan y siga los arreglos.
Cuándo no compensa
- Prototipos sin acceso a datos ni herramientas reales, donde basta una revisión manual rápida.
- Agentes sin políticas definidas: si no está claro qué es un fallo, la puntuación es ruido.
- Cuando nadie va a actuar con los hallazgos: un informe que no cambia permisos ni aprobaciones no da seguridad.
Riesgos y cómo controlarlos
- Falsa sensación de seguridad: pasar la batería solo demuestra que resistes los ataques probados; mantén el red teaming manual y actualiza la biblioteca.
- Jueces poco fiables: un modelo juez puede dejar pasar fallos o marcar cosas inofensivas; calíbralo con revisión humana.
- Probar contra sistemas reales: un ataque puede disparar acciones de verdad; trabaja en un entorno aislado con credenciales de prueba y datos falsos.
- Arreglar solo el síntoma: parchear instrucciones mientras el agente conserva permisos de más; recorta herramientas, alcance y autonomía.
- Exposición regulatoria: si el agente entra en un ámbito de alto riesgo del AI Act (empleo, crédito, servicios esenciales), las pruebas y la evidencia de solidez cuentan; revisa las obligaciones con tu equipo legal.
Cómo lo hace Thinkia
Empezamos por inventariar los casos de uso de IA y clasificarlos según el nivel de riesgo del AI Act, con responsables con nombre. Después alineamos las puertas del ciclo de vida, la documentación y la vigilancia con el reglamento y tu política interna, y un subconjunto de modelos y proveedores pasa primero por el flujo completo; los huecos se convierten en backlog.
En los sistemas de más riesgo diseñamos la capa de supervisión humana: quién revisa, qué dispara la revisión y cómo se registran las decisiones, con traza en todos los sistemas de IA para poder explicar cada decisión. Es entrega operativa, no asesoría legal.
La solución de Thinkia detrás de esta guía
- Gobierno, riesgo y control de la IAIA que tu consejo, tu equipo legal y el regulador pueden firmar.
- Vigilancia de cumplimiento con IACumple la norma sin que el cumplimiento sea un trabajo a jornada completa.
Productos de Thinkia implicados
Preguntas frecuentes
¿Qué es el red teaming de IA?
Atacar a propósito un sistema de IA, como lo haría un adversario, para ver dónde falla: si filtra datos, obedece instrucciones inyectadas, genera contenido dañino o hace lo que no debe. La idea es corregirlo antes de que lo encuentre otro.
¿Se puede automatizar del todo?
No del todo. La automatización cubre los ataques conocidos a escala y detecta lo que empeora en cada cambio. Hacen falta personas para modelar amenazas, juzgar los casos dudosos e inventar ataques nuevos.
¿Por qué un agente es más arriesgado que un chatbot?
Porque actúa. Un agente con herramientas puede enviar correos, cambiar registros o mover dinero, así que un ataque con éxito se convierte en una acción real y no en una mala respuesta. Por eso los permisos y las aprobaciones pesan tanto como el modelo.
¿Qué es una inyección indirecta de prompt?
Un ataque escondido en algo que lee el agente, como una web, un correo o un documento, en lugar de en el mensaje del usuario. El agente puede tomar ese texto como una orden si no está diseñado para tratarlo como dato.
¿Cada cuánto hay que lanzarlo?
De forma automática con cada cambio de instrucciones, herramientas, modelo o fuentes de datos, y con vigilancia continua en producción. Los ejercicios manuales conviene repetirlos cada cierto tiempo y tras cambios importantes.
¿El AI Act obliga a hacer red teaming?
El reglamento fija requisitos de pruebas, precisión y solidez para los sistemas de alto riesgo y pruebas adversarias para los modelos de uso general con riesgo sistémico. Si te aplican y cómo depende del uso del agente; revísalo con tu equipo legal.
Para seguir explorando
Guías relacionadas
Decisiones relacionadas
- Evals automáticas o revisión humana: ¿cómo garantizas la calidad de la IA en la empresa?
- Humano en el bucle o agentes autónomos: ¿cuánto debe decidir un agente de IA por su cuenta?