The teams using AI coding tools in your organisation are generating infrastructure configurations every day. Some of those configurations land in staging, get reviewed, and reach production without incident. Some of them reach production with a latent problem nobody caught — because the review happened at the speed of the generation.
This is not a capability problem. The tools are impressive. Terraform modules from a prompt, IAM policies, security group rules, subnet configurations — all of it in under a minute. The question is not whether AI can generate it. The question is which of these should you automate, and which should you not.
Those are not the same question.
Not a question of capability
Most "AI for infrastructure" conversations make a category error: they treat automation decisions as capability decisions. If AI can generate it, the assumption goes, you should let it generate it.
But capability and appropriateness are different things. The relevant question is not "can the AI write this?" It is "what breaks if the AI writes this wrong, and who is accountable if it does?" Automating the wrong category of task is not an efficiency gain. It is a governance gap waiting to become an incident.
This is where the five-category map helps. The categories are based on consequence and accountability, not complexity.
Five categories — a working map
Category 1 — Scaffolding and boilerplate. Resource naming, tagging templates, provider configuration blocks, directory structure for a new module. Let AI own this without hesitation. Your only check is whether the output honours your naming standard and tagging policy. Consequence of error: a naming violation. Fix: rename and redeploy.
Category 2 — Configuration with constraints. Security group rules, IAM policies, storage configurations, network CIDR allocations. AI drafts; you validate. The generation is fast and useful. The validation is non-negotiable: run Checkov or OPA Rego policies against every output before it goes near an environment. These tools exist precisely because the failure modes here are expensive — overpermissive IAM, missing encryption at rest, incorrect CIDR that creates an overlapping network segment. Category 2 is where most teams skip the validation because the generation looks right. That is the moment the latent problem is introduced.
Category 3 — Reusable patterns and modules. A Terraform module for a standard VPC topology. A shared IAM role definition. A reusable ALB configuration. AI assists; the architect decides. The reason is scale: an error in a pattern is not one misconfiguration — it is the misconfiguration template. Before a module goes into your internal registry, it needs a human review of the decisions baked in: what does this pattern assume, and what does it break if that assumption changes?
Category 4 — Cross-system design. A landing zone spanning three clouds and an on-premises OT network. An identity federation design bridging your corporate IdP to a Databricks environment that feeds an ERP. AI informs. The architect integrates and decides. This is where the single-discipline failure happens: the AI generates something valid in isolation that breaks a constraint from a domain it was not given context about. The historian connection from OT Level 2 to a data lakehouse bronze layer is a configuration decision in each system separately — and an OT/IT boundary decision that affects both. No amount of prompting makes the AI aware of the boundary that was never in the files it was given.
Category 5 — Governance decisions. Approving a deviation from an enterprise security principle. Signing off on a compliance control. Deciding that a pattern change applies across all delivery teams. The architect assesses the options and proposes the path within the authority assigned — but AI cannot sign it, and a language model's assessment of compliance is not a compliance attestation. Under NIS2 Article 21, cybersecurity risk-management measures must be approved and accountable to named individuals in the organisation. The AI is not one of them.
Two questions that draw the line
For any infrastructure task you are considering automating, two questions put it in the right category.
Question 1 — what is the worst-case consequence of this output being wrong?
If the answer is "a naming violation we fix in five minutes," automate freely. If the answer involves privilege escalation, network exposure, cross-environment data flow, or a compliance attestation, you are in Category 2 or above. The severity of the consequence determines how much human review the output needs before it ships.
Question 2 — who is accountable if this configuration causes an incident?
Name a person. If that person would be comfortable learning the configuration was generated and deployed without their review, you are in a low-consequence category. If that person needs to have seen it before it goes to production — whether by architecture policy, compliance obligation, or organisational accountability — then the automation must include a human gate, not just a tool check.
The accountability test is not about distrust of the AI. It is about the explicit operating agreement your organisation runs on. When both questions point toward human review, that review is not optional overhead. It is the governance structure working as designed. And when a decision exposes that an existing principle needs to change — not an exception, a revision — that is precisely when governance structures exist: to assess, challenge, and formally update the frame that everyone builds within.
Four failure modes worth naming
In practice, the automation mistakes I see most often fall into four patterns.
IAM at scale. A team uses AI to generate IAM policies across fifty accounts without a consistent permission boundary baseline. The individual policies look reasonable. The cumulative effect is an IAM landscape nobody has a complete mental model of. Fix: establish the permission boundary baseline first, encode it as a Checkov check or OPA Rego policy, then let AI generate within that constraint.
Module version drift. A Terraform module is AI-generated, reviewed once, and added to the internal registry. Teams start using it. A provider releases a breaking change. Three delivery teams are now on different versions of the same module with no documented upgrade path. Fix: every module in the registry needs an owner, a version policy, and an upgrade protocol. AI does not provide any of those by default.
Missing organisational context. AI generates a valid DNS zone configuration that happens to overlap with a zone already delegated to a third-party provider — a detail that was not in the files it was given. Or a storage policy that conflicts with a CISO exception that lives in a Confluence page. Or a network segment that crosses an OT boundary in a way that was never documented anywhere. Fix: the architect's organisational knowledge is the thing that is not in the AI's context window, and no prompt engineering fully compensates for it. Category 4 exists for this reason.
Automated compliance attestation. A team prompts AI to describe how their infrastructure meets a specific NIS2 Article 21 control and uses the output in a compliance report. The description reflects what the prompt said, not what the infrastructure does. Fix: compliance attestation requires evidence from the actual running system — not a language model's interpretation of a configuration description.
Start here: the governance matrix
The first artefact is the governance matrix. Take your team through the five categories with your actual infrastructure tasks: name them, put them in a category, agree on the validation step for each. The two questions are the workshop tool.
A simplified version looks like this:
| Infrastructure task | Worst-case consequence | Category | Gate |
|---|---|---|---|
| Resource naming / tagging | Naming violation, one resource | 1 — Automate | Naming standard |
| IAM policy for production | Privilege escalation | 2 — AI drafts + validate | Checkov / OPA + review |
| Shared VPC module | Misconfiguration template | 3 — Architect decides | Architect sign-off |
| OT-to-cloud connectivity | OT boundary violation | 4 — Architect leads | Architecture board |
| NIS2 control attestation | Regulatory liability | 5 — Governance | CISO / named accountable |
Run this against your current AI-assisted tasks in a single working session. What it produces is something the AI tools cannot produce: an explicit organisational agreement about what gets automated, what gets reviewed, and who is accountable for each category.
That agreement is the architectural runway from which every team's AI-assisted delivery should operate. Without it, teams improvise — and in an AI-assisted environment, the machine fills the vacuum.
A governance matrix template will be available as a toolkit at delfen.ai/toolkits. Subscribe below to be notified when it lands.
Next
Article 3 in this series puts the policy-as-code gate directly in the pipeline: how to configure OPA Rego policies as a required CI/CD check so that the Category 2 validation is automated and cannot be skipped — and what to do when a policy check catches something the human review process missed. For teams running HCP Terraform or Terraform Enterprise, I'll also cover how HashiCorp Sentinel fits alongside OPA in the same pipeline.
If you want the series as it lands, subscribe below.
If you can't beat them, lead them.
Sources & further reading
- Open Policy Agent documentation — CNCF, 2025
- Checkov — open source static analysis for infrastructure as code — Bridgecrew (Palo Alto Networks), 2026
- HashiCorp Sentinel — policy as code for HCP Terraform and Terraform Enterprise — HashiCorp / IBM, 2026
- NIS2 Directive Article 21 — Cybersecurity risk-management measures — European Union, 2022
- Deployability-Centric Infrastructure-as-Code Generation (DPIaC-Eval) — Zhang et al., FSE 2026 (91.6% of AI-generated IaC fails security checks on first pass)