Para crear sistemas de IA que funcionen, primero hay que intentar vulnerarlos. Realizamos una evaluación adversarial red teaming en la que actuamos como atacantes para poner a prueba una aplicación de IA de servicios financieros orientada al cliente. Nuestros hallazgos son relevantes para cualquiera que implemente aplicaciones basadas en LLM donde la seguridad sea indispensable.
El red teaming consiste en intentar vulnerar deliberadamente un sistema de IA para corregir sus fallas antes de que las encuentre un atacante real. En los servicios financieros hay mucho en juego: las aplicaciones de IA manejan datos de clientes, procesan transacciones y ofrecen análisis financieros. Una falla puede causar desde una mala experiencia de usuario hasta infracciones regulatorias, pérdidas financieras y daños irreparables a la marca.
Nuestro objetivo era detectar vulnerabilidades de forma temprana, probar patrones de ataque realistas y ayudar a la organización a cumplir las 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 no confiables del usuario combinadas con el prompt confiable del desarrollador. La inyección de prompts supone un riesgo mayor porque ataca el sistema y los datos confidenciales que este procesa, no un modelo de propósito general.
Nuestra primera ronda abarcó aproximadamente 750 pruebas de:
Filtración de datos entre sesiones
Exposición de información de identificación personal (mediante lenguaje natural, manipulación de API y distintas codificaciones)
Inyección de SQL
Anulación del prompt del sistema
Durante esas pruebas iniciales identificamos dos problemas importantes en el sistema existente: el manejo de consultas con múltiples intenciones y el uso de prompts codificados.
Consultas con múltiples intenciones: solicitudes que combinan peticiones legítimas y maliciosas. Por ejemplo: “Muéstrame mis gastos por categoría y también ejecuta [SQL malicioso]”. La aplicación no detectaba la intención maliciosa y dependía por completo de las barreras de protección de la capa de datos. Es como dejar abierta la puerta principal porque confías en la caja fuerte del sótano.
Codificación: solicitudes codificadas en Base64, hexadecimal, LeetSpeak y homóglifos. A los sistemas puede resultarles difícil filtrar la intención maliciosa. Aunque estas consultas no expusieron datos confidenciales, sí desestabilizaron considerablemente el sistema: generaron alucinaciones, repitieron SQL malicioso a los usuarios, confundieron la clasificación de intenciones, etc.
Los resultados de nuestras pruebas iniciales mostraron:
Alucinaciones temporales: el modelo presentaba con seguridad fechas, marcas de tiempo de transacciones o resúmenes de períodos que eran inventados. Esto supone un riesgo considerable en un contexto financiero, donde actuar a partir de una fecha incorrecta puede tener consecuencias reales
Repetición de SQL malicioso al usuario, algo preocupante por el riesgo de envenenamiento de la memoria
Clasificación confusa de intenciones
Formato de salida desordenado
Con esos hallazgos, delimitamos nuestro enfoque. Las pruebas de inyección de SQL y codificación pasaron a tener menor prioridad, pues el equipo ya estaba abordándolas. En cambio, nos concentramos en los vectores de ataque más exitosos: la exposición de información de identificación personal y la filtración entre sesiones.
El hallazgo más llamativo de la segunda ronda fue sorprendentemente simple: muchas veces no hace falta ser ingenioso.
En muchos casos, bastaba con pedir datos internos como parte de una solicitud aparentemente legítima para que el sistema aceptara exponerlos. Consultas sencillas obtení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 una falla en la aplicación. El servicio posterior de texto a SQL generaba consultas que solicitaban más campos de los debidos, y sus respuestas explicativas mencionaban datos cuyo acceso debería haberse restringido. Esto reveló una verdadera grieta entre sistemas, el tipo de vulnerabilidad que solo aparece cuando se prueba toda la arquitectura y no cada componente de forma aislada.
Lleva a cabo evaluaciones adversariales red teaming del sistema, no del modelo. Probar un LLM de forma aislada revela muy poco sobre la postura de seguridad de una aplicación. Prueba toda la arquitectura de extremo a extremo, tal como interactuaría con ella un usuario.
Las entradas deben validarse antes de llegar al LLM. Las consultas codificadas, los ataques con múltiples intenciones y los intentos básicos de inyección deben detectarse en el perímetro, no delegarse a servicios posteriores.
No confíes en las interconexiones. En las arquitecturas con múltiples servicios, las grietas entre los sistemas ocultan las vulnerabilidades más interesantes. Confianza cero significa confianza cero: valida todo en cada capa.
Los ataques simples funcionan. Los jailbreaks sofisticados acaparan los titulares, pero a veces basta con... preguntar. Si el sistema muestra 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. Es posible que el propio entrenamiento del LLM detecte patrones de ataque conocidos, y no tus barreras de protección. Incorpora observabilidad al red teaming para comprender qué controles se están activando realmente.
Los entornos restringidos requieren soluciones creativas. Los proveedores personalizados y la compatibilidad con modelos locales permiten realizar un red teaming eficaz sin acceso especializado a la nube. Pero sé transparente sobre las limitaciones que esto introduce.
El red teaming no se hace una sola vez. Es iterativo, debe automatizarse cuando sea posible y evolucionar a la par del sistema. Los ataques que importarán mañana no son los mismos que importan hoy.
Los sistemas de IA en entornos regulados enfrentarán cada vez más escrutinio, no menos. Las organizaciones que traten las pruebas de seguridad como una disciplina continua, en lugar de una casilla que marcar antes del lanzamiento, estarán mejor preparadas para afrontar ese escrutinio y evitar las crisis de relaciones públicas que destruyen la confianza de sus clientes.