La gobernanza de los agentes de IA empresariales pasa de las políticas al control en tiempo de ejecución
La gobernanza de los agentes de IA empresariales ha cruzado su primer límite operativo: los documentos de políticas por sí solos no pueden controlar software que realiza acciones reales de forma independiente. El modelo emergente traslada la aplicación de controles al instante previo a que un agente envíe datos, modifique un registro, invoque una herramienta o gaste dinero.
Este cambio define el argumento central de la reciente tesis del punto de acción. La gobernanza ya no consiste únicamente en aprobar un modelo, documentar sus riesgos o revisar sus resultados tras la implementación. Se está convirtiendo en un problema de seguridad en tiempo de ejecución.
La presión recae sobre los equipos de seguridad, los proveedores de identidad, los responsables de aplicaciones y todos los proveedores que desarrollan plataformas de agentes. El conflicto es claro. Las empresas quieren que los agentes completen flujos de trabajo más largos con menos supervisión, mientras que los equipos de seguridad necesitan que toda acción relevante siga siendo atribuible y reversible.
Este no es otro debate sobre si la inteligencia artificial necesita normas. La cuestión más urgente es dónde deben aplicarse esas normas. Para los sistemas autónomos, la respuesta está cada vez más cerca de la propia acción.
Qué cambió en la gobernanza de los agentes de IA empresariales
El objeto gobernado ya no es solo un modelo o una aplicación. Es una identidad que actúa, con herramientas, memoria, permisos y un contexto cambiante.
La supervisión tradicional de la IA se centra en una secuencia relativamente estable. Una persona envía una entrada, un modelo genera una salida y alguien revisa o utiliza ese resultado. La gobernanza puede examinar el modelo, sus datos de entrenamiento, el uso previsto, los resultados de evaluación y el contenido generado.
Un agente de IA cambia esa secuencia. Puede dividir un objetivo en pasos, seleccionar herramientas, recuperar información, llamar a servicios externos y modificar sistemas. También puede repetir este proceso hasta considerar que el objetivo se ha completado.
Cada paso puede modificar el riesgo del siguiente. Una solicitud inocua para resumir comentarios de clientes se vuelve más delicada cuando el agente abre una base de datos de clientes. El riesgo cambia de nuevo si exporta registros, redacta mensajes o los envía sin revisión.
Esto crea una brecha entre la aprobación en la fase de diseño y el comportamiento en tiempo de ejecución. Un comité de gobernanza puede aprobar un agente para apoyar ventas, pero esa etiqueta dice poco sobre una consulta específica a una base de datos. Tampoco puede determinar si debe enviarse un correo concreto a las 2 de la madrugada desde una cuenta ejecutiva.
El marco de IA de NIST ofrece a las organizaciones una estructura amplia para gobernar, mapear, medir y gestionar los riesgos de IA. Esta estructura sigue siendo útil, pero los agentes obligan a los equipos a aplicar sus principios con una resolución mucho más fina.
Una clasificación de riesgo asociada a toda una aplicación no puede responder a todas las preguntas en tiempo de ejecución. El sistema debe saber quién solicitó la tarea, qué agente está actuando, a qué datos accedió y qué herramienta seleccionó. También debe saber si la acción solicitada excede la autoridad del usuario.
Ese es el significado práctico de la gobernanza en el punto de acción. Un control evalúa una acción intentada utilizando señales actuales de identidad, permisos, datos y entorno. Después permite, bloquea, limita o escala esa acción.
El control puede requerir aprobación humana antes de mover dinero. Puede ocultar campos sensibles antes de que la información llegue a un modelo. Puede impedir que un agente envíe correos a una dirección externa, incluso cuando ese mismo agente puede crear un borrador interno.
Estas decisiones deben tomarse durante la ejecución. Una revisión trimestral de políticas no puede interrumpir una llamada API peligrosa. Una auditoría realizada después de la implementación puede explicar un incidente, pero no puede evitar la acción original.
El cambio también modifica qué se considera evidencia. Las organizaciones necesitan más que un registro que demuestre que un agente fue aprobado. Necesitan registros que conecten la solicitud original con las decisiones del modelo, las llamadas a herramientas, los datos recuperados, las aprobaciones y el resultado final.
Esa cadena importa cuando un agente opera entre varios servicios. Un flujo de trabajo puede comenzar en una interfaz de chat, recuperar un contrato, actualizar un registro de cliente y crear una solicitud de pago. Cada transición genera otro punto donde la autoridad puede ampliarse o el contexto puede perderse.
La gobernanza en el punto de acción trata esas transiciones como límites de seguridad. El enfoque no supone que un agente aprobado siga siendo seguro durante todo un flujo de trabajo. Verifica si cada acción significativa continúa ajustándose al propósito original y a la autoridad delegada.
Por qué las políticas estáticas de IA pierden el control en tiempo de ejecución
Una política escrita describe un comportamiento aceptable, pero un flujo de trabajo autónomo necesita decisiones aplicables antes de cada paso relevante.
La gobernanza estática es más sólida cuando los sistemas se comportan de forma predecible. Los equipos pueden definir usos aprobados, prohibir entradas sensibles, probar un flujo fijo y formar a los empleados. Estas medidas se vuelven menos fiables cuando un agente elige su propia ruta entre herramientas conectadas.
Un agente puede comenzar con un objetivo permitido y aun así producir una acción inadmisible. Puede malinterpretar una instrucción, seguir contenido malicioso recuperado de un documento o combinar permisos que, por separado, parecen inocuos. La capacidad resultante puede superar lo que sugiere cualquier permiso individual.
La inyección de prompts ilustra este problema. Una instrucción hostil puede aparecer dentro de una página web, un correo electrónico, un documento o un ticket de soporte que el agente recupera. El contenido indica al agente que ignore su objetivo original, revele información o active otra herramienta.
Un filtro convencional puede inspeccionar el prompt inicial del usuario y no detectar nada peligroso. La instrucción dañina llega después, cuando el flujo de trabajo ya ha comenzado. Por tanto, la gobernanza debe acompañar al agente a medida que cambia su contexto.
La guía sobre agentes de OWASP describe riesgos relacionados con una autonomía excesiva, el mal uso de herramientas, la manipulación de memoria, fallos en cascada e interacciones comprometidas entre agentes. Son riesgos de ejecución, no solo resultados textuales indeseables.
La autonomía excesiva ocurre cuando un agente recibe más autoridad de la que requiere su tarea. Un asistente de programación puede necesitar leer calendarios y proponer horarios de reunión. Rara vez necesita acceso sin restricciones para eliminar eventos, invitar a participantes externos o leer todos los archivos adjuntos privados.
La distinción parece sencilla hasta que los flujos de trabajo se vuelven dinámicos. Un agente puede necesitar legítimamente acceso ampliado para una tarea, pero no para otra. Los permisos amplios y permanentes resuelven el problema operativo, pero crean una exposición de seguridad persistente.
Los controles en tiempo de ejecución ofrecen un enfoque diferente. El sistema puede emitir una autorización limitada y temporal tras evaluar la tarea y su contexto. Esa autorización puede caducar después de una acción o requerir aprobación cuando cambie el alcance solicitado.
El mismo principio se aplica a los datos. Un agente que prepara un resumen trimestral puede necesitar información agregada de ingresos, pero no el registro personal de cada cliente. Un control cerca de la fuente de datos puede limitar lo que recupera el agente antes de que el modelo siquiera lo vea.
Esto importa porque las salvaguardas a nivel de modelo son solo una capa. Se puede indicar a un modelo que no revele información sensible, pero las instrucciones pueden entrar en conflicto o fallar. La minimización de datos y la autorización de herramientas reducen las consecuencias cuando el comportamiento del modelo deja de ser fiable.
El enfoque en tiempo de ejecución también separa el razonamiento de bajo riesgo de la ejecución de alto riesgo. Un agente puede analizar opciones, redactar una recomendación y simular una acción sin recibir permiso para realizarla. La autoridad llega solo cuando el flujo de trabajo alcanza un límite controlado.
La aprobación humana sigue siendo importante, pero no puede convertirse en una respuesta universal. Exigir aprobación para cada llamada a una herramienta elimina gran parte de la eficiencia que prometen los agentes. También puede provocar fatiga de aprobación, en la que las personas aceptan solicitudes sin revisar su contexto.
Una buena gobernanza reserva la intervención para umbrales significativos. La lectura de una página pública de producto puede continuar automáticamente. Exportar registros de clientes, cambiar código de producción o enviar fondos debería activar comprobaciones más estrictas.
El límite exacto depende de la organización y de la tarea. Sin embargo, el mecanismo se mantiene: evaluar la acción, su objetivo, su iniciador y su impacto potencial. Después, aplicar la autoridad más limitada que permita continuar el trabajo legítimo.
El perfil de IA generativa de NIST enfatiza la gestión de riesgos a lo largo del ciclo de vida de la IA. Los sistemas agénticos extienden ese ciclo de vida a una cadena de decisiones que pueden generar efectos inmediatos.
Por tanto, la gobernanza se parece menos a publicar un reglamento y más a operar un sistema de autorización. Las políticas siguen definiendo lo que debe suceder. Los controles en tiempo de ejecución traducen esas políticas en decisiones técnicas que ocurren antes de que las consecuencias se hagan reales.
La identidad se convierte en el plano de control de los agentes de IA
Un agente necesita una identidad diferenciada y rastreable porque las credenciales prestadas de los empleados borran la responsabilidad y debilitan todos los controles posteriores.
Muchos de los primeros agentes operan mediante la cuenta existente de un usuario humano. El agente hereda una sesión, un token de API o una credencial de servicio. Ese diseño facilita los prototipos, pero genera ambigüedad durante las investigaciones y las revisiones de acceso.
Un registro del sistema puede mostrar que un empleado descargó un archivo. Puede no revelar si la persona hizo clic en la descarga, si un agente aprobado lo recuperó o si un flujo de trabajo comprometido actuó mediante su cuenta. Al registro de autorización le falta el actor real.
Una identidad independiente para el agente resuelve parte de este problema. Permite a los administradores asignar permisos al agente, supervisar su comportamiento y revocar su acceso sin deshabilitar al patrocinador humano. También permite que las políticas distingan entre acciones humanas y acciones de máquinas.
La identidad debe seguir vinculada a una persona responsable o a un proceso empresarial. De lo contrario, las organizaciones crean una población creciente de cuentas de máquina sin un propietario claro. Los agentes inactivos pueden entonces conservar acceso mucho después de que termine su proyecto original.
Microsoft ha presentado los controles de Agent ID como una capa de identidad para descubrir, gobernar y proteger agentes. Esta dirección refleja una conclusión más amplia del sector: los agentes necesitan una gestión de ciclo de vida comparable a la de otras identidades no humanas.
El descubrimiento es lo primero porque los equipos de seguridad no pueden gobernar agentes que no pueden ver. Las unidades de negocio pueden crear agentes dentro de plataformas de software, sistemas de bajo código, marcos de desarrollo y servicios en la nube. Cada vía puede generar otra identidad, token o integración.
El registro debe recoger el propietario del agente, su propósito, entorno, herramientas aprobadas y acceso previsto a datos. También debe indicar si el agente puede actuar automáticamente o requiere confirmación. Estos atributos proporcionan a los sistemas en tiempo de ejecución una base para la autorización.
La autenticación responde si quien llama es el agente registrado. La autorización responde si ese agente puede realizar esta acción en estas condiciones. La gobernanza falla cuando los equipos resuelven la primera cuestión, pero conceden acceso amplio y persistente para la segunda.
El contexto hace que la autorización sea más precisa. Una política puede examinar al usuario solicitante, el estado del dispositivo, la clasificación de los datos, el destino, el valor de la transacción y el comportamiento reciente del agente. Después, puede imponer distintos controles sin redefinir todo el agente.
Un asistente puede leer las notas de reuniones de un empleado durante el trabajo habitual. La misma solicitud debería recibir un escrutinio más riguroso cuando se dirige a archivos restringidos de otro departamento. Una descarga masiva repentina debería tratarse de forma distinta a la recuperación de un solo documento.
La memoria añade otro problema de identidad. Los agentes pueden almacenar el historial de tareas, preferencias, datos recuperados y decisiones intermedias. Esa memoria puede persistir después de que termine la sesión original del usuario, al tiempo que influye en acciones futuras para otra solicitud.
Los equipos deben saber qué identidad es responsable de la memoria y quién puede modificarla. También necesitan procedencia, es decir, un registro de dónde procede la información almacenada y cómo ha cambiado. Sin procedencia, una memoria envenenada puede redirigir silenciosamente flujos de trabajo posteriores.
Los sistemas de conocimiento pueden facilitar una recuperación más segura cuando preservan los límites de las fuentes y los controles de acceso. Una base de conocimientos de ingeniería resulta más útil cuando un agente recibe únicamente los documentos a los que puede acceder su solicitante actual.
Los flujos de trabajo multiagente hacen que la identidad sea aún más importante. Un agente puede delegar la investigación en otro y luego pedir a un tercero que actualice un sistema. El servicio receptor debe saber si la autoridad delegada sigue siendo válida a lo largo de esa cadena.
La delegación no debería crear nuevos privilegios por accidente. Si el primer agente no puede aprobar un pago, un agente delegado no debería obtener esa capacidad. Cada transferencia debe preservar los límites, el propósito y la fecha de expiración originales.
Este requisito se parece a ideas consolidadas en seguridad de identidades, pero los agentes aportan una velocidad y una escala inusuales. Una persona puede realizar varias acciones sensibles durante una sesión. Un agente automatizado puede iniciar muchas acciones en varios sistemas antes de que un revisor lo advierta.
Por tanto, el plano de control debe combinar la identidad con límites de tasa, supervisión del comportamiento y políticas de transacciones. La identidad indica a la organización quién actuó. La gobernanza en tiempo de ejecución determina si se debe permitir que ese actor continúe.
El control en el punto de acción crea sus propias compensaciones
La aplicación de controles en tiempo de ejecución reduce la autoridad sin supervisión, pero también introduce latencia, complejidad de políticas, riesgo de integración y nuevos puntos de control que los atacantes pueden atacar.
La versión más sólida del argumento de gobernanza puede sonar engañosamente completa. Asignar una identidad a cada agente, evaluar cada acción, registrar cada decisión y exigir aprobación para operaciones peligrosas. En la práctica, cada componente puede fallar.
La calidad de las políticas es la primera limitación. Un motor de ejecución en tiempo real no puede aplicar intenciones que los equipos no han traducido en reglas precisas. Términos como sensible, apropiado, material o fiable suelen requerir un juicio empresarial que varía entre departamentos.
Las reglas demasiado amplias dejan disponibles acciones peligrosas. Las reglas demasiado estrictas interrumpen el trabajo legítimo y animan a los empleados a sortear el sistema. La organización debe ajustar las políticas basándose en flujos de trabajo reales, no solo en categorías abstractas de riesgo.
El contexto también puede ser incompleto. Un servicio de seguridad puede ver una solicitud de API sin comprender la conversación que la produjo. Una pasarela de modelos puede entender el prompt, pero carecer de información sobre la clasificación de datos del sistema de destino.
Los atacantes pueden explotar esas brechas. Pueden dividir un objetivo prohibido en varias acciones permitidas. Cada paso parece inofensivo cuando se inspecciona por separado, mientras que la secuencia completa produce un resultado no autorizado.
Los controles conscientes de la secuencia pueden detectar algunos patrones, pero requieren un estado más rico y una retención más prolongada. Eso genera preocupaciones de privacidad y operativas. Las trazas detalladas pueden contener solicitudes de empleados, datos de clientes, resultados de modelos y decisiones empresariales confidenciales.
Las organizaciones deben proteger la telemetría de gobernanza con tanto cuidado como los sistemas que supervisa. Un registro comprometido puede ocultar un ataque o implicar falsamente a un usuario. Una traza expuesta puede revelar la misma información que los controles estaban diseñados para proteger.
El rendimiento presenta otra compensación. Un agente puede realizar muchas llamadas pequeñas a herramientas mientras completa una tarea. Enviar cada llamada a través de varios motores de políticas puede añadir retraso, coste y puntos de fallo adicionales.
La aplicación de controles basada en riesgos puede reducir esa carga. Las acciones reversibles y de bajo impacto reciben verificaciones ligeras. Las acciones de alto impacto o irreversibles reciben una autorización más sólida, un registro más completo o revisión humana.
Esa distinción requiere una clasificación cuidadosa. Enviar un borrador a una cola interna de revisión es reversible. Publicar el mismo texto para los clientes no lo es. Leer un registro de cliente difiere de exportar una base de datos completa.
Los agentes también pueden comportarse de forma distinta después de actualizaciones del modelo. Un modelo nuevo puede seleccionar herramientas en otro orden, generar argumentos diferentes o intentar más pasos. Las políticas existentes podrían bloquear el nuevo comportamiento o pasar por alto una vía recién introducida.
Esto convierte las pruebas continuas en parte de la gobernanza. Los equipos deberían reproducir flujos de trabajo representativos con modelos, herramientas y políticas actualizados. Las pruebas deberían incluir documentos adversariales, instrucciones ambiguas, permisos revocados y servicios no disponibles.
La interoperabilidad añade otra incertidumbre. La industria está desarrollando protocolos que ayudan a los agentes a descubrir capacidades y comunicarse entre sistemas. Google presentó su protocolo Agent2Agent para respaldar la colaboración entre agentes creados con distintos marcos.
La interoperabilidad puede reducir el trabajo de integración, pero también amplía las relaciones de confianza. Un agente local puede confiar en la descripción de un agente remoto sobre sus capacidades, identidad o trabajo completado. Esa afirmación necesita verificación técnica.
Un protocolo compartido no crea automáticamente una gobernanza compartida. Las organizaciones aún necesitan reglas para aceptar tareas delegadas, transmitir contexto sensible y validar los resultados devueltos. Deben decidir qué agentes remotos pertenecen a cada límite de confianza.
La concentración de proveedores presenta un riesgo relacionado. Si una plataforma de identidad o políticas media cada acción de un agente, una interrupción puede detener flujos de trabajo críticos. Un error de configuración puede bloquear a toda una organización u otorgar acceso excesivo a gran escala.
Los equipos necesitan un comportamiento de respaldo antes de la implementación. Algunas acciones deberían fallar de forma cerrada, lo que significa que el sistema las bloquea cuando un control no está disponible. Otras operaciones de bajo riesgo pueden continuar con límites más estrictos y un registro reforzado.
Por tanto, la gobernanza en el punto de acción debe tratarse como una defensa por capas, no como una garantía. Funciona mejor con herramientas restringidas, acceso mínimo a datos, ejecución aislada, validación de resultados, supervisión y respuesta a incidentes.
La conclusión escéptica es directa. Acercar los controles a la ejecución mejora la capacidad de la organización para prevenir daños. No hace que el comportamiento autónomo sea predecible ni elimina la necesidad de revisión en la fase de diseño.
La presión se extiende más allá de los equipos de seguridad
La gobernanza de agentes de IA obliga a los proveedores de aplicaciones y a los responsables de negocio a exponer controles que los equipos de seguridad no pueden añadir desde fuera del flujo de trabajo.
Un equipo de seguridad puede gestionar identidades y acceso a la red, pero no siempre puede comprender el significado empresarial de una aplicación. Una llamada de API que modifica un campo puede aprobar un reembolso, publicar un documento o cerrar una cuenta de cliente.
Los proveedores de aplicaciones deben etiquetar las acciones relevantes y exponer puntos de autorización a su alrededor. También deben devolver suficiente contexto para que los sistemas de políticas distingan una vista previa de un compromiso. Sin ese detalle, la aplicación de controles sigue siendo imprecisa.
Los proveedores de plataformas de agentes afrontan una obligación similar. Necesitan registros duraderos de los pasos de planificación, las selecciones de herramientas, los argumentos, las respuestas y las aprobaciones. Los equipos de seguridad deben poder buscar en esos registros sin exponer datos de cadena de pensamiento sin restricciones.
Los proveedores de modelos siguen siendo responsables de las salvaguardas, las evaluaciones y un comportamiento predecible en el uso de herramientas. Sin embargo, no pueden decidir la política de autorización de cada cliente. La misma acción de un modelo puede ser inocua en un entorno y estar prohibida en otro.
Los responsables de negocio deben definir esas distinciones. Los líderes financieros saben qué transacciones requieren separación de funciones. Los equipos de recursos humanos saben qué registros de empleados requieren un acceso más estricto. Los equipos jurídicos saben cuándo un borrador generado se convierte en una comunicación oficial.
Luego, los desarrolladores traducen esos requisitos en límites técnicos. Deciden qué herramientas puede llamar el agente, qué parámetros puede proporcionar y qué respuestas puede recibir. También determinan qué ocurre cuando un control rechaza un paso.
Esta división de responsabilidades genera presión porque ningún participante puede resolver el problema por sí solo. Las plataformas de identidad carecen de un significado completo de las tareas. Los proveedores de aplicaciones carecen de un contexto organizativo completo. Los proveedores de modelos carecen de autoridad sobre la política del cliente.
La integración más débil puede socavar toda la cadena. Un agente puede tener una identidad sólida, pero llamar a una herramienta a través de una cuenta de servicio compartida. Una herramienta puede aplicar permisos, pero aceptar instrucciones no validadas de un documento externo.
Los equipos de compras deberían esperar respuestas más concretas de los proveedores de agentes. Una declaración general sobre IA responsable no es suficiente. Los compradores necesitan saber cómo gestiona el producto las identidades, la delegación, las aprobaciones, los registros, la memoria y la revocación.
También deberían preguntar si los controles siguen siendo eficaces entre conectores. Un agente puede respetar restricciones dentro de su plataforma principal, pero perderlas cuando llama a un servicio de terceros. La herencia de permisos debe sobrevivir a esa transición.
La propiedad operativa importa después de la compra. Alguien debe revisar los accesos, investigar anomalías, eliminar agentes sin uso y actualizar las políticas cuando cambian los flujos de trabajo. Un inventario de agentes sin un proceso operativo se convierte en otra lista de activos obsoleta.
Los desarrolladores y trabajadores del conocimiento deberían preocuparse porque una gobernanza más estricta dará forma a la experiencia del producto. Algunos agentes se detendrán antes de acciones sensibles. Otros ofrecerán vistas previas, modos restringidos o solicitudes explícitas de permiso.
Esas interrupciones no siempre son defectos. Un paso de aprobación visible puede aclarar qué pretende hacer un agente y qué datos utilizará. Da al usuario la oportunidad de detectar un objetivo malinterpretado antes de la ejecución.
Los controles mal diseñados producirán el resultado contrario. Los avisos vagos y repetidos entrenarán a los usuarios para aprobar solicitudes automáticamente. La interfaz debe explicar la acción específica, el objetivo, el alcance y la consecuencia en lenguaje sencillo.
Por tanto, la presión del mercado favorece productos que combinan una autonomía útil con límites comprensibles. La finalización de tareas en bruto seguirá siendo importante. La delegación fiable será igual de importante a medida que los agentes obtengan acceso a sistemas valiosos.
Tres señales mostrarán si la gobernanza en tiempo de ejecución funciona
La próxima prueba no es otro anuncio de políticas. Es si la identidad, la autorización y la evidencia permanecen intactas en flujos de trabajo reales de varios pasos.
La primera señal es la adopción de identidades de agente independientes en las principales plataformas empresariales. La evidencia importante incluirá controles de ciclo de vida, propietarios identificados, permisos limitados, expiración y revocación.
Una etiqueta de producto por sí sola no será suficiente. Los equipos de seguridad necesitan distinguir a un agente de su empleado patrocinador y de las cuentas de servicio detrás de sus herramientas. Un respaldo más amplio reforzaría la tesis de la gobernanza en tiempo de ejecución.
La segunda señal es la aplicación de controles en los límites de las aplicaciones. Los proveedores de software empresarial deberían exponer políticas para acciones relevantes, incluidos los mensajes externos, cambios en registros, despliegue de código y operaciones financieras.
Observe si estos controles entienden el contexto empresarial o si simplemente filtran texto. Una autorización consciente del contexto demostraría que la gobernanza ha llegado a la ejecución. Las advertencias genéricas y los registros opcionales indicarían que la transición sigue incompleta.
La tercera señal es la evidencia procedente de fallos y pruebas independientes. Los investigadores deberían evaluar la inyección de prompts, la autoridad delegada, la memoria contaminada, los permisos excesivos y las interacciones entre agentes remotos.
Los informes transparentes de incidentes serán tan importantes como las demostraciones exitosas. Pueden revelar si los controles bloquearon acciones perjudiciales, limitaron su alcance o solo documentaron los daños después. Las evasiones repetidas debilitarían las afirmaciones de que la aplicación de políticas en el punto de acción está madura.
Durante los próximos meses, los compradores deberían pedir a los proveedores que demuestren una cadena completa. Comience con un usuario identificado, delegue una tarea acotada, recupere datos protegidos, llame a una herramienta, exija aprobación y revoque el acceso.
Luego examine la evidencia. ¿Puede el proveedor mostrar quién inició la tarea, qué agente actuó, a qué accedió, qué política se aplicó y si la delegación modificó la autoridad?
La gobernanza de los agentes de IA empresariales solo tendrá éxito cuando esas respuestas resistan implementaciones reales. Si su organización está realizando pilotos con agentes, identifique la primera acción irreversible de cada flujo de trabajo. Coloque allí el control más sólido, pruebe la vía de rechazo y confirme que cada decisión siga siendo atribuible.
