Problema

Los equipos que usan agentes de IA para generar infraestructura como código (IaC) ganan velocidad en la fase de “Day 1”, pero rápidamente aparecen dos síntomas críticos en producción:

  1. Blast radius amplio – Un PR generado por IA contiene cientos de líneas de recursos interdependientes. Un error de sintaxis o una configuración insegura se propaga a todo el entorno y, al aplicar, afecta a múltiples regiones o a recursos críticos.
  2. Deuda Day 2 – La falta de comprensión del razonamiento del agente genera código que se vuelve difícil de mantener. Los ingenieros senior pasan horas revisando cada PR, mientras que los incidentes nocturnos requieren una investigación profunda porque nadie conoce la lógica subyacente.

Estos patrones aparecen en cualquier stack que incluya Terraform, Helm, K8s manifests o GitHub Actions, sin importar el proveedor de nube. El reto es transformar la generación automática en un proceso controlado, reproducible y auditable.

Causa

1. Falta de contexto persistente

Los agentes de IA operan con prompts ad‑hoc. Cada invocación carece de la historia completa del proyecto, por lo que pueden generar recursos que rompen convenciones establecidas o duplican módulos existentes.

2. Ausencia de políticas de validación temprana

Sin un “gate” de policy‑as‑code, los artefactos generados llegan al PR sin filtrado. Herramientas como OPA, Checkov o tfsec no están integradas en el pipeline, lo que deja a los revisores humanos la única defensa contra errores de seguridad o de configuración.

3. Dependencia de la revisión manual

Los equipos confían en que los senior detecten “hallucinations” de la IA. La carga cognitiva aumenta y la calidad de la revisión disminuye, especialmente cuando los cambios son extensos.

4. Configuraciones implícitas y anti‑patterns

Los agentes tienden a usar valores por defecto o a copiar fragmentos de documentación sin adaptarlos al entorno concreto (por ejemplo, políticas IAM demasiado permisivas, puertos abiertos sin justificación, o recursos de red sin etiquetas de cost‑center).

Solución

Una estrategia de “Control de generación + Validación continua + Gestión de contexto” permite reducir el blast radius y la deuda Day 2 sin abandonar la productividad de los agentes.

1. Definir un “contract” de generación

  • Plantillas de módulo: Mantén módulos Terraform/Helm con versiones bloqueadas y publica su firma (inputs, outputs, tags). Los agentes deben invocar exclusivamente estos módulos mediante source = "git::...//module?ref=vX.Y.Z".
  • Prompt estándar: Crea un prompt base que incluya la referencia al contrato, los linters obligatorios y la lista de políticas a aplicar. Usa variables de entorno para pasar el module_version y el environment.

2. Integrar policy‑as‑code en el pipeline

  1. OPA/Rego para validar arquitectura: verifica que los recursos pertenezcan a la VPC correcta, que los nombres sigan la convención y que los roles IAM no tengan * en sus permisos.
  2. Checkov/Terraform‑validate para detectar vulnerabilidades conocidas (exposición pública, sin cifrado, etc.).
  3. tfsec para escanear configuraciones de Terraform en busca de anti‑patterns.

Ejemplo de regla OPA que prohíbe IAM policies con * en actions:

opa eval -i generated.tfplan -d policies/iam_no_wildcard.rego "data.iam.no_wildcard"

3. Automatizar la captura de contexto

  • Git‑ops de metadatos: Cada PR debe incluir un archivo context.yaml que enumere los módulos afectados, la versión de cada uno y los tickets de Jira vinculados. Los agentes actualizan este archivo automáticamente.
  • Cache de prompts: Almacena en un KV store (por ejemplo, Consul o Redis) los últimos prompts y respuestas relevantes. Cuando un agente genera código para el mismo dominio, recupera el historial y lo incluye en el prompt, evitando desviaciones de arquitectura.

4. Limitar el “blast radius” mediante “guardrails”

  • Áreas protegidas: Define en OPA una lista de recursos críticos (VPC, IAM, DNS) que sólo pueden ser modificados por usuarios humanos o por agentes con un token de alto privilegio.
  • Pull‑request size caps: Configura el CI para fallar si el número de recursos añadidos supera un umbral (p.ej., 30 recursos). Esto fuerza a dividir cambios grandes en PRs más pequeños y revisables.

5. Refuerzo de la cultura de “ownership”

  • Post‑mortem de IA: Cada incidente que involucre código generado por IA debe documentarse con una sección “AI rationale”. El autor del PR escribe, en 2‑3 frases, por qué el agente eligió esa configuración. Con el tiempo, el equipo construye una base de conocimiento que alimenta los prompts.

Cuándo aplicar esta solución

  • Síntomas: PRs de IA con >200 líneas, revisiones que consumen >2 h, incidentes nocturnos vinculados a cambios de IAM o red, alta tasa de rechazo en CI por vulnerabilidades.
  • Entornos: Multi‑region, infraestructuras que combinan varios proveedores de nube, pipelines CI/CD con despliegues automáticos de Terraform/Helm.
  • Exclusiones: Cambios triviales (actualización de etiquetas, comentarios) pueden seguir sin política estricta; la solución no es necesaria para scripts de prueba aislados.

Código

# OPA policy: prohibir wildcard en IAM actions
cat > policies/iam_no_wildcard.rego <<'EOF'
package iam

no_wildcard {
  input.resource_type == "aws_iam_policy"
  contains(input.actions, "*")
}
EOF

# Ejecutar la política contra un plan de Terraform
opa eval -i tfplan.json -d policies/iam_no_wildcard.rego "data.iam.no_wildcard"

Verificación

  1. Pipeline: Al crear un PR, el CI ejecuta opa test, checkov -d . y tfsec .. Todos deben pasar antes de que el PR sea mergeable.
  2. Tamaño de PR: Revisa que el número de recursos añadidos (git diff --stat) sea ≤ 30. Si supera, el pipeline falla con mensaje “PR demasiado grande”.
  3. Context file: Cada PR debe contener context.yaml. Un script de CI valida su esquema con yamllint.
  4. Incidente simulado: Despliega una versión de prueba con una política intencionalmente vulnerable. Verifica que OPA la bloquee y que el agente no pueda sobrescribir la regla sin token de alto privilegio.

Notas adicionales

  • Mantenimiento de módulos: Usa versiones semánticas y actualiza los módulos de forma controlada. Un cambio de versión dispara una alerta en el pipeline.
  • Rotación de tokens de IA: Los agentes que ejecutan cambios críticos deben usar tokens con expiración corta; así, si un agente se “descontrola”, el daño se limita temporalmente.
  • Feedback loop: Cada rechazo de política debe enviarse a un canal de Slack donde el equipo discuta si la regla es demasiado restrictiva o si el agente necesita ajuste de prompt.
  • Escalado: En organizaciones grandes, agrupa las políticas por dominio (network, security, cost) y asigna owners que revisen los cambios de su área. Esto distribuye la carga de revisión.

Con este enfoque, los equipos pueden seguir aprovechando la velocidad de los agentes de IA sin sacrificar la seguridad ni la mantenibilidad de la infraestructura. El objetivo es que la generación automática sea una herramienta, no una fuente de deuda operativa.