Los agentes de IA autónomos necesitan un nuevo modelo de gobernanza

Google News mostró un titular de SiliconANGLE con una advertencia directa: los actores autónomos de IA necesitan una gobernanza diseñada para software capaz de emprender acciones con consecuencias relevantes.

Esta distinción importa porque un agente de IA hace más que generar una respuesta. Puede recuperar archivos, llamar herramientas, ejecutar código, actualizar registros y comunicarse con otros sistemas. Estas capacidades convierten una salida poco fiable en una acción potencialmente no autorizada.

El titular recoge un conflicto al que ahora se enfrentan los líderes tecnológicos empresariales. Las empresas quieren agentes que operen con menos supervisión, pero muchos controles de seguridad aún asumen que una persona inicia cada acción importante.

Los reguladores, organismos de normalización y proveedores de seguridad han empezado a cerrar esa brecha. Su respuesta emergente combina identidades únicas para los agentes, permisos restringidos, monitorización continua, puntos de aprobación humana y mecanismos de recuperación.

La cuestión central ya no es si un modelo produce una frase inexacta. Es si una organización puede identificar, contener, explicar y revertir las acciones de un agente antes de que un error se propague.

El titular de Google News apunta a un cambio más amplio en la gobernanza

La gobernanza de la IA está pasando de supervisar las salidas de los modelos a controlar actores de software con identidades, permisos, herramientas y responsabilidades operativas.

La gobernanza tradicional de la IA generativa se centraba en gran medida en los datos de entrenamiento, el contenido dañino, la evaluación de modelos y la precisión de las respuestas generadas. Estas preocupaciones siguen siendo importantes, pero los agentes autónomos introducen un problema operativo distinto.

Un agente de IA puede perseguir un objetivo mediante una secuencia de decisiones. Puede elegir herramientas, leer información cambiante, revisar un plan e iniciar acciones sin solicitar aprobación en cada paso.

Ese comportamiento crea una cadena más larga entre la instrucción original de un usuario y el resultado final. Cada paso adicional introduce otro punto en el que la intención, el contexto o la autoridad pueden desviarse.

Pensemos en un empleado que pide a un agente preparar documentos de renovación de clientes. Un chatbot podría redactar el texto y esperar. Un agente autónomo podría recuperar registros de cuentas, seleccionar plantillas, modificar un contrato y enviar el paquete.

Estas acciones implican varios sistemas y múltiples límites de permisos. Una instrucción ambigua o un documento manipulado puede afectar a toda la secuencia.

Por tanto, el artículo de Google News es más que otra advertencia sobre una IA inexacta. Refleja un cambio estructural en la forma en que el software opera dentro de las organizaciones.

Los servicios de software utilizan desde hace tiempo identidades de máquina. Sin embargo, esos servicios suelen ejecutar funciones predecibles dentro de límites técnicos estrechos.

Un agente de IA puede interpretar objetivos ambiguos y elegir entre varias acciones posibles. Su comportamiento depende de prompts, datos recuperados, memoria, salidas del modelo, herramientas disponibles y condiciones ambientales cambiantes.

Esto hace que el agente no sea ni un empleado ordinario ni un servicio de software convencional. Las empresas aún necesitan asignarle un responsable, definir su autoridad y conservar evidencia de su actividad.

Esa responsabilidad no puede seguir siendo implícita. Si varios equipos despliegan agentes mediante distintas plataformas, los responsables de seguridad necesitan un inventario completo que muestre dónde se ejecutan esos agentes y a qué pueden acceder.

AppViewX ilustró esta categoría de producto emergente cuando presentó una plataforma de identidad de agentes. La empresa afirma que su sistema descubre agentes, mapea sus permisos y supervisa su comportamiento.

El producto se lanzó como vista previa privada para empresas cualificadas. Sus afirmaciones aún requieren validación en despliegues reales, pero su diseño refleja hacia dónde se dirige el mercado.

El cambio importante es conceptual. Las empresas están empezando a tratar a cada agente como un actor gobernado, en lugar de como una función invisible dentro de una aplicación.

