Red teaming de IA: cómo auditar chatbots y agentes

La decisión difícil no es comprar otra herramienta de seguridad. Es admitir, delante del comité, que el pentest que pagas cada año no sabe por dónde empezar a auditar el agente de IA que acabas de meter en producción.

Un chatbot no falla como falla una red. Su superficie de ataque es probabilística: el mismo prompt puede producir respuestas distintas según el contexto, y una sola instrucción escondida dentro de un documento aparentemente inofensivo es capaz de reescribir por completo lo que el modelo cree que debe hacer con los permisos que tú mismo le concediste. Eso no lo ve un escáner. Auditar ese comportamiento exige red teaming de IA, y exige un perfil que tu equipo de pentesting clásico, por bueno que sea en su propio terreno, casi nunca tiene todavía en plantilla.

¿En qué consiste el red teaming de IA y en qué se diferencia del pentesting?

El red teaming de IA es la auditoría adversaria de sistemas basados en modelos de lenguaje. Un equipo simula ataques reales contra tu chatbot o tu agente para encontrar cómo se rompe antes de que lo haga alguien de fuera. El pentesting clásico busca vulnerabilidades en una superficie determinista: puertos, dependencias, permisos, configuraciones. Todo eso es estable. El red teaming de IA, en cambio, trabaja sobre una superficie que cambia con cada entrada nueva, con cada actualización del modelo y con cada herramienta que conectas al agente, de modo que un objetivo que ayer estaba limpio hoy vuelve a ser terreno sin explorar.

Esa diferencia no es teórica. Un escáner de puertos revisa un objetivo estable. Un modelo de lenguaje reacciona al lenguaje, y el lenguaje es infinito. El marco de referencia que ordena estas amenazas es el OWASP Top 10 for LLM Applications, que cataloga los riesgos específicos de aplicaciones con LLM sin depender de ningún proveedor.

¿Por qué la ciberseguridad IA es distinta de la ciberseguridad tradicional?

Porque el sistema que proteges razona, y razonar se puede manipular. En ciberseguridad tradicional, un control bloquea una acción no autorizada. En un agente de IA, el atacante no fuerza el sistema: lo convence. No hace falta un exploit. Le basta con darle un contexto cuidadosamente preparado para que el propio modelo, siguiendo sus instrucciones al pie de la letra y sin saltarse ningún control técnico, tome por su cuenta la decisión equivocada con los permisos que tú le concediste.

La demanda de este perfil sigue la curva de adopción de agentes en producción, de modo que cuantos más agentes tocan clientes reales, más superficie hay que auditar y más evidente se vuelve el contexto de negocio que explica la urgencia con la que hoy se mira este riesgo. La cifra es tozuda. BCG midió en su AI Radar de enero de 2025 que el 75% de las empresas probó IA y solo el 25% vio resultados. La seguridad de los agentes es parte de ese último tramo: el sistema que no puedes auditar es el sistema que no puedes poner delante de un cliente.

¿Qué busca un ejercicio de red teaming en un chatbot o un agente de IA?

Busca las formas en que el sistema hace algo que no debería, sin necesidad de romper nada por la fuerza. A nivel conceptual, estas son las cuatro familias de exposición que un ejercicio serio cubre. No incluimos aquí cómo se ejecuta cada ataque: eso es trabajo del equipo que audita, no material de blog.

• Prompt injection: instrucciones ocultas en una entrada o en un documento que el modelo trata como órdenes legítimas.
• Jailbreak: técnicas para sortear las restricciones de seguridad que el modelo tiene definidas.
• Fuga de datos: respuestas que exponen información sensible del sistema, de otros usuarios o del propio modelo.
• Uso indebido de herramientas: hacer que un agente con acceso a APIs, ficheros o bases de datos ejecute acciones fuera de su cometido.

La cuarta es la que más subestiman los equipos. Un chatbot que solo conversa tiene un radio de daño limitado. Un agente con permisos para leer bases de datos, escribir en sistemas internos o llamar a APIs de terceros hereda exactamente el radio de daño de esos permisos, y ese radio crece cada vez que alguien, para que el agente sea más útil, le concede un acceso más. Ahí está el riesgo real.

¿Qué perfiles necesita un equipo capaz de auditar la seguridad de tus agentes?

No basta con un pentester senior. La capacidad se sostiene sobre tres perfiles que rara vez viven en la misma persona, y que tu equipo actual probablemente no tiene completos.

• AI security engineer: diseña y ejecuta el red teaming del modelo, entiende la superficie probabilística y sabe qué significa un fallo reproducible frente a un fallo anecdótico.
• ML engineer con adversarial ML: conoce cómo se manipula un modelo desde dentro, no solo cómo se consume desde fuera.
• Integrador con gobernanza de datos: mapea qué datos toca el agente, con qué permisos y bajo qué base legal, porque una fuga empieza casi siempre en un acceso mal acotado.

El modelo que funciona aquí es un blended team: tu gente, que conoce el negocio y el riesgo real, combinada con talento certificado en skills IA que ya ha auditado sistemas parecidos y sabe distinguir un hallazgo reproducible de una anécdota que no vuelve a aparecer cuando cambias una coma del prompt. La certificación no es un adorno. Separa a quien ha roto un agente en producción de quien ha visto una demo.

¿Cómo validar y certificar esa capacidad antes de contratarla?

