Tabla de Contenidos

«Le pedí a Claude Code "escribe Terraform para levantar una instancia EC2" y en 30 segundos tenía el código IaC listo. Esto significa que el trabajo del ingeniero de infraestructura desaparece, ¿no?».

Seguro que muchas personas piensan así. Y es cierto que las herramientas de codificación con IA están evolucionando a una velocidad vertiginosa, acelerando también la generación de código, la creación de archivos de configuración y el análisis de logs en el área de infraestructura. Codex (el agente de codificación que OpenAI presentó en 2025) también destaca en la generación automática de código de infraestructura.

Entonces, ¿los ingenieros de infraestructura y de redes realmente se volverán innecesarios?

Adelantemos la conclusión: la visión realista es que no habrá «reemplazo», sino un «cambio de rol». Este artículo organiza lo que la IA hace bien y lo que no, centrándose en el área de infraestructura, y explica en detalle qué estrategia deben adoptar los ingenieros.

1. ¿Qué está pasando ahora? — La evolución de las herramientas de codificación con IA

Primero, veamos qué pueden hacer hoy las herramientas de codificación con IA en el área de infraestructura.

Principales herramientas de IA y su soporte para infraestructura

HerramientaProveedorFortaleza en infraestructura
Claude CodeAnthropicGenera Terraform, Docker, Ansible, manifests de K8s, etc. Destaca en modificaciones que comprenden todo el proyecto
Codex (CLI)OpenAIEjecución y verificación de código en sandbox. Genera IaC y prueba su funcionamiento de forma integrada
GitHub CopilotGitHub/MSAutocompletado en el editor. Predice y continúa Terraform o YAML existentes
Amazon Q DeveloperAWSEspecializado en AWS. Fuerte en CloudFormation, CDK y políticas IAM
Google Cloud AssistGoogleAsistencia de configuración en GCP. Integración con Vertex AI

Lo notable es que estas herramientas han dejado de ser simples asistentes de autocompletado y comienzan a actuar como «agentes». Claude Code lee y escribe archivos, ejecuta comandos; Codex corre código en sandbox y verifica los resultados.

El rango de lo posible se expande rápidamente

Lo que en 2024 era apenas «producir una plantilla de Terraform» se ha convertido, entre 2025 y 2026, en tareas como las siguientes.

  • Leer código de infraestructura existente e identificar problemas de seguridad
  • «Quiero desplegar esta app en AWS» → Proponer de golpe VPC, subredes, SG, ALB y ECS/EKS
  • Analizar logs de errores en producción y sugerir causas probables y soluciones
  • Construir un pipeline CI/CD desde cero
  • Generar y modificar manifests de Kubernetes o Helm charts

Viendo esta velocidad, es comprensible pensar que «los ingenieros de infraestructura ya no hacen falta». Pero eso es solo una cara de lo que la IA puede hacer.

2. Tareas de infraestructura que la IA «sí puede» hacer

Mapa de capacidades de la IA en tareas de infraestructura: la IA destaca en generación de código y análisis de logs, mientras que el trabajo físico y el juicio ante incidentes necesitan humanos

La IA es especialmente fuerte en trabajos que son «expresables en código», «con patrones claros» y «basados en texto».

1. Generación de Infrastructure as Code (IaC)

Terraform, CloudFormation, Pulumi, Ansible, Chef: la generación de código para estas herramientas IaC es el área donde la IA mejor rinde.

TareaPrecisión de la IANotas
Definición de recursos de TerraformExcelenteLos recursos principales de AWS/GCP/Azure son casi siempre correctos
Playbooks de AnsibleExcelenteInstalación de paquetes y cambios de configuración comunes
Docker / docker-composeExcelentePermite multi-stage builds y configuración de red
Manifest K8s / HelmMedia-altaConfiguraciones básicas correctas. Revisar los custom resources complejos
Pipelines CI/CDMedia-altaGeneración de flujos para GitHub Actions, GitLab CI, etc.

