Publicar un agente es un hito técnico. Conseguir que forme parte del trabajo diario es un resultado organizativo. Entre ambos puede haber semanas de formación, ajustes de permisos y mejoras de las fuentes; también puede no haber nada, porque nadie vuelve a revisar qué ocurrió después del lanzamiento.
A medida que crece el catálogo de agentes, la pregunta cambia. Ya no basta con saber cuántos existen: necesitamos entender cuáles se utilizan, para qué procesos, con qué continuidad y bajo qué condiciones de seguridad.
La pregunta que debe resolver el gobierno de IA
¿Estamos desplegando agentes o estamos consiguiendo que resuelvan trabajo real? El inventario identifica lo que tenemos. La observabilidad aporta evidencias de actividad. La adopción y el valor requieren interpretar esas evidencias en su contexto.
Del inventario a una visión de uso
Un inventario permite registrar identidad, propietario, entorno, propósito y estado de publicación. Es necesario para asignar responsabilidades y controlar el ciclo de vida, pero no demuestra que una solución esté siendo utilizada.
Un agente publicado puede seguir en pruebas, estar pendiente de comunicación interna o atender un proceso que solo ocurre al cierre del trimestre. Otro puede generar actividad constante sin intervención humana. Tratarlos como equivalentes lleva a decisiones equivocadas.
En IntegroIA proponemos cruzar inventario, seguridad, uso y resultado. Las tres primeras dimensiones ayudan a entender qué ocurre; la última permite decidir si merece la pena mantener o ampliar la inversión. Este enfoque complementa la preparación del tenant y el gobierno de Copilot.
Qué aportan Agent 365, Defender y Copilot Studio
Microsoft Agent 365 incorpora capacidades para observar, gobernar y proteger agentes. Dentro de ese ecosistema, Microsoft Defender permite consultar datos de observabilidad mediante Advanced Hunting y Kusto Query Language (KQL). Su finalidad principal es investigar actividad y riesgos; esa telemetría también puede servir como fuente complementaria para estudiar patrones de uso.
La documentación de Microsoft distingue, entre otras, dos tablas: AgentsInfo, con inventario y configuración de agentes, y CloudAppEvents, que puede contener datos de observabilidad de Agent 365, como acciones, invocaciones de herramientas y accesos a datos. Las alertas de seguridad son otra dimensión: contar alertas no equivale a contar uso.
Esto no significa que cualquier tenant disponga automáticamente de una medición completa. Hay que validar licencias, roles de acceso, configuración del conector de Microsoft 365, emisión de telemetría y cobertura de cada plataforma. La documentación consultada mantiene la detección e investigación de amenazas a agentes en vista previa; no debe extrapolarse la disponibilidad general de Agent 365 a todas sus capacidades.
Para agentes de Copilot Studio conviene contrastar el análisis con sus propias métricas de Monitor. Microsoft diferencia sesiones conversacionales y ejecuciones activadas por eventos. Además, la métrica de usuarios activos requiere autenticación y la actividad del panel de pruebas no se incluye en esa analítica. Las fuentes pueden contar cosas distintas sin que ninguna esté necesariamente equivocada.
Qué medir durante una ventana de 30 días
Una ventana móvil de 30 días es un punto de partida práctico, no una regla universal. Debe ajustarse a la retención disponible y al ritmo del proceso. También conviene fijar la zona horaria, excluir periodos parciales cuando proceda y documentar retrasos de ingesta.
| Indicador | Qué permite observar | Qué no demuestra |
|---|---|---|
| Usuarios humanos identificados | Alcance entre personas que generan interacciones válidas. | No incluye necesariamente usuarios anónimos ni mide agentes autónomos. |
| Días y semanas con actividad | Distribución temporal y continuidad. | No prueba que las mismas personas vuelvan. |
| Eventos observados | Volumen de registros dentro del filtro elegido. | No equivale a conversaciones, tareas resueltas ni ahorro. |
| Última actividad | Recencia de la señal disponible. | La ausencia de señal no demuestra abandono. |
| Usuarios recurrentes | Personas que vuelven en periodos distintos, según una definición explícita. | No demuestra satisfacción ni calidad de las respuestas. |
| Resultado del proceso | Resolución, calidad, tiempo y coste frente a una referencia. | No suele obtenerse solo de los registros de seguridad. |
Para un agente autónomo, el indicador principal puede ser el número de ejecuciones válidas y su tasa de finalización, no el número de usuarios. Para uno conversacional, puede interesar la proporción de usuarios recurrentes dentro de la población a la que realmente está destinado. El denominador debe ser relevante y estar documentado.
Una plantilla KQL, no un esquema universal
Antes de escribir la agregación hay que comprobar muestras del tenant: qué evento representa una interacción, dónde aparece el identificador estable del agente y qué identidad corresponde a la persona. Un propietario, una cuenta de servicio y un usuario que inicia una conversación no son intercambiables.
El siguiente ejemplo es una plantilla conceptual sobre una vista normalizada ficticia. ActividadAgentesNormalizada y sus columnas no son una tabla ni un esquema nativo de Microsoft. La transformación previa debe construirse y validarse con los eventos reales disponibles; pegar esta consulta directamente en Advanced Hunting no funcionará sin esa adaptación.
// Vista propia: una fila por evento válido y deduplicado.
// Solo interacciones humanas de producción para este análisis.
ActividadAgentesNormalizada
| where Timestamp >= ago(30d) and Timestamp < now()
| where Entorno == "Produccion"
| where TipoActividad == "InteraccionHumana"
| where isnotempty(AgentId)
| summarize
EventosObservados = count(),
UsuariosIdentificadosAprox = dcountif(UserId, isnotempty(UserId)),
DiasActivosAprox = dcount(startofday(Timestamp)),
PrimeraActividadEnVentana = min(Timestamp),
UltimaActividadEnVentana = max(Timestamp)
by AgentId
| order by UltimaActividadEnVentana descLa vista normalizada debe resolver la extracción de campos, la identidad, el entorno y los duplicados antes del recuento. dcount y dcountif son funciones de recuento distinto aproximado: si el informe exige cifras exactas, hay que utilizar una estrategia de agrupación adecuada y revisar sus costes y límites.
Agrupar por un identificador estable evita dividir el historial cuando cambia el nombre del agente. El nombre visible y el propietario pueden añadirse después desde un inventario depurado, cuidando que la unión no multiplique filas.
La primera actividad dentro de la ventana no es la fecha de creación. Y para detectar agentes sin actividad hay que partir del inventario completo y hacer una unión que conserve los agentes sin coincidencias: una consulta sobre eventos, por sí sola, nunca mostrará los que no han producido registros.
Cómo evitar conclusiones engañosas
Una consulta puede ser técnicamente correcta y producir un cuadro de mando que invite a interpretar mal los datos. Antes de presentarlo a dirección, conviene resolver estas situaciones:
- Una interacción genera varios eventos. Las llamadas a herramientas, reintentos y accesos a recursos inflan el volumen. Para contar sesiones o ejecuciones hacen falta identificadores de correlación fiables.
- Actividad no implica éxito. Un agente con errores puede generar más registros que otro que resuelve la tarea a la primera. Conviene contrastar fallos, escalados y resultados.
- Una identidad técnica no es una persona. No atribuyas a un empleado las acciones de una cuenta de servicio ni rellenes usuarios desconocidos con el propietario del agente.
- Los días activos no miden retención. Para estudiar recurrencia de usuarios hay que agrupar por agente y persona, y comprobar su presencia en periodos distintos.
- La falta de registros tiene varias causas. Puede indicar desuso, pero también cobertura incompleta, interrupción del conector, cambios de identidad o un proceso estacional.
Es preferible mostrar «sin actividad observada en la ventana analizada» que etiquetar un agente como «inactivo» sin más comprobaciones. Del mismo modo, una ventana móvil de 30 días no debe compararse directamente con una métrica mensual calculada por mes natural.
Del cuadro de mando a decisiones de gobierno
El informe debe terminar en una revisión con responsables, no en un ranking de agentes por volumen. Estas son algunas decisiones razonables:
- Uso sostenido y resultados útiles: mantener, documentar y evaluar una ampliación al colectivo adecuado.
- Actividad concentrada en el creador: comprobar si sigue siendo un piloto, si se ha comunicado su disponibilidad y si responde a una necesidad compartida.
- Mucho uso y mala resolución: revisar fuentes, instrucciones, herramientas y criterios de escalado antes de promocionarlo.
- Sin actividad observada: verificar cobertura, estacionalidad, dependencias y necesidad con su responsable antes de retirarlo.
- Actividad inesperada o acceso sensible: abrir una revisión de seguridad aunque las métricas de adopción sean positivas.
La retirada no debería ser automática por superar un umbral de días. Un agente de contingencia puede ser valioso aunque apenas se ejecute. Otro muy utilizado puede requerir suspensión por riesgo. La decisión combina propósito, evidencia y responsabilidad.
Adopción por departamento, sin vigilancia individual
En determinados escenarios puede ser útil enriquecer los eventos con atributos organizativos de Microsoft Entra ID. Esa relación requiere permisos y una integración explícita: no debe suponerse que Advanced Hunting contiene por defecto todos los atributos del directorio.
La unión debe utilizar identificadores estables y contemplar invitados, cuentas eliminadas y cambios de departamento. Asociar actividad histórica con el departamento actual puede distorsionar la evolución; conviene declarar esa limitación o conservar una referencia temporal cuando sea necesario y legítimo.
El objetivo es mejorar servicios y procesos, no construir clasificaciones individuales de productividad. Recomendamos limitar la información a la necesaria, priorizar agregados, evitar desgloses de colectivos pequeños, restringir accesos y acordar conservación y finalidad con privacidad y seguridad. Para medir adopción normalmente no hace falta analizar el contenido de los prompts.
Cómo empezar con un piloto medible
- Seleccionar un conjunto acotado de agentes. Registrar propósito, propietario, público objetivo y frecuencia esperada del proceso.
- Validar cobertura y permisos. Confirmar fuentes, licencias, conectores, retención e identidades con actividad controlada y autorizada.
- Acordar un diccionario de métricas. Definir interacción, usuario activo, ejecución, recurrencia, éxito y exclusiones antes de comparar cifras.
- Construir y contrastar las consultas. Revisar muestras, deduplicación y correlación; comparar con Monitor de Copilot Studio donde sea aplicable.
- Revisar con negocio y seguridad. Añadir calidad, coste y resultado del proceso, y asignar acciones con responsable y fecha de seguimiento.
La salida útil del piloto es un inventario enriquecido con evidencias, limitaciones conocidas y decisiones pendientes. No hace falta empezar con un gran cuadro de mando: hace falta poder explicar qué significa cada cifra y qué decisión permite tomar.
El criterio de IntegroIA
Gobernar agentes significa saber cuáles existen, qué hacen y si siguen siendo útiles. La telemetría acerca esas respuestas, pero solo cuando se interpreta junto al proceso, las personas y el riesgo. Desplegar es el principio; demostrar utilidad es el trabajo que viene después.
Fuentes oficiales y alcance
Revisión documental: 28 de septiembre de 2026. Este artículo propone un enfoque de análisis; no presenta resultados de un tenant ni una consulta probada en un entorno de cliente. La disponibilidad, los requisitos y los esquemas deben comprobarse antes de implantarlo.
- Microsoft Agent 365: visión general y requisitos. Actualización indicada: 20 de agosto de 2026.
- Microsoft Defender: detección e investigación de amenazas a agentes, Advanced Hunting y tablas de observabilidad (vista previa). Actualización indicada: 3 de septiembre de 2026.
- Copilot Studio: Monitor, usuarios activos y sesiones. Actualización indicada: 25 de agosto de 2026.