January 16, 2026

MOC for AI: Deploying Models Under Management of Change

Any AI that touches a process unit runs through Management of Change before it goes live. That isn't bureaucracy to route around. It's the discipline that makes AI safe to deploy in a plant, and building for it from the start is what separates models that ship from models that stall.

  • pod-d
  • refining
  • petchem
  • governance

In a refinery or chemical plant, you don't just turn on a new system. Anything that can affect the process goes through Management of Change: a review of what's changing, what could go wrong, who's trained on it, and how it gets rolled back. AI is no exception. The moment a model can influence a process decision, it's a change, and MOC is the gate. Most AI vendors have never seen an MOC packet, which is exactly why their pilots stall at the unit fence.

For an operator, MOC isn't the obstacle. It's the specification.

Why MOC governs AI in a plant

A refinery runs as one coupled, continuous system with catastrophic failure modes. That's why the industry built MOC and Process Hazard Analysis in the first place: to make sure no change, however small it looks, introduces an unreviewed risk. An AI model that nudges a recommendation an operator acts on is a change to how the unit is run. Treating it as "just software" is how you end up with an unreviewed risk in a place that can't tolerate one.

So the useful question isn't how to get AI around MOC. It's how to build AI that moves through MOC cleanly.

Building MOC-native

AI that clears Management of Change shares a few properties, and they're design decisions, not paperwork added at the end:

  • Human-in-the-loop on anything consequential. The model advises; a qualified person makes the call that affects the process. That keeps the change reviewable and the accountability clear.
  • Documented and inspectable. What the model does, what it reasons from, and its limits are written down in terms a PHA team can evaluate.
  • A rollback path. MOC asks how you undo a change. An advisory system that a person can simply stop relying on has a clean answer.

Build those in from day one and the MOC review becomes a conversation, not a wall.

The safety case is a property of the build

You can't bolt explainability onto a black box at review time. A model whose inputs are traceable and whose recommendations carry their supporting evidence is one a PHA team can sign off on. One that produces a number with no account of why is not, regardless of how it tested. The safety case is built when the system is built, or it isn't built at all.

What the evidence looks like

Kaysee, Cortland's reliability platform, runs in operator environments on equipment health with the human in the loop and the governance documented. It's a concrete example of the pattern that clears review: advisory intelligence, traceable reasoning, a person owning the decision. The same discipline that lets it operate on critical equipment is what an MOC packet for any process-adjacent AI demands.

Management of Change isn't what keeps AI out of the plant. Designed for from the start, it's what lets the model stay in the unit instead of getting pulled at the first review.

Keep reading

Take the next step.

If this is the kind of work you want Claude doing inside your own operation, Cortland scopes engagements in three tiers: Walk (strategy), Run (build), Sprint (ongoing). Start wherever the risk fits.