Ese cambio crea la tensión central del artículo. Cuanto más útil se vuelve un agente, más acceso suele requerir. Cada permiso añadido también amplía el daño posible tras una manipulación, un error o el compromiso de credenciales.

La capacidad autónoma no equivale a poder autorizado

La capacidad técnica de un agente nunca debería determinar lo que la organización le permite hacer.

Los desarrolladores suelen medir los agentes mediante tasas de finalización, pruebas de razonamiento o benchmarks de uso de herramientas. Estas evaluaciones describen la capacidad, pero no responden si un agente debería recibir autoridad operativa.

Un agente de programación podría ser capaz de modificar un repositorio entero. Eso no significa que deba integrar cambios en producción sin revisión.

Un agente financiero podría generar una instrucción de pago válida. Eso no significa que deba transferir fondos por encima de un umbral definido.

La gobernanza debe separar lo que un agente puede lograr de lo que tiene permitido ejecutar. Esta separación se vuelve esencial cuando un mismo modelo da soporte a muchos agentes con responsabilidades diferentes.

El mismo modelo subyacente podría impulsar un asistente de investigación, un agente de atención al cliente y un operador de infraestructura. Sus permisos deberían diferir porque las consecuencias de sus acciones son distintas.

Las organizaciones ya aplican un razonamiento similar a los empleados y los servicios de software. Un trabajador de atención al cliente no recibe acceso ilimitado a una base de datos solo porque entiende las consultas de bases de datos.

Los agentes necesitan el mismo principio, implementado mediante controles técnicos. Los permisos deben reflejar una tarea definida, un responsable de negocio, un entorno y un impacto aceptable.

NIST situó la identidad y la autorización en el centro de su iniciativa sobre estándares para agentes, anunciada el 17 de febrero de 2026. La iniciativa se centra en estándares, protocolos abiertos, investigación de seguridad e interoperabilidad de confianza.

NIST también describió agentes capaces de escribir código, gestionar comunicaciones y comprar bienes. Estos ejemplos muestran por qué las políticas de seguridad a nivel de modelo no pueden gobernar cada acción resultante.

Un agente que opera en varias aplicaciones necesita una identidad verificable. Cada sistema receptor debe saber qué agente solicita acceso y en nombre de quién actúa.

Esa identidad debe estar vinculada a una persona responsable o a una unidad organizativa. De lo contrario, un registro de auditoría puede mostrar que ocurrió una acción sin establecer quién autorizó al actor.

La autorización también debe tener en cuenta la delegación. Un agente podría crear un subagente especializado o llamar a otro agente operado por un proveedor externo.

Una simple credencial de usuario no refleja esa cadena. La organización necesita evidencia que describa la solicitud original, la autoridad delegada, los actores intermedios y la acción final.

Aquí es donde las herramientas de identidad conocidas siguen siendo útiles, pero incompletas. La autenticación puede verificar quién presenta una credencial. No establece automáticamente si una acción sensible al contexto coincide con el propósito asignado al agente.

Un agente de compras autenticado aún podría hacer un uso indebido de una herramienta de adquisición válida. Una instrucción comprometida podría dirigirlo a un proveedor no autorizado mientras todas las credenciales siguen siendo técnicamente válidas.

Por tanto, la gobernanza de agentes necesita una autorización consciente de la tarea. El sistema debe evaluar la acción solicitada frente al rol del agente, su objetivo actual, la sensibilidad de los datos y el impacto potencial.

Las credenciales de corta duración pueden reducir la exposición. Los alcances restringidos de las herramientas pueden impedir que un agente use funciones no relacionadas con su asignación.

Las organizaciones también deberían separar el acceso de lectura de la autoridad para actuar. Un agente que necesita datos de facturas para analizarlos no necesariamente necesita permiso para aprobarlas o pagarlas.

Estos controles introducen fricción, pero la autonomía indiscriminada no es la alternativa útil. El mejor objetivo es una autonomía proporcional, en la que la supervisión disminuya solo después de que la evidencia respalde esa decisión.

Los controles de acceso estáticos no pueden gobernar una intención cambiante

Los agentes de IA requieren controles en tiempo de ejecución porque unas credenciales válidas no garantizan un comportamiento válido.

