Marketing crea un agente para campañas. Finanzas conecta otro al ERP. Sistemas prueba tres asistentes de código. Un área contrata una herramienta y otra desarrolla internamente la misma función. En pocos meses nadie sabe cuántos agentes existen, quién responde por ellos o qué datos pueden consultar.
Este crecimiento desordenado se conoce como agent sprawl. El problema no es disponer de muchos agentes, sino operarlos sin inventario fiable, propietario, versión, evaluación, política de acceso o proceso de retirada.
El 27 de octubre de 2026, IBM anunció funciones para descubrir y administrar agentes de distintas plataformas mediante una capa común. Días antes, Google Cloud presentó Agent Registry y Agent Gateway para centralizar agentes, herramientas, skills y servidores MCP. El mercado está pasando de crear un agente aislado a gestionar una flota.
¿Qué es el agent sprawl?
Aparece cuando agentes, automatizaciones y herramientas se multiplican más rápido que la capacidad de la empresa para identificarlos y controlarlos. Se parece al shadow IT, con una diferencia crítica: los agentes no solo almacenan o muestran información; también pueden decidir y actuar.
Un agente olvidado puede conservar credenciales activas, utilizar un modelo obsoleto, invocar una API retirada o seguir generando gasto. Dos agentes con la misma finalidad pueden ofrecer resultados incompatibles porque emplean reglas, fuentes y versiones distintas.
Señales de falta de control
- nadie puede enumerar todos los agentes en producción;
- varios equipos han desarrollado el mismo caso de uso;
- faltan responsables técnicos o de negocio;
- se conectan herramientas y MCP sin revisión;
- las credenciales sobreviven al final de los proyectos;
- no existe una versión aprobada ni historial de cambios;
- calidad, latencia y coste se miden de forma incompatible;
- un incidente no puede vincularse rápidamente a un agente;
- prototipos experimentales participan en procesos críticos.
Un catálogo es algo más que una lista
Una hoja de cálculo puede servir para comenzar, pero un registro empresarial debe actuar como fuente de verdad. Cada agente necesita identidad estable y metadatos suficientes para descubrimiento, seguridad y operación.
- nombre, finalidad y descripción;
- responsable funcional y técnico;
- entorno, versión y estado del ciclo de vida;
- modelo, prompts, skills y herramientas;
- fuentes de datos y nivel de sensibilidad;
- permisos, credenciales y sistemas utilizados;
- métricas de calidad, coste y rendimiento;
- evaluaciones, riesgos y aprobaciones;
- dependencias, consumidores y próxima revisión.
El catálogo debe poder consultarse. Antes de construir algo nuevo, cualquier equipo debería descubrir si existe una capacidad aprobada que pueda reutilizar o ampliar.
Registro, gateway e identidad: funciones distintas
El registro conserva la fuente de verdad
Indica qué existe, quién es el propietario, qué versión está activa y qué componentes están aprobados. Organiza agentes, herramientas, endpoints y skills.
El gateway aplica políticas al tráfico
Controla las llamadas entre usuarios, agentes, modelos y herramientas. Puede verificar identidad, bloquear destinos, filtrar información sensible, imponer límites y registrar cada interacción.
La identidad permite exigir responsabilidades
Cada agente debe contar con identidad propia. Así se evita compartir cuentas genéricas y se pueden conceder permisos mínimos, emitir credenciales temporales y revocar una sesión concreta. Es la continuación práctica de una delegación segura para agentes.
Ejemplo: cuatro departamentos trabajan con proveedores
Compras crea un agente para comparar ofertas. Finanzas desarrolla otro para validar datos bancarios. Jurídico contrata un asistente de contratos y Operaciones automatiza las altas. Todos trabajan con proveedores, pero cada uno mantiene su propia definición de empresa activa.
Con un catálogo gobernado, la organización registra las cuatro capacidades y detecta componentes comunes: consulta mercantil, política de riesgo, lectura documental e integración con el ERP. Estas funciones se convierten en herramientas reutilizables, con propietarios y contratos claros.
El agente de Compras puede orquestar herramientas aprobadas sin recibir permisos administrativos sobre el ERP. Un cambio en la política de riesgo se realiza una sola vez. Las métricas muestran qué agente utiliza cada recurso y cuánto cuesta el proceso completo.
Ciclo de vida: del experimento a la retirada
- borrador: idea todavía sin acceso a datos reales;
- experimental: prueba aislada y limitada;
- candidato: evaluación funcional, de seguridad y coste;
- aprobado: disponible para uso o reutilización;
- producción: operado con métricas, alertas y soporte;
- restringido: bloqueado para nuevos usos mientras se corrige;
- retirado: credenciales revocadas y dependencias migradas.
La promoción debe exigir pruebas, no solo una demostración convincente. Define casos, criterios de éxito y límites de riesgo para cada fase.
La evaluación debe ser continua
Modelos, datos, herramientas y normas cambian. Una evaluación de lanzamiento no garantiza el comportamiento futuro. Mide calidad, llamadas a herramientas, latencia, coste e incumplimientos.
Combina recorridos deterministas para acciones críticas con evaluaciones semánticas para respuestas abiertas. Las correcciones humanas, quejas y errores deben convertirse en nuevos casos de prueba. La observabilidad de agentes aporta las evidencias para ese ciclo.
Evitar duplicidades sin frenar la innovación
Un buen gobierno crea vías rápidas para experimentos de bajo riesgo y controles sólidos para producción. Un sandbox con datos sintéticos permite libertad; los accesos reales exigen registro, propietario y revisión.
- publica plantillas y componentes aprobados;
- ofrece búsqueda antes de iniciar el desarrollo;
- automatiza el registro desde el pipeline;
- utiliza políticas como código;
- permite excepciones con fecha de caducidad;
- mide reutilización y tiempo de aprobación;
- evita que el catálogo sea un formulario desconectado de la operación.
Arquitectura mínima
- inventario central con API y búsqueda;
- identidad única por agente y entorno;
- gateway o proxy para llamadas externas;
- almacén de credenciales temporales;
- telemetría común para modelos y herramientas;
- pipeline de evaluación y aprobación;
- alertas de coste, fallo y anomalías;
- caducidad y recertificación automáticas.
No es imprescindible adquirir una plataforma completa el primer día. Se puede comenzar con un catálogo integrado en CI/CD y evolucionar los controles según crezcan el número y el riesgo de los agentes.
Métricas para gestionar la flota
- agentes activos, experimentales y sin propietario;
- porcentaje revisado dentro de plazo;
- capacidades reutilizadas frente a reconstruidas;
- fallos e incidentes por versión;
- coste por agente y resultado empresarial;
- tiempo entre solicitud y aprobación;
- herramientas o credenciales sin uso reciente;
- agentes retirados con dependencias pendientes.
Plan de 30 días
Semana 1: descubre
Localiza agentes, bots, automatizaciones, MCP y herramientas. Incluye experimentos departamentales y proveedores.
Semana 2: clasifica
Asigna propietario, finalidad, datos, permisos, entorno, criticidad y estado. Atiende primero los riesgos inmediatos.
Semana 3: normaliza
Crea el esquema de registro, criterios de aprobación, métricas y caducidad. Vincula el alta al despliegue.
Semana 4: consolida
Elimina duplicidades evidentes, revoca accesos abandonados y publica capacidades aprobadas para reutilización.
De una colección de bots a una capacidad empresarial
Una gran cantidad de agentes puede ser una ventaja si existe claridad sobre finalidad, propiedad, calidad y autoridad. Sin ella, cada agente amplía el riesgo y el coste de coordinación.
ProativaIA desarrolla agentes y automatizaciones empresariales, plataformas a medida e integraciones. Podemos inventariar tu operación, construir un catálogo gobernado y diseñar una arquitectura de agentes reutilizables, observables y seguros.