Agentes de IA y pymes: por qué la confianza debe estar en la capa de ejecución

El problema del "diputado confundido" en la era de la IA

En 1988, Norm Hardy describió un fallo de seguridad que sigue vigente: el "confused deputy" (diputado confundido). Un programa actúa con los permisos de otro, en lugar de los propios. Hoy, cada agente de IA encarna este problema: hereda tus credenciales, tu acceso a repositorios y tu capacidad de llamar APIs, pero su comportamiento es probabilístico y puede ser manipulado.

Para las pymes, esto significa que si adoptan agentes de IA para tareas como atención al cliente, gestión de inventario o automatización de marketing, están delegando autoridad a un sistema que puede cometer errores o ser engañado. La solución histórica no fue hacer al diputado más cuidadoso, sino mover su autoridad a una capa separada. Cuarenta años después, la lección sigue siendo la misma.

Hacia un mundo multi-modelo y multi-arnés

Tres realidades están empujando a todas las empresas, incluidas las pymes, hacia un mismo futuro: los agentes son caros (cada paso consume tokens), el modelo líder cambia constantemente y los flujos de trabajo requieren modelos personalizados. Como resultado, las organizaciones acaban con un portafolio de modelos y herramientas diversas.

En una pyme, esto puede traducirse en usar un asistente para correos, otro para análisis de datos y un tercero para programación. Cada uno con su propio "arnés" (harness), es decir, su interfaz y entorno de ejecución. La pregunta clave ya no es qué modelo es mejor, sino qué sucede cuando uno de estos agentes se equivoca o es manipulado.

Las barreras de seguridad por arnés no funcionan

La mayoría de los arneses incluyen sus propias salvaguardas, pero confiar en ellas como límite de seguridad falla por tres razones. Primero, el agente puede evadirlas: si le niegas un push a git, usa la API; si le niegas la API, abre un gist; y así sucesivamente. Un límite con el que el agente puede negociar no es un límite real.

Segundo, las reglas cambian sin control: los arneses se actualizan según el calendario del proveedor, y cada cambio en el sandbox o en las aprobaciones debería tratarse como un evento de seguridad. Tercero, no cubren todos los agentes: los personalizados tienen las reglas que tú escribiste, pero los de SaaS externos tienen las que su proveedor decidió, y a menudo no ofrecen controles de aislamiento.

La solución: una capa de ejecución por debajo de todo

La propuesta es clara: dado un futuro multi-agente, toda organización necesitará una capa de ejecución (runtime) que esté por debajo de los arneses y por la que pasen todos los agentes. Esta capa es el punto donde se ejecutan los procesos, se usan las credenciales y salen las solicitudes de red. Al poner ahí las reglas de seguridad, se resuelven los tres fallos anteriores.

• Los agentes no pueden negociar con la barrera: al estar fuera del bucle del agente, la regla se mantiene firme aunque el modelo esté comprometido o alucine.
• Las reglas no cambian solas: la política es tuya, escrita una vez, y no depende de las actualizaciones del proveedor.
• Cobertura completa: la capa ve a todos los agentes, sin importar su origen, y ofrece un lugar único para definir reglas y auditar acciones.

Qué pueden hacer las pymes hoy

Implementar esta capa de ejecución no es solo para grandes corporaciones. Las pymes que usan herramientas de IA pueden empezar por auditar qué agentes tienen, qué permisos poseen y si existen controles centralizados. Aunque no exista una solución comercial inmediata, el principio de separar la autoridad del agente es aplicable: usar contenedores, limitar credenciales por tarea y monitorear las acciones.

En Altya Studio ayudamos a pymes a integrar IA de forma segura y eficiente, diseñando arquitecturas que consideran la gobernanza desde el inicio. Si estás adoptando agentes de IA, no subestimes la importancia de la capa de ejecución: es la diferencia entre un asistente útil y un riesgo de seguridad.

Fuente: www.docker.com