Los sistemas de acceso tradicionales suelen preguntar si un usuario o servicio puede acceder a un recurso. La gobernanza de agentes también debe preguntar qué pretende hacer el actor y si esa acción sigue dentro de su objetivo asignado.

Esta diferencia se vuelve visible cuando un agente procesa contenido no confiable. Un documento, correo electrónico, sitio web o respuesta de una herramienta puede contener instrucciones que entran en conflicto con la solicitud del usuario.

La inyección de prompts es un ataque que introduce instrucciones maliciosas dentro del contenido que procesa un sistema de IA. El agente puede confundir esas instrucciones con orientación legítima.

Un agente de investigación podría leer una página web que le indica divulgar información almacenada. Un agente de soporte podría encontrar un mensaje que le ordena ignorar las reglas de verificación de clientes.

El modelo puede seguir funcionando técnicamente mientras obedece la instrucción equivocada. La autenticación por sí sola no detendrá el comportamiento porque el agente sigue presentando una identidad válida.

La lista de riesgos de agentes de OWASP identifica el secuestro de objetivos, el uso indebido de herramientas, el abuso de privilegios, el envenenamiento de memoria y las debilidades de la cadena de suministro entre las principales preocupaciones.

La lista recibió aportaciones de más de 100 investigadores de seguridad, profesionales, organizaciones usuarias y proveedores de tecnología. Refleja un cambio importante en el pensamiento sobre seguridad.

Los defensores no pueden evaluar únicamente el modelo. Deben examinar el sistema completo del agente, incluidos los prompts, la memoria, las herramientas, los conectores, las credenciales, la lógica de orquestación y las comunicaciones externas.

La aplicación de políticas en tiempo de ejecución ofrece una respuesta. Evalúa una acción mientras el agente está operando, en lugar de depender por completo de reglas establecidas durante el despliegue.

Una capa de políticas podría permitir a un agente de compras preparar un pedido, pero exigir aprobación antes de enviarlo. Podría impedir que ese mismo agente cambie los datos bancarios de un proveedor.

La decisión también puede depender de la reversibilidad. Redactar una invitación de calendario es fácil de deshacer. Eliminar datos de producción conlleva una carga de recuperación muy distinta.

Las acciones de alto impacto necesitan controles más sólidos. Estos pueden incluir confirmación humana, un segundo verificador automatizado, límites de transacción o ejecución dentro de un entorno aislado.

Sin embargo, la aprobación humana no es automáticamente significativa. Un revisor no puede tomar una decisión informada tras recibir una solicitud de confirmación sin explicación que solo contiene un botón de aprobar.

El sistema debería presentar la acción propuesta, los recursos afectados, la evidencia de respaldo y las consecuencias esperadas. También debería revelar la incertidumbre o la información contradictoria.

La memoria añade otra complicación. La memoria de un agente almacena hechos o interacciones pasadas para usarlos más adelante, lo que permite que el comportamiento persista entre sesiones.

Esa persistencia puede mejorar la continuidad, pero también puede conservar información falsa o maliciosa. Una entrada de memoria envenenada podría influir en decisiones mucho después de que desaparezca el ataque original.

Las organizaciones necesitan controles sobre quién puede escribir en la memoria, cómo las entradas reciben procedencia y cuándo expira el contexto antiguo. Los almacenes de memoria sensibles también requieren la misma disciplina de acceso que otros datos empresariales.

Esto importa para los sistemas internos de conocimiento. Una base de conocimiento con capacidad de búsqueda pasa a formar parte del entorno de decisiones del agente cuando se conecta mediante herramientas de recuperación.

Los permisos deben seguir los documentos subyacentes. Conectar un agente no debe eliminar los controles de acceso ni exponer información que el usuario solicitante normalmente no pueda ver.

El titular de Google News presenta estos sistemas como actores autónomos, pero la autonomía debe seguir siendo condicional. Toda acción significativa necesita una vía acotada desde la autoridad hasta la ejecución.

La verdadera competencia es entre autonomía y rendición de cuentas

Las empresas no están eligiendo entre agentes útiles y agentes seguros; están decidiendo si la autonomía seguirá siendo responsable a la velocidad operativa.

