Cuando un equipo de seguridad revisa una aplicación que incorpora IA, casi siempre revisa la aplicación: autenticación, cifrado en tránsito, gestión de secretos, dependencias desactualizadas. Todo eso sigue siendo necesario y ninguno de esos controles toca lo que hace distinto a un sistema de IA. Quien ataca un asistente o un agente no busca el mismo tipo de falla y, sobre todo, no entra por el mismo lugar.
Vale la pena recorrer el sistema completo como lo recorrería alguien que quiere abusar de él. Son cinco capas, y cada una tiene su propio momento en el tiempo y su propia forma de fallar: los datos con los que se construyó el modelo, el modelo como artefacto, la ventana de contexto en tiempo de ejecución, las herramientas que el sistema puede invocar y las personas que actúan sobre su salida.
Antes del despliegue: datos y modelo
Los datos de entrenamiento y de ajuste
El primer punto de entrada existe mucho antes de que el sistema llegue a producción. Si el atacante consigue colocar contenido en el material con el que el modelo se entrena o se ajusta, no necesita volver: el comportamiento queda incorporado en los pesos. Pocas organizaciones entrenan modelos base, pero muchas hacen ajuste fino con documentación interna, transcripciones de soporte o conversaciones que los propios usuarios marcaron como buenas. Ese último caso es el más expuesto, porque el canal de retroalimentación suele estar abierto a cualquiera que use el producto y casi nunca se trata como lo que es: una entrada de datos que llega desde fuera de la organización.
Lo incómodo de esta capa es que el fallo no se ve. Un modelo contaminado responde con normalidad ante las pruebas habituales y solo cambia de comportamiento cuando aparece el patrón que el atacante eligió como disparador.
El modelo como pieza de cadena de suministro
El modelo llega desde algún lugar: un proveedor por API, un repositorio de pesos abiertos, una imagen de contenedor con una versión concreta. Cada camino arrastra los riesgos clásicos de dependencias —quién publicó eso, cómo se verifica la integridad— más uno propio: ciertos formatos de serialización de modelos pueden ejecutar código al cargarse, de modo que descargar pesos equivale a ejecutar software de terceros. Cuando el modelo es un servicio externo aparece otra variante que rara vez está en el registro de riesgos: el proveedor actualiza la versión y el comportamiento cambia sin que tu equipo despliegue nada.
En ejecución: la ventana de contexto
Esta es la capa donde ocurre la mayoría de los ataques que se ven hoy, y la que peor encaja en los modelos mentales heredados. El contexto reúne en un mismo espacio de texto el prompt de sistema, la pregunta del usuario, los documentos recuperados del repositorio interno, el historial de la conversación y las respuestas de las herramientas. El modelo no dispone de un mecanismo estructural que distinga cuál de esos bloques es una instrucción legítima y cuál es un dato que solo debía leer.
El atacante lo sabe y por eso rara vez escribe de frente. Deja el texto en un lugar que el sistema leerá más tarde: una página web que el agente consultará, un PDF adjunto a un ticket, un campo de un registro del CRM. Es la diferencia entre inyección directa e indirecta, y la segunda es la que importa, porque convierte al usuario en víctima en vez de en origen. Ese mecanismo lo desarrollamos en nuestro análisis sobre inyección de prompts.
Toda fuente que alimenta la ventana de contexto es superficie de ataque, aunque nadie la haya diseñado como entrada.
Al otro lado del modelo: las herramientas conectadas
Un sistema que solo escribe texto tiene un techo de daño relativamente bajo. Un sistema que puede consultar bases de datos, enviar correos, abrir tickets, ejecutar código o modificar registros tiene el techo de daño de esas herramientas, no el suyo. Aquí el ataque no consiste en romper el modelo, sino en usarlo como intermediario: el atacante no necesita credenciales porque el sistema ya las tiene.
Los tres errores que encontramos con más frecuencia en esta capa son el agente que hereda los permisos completos de la persona que lo invoca, la herramienta que acepta parámetros generados por el modelo sin validarlos como entrada no confiable, y la acción irreversible que se ejecuta sin confirmación fuera del canal conversacional. Los tres son problemas de diseño de autorización, no de calidad del modelo, y se corrigen con un diseño explícito de permisos por herramienta.
La capa final: las personas
El último eslabón es quien lee la salida y actúa. Un sistema de IA produce texto con una fluidez que el lector asocia a competencia, y esa asociación es explotable. Un resumen manipulado que omite una cláusula, una recomendación inclinada hacia un proveedor, un supuesto requerimiento del área legal insertado en la respuesta: nada de eso deja rastro técnico y todo eso puede terminar en una decisión.
Esta capa se defiende con procedimiento más que con tecnología. Que la salida del modelo esté identificada como tal, que las decisiones con consecuencia real exijan verificar la fuente original, y que exista un camino evidente para reportar respuestas extrañas. Sin esos tres elementos, el sistema tiene un canal de influencia sobre la organización que ningún control técnico observa.
Recorrer las cinco capas sirve, sobre todo, para ubicar dónde está puesto tu esfuerzo hoy. Lo habitual es encontrar mucha atención en la capa de ejecución —filtros de entrada, listas de frases prohibidas— y muy poca en las dos que determinan el daño real: qué puede hacer el sistema cuando lo engañan y quién actúa sobre lo que dice. Si tuvieras que revisar un solo despliegue esta semana, hazlo en ese orden: primero la lista de herramientas conectadas y sus permisos, después las fuentes que alimentan el contexto, y solo entonces los filtros.