AI programme management
AI governance: assign responsibility before release
Make AI governance operational with clear decision rights, release gates and incident ownership. Use a charter that your team can apply to real work.
An AI system gives a customer the wrong answer. Engineering can change the prompt. Operations can suspend the workflow. The business sponsor can approve a narrower use case. Who decides, and who tells the affected customer? AI governance becomes useful when those questions have answers before the incident.
A policy can express the organisation's intentions. An operating charter turns them into decisions that people can make under pressure. This article focuses on accountability: authorised uses, release decisions, changes and recovery. For roadmap, funding and programme structure, use the AI programme management guide.
Govern the workflow, including the people around the model
Start with a boundary statement. Describe who uses the system, what inputs it receives, what it produces and what happens next. An internal draft-writing assistant and an agent that sends customer emails may use the same model. Their permissions and failure consequences differ because the surrounding workflow differs.
Include the actions people take after reading an output. If a colleague uses a draft as a contractual statement, “internal use only” does not describe the real boundary. Observe how the work actually moves. Ask operational teams where model suggestions become customer promises, records, approvals or changes to another system.
The OECD AI Principles connect accountability with roles, context and traceability. The practical charter below is an editorial way to organise those responsibilities, rather than a statement that a project meets any legal requirement.
Keep a versioned inventory entry for each workflow. Name its business purpose, owner, permitted users, input sources, supplier dependencies and current release. An inventory of tool names alone cannot tell you who should act when an output is wrong. The same tool may support several workflows with different accountable owners.
Give responsibility the authority and time it needs
Responsibility is hollow if the named person cannot pause a release, access evidence or obtain help. When assigning an operational owner, state what they can decide and which resources they can call on. If every routine change needs the sponsor's approval, the sponsor becomes an unplanned service desk.
Separate business acceptance from technical validation. A developer can show that an integration works; that does not establish that its output is appropriate for the task. A domain reviewer can assess factual suitability; that does not establish that access controls work. Both judgements should enter the release decision.
NIST's AI RMF core explicitly addresses documented responsibilities and executive accountability. Use those principles to ask whether a named owner has real decision rights. This is stronger than collecting initials on a document without specifying what each signatory has accepted.
Avoid making one person responsible for every aspect of the system. Instead, appoint one accountable decision owner for each material decision, supported by people with relevant expertise. There should still be a clear route when those experts disagree. Record who resolves the disagreement and what evidence they need.
Write a decision charter, not a directory of job titles
A responsibility matrix helps when its rows are decisions. “Governance”, “quality” and “security” are too broad to guide an action. Replace them with decisions such as approving input sources, authorising an external action or accepting a residual risk after evaluation.
Swipe or use the arrow keys to see every column.
| Decision | Evidence required | Accountable role | People who contribute |
|---|---|---|---|
| Permit a workflow | Purpose, users, sources, exclusions | Business service owner | Operations, security, relevant specialists |
| Approve an input source | Ownership, currency, access boundary | Data or content owner | Domain reviewers, engineering |
| Authorise release | Evaluation, fallback, operating capacity | Release decision owner | Engineering, domain and operational reviewers |
| Change external permissions | Action scope and failure scenarios | Authorised system owner | Security, service owner |
| Pause unsafe operation | Incident signals and affected scope | On-call operational authority | Technical and business responders |
| Restart after an incident | Correction evidence and residual issues | Named restart authority | Incident team and affected workflow owner |
This table is a starting point, not a universal organisational design. In a small team, one person may hold several roles. Make that overlap visible and arrange independent review for consequential decisions. In a large organisation, avoid adding contributors who have no defined question to answer.
Put a time expectation beside decisions that can block work. It should reflect genuine reviewer capacity. If a reviewer cannot respond, the workflow needs a fallback or a narrower service promise. A target in a charter does not create capacity; it gives the team something concrete to discuss and staff.
Define release gates around observable evidence
A gate needs a question, evidence and an outcome. “Quality approved” leaves too much implicit. “The agreed task set meets the factuality criteria, with unresolved severe failures recorded and reviewed” lets the decision owner inspect what was tested.
Use a small set of gates appropriate to the workflow. A purpose gate establishes the task and exclusions. An input gate establishes authorised, current sources. An evaluation gate reviews performance and known limitations. An operating gate checks monitoring, reviewer capacity and fallback. A release gate records the final scope and decision.
Do not use these labels as a ritual sequence. An input change may reopen evaluation after release. A new audience may change the purpose boundary. The guide to evaluating AI output explains how to make the quality evidence specific enough to inform those decisions.
A conditional approval must include the condition, owner, deadline and allowed interim scope. “Approved subject to review” is ambiguous if no one knows whether production can begin. If the condition cannot be fulfilled, specify whether the approval expires, the scope narrows or the workflow returns to discovery.
Hypothetical example: a sales assistant changes its role
Imagine a hypothetical team that uses AI to draft answers from approved product documents. People inspect each draft and send the final message themselves. The team then proposes adding a button that sends the draft directly. This is an illustrative scenario, not a reported project or client result.
The engineering change may be small. The governance change is substantial: the system now takes an external action. The charter asks who may enable sending, which messages are eligible, what preview the sender receives and how an incorrect email can be investigated.
The content owner remains responsible for approved statements. The service owner decides whether the new workflow is acceptable for the task. Security reviews the sending permission. Operations tests the pause mechanism and escalation route. None of those responsibilities disappears because the model previously performed well as a drafting aid.
The release decision could keep sending disabled while the team measures review behaviour and verifies the controls. That is a concrete decision with evidence to gather. A blanket “AI approved” label would fail to explain the difference between assistance and action.
For marketing tools, connect the decision with the guide to choosing AI marketing tools, so operational responsibilities enter the selection before procurement.
Make change control proportional to the change
Agree which changes require renewed review. Examples include a new model version, a new source collection, a changed prompt, different permissions, a new user group or a revised business rule. Not every wording adjustment needs the same approval process, but the team should document why a change is considered routine.
Keep an evaluation record tied to the released configuration. If you cannot reconstruct the model, prompt, sources and relevant settings, a passing evaluation may refer to something no longer running. Supplier-managed changes deserve particular attention: the team may need monitoring and renewed testing when it cannot control the timing.
A risk register helps decide how much evidence a change needs. Link changes to failure scenarios rather than treating every update as equally important. A minor display change and a permission to modify customer records should not share an identical gate.
Also govern temporary exceptions. Record why the normal control cannot be applied, who accepts the exception, how long it lasts and how the team will detect trouble. Exceptions without expiry often become the real process while the formal charter describes a different one.
Rehearse an incident before the first one arrives
Use a tabletop exercise with a plausible failure. Give the team an incorrect customer statement, a missing source document or an unexpected external action. Ask participants to identify the affected workflow, preserve evidence, stop the action, escalate and decide what communication is needed.
Watch where people hesitate. An exercise reveals whether an owner is reachable, whether logs are useful and whether the pause mechanism needs an unavailable administrator. Fix those practical gaps. A successful rehearsal demonstrates a particular response path; it does not prove that every future incident will be handled well.
Include recovery in the exercise. Stopping the system can leave unfinished work, queued messages or people using old outputs. Define how those cases return to a manual workflow and how the team prevents accidental reactivation. The human-in-the-loop workflow guide covers review and escalation at the task level.
Do not confuse incident learning with blame. The objective is to find which control, assumption or handoff failed and what evidence supports the correction. A report that says “human error” without examining workload and permissions rarely improves the system.
Measure whether decisions can actually be made
Useful governance measures include unresolved decisions, time awaiting approval, overdue source reviews, open exceptions, failed controls and response times during incidents. These are diagnostic signals. Interpret them alongside the severity and context of the work rather than celebrating a large number of approvals.
Test the charter through a limited rollout. Observe whether people know their permitted actions, find the correct evidence and escalate uncertain cases. Record departures from the intended workflow. If people repeatedly bypass a gate, investigate capacity, clarity and task fit before adding another mandatory form.
Governance has limits. A responsibility matrix cannot establish legal compliance, guarantee correct output or replace specialist assessment of consequential uses. It can make decisions traceable and improve the organisation's ability to respond. Revisit it when the workflow or its risk changes.
To begin, choose one AI workflow and identify the people who can approve it, change it, pause it and restart it. If any answer is “everyone” or “someone in IT”, the charter needs another pass. To structure those decisions with your team, tell me about the programme.
Apply this to your project
Tell me the decision you are facing, the constraints and what you have already tried.
Keep exploring
AI project risk register: turn concerns into controls
Build an AI project risk register around failure scenarios, owners and tested controls. Use a worked example to review residual risk before release.
AI roadmap prioritisation: choose what to build first
Prioritise an AI roadmap around evidence, dependencies and measurable value. Use a practical decision sheet to choose the next project with confidence.
Evaluating AI output: a practical quality scorecard
Evaluate AI output with task-specific criteria, representative cases and independent review. Build a scorecard that informs a clear release decision.