El argumento más sólido a favor de los agentes autónomos es la eficiencia. Pueden coordinar tareas repetitivas, operar de forma continua y reducir las demoras entre el análisis y la ejecución.

La objeción más fuerte se refiere al radio de impacto. Un agente rápido puede repetir una mala acción en muchos registros, sistemas o clientes antes de que una persona lo advierta.

Ese riesgo aumenta cuando un agente cuenta con credenciales amplias. Aumenta de nuevo cuando el agente puede delegar trabajo o modificar el contexto utilizado por agentes posteriores.

Los proveedores de seguridad están respondiendo desde distintas direcciones. Los especialistas en identidad enfatizan las identidades criptográficas y los privilegios limitados. Las empresas de seguridad de datos destacan la supervisión, la recuperación y la protección de información sensible.

Los proveedores de seguridad en la nube se centran en las conexiones entre agentes, aplicaciones y datos. Los proveedores de plataformas de agentes suelen destacar la evaluación, la definición de políticas y los controles para desarrolladores.

Estos enfoques se superponen, pero ninguno resuelve el problema por sí solo. Una identidad verificada no evita la manipulación de objetivos, mientras que la supervisión del comportamiento no establece quién otorgó la autoridad.

Del mismo modo, un paso de aprobación humana no puede reparar registros de auditoría inexistentes. Una herramienta de reversión no puede deshacer todas las consecuencias físicas, financieras o reputacionales.

La Infocomm Media Development Authority de Singapur publicó su marco de gobernanza para agentes el 22 de enero de 2026. Organiza la gobernanza en torno a cuatro dimensiones prácticas.

Las organizaciones deben primero acotar el riesgo limitando la autonomía y el acceso. Después deben establecer una rendición de cuentas humana significativa y puntos de aprobación.

El marco también exige controles durante todo el ciclo de vida, pruebas de referencia y acceso a servicios incluidos en listas permitidas. Su dimensión final aborda la transparencia, la capacitación y la responsabilidad del usuario final.

Este enfoque reconoce que la gobernanza de agentes no puede residir por completo dentro del departamento de seguridad. Los responsables de producto deciden el caso de uso, los desarrolladores ensamblan el sistema y los líderes empresariales autorizan el despliegue operativo.

Los equipos de compras también influyen en el riesgo cuando seleccionan herramientas de terceros. El agente de un proveedor podría procesar datos empresariales mediante modelos externos, conectores o servicios de memoria.

Los contratos deben abordar el registro de eventos, la notificación de incidentes, la retención de datos, los subcontratistas y los cambios en el sistema. Los compradores deben entender si el proveedor puede reproducir la ruta de decisión de un agente después de un incidente.

La disyuntiva central no se resuelve fijando para siempre un único nivel de autonomía. Los permisos de un agente deben cambiar a medida que cambien la tarea, el entorno y la evidencia.

Un agente nuevo podría comenzar con acceso de solo lectura y aprobación obligatoria. Las pruebas controladas satisfactorias podrían justificar una ejecución limitada dentro de un flujo de trabajo estrecho.

Los fallos repetidos deben reducir la autoridad. Un comportamiento inesperado, una desviación de configuración o una actualización del modelo deben activar otra revisión.

Esto crea un modelo de autonomía ganada. El agente recibe más libertad operativa solo después de que las pruebas demuestren un comportamiento aceptable en condiciones pertinentes.

Incluso entonces, las organizaciones deben preservar límites estrictos. Algunas acciones siguen siendo inadecuadas para una ejecución sin supervisión porque sus consecuencias son difíciles de revertir.

Entre los ejemplos se incluyen cambiar controles de acceso, publicar divulgaciones reguladas, rescindir empleos, transferir grandes sumas de dinero o eliminar registros principales.

El límite preciso variará entre empresas. Lo que debe mantenerse constante es una decisión explícita que vincule la autonomía con el riesgo, la reversibilidad y una titularidad responsable.

Lo que los productos actuales de gobernanza todavía no pueden demostrar

