Un desarrollador lo perdió todo. Tenían plantillas de Terraform. Tenían la infraestructura definida en código. Lo que no tenían era detección de derivas, reproducibilidad entre regiones, pipelines de despliegue probados ni un proceso de recuperación ante desastres que alguien hubiera ejecutado realmente. Su IaC era una instantánea de la intención, no una capacidad operativa.

Otro equipo se recuperó en cuestión de horas. También tenían Terraform. Pero tenían otra cosa: operaciones sin deriva, pipelines de despliegue automatizados que se habían probado contra escenarios de fallo e infraestructuras que podían ser redesplegadas en una región alternativa porque el código y las prácticas operativas que lo rodeaban se trataban como un solo sistema.

La misma herramienta, resultados radicalmente diferentes. Lo que los diferenciaba era todo lo relacionado con el código: las prácticas operativas, las pruebas, la disciplina.

Esta es la idea errónea que quiero abordar: la creencia generalizada de que adoptar Infraestructura como Código significa que has adoptado DevOps. No es así. IaC es un requisito previo. No es el destino.

Falacia de la línea de meta

A lo largo de cientos de interacciones en la nube, destaca una dinámica recurrente: organizaciones que tratan la adopción de IaC como la culminación de su camino DevOps en lugar de como el principio.

La progresión suele ser así. Un equipo pasa de la provisión manual a la provisión por script. Luego, de scripts a plantillas declarativas: Terraform, ARM, Biceps, CloudFormation, CDK, Pulumi. Las plantillas van a un repositorio. Alguien escribe un README. La dirección declara que la infraestructura está «codificada».

Y entonces nada más cambia.

El proceso de despliegue de esas plantillas sigue siendo manual o semi-manual. No existe un pipeline que valide, planifique y aplique cambios de infraestructura a través de los entornos. No hay detección de deriva que detectar cuando alguien hace un cambio de consola que se desvíe del estado declarado. No hay pruebas, ni siquiera básicas, que verifiquen que las plantillas produzcan lo que afirman. No existen manuales operativos que conecten la IAC con la respuesta a incidentes, los procedimientos de escalado o la recuperación ante desastres.

La organización tiene aprovisionamiento automatizado, pero no dispone de DevOps.

Este es un primo cercano del problema que describí sobre por qué las migraciones a la nube tienen éxito mientras que las operaciones en la nube fracasan. La IaC suele ser un artefacto de migración: se crea durante el paso a la nube y luego se trata como un producto terminado en lugar de la base de una capacidad operativa continua. El equipo de migración redacta las plantillas, declara la victoria y se disuelve. El equipo de operaciones hereda código que no escribieron, envuelto en prácticas en las que nunca se les formó.

La distinción importa porque el valor de IaC no está en las plantillas en sí. El valor está en lo que permiten esas plantillas: despliegues repetibles, consistencia del entorno, cambios auditables, recuperación rápida y confianza operativa. Sin las prácticas que extraigan ese valor, IaC es una mejor forma de crear infraestructura una vez. Eso es útil, pero es una fracción de la promesa.

Cómo es realmente la IaC sin prácticas operativas

Los síntomas son predecibles. He trabajado con equipos que exponen cada uno de estos modelos, a veces todos a la vez.

Deriva como estado predeterminado. Las plantillas dicen una cosa. La infraestructura real dice otro. Alguien hizo un cambio de consola durante un incidente y nunca actualizó el código. Alguien más modificó un grupo de seguridad para una demo y se olvidó de ella. Con el paso de semanas y meses, la brecha entre el estado declarado y el estado real se amplía hasta que las plantillas son documentación de lo que se pretendía, no de lo que existe.

Esto no es una molestia menor. Cuando el incidente de AWS en Baréin obligó a los equipos a reubicarse en regiones alternativas, los que tenían deriva descubrieron que su «infraestructura reproducible» no era reproducible. Las plantillas describían un entorno que ya no coincidía con la realidad. Redesplegar desde esas plantillas significaba volver a desplegar una versión de la infraestructura que quizá no funcionara, porque los cambios no documentados eran los que mantenían la producción en marcha.

Pipelines que se detienen en provisiones. Muchos equipos construyen una pipeline que ejecuta terraform apply o cdk deploy. Ese oleoducto suministra infraestructura. Pero el aprovisionamiento es un paso más en un ciclo de vida operativo mucho más largo. ¿Qué ocurre cuando necesitas retroceder? ¿Qué ocurre cuando un cambio rompe un servicio posterior? ¿Qué ocurre cuando necesitas promover un cambio de escenografía a producción con la confianza de que los entornos son realmente equivalentes?

Sin pipelines de despliegue que incluyan validación, puertas de aprobación, pruebas automatizadas y capacidades de rollback, la pipeline IaC es una calle de sentido único. Puede crear. Le cuesta recuperarse.