2. Generación y optimización de archivos de configuración

nginx.conf, apache.conf, reglas de iptables/nftables, unit files de systemd: la IA también es buena generando estos archivos. Si le pides «escribe una configuración de proxy inverso nginx con SSL para esta aplicación web», obtendrás una configuración alineada con las buenas prácticas.

3. Análisis de logs y detección de anomalías

Encontrar patrones en grandes volúmenes de logs es terreno donde la IA brilla.

  • Resumir logs de texto como syslog, journald o CloudWatch Logs
  • Clasificar patrones de errores y analizar su frecuencia
  • Respuestas inmediatas a preguntas del tipo «¿qué errores han aumentado en la última hora?»
  • Propuesta de causas probables y acciones correctivas a partir de los logs

4. Generación automática de documentación y procedimientos

Leyendo código de infraestructura existente, la IA puede generar borradores de diagramas explicativos, manuales operativos y procedimientos de respuesta a incidentes. Es una de las tareas que más detestan los ingenieros de infra (y también de las más importantes).

5. Comprobaciones de seguridad

Verificación de privilegios excesivos en políticas IAM, validación de reglas de security groups, comprobación de conformidad con CIS Benchmark en código Terraform: la IA puede asistir en estas revisiones de seguridad rutinarias.

3. Tareas de infraestructura que la IA «no puede» hacer

Aquí está el punto clave. Si no se entiende bien el límite de la IA, se cae en el peor escenario posible: «dejémoselo todo a la IA» → un incidente grave.

1. Trabajo en la capa física

Obviamente, la IA no puede hacer trabajo físico.

  • Instalar equipos en racks de servidores y hacer el cableado
  • Sustituir HDD/SSD averiados
  • Configurar o sustituir físicamente equipos de red (routers, switches, firewalls)
  • Gestión de acceso al centro de datos y seguridad física

Tal vez pienses: «Con la nube el trabajo físico ya no será necesario». Pero alrededor del 60% de las empresas japonesas siguen usando entornos on-premise combinados (según un estudio de IDC Japan), y la infraestructura física no va a desaparecer por completo en el corto plazo.

2. Juicios de negocio ante incidentes

Cuando ocurre un incidente en producción, lo más importante es la decisión de negocio sobre «qué priorizar».

  • «La BD se ha corrompido. Si restauro desde copia perderé las últimas 2 horas de datos. ¿Restauro o intento repararla?»
  • «Los servicios A y B están caídos. Con recursos limitados, ¿cuál recupero primero?»
  • «Sospecha de brecha de seguridad. ¿Detengo el servicio para investigar o investigo con el sistema en marcha?»

Estas decisiones no solo requieren conocimiento técnico, sino que exigen considerar en conjunto el impacto en el negocio, los compromisos con el cliente (SLA), los riesgos legales y la coordinación con la dirección. No se pueden delegar en la IA. La IA puede «presentar opciones», pero no puede «tomar decisiones con responsabilidad».

3. Respuesta a patrones de fallo desconocidos

La IA es fuerte con patrones presentes en sus datos de entrenamiento, pero débil ante fallos que nadie ha vivido antes.

  • Bugs no publicados del lado del proveedor de nube
  • Fallos combinados de varios sistemas (red + DNS + app al mismo tiempo)
  • Fallos intermitentes por degradación de hardware por el tiempo

En esas situaciones, la «intuición» de un ingeniero experimentado —es decir, la capacidad de analogía con casos similares del pasado— resulta decisiva.

4. Responsabilidad final en seguridad

Que la IA diga «esta configuración es segura» no es ninguna garantía. Cuando ocurre un incidente de seguridad, la responsabilidad legal y ética recae sobre las personas, no sobre la IA.

  • Notificación y respuesta ante autoridades en casos de fuga de datos personales
  • Investigación forense y preservación de evidencias
  • Definición de medidas preventivas e informe a la dirección
  • Notificación y comunicación con los clientes

