Los problemas de seguridad de IA más difíciles ahora existen fuera del modelo

El 2026 OWASP Top 10 para Aplicaciones LLM ofrece una perspectiva crítica sobre la madurez de la IA en producción. Captura un cambio fundamental: la industria está superando el entorno de pruebas y enfrentándose a las complejidades de la integración en el mundo real.

Cuando conectas un LLM a herramientas y flujos de trabajo empresariales, la superficie de amenaza cambia fundamentalmente. Los riesgos asociados con la autoridad y la utilización de recursos se vuelven significativamente más difíciles de contener. Simultáneamente, vulnerabilidades como el manejo inadecuado de la salida están retrocediendo del primer plano, no porque se hayan resuelto, sino porque otros problemas han saltado al frente.

La clasificación OWASP Top 10 refleja esta evolución. “Excessive Agency” ha ascendido del sexto al tercero, mientras que “Unbounded Consumption” subió al sexto. Por el contrario, “Improper Output Handling” ha descendido al décimo.

Esto no disminuye el riesgo del manejo de la salida. Si la respuesta de un LLM llega a una shell o base de datos sin una validación rigurosa, persisten las vulnerabilidades tradicionales de inyección. Sin embargo, el paradigma ha cambiado. En un sistema agente, la respuesta del modelo no es el destino; es una entrada que lleva autoridad. Cuando un modelo posee credenciales o interactúa con una API, su salida actúa como un vector que puede desencadenar acciones en sistemas dispares.

El desafío de seguridad ya no consiste solo en evaluar el modelo; se trata de definir los límites de lo que ocurre después de la inferencia. Tu arquitectura determina si una alucinación permanece en texto o se manifiesta como una mutación no autorizada de la base de datos.

El ranking sigue al daño

OWASP utilizó 7,714 incidentes, 75 % impulsados por consenso de la comunidad y 25 % por datos empíricos de incidentes. Esta base de evidencia obligó a un verdadero reordenamiento de prioridades.

“Excessive Agency” aumentó porque la realidad de los entornos de producción alcanzó a la teoría. Las organizaciones están acelerando el despliegue de capacidades autónomas más rápido de lo que establecen los planos de control necesarios. La vulnerabilidad crítica no es solo la respuesta que proporciona el modelo, sino el contexto de autorización en el que se ejecuta esa respuesta.

Aunque “Improper Output Handling” sigue siendo una preocupación, los equipos de DevOps han madurado en su capacidad para asegurar los destinos posteriores mediante la validación de esquemas y consultas parametrizadas. Estas son prácticas establecidas de seguridad de aplicaciones.

Sin embargo, la agencia es una clase diferente de problema. Una llamada a una herramienta puede ser estructuralmente válida pero contextualmente ilegítima. El modelo puede invocar una función aprobada para una tarea inapropiada o dirigirse al recurso equivocado. La sanitización estática no puede adjudicar la intención. Esto requiere una autorización sofisticada y consciente del contexto que el modelo nunca debería ejecutar de forma aislada.

Trata cada herramienta como una capacidad expuesta

Muchos equipos tratan las definiciones de herramientas como simples tuberías de integración. Esto es un error bastante risible y fundamental. Cada herramienta, conector o punto final de API amplía la esfera de influencia de la aplicación de IA.

Considera un agente diseñado para resumir un buzón de correo. Si la implementación utiliza un conector amplio que incluye capacidades de escritura o eliminación, has introducido una funcionalidad excesiva antes de que se procese el primer prompt.

Debes aplicar el principio de menor privilegio:

• Limita la interfaz: Proporciona al agente herramientas de solo lectura en lugar de conectores de propósito general.
• Contexto delimitado: Ejecuta solicitudes dentro de la identidad con alcance OAuth del usuario.
• Puntos de Aplicación de Políticas (PEP): Implementa la lógica de autorización como un middleware obligatorio entre el modelo y los sistemas descendentes. Cada acción debe validarse contra la política antes de su ejecución.
• Humano en el bucle (HITL): Requiere aprobación explícita para operaciones que son difíciles de revertir o que conllevan un alto impacto material.