El problema del autor único. En demasiadas organizaciones, el IaC fue escrito por una sola persona o un pequeño equipo, y nadie más lo entiende lo suficiente como para modificarlo de forma segura. Las plantillas se convierten en una caja negra de la que depende el resto de la organización de ingeniería pero no puede mantener. Cuando esa persona se va, o cuando se necesita un cambio urgente a las 2 de la madrugada, la organización descubre que «infraestructura como código» no significa «infraestructura que cualquiera pueda operar».

Esto es el equivalente en IaC al problema de conocimiento tribal que DevOps se suponía que debía eliminar. El conocimiento simplemente pasó de «cómo configurar el servidor» a «cómo leer y modificar los módulos de Terraform».

No hay relación con la respuesta a incidentes. Cuando ocurre un incidente, la primera pregunta debería ser: ¿qué ha cambiado? Si la tubería IaC es la única vía para cambios en la infraestructura, la respuesta está en la pista de auditoría de la canalización. Pero si los cambios en la consola ocurren junto con los cambios en IaC, si se tolera la deriva, si la pipeline no obliga a que todos los cambios fluyan por código, entonces la pista de auditoría queda incompleta. La respuesta a incidentes se convierte en arqueología en lugar de investigación.

El oleoducto es producción

Uno de los hilos de Reddit que llamó mi atención tras el ataque a la cadena de suministro de Axios npm en marzo de 2026 tenía una conclusión sencilla: «tratar CI/CD como producción.»

El ataque comprometió la cuenta npm de un mantenedor y publicó versiones maliciosas de Axios, una de las bibliotecas JavaScript más usadas, con una dependencia oculta que desplegaba un troyano de acceso remoto. Los atacantes evitaron por completo la cadena de GitHub Actions del proyecto, publicando directamente a través de la CLI npm con credenciales robadas.

La lección para IaC es directa. Tu pipeline de despliegue es un sistema de producción. Tiene su propia superficie de ataque, sus propios modos de fallo, sus propios requisitos operativos. Gestión de secretos, fijación de dependencias, controles de acceso, registro de auditorías: estos son lo mínimo para una pipeline madura, no funciones opcionales.

Las organizaciones que tratan IaC como la línea de meta rara vez invierten en seguridad de oleoductos porque ven la tubería como una herramienta, no como infraestructura. Pero el oleoducto es el mecanismo por el que fluyen todos los cambios de infraestructura. Si se ve comprometida, todo lo que toca está comprometido. Si es poco fiable, cada despliegue es poco fiable.

Esto se conecta con un argumento más amplio. Recientemente escribí sobre el teatro DevOps: la interpretación de las prácticas modernas de ingeniería sin la transformación subyacente. La IAC sin prácticas operativas es un caso específico de ese teatro. El artefacto existe, pero la capacidad no.

Las seis prácticas que convierten IaC en DevOps

IaC se convierte en una capacidad DevOps cuando está rodeada de prácticas que lo hacen operativo, no solo provisionamiento. No son aspiracionales. Son el mínimo para las organizaciones que quieren afirmar que su infraestructura está realmente gestionada como código.

1. Detección y control de deriva

Si no puedes detectar cuándo la infraestructura real se desvía del estado declarado, tu IaC es un deseo, no un contrato. La detección de deriva debe ejecutarse de forma continua, no como una auditoría ocasional. Cuando se detecta deriva, la respuesta debe ser o bien reconciliar (actualizar el código para que coincida con la realidad) o remediar (forzar la realidad a que coincida con el código). Tolerar la deriva es tolerar la erosión de todo lo que se supone que debe proporcionar el IaC.

2. Canalizaciones de despliegue con validación y retroceso

Cada cambio de infraestructura debe fluir a través de una tubería que incluya: planificación/vista previa (qué cambiará), validación (si pasa las comprobaciones de políticas), aprobación (para cambios en producción), aplicación y verificación (si el cambio produjo el resultado esperado). El rollback debe ser una capacidad probada, no teórica. Si nunca has revertido un cambio de infraestructura a través de tu pipeline, no tienes capacidad de rollback. Tienes la esperanza de retroceder.

3. Pruebas

El código de infraestructura es código. Debería ser probado. Como mínimo: validación de sintaxis, comprobaciones de cumplimiento de políticas (¿están abiertos los grupos de seguridad? ¿son correctas las configuraciones de cifrado? ¿se cumplen los estándares de etiquetado?) y pruebas de integración que verifiquen que la infraestructura realmente funciona tras el despliegue. Existen herramientas para esto. La barrera es cultural, no técnica: la creencia de que las plantillas de infraestructura no necesitan el mismo rigor que el código de aplicación.

4. Guías operativas relacionadas con IaC