El mercado está produciendo herramientas de control de agentes más rápido de lo que los compradores pueden verificar si esos controles funcionan entre modelos, plataformas y flujos de trabajo delegados.

Los anuncios de productos suelen prometer descubrimiento, supervisión, aplicación de políticas y corrección rápida. Estas funciones son valiosas, pero la evidencia circundante sigue siendo desigual.

Un proveedor puede demostrar que su plataforma bloquea una llamada de herramienta conocida. Esa prueba no establece el rendimiento frente a ataques nuevos, objetivos ambiguos o cadenas complejas de delegación.

El descubrimiento también presenta un problema difícil. Los agentes gestionados de forma centralizada son más fáciles de inventariar, pero los empleados pueden crear automatizaciones informales mediante herramientas de navegador, scripts y servicios externos.

Esos agentes podrían utilizar credenciales personales o claves API copiadas. Pueden operar fuera de los sistemas que supervisa una consola central de gobernanza.

Por tanto, las organizaciones se enfrentan a un equivalente de agentes de la TI en la sombra. La diferencia es que los agentes en la sombra pueden iniciar acciones y crear automatización adicional.

Las herramientas de supervisión deben distinguir el comportamiento malicioso de la variación legítima. Los agentes suelen utilizar secuencias diferentes para completar la misma tarea, lo que hace que las reglas de comportamiento rígidas sean propensas a falsas alarmas.

Demasiadas alertas pueden socavar la supervisión. Los equipos de seguridad pueden ignorar advertencias ruidosas, mientras que los equipos empresariales buscan formas de sortear controles que bloquean con frecuencia el trabajo legítimo.

Las explicaciones son otro punto débil. Un agente puede producir una explicación plausible de su razonamiento sin aportar evidencia fiable sobre el proceso que generó una acción.

Los sistemas de auditoría deben priorizar los eventos observables. Los registros útiles incluyen la procedencia de las entradas, las llamadas de herramientas, las decisiones de autorización, el acceso a datos, las versiones de modelos, los resultados de políticas y las salidas finales.

Esos registros deben permanecer protegidos contra alteraciones. Un agente no debe poder borrar la evidencia necesaria para investigar su propio comportamiento.

Las afirmaciones sobre recuperación también merecen escrutinio. Restaurar una rama de código eliminada es posible cuando existe una copia independiente. Retirar un correo electrónico externo o revertir información divulgada es mucho más difícil.

Algunas acciones son solo parcialmente reversibles. Un pago podría cancelarse, pero el intento de transferencia aún puede generar preocupaciones de cumplimiento o fraude.

Una plataforma de gobernanza debe indicar qué recursos puede restaurar y qué consecuencias permanecen fuera de su control. Los compradores necesitan evidencia basada en escenarios, no una promesa general de reversión.

La interoperabilidad añade más incertidumbre. Las empresas rara vez operan con un solo modelo, un solo marco de agentes o un solo proveedor de identidad.

Una política que funciona dentro de la plataforma de un proveedor podría perder contexto cuando el agente llama a una herramienta externa. Los agentes delegados pueden cruzar fronteras organizativas y técnicas.

Los estándares pueden reducir esa fragmentación, pero aún están en desarrollo. El trabajo de NIST indica impulso, mientras que las implementaciones prácticas necesitarán pruebas en sistemas empresariales reales.

El Foro Económico Mundial informó que el 82 % de los ejecutivos planeaba adoptar agentes en un plazo de uno a tres años. La cifra describe intención, no una adopción en producción comprobada.

Esa distinción importa. El entusiasmo de las encuestas no demuestra que las organizaciones cuenten con inventarios fiables, controles maduros o retornos medibles.

Por lo tanto, las afirmaciones de los proveedores deben seguir siendo afirmaciones hasta que evaluaciones independientes las confirmen. Los compradores deben solicitar evidencia de despliegues que se asemejen a su propio perfil de riesgo.

El mercado de gobernanza también enfrenta un problema de incentivos. Las plataformas que venden mayor autonomía a menudo venden los controles destinados a hacer aceptable esa autonomía.

Esa situación no invalida sus herramientas. Sí significa que los clientes necesitan pruebas de seguridad independientes, una rendición de cuentas contractual clara y autoridad interna para restringir el despliegue.

