Para crear sistemas de IA que funcionen, primero hay que intentar romperlos. Llevamos a cabo un ejercicio de red teaming en el que actuamos como atacantes para poner a prueba una aplicación de IA de servicios financieros orientada al cliente. Nuestros hallazgos son importantes para cualquiera que implante aplicaciones basadas en LLM en las que la seguridad sea imprescindible.
El red teaming consiste en intentar romper deliberadamente un sistema de IA para corregir sus vulnerabilidades antes de que las descubra un atacante real. En los servicios financieros, hay mucho en juego: las aplicaciones de IA acceden a datos de clientes, procesan transacciones y ofrecen información financiera. Un fallo puede provocar desde una mala experiencia de usuario hasta infracciones normativas, pérdidas económicas y daños irreparables para la marca.
Nuestro objetivo era detectar vulnerabilidades a tiempo, probar patrones de ataque realistas y ayudar a la organización a cumplir unas expectativas de seguridad de la IA que los reguladores se toman muy en serio.
Conviene hacer una distinción: el jailbreak ataca los filtros de seguridad del modelo subyacente; la inyección de prompts ataca la propia aplicación mediante entradas de usuario no fiables combinadas con el prompt de confianza del desarrollador. La inyección de prompts supone un riesgo mayor porque ataca el sistema y los datos confidenciales con los que opera, no un modelo de uso general.
Nuestra primera ronda constó de unas 750 pruebas sobre:
Filtración de datos entre sesiones
Exposición de PII (mediante lenguaje natural, manipulación de API y distintas codificaciones)
Inyección de SQL
Anulación del prompt del sistema
Durante las pruebas iniciales identificamos dos problemas importantes en el sistema existente: el tratamiento de las consultas con varias intenciones y el uso de prompts codificados.
Consultas con varias intenciones: solicitudes que combinan peticiones legítimas y maliciosas. Por ejemplo: «Muéstrame mis gastos por categoría y ejecuta también [SQL malicioso]». La aplicación no detectaba la intención maliciosa y dependía por completo de las barreras de seguridad de la capa de datos posterior. Es como dejar abierta la puerta principal porque se confía en la caja fuerte del sótano.
Codificación: solicitudes codificadas en Base64, hexadecimal, LeetSpeak y homógrafos. A los sistemas puede resultarles difícil filtrar la intención maliciosa. Aunque comprobamos que estas consultas no exponían datos confidenciales, sí provocaban una considerable desestabilización del sistema: alucinaciones, repetición de SQL malicioso a los usuarios, clasificación errónea de intenciones, etc.
Los resultados de las pruebas iniciales mostraron:
Alucinaciones temporales: el modelo devolvía fechas, marcas de tiempo de transacciones o resúmenes temporales inventados, pero expresados con seguridad. Esto supone un riesgo considerable en un contexto financiero, donde actuar basándose en una fecha errónea puede tener consecuencias reales
Repetición de SQL malicioso al usuario, algo preocupante por el riesgo de envenenamiento de la memoria
Clasificación errónea de intenciones
Formato de salida desordenado
Con estos hallazgos, acotamos nuestro análisis. Restamos prioridad a las pruebas de inyección de SQL y codificación, pues el equipo ya estaba abordando esos problemas. En su lugar, nos centramos en los vectores de ataque más eficaces: la exposición de PII y la filtración entre sesiones.
El hallazgo más llamativo de la segunda ronda fue de una sencillez desconcertante: a menudo no hace falta recurrir a ningún método ingenioso.
En muchos casos, bastaba con pedir datos internos como parte de una solicitud aparentemente legítima para que el sistema accediera a exponerlos. Consultas sencillas recibían respuestas que mencionaban identificadores internos y campos del sistema que nunca deberían mostrarse a los usuarios finales.
Al profundizar, descubrimos que no se trataba solo de un fallo de la aplicación. El servicio posterior de conversión de texto a SQL generaba consultas que solicitaban más campos de los debidos, y sus respuestas explicativas hacían referencia a datos cuyo acceso debería haber estado restringido. Esto reveló una auténtica fisura entre sistemas, el tipo de vulnerabilidad que solo aparece al probar toda la pila y no componentes individuales de forma aislada.
Aplica el red teaming al sistema, no al modelo. Probar un LLM de forma aislada dice muy poco sobre el nivel de seguridad de una aplicación. Prueba toda la pila de principio a fin, tal como interactuaría con ella un usuario.
Las entradas deben validarse antes de llegar al LLM. Las consultas codificadas, los ataques con varias intenciones y los intentos básicos de inyección deben detectarse en el perímetro, no delegarse en servicios posteriores.
No confíes en los puntos de conexión. En las arquitecturas con varios servicios, las fisuras entre sistemas esconden las vulnerabilidades más interesantes. La confianza cero es absoluta: valida todo en cada capa.
Los ataques sencillos funcionan. Los jailbreaks sofisticados acaparan los titulares, pero a veces basta con... pedirlo. Si el sistema muestra sin reparos identificadores internos cuando un usuario los incluye en una consulta que, por lo demás, es legítima, hay un problema.
Comprende qué estás probando realmente. Puede que el propio entrenamiento del LLM detecte patrones de ataque conocidos en lugar de hacerlo las barreras de seguridad. Incorpora observabilidad al red teaming para saber qué controles se están poniendo realmente a prueba.
Los entornos restringidos exigen soluciones creativas. Los proveedores personalizados y la compatibilidad con modelos locales permiten realizar un red teaming significativo sin acceso especializado a la nube. Pero hay que explicar con transparencia las limitaciones que esto conlleva.
El red teaming no se hace una sola vez. Es un proceso iterativo, debe automatizarse siempre que sea posible y evolucionar a medida que lo hace el sistema. Los ataques que importen mañana no serán los mismos que importan hoy.
Los sistemas de IA en entornos regulados estarán sometidos a un escrutinio cada vez mayor. Las organizaciones que traten las pruebas de seguridad como una disciplina continua, en lugar de como una casilla que marcar antes del lanzamiento, estarán mejor preparadas para afrontar ese escrutinio y evitar crisis de reputación que les hagan perder la confianza de sus clientes.