Riesgo de los agentes de IA: por qué los agentes necesitan un nuevo modelo de gobernanza
12 de abril de 2026 · 8 min de lectura
Los agentes de IA se están convirtiendo rápidamente en la nueva narrativa por defecto de la IA empresarial. Los proveedores están añadiendo agentes a suites de productividad, plataformas de atención al cliente, herramientas para desarrolladores, sistemas de workflow y entornos low-code. Microsoft Copilot Studio, por ejemplo, se presenta ahora como una plataforma para crear, personalizar, desplegar y gestionar agentes de IA que pueden conectarse a datos de negocio, usar herramientas y publicarse en canales como Microsoft 365 Copilot, Teams, SharePoint y sitios web.
Ese cambio importa. Pero también crea un problema de lenguaje.
No todos los productos llamados "agentes" implican el mismo nivel de riesgo.
Un simple asistente de prompt y respuesta apoyado en unos pocos documentos no es lo mismo que un agente de workflow autónomo que monitoriza eventos, decide qué hacer, llama herramientas, actualiza registros, envía mensajes, escala casos o activa procesos de negocio en segundo plano. Ambos pueden venderse como agentes. Pero no necesitan el mismo modelo de gobernanza.
Idea clave: un agente es una categoría de producto, pero el comportamiento agéntico es una propiedad de riesgo.
De la IA que responde a la IA que actúa
La gobernanza tradicional de IA suele empezar con preguntas como:
- ¿El modelo es preciso?
- ¿La salida está sesgada?
- ¿El sistema explica su resultado?
- ¿Los datos personales se procesan legalmente?
- ¿Los usuarios pueden confiar en la respuesta?
Estas preguntas siguen siendo importantes. Pero los sistemas agénticos añaden una nueva capa: la acción.
Con agentes, la pregunta de gobernanza cambia de:
¿Qué dijo el modelo?
A:
¿Qué estaba autorizado a hacer el agente, qué hizo realmente, por qué lo hizo, quién lo aprobó y podemos demostrarlo?
Ese es un problema de control muy distinto.
Un chatbot puede dar una respuesta equivocada. Un agente puede dar una respuesta equivocada y luego actuar sobre ella. Puede llamar a una API, actualizar un ticket, enviar un correo a un cliente, cambiar un registro, recuperar datos sensibles, iniciar un reembolso, crear una tarea o pasar el trabajo a otro agente.
En el momento en que un sistema de IA puede afectar a otro sistema, la gobernanza de IA se convierte en gobernanza operativa.
La etiqueta “agente” es demasiado amplia
La propia documentación de Microsoft hace visible el espectro. Microsoft 365 Copilot describe agentes que van desde simples agentes de prompt y respuesta hasta agentes plenamente autónomos. Copilot Studio amplía esto con capacidades autónomas donde los agentes pueden actuar a partir de disparadores, instrucciones y guardrails, operando en segundo plano en lugar de responder solo dentro de una conversación.
Ese espectro es útil. Pero también genera confusión.
Muchas organizaciones oyen la palabra “agente” y asumen que están tratando con una sola categoría. En la práctica, hay varios niveles de comportamiento agéntico.
Nivel 1: asistente de conocimiento
Se trata de una herramienta poco agéntica. Responde preguntas usando instrucciones y fuentes de conocimiento seleccionadas.
Ejemplo:
- Un asistente interno de RR. HH. que responde preguntas de políticas a partir de documentos aprobados.
- Un agente de Copilot Studio que responde en un chat de Teams usando temas y conocimiento configurados.
Riesgos principales:
- Respuestas incorrectas
- Conocimiento desactualizado
- Divulgación inapropiada
- Exceso de confianza del usuario
Enfoque de gobernanza:
- Calidad del contenido
- Acceso a las fuentes de conocimiento
- Descargos y escalado
- Logging básico
Nivel 2: asistente de workflow guiado
Esta herramienta ayuda a un usuario a completar una tarea, pero la persona sigue llevando el control.
Ejemplo:
- Un asistente de soporte que redacta una respuesta y sugiere el siguiente paso.
- Un asistente comercial que resume la información de una cuenta y propone un correo de seguimiento.
Riesgos principales:
- Recomendaciones deficientes
- Contexto incompleto
- Resúmenes engañosos
- Aprobación automática sin revisión real
Enfoque de gobernanza:
- Revisión humana
- Transparencia de fuentes
- Límites del workflow
- Formación del usuario
Nivel 3: agente que usa herramientas
Aquí es donde el riesgo empieza a cambiar materialmente. El agente puede llamar herramientas, APIs, flows o conectores.
Ejemplo:
- Un agente de soporte IT que crea tickets y revisa el estado de un dispositivo.
- Un agente de atención al cliente que consulta pedidos e inicia acciones aprobadas.
- Un agente de Copilot Studio conectado a flows de Power Automate o a APIs de sistemas de negocio.
Riesgos principales:
- Uso no autorizado de herramientas
- Permisos excesivos
- Prompt injection que conduce a un mal uso de herramientas
- Fuga de datos a través de entradas o salidas de herramientas
- Auditabilidad incompleta
Enfoque de gobernanza:
- Matriz de permisos de herramientas
- Acceso de mínimo privilegio
- Reglas de aprobación
- Audit logs
- Aplicación de políticas en runtime
Nivel 4: agente de workflow autónomo
El agente puede monitorizar eventos, tomar decisiones y ejecutar tareas sin esperar a un prompt del usuario.
Ejemplo:
- Un agente que vigila correos de proveedores, extrae cambios contractuales, clasifica el riesgo y enruta aprobaciones.
- Un agente financiero que monitoriza excepciones de conciliación e inicia workflows de corrección.
- Un agente de seguridad que observa alertas, enriquece casos y toma medidas de contención.
Riesgos principales:
- Acción no aprobada
- Decisión errónea a escala
- Fallo silencioso
- Fallo en el escalado
- Disrupción del proceso de negocio
- Brechas en la evidencia de compliance
Enfoque de gobernanza:
- Validación de disparadores
- Límites de decisión
- Aprobación humana para acciones críticas
- Monitoring y alerting
- Respuesta a incidentes
- Kill switches
Nivel 5: orquestación multiagente
Varios agentes se coordinan, delegan o se pasan trabajo.
Ejemplo:
- Un proceso de onboarding de clientes donde un agente recopila documentos, otro comprueba compliance, otro actualiza sistemas y otro comunica con el cliente.
Riesgos principales:
- Vacíos de accountability
- Instrucciones en conflicto
- Propagación de errores
- Delegación oculta
- Dificultad para encontrar la causa raíz
Enfoque de gobernanza:
- Identidad del agente
- Reglas de delegación
- Trazabilidad end-to-end
- Pruebas a nivel de sistema
- Modelo de ownership
Regla práctica: no gobiernes la etiqueta, gobierna el comportamiento.
Ejemplos de casos de uso por nivel de agente
Los niveles no pretenden ser cajas perfectas. Son una forma práctica de preguntar: ¿cuánta agency tiene realmente este sistema?
| Nivel de agente | Casos de uso típicos | Qué lo hace agéntico | Enfoque de gobernanza |
|---|---|---|---|
| Nivel 1: asistente de conocimiento | Q&A sobre políticas de RR. HH., búsqueda de conocimiento para helpdesk IT, FAQ de compliance interna, asistente de documentación de producto, asistente de onboarding | Responde desde fuentes aprobadas pero no realiza acciones | Calidad del conocimiento, control de acceso, actualización de fuentes, disclaimers, rutas de escalado |
| Nivel 2: asistente de workflow guiado | Borradores de respuestas a clientes, resúmenes de cuentas comerciales, preparación de briefs para reuniones, sugerencias de next best actions, primeras notas de riesgo | Guía a un humano en una tarea mientras la decisión sigue siendo humana | Revisión humana, transparencia de fuentes, límites del workflow, formación, aprobación del resultado final |
| Nivel 3: agente que usa herramientas | Creación de tickets de soporte, verificación de estado de pedidos, consulta de registros CRM, apertura de solicitudes de servicio IT, invocación de flows de Power Automate | Llama herramientas o conectores, normalmente dentro de una sesión iniciada por el usuario | Matriz de permisos, mínimo privilegio, audit logging, reglas de aprobación, pruebas de prompt injection |
| Nivel 4: agente de workflow autónomo | Monitorización de correos de proveedores, enrutado de excepciones contractuales, triaje de alertas de seguridad, conciliación de excepciones financieras, escalado de casos de clientes | Actúa a partir de disparadores y ejecuta partes de un proceso sin esperar un prompt explícito en cada paso | Validación de disparadores, límites de acción, monitoring, kill switches, aprobación humana para acciones de alto impacto |
| Nivel 5: orquestación multiagente | Onboarding de clientes entre KYC, legal, CRM y soporte; incident response con agentes de investigación y remediación; workflows corporativos de procurement | Varios agentes se coordinan, delegan o se pasan trabajo entre sistemas y equipos | Identidad de agentes, reglas de delegación, trazabilidad end-to-end, pruebas de sistema, ownership y accountability |
Las herramientas poco agénticas también necesitan gobernanza
Sería un error considerar las plataformas poco agénticas como inofensivas. Un simple agente de Copilot Studio todavía puede exponer información sensible, dar respuestas engañosas, apoyarse en conocimiento desactualizado o crear una falsa sensación de autoridad.
Pero las herramientas poco agénticas suelen encajar en un modelo de gobernanza más ligero, porque el sistema principalmente responde y no actúa de forma independiente.
Para las herramientas poco agénticas, las preguntas más importantes son:
- ¿A qué fuentes de conocimiento puede acceder el agente?
- ¿Se heredan correctamente los permisos de Microsoft 365, SharePoint u otros sistemas?
- ¿Las respuestas están ancladas en contenido aprobado?
- ¿El usuario sabe cuándo verificar o escalar?
- ¿Se registran adecuadamente las conversaciones?
- ¿Quién es el owner del agente después del lanzamiento?
Esto es gobernanza, pero sobre todo es gobernanza de contenido, acceso, calidad y ownership.
El riesgo más serio empieza cuando el agente gana herramientas, autonomía, memoria, disparadores o la capacidad de afectar a sistemas de negocio.
En ese punto, el modelo de gobernanza debe incluir diseño de controles, no solo revisión de contenido.
Por qué la gobernanza de IA existente no es suficiente
Muchos programas de gobernanza de IA se diseñaron alrededor de modelos y casos de uso. Piden a los equipos documentar el modelo, clasificar el caso de uso, evaluar el impacto de privacidad, probar sesgos y aprobar el despliegue.
Es un buen comienzo. Pero los agentes introducen riesgos que no quedan totalmente cubiertos por una gobernanza centrada en el modelo.
1. Los agentes tienen permisos
Los modelos generan salidas. Los agentes suelen tener permisos.
Pueden acceder a archivos, consultar bases de datos, llamar APIs, enviar correos, crear registros o invocar workflows. Eso significa que la agent governance tiene que tomar elementos del identity and access management.
La pregunta clave pasa a ser:
¿Qué está autorizado a hacer este agente, bajo qué condiciones, y quién aprobó esos permisos?
2. Los agentes tienen herramientas
Las herramientas crean una nueva superficie de ataque. Una instrucción maliciosa escondida en un documento, un correo, una página web, un ticket o una fuente de conocimiento recuperada puede intentar manipular al agente para que use mal sus herramientas.
En los agentes, el prompt injection no va solo de influir en el texto. Puede ir de influir en la acción.
3. Los agentes tienen comportamiento en runtime
Una evaluación del modelo antes del lanzamiento no basta. Los agentes pueden comportarse de manera distinta según los disparadores, el contexto, las respuestas de herramientas, los datos recuperados, las instrucciones del usuario y el estado del workflow.
La gobernanza debe continuar en runtime mediante logging, monitoring, alertas y respuesta a incidentes.
4. Los agentes necesitan límites de acción
Una respuesta aceptable no es lo mismo que una acción aceptable.
Por ejemplo, un agente puede estar autorizado a redactar una recomendación de reembolso pero no a emitir el reembolso. Puede estar autorizado a crear un ticket pero no a cerrarlo. Puede resumir un riesgo contractual pero no enviar el contrato revisado a la contraparte.
Estos límites deben ser explícitos.
5. Los agentes crean requisitos de evidencia
Cuando algo sale mal, la organización necesita reconstruir la secuencia:
- ¿Qué activó al agente?
- ¿Qué datos vio?
- ¿Qué instrucción siguió?
- ¿Qué herramientas llamó?
- ¿Qué decisión de policy se tomó?
- ¿Se requería aprobación humana?
- ¿Quién aprobó o rechazó la acción?
- ¿Qué cambió en el sistema de negocio?
Si no puedes responder a esas preguntas, no tienes agent governance. Tienes agent hope.
Un modelo práctico de gobernanza para agentes de IA
Un modelo útil de gobernanza para agentes debería incluir al menos ocho capas de control.
1. Inventario de agentes
No puedes gobernar agentes que no ves.
Registra cada agente con:
- Owner
- Propósito
- Grupo de usuarios
- Modelo o plataforma
- Fuentes de datos
- Herramientas y conectores
- Nivel de autonomía
- Nivel de riesgo
- Estado de aprobación
- Fecha de revisión
- Responsable de monitoring
2. Tiering del riesgo agéntico
Clasifica los agentes por comportamiento, no por la etiqueta del proveedor.
Dimensiones útiles:
- ¿Puede acceder a datos sensibles?
- ¿Puede llamar herramientas?
- ¿Puede escribir en sistemas?
- ¿Puede actuar sin un prompt del usuario?
- ¿Puede activar comunicación externa?
- ¿Puede tomar o influir en decisiones de alto impacto?
- ¿Puede delegar a otros agentes?
3. Matriz de permisos de herramientas
Cada herramienta debería tener una policy explícita.
Para cada herramienta, define:
- Permitida o bloqueada
- Solo lectura o capacidad de escritura
- Aprobación requerida o no
- Umbrales máximos
- Clases de datos permitidas
- Grupos de usuarios permitidos
- Requisitos de logging
Una herramienta de reembolsos, por ejemplo, podría permitir recomendaciones en borrador sin aprobación, requerir aprobación por debajo de cierto umbral y bloquear reembolsos autónomos por encima de ese umbral.
4. Puntos de aprobación humana
Human-in-the-loop no debería ser un eslogan. Debe estar diseñado dentro del workflow.
La aprobación debería ser obligatoria para:
- Compromisos legales
- Transacciones financieras
- Decisiones de RR. HH.
- Acciones con impacto en clientes
- Cambios sensibles de seguridad
- Acciones irreversibles
- Decisiones automatizadas de gran volumen
La aprobación debe convertirse en parte del audit trail.
5. Pruebas de prompt injection y tool misuse
Los agentes deberían probarse frente a escenarios adversariales antes de producción.
Pruebas para:
- Documentos recuperados maliciosos
- Instrucciones en conflicto
- Intentos de exfiltrar datos
- Intentos de saltarse aprobaciones
- Intentos de usar herramientas no autorizadas
- Intentos de sobrescribir instrucciones del sistema
- Intentos de activar acciones desde entradas no confiables
6. Runtime audit logging
Los logs deben capturar más que la respuesta final.
Como mínimo:
- Trigger de usuario o evento
- ID del agente
- Versión del prompt o de las instrucciones
- Versión del modelo
- Contexto recuperado
- Llamadas a herramientas
- Entradas y salidas de herramientas
- Decisiones de policy
- Aprobaciones humanas
- Acción final
- Trace ID
7. Monitoring y kill switches
Los agentes necesitan controles operativos.
Hay que monitorizar:
- Uso inesperado de herramientas
- Acceso inusual a datos
- Fallos repetidos
- Picos de escalado
- Anomalías de coste
- Comportamiento en bucle
- Acciones fuera de patrones normales
Un agente de alto riesgo debería tener un procedimiento claro de pausa, revocación o kill switch.
8. Revisiones de ciclo de vida
Los agentes evolucionan. Sus herramientas, prompts, fuentes de datos, modelos, usuarios y contexto de negocio cambian.
Revisa los agentes cuando:
- Se añade una nueva herramienta
- Se conecta una nueva fuente de datos
- Aumenta la autonomía
- Cambia el modelo
- El agente se publica en un nuevo canal
- Cambia el proceso de negocio
- Ocurre un incidente
La lección de Microsoft Copilot Studio
El enfoque de Microsoft es útil porque muestra el patrón empresarial emergente. Copilot Studio reúne creación low-code de agentes, grounding sobre datos de negocio, herramientas, flows, APIs, canales de publicación, capacidades de gestión, analítica y funciones de gobernanza.
Pero también muestra por qué las organizaciones necesitan su propio lenguaje de riesgo agéntico.
Un agente declarativo simple o prompt-response puede ser una extensión manejable del knowledge management. Un agente autónomo de Copilot Studio conectado a workflows de negocio se parece más a un actor de proceso digital. Un sistema multiagente que coordina entre herramientas y departamentos se parece más a un sistema operativo distribuido.
Esos sistemas no deberían pasar por la misma checklist de aprobación.
La pregunta de riesgo no es:
¿Se construyó con Copilot Studio, Azure AI Foundry, LangGraph, OpenAI, CrewAI u otro framework?
La mejor pregunta es:
¿Qué grado de agency tiene este sistema, y qué controles corresponden a ese grado de agency?
Ese enfoque también ayuda a evitar puntos ciegos específicos del proveedor. Una plataforma low-code puede ofrecer guardrails útiles, controles de administración e integración con herramientas de gobernanza empresarial. Eso es valioso. Pero la organización aún tiene que decidir qué acciones son aceptables, qué aprobaciones se requieren, qué evidencias deben conservarse y quién es owner del agente después del despliegue.
Una regla simple
Cuanto más pueda actuar un sistema de IA, más debe pasar la gobernanza de la documentación al control.
Usa esta regla:
- Si solo responde, gobierna contenido, acceso y precisión.
- Si recomienda, gobierna apoyo a la decisión y revisión humana.
- Si usa herramientas, gobierna permisos y políticas de llamadas a herramientas.
- Si actúa de forma autónoma, gobierna disparadores, aprobaciones, monitoring y respuesta a incidentes.
- Si se coordina con otros agentes, gobierna identidad, delegación y trazabilidad end-to-end.
Esa es la base de AI Agent Risk.
Qué hacer ahora
Para las organizaciones que empiezan ahora, los primeros pasos son prácticos:
- Crear un inventario de todos los agentes y sistemas tipo agente.
- Clasificarlos por nivel de agency, no por nombre de producto.
- Identificar qué agentes pueden acceder a datos, llamar herramientas o activar acciones.
- Definir una matriz de permisos para cada agente que use herramientas.
- Exigir aprobación humana para acciones sensibles o irreversibles.
- Registrar las acciones de los agentes de forma que soporte auditoría y respuesta a incidentes.
- Probar los agentes frente a prompt injection, fuga de datos y bypass de aprobación.
- Revisar los agentes cada vez que aumenten su autonomía, sus herramientas o su acceso a datos.
El futuro de la gobernanza de IA no va a tratar solo de modelos. Va a tratar de sistemas que perciben, deciden y actúan dentro de procesos de negocio.
Por eso los agentes necesitan un nuevo modelo de gobernanza.