The agent ran four months without an incident. Then someone widened its scope from reading inventory to posting transfer orders, and on a Tuesday afternoon it moved 400 units out of a plant that had a customer commitment sitting against them. The model behaved as designed. The governance policy said a plant manager approves any transfer over 250 units. That policy lived in a signed-off PDF. Nothing in the execution path had ever read it.
Gartner put a number on that gap in its March 2026 top predictions for data and analytics: by 2030, 50% of AI agent deployment failures will be due to insufficient AI governance platform runtime enforcement for capabilities and multisystem interoperability (Gartner, 2026). The qualifier carries the weight. Runtime enforcement across systems is a different object from an approved AI policy, and only one of the two shows up when an agent posts a transfer order.
Runtime enforcement means the governance rule sits inside the execution path rather than beside it. Before an agent writes to Business Central, a control checks what this agent is permitted to do, at this value, on this document type, and either allows the write, blocks it, or routes it for named approval. A policy document describes the rule. Runtime enforcement is the rule refusing to be skipped.
Most multi-year AI roadmaps for Business Central open on the wrong question. Which model, which Copilot licence, which vendor's agent framework. Those decisions get revisited within eighteen months anyway. The decisions that survive the roadmap are the ones underneath: what an agent is allowed to write, who signs off when it exceeds that, where the check physically runs, and what record the approval leaves behind.
From the work
Written from 5+ manufacturing and distribution engagements, 2022–2026, where agent write access to Business Central was scoped, tiered, and routed through named approval before go-live.
The AI model is the least durable decision on a Business Central roadmap
A model swap is a configuration change. New endpoint, revised prompts, a fortnight of regression testing against the same set of operational questions. Teams that have done it once stop treating it as an architectural event.
Now price the layer underneath. The write-access contract naming every Business Central table an agent may touch. The approval matrix mapping document types and value bands to named roles. The identity mapping that ties an Entra ID to an approver of record. The audit schema that captures what data an approver saw at the moment they said yes. Each of those took cross-functional argument to settle. Each one gets inherited unchanged by whatever model runs next year.
So a roadmap that sequences model selection in year one and governance in year two has the durability backwards. It commits early to the cheap decision and defers the expensive one until a pilot is already writing to production. That is the point where changing the write path stops being a decision and starts being a rebuild.
Uniform AI agent governance fails in both directions
The obvious correction is to put approval on everything. Gartner's research says that fails too, which is the part most governance pitches leave out.
A May 2026 Gartner release on uniform agent governance forecasts that by 2027, 40% of enterprises will have autonomous AI efforts partly derailed by governance gaps found only after a production incident. Shiva Varma, the Senior Director Analyst behind it, locates the cause upstream of the incident: "Enterprises are treating AI agent governance as binary, either locked down or fully trusted, and that is the root cause of failure."
Both settings break, in opposite ways. Over-restrict the simple agents and delivery slows until someone in operations builds their own workaround outside IT's line of sight, which is where shadow AI comes from. Under-restrict the autonomous ones and the operational, security, and compliance exposure arrives on its own schedule. A single approval policy applied across the estate guarantees you are doing one of these to every agent you run.
Which means the useful roadmap artefact is not an AI policy. It is a tiering model.
Autonomy and scope are separate controls for Business Central agents
Varma draws the line that most internal governance frameworks blur: "Autonomy level defines an agent's ability to act, while scope defines the breadth of data, systems and permissions it can access." Two axes, not one dial.
The distinction gets concrete fast inside Business Central. An agent that posts inventory adjustments in a single company sits high on autonomy and narrow on scope. Its blast radius is one legal entity, but it changes the ledger. An agent that only drafts purchase requisitions, across every company plus the CRM, sits low on autonomy and wide on scope. It changes nothing directly, and it can read your entire commercial position.
Rank those two by risk and most teams pick the first, then apply the same approval gate to both. That inverts the actual exposure on one axis while ignoring it on the other. The posting agent needs a value-banded approval gate. The drafting agent needs data-scope restriction and read-access audit, and gating its drafts behind human sign-off adds latency that buys nothing. Governance tiered by department, or by "is it AI," reaches neither conclusion.
Three human-in-the-loop oversight patterns for Business Central actions
Once agents are tiered, the oversight pattern follows from the tier. Work on human-in-the-loop agent oversight (Galileo, 2026) separates three, and each maps cleanly onto Business Central document types.
| Oversight pattern | Business Central actions it fits | What runtime enforces | Record it leaves |
|---|---|---|---|
| Synchronous approval | Credit hold release, PO above the approver's limit, production order override, vendor bank detail change | Write is blocked at the API boundary until a named approver responds | Approver identity, timestamp, snapshot of the data shown, action taken |
| Asynchronous audit | Reorder point proposals, item reclassification, forecast updates, reversible posting corrections | Write executes; the action enters a review queue with a defined response window | Agent identity, reviewer, review outcome, link to the reversing entry |
| Hybrid multi-tier | Weekly replenishment runs, multi-line transfer plans, batch payment proposals | Human approves the plan; agent executes lines inside the approved bounds and escalates anything outside them | Plan approver, the bounds as approved, per-line execution log, escalation events |
Read the middle column, because it is where roadmaps quietly fail. "Write is blocked at the API boundary" is an engineering commitment with a delivery cost. "Requires plant manager approval" is a sentence in a document. A programme can ship the second one in an afternoon and report governance as complete, then discover during the incident review that no system ever consulted it. The transfer order at the top of this article moved because the rule existed in the second form only.
Sequencing a governance-first Business Central AI roadmap
Reordering the roadmap costs nothing at planning stage and a great deal after go-live. The sequence that holds:
- Inventory the writes before selecting anything. Every Business Central table and action an agent could eventually post to, listed. Not the ones in the pilot. The ones in the three-year plan, because the pilot's write path becomes the platform's write path by default.
- Tier each action by autonomy and scope separately. Two axes produce four quadrants and four control profiles. One axis produces the binary Varma names as the root cause of failure.
- Decide where enforcement physically runs. Inside the write path, at the boundary the agent has to cross. A reviewer's calendar, a weekly governance forum, and a policy PDF all sit outside it.
- Define the record before the first agent ships. Approver identity, timestamp, the data the approver saw, exportable outside the vendor's dashboard. Retrofitting the audit schema after twelve months of agent activity means twelve months of undocumented actions.
- Select the model last, and plan to change it. If steps one through four are right, the change is a fortnight of regression testing rather than a governance review.
Most teams can place their own programme on that list in about a minute, and the honest answer is usually step five first. If you want a sharper read on where the gap sits, the Decision Latency Diagnostic scores all five stages of the decision path, Signal through Audit, in 12 questions.
This is what decision infrastructure means in practice, and why OpsGrid puts the approval gate in the write path to Business Central rather than in a policy layer above it. A credit hold release, a production override, a supplier payment exception: none of them post until a named person approves inside Microsoft Teams, and the approval generates the record as a side effect of happening. Swap the model underneath and none of that changes.
Frequently asked questions
What is AI agent governance runtime enforcement?
Runtime enforcement means the governance rule sits inside the execution path rather than beside it. Before an agent writes to a system of record, a control checks what that agent is permitted to do, at that value, on that document type, and either allows the write, blocks it, or routes it for named approval. A policy document describes the rule. Runtime enforcement is the rule refusing to be skipped, including by an agent nobody remembered to tell.
Does choosing a different AI model reduce AI agent deployment risk?
Very little, at the failure modes that actually stop deployments. Gartner's March 2026 data and analytics predictions attribute half of AI agent deployment failures by 2030 to insufficient AI governance platform runtime enforcement for capabilities and multisystem interoperability, not to model capability. A model swap is a configuration change measured in days. The write-access contract, approval matrix, identity mapping, and audit schema underneath it are measured in quarters, and every model that follows inherits them.
How should Business Central AI agents be tiered by autonomy and scope?
As two independent axes. Gartner's Shiva Varma draws the distinction directly: autonomy level defines an agent's ability to act, while scope defines the breadth of data, systems and permissions it can access. A Business Central agent that posts journals in one company carries high autonomy on narrow scope. An agent that only drafts, but reads every company plus the CRM, carries low autonomy on wide scope. They need different controls, and a single approval policy applied to both over-restricts one and under-restricts the other.
What should a multi-year Business Central AI roadmap sequence first?
The write inventory. Enumerate every Business Central table and action an agent could eventually write to, then tier those actions by autonomy and scope, then decide where enforcement physically runs, then define the record each approval leaves. Model selection comes last, because it is the cheapest step to revisit. Roadmaps that sequence the model first tend to discover the write-path question during rollout, when changing it costs a rebuild instead of a decision.
You will change the model. Plan not to change the write path twice. For what the same record looks like when a regulator or opposing counsel asks for it, see why a correct AI decision still needs a named approver.