Este enfoque requiere un cambio en la cadena de entrega. Tu proceso de revisión debe ampliarse más allá del modelo para abarcar cambios en los esquemas de herramientas, identidades de servicios y alcances de permisos. Una actualización del modelo puede parecer inofensiva, pero un cambio en el contexto de autorización de un conector puede crear una vulnerabilidad catastrófica.

La visibilidad es innegociable. Debes registrar la ejecución específica de la herramienta, la identidad que autoriza y el cambio resultante en el sistema objetivo. Esta cadena de custodia es esencial para la respuesta a incidentes, permitiéndote interrumpir un proceso activo y reconstruir el rastro de auditoría después del incidente.

Cada ejecución autónoma necesita una parada definitiva

“Unbounded Consumption” ha aumentado porque el volumen de solicitudes es una métrica insuficiente para el riesgo de recursos. Un prompt único y conciso puede desencadenar una cadena recursiva y de alto consumo de recursos de llamadas a herramientas. El medidor no se detiene hasta que el agente finaliza.

Una alerta simple es insuficiente cuando la velocidad de ejecución supera la respuesta humana. Necesitas límites determinísticos y duros que permanezcan fuera del control del agente. Implementa topes estrictos para el uso de tokens, tiempo transcurrido, profundidad de recursión y costo operativo acumulado. Si una ejecución supera estos parámetros, el sistema debe terminar o limitar la ejecución.

El alcance operativo exige un rigor similar. Determine el número máximo de registros que un agente puede modificar y defina los límites de la propagación de tareas. Si su arquitectura carece de un mecanismo determinístico “stop”, esencialmente ha delegado autoridad sin definir su perímetro.

Construir para la respuesta incorrecta

La ingeniería de sistemas ha confiado durante mucho tiempo en una arquitectura resiliente para proteger componentes inherentemente poco fiables. Anticipamos fallos de componentes e inestabilidad de la red; la seguridad se deriva de esa suposición, no de la ilusión de perfección. Los LLM exigen la misma disciplina arquitectónica.

No base su estrategia de seguridad en la suposición de una alineación perfecta del modelo. Suponga fallos, ya sea por un malentendido benigno o una explotación maliciosa. Limite las capacidades del agente al mínimo absoluto necesario y mantenga contextos de autorización de usuario estrictos para todas las llamadas posteriores. Crucialmente, la aplicación de políticas debe existir fuera del modelo para evitar que la inyección de indicaciones o errores de razonamiento eludan sus controles.

Ahora vemos la inyección de indicaciones como menos una vulnerabilidad y más una ley de la física. Siempre estará al acecho. El hecho es que los propios modelos no pueden ser decisores eficaces de preguntas críticas de seguridad. En un proyecto agente real que estoy construyendo, tenemos alrededor de 100 pruebas automatizadas de “red team”. Nos aseguramos de aprobarlas todas. Pero lo hacemos construyendo controles duros fuera del modelo. Podemos desactivarlos y observar las tasas de aprobado/reprobado solo para el modelo. El modelo más antiguo y débil que probamos falla el 17 % de las veces. El modelo más nuevo y grande falla el 2 % de las veces. Gran progreso, ¿verdad? Pero, ¿es suficiente un 98 % cuando cada fallo implica la filtración de datos sensibles? Ni de lejos.

Las operaciones de alto impacto deben ser observables, auditables y, idealmente, reversibles. Cada ejecución autónoma requiere barreras inmutables que permanezcan fuera del alcance del modelo.

Los rankings de 2026 realmente iluminan dónde los fallos de IA se convierten en consecuencias materiales. El modelo puede iniciar el error, pero la arquitectura define el radio de explosión. Para la IA en producción, el trabajo de seguridad más crítico ocurre en la canalización posterior a la inferencia.