El control que falta para los agentes de IA es una política de ejecución
Los agentes de IA son cada vez más fáciles de desplegar. En la última semana, el mercado ha reforzado esa dirección: nuevas API para construir agentes, nuevos productos de observabilidad empresarial y más inversión en infraestructura de seguridad para agentes. La consecuencia práctica para los responsables de seguridad no es que todas las organizaciones necesiten de repente una estrategia para agentes. Es que más equipos podrán crear agentes antes de que los equipos de gobernanza hayan decidido qué pueden hacer realmente esos agentes.
Ese es el orden incorrecto.
La mayoría de la gobernanza de IA empresarial aún comienza con una cuestión sobre el modelo: qué modelo está aprobado, dónde se almacena la información y qué solicitudes son aceptables. Esos son controles útiles. No son suficientes una vez que un sistema puede recuperar datos, llamar a una herramienta, actualizar un registro, enviar un mensaje o activar un flujo de trabajo. Un agente puede hacer una solicitud perfectamente conforme a la política a un modelo y aun así crear un resultado empresarial inaceptable mediante la acción que realiza a continuación.
El control que falta es una política de ejecución: una respuesta clara y aplicable sobre qué puede hacer un agente, con qué identidad, contra qué sistemas, bajo qué condiciones y con qué evidencia posterior.
El riesgo real comienza después de que el modelo responde
Considera un asistente de compras. Un chatbot convencional redacta una comparación de proveedores para que un humano la revise. Una versión agentica puede buscar en registros de contratos, contactar a un proveedor, actualizar un sistema de compras y preparar una solicitud de compra. El modelo de lenguaje es solo un componente en esa cadena. El riesgo reside en la cadena de decisiones y efectos secundarios.
Esta distinción importa porque los controles de seguridad existentes pueden generar una falsa confianza. Una regla de prevención de pérdida de datos puede impedir que un empleado pegue un archivo fiscal en un chatbot público. No puede decidir si un agente interno con acceso legítimo debe crear un registro de proveedor, cambiar detalles de pago o enviar información comercial sensible al destinatario incorrecto. Los controles de identidad pueden autenticar al agente. Pero por sí solos no establecen si una acción particular es apropiada en un contexto determinado.
Por eso la gobernanza de agentes no puede reducirse a un PDF de política de IA o a un cuestionario de proveedor. Debe operar donde ocurre la acción.
Define una política de ejecución antes del acceso a producción
Una política de ejecución debe ser lo suficientemente específica para que un sistema la evalúe, no solo un principio que suene sensato en un taller. Para cada agente en producción, documenta y aplica cinco aspectos.
1. Un propietario de negocio nombrado y un propietario técnico nombrado
Un agente no puede ser propiedad de "el negocio". El propietario del negocio acepta el riesgo del resultado: qué se espera que logre el agente, qué errores son tolerables y cuándo se requiere revisión humana. El propietario técnico es responsable de la integración, credenciales, monitoreo y proceso de cambios. Si esos nombres faltan, el agente no está listo para producción.
Esto parece básico, pero elimina un patrón común de IA en la sombra: un empleado capacitado conecta un nuevo agente a un espacio de trabajo compartido o herramienta SaaS porque elimina un paso manual. El flujo de trabajo puede ser útil. Sin un responsable, no hay nadie que apruebe la expansión del alcance o responda cuando la herramienta se comporta de forma inesperada.
2. Una lista blanca de acciones restringida
Empieza con el conjunto más pequeño de acciones útiles. "Puede acceder a Salesforce" no es un modelo de permisos. "Puede leer oportunidades abiertas en el territorio asignado y crear una tarea de seguimiento en borrador" sí es un modelo de permisos.
Haz explícita la lista blanca a nivel de herramienta y operación. Separa lectura, borrador, creación, actualización, aprobación, envío y eliminación. Por defecto, acceso solo de lectura cuando sea posible. Requiere un paso de aprobación humana para acciones irreversibles, comunicaciones externas, pagos, cambios de identidad y actualizaciones de registros de alto impacto. El objetivo no es inutilizar a los agentes, sino evitar que una integración amplia se convierta silenciosamente en una delegación amplia.
3. Condiciones contextuales, no solo permisos estáticos
Un permiso seguro a las 10 a. m. puede no serlo durante un incidente. Un agente de atención al cliente puede tener permitido redactar una respuesta pero no enviarla cuando un caso contiene información legal, sanitaria, financiera o regulada. Una política de ejecución necesita condiciones como clasificación de datos, entorno del sistema, nivel del cliente, ventana temporal, valor de la transacción y umbral de confianza.
Los roles estáticos son necesarios. El contexto es lo que los convierte en un control defendible.
4. Una identidad de agente con credenciales de corta duración
No ejecutes un agente a través de una cuenta compartida de empleado ni con una clave API permanente copiada en una herramienta de flujo de trabajo. Dale una identidad distinta, acceso con privilegios mínimos, tokens con alcance limitado y un proceso de expiración de credenciales. Esto hace que las acciones sean rastreables y que la revocación sea práctica.
También protege a la organización de un modo de fallo conocido: un empleado se va, queda un conector y una automatización sigue actuando con un acceso que nadie recuerda haber concedido. Para sistemas agenticos, el ciclo de vida de la identidad no es una tarea administrativa, es parte de la gobernanza en tiempo real.
5. Evidencia que conecta la intención con la acción
Registrar una requête no es suficiente. Una pista de auditoría útil registra la solicitud, los datos fuente usados, la versión del modelo o política, la llamada a la herramienta propuesta, el resultado de la aprobación, la acción tomada y el resultado. Los equipos de seguridad y GRC necesitan suficiente contexto para responder tres preguntas tras un incidente: qué sabía el agente, por qué se le permitió actuar y qué cambió.
Aquí es donde la observabilidad es más que un panel de control. Es la capa de evidencia para una autonomía responsable.
Trata el cambio como una nueva decisión de riesgo
Un agente aprobado no está aprobado permanentemente. Un nuevo conector, una fuente de datos más amplia, un cambio de modelo, una requête alterada o un nuevo tipo de acción pueden cambiar materialmente el riesgo. La gobernanza debe distinguir entre un pequeño cambio de configuración y una expansión de la autoridad del agente.
Una regla práctica: si un cambio permite que el agente vea nuevos datos sensibles, actúe en un sistema nuevo, se comunique externamente o tome una decisión irreversible, desencadena una reevaluación ligera. Esa reevaluación debe revisar la política de ejecución, probar rutas de fallo, confirmar controles y actualizar la aprobación del responsable.
Este enfoque es más rápido que un comité pesado para cada ajuste y más seguro que tratar todos los cambios como trabajo rutinario de ingeniería.
Comience con el descubrimiento, no con una prohibición
La dura verdad es que muchos de los agentes más importantes no llegarán a través del programa formal de IA. Aparecerán en plataformas de flujo de trabajo, extensiones de navegador, copilotos, herramientas low-code y complementos SaaS. Si la organización solo gobierna agentes registrados, está gobernando una fracción del comportamiento real.
Comience descubriendo el uso de IA y las integraciones capaces de agentes en toda la empresa. Luego clasifíquelos según el acceso a datos y la capacidad de acción. Un asistente de investigación solo de lectura y un agente que puede modificar registros de clientes no deberían tener el mismo proceso de revisión. Esta visión basada en riesgos ofrece a los equipos un camino seguro para sacar a la luz automatizaciones útiles en lugar de ocultarlas para evitar fricciones.
Aona ayuda a las organizaciones a realizar esa transición mediante descubrimiento del uso de IA, límites en tiempo real y formación a empleados. Si está definiendo sus primeros controles para agentes, comience con una prueba de descubrimiento de riesgos de IA generativa de 90 días para identificar la actividad de IA que debe gobernar antes de que se convierta en un incidente.
El objetivo de la gobernanza de agentes no es ralentizar la automatización. Es asegurar que cada acción automatizada tenga un responsable, un límite y un registro. Así es como la IA empresarial se vuelve escalable en lugar de solo rápida.