5. Gestión y negociación con proveedores

Proveedores de nube, operadores de centros de datos, ISPs, proveedores de seguridad: el trabajo de un ingeniero de infra incluye muchas negociaciones externas. Negociar condiciones contractuales, acordar SLAs o coordinar en incidentes son puramente dominio humano, algo que la IA no puede hacer.

4. Impacto sobre los ingenieros de redes

La ingeniería de redes ocupa una posición algo especial dentro de la infraestructura. Veamos por separado el impacto de la IA.

Tareas de red que la IA puede automatizar

TareaCapacidad de la IAEjemplo
Generación de ACL / reglas de firewallExcelenteCon los requisitos, genera reglas iptables / nftables / SG
Propuesta de diseño VLAN/subredesBienCrea borradores de esquema IP según requisitos
Generación de configs de equipos de redBienConfigs para Cisco IOS, Junos, etc. (requieren verificación)
Análisis de tráficoExcelenteDetección de anomalías y patrones en datos NetFlow/sFlow
Configuración BGP/OSPFLimitadoConfigs básicas sí; políticas de enrutamiento complejas requieren revisión

Tareas de red difíciles para la IA

  • Diseño y ejecución de cableado físico: distribución de planta, recorrido de cables, organización de paneles de distribución
  • Estudio de radiofrecuencia y diseño Wi-Fi: requiere inspección física in situ (material de paredes, identificación de fuentes de interferencia)
  • Diagnóstico de fallos en capa 1: cables cortados, puertos averiados, caída de nivel de señal óptica (requieren verificación física)
  • Coordinación con operadoras: alta de nuevas líneas, cambios de ancho de banda, ajustes de redundancia
  • Migraciones de red a gran escala: planificación y ejecución de migración de cientos de equipos, con transición escalonada para minimizar caídas

Como la ingeniería de redes depende fuertemente de la capa física, es más difícil de reemplazar totalmente con IA que la infraestructura de servidores. Dicho esto, la IA contribuye enormemente a agilizar la generación de configuraciones y el troubleshooting.

5. ¿Cómo cambia el trabajo real en el día a día?

Cambio en el rol del ingeniero de infraestructura: de construir y configurar manualmente a un arquitecto que sabe usar la IA

Dejemos la teoría y veamos algunos patrones de uso reales de la IA en el día a día.

Patrón 1: Desarrollo IaC acelerado

En una startup, los ingenieros de infraestructura usan Claude Code para generar código Terraform. Lo que antes tardaba entre 30 minutos y 1 hora para definir un solo recurso de AWS ahora se reduce a 5-10 minutos, porque comunican los requisitos a la IA y luego revisan y corrigen.

Un punto crucial: nunca aplican directamente a producción el código generado por la IA. Siempre un humano lo revisa y añade ajustes de configuración de seguridad y optimización de costes.

Patrón 2: Respuesta inicial asistida ante incidentes

Cuando ocurre un incidente en producción, primero se deja que la IA analice los logs y acote las causas probables. Después, los humanos toman la decisión final y ejecutan la recuperación: una división del trabajo muy eficaz.

  • Antes: 30 minutos a 1 hora siguiendo logs a ojo para identificar la causa
  • Ahora: la IA reduce en 5 minutos los candidatos a 3 → un humano verifica y actúa

El MTTR (tiempo medio de recuperación) se reduce, pero surge un nuevo riesgo: «tomar el análisis de la IA al pie de la letra y aplicar una recuperación errónea». Por eso la decisión final debe tomarla un ingeniero con experiencia.

Patrón 3: Aceleración en la formación de ingenieros junior

En el área de infraestructura se decía que «sin experiencia no se puede hacer nada», pero la IA ha suavizado enormemente la curva de aprendizaje.

  • «Explícame qué hace este código Terraform» → la IA lo comenta línea por línea
  • «¿Por qué en este security group hay que restringir el puerto 22?» → la IA explica contexto y razón
  • «No sé leer este log de error» → la IA muestra la estructura del log y los puntos clave

