What ‘Governed AI’ Actually Means in an ERP Context
‘Governed AI’ is becoming a common phrase in the enterprise technology conversation. It is worth being precise about what it actually means – and what it requires – before the term loses its meaning entirely.
Governance is one of those words that accumulates definitions. Ask ten technology vendors what governed AI means and you will receive ten different answers — most of them reassuring, few of them specific. Governed AI means the AI operates within guardrails. Governed AI means there is a human in the loop. Governed AI means the AI is responsible.
These answers are not wrong. They are insufficient. In an ERP context specifically, governed AI has a precise meaning — and that precision is what separates a genuine governance capability from a marketing claim.
Here is what governed AI actually requires in a Business Central environment.
A policy framework the business defines — not the vendor
The first requirement of governed AI in an ERP is that the governance rules are set by the business, not inherited from the software.
This is a more important distinction than it appears. An AI system that has its own built-in governance defaults — thresholds, confidence levels, approval triggers — may be well-designed. But it is still an AI system making assumptions about how the business operates and what level of autonomy is acceptable. Those assumptions may not match the business’s actual risk tolerance, its audit requirements, or its regulatory environment.
Genuinely governed AI in Business Central allows the business to define the policy framework within which the AI operates. Which transaction types may be processed autonomously within defined parameters? At what value threshold does an action require human approval before execution? Which accounts, which items, which customer segments are excluded from automated processing entirely? Which team member or role is the designated approver for which category of exception?
These are business decisions. They belong to the finance director, the operations lead, and the compliance team — not to the software configuration defaults.
A confidence score on every decision
The second requirement is that every AI decision carries a confidence score — a quantified statement of how certain the system was when it made the decision, and whether that certainty was above or below the threshold required for autonomous action.
This matters for two reasons. First, it determines the routing. A decision made at high confidence within policy guardrails proceeds automatically. A decision made below the confidence threshold routes to a human approver with the AI’s recommendation and the reasoning behind it. The confidence score is the mechanism that distinguishes autonomous action from supervised recommendation.
Second, it creates a reviewable record. When a finance controller or an auditor reviews the AI’s activity, they are not reviewing a list of outcomes. They are reviewing a list of decisions, each with its confidence level, its triggering rule, and its routing outcome. That is a fundamentally different audit experience from reviewing a transaction log and trying to reconstruct what the AI was doing.
A reason code on every action
The third requirement is that every AI action carries a reason code — a structured explanation of why the action was taken, which rule applied, and what data the AI was acting on when it made the decision.
Reason codes are what make AI decisions contestable. If a pricing action looks wrong, the reason code shows which pricing rule applied and at what confidence level. If a subscription term was processed differently from what the customer expected, the reason code shows what the AI read and how it interpreted the contract. If an access assignment was made that the auditor is questioning, the reason code shows the trigger condition and the policy the assignment was made under.
Without reason codes, AI decisions can be audited for outcome but not for process. With reason codes, every decision has an explanation — and every explanation can be examined, challenged, and if necessary corrected.
A rollback capability
The fourth requirement is that AI actions can be reversed. Not every action — some ERP transactions, once posted, have downstream consequences that make simple reversal impractical. But the governance framework should include a defined rollback process for AI-initiated actions within a specified window, with a complete record of what was reversed, by whom, and why.
Rollback is the safety net that makes the governance framework credible. An organisation that can say with confidence ‘if the AI makes a wrong decision, here is exactly how we reverse it, who authorises the reversal, and how quickly it can be done’ is an organisation that has done the governance work properly. An organisation that cannot answer that question has a governance framework that exists on paper but has not been tested in practice.
An approval workflow that is part of the process, not an override of it
The fifth requirement is that human approval — where the governance framework requires it — is built into the process, not grafted on top of it.
There is a version of ‘human in the loop’ that is performative: a confirmation screen that appears before high-value actions, which approvers routinely click through without reading because the AI has never been wrong before. This is not governance. It is the appearance of governance.
Genuine approval workflow means the approver receives the AI’s recommendation alongside the confidence score, the reason code, and the relevant context — the data the AI was acting on, the rule it was applying, and the exception that triggered the review. The approver is in a position to make a genuine decision, not just ratify a system output.
The test that separates governance from the appearance of governance
Here is the test worth applying to any AI system operating inside an ERP. Ask it five questions.
Can you show me the confidence score on this decision? Can you show me the reason code? Can you show me who — or what threshold — determined that this decision was eligible for autonomous action? Can you show me what the rollback process is if this decision turns out to be wrong? And can you show me the policy document that the business approved, within which this AI has been authorised to operate?
If all five questions have clear, specific, documented answers — the AI is governed. If any of them cannot be answered, the governance is incomplete.
The phrase ‘governed AI’ is worth preserving. The way to preserve it is to be precise about what it means.
Let’s chat further.
"*" indicates required fields
