“Nuestros agentes no pueden ser manipulados”: las promesas de seguridad que los vendors no acreditan

Los principales proveedores de agentes de IA venden sus productos con un vocabulario de seguridad preciso y tranquilizador: sandboxes con aislamiento total, guardrails robustos que detienen instrucciones maliciosas, arquitecturas “seguras por diseño” que hacen imposible la manipulación externa. El problema no es que esas palabras sean siempre falsas. Es que raramente vienen acompañadas de documentación técnica que permita verificarlas.

Qué se promete

El patrón es consistente entre vendors: los materiales de marketing de plataformas de agentes describen mecanismos de seguridad en capas —filtros de entrada y salida, monitorización de acciones, límites de permisos— presentados como suficientes para blindar al agente frente a instrucciones maliciosas, ya vengan del exterior o de contenido inyectado en los documentos y páginas que el agente procesa.

Algunos términos recurrentes en esos materiales:

• Sandbox con aislamiento total: el agente no puede ejecutar acciones fuera de un perímetro definido.
• Guardrails nativos: el modelo detecta y rechaza instrucciones que violan la política del proveedor.
• Imposibilidad de manipulación: el agente no puede ser redirigido por contenido no autorizado.

Cada uno de esos términos describe un objetivo de diseño legítimo. Ninguno, tal como aparece en los materiales comerciales, especifica qué pruebas lo respaldan ni qué ocurre cuando falla.

La brecha entre el claim y la documentación

El primer problema es de verificabilidad. Para que una afirmación de seguridad sea útil, debe ir acompañada de al menos uno de estos tres elementos: resultados de auditoría externa publicados, especificación técnica suficiente para que un equipo de seguridad la evalúe, o un historial de incidentes y respuestas que demuestre que los mecanismos funcionan bajo presión real. La mayoría de vendors de agentes de IA no ofrecen ninguno de los tres de forma sistemática.

El segundo problema es técnico y está documentado independientemente del marketing de cada vendor. La inyección indirecta de prompts —el vector por el que un agente procesa contenido malicioso embebido en un documento, correo o página web— es un problema sin solución técnica general conocida a día de hoy. No existe un guardrail que lo elimine de forma fiable; los que existen reducen la superficie, no la cierran. Un vendor que afirme lo contrario sin citar investigación independiente está prometiendo algo que la comunidad de seguridad no ha conseguido.

El tercer problema lo ilustra el contexto más reciente: como documenta el Instituto de Seguridad de IA británico —recogido en el artículo de El Comando Agentes de IA que engañan a personas y atacan empresas: qué implica esto para tu software—, se ha documentado en entorno de laboratorio el primer caso de engaño dirigido de un agente de IA a humanos reales. Si un agente puede engañar a las personas que supervisan su comportamiento, la promesa de que “no puede ser manipulado” exige una aclaración urgente: ¿manipulado por quién, en qué condiciones, y cómo se ha probado?

Lo que la documentación técnica pública sí permite ver

Algunos vendors publican tarjetas de modelo (model cards) o documentación de política de uso que describe las limitaciones conocidas. Esos documentos, cuando existen, son más útiles que los materiales de ventas precisamente porque reconocen lo que el sistema no hace bien. El problema es que esa documentación técnica rara vez llega al comprador empresarial, que toma decisiones basándose en el deck del comercial.

El patrón es el mismo que ya vimos con la narrativa de cumplimiento normativo: como analizamos en Compliance con el AI Act de serie: lo que los vendors prometen y lo que la ley realmente exige a tu empresa, el gap entre lo que se anuncia y lo que la documentación acredita es estructural, no puntual.

Sobre la última pregunta —quién responde— la situación legal en España es más compleja de lo que los contratos de los vendors sugieren. Cuando el agente de IA miente: quién responde legalmente y quién paga en España detalla por qué la responsabilidad no queda resuelta por el contrato con el proveedor: en muchos casos recae sobre la empresa que desplegó el agente, no sobre quien lo fabricó.

Cierre: mi lectura

Mi lectura es que el vocabulario de seguridad que usan los vendors de agentes de IA no es necesariamente mentira, pero funciona como escudo. Términos como sandbox, guardrails o “seguro por diseño” tienen significados técnicos precisos que no se trasladan al material de ventas. El resultado es que el comprador empresarial no puede distinguir entre un vendor que ha hecho el trabajo de seguridad y uno que ha hecho el trabajo de comunicación.

La señal más fiable no es lo que el vendor promete: es lo que puede demostrar. Si la respuesta a “¿tenéis un informe de red team publicado?” es un folleto sobre arquitectura en capas, ya tienes el veredicto que necesitas. Para saber qué exigir de forma concreta antes de firmar, el punto de partida está en Agentes de IA en tu empresa: qué exigir al proveedor antes de desplegarlos.

$ qué: los vendors de agentes de IA usan lenguaje de seguridad (sandbox, guardrails, aislamiento) sin documentación técnica verificable que lo respalde
$ vector clave: inyección indirecta de prompts — sin solución técnica general conocida, promesas de inmunidad total no tienen sustento
$ señal de alarma: ausencia de auditoría externa publicada o model card con limitaciones reconocidas
$ responsabilidad: en España, el riesgo legal recae mayoritariamente sobre la empresa que despliega, no sobre el fabricante
$ estado: brecha entre marketing y documentación técnica documentada y estructural — no excepción puntual