Cuando ocurre un incidente, el libro de procedimientos debe consultar el IaC. «Para escalar la base de datos, modifica el parámetro X en el módulo Y ejecuta la canalización.» «Para hacer el failover a la región DR, activa el flujo de trabajo Z.» Si los libros de ejecución describen los pasos manuales de la consola mientras la infraestructura supuestamente se gestiona como código, los dos sistemas se desconectan. El libro de reglas ganará siempre, porque es lo que la gente sigue bajo presión.

5. Propiedad y conocimiento compartidos

Si solo una persona o un equipo puede modificar el código de infraestructura, tienes un único punto de fallo disfrazado de automatización. IaC debe ser legible, documentado y modificable por los equipos que dependen de él. Esto implica diseño modular, convenciones claras de nombres, decisiones documentadas y un intercambio regular de conocimientos. El objetivo no es que todo el mundo se convierta en experto en IaC. El objetivo es que nadie se vea bloqueado por la ausencia de una sola persona.

6. Gobernanza automatizada

Las comprobaciones de políticas deben ejecutarse en la tubería antes de aplicar las plantillas. Estándares de etiquetado, requisitos de cifrado, reglas de segmentación de red, gestión de secretos: todo validado automáticamente. Si una plantilla viola una política, la tubería falla. Sin excepciones, sin aprobaciones manuales que se conviertan en sellos de goma.

Esto incluye mantener las credenciales fuera de las plantillas. Parece obvio, y sin embargo me encuentro regularmente con repositorios donde las claves de API, las contraseñas de bases de datos y las credenciales de cuentas de servicio están codificadas en variables plantilla o se pasan como parámetros de texto plano. La IAC sin una gestión secreta adecuada no es solo una brecha operativa; Es una vulnerabilidad de seguridad.

Donde el desarrollo impulsado por IA cambia la ecuación

Existe una dimensión emergente en este problema que la mayoría de las organizaciones aún no han afrontado. A medida que las herramientas de codificación con IA se convierten en estándar en los flujos de trabajo de desarrollo, el volumen de código de infraestructura está aumentando. Los agentes de IA pueden generar módulos de Terraform, plantillas de CloudFormation y construcciones CDK más rápido que cualquier equipo humano. El problema de aprovisionamiento se está resolviendo a una velocidad acelerada.

Pero las prácticas operativas en torno a ese código no están siguiendo el ritmo. Si acaso, la brecha se está ampliando. Se generaron más plantillas más rápido, con los mismos procesos manuales de despliegue, la misma ausencia de detección de derivas, las mismas tuberías sin probar. Un comentarista en un hilo sobre la deuda tecnológica de ingeniería agente lo expresó con precisión: los equipos están «automatizando la capa de demo más rápido que la capa de ingeniería.»

Esta es la versión IaC de una dinámica sobre la que he escrito en el contexto del desarrollo impulsado por IA: la velocidad de generación de código supera la madurez de las prácticas que la rigen. Ralentizar la generación de código no es el punto. Las prácticas operativas deben acelerarse para ajustarse. Los enfoques estructurados para el desarrollo impulsado por IA abordan esto en el código de aplicaciones. La misma disciplina debe extenderse al código de infraestructuras.

La pregunta después de IaC

Alguien en un subreddit de Azure preguntó recientemente: «¿Cómo puedo empezar IaC en Azure?» La propia pregunta revela el malentendido. Empezar IaC no es el reto. El reto es lo que viene después.

Después de tener plantillas en un repositorio, ¿tienes una pipeline que las despliegue de forma segura? Después de tener una pipeline, ¿tienes detección de deriva que mantenga la realidad alineada con el código? Después de tener detección de deriva, ¿tienes libros de procedimientos que conecten tus procedimientos operativos con el código? Después de tener los libros de runas, ¿tienes propiedad compartida para que el sistema no dependa de una sola persona?

Cada uno de estos pasos se basa en el anterior. Si te saltas alguno de ellos, tendrás un hueco que aparecerá durante el incidente que menos esperes.

Las organizaciones que se recuperaron de las interrupciones de la infraestructura del Golfo en horas, no en días, no fueron las que contaron con los módulos Terraform más sofisticados. Fueron ellos quienes construyeron toda la pila operativa alrededor de su IaC: pipelines, pruebas, detección de derivas, runbooks, conocimiento compartido y la disciplina para hacer cumplir que todos los cambios fluyan a través del sistema.

IaC les dio la base. Las prácticas les dieron la capacidad. La capacidad fue lo que les salvó.

Si tu organización ha adoptado Infraestructura como Código pero no ha invertido en las prácticas que lo hacen operativo, has completado el primer paso de un proceso más largo. La cuestión es si completarás el resto antes del incidente que revela la brecha.

Ricardo