AI governance in practice: who decides, who checks and when to review

“We use an AI writing tool” tells you very little. Drafting an internal note and sending an answer to a customer are different uses, even when they share a subscription. Describe the work, who receives the output and what happens before anyone relies on it. That gives management something concrete to approve.

Consider a fictional equipment distributor. Its service team wants AI to draft maintenance appointment replies from approved service information. Staff will check each reply and send it themselves. The proposal excludes diagnosing faults, changing warranty terms and promising a repair date that has not been confirmed.

The initial decision is whether that bounded workflow is ready for a supervised trial. It is not permission to automate the whole service desk. Writing down the boundary makes later changes visible: an automatic-send feature is a new decision, even if the supplier describes it as an upgrade.

Suppose the service manager owns the trial, but only IT can remove access and only the commercial director can change customer promises. Calling the service manager “accountable” does not resolve those dependencies. Establish who can stop the workflow, who can approve wider use and who will respond when the owner raises a concern.

For this example, the service manager can return the team to manual drafting immediately. IT maintains access settings. The commercial director must approve any change to the kinds of commitment the tool helps staff make. Each knows the route for urgent decisions. The board receives material issues through the organisation’s normal reporting arrangements; it does not approve individual drafts.

A useful practical check is to ask the owner to describe the first action they would take if the output became unreliable tomorrow. If the answer depends on an unidentified person or an unavailable committee, the approval is incomplete.

A polished reply is not proof of a successful workflow. Test representative requests, including ambiguous requests, outdated service information and cases where no answer should be offered. Check whether the reviewer can find the source and correct the answer before it reaches the customer.

Record preparation, checking and rework as well as drafting time. If an experienced colleague spends longer repairing the answer than drafting it, the initial business case needs changing. Do not turn a promising demonstration into a staffing assumption or customer service promise before testing the full task.

Keep the evidence proportionate: an agreed test set, the issues found, changes made and the reason the decision-maker accepted the remaining limitations. A statement that “a human checks it” is insufficient unless that person has the time, information and competence to check.

A scheduled review is a backstop. In this example, new source documents, a different supplier model, automatic sending, a missed warranty condition or a change in reviewer capacity should prompt an earlier check. Assign somebody to notice each kind of change; a register cannot discover a process change nobody reports.

At review, record whether the use continues, changes or stops, and why. Retain the previous reasoning so that a later reviewer can understand what was known at the time. The useful output is a defensible current decision, not a permanently green status.