Qué es el red teaming aplicado a IA y para qué sirve

El dolor real: se prueba que funcione, nadie prueba que no se pueda abusar

Cuando una empresa mediana decide llevar un asistente de IA a producción, la conversación interna gira casi siempre alrededor de la misma pregunta: ¿funciona? Se prueban los flujos felices, se revisan las respuestas ante las preguntas típicas, se mide el tiempo de respuesta y se ajusta el tono si suena robótico. Es una validación legítima y necesaria. El problema es que casi siempre se detiene ahí, como si un sistema que responde bien en pruebas controladas ya estuviera listo para enfrentarse a miles de usuarios reales, algunos de ellos con toda la intención de hacerlo fallar.

La consecuencia aparece casi siempre después del lanzamiento, no antes. Una empresa de retail en México, con presencia en varias ciudades, integró un asistente de IA para resolver dudas de compra en su sitio. En la primera semana, un usuario descubrió que formulando la pregunta de cierta manera lograba que el asistente revelara condiciones internas de descuento que no debían salir a público, y en otro caso repetía instrucciones internas que el equipo de marketing consideraba confidenciales. Nadie del equipo técnico había intentado provocar eso a propósito antes de abrir el sistema a los clientes. El hallazgo llegó por una captura de pantalla que un cliente compartió en redes, no por una alerta interna, y para cuando el equipo se enteró ya llevaba horas circulando.

El error de fondo no es técnico, es de proceso. Se construye o se contrata el sistema, se prueba que cumpla su función, y se asume que la seguridad viene incluida porque el proveedor la menciona en una propuesta comercial. Nadie se sienta deliberadamente a intentar romperlo antes de que lo haga un desconocido con más tiempo, más curiosidad y ninguna obligación de avisar cuando lo logra.

Qué es el red teaming en IA, en criterio de negocio

Lo que falta en ese proceso tiene nombre dentro de la disciplina de seguridad, y no es exclusivo de laboratorios de ciberseguridad de élite ni de empresas con presupuestos enormes. Cualquier equipo que conozca su propio producto puede hacerlo con una sesión ordenada, un par de horas protegidas en la agenda y una lista clara de qué intentar romper.

En la práctica esto significa sentar al propio equipo, o a alguien externo con el mandato explícito de hacerlo, a interrogar al sistema con la misma mala intención que tendría un usuario malicioso, un competidor curioso o un cliente aburrido con tiempo libre. No es la pregunta de '¿funciona?', que es la que responde el control de calidad. Es la pregunta de qué se puede sacar de este sistema que nunca debió salir.

La sesión termina en un documento de hallazgos concreto: qué se logró que el sistema hiciera o dijera que no debía, con qué tipo de mensaje se consiguió, y qué ajuste corrige cada hallazgo antes de que el sistema vuelva a quedar frente a un cliente real.

Qué se prueba en una sesión de red teaming

Una sesión ordenada no busca vulnerabilidades de software en el sentido clásico, busca comportamientos indebidos del asistente frente a distintos tipos de presión. Las categorías que conviene cubrir, sin importar el sector, son casi siempre las mismas:

• Fuga de datos ajenos: que el sistema mencione información de otro cliente, otro caso o una condición interna que no debía estar disponible para quien pregunta.
• Instrucciones ocultas manipuladas: intentar que el sistema ignore sus reglas de origen o revele las instrucciones internas que lo gobiernan, lo que en la disciplina se conoce como un jailbreak de IA.
• Mensajes diseñados para desviarlo de su tarea: instrucciones escondidas dentro de un texto que el usuario pega o adjunta, lo que se conoce como un prompt injection.
• Respuestas fuera de alcance: que opine o asesore sobre temas legales, médicos o financieros para los que no tiene autorización, en vez de derivar a una persona.
• Tono inaceptable bajo presión: que insulte, discrimine o pierda el control cuando el usuario lo provoca o lo insulta primero.

Y un quinto grupo que suele quedar fuera de la lista inicial: acciones que el sistema no debería ejecutar solo porque alguien se lo pidió con las palabras correctas, como cancelar un pedido, aplicar un reembolso o escalar una solicitud sin validar antes la identidad de quien la hace. Cada categoría conviene probarla con varias formulaciones distintas, porque un sistema que resiste una forma de pedirle algo indebido puede ceder ante otra formulación de la misma idea, con otro tono o en otro idioma.

Cómo se organiza una sesión sin ser un laboratorio de ciberseguridad

La sesión no requiere un equipo de hackers contratados por semanas. Requiere orden y a alguien dispuesto a jugar en contra de su propio trabajo durante un par de horas. La estructura que funciona en la práctica es simple:

• Convocar a alguien que conozca el negocio, no solo a quien construyó el sistema: suele detectar riesgos que el equipo técnico no ve porque da por sentado el contexto.
• Preparar antes una lista de intentos organizada por categoría de riesgo, no improvisar preguntas sueltas el mismo día.
• Proteger el tiempo en la agenda como una actividad seria, no como algo que se hace si sobra rato antes del lanzamiento.
• Documentar cada hallazgo con el mensaje exacto que lo provocó y la respuesta completa del sistema, no un resumen aproximado de memoria.
• Cerrar la sesión con una lista corta de correcciones priorizadas, no con un documento largo que nadie vuelve a abrir.

