Un agente de IA puede recuperar información, razonar sobre contexto, invocar herramientas, iniciar workflows y, en algunos casos, ejecutar acciones sin que una persona realice manualmente cada paso. Por eso, la gobernanza de agentes es distinta de la gobernanza tradicional de software y de la de un asistente generativo aislado.
La cuestión práctica no es solo si una organización permite la IA. Es si cada agente tiene un propósito conocido, un propietario, límites de autoridad y datos, una vía de escalado, evidencias de prueba y un estado operativo definido.
Un marco útil gobierna todo el ciclo de vida: idea, diseño, desarrollo, pruebas, aprobación, despliegue, monitorización, cambios y retirada.
1. Empezar por principios de gobernanza
Un modelo de gobernanza debe comenzar con un conjunto reducido de principios consistentes aplicables a todo el parque de agentes. Deben ser comprensibles para product owners, desarrolladores, riesgos, compliance y negocio.
Los principios clave son propiedad trazable, mínimo privilegio, controles proporcionales, responsabilidad humana, evidencias desde el diseño y cambios controlados.
- Cada agente tiene un propietario de negocio y un propietario técnico identificados.
- Cada agente opera dentro de un propósito y límite de autoridad explícitos.
- El acceso a sistemas, datos y acciones sigue el principio de mínimo privilegio.
- La supervisión humana se diseña según las consecuencias potenciales de un error.
- Las evidencias de prueba y aprobación se conservan y pueden reproducirse.
- Los cambios materiales desencadenan una nueva evaluación.
2. Mantener un inventario autoritativo de agentes
Una organización no puede gobernar agentes que no puede identificar. Por ello, el inventario empresarial es un control fundamental.
El inventario debe ir más allá de una lista de nombres y permitir entender qué hace el agente, dónde opera, a qué sistemas accede y quién responde por él.
- Nombre, versión y estado del ciclo de vida.
- Propósito de negocio y usuarios previstos.
- Propietario de negocio, propietario técnico y responsable de soporte.
- Entorno Microsoft, solución y ubicación de despliegue.
- Sistemas conectados, conectores, herramientas y categorías de datos.
- Permisos de acción y autoridad transaccional.
- Clasificación de riesgo y nivel de aprobación requerido.
- Modelo de supervisión humana.
- Evidencias de prueba, estado de certificación y fecha de última revisión.
3. Clasificar el riesgo antes del despliegue
La clasificación de riesgo determina cuánta gobernanza necesita un agente. No importa solo el modelo utilizado, sino lo que el agente completo puede ver, decidir y hacer.
Un agente de consulta en modo lectura es muy distinto de uno capaz de aprobar transacciones, comunicarse externamente, modificar registros o activar procesos.
CAI Score es el enfoque estructurado de ColleagueAI para clasificar el riesgo de agentes empresariales. Considera autonomía, impacto, sensibilidad de datos, acceso a herramientas, reversibilidad, supervisión y requisitos de gobernanza.
4. Separar responsabilidad de negocio y propiedad técnica
Los equipos técnicos pueden construir y mantener un agente, pero no deben ser los únicos responsables del resultado de negocio. La función que utiliza el agente debe seguir siendo responsable del proceso y sus consecuencias.
Un modelo maduro distingue entre propiedad de negocio, propiedad técnica y garantía de gobernanza.
El modelo de responsabilidad también debe definir claramente los derechos de decisión. El responsable de negocio aprueba el propósito previsto, los resultados aceptables y los cambios materiales del proceso, mientras que el responsable técnico mantiene la responsabilidad sobre la integridad de los componentes de la solución, la configuración y los controles técnicos. Las funciones de gobernanza, riesgo, seguridad o cumplimiento pueden aportar revisión independiente sin sustituir la responsabilidad del negocio.
5. Gobernar identidad, accesos y permisos de herramientas
La capacidad de un agente depende en gran medida de los sistemas y acciones a los que puede acceder. Los conectores, credenciales, identidades de servicio y permisos deben tratarse como controles de primer nivel.
Los permisos deben limitarse al mínimo necesario para el caso de uso aprobado.
- Usar identidades dedicadas cuando la arquitectura lo permita.
- Restringir conectores y acciones a casos de uso aprobados.
- Evitar permisos amplios concedidos solo por comodidad de desarrollo.
- Registrar acciones privilegiadas en logs auditables.
- Utilizar gates de aprobación para acciones irreversibles o de alto impacto.
- Revalidar permisos cuando cambien workflows o integraciones.
6. Diseñar la supervisión humana dentro del workflow
La supervisión humana no debe ser una declaración genérica de que una persona sigue siendo responsable. Debe indicar exactamente dónde las personas revisan, aprueban, intervienen o detienen al agente.
El modelo adecuado depende del riesgo. Algunos agentes pueden operar de forma autónoma en tareas acotadas y de bajo riesgo; otros necesitan aprobación humana antes de una acción relevante.
El control debe especificar el punto de intervención, la persona que realiza la revisión, la información disponible para ella y las acciones que está autorizada a realizar. Una aprobación meramente formal no es suficiente si la persona no puede comprender o detener el resultado propuesto. Por ello, la supervisión humana debe probarse como un control operativo real y no limitarse a una declaración de política.
7. Probar el agente como un sistema completo
El assurance del agente requiere probar el workflow completo. Importan el prompt, los permisos, llamadas a herramientas, comportamiento ante fallos, tratamiento de datos, escalado, calidad del output y recuperación ante entradas inesperadas.
Un paquete de producción debe conservar evidencia de qué se probó, qué comportamiento se esperaba, qué limitaciones existen y qué versión superó las pruebas.
- Pruebas funcionales y por escenarios.
- Pruebas de permisos y conectores.
- Rutas de fallo y excepción.
- Rutas de aprobación y escalado.
- Tratamiento de datos sensibles.
- Criterios de calidad de salida.
- Logging y generación de evidencias.
- Pruebas de regresión tras cambios materiales.
8. Convertir el despliegue en una transferencia controlada
Un agente empaquetado debe tener una frontera de despliegue clara. El proveedor puede aportar una solución probada, documentación, guías de configuración, evidencias de gobernanza e instrucciones de despliegue, pero el cliente controla su propio tenant y entorno operativo.
En los productos ColleagueAI, el despliegue y el runtime permanecen en el entorno Microsoft del cliente. La configuración específica del tenant, las integraciones, el despliegue y la operación los realiza el cliente o su partner de implementación aprobado.
Una transferencia controlada también debe documentar los requisitos previos, variables de entorno, referencias de conexión, roles necesarios, limitaciones conocidas y pasos de validación posteriores a la importación. Esto permite al cliente o a su socio de implementación reproducir la configuración probada sin depender de conocimientos no documentados del desarrollador original. La versión desplegada debe seguir siendo trazable hasta el paquete y las evidencias aprobadas.
9. Monitorizar el riesgo operativo y los cambios materiales
La aprobación inicial no pone fin a la gobernanza. El comportamiento del agente puede cambiar cuando se modifican prompts, modelos, herramientas, permisos, fuentes de conocimiento o sistemas conectados.
La gobernanza continua debe centrarse en cambios materiales, excepciones, incidentes, patrones de uso y evidencias de que la configuración desplegada sigue correspondiendo al diseño aprobado.
La monitorización debe vincularse a desencadenantes explícitos de revisión. Entre ellos pueden estar un nuevo conector, permisos más amplios, un modelo diferente, una nueva fuente de conocimiento, un aumento de anulaciones, excepciones repetidas o cambios en el proceso empresarial. Estas señales deben determinar cuándo el agente necesita investigación, corrección, recertificación o una nueva decisión de gobernanza.
10. Gobernar la retirada con el mismo rigor que el lanzamiento
Los agentes sin uso o sustituidos no deben conservar accesos inactivos indefinidamente. La retirada debe eliminar permisos, desactivar integraciones, archivar evidencias y actualizar el inventario.
Un proceso de retirada limpio reduce la superficie de ataque y evita acumular capacidades de IA sin propietario.
La retirada del agente también debe cerrar sus dependencias operativas y de gobernanza. Los responsables deben confirmar que los flujos programados están desactivados, las credenciales de servicio se han revocado cuando corresponda, las integraciones dependientes ya no esperan al agente y las evidencias se conservan según la política aplicable. El inventario debe registrar la fecha de retirada y la disposición final del agente.
Un ciclo práctico de gobernanza
- Identificar y registrar el caso de uso.
- Asignar propietarios responsables.
- Clasificar el riesgo del agente.
- Definir límites de datos, herramientas y autoridad.
- Diseñar la supervisión humana.
- Construir y probar el workflow completo.
- Revisar evidencias y aprobar el despliegue.
- Desplegar en el entorno controlado del cliente.
- Monitorizar operación y cambios relevantes.
- Reevaluar, recertificar o retirar.
Límite de producto y despliegue
ColleagueAI diseña, prueba, certifica, empaqueta y vende productos de agentes de IA empresariales. Los clientes o partners de implementación aprobados importan, configuran, integran, despliegan y operan estos productos dentro del entorno Microsoft del cliente. Las licencias Microsoft, el runtime de Copilot Studio, Power Platform, Azure, Dataverse, los conectores y otros servicios de ejecución siguen siendo responsabilidad del cliente.
Preguntas frecuentes
¿Qué es la gobernanza de agentes de IA?
Es el conjunto de controles de propiedad, riesgo, acceso, supervisión humana, pruebas, evidencias, despliegue y ciclo de vida que mantiene a los agentes dentro de los límites aprobados de la organización.
¿Es lo mismo que la gobernanza de modelos?
No. La gobernanza de agentes también debe cubrir herramientas, permisos, fuentes de datos, acciones, lógica de workflow, supervisión humana y configuración operativa.
¿Quién debe ser responsable de un agente empresarial?
El proceso debe tener un propietario de negocio responsable y la solución un propietario técnico. Riesgos o gobernanza pueden aportar assurance independiente.
¿Todos los agentes necesitan los mismos controles?
No. Los controles deben ser proporcionales al riesgo.
¿Dónde se ejecutan los agentes ColleagueAI?
Los productos ColleagueAI están diseñados para ser importados, configurados, desplegados y operados en el entorno Microsoft del cliente. ColleagueAI no opera el runtime del cliente.