Poco después de un despliegue salta una alerta. Las tasas de error aumentan, un servicio consume más memoria de lo habitual y las solicitudes de los clientes empiezan a fallar.
Un agente de IA de operaciones examina el historial de despliegues, rastrea las dependencias afectadas y compara el incidente con fallos anteriores. Concluye que un servicio concreto es probablemente el responsable y propone reiniciarlo.
La recomendación parece razonable. Esperar a que intervenga alguien de ingeniería puede alargar la interrupción. Reiniciar de inmediato puede restablecer el servicio.
¿Debe actuar el agente?
Es un escenario hipotético, pero la decisión ya empieza a ser real para los equipos de operaciones. Resume la pregunta central de AgenticOps. La cuestión no es solo si un sistema de IA puede investigar un incidente o ejecutar un comando. Es cuánta autoridad debe recibir ese sistema y qué debe cumplirse antes de que esa autoridad aumente.
Mi opinión es que AgenticOps ya es útil, pero la evidencia pública respalda una forma de autonomía más limitada de lo que sugieren muchos titulares. Las empresas están obteniendo valor de agentes que recopilan evidencias, correlacionan eventos, investigan causas probables y aplican políticas de lanzamiento. La evidencia de un control amplio y desatendido de la infraestructura de producción sigue siendo limitada.
Eso no convierte a AgenticOps en una moda tecnológica vacía. Significa que debemos evaluarlo como un modelo de autoridad, no solo como una herramienta de automatización más inteligente.
La adopción es real, pero la adopción no describe la autoridad
El informe de AgenticOps que Cisco publicó en septiembre de 2026 ofrece una señal de mercado importante. El estudio de Omdia en el que se basa encuestó a más de 1000 responsables de operaciones de TI y de red de organizaciones con al menos 500 empleados de Norteamérica, Europa Occidental y Asia-Pacífico.[1]
El 51 % afirmó tener sistemas agénticos que actúan en producción. Por otra parte, el 82 % dijo sentirse cómodo permitiendo al menos algunos cambios en la red de producción sin aprobación previa.
Esas cifras muestran que los agentes operativos están dejando atrás la fase experimental. No nos dicen cuánta autoridad tienen hoy esos agentes.
«Actuar en producción» puede describir situaciones muy distintas. Un agente puede recopilar registros (logs), abrir un incidente, recomendar una reversión (rollback), bloquear un lanzamiento arriesgado o ejecutar un paso de recuperación predefinido. Todas estas actividades tocan las operaciones de producción, pero el riesgo no es el mismo.
Los resultados sobre confianza ponen de manifiesto esa diferencia. El 69 % de las personas encuestadas exigía explicaciones detalladas de las acciones realizadas por agentes. El 99 % quería al menos una salvaguarda (guardrail), como puntos de aprobación, límites de política, acceso basado en roles, registros de auditoría o mecanismos de anulación de emergencia.[2]
Por tanto, la señal del mercado tiene más matices que «las empresas están entregando las operaciones a la IA». Las organizaciones parecen dispuestas a aumentar la automatización, pero exigen controles más estrictos sobre lo que un agente puede ver, decidir y cambiar.
El alcance también importa. Este estudio se refiere a responsables de operaciones de red. Es una evidencia útil sobre las actitudes en NetOps y sobre los despliegues declarados. No es una medición universal de todas las cargas de trabajo empresariales.
Un agente puede elegir un paso sin ser dueño de la decisión
La automatización tradicional sigue un camino que los equipos de ingeniería definen de antemano. Un script reinicia un servicio cuando se supera un umbral. Un pipeline de despliegue ejecuta una secuencia fija de pruebas. Un runbook (procedimiento operativo) ejecuta comandos conocidos en un orden conocido.
Un agente operativo (en inglés) es distinto porque puede interpretar el contexto y elegir entre distintas herramientas o acciones posibles. Puede decidir qué registros consultar, qué dependencia inspeccionar o qué playbook de recuperación encaja mejor con la evidencia.
Esa flexibilidad es valiosa cuando los incidentes no siguen una secuencia predecible. También es la razón por la que la autoridad debe tratarse por separado de la inteligencia.
La certeza de un modelo es una predicción. No es una decisión de control de acceso.
Un agente puede estar muy seguro de que reiniciar un servicio resolverá un incidente. Esa certeza no demuestra que el agente tenga permiso para reiniciarlo, que la acción sea segura en el entorno actual ni que alguien haya aceptado la responsabilidad de las consecuencias.
Por tanto, AgenticOps combina dos sistemas distintos:
- Un sistema de razonamiento propone lo que debería ocurrir.
- Un sistema de autoridad determina lo que se permite que ocurra.
El agente puede elegir entre herramientas y pasos autorizados previamente dentro de un límite de tarea definido. No debe ampliar ese límite ni decidir cuánta autoridad merece.
Lo que demuestra la evidencia actual de los productos
La documentación actual más sólida apunta en una dirección coherente. Los agentes operativos útiles trabajan dentro de límites explícitos de recursos, permisos y aprobación.
| Evidencia | Comportamiento documentado | Lo que respalda | Lo que no demuestra |
|---|---|---|---|
| Estudio de NetOps de Cisco y Omdia [1][2] | Informa de adopción en producción, de disposición a permitir algunos cambios autónomos y de una fuerte demanda de salvaguardas | AgenticOps es una tendencia real en NetOps, y los controles de confianza siguen siendo importantes | Una prueba independiente de que la autonomía amplia es segura |
| Documentación de seguridad de AWS DevOps Agent [3][4] | Usa Agent Spaces, roles de IAM, salvaguardas de permisos, acceso de solo lectura por defecto y registros de auditoría | Una investigación útil depende de un límite de acceso definido | Que el acceso de escritura sin restricciones sea apropiado |
| Documentación de Azure SRE Agent [5] | Separa los permisos sobre recursos de los modos de ejecución Review y Autonomous | Los derechos de acceso y la política de aprobación deben gobernarse de forma independiente | Que el modo autónomo sea adecuado para cualquier tarea de producción |
| Recorrido práctico de SRE de Google [6] | Recupera evidencias, elige entre playbooks de mitigación y verifica el resultado | Un patrón de acción creíble incluye un conjunto cerrado de acciones y una verificación | Un resultado medido en producción a escala |
Estas fuentes no son equivalentes. El informe de Cisco es un estudio de mercado patrocinado por Cisco y realizado por Omdia. AWS y Microsoft describen controles de producto. El recorrido de Google es un ejemplo de arquitectura, no un resultado medido en un cliente.
Aun con esas limitaciones, el patrón está claro. La evidencia pública es más sólida para la investigación, la correlación, la elaboración de resúmenes, el control de lanzamientos y las acciones cuidadosamente acotadas. Es mucho más débil para los cambios sin restricciones en los sistemas de producción.
Este patrón me llevó a una forma más útil de hablar de AgenticOps. La elección no es entre operaciones manuales y autonomía total. Es una escalera de autoridad operativa.
La escalera de autoridad del agente
Por accesibilidad, el marco también se ofrece a continuación.
- Observar: el agente recopila y normaliza la telemetría. Las personas definen las fuentes de confianza y los límites de acceso.
- Investigar: el agente correlaciona evidencias y pone a prueba posibles explicaciones. Las personas revisan la incertidumbre y cuestionan las conclusiones.
- Recomendar: el agente propone un runbook, una remediación o un veredicto sobre un lanzamiento. Las personas aceptan, rechazan o modifican la recomendación.
- Acción aprobada: el agente ejecuta un único cambio claramente descrito tras la aprobación. Una persona responsable de la operación evalúa el impacto y lo autoriza.
- Autonomía acotada: el agente ejecuta una clase de acción predefinida y reversible. Las personas fijan la política, vigilan el comportamiento y conservan la autoridad para anular sus decisiones.
Pasar de un nivel al siguiente no es simplemente una mejora del modelo. Es una decisión de la organización sobre permisos, riesgo y rendición de cuentas.
Un equipo puede confiar en un agente para investigar todos los incidentes de producción y, al mismo tiempo, permitirle ejecutar solo un pequeño conjunto de acciones. Otro equipo puede permitir reinicios automáticos de servicios de desarrollo sin estado, pero exigir aprobación para la misma acción en un sistema de pagos.
El modelo podría ser idéntico en ambos entornos. La autoridad adecuada no lo es.
De vuelta a la decisión de reiniciar
Antes de que el agente ejecute el reinicio del servicio del escenario inicial, hay que responder cuatro preguntas.
1. ¿Tiene suficiente contexto operativo?
Una recomendación basada en un solo registro de errores es muy distinta de otra respaldada por el historial de despliegues, la topología de dependencias, las métricas de recursos, los cambios de configuración recientes e incidentes similares.
Un agente no puede compensar la telemetría que falta razonando con más seguridad. Por eso la madurez de la observabilidad va antes que la autonomía operativa. Si la titularidad de los servicios, las dependencias y el historial de incidentes están fragmentados, el agente hereda esa fragmentación.
2. ¿Está la acción permitida de forma explícita?
El agente debe operar mediante una identidad restringida con acceso de mínimo privilegio. Sus herramientas, los recursos sobre los que actúa y las acciones permitidas deben definirse fuera del modelo. Un prompt que le pide al agente que «tenga cuidado» no es un control de seguridad.
AWS documenta esta separación mediante Agent Spaces, roles de IAM y salvaguardas de permisos. Microsoft ofrece una comparación útil en Azure SRE Agent, que separa los permisos sobre recursos del modo de ejecución que decide si las acciones sobre la infraestructura necesitan aprobación.
Los productos difieren, pero el principio duradero es el mismo. La capacidad y el permiso deben gobernarse de forma independiente.
3. ¿Se da con conocimiento de causa la aprobación que se requiera?
Antes de aprobar el reinicio, la persona que opera el sistema debería ver:
- La evidencia que respalda el diagnóstico.
- La acción exacta que se propone.
- Los sistemas y usuarios que pueden verse afectados.
- La señal de recuperación esperada.
- La reversión o la respuesta alternativa.
- Las condiciones que determinan el éxito o el fracaso.
Si esa persona no puede entender esos puntos, la aprobación se convierte en un ritual. Un botón no crea un control humano real cuando quien lo pulsa carece de la evidencia, el tiempo o la autoridad para juzgar la acción.
El OWASP Top 10 for Agentic Applications 2026 ofrece una advertencia de seguridad más amplia sobre la agencia excesiva (excessive agency).[7] La lección práctica para las operaciones es sencilla. Las herramientas de alto impacto necesitan límites de permisos más estrictos que las herramientas de investigación de bajo riesgo.
4. ¿Se puede verificar el resultado?
Ejecutar un comando no es el final de una acción operativa. El sistema debe confirmar si las tasas de error bajaron, el tráfico se recuperó, las dependencias se estabilizaron y el impacto en los clientes terminó.
Si no se puede confirmar la recuperación, el agente debe revertir el cambio cuando sea posible o escalar el caso con la evidencia que haya recopilado. Sin ese ciclo, un agente puede confundir la ejecución correcta de un comando con la resolución correcta de un incidente.
La aprobación humana no siempre es la respuesta más segura
Es tentador resolver cada riesgo de AgenticOps exigiendo que una persona apruebe cada acción. No creo que eso sea sostenible.
Durante una interrupción que evoluciona deprisa, una solicitud de aprobación puede quedarse sin respuesta. Una persona ingeniera agotada puede aprobarla sin revisar la evidencia. Exigir confirmación humana para cientos de acciones de bajo riesgo puede generar fatiga de alertas y reducir la calidad de la supervisión allí donde realmente importa.
En algunos entornos, la autonomía acotada puede ser más segura que una intervención humana tardía. Reiniciar un worker sin estado, escalar un nivel de servicio predefinido o pausar un despliegue defectuoso puede ser apropiado cuando la acción es repetible, observable y reversible.
El objetivo no es introducir a una persona en cada ruta de ejecución. Es ajustar la autoridad a la acción.
| Delega antes cuando la acción es | Mantén la aprobación explícita cuando la acción afecta a |
|---|---|
| Repetible y bien entendida | La identidad o el control de acceso |
| De radio de impacto reducido | El firewall y la política de seguridad de red |
| Observable antes y después de la ejecución | Bases de datos de producción o datos persistentes |
| Reversible mediante una vía probada | Operaciones de almacenamiento destructivas |
| Segura de repetir sin agravar el daño | Infraestructura compartida sin un responsable claro |
| Cubierta por políticas y registros de auditoría completos | Sistemas regulados o sensibles en materia de cumplimiento normativo |
Es un punto de partida, no una lista universal de permisos. La misma acción puede conllevar un riesgo distinto en sistemas distintos.
La autoridad del agente no elimina la autoridad humana
Un agente puede recibir permisos. No puede asumir la rendición de cuentas de la organización.
Alguien debe decidir qué fuentes de evidencia son de confianza, qué herramientas están disponibles, qué entornos pueden modificarse y qué fallos requieren escalado. Una persona concreta, responsable del servicio, sigue respondiendo de la política, incluso cuando el agente opera correctamente dentro de ella.
El reparto debe ser explícito. El agente trabaja dentro del límite de tarea que se le asigna: recopila evidencias, explica su razonamiento, elige entre las acciones permitidas e informa del resultado. La autoridad humana crea ese límite, aprueba las excepciones de alto impacto, revisa los fallos y decide si los permisos deben ampliarse, mantenerse o reducirse.
Por eso «una persona en el circuito» (human in the loop) es una idea demasiado vaga para servir como modelo de gobernanza. La pregunta importante no es si aparece una persona en algún punto del flujo de trabajo. Es qué decisiones siguen siendo decisiones humanas.
Resolver más rápido no lo es todo en la evaluación
Reducir el tiempo medio de resolución es útil, pero el MTTR no es una medida de confianza.
Un sistema puede reducir el tiempo de resolución actuando de forma agresiva, escalando menos casos o dando por recuperado el servicio antes de que se haya eliminado el problema de fondo. Un incidente puede cerrarse rápidamente y volver una hora después.
| Medida | Lo que revela |
|---|---|
| Tiempo hasta obtener evidencia útil | Si el agente acelera la investigación |
| Tasa de aceptación de recomendaciones | Si los equipos de ingeniería consideran útiles sus conclusiones |
| Calidad de la abstención | Si reconoce cuándo la evidencia es insuficiente |
| Tasa de anulación humana | Con qué frecuencia los equipos de operaciones rechazan o interrumpen sus decisiones |
| Tasa de éxito de las reversiones | Si las acciones fallidas pueden recuperarse de forma segura |
| Recurrencia de incidentes | Si la acción corrigió la causa o solo el síntoma |
| Tasa de infracción de políticas | Si el agente se mantuvo dentro de su autoridad |
| Completitud de la auditoría | Si quienes investigan pueden reconstruir lo ocurrido |
Un buen piloto debería mejorar la velocidad sin debilitar estas medidas de seguridad y calidad.
Por dónde deberían empezar los equipos
El punto de partida más seguro no es la remediación autónoma. Es la comprensión operativa.
Deja primero que los agentes observen. Dales acceso a telemetría aprobada, registros de despliegue, historial de incidentes y documentación de servicios. Mide si recuperan la evidencia correcta y si sus resúmenes son precisos.
Después, permíteles investigar y recomendar. Compara sus conclusiones con las de profesionales de ingeniería con experiencia. Registra cuándo acierta el agente, cuándo se abstiene y cuándo produce una explicación segura de sí misma pero incompleta.
La acción aprobada solo debería llegar cuando el proceso de recomendación se haya vuelto fiable. Incluso entonces, empieza con cambios acotados y reversibles, y exige al sistema que indique el resultado esperado antes de la ejecución.
La autonomía acotada debe ganarse por clase de acción. No debe concederse de forma amplia porque un modelo haya funcionado bien en otra tarea.
Un agente que reinicia de forma fiable workers sin estado no ha demostrado que pueda modificar la política del firewall. Un agente que revisa despliegues no se ha ganado el permiso para cambiar esquemas de bases de datos. La autoridad debe ampliarse a partir de evidencia específica, no de una confianza general en la tecnología.
La confianza se gana decisión acotada a decisión acotada
Volvamos una vez más al reinicio del servicio que se propuso.
Puede permitirse al agente ejecutarlo sin esperar a que intervenga alguien de ingeniería, pero solo si la organización ya ha determinado que esta clase de reinicio está permitida y es reversible y verificable. El agente no debe inventarse esa autoridad durante el incidente.
Si las dependencias no están claras, el radio de impacto es incierto o la recuperación no puede medirse, la acción correcta puede ser recomendar y escalar. Eso no es un fracaso de AgenticOps. Saber cuándo no actuar forma parte de la competencia operativa.
El mercado avanza deprisa, y los agentes operativos recibirán más autoridad a medida que mejoren sus capacidades. Las organizaciones que más se beneficien no serán las que eliminen antes los puntos de aprobación. Serán las que entiendan por qué existe cada punto de aprobación, cuándo puede eliminarse con seguridad y cómo detectarán los fallos los controles que queden.
AgenticOps no consiste en sacar a las personas de las operaciones. Consiste en decidir con cuidado y de forma explícita qué decisiones puede tomar un agente, cuáles requieren aprobación y cuáles deben seguir siendo humanas.
Referencias y lecturas adicionales
Fuentes y documentación revisadas el 28 de septiembre de 2026. El incidente inicial es un escenario ilustrativo, no el informe de la interrupción de un cliente concreto.
- The Impact of Agentic AI on Network Operations, Cisco y Omdia, 2026. Informe de investigación que encuestó a más de 1000 responsables de NetOps de Norteamérica, Europa Occidental y Asia-Pacífico sobre adopción, acciones autónomas y demanda de salvaguardas. ↩
- NetOps Is Already Deploying Autonomy. Trust Will Decide How Far It Goes, Cisco, septiembre de 2026. Análisis operativo de Cisco sobre los resultados de la encuesta y los requisitos de confianza en torno a las acciones autónomas en la red. ↩
- AWS DevOps Agent Security, AWS, revisado el 28 de septiembre de 2026. Documentación oficial sobre Agent Spaces, aislamiento de identidades, tratamiento de datos operativos, journals y registros de auditoría.
- Limiting Agent Access in an AWS Account, AWS, revisado el 28 de septiembre de 2026. Guía técnica sobre roles de IAM, salvaguardas de permisos y controles de acceso efectivos.
- Run Modes in Azure SRE Agent, Microsoft, revisado el 28 de septiembre de 2026. Documentación de arquitectura que muestra la separación entre los permisos sobre recursos y los modos de ejecución Review y Autonomous.
- How Google SREs Use Gemini CLI to Solve Real-World Outages, Google Cloud, enero de 2026. Recorrido práctico que muestra la recuperación de evidencias, la mitigación mediante un conjunto cerrado de playbooks, la aprobación humana y la verificación del resultado.
- OWASP Top 10 for Agentic Applications 2026, OWASP GenAI Security Project, diciembre de 2025. Guía de seguridad que detalla la agencia excesiva y la necesidad de límites estrictos de privilegios operativos. ↩
- AI Risk Management Framework (AI RMF 1.0), NIST, revisado el 28 de septiembre de 2026. Norma federal de referencia para gestionar los riesgos de los sistemas de inteligencia artificial.