La seguridad de tu agente de IA es una hipótesis hasta que alguien la rompe

Las empresas españolas despliegan agentes de IA más rápido de lo que sus comités de seguridad pueden validarlos. La pregunta incómoda no es si las defensas están bien diseñadas, sino si alguien ha comprobado, de verdad, que funcionan.

Las empresas españolas están desplegando agentes de IA a una velocidad que ningún comité de seguridad había visto antes. Asistentes que leen correos, agentes que consultan bases de datos, sistemas que encadenan herramientas y toman decisiones sin que un humano revise cada paso. La presión de negocio es real y no va a frenar. Pero hay una pregunta incómoda que casi ningún directivo se está haciendo: ¿alguien ha comprobado, de verdad, que las defensas que protegen a esos agentes funcionan?

No me refiero a si están bien diseñadas. Diseñar el control correcto y demostrar que es eficaz son dos problemas distintos. El primero pertenece a la arquitectura; el segundo solo se resuelve intentando romper el control en condiciones reales. Y ahí está el punto: un control de seguridad no es un hecho. Es una hipótesis hasta que alguien intenta vulnerarlo, sin éxito, de forma repetida y reciente.

Los agentes hacen esa distinción más urgente por dos motivos. El primero es que ellos mismos amplían la superficie de ataque: interpretan instrucciones, eligen herramientas y ejecutan operaciones de varios pasos. Una instrucción maliciosa escondida en una página web o en un correo —lo que llamamos inyección indirecta—puede ser leída por el agente como una orden legítima y propagarse a velocidad de máquina por toda la cadena. Los controles de acceso clásicos no lo impiden, porque el agente abusa de permisos que ya tiene concedidos.

El segundo motivo es la velocidad del adversario. Los modelos de IA más avanzados están comprimiendo el tiempo entre que existe una vulnerabilidad y alguien la explota: de meses a horas, a un coste de unos pocos euros. En ese contexto, un pentest anual es una fotografía estática de un sistema en movimiento. El día que se firma el informe, el agente ya ha cambiado un prompt, ha sumado una herramienta o ha recompuesto una dependencia. La foto ya no se parece a la realidad.

Hay una sola pregunta que ordena todo lo demás cuando se evalúa un control: ¿hace el ataque imposible, o solo tedioso? Muchas mitigaciones que tranquilizan en una diapositiva —un salto de red adicional, un límite de peticiones, un puerto no estándar— no detienen a un adversario que automatiza tareas repetitivas con paciencia ilimitada. Solo lo incomodan. La diferencia entre una barrera dura y un simple inconveniente no se ve en el diseño: se ve cuando alguien ataca.

La pregunta no es «¿qué pasaría si me comprometieran?», sino qué pasa cuando ejecuto el compromiso contra mi propio entorno, antes de que lo haga un tercero.

Por eso creo que esto ha dejado de ser una conversación puramente técnica. Es una decisión de dirección. Asumir la brecha está bien, pero es insuficiente; la pregunta operativa no es «¿qué pasaría si me comprometieran?», sino «¿qué pasa cuando ejecuto el compromiso contra mi propio entorno, antes de que lo haga un tercero?». Quien valida primero, manda. Quien espera al incidente, paga el reajuste de controles mucho más caro de lo que costaba probarlos.

Y hay un incentivo que los responsables de seguridad ya conocen: el ENS, NIS2 y el EU AI Act se aproximan, y todos apuntan en la misma dirección. Demostrar empíricamente que un control funciona vale cada vez más que declararlo implantado en un documento. La evidencia de validación continua no solo reduce el riesgo; se está convirtiendo en parte de la conversación de cumplimiento.

La buena noticia es que las organizaciones mejor posicionadas para esta etapa no serán las que tengan la IA más avanzada, sino las que traten cada control como una hipótesis falsable y la pongan a prueba de forma continua. Diseña para la brecha desde el primer día. Y valídala desde el segundo.

Álvaro Morales Moreno
CEO y cofundador de CISEC