La gobernanza uniforme está fallando a los agentes de IA empresariales
Google News puso de relieve una seria advertencia para las empresas: una gobernanza uniforme puede hacer que los agentes de IA sean menos seguros, menos útiles o ambas cosas. El análisis de fondo, publicado por JFrog y destacado por Techzine Global, se apoya en una previsión de Gartner con importantes consecuencias operativas.
Gartner prevé que el 40% de las empresas degradará o retirará agentes autónomos de IA antes de 2027. La firma espera que las brechas de gobernanza solo se hagan evidentes después de que ocurran incidentes en producción. Esa previsión transforma la gobernanza, que deja de ser un ejercicio de cumplimiento para convertirse en un riesgo de despliegue.
El conflicto no es gobernanza frente a innovación. Es control uniforme frente a control proporcional. Un asistente de investigación y un agente autónomo de pagos no generan la misma exposición. Sin embargo, muchas organizaciones siguen sometiendo a ambos a procesos de revisión, permisos y reglas de supervisión idénticos.
Ese enfoque produce dos fallos opuestos. Los controles excesivos hacen que las herramientas de bajo riesgo sean demasiado lentas de desplegar. Los controles generales débiles dejan a los agentes de alto impacto con más autoridad de la que las organizaciones pueden supervisar con seguridad.
La alternativa emergente asigna controles según la autonomía, el acceso y las posibles consecuencias. También trata cada modelo, herramienta, plugin, skill y conexión como un componente de software sujeto a gobernanza.
Qué cambió realmente la noticia de Google News
El cambio importante es la vinculación explícita que hace Gartner entre la gobernanza uniforme y los despliegues fallidos de agentes de IA.
Gartner publicó su advertencia el 26 de mayo de 2026. Sostuvo que aplicar el mismo modelo de gobernanza a todos los agentes genera fallos porque estos operan con distinta autoridad y alcance.
La distinción parece obvia, pero las políticas empresariales a menudo la ignoran. Muchos programas comienzan con una política de uso aceptable, un comité de revisión y una lista de comprobación de seguridad. Por lo general, esos controles abordan la IA generativa como una categoría amplia.
Los agentes complican esa estructura. Un agente de IA es un sistema que puede planificar pasos, seleccionar herramientas y ejecutar acciones para alcanzar un objetivo. Por tanto, su comportamiento depende de más factores que su modelo subyacente.
Un agente básico de resumen puede leer documentos y producir texto. No puede modificar un archivo fuente, enviar un mensaje ni ejecutar código. Su peor fallo probable es una respuesta inexacta o engañosa.
Un agente de atención al cliente puede leer datos de cuentas, actualizar registros, emitir créditos y contactar con usuarios. Sus errores pueden afectar al dinero, la privacidad, las obligaciones contractuales y la confianza de los clientes.
Un agente de infraestructura plantea una exposición aún mayor. Podría modificar recursos en la nube, cambiar políticas de acceso, desplegar código o responder a alertas de seguridad. Una acción incorrecta puede propagarse por los sistemas conectados.
Una sola etiqueta, «agente de IA», oculta estas diferencias. Un único paquete de controles vuelve a ocultarlas.
La advertencia sobre gobernanza de Gartner separa la autonomía del agente del alcance de su acceso. Ambas dimensiones importan.
La autonomía describe con qué independencia un agente puede elegir y ejecutar pasos. El alcance describe los sistemas, datos y procesos empresariales a los que puede acceder. Un agente puede tener una puntuación alta en una dimensión y baja en otra.
Por ejemplo, un agente muy autónomo dentro de un entorno de pruebas desechable puede generar un riesgo empresarial limitado. Un agente menos autónomo con acceso a pagos en producción puede requerir controles estrictos de todos modos.
El resultado de Google News importa porque apunta a un modelo de gobernanza basado en la exposición real. La pregunta relevante ya no es si una organización «permite agentes».
Los líderes deben preguntarse qué puede observar, decidir y modificar cada agente. También deben determinar si esas acciones pueden revertirse.
Estas preguntas acercan la gobernanza a la ingeniería. Los equipos de políticas siguen definiendo el riesgo aceptable, pero los sistemas técnicos deben hacer cumplir esos límites durante el desarrollo y en producción.
Por tanto, el cambio es estructural. La gobernanza de IA empresarial no puede seguir siendo un documento aplicado durante la aprobación. Debe convertirse en un sistema de control continuo vinculado a identidades, permisos, dependencias, acciones y resultados.
Por qué una sola política crea dos fallos distintos
La gobernanza uniforme falla porque la misma restricción puede ser excesiva para un agente y peligrosamente débil para otro.
El primer fallo es la parálisis operativa. Un asistente interno de bajo riesgo puede enfrentarse al mismo proceso de aprobación que un agente autorizado para modificar registros financieros.
Esa revisión puede involucrar a equipos jurídicos, de privacidad, ciberseguridad, riesgo de modelos, compras y arquitectura. Cada grupo puede solicitar pruebas diseñadas para los sistemas más sensibles de la organización.
Este proceso tiene sentido para despliegues con consecuencias significativas. Se vuelve desproporcionado cuando un agente solo resume documentación pública o redacta textos para revisión humana.
Los largos ciclos de aprobación no siempre detienen la adopción. Pueden desplazarla fuera de los canales aprobados. Los empleados siguen teniendo plazos, trabajo repetitivo y presión para usar las herramientas disponibles.
El resultado es la IA en la sombra: sistemas no aprobados utilizados sin visibilidad central. Por tanto, una política uniforme estricta puede reducir el despliegue formal mientras incrementa el despliegue desconocido.
El segundo fallo es la exposición sistémica. Una lista de comprobación general puede aprobar a un agente de alto impacto sin probar sus herramientas exactas, credenciales, rutas de fallo o comportamiento de escalamiento.
Un agente que puede leer facturas es distinto de uno que puede aprobar pagos. Un agente que redacta un cambio en la nube es distinto de uno que lo despliega automáticamente.
El lenguaje general de las políticas rara vez capta estos límites. Términos como «supervisión humana» tampoco significan mucho sin describir dónde se produce la aprobación y qué evidencia recibe el revisor.
Un humano que aprueba cada acción puede convertirse en un mero validador automático. Un humano que solo revisa acciones excepcionales necesita criterios fiables para identificar las excepciones.
El momento también importa. La aprobación tras una acción irreversible no constituye una supervisión significativa. Una auditoría posterior a un incidente puede explicar el daño, pero no puede evitarlo.
El análisis de gobernanza de agentes de JFrog plantea el problema como una elección entre restricciones generales y controles proporcionales. Su argumento refleja una perspectiva de cadena de suministro de software.
Esa perspectiva resulta útil porque los agentes constan de múltiples componentes cambiantes. Un equipo puede aprobar un agente hoy y actualizar mañana su modelo, prompt, plugin o herramienta.
Cada cambio puede modificar el comportamiento. Una nueva herramienta puede ampliar el acceso. Un prompt revisado puede cambiar las prioridades de decisión. Una actualización de dependencias puede introducir código vulnerable.
La gobernanza uniforme trata al agente aprobado como un objeto estable. En la práctica, el sistema desplegado se comporta más como una pila de software cambiante.
Por tanto, el modelo de aprobación debe contemplar el cambio. Una actualización inofensiva no debería activar el mismo proceso que una nueva capacidad de pago. Sin embargo, los cambios significativos no pueden pasar inadvertidos.
Esto requiere umbrales definidos. Los equipos necesitan saber qué cambios exigen pruebas automatizadas, revisión de seguridad, aprobación empresarial o una nueva evaluación de riesgos.
El problema central no es la falta de papeleo. Es la baja resolución de los controles.
La gobernanza tiene baja resolución cuando considera equivalentes a todos los agentes. Adquiere una resolución útil cuando distingue entre autoridad, sensibilidad de los datos, reversibilidad y alcance operativo.
La verdadera división es entre acceso de lectura y autoridad para actuar
Un agente se vuelve sustancialmente más difícil de gobernar cuando puede cambiar el mundo fuera de su ventana de conversación.
Los chatbots tradicionales producen principalmente contenido. Los usuarios deciden si confían en ese contenido y si actúan en consecuencia. Esta separación crea un límite natural de aprobación.
Los agentes pueden eliminar ese límite. Pueden seleccionar herramientas, llamar a APIs, actualizar aplicaciones y seguir trabajando sin que una persona apruebe cada paso.
Esa capacidad genera valor porque reduce los traspasos manuales. También desplaza el punto de fallo de una respuesta en pantalla a una acción dentro de un proceso empresarial.
Consideremos tres escenarios empresariales.
Un agente de investigación lee documentos aprobados y redacta un resumen de mercado. No cuenta con herramientas de comunicación externa. Una persona revisa el resultado antes de su distribución.
Un agente de ventas lee registros de clientes, crea tareas de seguimiento y redacta mensajes. Puede escribir en una plataforma de relación con clientes, pero no puede enviar comunicaciones externas.
Un agente de ingresos cambia el estado de las suscripciones, aplica créditos y envía avisos a los clientes. Puede generar consecuencias financieras y reputacionales directas.
Estos sistemas pueden utilizar el mismo modelo fundacional. Aun así, sus requisitos de gobernanza deberían diferir de forma notable.
El primer agente necesita controles para el acceso a fuentes, la filtración de datos y la exactitud factual. El segundo también necesita restricciones de escritura, permisos a nivel de registro y registros de cambios.
El tercero necesita límites de transacción, puertas de aprobación, procedimientos de reversión, separación de funciones y suspensión rápida. También puede requerir una revisión de cumplimiento vinculada a jurisdicciones específicas.
Esto es gobernanza proporcional. Los controles aumentan a medida que un agente cruza límites de confianza con consecuencias más importantes.
El principio ya aparece en marcos consolidados. El NIST AI RMF organiza el trabajo de riesgos mediante las funciones de gobernar, mapear, medir y gestionar.
NIST no presenta estas funciones como una lista de comprobación universal. Sus directrices piden a las organizaciones alinear la gestión de riesgos con el contexto, los objetivos, los requisitos legales y la tolerancia al riesgo.
La función de mapeo del marco es especialmente relevante. Un equipo no puede elegir controles adecuados hasta comprender las tareas previstas del agente, las partes afectadas, las condiciones operativas y los posibles modos de fallo.
La Unión Europea sigue una lógica relacionada. Su Ley de IA establece distintas obligaciones según las categorías de riesgo y los casos de uso.
La guía sobre la Ley de IA distingue entre sistemas de riesgo inaceptable, alto, de transparencia y mínimo. No regula de forma idéntica todas las aplicaciones de IA.
La gobernanza empresarial necesita una diferenciación similar a un nivel más detallado. La clasificación regulatoria proporciona un límite, pero el riesgo operativo interno requiere capas adicionales.
Dos agentes pueden quedar fuera de una categoría jurídica de alto riesgo y, aun así, generar exposiciones de ciberseguridad muy diferentes. Uno puede acceder a información pública, mientras otro dispone de credenciales para sistemas internos.
La identidad se convierte en un control central. Cada agente debería tener una identidad no humana distinta, en lugar de tomar prestada la cuenta de un desarrollador o compartir una credencial de servicio amplia.
Los permisos deben seguir el principio de mínimo privilegio. Esto significa conceder solo el acceso necesario para una tarea definida y retirarlo cuando ya no sea necesario.
Las organizaciones también necesitan políticas a nivel de acción. El acceso a una aplicación no debería autorizar automáticamente todas las operaciones dentro de ella.
Un agente puede necesitar permiso para leer un ticket, añadir una nota interna y sugerir un cambio de estado. Puede que no necesite permiso para cerrar el ticket ni eliminar su historial.
Esta distinción crea una superficie de acción controlable. También hace que las auditorías sean más útiles porque los registros muestran qué identidad solicitó cada operación.
Cada agente también es una cadena de suministro de software
La gobernanza no puede detenerse en la aprobación del modelo porque los modelos son solo un componente en la ruta de ejecución de un agente.
Los agentes modernos combinan modelos con prompts, memoria, sistemas de recuperación, herramientas, plugins, APIs y código de orquestación. Cada componente puede modificar lo que el agente sabe o hace.
Un modelo puede generar un plan razonable. Una herramienta comprometida aún puede ejecutar algo perjudicial. Una herramienta segura también puede volverse peligrosa cuando se configura con permisos excesivos.
El Model Context Protocol, comúnmente llamado MCP, ilustra este desafío. MCP proporciona una forma estándar para que las aplicaciones de IA se conecten con fuentes de datos y herramientas ejecutables.
Esa estandarización puede reducir el trabajo de integración personalizada. También puede facilitar la incorporación de nuevas capacidades, a veces mediante paquetes o servidores obtenidos de fuentes externas.
La facilidad de conexión cambia el problema de la gobernanza. Un equipo de seguridad puede aprobar el modelo de un agente, pero pasar por alto un servidor MCP añadido recientemente con acceso a código fuente o credenciales.
Los plugins y las skills generan preocupaciones similares. Pueden contener esquemas, instrucciones, scripts, ámbitos de autenticación y cadenas de dependencias. Cada elemento amplía el comportamiento del sistema.
Los programas de software tradicionales siguen rutas de código explícitas, aunque los sistemas complejos aún pueden comportarse de forma inesperada. Los agentes añaden decisiones impulsadas por modelos que eligen entre esas rutas durante la ejecución.
Esto no hace que los agentes sean imposibles de proteger. Hace que el inventario de componentes y la observación en tiempo de ejecución sean esenciales.
Las organizaciones necesitan una lista de materiales para cada agente desplegado. Ese registro debe identificar modelos, prompts, herramientas, plugins, paquetes, contenedores, fuentes de datos y servicios externos.
Cada componente debe tener un propietario y una versión. Los equipos deben saber quién lo aprobó, qué pruebas superó y a qué sistemas puede acceder.
Los controles de dependencias son importantes porque una actualización puede alterar el comportamiento sin cambiar el nombre público del agente. Una versión de un plugin puede solicitar nuevos permisos o introducir una biblioteca vulnerable.
Los artefactos deben pasar por repositorios de confianza. Así, las comprobaciones de seguridad pueden analizar paquetes, contenedores y archivos de configuración antes del despliegue.
La misma disciplina debe aplicarse a los prompts y las políticas. No son código ejecutable en el sentido tradicional, pero los cambios pueden alterar sustancialmente el comportamiento del agente.
Una actualización de prompt podría indicar a un agente que priorice la velocidad sobre la revisión. Una actualización de política podría permitir la ejecución automática por debajo de un umbral de transacción.
Ambos cambios merecen historial de versiones y pruebas. La revisión requerida debe corresponderse con su impacto, no con su formato de archivo.
La guía de OWASP sobre agentes describe riesgos que surgen de los objetivos, las herramientas, la memoria, la identidad y la interacción multiagente. Estos riesgos van más allá de las salidas inexactas de los modelos.
La manipulación de objetivos puede redirigir a un agente hacia el objetivo de un atacante. El uso indebido de herramientas puede convertir una funcionalidad legítima en una vía de ataque.
El envenenamiento de memoria puede influir en decisiones posteriores mediante contexto almacenado. Una autonomía excesiva puede permitir que un agente realice acciones más allá de la intención del usuario.
Estas amenazas requieren controles diferentes. El filtrado de entradas por sí solo no puede impedir una dependencia comprometida. La evaluación del modelo por sí sola no puede detectar una cuenta de servicio con privilegios excesivos.
Por eso la gobernanza proporcional también debe centrarse en los artefactos. La clasificación de riesgos determina los controles necesarios, mientras que la gestión de artefactos hace que esos controles sean aplicables.
El modelo responde a aquello sobre lo que el agente puede razonar. Sus herramientas y credenciales determinan a qué puede afectar ese razonamiento.
La gobernanza proporcional necesita evidencia, no etiquetas
Un nivel de riesgo tiene poco valor si los equipos no pueden demostrar que sus controles funcionan durante la ejecución real.
Las organizaciones suelen crear categorías como riesgo bajo, medio y alto. El ejercicio puede convertirse en otra lista de verificación uniforme si esas etiquetas carecen de criterios medibles.
Un nivel útil comienza con la autonomía. Los equipos deben documentar si el agente solo recomienda acciones, requiere aprobación o ejecuta de forma independiente.
La siguiente dimensión es el acceso. Esto incluye la sensibilidad de los datos, los sistemas permitidos, los tipos de operación, los límites geográficos y los usuarios afectados.
Una tercera dimensión es la consecuencia. Los equipos deben estimar el daño derivado de un comportamiento incorrecto, malicioso o no disponible.
La reversibilidad constituye otra dimensión importante. Un borrador puede descartarse. Un registro interno a menudo puede restaurarse. Una divulgación pública o una transferencia financiera pueden ser difíciles de revertir.
La velocidad también modifica el riesgo. Un agente que realiza una acción revisada al día plantea un problema de contención distinto al de uno que efectúa miles de cambios por hora.
Estas dimensiones deben dar lugar a controles concretos.
Un agente de solo lectura y bajo riesgo puede necesitar fuentes aprobadas, protecciones contra pérdida de datos, revisión de salidas y registro básico. Su proceso de lanzamiento puede mantenerse ligero.
Un agente de riesgo medio con capacidad de escritura puede requerir credenciales con alcance limitado, registros de acciones, pruebas automatizadas, límites de uso y aprobación para operaciones sensibles.
Un agente autónomo de alto riesgo necesita una separación más sólida. Los controles pueden incluir límites de transacción, autorización independiente, supervisión continua, suspensión de emergencia y procedimientos de reversión probados.
La organización debe verificar entonces esos controles. Una declaración escrita de que un agente aplica el principio de mínimo privilegio no demuestra lo que realmente puede hacer su credencial.
Las pruebas deben intentar realizar operaciones prohibidas. Deben confirmar que el agente no puede acceder a registros, herramientas o entornos no aprobados.
Los equipos también deben probar vías indirectas. Un agente podría no tener permiso para modificar un pago directamente, pero aun así activar un flujo de trabajo que realice el cambio.
La telemetría de ejecución proporciona la siguiente capa de evidencia. Los registros deben capturar la identidad del agente, la herramienta seleccionada, los parámetros, el resultado y el estado de aprobación.
Los datos sensibles requieren un tratamiento cuidadoso dentro de los registros. La supervisión no puede convertirse en una nueva fuente de información confidencial o credenciales.
Las líneas base de comportamiento pueden ayudar a detectar actividad inusual, pero no deben sustituir una política explícita. El comportamiento novedoso de un agente no siempre es malicioso, y el comportamiento conocido no siempre es seguro.
Los controles deterministas deben bloquear acciones claramente prohibidas. Los sistemas conductuales deben identificar patrones inesperados que merezcan investigación.
La pregunta escéptica es si las empresas pueden mantener este nivel de detalle en miles de agentes. Un modelo proporcional exige un inventario, una propiedad y una supervisión más completos que una prohibición generalizada.
Una implementación deficiente puede producir inflación de niveles. Los equipos pueden clasificar todo como de bajo riesgo para evitar retrasos, o clasificarlo todo como de alto riesgo para evitar la responsabilidad personal.
Por lo tanto, los responsables del negocio deben participar. Los equipos de seguridad comprenden las amenazas, pero los propietarios de los procesos comprenden las consecuencias financieras, para los clientes y operativas.
El propietario de un agente debe seguir siendo responsable después del despliegue. La propiedad incluye revisar incidentes, aprobar cambios importantes y confirmar que el agente sigue cumpliendo un propósito válido.
La gobernanza también debe caducar. Los permisos y las aprobaciones deben tener fechas de revisión en lugar de permanecer válidos indefinidamente.
El modelo más sólido no es el control sin fricción. Es la fricción aplicada donde las consecuencias la justifican.
Qué deberían vigilar a continuación los lectores de Google News
La siguiente prueba es si las empresas convierten los principios basados en riesgos en controles operativos aplicables.
La primera señal es la calidad de los inventarios de agentes. Las organizaciones no pueden gobernar sistemas que no pueden identificar.
Un inventario creíble debe incluir agentes autorizados, agentes integrados de proveedores, prototipos internos y servicios externos conectados mediante cuentas de empleados.
El descubrimiento debe ir más allá de los registros de adquisiciones. Los agentes pueden incorporarse mediante extensiones de navegador, funciones SaaS, paquetes de desarrollo, herramientas de flujo de trabajo y marketplaces en la nube.
La segunda señal es la separación de identidades. Los despliegues maduros proporcionarán a cada agente de producción una identidad distinta con permisos limitados e inspeccionables.
Las cuentas compartidas seguirán siendo una señal de alerta. Ocultan la responsabilidad y dificultan suspender un agente sin interrumpir otros servicios.
La tercera señal es la visibilidad a nivel de acción. Las empresas deben saber qué operaciones intentan realizar los agentes, cuáles bloquean las políticas y cuáles aprueban las personas.
Un panel que muestra el uso de modelos es insuficiente. Los recuentos de tokens no revelan si un agente modificó un campo de base de datos o inició una transacción empresarial.
La base de conocimientos ATLAS de MITRE ofrece una referencia útil sobre tácticas adversarias contra sistemas habilitados por IA. Sus técnicas en evolución muestran por qué los modelos de amenazas deben seguir el comportamiento real del sistema.
Las organizaciones también deben hacer seguimiento de los incidentes de producción por nivel de agente. Esa evidencia puede revelar si los controles son proporcionales o simplemente convenientes.
Si los agentes de bajo riesgo enfrentan largas demoras sin beneficios de seguridad significativos, la gobernanza sigue siendo demasiado restrictiva. Si los incidentes de alto riesgo aparecen tras el despliegue, los controles siguen siendo demasiado débiles.
Las métricas deben incluir la latencia de aprobación, las acciones bloqueadas, la frecuencia de reversión, las excepciones de política, las herramientas no autorizadas y la propiedad sin resolver.
Estos indicadores conectan la gobernanza con las operaciones. También ayudan a los líderes a determinar si un control reduce el riesgo o solo genera trabajo administrativo.
Los avances regulatorios proporcionarán otra señal. La Unión Europea continúa publicando orientaciones sobre clasificación de alto riesgo, supervisión, documentación, supervisión humana, ciberseguridad y respuesta a incidentes.
Sin embargo, el cumplimiento legal representa un mínimo, no un programa completo de seguridad para agentes. Muchas acciones perjudiciales quedan fuera de los casos de uso específicamente regulados.
El comportamiento de los proveedores también merece escrutinio. Las plataformas empresariales incorporan cada vez más agentes en productos existentes, a veces activando nuevas capacidades mediante actualizaciones rutinarias de funciones.
Los clientes deben preguntar si esos agentes reciben identidades separadas. También deben preguntar qué acciones pueden limitarse y qué registros siguen disponibles para auditoría.
La previsión de Gartner ganará credibilidad si las empresas comienzan a degradar agentes de ejecución autónoma a modos de recomendación. Ese cambio mostraría que las organizaciones corrigen la autoridad tras las lecciones de producción.
La previsión se debilitará si las empresas escalan sistemas autónomos sin un aumento de incidentes ni reversiones generalizadas. Ese resultado exige controles que funcionen en los entornos de desarrollo y de ejecución.
Google News ha amplificado una advertencia útil, pero el titular no debería convertirse en una razón para prohibir los agentes empresariales. El argumento respalda una gobernanza más detallada, no una automatización menos ambiciosa.
Los ejecutivos deben hacer una pregunta directa sobre cada agente desplegado: ¿qué puede cambiar este sistema sin que una persona lo detenga?
La respuesta debe determinar su identidad, permisos, pruebas, supervisión, puertas de aprobación y proceso de apagado. Si esos controles siguen siendo idénticos para todos los agentes, el modelo de gobernanza aún no refleja el riesgo.
