Cuando un agente de IA se convierte en su SRE, los permisos pasan a ser ingeniería de fiabilidad

Un asistente de chat que se equivoca hace perder unos minutos. Un agente de operaciones que toma una acción equivocada durante un incidente puede convertir una caída parcial en una total. Por eso las decisiones más importantes al diseñar agentes de operaciones no tienen que ver con el modelo. Tienen que ver con lo que el agente puede leer, lo que puede proponer y lo que puede hacer.

AWS tiene dos agentes que lo hacen concreto. AWS DevOps Agent, con disponibilidad general desde marzo de 2026 y con su referencia de API actualizada el 2 de octubre, funciona como un compañero de operaciones siempre disponible. AWS Well-Architected Agent, anunciado en versión preliminar el 1 de octubre, lleva la revisión de arquitectura al mismo modelo.

Qué hace cada agente

AWS describe DevOps Agent como un agente que resuelve y previene incidentes, optimiza la fiabilidad y el rendimiento y ejecuta tareas de SRE bajo demanda en AWS, en otras nubes y en entornos locales. Trabaja con herramientas de observabilidad, runbooks, repositorios de código y pipelines de CI/CD, y cruza telemetría, código y datos de despliegue. Las integraciones incluyen GitHub, GitLab, Dynatrace, Datadog, New Relic, Splunk, ServiceNow y servidores MCP.

Well-Architected Agent es la evolución, con IA, de Trusted Advisor y de la Well-Architected Tool. Lee configuraciones, métricas de uso y topología de aplicaciones mediante roles de IAM gestionados por el cliente, las contrasta con las prácticas de Well-Architected en más de 65 servicios y prioriza los hallazgos según los objetivos de negocio que declara el cliente. También revisa proyectos de Terraform, CloudFormation y CDK antes del despliegue. Cada hallazgo llega con un paquete de implementación: runbooks de SSM, scripts de CLI o pasos guiados en la consola. La versión preliminar funciona en US East (N. Virginia), US East (Ohio) y US West (Oregon), admite cargas de cualquier región comercial y exige un plan de AWS Support.

Los límites que eligió AWS

Si se lee el registro de cambios de DevOps Agent de los últimos meses, aparece un modelo de permisos claro:

• Leer es lo predeterminado. Las acciones de lectura vienen habilitadas. Las acciones dirigidas que crean o modifican recursos vienen deshabilitadas y hay que activarlas de forma explícita, con una política gestionada y en las preferencias del Agent Space.
• Propuesta antes que acción. Cuando una alarma lanza una investigación, el agente presenta propuestas de mitigación que un operador revisa y ajusta antes de aplicarlas.
• Cada aprobación tiene nombre. Según AWS, cada aprobación y cada acción quedan atribuidas al operador que aprobó, en AWS CloudTrail.
• El código se ejecuta aislado. El código de investigación corre en una microVM aislada por investigación, con llamadas a AWS limitadas a lectura.
• El acceso de escritura al código lo decide el cliente. La GitHub App propia puede crearse con acceso de solo lectura o de lectura y escritura.

Well-Architected Agent va todavía más lejos hacia lo conservador: no cambia nada por su cuenta. El cliente elige cómo corregir y lo ejecuta.

1. Leer telemetría, código y despliegues
2. Investigar y correlacionar
3. Proponer mitigación o corrección
4. El operador aprueba
5. Acción dirigida, si está activada
6. Registro en CloudTrail

• Activo por defecto: Leer telemetría, código y despliegues · Investigar y correlacionar · Proponer mitigación o corrección
• Opcional y trazable: El operador aprueba · Acción dirigida, si está activada · Registro en CloudTrail

Autonomía del agenteAutoridad humana y evidencia

Por qué los permisos son ahora una decisión de fiabilidad

En la práctica clásica de SRE, la fiabilidad viene de limitar el radio de impacto: cambios pequeños, despliegues graduales, rollback rápido. Un agente de operaciones es una nueva fuente de cambios, así que la misma disciplina se le aplica:

Delimite al agente como una cuenta de servicio, no como un ingeniero sénior. El Agent Space define qué cuentas y recursos ve el agente. Empiece por poco. Es el mismo diseño de la autonomía con límites que vimos en el SOC agéntico: autonomía para leer, autoridad para escribir.

Dele al agente una identidad propia. Si sus acciones se ejecutan con un rol de administración compartido, nadie podrá distinguir después lo que hizo el agente de lo que hizo una persona. Es el argumento para tratar la identidad de los agentes como una disciplina propia de IAM.

Trate las mitigaciones aplicadas por el agente como cambios. En España, una entidad financiera sujeta a DORA tiene que gestionar y documentar sus incidentes relacionados con las TIC; si un agente investiga y mitiga, sus pasos forman parte de ese expediente. El diario del agente, que AWS describe como inmutable, ayuda; el ticket y la revisión posterior al incidente siguen siendo necesarios.

Sepa dónde van los datos. Los datos del Agent Space (investigaciones, topología, recomendaciones) se guardan en la región donde se crea. La documentación de seguridad de AWS precisa además que, para Agent Spaces en regiones de la UE como Frankfurt o Irlanda, la inferencia solo se enruta a otras regiones de la UE; Londres queda fuera de esa frontera. Para Latinoamérica el panorama es distinto: la región más cercana con el agente es São Paulo, y desde allí la inferencia se enruta de forma global. Una empresa mexicana, colombiana o chilena que conecte logs con datos personales tiene que evaluar esa transferencia internacional con su propia ley de protección de datos. La misma documentación advierte de que el agente no filtra datos personales al resumir logs, así que el enmascaramiento tiene que ocurrir antes.

Qué cambia en la revisión de arquitectura

Las revisiones Well-Architected solían ser cuestionarios periódicos. Un agente que lee la configuración real y el IaC las convierte en algo parecido a una revisión continua: la desviación se ve cuando ocurre, no en la siguiente sesión trimestral. La responsabilidad, sin embargo, no se mueve. El agente recomienda y empaqueta la corrección; el arquitecto decide, y el cambio pasa por el pipeline como cualquier otro, idealmente con la revisión de IaC detectando el problema antes del despliegue, igual que los agentes de Google dentro de la revisión de código. Durante la versión preliminar, el análisis se ejecuta en regiones de Estados Unidos aunque la carga esté en Europa, algo que conviene revisar con protección de datos.

Qué hacer ahora

1. Escriba la escalera de permisos antes de activar nada: leer, proponer, actuar con aprobación, actuar solo. Asigne cada tipo de acción a un peldaño.
2. Mantenga desactivadas las acciones dirigidas hasta tener un playbook que diga qué mitigaciones puede ejecutar el agente y quién las aprueba.
3. Cree un rol dedicado por Agent Space limitado a las cuentas que necesita.
4. Elija la región del Agent Space por su enrutamiento de inferencia, no solo por cercanía, y enmascare los datos personales en origen.
5. Lleve las propuestas del agente al proceso de cambios, para que una mitigación aprobada tenga su ticket.
6. Mida la ayuda: tiempo hasta la primera hipótesis útil, proporción de propuestas aceptadas, propuestas que habrían empeorado la situación.

En resumen

Los agentes de operaciones de AWS muestran un punto de partida sensato: leer con libertad, proponer con generosidad y actuar solo con un permiso explícito y un aprobador con nombre. Conviene adoptarlo como política de empresa y no solo como ajuste de producto, porque el próximo agente de operaciones que llegue puede no venir con la misma prudencia.