Cattle, no pets: por qué la IA agéntica obliga a repensar la infraestructura en Azure

El artículo, publicado por PwC dentro de su alianza con Microsoft, retoma una metáfora clásica de la infraestructura en la nube —tratar los servidores como 'ganado' (cattle) reemplazable y no como 'mascotas' (pets) que se cuidan individualmente— para argumentar que la llegada de la IA agéntica convierte esa vieja recomendación, largamente ignorada, en una necesidad urgente. Durante años, según el autor, muchas organizaciones adoptaron el vocabulario de 'cattle' pero conservaron el apego emocional y las prácticas informales propias de las 'pets': máquinas virtuales con nombres propios que nadie se atreve a tocar un viernes, configuraciones únicas que solo existen en la memoria de un ingeniero, repositorios de Infraestructura-como-Código abandonados en cuanto alguien 'arregla algo rápido' manualmente desde el portal, permisos de Entra que sobreviven a su propósito original, o aprobaciones que ocurren en un chat de Teams en lugar de en un pipeline auditable.

Esas prácticas eran costosas pero tolerables cuando quien operaba el entorno era una persona con contexto tribal. El problema, plantea el texto, es que los sistemas agénticos —agentes de Copilot, flujos de Microsoft Foundry, pipelines autónomos— no tienen forma de 'saber' que un servidor llamado SQLPROD03 es especial o que 'el equipo de red siempre lo hace así'. Un agente lee políticas y capacidad disponible, y actúa en consecuencia; si el entorno depende de excepciones no documentadas, el agente puede fallar contra ellas o comportarse de forma no prevista por la organización.

De ahí la propuesta central del artículo: la 'infraestructura lista para agentes' (agent-ready infrastructure) implica entornos aprovisionados, gobernados y retirados mediante código, con identidad, observabilidad y control de costes integrados desde el diseño, no como añadidos posteriores. Esto transforma lo que antes era una conversación puramente operativa (automatización, orquestación, capacidad elástica) en una conversación de gobernanza que exige un modelo operativo explícito.

Para ordenar ese modelo, el artículo propone tres niveles de autonomía definidos por el riesgo y no por el tipo de tarea: autonomía preautorizada (escalar dentro de límites ya aprobados, reiniciar un servicio caído, corregir una desviación conocida respecto a una política base de Azure Policy); autonomía supervisada (aprovisionar nuevos tipos de recursos o modificar la topología de red, pero pasando por una puerta de aprobación en Azure DevOps o GitHub Advanced Security, con registro de auditoría en Microsoft Purview y accesos acotados en el tiempo mediante Entra Privileged Identity Management); y autonomía sujeta a aprobación (cualquier acción que toque límites de identidad, planos de datos de producción o cargas reguladas, donde un humano debe aprobar antes de ejecutar, no después de leer el informe del incidente). La idea clave es que ese nivel de autonomía debe quedar codificado en la política antes de que el agente actúe, no decidirse sobre la marcha, y que además debe tener en cuenta el contexto operativo (una acción rutinaria un día cualquiera puede ser crítica durante un incidente o una ventana de tráfico pico).

Como ejemplo concreto de esta dirección, el artículo cita el Azure SRE Agent de Microsoft, ya disponible con carácter general, capaz de investigar incidentes de producción, proponer mitigaciones y automatizar respuestas dentro de barreras de control y flujos de aprobación definidos por cada organización. Lo presenta como una señal de hacia dónde va la operación en Azure: agentes que trabajan dentro de controles definidos y niveles de autonomía configurables, no una sustitución total de la supervisión humana.

El texto también matiza el argumento habitual de 'ir más allá de las máquinas virtuales' hacia arquitecturas cloud-native. Reconoce que las VM no van a desaparecer —siguen siendo apropiadas para dependencias a nivel de sistema operativo, cargas sujetas a cumplimiento normativo o sistemas que aún no están listos para lo cloud-native— y aclara que el debate no es 'VM sí o VM no', sino 'mascota contra ganado' aplicado a todo el estado tecnológico: la VM, el contenedor, la función serverless, la identidad, la ruta de red y la política que los gobierna en conjunto. Un workload cloud-native migrado a mano, con excepciones no documentadas y modificado por quien esté de guardia, sigue siendo una 'mascota', solo que una de moda. Lo que añade la IA agéntica a ese argumento es un requisito nuevo: el entorno debe ser legible para una máquina, y un entorno gobernado por políticas explícitas resulta más legible que uno construido sobre excepciones manuales.

En términos prácticos, el artículo enumera el trabajo concreto necesario para llegar a ese estado 'agent-ready': cobertura de Infraestructura-como-Código en todo el estado relevante (incluidas las excepciones que hoy se gestionan a mano); identidades de agente delimitadas y con caducidad a través de Microsoft Entra, de forma que cada acción sea atribuible a una identidad específica y revocable, no a credenciales compartidas; políticas como código que abarquen cómputo, identidad, red y seguridad de forma conjunta en Azure Policy y Entra; observabilidad y auditoría que permitan reconstruir qué hizo un agente, qué accedió y por qué; rutas definidas de reversión para acciones autónomas, proporcionales a su riesgo e impacto; controles de FinOps que limiten cuánto puede gastar un escalado autónomo, no solo qué puede tocar; y, de nuevo, un modelo de autonomía escalonado, definido de antemano y aplicado mediante Entra PIM, puertas de aprobación en Azure DevOps y trazas de auditoría en Purview.

El artículo cierra situando esta discusión dentro de un desafío mayor: cita una encuesta de PwC según la cual el 45% de los CEOs consultados no cree que sus empresas sigan siendo viables dentro de diez años si continúan por su trayectoria actual. La conclusión del autor es que la oportunidad no es la autonomía por sí misma, sino construir una base operativa que permita delegar en la IA más trabajo repetitivo dentro de controles definidos, liberando a los ingenieros con experiencia para problemas de mayor valor. El límite, sugiere, ya no está tanto en la capacidad de los agentes de IA como en si el entorno que los rodea está preparado para que operen dentro de fronteras claras de política, acceso y supervisión humana.

Conviene señalar que se trata de contenido de PwC ligado a su alianza tecnológica con Microsoft y orientado a promover servicios de evaluación y modernización de infraestructura en Azure, por lo que combina un diagnóstico técnico razonable con un fin comercial explícito (incluye una llamada a contratar una 'evaluación de preparación de Azure' de PwC). Aun así, el diagnóstico de fondo —que la deuda técnica y las excepciones no documentadas, tolerables con operadores humanos, se convierten en puntos de fallo cuando actúan agentes autónomos— es coherente con preocupaciones más amplias que está planteando el sector sobre gobernanza de agentes de IA en entornos empresariales.