Document First, Then Apply: AI Meets Regulated Change Management

Regulated environments already trail their commercial twins. Anyone operating under FedRAMP or the DoD impact levels in the United States, IRAP in Australia, or C5 and SecNumCloud in Europe knows the pattern: features arrive quarters later, the tooling is a generation behind, the government estate runs the older version of everything. The cause is not technology. Every change pays a process toll, so fewer changes get made. Call it paperwork physics.

Now project this further out as AI starts enabling a faster velocity of change. The most mature commercial engineering organizations can at least absorb the application half of that stream: fifteen years of continuous delivery built them a fast lane for code, even while everything beneath it is still hand-carried. Many enterprises are somewhere short of that. And the regulated estate has no fast lane at all. There, even an application deployment, the thing the commercial world ships daily with minimal ceremony, sits behind a change request, initiated and managed by someone other than the engineer who made the change. The gap between what commercial customers have and what government customers are allowed to run keeps growing. I have seen the pain personally: federal customers waiting years for capabilities their commercial peers already had.

And a stale environment is not a safe one. The most sensitive estates end up running the oldest code, the unpatched dependency, the workaround that was supposed to be temporary. Staleness is itself risk. That is the uncomfortable endpoint of the current trajectory: a compliance process built to reduce risk becomes the mechanism that accumulates it.

There is only one honest way out of this. The gate cannot be loosened; the controls exist for reasons. The stream of change will not slow; AI guarantees that. The only variable left is the cost of putting a change through the gate, and this post is about collapsing it. In a previous post I argued that AI for platform engineering is the creation of valid declarative configuration and the evaluation of the path from one state to the next, not the supervision of an agent's actions. Here is where that argument stops being philosophy and becomes a compliance requirement.

In these environments, change management has run on the same contract for decades: describe the change first, get it approved, then execute exactly what was described. The System Security Plan describes what the system is. The change request describes what it will become. The assessor and the change authority approve a document, and the operation that follows is expected to match the document. Document first, apply second. Every audit you will ever face is, at bottom, a comparison between the paper and the reality.

Now put an AI agent in that world.

The stochastic problem

Agents are stochastic. Ask one to solve the same problem twice and you will get two answers, often both reasonable, rarely identical. That is not a flaw to be patched out of the models; it is what generative systems are. And it collides head-on with the regulatory contract, because a change authority asks two questions before anything touches a production system:

What will change? And how will it be done?

An agent operating live against production cannot answer either question until after it has acted. Whatever it tells you in advance is a prediction about its own behavior, and the whole premise of stochastic systems is that such predictions are unreliable. Post-hoc review, the pattern most AI-operations products offer today, inverts the regulatory contract: apply first, describe second, hope the description passes. In a regulated environment that is not a weaker form of compliance. It is noncompliance, by construction.

Look carefully at where security and compliance leaders are drawing the line, because it is more precise than "cautious about AI." Agents that produce artifacts are already inside the tent: review agents commenting on code, SRE tools analyzing logs and drafting root-cause summaries, assistants writing runbooks. What remains untrusted is the act of making a change: an agent whose output is not an artifact for a human to consider, but an action against a live system. That caution is not backwards. It is exactly right, for two reasons. An actor that cannot state its actions in advance cannot participate in a describe-then-approve regime. And an actor that is not human cannot be held accountable for its actions. A regulatory regime is an accountability structure before it is anything else: every control, every approval, every audit assumes that at the end of the chain there is a person who answers. An agent cannot answer. "The model made a mistake" satisfies no assessor, no regulator, and no customer.

The wrong fix

I'm seeing the industry reach for the same instinct everywhere: wrap the agent in action monitoring, watch every command, allow or block or escalate. I have written about why that model is not appropriate for platform engineering. In a regulated context it has a sharper problem: regulators do not accredit actors, they approve changes. An allowlist over an agent's commands is a statement about who may do what. A change board wants a statement about what will become different and how. The two do not translate. You cannot show an assessor a policy file over shell commands and call it a change description.

