A question like “Who owns AI governance?” is often answered with a function, a committee or a job title. That answer may describe where work sits, but it does not show who can make a decision, what evidence supports it, or where a difficult question goes next.
A more useful operating answer names an internal owner, records decision rights, identifies the evidence to retain, and sets an escalation and review path. This is an internal governance method. It does not transfer legal accountability, establish compliance by itself or replace legal advice.
Start with the decisions, not the title
Begin by listing the decisions that need an owner. Examples include approving an AI vendor, accepting a use case, deciding which data may be used, setting requirements for human review, responding to a material concern, and retiring a system. The right list depends on the organisation, its products and the systems it uses.
An organisation chart can show reporting lines, but it rarely answers those questions. A decision map makes the boundary visible: who prepares the decision, who approves it, who must be consulted, what evidence is kept, and who receives an escalation when the decision exceeds the owner's authority.
| Decision area | What to record | Evidence to retain |
|---|---|---|
| Vendor and tool approval | Who approves use, data access and contractual conditions? | Review record, contract or terms, approved-use decision |
| Use-case acceptance | Who decides whether the proposed use is within the agreed scope? | Use-case description, risk questions and decision rationale |
| Data and output handling | Which data, users and downstream decisions are covered? | Data boundary, access decision and human-review instructions |
| Escalation | Which concerns move to legal, privacy, security, product or management? | Escalation record, decision and outstanding condition |
| Review and retirement | What change or concern requires the decision to be revisited? | Review trigger, current owner and retirement or renewal decision |
Keep the legal boundary visible
The EU AI Act sets duties for providers and deployers in the situations covered by the regulation. Article 4 concerns measures that support AI literacy among staff and other people who operate or use AI systems on behalf of a provider or deployer. The provision does not prescribe a particular internal title or say that a named owner is enough on its own.
The European Commission's AI literacy questions and answers are useful context for reading the obligation. They do not replace the regulation or a legal assessment of a particular use case. Where personal data, automated decisions, employment, safety or contractual commitments are involved, involve the relevant legal, privacy and operational owners.
A decision-rights mandate therefore has a limited job. It makes internal responsibility and evidence easier to see. It does not transfer the organisation's legal accountability to the named person, make the person a legal adviser, or settle whether a particular system falls within a legal category.
Write a short mandate that can be used
The mandate should identify the owner in their current role and state what the role covers. It should describe the AI systems, vendors and use cases within scope, along with exclusions and handoffs. If the owner can approve a vendor but cannot approve the use of personal data, say that plainly.
Describe decision rights in verbs: approve, reject, pause, require evidence, consult, escalate and review. Avoid broad language such as “owns all AI”. The owner may coordinate the decision process while legal accountability remains with the relevant provider, deployer or organisation.
Name the evidence that should exist for each decision. Depending on the use, that may include a tool inventory entry, a data and access description, a vendor review, an acceptable-use decision, human-review instructions, training or briefing records, an incident record, or a retirement decision. Mark evidence that is planned or missing as such.
Finally, state the escalation path and review triggers. A new vendor, a material change in data or use, a significant incident, a concern from monitoring, or a change in applicable requirements may all justify a fresh decision. The owner needs enough authority and time to coordinate those handoffs, but the mandate should not imply that one person can decide matters assigned to another function.
Use the mandate in a real decision
Suppose a product team wants to add an AI tool to a customer-facing workflow. The owner does not simply approve or reject it from the tool name. The review starts with the proposed use, the data involved, the people affected, the vendor terms, the output, the human checks and the consequences of an error.
The decision record should show what was known at the time, which functions were consulted, which conditions were attached, and where an unresolved question was escalated. If the information is insufficient, the decision can be to pause the use until the missing evidence is available. That is a governance decision, not a promise that the system is safe or legally approved in every context.
This also keeps data governance and AI governance connected without collapsing them. A data owner may define data quality, lineage and access. An AI governance owner may coordinate tool and use-case decisions. A DPO, security lead, product owner or legal adviser may have separate authority. The mandate should show the relationship rather than assign every responsibility to one person.
Make review and evidence part of the operating rhythm
A mandate that is filed once and never revisited will stop describing the organisation. Keep the owner, scope, decisions and evidence current. Record why a use was accepted, what conditions apply, and what would cause the decision to be reviewed.
Review does not mean producing a new policy for every change. It means checking whether the original decision still describes the vendor, data, users and use. A clear trigger gives the owner a reason to reopen the decision and gives other functions a defined point at which to raise a concern.
For board context, this Deloitte analysis published by the Harvard Law School Forum on Corporate Governance is a secondary perspective, not legal authority. The useful question it raises is the same operating question: can the organisation explain who decides, what was considered and how concerns reach the right level?
What this method can and cannot show
A named owner and a decision map can show that the organisation has assigned internal work. They can connect an AI inventory, literacy activity, vendor review, use-case decision and escalation record to people who know their responsibilities. They cannot prove that every applicable requirement has been met, and they cannot replace a legal opinion, a privacy assessment, a security review or management accountability.
The practical test is whether someone can answer these questions from the records already kept: who decides, what evidence supports the decision, who must be consulted, and what causes a review? If the answer is unclear, the next step is to make that responsibility clear rather than create another broad policy.
The AI governance page covers the wider operating context. If you need help mapping one live decision, the AI decision review explains the scope, or you can get in touch with the specific question and evidence you already have.