Agentes de IA para empresas: control con límites demostrables
La prueba, no la estimación.
Cuando un chatbot se equivoca, produce una respuesta mala. Cuando un agente se equivoca, produce una acción ejecutada: un correo enviado, un registro modificado, un pago realizado.
Y las acciones, a diferencia de las respuestas, no se deshacen.
El problema que nadie ha resuelto
El artículo 14 del EU AI Act exige que la supervisión humana permita «descartar, invalidar o revertir» las salidas del sistema e interrumpirlo 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 uno que actúa, es un requisito de diseño — y hay que resolverlo antes de desplegar.
Por qué un prompt no sirve como control
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. Una inyección de prompt las sobrescribe.
Un prompt no es un control de seguridad. Es una sugerencia muy bien redactada.
Qué obtiene
- Límites externos al modelo y verificables: una capa que sencillamente no permite ejecutar la acción prohibida, aunque el modelo esté convencido de que debe hacerlo.
- Trazabilidad completa de qué hizo el agente, en qué orden y por qué — lo que exige el artículo 12 del AI Act. Si su agente no deja ese rastro, no es auditable, y por tanto no es conforme.
- Capacidad real de intervención y parada, conforme al artículo 14.
- Evidencia demostrable ante el supervisor, no una carpeta improvisada el día de la inspección.
Lo que dice la norma (aunque no diga «agente»)
El EU AI Act no crea una categoría llamada «agente». No le hace falta:
- Si el agente realiza una función del anexo III —criba de candidaturas, evaluación de solvencia, servicio esencial—, es de alto riesgo.
- El artículo 14 gradúa la supervisión exigible según el nivel de autonomía del sistema: cuanta más autonomía, más supervisión. La norma ya piensa en agentes sin usar la palabra.
- Si se apoya en un modelo de terceros, hereda el régimen de los modelos de uso general (GPAI).
- En banca y seguros, bajo DORA, el agente es un servicio de TIC y su fallo puede ser un incidente notificable.
El reto de fondo
Un agente es un sistema no determinista que ejecuta acciones. Las pruebas, por exhaustivas que sean, solo muestran lo que hizo en los casos probados: entregan una estimación de su comportamiento.
Deflank convierte los límites de un sistema agéntico en una prueba demostrable, reproducible y auditable mediante una metodología de verificación propia. No se trata de esperar que el agente se porte bien: se trata de acreditar que no puede hacer lo que tiene prohibido.
Despliegue soberano
Autohospedable: on-premise o en su nube privada, incluso en entornos aislados. Sus agentes, sus datos y sus pruebas no salen de su perímetro.
Empiece por saber dónde está
Diagnóstico de gobernanza agéntica. Le decimos qué puede ejecutar hoy su agente —incluido lo que usted no autorizó— y si podría demostrarlo ante un supervisor.
Enlaces internos: IA agéntica: qué es y qué riesgos asume (guía) · Seguridad de LLM · EU AI Act · Reglamento DORA.
Fuentes: Reglamento (UE) 2024/1689, artículos 12, 14 y anexo III; OWASP Top 10 for LLM Applications (2025), riesgo LLM06 «agencia excesiva».