The resolution: confine the randomness to authoring

The way through is not a better-behaved agent. It is an architecture that puts the stochastic step on the correct side of the approval gate.

Let the agent be as creative, as variable, as stochastic as it likes, in one specific place: producing an artifact. Declarative configuration describing the target state, and a plan describing the movement to it. It does not matter that two runs of the agent would have produced two different artifacts. Whatever path the agent took, the output is a concrete, inspectable thing, and at that moment the variability collapses. The artifact does not change when you read it twice.

Then the regulatory contract proceeds exactly as written, with better inputs than it has ever had:

What will change? Computed, not narrated. The difference between the current declared state and the proposed one is mechanical: which resources are created, which are modified in place, which are destroyed or replaced. A blast-radius classification falls out of the diff before anything runs, and a change that destroys nothing can be distinguished from a change that replaces a database, statically, with the ceremony scaled accordingly.

How will it be done? Declared, not improvised. The plan is data: which environments move in what order, what metrics must hold within what bounds for how long before the next step proceeds, what conditions trigger retreat, what the rollback path is and whether it has been rehearsed. This is not a runbook for a human to interpret, and not a skill for an agent to follow with its own judgment after review. Both of those put a stochastic interpreter downstream of the approval, which is the exact failure being fixed. It is a deterministic, machine-readable description of how the task will be performed, executable without interpretation. What was approved is what runs, byte for byte, because the only thing that touches production is a deterministic actuator executing the approved artifact.

Notice that this downstream determinism is not a new demand invented for AI. It is the direction infrastructure has been moving for fifteen years. Terraform exists because we stopped trusting hands at consoles. Argo exists because we stopped trusting kubectl against production. Every generation of tooling has shrunk the zone of human improvisation after the approval, and we called it progress each time. We just never finished the job. The runbook, the change window, the engineer performing the migration by hand at two in the morning still live downstream of the gate. And even where the tools are fully adopted, look at what remains: the change that is really five commits across three repositories and two technologies, merged in an order dictated by experience and unwritten policy; upgrade one cluster at a time; run the pre-checks before deploying; watch the metrics before promoting to the next environment. Each individual apply is deterministic; the campaign is a person walking between machines, deciding when to pull each lever. The tools made the steps trustworthy. The sequence is still improvised. That is why the approved artifact has to carry the plan and not only the target state: the ordering, the gates, and the metric thresholds are precisely the part of today's process that still lives in someone's head. Keeping the agent on the correct side of the gate finishes what Terraform and Argo started, and the destination is better than today's process, not merely equal to it: an approval regime where nothing downstream of the gate improvises, human or machine, is stronger than the one we currently defend.

The uncomfortable mirror

Here is the part worth sitting with: the stochastic-executor problem did not arrive with AI. Humans are stochastic executors too. Today's change board approves a prose description, and then an engineer at two in the morning performs an interpretation of it, improvising within the description, and sometimes beyond it, under pressure, from memory. The gap between the approved document and the performed change has always existed. We papered over it with runbooks, peer review, and trusted individuals. In the most sensitive environments the papering is explicit about where the trust lives: e.g. only US persons may operate the system. Whatever you think of that rule, notice what kind of rule it is. It attaches trust to an attribute of the actor, a passport, not to any property of the action or the resulting state. It is the regime admitting that, lacking a way to evaluate the change itself, it must grade the person.

And that papering worked, barely, for one reason: there was a trusted human in the middle of it. The engineer performing the change carried context no document held. They knew what was fragile, what had bitten the team before, which customer was mid-audit, when to stop and ask. The approval was never really an approval of the document. It was a delegation to that person's judgment. The document was a summary; the human was the control.

AI agents remove that person, and the industry's reflex, put a human in the loop, does not put them back. Ask the honest question: does the human in the loop understand what they are approving? An approver shown a stream of proposed commands, or a thousand lines of generated change, has neither the context nor the intent that made the old middle-human trustworthy. They are not the seasoned engineer exercising judgment; they are a signature on work they cannot evaluate, at a pace that guarantees the evaluation stays shallow. Approval without understanding is not accountability. It is rubber-stamping with better paperwork, and it launders responsibility rather than locating it.

