Policy as Code en la era del código IA: la paradoja de velocidad y control

Copilot escribe en 10 segundos lo que un senior antes escribía en una hora. Cursor monta una feature a partir de un párrafo. Claude Code abre un PR sin un humano en el bucle. Todo esto funciona — salvo una cosa: el review se quedó manual. La velocidad del código de producción supera ahora rutinariamente la velocidad del review humano, y eso reescribe los requisitos del governance.

Antes Policy as Code era un «nice to have»: el código pasaba por un PR, dos pares de ojos miraban el diff, un Action: "*" en IAM o un resources.limits ausente lo cazaba un senior en un día. Hoy la latencia entre código generado por IA y su intento de aterrizar en un cluster se mide en minutos, y el número de esos intentos en decenas al día por equipo. PaC pasa de bonus a requisito funcional. No es «la IA escribe políticas» — son reglas deterministas de admission, escritas por humanos o por IA, pero aplicadas sin humano en el bucle, porque el humano ya no llega físicamente.

Tres puntos donde se puede atrapar una infracción

Un único admission-gate en el cluster es «todo o nada». Un único CI-check es «evitable con --skip o una rama hotfix». El modelo que aguanta de verdad en producción son tres capas, y cada una caza su propia clase de errores.

CI / pre-merge. conftest contra políticas Rego, Trivy contra CVE, Checkov contra configs Terraform. Lo más barato: el defecto se caza antes del merge, antes del build, antes del registry. Aquí viven «no permitas cidr_blocks = ["0.0.0.0/0"] en el puerto 22» y «no permitas Action: "*" en IAM». Para Terraform el gate obligatorio es conftest test plan.json --policy ./policies/ contra terraform plan -json, porque un solo apply levanta decenas de recursos de golpe, y revertir en el PR es más barato que revertir después.

Admission (cluster). OPA Gatekeeper, Kyverno o el CEL ValidatingAdmissionPolicy nativo. Aquí se caza lo que CI dejó pasar: deploy de un tag viejo que esquivó el pipeline, una imagen desde un registry sin firmar, un pod sin runAsNonRoot. Admission es la última línea de defensa en el sentido de «antes de la escritura a etcd»: el network egress-block se dispara más tarde, la detección runtime (Falco) más tarde aún.

Runtime. Falco/Tetragon son detectivos, no preventivos. Cazan la shell en un contenedor de producción, el acceso a un Secret desde el ServiceAccount default. No bloquean — alertan, y por eso sin las dos primeras capas son inútiles.

El detalle importante: un gate de CI sin un gate de admission es una falsa sensación de seguridad. CI caza lo que construiste; admission caza lo que desplegaste. Esos dos conjuntos se solapan, pero no coinciden.

Con qué aplicar

Tres herramientas, y la elección entre ellas no es «la mejor», sino «la que encaja con el perfil del equipo».

OPA Gatekeeper — Rego, estándar de la industria, mutation maduro en beta. Su fortaleza es la expresividad de Rego para reglas complejas con lógica cross-resource. Su debilidad es la curva de aprendizaje y la barrera de idioma: un equipo que nunca escribió Rego invierte semanas en «su primer constraint útil».

Kyverno — YAML en vez de Rego, mutate/generate de fábrica (por ejemplo, añadir automáticamente una NetworkPolicy a un namespace nuevo), verifyImages incorporado para Cosign/Sigstore sin data providers externos. CNCF Incubating. Default para equipos que necesitan mutation y image-policy y no quieren otra DSL más.

CEL ValidatingAdmissionPolicy — GA en Kubernetes 1.30, MutatingAdmissionPolicy + CEL GA en 1.36. Corre dentro del API server: sin TLS, sin Deployment, sin dependencia de cert-manager, sin el failure mode «webhook caído → todo rechazado o todo aceptado». Cubre la clase de validaciones declarativas simples (required labels, naming conventions, transition rules) y le quita a Kyverno/OPA el «impuesto de las validaciones simples». No las desplaza — para image verification, multi-resource generate y reglas complejas sigue haciendo falta Kyverno.

Una guía práctica: CEL para lo simple, Kyverno para el medio y para image-policy, OPA Gatekeeper para equipos con lógica cross-resource compleja y cultura Rego.

Qué rompe PaC en producción

• failurePolicy: Ignore en la ValidatingWebhookConfiguration. Default de muchos tutoriales. Bajo carga o durante un incidente el policy-engine degrada — admission defaults to allow, el bypass se activa justo cuando es más peligroso. Siempre Fail.
• enforcementAction: dryrun para siempre. La killer-feature de Gatekeeper es el modo dryrun para observar el blast radius antes de pasar a deny. Si se queda medio año, ya no es una política, es logging. Timeline firme: dryrun una semana → deny.
• Un único ConstraintTemplate / ClusterPolicy gigante. Imposible de depurar, imposible de revisar, una excepción para un namespace rompe todas las demás.
• PaC sin unit tests. OPA Rego trae un framework de tests integrado, Kyverno tiene kyverno cli test. Una policy generada por IA sin test es un incidente de seguridad generado por IA.

Dónde converge esto

Policy as Code en la era del código IA no es una manera de frenar al desarrollador hasta las velocidades pre-IA. Son guardrails deterministas que permiten soltar el review humano sobre patrones repetitivos (required labels, image tags, resource limits, wildcards de IAM) y conservarlo donde de verdad importa (arquitectura, lógica de negocio, edge cases). La paradoja velocidad-vs-control no se resuelve eligiendo «velocidad o control», sino desplazando el control del carril manual al automático.

Sin ese puente, un agente IA es un amplificador de errores. Con él, un agente IA es un amplificador del throughput del equipo.