Y repetirla cada vez que el sistema cambia de forma relevante: se agrega un caso de uso nuevo, se amplía el alcance de lo que puede hacer, o se cambia el modelo o proveedor detrás del asistente. Un red teaming hecho una sola vez, al lanzamiento, protege contra el sistema que existía ese día, no contra el que existe seis meses después. Tampoco hace falta que la primera sesión sea perfecta: es mejor una sesión corta y desordenada que se corre de verdad, que una sesión ideal que se sigue posponiendo hasta el mes que viene.

En qué se diferencia del control de calidad normal

Es fácil confundir el red teaming con una ronda más exigente de control de calidad, y es un error que sale caro. El QA parte de una pregunta amable: ¿el sistema responde bien a lo que se espera que le pregunten? El red teaming parte de una pregunta hostil: ¿qué puede lograr alguien que quiere que el sistema se porte mal?

• Objetivo: el QA confirma que el sistema cumple su función; el red teaming confirma que no se puede abusar de esa función.
• Mentalidad: el QA prueba con las preguntas esperadas; el red teaming prueba con las preguntas que nadie quisiera que le hicieran.
• Quién debe hacerlo: el QA lo hace bien el mismo equipo que construyó el sistema; el red teaming funciona mejor con alguien que no participó en construirlo, porque no defiende el diseño.
• Resultado esperado: el QA busca cero errores funcionales; el red teaming busca encontrar la mayor cantidad de fallas posibles, porque cada una que se encuentra ahí es una que no encuentra un cliente.

Un sistema puede pasar el control de calidad con nota perfecta y fallar por completo un red teaming el mismo día, porque son pruebas de naturaleza distinta, no de distinto rigor.

Qué no resuelve el red teaming y qué necesita antes

El red teaming no arregla un sistema mal diseñado, solo revela dónde falla. Si el asistente todavía comete errores básicos en el uso normal, antes toca resolver eso, algo más cercano a la disciplina de cómo evitar que la IA se equivoque, que sentarse a buscarle fallas de seguridad a algo que ni siquiera funciona bien en lo esperado.

Tampoco es un sustituto de la revisión continua. Una sesión de red teaming es una fotografía de un momento; una auditoría de IA recurrente, con revisión periódica de conversaciones reales, es lo que sostiene esa foto en el tiempo. Y antes de correr los intentos más agresivos contra un sistema con datos reales de clientes, conviene tener un entorno de prueba separado, un sandbox de IA, para no terminar provocando en producción el mismo daño que se quería evitar.

Tampoco resuelve un problema de gobierno de datos que ya existía antes del asistente: si el sistema tiene acceso a información que nunca debió tener a su alcance, el red teaming lo va a exhibir, pero el arreglo real está en los permisos de acceso, no en el modelo. Confundir esos dos arreglos, el técnico y el de acceso a datos, es lo que hace que un mismo hallazgo se repita sesión tras sesión sin que nadie lo cierre de raíz.

Mi criterio

Cuándo es obligatorio y cuándo puede esperar

No todas las empresas necesitan correr esto la próxima semana, pero ignorarlo tiene un costo distinto según qué tan expuesto esté el sistema.

Señales de que toca hacer red teaming ahora

• El asistente conversa directamente con clientes externos, no solo con empleados internos.
• El sistema tiene acceso a datos de más de un cliente, caso o cuenta al mismo tiempo.
• Ya hubo al menos un incidente menor, una respuesta rara o un usuario que reportó algo extraño, que nadie investigó a fondo.
• El sistema puede ejecutar acciones (cancelar, reembolsar, agendar, escalar) y no solo responder texto.
• Se está por ampliar el alcance del asistente a un caso de uso nuevo antes de haber probado a fondo el actual.

Señales de que todavía no es prioridad

• El sistema es de uso interno, con un grupo reducido y conocido de empleados como únicos usuarios.
• Todavía falla en el uso normal esperado y ni siquiera ha pasado un control de calidad básico.
• No maneja ningún dato sensible ni de clientes, solo información pública o ya disponible en otros canales.
• Es un piloto acotado, sin fecha de apertura a clientes reales en el corto plazo.
• No tiene ninguna capacidad de ejecutar acciones, solo de responder preguntas con información ya pública.

El orden importa más que la herramienta

El orden que sostiene todo esto es el mismo en cualquier implementación seria de IA: primero el dolor real de la operación, después el proceso que lo resuelve, después el dato que confirma si el proceso funciona, y al final la herramienta. El red teaming es la parte del proceso que confirma, con evidencia y no con la palabra del proveedor, que el sistema no se puede llevar a hacer lo que no debe. Sin esa evidencia, lo único que hay es la esperanza de que ningún cliente sea lo suficientemente curioso, y la esperanza no es un proceso de gestión de riesgo.

Un asistente de IA que nunca ha sido atacado a propósito por su propio equipo no está probado, está sin probar en la única dimensión que realmente importa una vez que sale a producción. La pregunta no es si alguien va a intentar romperlo, es si el primero en lograrlo va a ser el equipo que lo construyó o un desconocido con una captura de pantalla lista para compartir.