Solución · AI Operations
Todos tus agentes de IA tienen fecha de encendido. Casi ninguno tiene fecha de revisión ni de apagado.
Montar un agente es un proyecto. Lo que casi nadie tiene montado es la función que lo gobierna después: un catálogo donde cada agente tiene dueño y versión, una puerta que decide qué cambio llega a producción, un rollback que funciona, una revisión que comprueba si sigue aportando y una retirada de verdad —con las credenciales revocadas—. Montamos ese ciclo de vida y lo operamos.
El problema
El agente número uno lo recuerda todo el mundo. Del número catorce nadie sabe quién lo pidió, qué versión corre ni si lo usa alguien.
- Nadie tiene la lista. No existe un sitio donde estén todos los agentes que corren hoy con su dueño, su versión, sus permisos y el motivo por el que se aprobaron: hay una hoja de cálculo vieja y la memoria de tres personas.
- Un cambio de prompt llega a producción porque alguien lo tocó, no porque haya pasado una puerta: no hay entorno de prueba, no hay evaluación que lo compare con la versión anterior y no hay forma limpia de volver atrás si sale peor.
- «Versión» significa cosas distintas según a quién preguntes: el modelo cambió por su cuenta, el prompt se editó a mano y las herramientas conectadas no son las de hace tres meses —y nada de eso está atado a un número que puedas nombrar.
- Hay agentes que ya no usa nadie y siguen encendidos: consumen tokens todos los días y mantienen vivas credenciales con permisos de escritura, y nadie los apaga porque nadie está seguro de qué se rompe si lo hace.
- Cuando alguien pregunta si un agente sigue aportando, la respuesta es una opinión: no hay línea base, ni revisión con cadencia, ni criterio escrito de cuándo se rehace y cuándo se retira.
Coste de seguir igual
Gartner predijo, en su comunicado del 25 de junio de 2025, que más del 40 % de los proyectos de IA agéntica se cancelarán antes de que acabe 2027, y las razones que da no son técnicas: costes que suben, valor de negocio poco claro y controles de riesgo inadecuados. Las tres se gestionan en el ciclo de vida o no se gestionan en ninguna parte. Y el agujero está medido: en el whitepaper «The Non-Human Identity Governance Vacuum» de la Cloud Security Alliance (mayo de 2026), el 78 % de las organizaciones declara no tener una política documentada para crear y eliminar identidades de IA, el 51 % no tiene un propietario claro de esas identidades y solo el 20 % dispone de un proceso formal de baja con revocación de claves. Traducido a tu empresa: cada agente que enciendes sin ciclo de vida es coste que nadie vuelve a revisar y una credencial que nadie va a revocar. No falla el día uno. Se acumula.
La solución
Montamos el ciclo de vida de tus agentes —catálogo, puerta de promoción, versionado con rollback, revisión y retirada— y lo operamos como función continua
- 1Levantamos el catálogo real, no el que crees que tienes: qué agentes corren hoy, quién los pidió, quién responde de cada uno, qué versión está viva, con qué permisos y con qué credencial. Casi siempre aparecen agentes que nadie recordaba haber encendido.
- 2Ponemos estados y puertas. Un agente pasa de propuesto a validado, de validado a producción y de producción a retirado por un camino escrito, no porque alguien lo despliegue un jueves. Antes de entrar en producción hay una evaluación contra casos reales de tu negocio, y es esa evaluación la que abre la puerta —no la sensación de que va bien.
- 3Hacemos que «versión» signifique algo: prompt, modelo, herramientas conectadas y límites quedan atados a una versión con nombre, comparable con la anterior y a la que se puede volver en minutos. Es lo que ya hacen las plataformas serias —AWS Bedrock AgentCore congela cada actualización en una versión inmutable y revierte repuntando el endpoint; Microsoft Foundry guarda snapshots de agente y promociona entre entornos con puertas basadas en evaluaciones—, y lo montamos sobre lo que tú ya uses en vez de traerte otra herramienta.
- 4Metemos la revisión periódica, que es donde se decide si un agente sigue vivo: cuánto cuesta, cuánto se usa, con qué calidad responde frente a su línea base y si el proceso al que servía sigue existiendo. Con criterio escrito de cuándo se ajusta, cuándo se rehace y cuándo se retira —para que la decisión no dependa de quién esté en la reunión.
- 5Cerramos por el final, que es lo que casi nadie tiene montado: la retirada. Se apaga el agente, se revocan sus credenciales y sus accesos, se decide qué se conserva de sus registros y durante cuánto tiempo, y se traspasa lo que hacía a quien corresponda. Es la fase de retirada que un sistema de gestión de IA como ISO/IEC 42001 exige tratar de forma explícita y, de paso, la que deja de pagar por agentes que ya no usa nadie.
Lo que cambia
Lo que dejas de perder
El catálogo deja de ser una hoja desactualizada: cada agente vivo tiene dueño, versión, permisos y motivo de aprobación —y lo que no está en el catálogo, no corre.
Mecanismo
Un cambio malo deja de ser un problema de horas: la versión anterior tiene nombre y se vuelve a ella, en lugar de reconstruir a mano el prompt que había el martes.
Mecanismo
El agente que ya no usa nadie deja de ser gasto invisible y credencial abierta: la revisión lo detecta y la retirada lo cierra de verdad, con los accesos revocados.
Mecanismo
Qué medimos: % de agentes vivos con dueño y versión en el catálogo, % de cambios que llegaron a producción por la puerta de evaluación, tiempo de rollback a la versión anterior, agentes revisados y retirados por trimestre, y credenciales revocadas tras cada baja.
Qué medimos
Ficha técnica
- Trabajo que elimina
- descubrir tarde qué agentes corren, quién los pidió y qué versión está viva —y no poder volver atrás cuando un cambio sale mal ni apagar del todo el que ya no usa nadie
- Implementación habitual
- 4–8 semanas
- Entrada
- los agentes que ya tienes corriendo, con sus prompts, sus modelos, sus herramientas conectadas y sus credenciales
- Salida
- un catálogo vivo con dueño, versión y estado por agente, una puerta de promoción con evaluación, rollback a la versión anterior, revisión periódica con criterio escrito y una retirada que revoca accesos
- Compatible con
- AWS Bedrock AgentCoreMicrosoft Foundry Agent ServiceGoogle Vertex AI Agent EngineLangSmithLangGraphn8nOpenAIAnthropic
- Puede conectarse con
- Tu control de versiones y tu CITu gestor de secretos y tu proveedor de identidadTu batería de evaluación sobre casos reales del negocioTu inventario de identidades no humanas, si ya lo tienes
- Qué medimos
- % de agentes vivos con dueño y versión en el catálogo% de cambios promocionados a través de la puerta de evaluacióntiempo de rollback a la versión anterioragentes revisados y retirados por trimestrecredenciales revocadas tras cada baja
- Adecuado para
- empresas que ya han pasado del primer agente al décimo y empiezan a no saber cuántos tienen, quién responde de cada uno ni cuáles se podrían apagar sin que se note
- No adecuado para
- quien tiene un solo agente en producción y una persona que lo conoce entero: ahí el ciclo de vida es una conversación, no una función
Preguntas frecuentes
En el objeto. Mantener responde a «que mis agentes sigan funcionando bien»: vigilar la deriva, actualizar cuando cambia un modelo, controlar el coste, reaccionar cuando algo se degrada. Eso lo tienes desarrollado en quién mantiene los agentes de IA en producción, y responder a un fallo concreto es gestión de incidencias. El ciclo de vida responde a otra cosa: qué estados atraviesa un agente y quién autoriza cada salto. Alta con dueño y motivo, validación antes de producción, promoción por una puerta de evaluación, versiones nombradas con rollback, revisión con cadencia y retirada con revocación. Mantener es el verbo del día a día; el ciclo de vida es el marco que decide qué entra, qué cambia y qué sale. Sin él, mantener acaba siendo cuidar cosas que ya nadie debería tener encendidas.
Te da el mecanismo, no la función, y esa diferencia es la que se paga. AWS Bedrock AgentCore versiona de forma inmutable y te deja revertir; Microsoft Foundry guarda snapshots y permite poner puertas de evaluación entre entornos. Perfecto: los usamos. Lo que ninguna plataforma te da es quién responde de cada agente, qué evaluación tiene que pasar un cambio para ser aceptable en TU negocio, cada cuánto se revisa si el agente sigue aportando, con qué criterio se decide retirarlo, ni qué se hace con sus credenciales y sus registros el día que se apaga. Eso son decisiones y cadencias, y hay que operarlas. Y si tienes agentes repartidos entre varias plataformas —lo normal en cuanto pasas de tres—, el catálogo y el criterio tienen que vivir por encima de todas ellas.
Apagarlo es la parte fácil y la que menos importa. Retirar de verdad es revocar sus credenciales y sus permisos —que es donde falla casi todo el mundo: solo el 20 % de las organizaciones dice tener un proceso formal de baja con revocación de claves, según el whitepaper de la Cloud Security Alliance de mayo de 2026—, decidir qué registros se conservan y durante cuánto tiempo, avisar a quien dependía de él y traspasar lo que hacía. Un agente «apagado» cuya identidad sigue viva no es un agente retirado: es una credencial con permisos de escritura que ya no vigila nadie porque, oficialmente, ese agente no existe. Por eso la retirada es una fase del ciclo de vida con lista de comprobación, no un interruptor.
¿Lo montamos en tu negocio?
Tú tienes el problema localizado. Nosotros lo dejamos funcionando y medido.