Almost every infrastructure leader I talk to says they’re confident they can govern AI-assisted changes to their environment. Far fewer can point to a written policy that actually enforces it.
We saw the same disconnect in our 2026 Infrastructure Automation Report. Among more than 400 platform and engineering leaders surveyed, 86% said they were confident in their ability to govern AI-assisted infrastructure. Yet only 30% had a formal governance policy in place.
I don’t think that gap is simply overconfidence. I think it exposes something infrastructure teams rarely had to acknowledge before: for years, slowness itself was a form of governance. AI just removed it.
The Guardrail Nobody Wrote Down
Writing infrastructure code used to be expensive. It took specialists, it took time, and relatively few people in an organization could confidently stand up a new VPC, change a production network, or refactor a Terraform module.
That difficulty created friction, but it also created safety. It limited how many changes could be in flight at once. It kept those changes in the hands of people who understood their blast radius. And it made reviews relatively cheap. If a module took three days to write and twenty minutes to review, review was rarely the bottleneck.
None of this appeared in a governance policy. It was simply a property of the work. Then AI collapsed the cost of producing infrastructure code.
The engineers didn’t suddenly become less responsible. What changed was the constraint that used to absorb mistakes and limit change volume. In many organizations, nothing explicit was built to replace it.
That’s what I see in the gap between 86% confidence and 30% formal governance. Teams trusted the people making changes, and for years the pace of the work helped make that model viable. Now infrastructure can be generated far faster than humans can understand it.
I recently talked this through in a webinar with Faisal Afzal, a CNCF Ambassador and Platform Engineering Ambassador who has spent more than 20 years building and advising on enterprise infrastructure. His version is blunter:
“Confidence without a policy is not governance. It’s a feeling, and the feeling does not survive contact with an agent making changes at 3 a.m.”
The organizations handling this transition best aren’t necessarily doing anything futuristic. They already had high infrastructure-as-code coverage, enforceable policy, standardized paths, and tightly scoped access.
In other words, the boring infrastructure work suddenly became an AI advantage.
Review Is Now the Constraint
AI has inverted the economics of infrastructure change.
Writing used to be expensive and reviewing was cheap. Now writing is cheap and understanding is expensive.
AI can generate infrastructure code almost instantly. Humans still have to reason about dependencies, state, blast radius and everything else surrounding that change. In some ways, AI-generated code is harder to review than a colleague’s code because you don’t get the author’s reasoning along with it.
So the queue builds at the one point in the system that still runs at human speed.
Our data suggests we’re already seeing the result: 76% of teams say they are shipping AI-generated infrastructure code with little review, and about a third say some of it receives no review at all. Ninety-three percent reported experiencing an AI-related infrastructure issue or incident.
This isn’t necessarily a discipline failure. Nobody sat down and decided that review no longer mattered. The review process was designed for a world in which producing the change took longer than evaluating it. When that relationship reverses, review gets compressed until the process can move again.
Even organizations with mandatory human approval aren’t immune.
One platform engineer at a security software company described an increasingly common failure mode. His organization requires human approval for every production change. But when a reviewer doesn’t fully understand an AI-generated plan, what is the natural thing to do now?
Ask AI to summarize it.
If that summary misses something important and the reviewer trusts it, the organization can satisfy every requirement in its change-management process while still having nobody in the loop who truly understands what’s about to happen in production.
That’s not meaningful human review. It’s humans approving machine interpretation of machine-generated work.
Correct Code Can Still Be the Wrong Change
The same team gave me one of the clearest examples I’ve heard of why infrastructure is particularly vulnerable to this problem.
They used AI to help build out a project, and initially it worked well. Then the AI encountered a legacy project that was still using deprecated resource definitions. It saw the deprecation warnings and did exactly what the documentation suggested: it replaced the old resources with the new ones.
Technically sensible. Operationally catastrophic.
Because of the way the existing environment had evolved, running the two together would have deleted network access. No automated check caught it. Humans who understood the environment recognized what would happen and stopped the change.
The AI wasn’t careless. It followed the documentation. It just didn’t know what else was in the building.
That’s a critical distinction for infrastructure teams. Infrastructure correctness is contextual. A resource definition can be valid. A Terraform plan can look reasonable. A proposed change can follow the documentation exactly and still be unsafe because of the state, dependencies, and history surrounding it.
AI makes producing the change easier. It doesn’t automatically provide that institutional understanding.
Agents Can’t See Your Tribal Knowledge
A human engineer walks in Monday morning already knowing what happened Friday. They know which cluster nobody touches before the weekend, which database migration still makes everyone nervous, and which supposedly deprecated component can’t actually be removed yet.
An agent starts with whatever context we’ve made available to it.
As Faisal put it:
“The rule has to live in the pipeline, not in a Confluence page.”
It’s useful to have the rule in Confluence. But if an agent can’t see it and the system can’t enforce it, that rule doesn’t exist at execution time.
Every piece of tribal knowledge your infrastructure team relies on is, from an agent’s perspective, a rule that was never made.
This is why I’ve stopped thinking about AI as the cause of these problems. It’s an amplifier. Governance gaps, drift, inconsistent processes, privileged access, and dependence on tribal knowledge all existed before generative AI.
AI simply removed the friction that was hiding them.
What Prepared Teams Have Already Done
The encouraging part is that the organizations handling AI-assisted infrastructure well didn’t discover some entirely new operating model. They had already made much of their infrastructure judgment explicit and enforceable.
There’s a fairly concrete sequence for doing the same.
1. Manage all your infrastructure as code.
You can’t enforce policy against infrastructure you can’t see.
In our research, the organizations we classified as pioneers had 91% of their infrastructure managed as code. The most exposed organizations were at just 14%.
Governance coverage can never exceed infrastructure coverage. A console change or manually edited resource sits outside the controls you build around code.
Before worrying about sophisticated AI governance, get the estate under management.
2. Turn institutional knowledge into executable controls.
Most organizations already have policies. The problem is that many live in spreadsheets, wikis and people’s heads.
Start with the rule protecting your largest blast radius and make it executable. Public exposure, destructive operations, approved regions, required tags, approved modules, or production access shouldn’t depend entirely on someone remembering the rule during review.
A policy nobody executes is documentation. A control runs every time, in your pipeline.
3. Make the governed path the fast path.
One security leader at a fintech company told me his engineers were spending significant time trying to vibe code their own infrastructure when they could have asked the platform team and received it faster.
His response wasn’t to send a memo telling everyone to stop using AI.
He took the behavior as a signal that the approved path had too much friction. His team began building agents that already understood how to provision infrastructure the company’s way.
That’s the right lesson. If bypassing the platform is faster than using it, people will eventually bypass it. The answer isn’t simply more enforcement. It’s creating a paved path people actually want to take.
4. Give agents boundaries, not policy statements.
Treat an infrastructure agent the way you would treat a new hire with unlimited typing speed.
That means scoped and short-lived credentials, least privilege, explicit allowed actions, environment boundaries, auditability, and a way to stop the system when something goes wrong.
None of that is especially novel. That’s the point.
AI doesn’t eliminate the need for ordinary access discipline. It increases the value of having it encoded and consistently enforced.
5. Measure AI-generated changes separately.
Infrastructure teams measure human-written changes obsessively: failed deployments, review time, rollback rates, incidents, and change failure rates.
AI-generated infrastructure should be measurable too.
Tag AI-assisted changes at the source. Compare their review time, failure rate, rollback rate, and incident attribution with your human baseline.
Without that data, teams are effectively deciding where AI is safe by instinct.
Several teams I spoke with still require human review on every Terraform change and are moving deliberately because they understand that a deterministic linter and a probabilistic AI reviewer serve very different purposes.
They’re not avoiding AI. They’re being explicit about where each control belongs.
Boring Is the Flex
When I asked Faisal what he wanted platform leaders to take from all of this, he reframed the entire issue for me:
“AI did not create a single one of these gaps. Governance, review, drift. They all existed before AI arrived. The pioneers vibe code more than anyone else in the data. They just do it inside pipelines that were boring before AI, and they still are. So the question isn’t how do we govern AI. It’s why weren’t we governed already. The pioneers figured out the secret, and it’s unglamorous. Boring is the flex.”
This isn’t an argument for moving cautiously with AI. In our data, the pioneers are among the most aggressive AI adopters.
What lets them move aggressively is the boring plumbing underneath: infrastructure coverage, enforceable policy, standardized paths, scoped permissions, and observable changes.
Most of those weren’t built as AI investments. They were simply good infrastructure engineering. They reduced drift, eliminated repetitive work, made changes more predictable, and gave teams quieter weeks. Now those same investments allow organizations to increase the velocity of infrastructure change without increasing risk at the same rate.
The teams that are ready for agentic infrastructure aren’t the ones who moved fastest on AI. They’re the ones whose safety never depended on going slow.