Con evidencias, no con currículums. Antes de firmar con cualquiera, interno o externo, exige que demuestre lo que dice saber. Este es el mínimo que un equipo serio puede enseñar sin inventar.

• Informes de red teaming sobre agentes reales en producción, con hallazgos concretos, no capturas de una demo controlada.
• Metodología reproducible: un tercero debería poder repetir el ejercicio y llegar a los mismos hallazgos.
• Cadena de custodia de los hallazgos: cómo se documentan, se priorizan y se verifica su corrección.
• Trazabilidad de datos: qué información tocó el ejercicio y cómo se protegió durante la auditoría.

Shakers no ejecuta el red teaming de tus sistemas: provee y certifica el talento que lo hace, dentro de una infraestructura de contratación con ISO 27001, con un 4% de aceptación entre los aspirantes y más de 14.000 expertos en la comunidad. Ese filtro es el punto: en seguridad de IA, contratar al perfil equivocado no te deja igual que antes, te deja peor, porque crees que auditaste algo que no auditaste.

¿Equipo interno, blended team o servicio de agencia cerrada?

Depende de qué quieras retener. Un servicio de agencia cerrada entrega un informe y se va con el conocimiento. Un equipo interno puro rara vez tiene el volumen de trabajo continuo que justifique tener a tres perfiles tan especializados como un AI security engineer, un ML engineer con adversarial ML y un integrador de datos contratados a tiempo completo y sin momentos muertos. El blended team resuelve esa tensión. Retiene el conocimiento en casa y trae la especialidad cuando hace falta.

Un ejemplo ilustra el matiz. Imagina el agente de atención al cliente de una aseguradora media, auditado por un blended team antes de abrirlo al público. En ese ejercicio aparece una vía de prompt injection: un usuario que redacta su consulta de una forma concreta consigue que el agente devuelva datos que pertenecen a otros clientes. El hallazgo llega semanas antes del lanzamiento, no en el post mortem de un incidente. Ese es el trabajo: no prometer que nada fallará, sino encontrar el fallo mientras todavía es barato arreglarlo.

¿Es lo mismo el red teaming de IA que el pentesting que ya contrato?

No. Confundirlos deja un hueco abierto, porque el pentesting que ya contratas cubre la superficie clásica de red, aplicaciones e infraestructura, mientras que el red teaming de IA cubre la superficie específica de los modelos y los agentes, esa que tu proveedor actual casi nunca audita. Necesitas los dos, no uno en lugar del otro.

Si tu programa de seguridad ya cubre la parte tradicional y ahora tienes agentes en producción, el trabajo es sumar la capacidad que falta. La página de expertos en ciberseguridad de Shakers reúne los perfiles clásicos; el red teaming de IA es la extensión de ese equipo hacia la superficie de los modelos.

Preguntas frecuentes sobre red teaming de IA

¿Es lo mismo el red teaming de IA que el pentesting?

No. El pentesting audita una superficie determinista: red, aplicaciones e infraestructura. El red teaming de IA audita una superficie probabilística: cómo responde un modelo de lenguaje o un agente ante entradas manipuladas. Un pentest no detecta prompt injection ni uso indebido de herramientas de un agente. Son disciplinas complementarias, no intercambiables.

¿Puedo usar mi equipo de pentesting actual para auditar un agente de IA?

Solo en parte. Tu equipo de pentesting cubre la infraestructura donde vive el agente, pero auditar el modelo exige skills adicionales de adversarial ML y gobernanza de datos que la mayoría de equipos clásicos no tiene. Por eso el modelo habitual es un blended team: tu equipo más talento certificado en seguridad de IA.

¿Cada cuánto hay que hacer red teaming de un sistema de IA?

No es un ejercicio puntual. Los modelos se actualizan, los prompts del sistema cambian y las integraciones crecen, y cada cambio abre superficie nueva. La práctica razonable es tratar el red teaming como capacidad continua, con ejercicios ligados a cada cambio relevante del modelo o de sus permisos, no como una auditoría anual aislada.

¿Qué evidencias debo pedir a quien contrate para esto?

Informes de red teaming sobre agentes reales en producción, con hallazgos concretos y no capturas de una demo. Metodología reproducible por un tercero. Cadena de custodia de los hallazgos: cómo se documentan, priorizan y verifica su corrección. Y trazabilidad de qué datos tocó el ejercicio. Sin evidencias, cualquier currículum es una promesa sin respaldo.

¿Cuánto cuesta montar esta capacidad?

Depende del alcance y del modelo de colaboración. Un equipo interno puro implica coste fijo de tres perfiles especializados; un blended team ajusta el coste al volumen real de auditoría. La variable que más mueve el precio no son las horas, sino la especialización certificada del talento que audita. El dimensionamiento se hace caso a caso.

El red teaming de IA no es un proyecto que se cierra y se archiva. Es una capacidad que sostienes mientras tengas agentes en producción, con los mismos estándares de rigor que aplicas al resto de tu seguridad, y que se actualiza cada vez que cambias el modelo, amplías los permisos del agente o conectas una integración nueva que ayer no existía. La pregunta que decide el resultado no es si conoces la amenaza. Es si tienes, hoy, a alguien que sepa romper tu agente en un entorno controlado antes de que lo rompa alguien de fuera.

Si el hueco está en el equipo y no en el plan, un blended team con talento certificado en seguridad de IA cubre esa capacidad sin montar estructura de más. Habla con un experto Shakers para dimensionar el tuyo.