So the real question is not whether a human is in the loop. It is what the human is given to judge. A stream of actions is not judgable. A consequence is: this change destroys nothing, modifies these two resources in place, rolls out one environment at a time behind these metric gates, retreats on breach, and has already executed successfully five times in pre-production. That is an object a human can genuinely evaluate, at the altitude where human judgment actually operates. The trusted human of the old regime is not replaced by a checkpoint in an agent's workflow. They are replaced by two things: the rules they ratified in advance, and the specific, fully described consequences they approve with the evidence in front of them.

Binding approval to an executable artifact closes a gap that predates the technology that made us notice it. In that sense the AI question is clarifying rather than threatening: it forces regulated operators to admit that "approve a description, then have an actor improvise" was always the weak link, whoever the actor was. The structure held only as long as the trusted individuals could hold it. Overwhelm them with multiples of today's change volume, or swap in stochastic agents, and the trust the whole regime rested on is gone either way. A regime where the approved thing and the executed thing are the same object is stronger for human-driven change too.

What the regulator gets

Once change flows this way, several of the most expensive process controls start to collapse into technical ones:

None of this removes the human from the loop. It moves the human to the two places regulators actually want them: ratifying the rules the machinery enforces, and approving specific, fully described consequences. And it answers the accountability objection directly, because accountability never transfers to the machine. The agent authored a proposal; a named person approved the exact artifact, with the diff and the classification in front of them; the record binds the two together permanently. When something goes wrong, there is a person who answers, and they answer for a decision they demonstrably made with the evidence demonstrably in hand. That is a stronger accountability chain than most human-only change processes have today. Even the personnel rules keep their real purpose: the named approver remains a person the law can reach. What changes is that the trust in the work itself no longer rides on anyone's passport; it rides on the artifact, the classification, and the evidence. What disappears is improvisation, and improvisation was never a compliance feature.

The gap, closed the only way it can be

Return to where this post started: the widening gap between regulated and commercial estates. Loosening the gate is not an option; the controls exist for reasons this post takes seriously. The only lever left is the cost per change: make the description, the classification, the evidence, and the execution mechanical, so that ten times the change survives the same scrutiny.

And the gain is not only that approval gets cheaper. Execution gets faster, because nothing downstream of the gate needs to be figured out. The destination is approved. The plan is approved. What remains is the practiced, mechanical performance of declared steps: the same rehearsed transition, executed identically for the hundredth time, at machine pace, overnight, in parallel, waiting on no expert's calendar. There is no need to be innovative after the gate, and work that requires no innovation is exactly the work machines do fast. Today's regulated change spends its scarcest resource, senior engineers, on execution. This model spends them only on judgment. That is where the throughput comes from: a regulated estate running this way does not merely keep up. It gets fast.

Regulated operators will not adopt the artifact-bound model because it is novel. They will adopt it because it will become the only way to keep up.

The rule

So the answer to "can AI operate regulated infrastructure" is neither yes nor no. It is a rule:

Stochastic processes may author. Only deterministic processes may apply. And approval binds to the artifact in between.

Notice that the industry has already adopted the first half of this rule by instinct: artifact-producing AI is welcomed everywhere, and acting AI is resisted. The rule only makes the instinct explicit, and then completes it.

Regulated environments do not need to ban AI. They need to ban improvisation in production, for agents and humans alike, and they have always needed to. The describe-then-approve contract that makes agentic AI look impossible is, run through a declarative architecture, the exact contract that makes it safe.

Ashley Flavel is the founder of Cloudstrate.ai, where this model is in active development. If your team has a big infrastructure project ahead — a new region, a compliance environment such as FedRAMP, a Kubernetes upgrade across your fleet — I am looking for early partners to prove this model on real infrastructure. Talk to me about partnering with Cloudstrate.