Enterprise AI Governance Begins with Business Accountability

Governance that starts from a model usage policy constrains behaviour without changing it; the version that works names the business owner of each outcome and the authority they hold over it.

The policy arrived before the business knew what it owned

A large organisation decides it needs rules for AI. The rules get written quickly, because rules are easy to write and hard to implement. The result is familiar: a list of approved tools, a data handling rule, and a paragraph requiring review. It changes almost nothing, because it never says who owns the outcome of the work it governs.

Decisions continue to be made, but now below the policy. A function adopts a tool, a team routes a process through a model, a manager overrides a recommendation because the model missed a case. None of it appears in a register of exposure, so the risk has moved further from the executive who assumed it was covered.

Accountability is a business arrangement before it is a control

Governance that begins with business accountability starts from a different question. For each process in which an AI system will read, advise or act, who is the business owner of the result, what are they accountable for, and what decision rights do they hold to change the system, its inputs or its limits? These are questions for the executive who owns the process.

The authority half of the question is usually dropped. Accountability without authority is a blame mechanism rather than a governance arrangement. A finance leader accountable for forecast accuracy cannot change the pipeline that produces the data, the rules that consume it, or who overrides the output. The result is a named owner of a system nobody lets them change.

Risk tiering works only when the consequence is a business quantity

Most tiering schemes classify a use case by the sensitivity of the data or by the capability of the model, and both are inputs to the judgement rather than the judgement itself. The tier should be driven by what is at stake: whether the action can be reversed, who sees the result, how much is involved, and whether a person will look at it before it counts.

Element of the tierWhat it meansControl it implies
ReversibilityCan the effect be undone, and at what costA limit, a delay, or a hold for review
ExposureWho outside the business sees the resultHuman confirmation before it counts
AmountWhat value the action commits or movesA threshold above which an approver is required
RecurrenceHow often the action runs unattendedMonitoring on a frequency set by the tier

This is a business conversation held in business units, and it is worth having before any model is selected. It also produces what a reviewer will later ask for: a written statement of what a use case commits the business to, and by whom. The organisational work of getting past departmental boundaries is in why enterprise AI projects fail between departments.

Approval authority has to match the cost of being wrong

If a wrong output can be undone with a phone call, a lightweight check is the right control and a heavy one is waste. If it cannot be undone, the approval must be explicit, and the approver needs the evidence rather than a summary of it: the source records, the reasoning, the alternative that was available, and the decision being asked for.

Two further distinctions matter. Authority should sit with the person who carries the consequence, not necessarily with whoever funded the system. And where the same team builds, configures and approves, no independent control exists however well documented the process is.

Escalation is a designed path rather than an interruption

Most organisations have an escalation path on a slide and none in practice. The difference is a set of specifics: what triggers the escalation, who is notified, how long they have to respond, and what the system does while the clock runs. A system that keeps acting on stale confidence while a case waits will eventually act on the wrong thing.

What does not belong in a governance document

Several common items on a governance register are not governance questions at all. Whether a system behaves acceptably is a testing question. Whether its source data is fit for use is a data engineering question, and a policy saying that the authoritative record must be used is empty when two records disagree and nobody owns the definition. The distinction between data access and usable context is in why an AI agent needs more than database access.

AI is also the wrong instrument for several of these decisions. Risk tiering, authority and escalation are administrative arrangements, and conventional workflow tooling enforces them more reliably than a model.

A sequence for the first ninety days

  1. Choose one live process with a visible business owner and one outcome somebody genuinely cares about. Start where the owner has time.
  2. Write down what the owner is accountable for, and what they may change to affect it: inputs, rules, thresholds, exceptions.
  3. Describe the consequence in business terms, then set the tier, the controls and the approver from that description.
  4. Design the escalation path with a named substitute and an explicit default of inaction, and record the clock on every case.
  5. Instrument the arrangement before go-live, and review at ninety days against the decisions that bypassed the path.

The measures that tell you whether governance is real are unglamorous: the share of AI-assisted decisions with a named owner, the number taken outside the approval path, the time to close an escalation, and the number of controls changed after a failure rather than added in advance. The delivery discipline for holding this in place is in enterprise AI deployment.

Where this method stops working

The approach depends on conditions the organisation either has or has not got: an owner with both authority and time, processes defined well enough for a control to attach to, and a willingness to let some decisions be made more slowly. Where the process is undocumented, governance has nothing to attach to and the work is specification first, as in why AI cannot fix data problems nobody has defined.

It also fails when the business changes faster than the arrangement can be updated. The honest response is then not to accelerate the governance but to narrow the scope: permit only reversible actions and keep the consequential ones human.