Esto no es «los ingenieros dejan de ser necesarios», sino el efecto de que «los ingenieros crecen más rápido».

Patrón 4: Equipos de infra de una sola persona

Operaciones de infraestructura que antes necesitaban equipos de 3 a 5 personas, con el apoyo de la IA, empiezan a poder llevarse con 1 o 2 personas. El número se reduce, pero al personal que queda se le exigen habilidades y criterio mucho más altos.

6. Cómo sobrevivir como ingeniero de infra en la era de la IA

A partir de aquí, estrategias concretas. Organizamos el conjunto de habilidades que la IA no puede reemplazar y que, de hecho, se ven revalorizadas gracias a la IA.

1. Aprender a dominar la IA

La estrategia más importante y la de efecto más inmediato. Un ingeniero que use la IA como «herramienta» en vez de como «amenaza» puede multiplicar su productividad.

  • Integrar herramientas como Claude Code, Codex o Copilot en el trabajo diario
  • Aprender a escribir prompts (instrucciones) adecuados para la IA
  • Mantener la capacidad técnica para verificar y corregir correctamente las salidas de la IA

Para las formas gratuitas de usar estas herramientas de IA, consulta «Cómo usar la IA gratis [edición 2026]».

2. Desplazarse al lado de «diseño y arquitectura»

La IA es buena «escribiendo código», pero no decidiendo «qué diseñar y cómo».

  • Diseño de arquitectura en la nube: equilibrar disponibilidad, escalabilidad y optimización de costes
  • Estrategia multicloud: entender las particularidades de AWS, GCP y Azure y elegir con criterio
  • Diseño de DR (recuperación ante desastres): desde definir RPO/RTO hasta redactar procedimientos de recuperación

3. Profundizar en la especialización en seguridad

La seguridad es el área donde «el impacto de un error de la IA es mayor». Por eso se estima que la demanda de ingenieros con especialización en seguridad, junto con la expansión de la IA, más bien aumentará.

  • Diseño e implementación de arquitecturas Zero Trust
  • Capacidad de respuesta ante incidentes de seguridad
  • Adecuación a normativas (ISMS, PCI DSS, GDPR, etc.)

4. Adoptar el enfoque SRE (Site Reliability Engineering)

La idea de SRE propuesta por Google —«tratar la operación como un problema de ingeniería de software»— cobra aún más importancia en la era de la IA.

  • Diseño y operación de SLI/SLO/SLA
  • Decisiones basadas en el error budget
  • Promoción de la automatización (la IA es también un medio de automatización)
  • Construcción de una cultura de post-mortems (revisión de incidentes)

5. Aumentar el contacto con el negocio

Lo más difícil de reemplazar por IA son las habilidades que tienden puentes entre tecnología y negocio.

  • Propuestas de optimización de costes de infraestructura e informes a la dirección
  • Definición y estimación de requisitos de infra para nuevos negocios
  • Capacidad de traducir riesgos técnicos a riesgos de negocio y explicarlos

7. Conclusión — No es «reemplazo», sino «evolución»

Resumimos la conclusión del artículo.

PerspectivaConclusión
¿La IA reemplaza al ingeniero de infra?Reemplazo total: No. Pero la demanda de «ingenieros que solo ejecutan tareas» caerá con seguridad
Áreas en las que la IA destacaGeneración de código IaC, creación de configs, análisis de logs, documentación, etc.: «tareas rutinarias expresables en código»
Áreas en las que hace falta humanoTrabajo físico, juicio en incidentes, responsabilidad de seguridad, negociación con proveedores, diseño de arquitectura
Impacto en el tamaño del equipoProbablemente los equipos se reducirán. Pero a quienes queden se les pedirán habilidades más altas
Impacto sobre ingenieros de redesComo la dependencia de la capa física es alta, el reemplazo es más difícil que en infra de servidores. La generación de configs sí se agiliza

