IA agéntica: qué es y qué riesgos asume su empresa

La IA agéntica es el paso que va del modelo que responde al sistema que actúa. Un agente no se limita a generar texto: recibe un objetivo, lo descompone en pasos, decide qué hacer y ejecuta acciones usando herramientas — consultar una base de datos, escribir en un sistema, enviar un correo, lanzar una transacción — repitiendo el ciclo hasta cumplir la meta.

Es el motivo de su enorme atractivo. Y también de que el cálculo del riesgo cambie por completo.

La diferencia que lo cambia todo: el agente actúa

Cuando un chatbot se equivoca, produce una respuesta mala. El usuario la lee, la descarta y sigue.

Cuando un agente se equivoca, produce una acción ejecutada. Y las acciones, a diferencia de las respuestas, tienen consecuencias en el mundo: un correo enviado, un registro modificado, un pago realizado, un permiso concedido.

De ahí se derivan dos propiedades incómodas: el error es irreversible y es silencioso —el agente encadena pasos sin que nadie los revise uno a uno—.

El riesgo compuesto: cuando la inyección se convierte en acción

Aquí se cruzan dos problemas y el resultado es peor que la suma. La inyección indirecta de prompts —instrucciones maliciosas escondidas en un PDF, una web o un correo que el sistema procesa— es, según OWASP, la vulnerabilidad número uno de las aplicaciones basadas en LLM.

En un chatbot, una inyección exitosa consigue, como mucho, que el modelo diga algo que no debía. En un agente con acceso a herramientas, consigue que el sistema haga algo que no debía. La fuga de información se convierte en ejecución de código, en un pago o en un borrado.

Y el atacante no necesita acceder a sus sistemas: le basta con que su agente lea un documento que él controla.

Qué dice la norma (aunque no diga «agente»)

El EU AI Act no crea una categoría llamada «agente». No le hace falta, y conviene entender por qué:

1. Si el agente realiza una función de alto riesgo, es de alto riesgo. Un agente que criba candidaturas, evalúa solvencia o gestiona un servicio esencial cae en el anexo III, con todas las obligaciones que ello implica.

2. La norma ya piensa en términos de autonomía. El artículo 14 establece que las medidas de supervisión humana serán proporcionales a los riesgos, al nivel de autonomía y al contexto de uso del sistema. Es decir: cuanta más autonomía, más supervisión exigible. El texto no necesita la palabra «agente» para regularlo.

3. Y aquí viene la exigencia que casi nadie ha medido. El artículo 14 exige que las personas encargadas de la supervisión puedan:

«decidir, en cualquier situación concreta, no utilizar el sistema o descartar, invalidar o revertir los resultados de salida que este genere», e «intervenir en el funcionamiento del sistema o interrumpir el sistema pulsando un botón de parada o mediante un procedimiento similar que permita que el sistema se detenga de forma segura».

Léalo pensando en un agente. ¿Cómo se «revierte» una salida que ya es una acción ejecutada? No se des-envía un correo. No se des-realiza una transferencia. No se des-borra un registro que el agente eliminó hace cuatro pasos.

Para un sistema que solo genera texto, «revertir la salida» es trivial. Para un sistema que actúa, es un requisito de diseño — y hay que resolverlo antes de desplegar, no después.

4. Trazabilidad obligatoria. El artículo 12 exige el registro automático de acontecimientos a lo largo de todo el ciclo de vida, para garantizar la trazabilidad. Con un agente esto significa poder reconstruir qué hizo, en qué orden y por qué. Si su agente no deja ese rastro, no es auditable — y por tanto no es conforme.

5. Y si se apoya en un modelo de terceros, hereda además el régimen de los modelos de uso general (GPAI): necesitará del proveedor la documentación del anexo XII para poder acreditar su propia conformidad.

En banca y seguros hay una capa más: bajo DORA, el agente es un servicio de TIC, y su fallo puede ser un incidente notificable.

El error de fondo: confiar el límite al prompt

La forma habitual de «controlar» un agente es escribirle instrucciones: no hagas X, pide confirmación antes de Y. Es necesario, pero es frágil: esas instrucciones viven en el mismo canal —lenguaje natural— por el que llega el ataque. Un prompt no es un control de seguridad; es una sugerencia muy bien redactada.

Los límites de un agente no pueden depender de que el modelo decida respetarlos. Tienen que ser externos al modelo y verificables: una capa que, sencillamente, no permita ejecutar la acción prohibida, aunque el modelo esté convencido de que debe hacerlo.

Qué implica según el tamaño de su empresa

• Pyme: empiece por agentes de solo lectura. Un agente que consulta pero no escribe elimina de un plumazo la mayor parte del riesgo.
• Mediana empresa: introduzca aprobación humana en las acciones irreversibles (pagos, envíos, borrados) y registre todo lo que el agente hace.
• Gran empresa: si despliega agentes con acceso real a sistemas, necesita límites verificables y trazabilidad completa — y, si la función es de alto riesgo, poder demostrarlo ante el supervisor a partir de agosto de 2026.

El reto de fondo: límites demostrables, no confiados

Un agente es un sistema no determinista que ejecuta acciones. Las pruebas —por exhaustivas que sean— solo muestran lo que el agente hizo en los casos probados: entregan una estimación de su comportamiento. Pero el artículo 14 no pide confianza: pide capacidad efectiva de intervenir, revertir y detener, y el artículo 12 pide rastro.

Ahí trabaja Deflank. Mediante una metodología de verificación propia, convierte los límites de un sistema agéntico en una prueba demostrable, reproducible y auditable: no se trata de esperar que el agente se porte bien, sino de acreditar que no puede hacer lo que tiene prohibido. Y de poder enseñárselo a un supervisor.

La prueba, no la estimación.

---

¿Puede demostrar que su agente no hará lo que no debe? Solicite un diagnóstico de gobernanza agéntica.

Enlaces internos: [Gobernanza de agentes de IA (pilar)] · [prompt injection] · [GPAI: modelos de uso general].

Contenido informativo; no constituye asesoramiento jurídico. Fuentes: Reglamento (UE) 2024/1689, artículos 12 y 14 y anexo III; OWASP Top 10 for LLM Applications (LLM01).