Tres señales mostrarán si la gobernanza de agentes está madurando

La próxima fase se medirá mediante identidad interoperable, autonomía basada en evidencia y despliegues en producción recuperables, en lugar de declaraciones de políticas adicionales.

La primera señal es una guía de implementación concreta de la AI Agent Standards Initiative de NIST. Su valor dependerá de si las organizaciones pueden traducir los estándares en controles interoperables.

Un resultado útil permitiría que una aplicación verificara la identidad de un agente, la autoridad delegada, el alcance permitido y el responsable correspondiente a través de los límites entre proveedores.

Los campos de identidad comunes también mejorarían la respuesta a incidentes. Los investigadores podrían reconstruir qué agente actuó, quién lo autorizó y si su autoridad cambió durante la ejecución.

Si los estándares siguen siendo abstractos, los proveedores continuarán implementando modelos de identidad incompatibles. Esa fragmentación debilitaría el argumento a favor de una gobernanza centralizada en entornos heterogéneos.

La segunda señal es la adopción de políticas de autonomía dinámicas. Las empresas deberían empezar a informar cómo cambian los permisos de los agentes según las pruebas, el riesgo y el rendimiento observado.

Esto requiere criterios medibles. Las tasas de finalización por sí solas son insuficientes porque un agente puede completar una tarea mientras vulnera una política o expone información protegida.

Las evaluaciones deben cubrir el uso no autorizado de herramientas, la inyección de prompts, el envenenamiento de memoria, el uso indebido de credenciales, la delegación y la recuperación. Las pruebas también deben reflejar el entorno de producción real del agente.

Un despliegue maduro conectará los resultados de las evaluaciones con los permisos. Las pruebas fallidas deben bloquear automáticamente una autoridad más amplia hasta que se corrija y revise la debilidad.

La evidencia de esta práctica reforzaría el argumento de que las empresas pueden escalar la autonomía de manera responsable. Los modelos de permisos estáticos sugerirían que la gobernanza sigue por detrás del despliegue.

La tercera señal es la evidencia pública sobre la contención y recuperación de incidentes. Las organizaciones deben demostrar que pueden detectar actividad dañina de agentes y limitar sus consecuencias.

Esto no exige exponer detalles sensibles de incidentes. Las empresas pueden publicar escenarios anonimizados, evaluaciones independientes y resultados medidos de recuperación.

Las divulgaciones útiles explicarían qué ocurrió, qué control lo detectó, hasta dónde se propagó la acción y qué pudo revertirse.

Los fallos también aportarán información. Un incidente que involucre a un agente correctamente autenticado mostraría por qué la identidad por sí sola no puede establecer una intención fiable.

Un fallo que atraviese varios agentes pondría a prueba si los registros actuales preservan una cadena de delegación completa. Un resultado irreversible expondría los límites del marketing sobre reversión.

Estas señales importan más que otro panel de gobernanza. La tecnología debe demostrar que los controles siguen siendo eficaces cuando los agentes operan a velocidad de máquina en sistemas reales.

Para los desarrolladores, la implicación inmediata es clara. La arquitectura de agentes debe exponer puntos de control de políticas, llamadas de herramientas rastreables y credenciales restringidas desde el principio.

Para los compradores empresariales, los requisitos de gobernanza deben formar parte de las compras antes del despliegue. Adaptar la titularidad, la auditabilidad y la recuperación después de que los agentes se extiendan por los departamentos costará más.

Los trabajadores del conocimiento también tienen interés en ello. Los agentes actúan cada vez más mediante sus cuentas, datos y herramientas de comunicación, creando consecuencias que pueden aparecer bajo una identidad humana.

El titular de Google News identifica correctamente la necesidad de un nuevo modelo de gobernanza. La pregunta más difícil es si las organizaciones impondrán ese modelo antes de que la actividad autónoma se convierta en infraestructura habitual.

Pregunte quién es responsable de cada agente desplegado, qué acciones puede realizar y qué sucede cuando cambian sus instrucciones. Después, exija evidencia de que las respuestas resisten un fallo real.