El mensaje más importante es que «los ingenieros de infraestructura que saben usar la IA» serán los de mayor valor de mercado. Al delegar en la IA las tareas rutinarias, los ingenieros pueden concentrarse en diseño, juicio y estrategia de mayor nivel.

Esto no es una «amenaza», sino una «oportunidad de evolución». No temer a la IA, sino usarla como arma. Esa es la estrategia de supervivencia del ingeniero de infraestructura en la era de la IA.

Para conocimientos básicos de TI y cómo empezar a desarrollar con IA, consulta también «Guía de Desarrollo de IA para Principiantes Absolutos».

Preguntas Frecuentes

P. ¿Es mala idea intentar ser ingeniero de infraestructura a día de hoy?

No, al contrario, es una oportunidad. Con la llegada de las herramientas de IA, la barrera de aprendizaje en el área de infra ha bajado. Eso sí, «instalar Linux en un servidor y levantar nginx» ya no es suficiente. Se requieren capacidades de diseño de arquitecturas en la nube, conocimientos de seguridad y saber usar las herramientas de IA. Dicho de otra forma, se estima que la demanda de ingenieros con estas habilidades seguirá siendo alta en los próximos años.

P. ¿Las certificaciones de redes como CCNA perderán valor?

El valor de la certificación en sí no «desaparecerá», pero parte de las habilidades que certifica (como memorizar comandos de configuración) sí puede ser reemplazada por la IA. Lo importante es la comprensión de los principios básicos de red que se adquiere al estudiar para el examen (modelo OSI, funcionamiento TCP/IP, concepto de los protocolos de enrutamiento): esos conocimientos siguen valiendo en la era de la IA, porque son imprescindibles para juzgar si la salida de la IA es correcta.

P. Si la IA provoca un incidente en producción, ¿quién asume la responsabilidad?

A día de hoy, la responsabilidad recae sobre la persona (y la organización) que decidió aplicar el código generado por la IA a producción. La IA es una herramienta, no un sujeto legalmente responsable. Es como cuando un cuchillo arruina una receta: la culpa no es del fabricante del cuchillo. Por eso, es imprescindible aplicar un proceso en el que un humano siempre revise y verifique el código de infra generado por la IA antes de ponerlo en producción.

P. ¿El impacto de la IA es menor en entornos on-premise?

En entornos on-premise, donde hay mucho trabajo físico (instalación, sustitución, cableado), el impacto de la IA es menor que en la nube. Pero en tareas basadas en texto —gestión de configuración con Ansible u otras herramientas, configuración de monitoreo, redacción de documentación—, los beneficios de la IA también son grandes en on-premise. Se avanzará de forma natural a un reparto donde «lo físico lo hace el humano y lo lógico (configs y código) lo asiste la IA».

P. ¿Cómo se deben usar Claude Code y Codex según el caso?

Claude Code funciona en tu terminal local y destaca en generar y modificar código entendiendo todo el proyecto existente. Codex, por su parte, ejecuta y verifica código en un sandbox, por lo que es ideal para generar nuevo código IaC con validación de funcionamiento incluida. En la práctica, usa Claude Code para modificar y ampliar infraestructura existente, y Codex para hacer prototipos desde cero. Pero como las herramientas evolucionan rápido, lo mejor es probar ambas y elegir la que mejor encaje con tu flujo de trabajo.

P. ¿Las empresas pequeñas también deberían adoptar la gestión de infraestructura con IA?

Sí, podría decirse que cuanto más pequeña es la empresa, mayor es el beneficio. Incluso las empresas que no pueden contratar a un ingeniero de infra dedicado pueden delegar fácilmente esa responsabilidad en sus desarrolladores cuando cuentan con el apoyo de herramientas de IA. Eso sí, se recomienda encarecidamente que tareas críticas como configuración de seguridad o copias de respaldo no se acepten a ciegas de la IA, y que siempre las revise una persona con conocimientos de confianza.