¿Qué es IaC?
Entrega, operaciones e infraestructura de IA
IaC significa Infraestructura como Código (Infrastructure as Code). Es la práctica de definir la infraestructura y su configuración en archivos versionados y revisables, en lugar de depender principalmente de la configuración manual en consolas y pantallas de administración. Esos archivos describen los recursos, ajustes, políticas y relaciones que debe tener un entorno; las herramientas comparan ese estado deseado con el entorno real y aplican los cambios aprobados. Bien implementado, IaC hace que la infraestructura sea más reproducible, más fácil de revisar, más fácil de reconstruir y más fácil de gobernar con el tiempo.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Una forma sencilla de entender IaC es compararlo con el "ClickOps", donde un administrador crea redes, permisos, almacenamiento, pasarelas y configuraciones manualmente a través de interfaces web. El trabajo manual a veces es inevitable, pero es difícil de revisar a posteriori, difícil de recrear de forma consistente y fácil de olvidar cuando llega una interrupción del servicio, una pregunta de auditoría o un cambio de personal.
Con IaC, la configuración prevista vive en código o en archivos estructurados. Un equipo puede revisar el cambio en una solicitud de incorporación de cambios (pull request), ejecutar comprobaciones, aprobarlo y luego aplicarlo mediante un flujo de trabajo definido. Si el entorno de pruebas necesita reflejar fielmente el de producción, IaC lo hace más viable. Si un entorno se daña o simplemente se vuelve desordenado, IaC proporciona al equipo una línea base desde la que recuperarse.
Las organizaciones pequeñas y medianas no necesitan codificarlo todo. Por lo general, obtienen mayor beneficio al codificar la infraestructura que sustenta los servicios importantes: redes, identidades, registros, políticas de almacenamiento, pasarelas y entornos principales.
Por qué es importante
IaC importa porque las decisiones sobre infraestructura son decisiones de negocio en cuanto los servicios en producción dependen de ellas. Si el portal de clientes, la plataforma de analítica interna, el almacén de documentos o el endpoint de servicio de modelos depende de recursos en la nube configurados de memoria y con capturas de pantalla, existe un problema de fragilidad operativa.
Los cambios de infraestructura versionados mejoran la reproducibilidad y la trazabilidad. Las solicitudes de incorporación de cambios revisables facilitan detectar permisos arriesgados, endpoints expuestos, registros ausentes o recursos costosos antes de que lleguen a producción. La consistencia entre entornos también importa. Los equipos suelen querer que el entorno de pruebas se comporte como el de producción, pero la configuración manual diverge rápidamente. IaC reduce esa brecha.
IaC también favorece la disciplina de cambios, porque la infraestructura puede incorporarse al mismo flujo de trabajo que el código de aplicación: control de versiones, revisión, pruebas, CI/CD, aprobaciones, registros y planificación de reversiones. En los sistemas habilitados con IA, esto importa porque una funcionalidad de modelo sigue dependiendo de almacenamiento, redes, roles, secretos, APIs, colas, observabilidad y controles de costes. Si esas bases están configuradas manualmente y se comprenden mal, la capa de "IA" hereda esa debilidad.
Cómo funciona
La mayoría de los flujos de trabajo de IaC giran en torno a un estado deseado. Un equipo declara qué recursos deben existir y cómo deben configurarse. La herramienta IaC lee el entorno actual, lo compara con el estado declarado y propone los cambios necesarios para cerrar la brecha. En una práctica madura, los equipos no pasan directamente de los archivos editados a los cambios en producción. Primero revisan el plan.
Ese paso de propuesta es valioso porque muestra la intención con claridad. Un plan puede revelar que se creará una nueva subred, que se eliminará un bucket de almacenamiento antiguo, que una política de rol se ampliará o que cambiará una regla de la API gateway. En muchas herramientas, los equipos pueden separar el paso de planificación del de aplicación, de modo que lo que ejecuta la automatización sea un plan revisado y no un cálculo ad hoc reciente.
El estado es otro concepto operativo que los responsables deben comprender. Las herramientas IaC suelen necesitar un registro que relacione los recursos declarados con los reales en el entorno. Sin ese estado, la herramienta no puede determinar de forma fiable qué gestiona ya y qué debe cambiar a continuación. Por eso la gestión del estado merece atención.
La deriva (drift) es la otra cara de la historia. El estado deseado es lo que dicen los archivos. El estado real es lo que existe de verdad. Ambos divergen cuando las personas realizan cambios manuales, cuando se producen acciones de emergencia o cuando los servicios conectados modifican su comportamiento. Una buena práctica de IaC incluye la detección de deriva y una regla de respuesta: restaurar el entorno para que coincida con la configuración aprobada, o actualizar la configuración para que el código refleje la realidad.
En términos prácticos, IaC suele integrarse dentro de CI/CD. Un cambio en el código de infraestructura desencadena validación, comprobaciones de políticas, posiblemente análisis de seguridad, un plan visible y luego una aplicación controlada sobre un entorno concreto. Ese flujo de trabajo puede abarcar redes, roles IAM, destinos de registro, configuración de API gateway, bases de datos gestionadas y otros componentes de la plataforma.
Ejemplos
Consideremos una empresa de servicios con entornos de desarrollo, pruebas y producción en una nube pública. Originalmente, cada entorno se creó de forma manual. Con el tiempo, producción adquirió reglas de red más estrictas, configuraciones de almacenamiento diferentes y registros adicionales que el entorno de pruebas nunca recibió. Las versiones empezaron a fallar solo en producción porque los entornos ya no eran comparables. Trasladar esos recursos principales a IaC permite al equipo definir la línea base una sola vez, revisar los cambios de forma explícita y reconstruir los entornos de manera más consistente.
Tomemos ahora un ejemplo con IA. Una empresa construye un flujo de trabajo de análisis de documentos que utiliza almacenamiento de objetos gestionado, una cola, una función serverless, una API de modelo, una base de datos privada y una API gateway para acceso interno. El flujo funciona en una cuenta porque un ingeniero sénior lo configuró todo a mano. Cuando la empresa necesita una segunda región o una copia realista del entorno de pruebas, la falta de infraestructura codificada se convierte en un problema. IaC permite recrear la arquitectura de forma revisable en lugar de depender de la memoria y las capturas de pantalla.
Un tercer caso es la recuperación ante incidentes. Los ingenieros pueden realizar cambios urgentes en la consola para restaurar el servicio. La pregunta de gobernanza posterior es si la definición de infraestructura aprobada se actualizó y la deriva se reconcilió, en lugar de dejar el entorno en un estado parcialmente documentado.
Malentendidos frecuentes
Un malentendido habitual es creer que IaC hace que la infraestructura sea automáticamente segura. No es así. La infraestructura mal configurada también puede desplegarse con mayor rapidez y consistencia. Si un bucket de almacenamiento es público en el código, IaC ayudará a recrear ese error fielmente.
Otro malentendido es que IaC elimina la necesidad de entender la plataforma. Tampoco es así. Los equipos siguen necesitando criterio sobre las relaciones entre recursos, los límites de identidad, la gestión del estado, la reutilización de módulos y las consecuencias de aplicar cambios.
También es un error tratar IaC como un lujo reservado a grandes empresas. Las organizaciones más pequeñas pueden beneficiarse incluso más, porque a menudo dependen de un puñado de personas y servicios gestionados. Codificar las partes importantes del entorno reduce la concentración de conocimiento y disminuye el riesgo de recuperación.
Riesgos y límites
El gran riesgo de IaC no es que exista el código, sino que los equipos confíen en él con demasiada facilidad. Los secretos codificados directamente son un problema evidente. También lo son los módulos copiados y pegados que trasladan permisos innecesarios, endpoints expuestos, valores predeterminados desactualizados o recursos costosos a cada nuevo entorno. La calidad de la revisión importa porque los cambios de IaC pueden tener un radio de impacto muy amplio.
Los permisos merecen un escrutinio especial. El rol utilizado para aplicar cambios de infraestructura suele tener privilegios elevados. Si esa identidad está mal protegida, o si demasiadas personas pueden desencadenar aplicaciones en producción, IaC se convierte en una forma eficaz de acelerar un compromiso de seguridad. Los archivos de estado también pueden ser sensibles, ya que pueden revelar identificadores de recursos, detalles de configuración y, a veces, secretos si los equipos no son cuidadosos.
La deriva es otro riesgo operativo. Si los ingenieros realizan cambios en la consola por comodidad, el código y el entorno divergen. Con el tiempo, nadie sabe cuál es la fuente de verdad. Entonces, la siguiente aplicación automatizada puede sobrescribir una corrección de emergencia o reintroducir una configuración insegura que alguien creía haber corregido.
También existe un límite de negocio. IaC ayuda a gobernar la infraestructura, pero no garantiza una buena arquitectura, seguridad ni cumplimiento normativo.
Una gestión débil del estado es una versión práctica del mismo problema. Si los equipos comparten el estado de forma descuidada entre entornos, no lo bloquean correctamente o lo almacenan donde personas no autorizadas pueden acceder a él, la fiabilidad del flujo de trabajo cae rápidamente. El resultado puede ser una eliminación accidental, una propiedad confusa o la exposición de detalles operativos sensibles.
Próximos pasos
Los responsables deben empezar por identificar qué partes del entorno generan más problemas cuando cambian. Conviene centrarse primero en la infraestructura que sustenta los servicios importantes, las cargas de trabajo reguladas, las integraciones externas o las interrupciones costosas. Las redes, los roles de acceso, los registros, las políticas de almacenamiento, las pasarelas y los entornos principales suelen ser mejores puntos de partida que intentar codificarlo todo a la vez.
Conviene pedir al equipo que haga explícitas algunas reglas. ¿Qué entornos se controlan mediante IaC? ¿Qué acciones manuales siguen permitidas y cómo se reconcilian después? ¿Dónde se almacena el estado? ¿Cómo se mantienen los secretos fuera de la configuración? ¿Qué aprobaciones se requieren antes de aplicar cambios en producción? ¿Cómo se detecta y gestiona la deriva?
A continuación, conviene alinear IaC con disciplinas operativas más amplias, como el control de versiones, la revisión entre pares, las comprobaciones de CI/CD, la conciencia de costes, la disciplina de IAM y el aprendizaje de incidentes. El objetivo no es tener más código, sino una infraestructura más fácil de entender, recuperar y gobernar: más sencilla, más segura y menos dependiente de la memoria individual.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿IaC solo es relevante si gestionamos todo nosotros mismos en la nube?
No. Incluso las organizaciones que dependen en gran medida de servicios gestionados siguen configurando redes, identidades, registros, almacenamiento, pasarelas, políticas y entornos. Esos ajustes suelen determinar la exposición, la resiliencia y los costes, por lo que se benefician de estar versionados y ser revisables.
¿IaC elimina la deriva de configuración?
No de forma automática. IaC facilita la detección y corrección de la deriva, pero esta sigue produciéndose cuando las personas cambian la infraestructura manualmente, se aplican correcciones de emergencia o los servicios conectados se modifican de forma inesperada. La buena práctica consiste en decidir qué fuente de verdad prevalece y reconciliar las desviaciones con rapidez.
¿Es fácil revertir cambios con IaC?
A veces, pero no siempre. Revertir un archivo de configuración suele ser sencillo. Revertir el impacto real de un cambio puede ser más difícil, especialmente si los datos se han movido, los recursos se han eliminado o los sistemas dependientes ya se han adaptado. IaC mejora el control y la trazabilidad, pero no crea un botón de deshacer perfecto.
¿Cómo se relaciona IaC con FinOps y el control de costes?
IaC hace visibles las decisiones de infraestructura antes de que se apliquen, lo que ayuda a los equipos a cuestionar tamaños de recursos innecesarios, entornos duplicados o servicios olvidados. No optimiza los costes de forma automática, pero crea una mejor superficie de revisión para las decisiones de coste.
Fuentes
SP 800-128, Guide for Security-Focused Configuration Management of Information Systems (NIST). Configuration management integrity, monitoring, and risk reduction concepts that underpin IaC.
Interactive administration in the cloud: managing the risks (UK NCSC). Replacing manual cloud administration with IaC and secure CI/CD, repeatable deployments, and easier recovery.
Using a cloud platform securely (UK NCSC). Automation, cloud platform configuration, observability, incident preparation, and protecting secrets.
Infrastructure as Code Security Cheatsheet (OWASP). IaC consistency, repeatable deployments, and security best practices.
Guidelines for secure AI system development (UK NCSC). AI-system infrastructure, access controls, and deployment discipline.