Who owns the AI decision?

An AI use case needs an owner before it needs a model. This article looks at approval, performance review and escalation across the AI lifecycle, and at who acts when conditions change.

The question that gets skipped

When an AI use case comes up for approval, the conversation usually centers on the technology. Which model? Which vendor? How accurate is it? Is the data protected? Those questions matter. But the question that decides whether the use case stays under control for its whole life is simpler, and it is often skipped:

Who owns this decision, and who acts when it stops working as intended?

I ask that question early in every AI governance review. The answers tell me more about the strength of the program than the policy does. A strong answer names one person in the business who is accountable for the outcome, can explain what the system is for, and knows what would make them pause or retire it. A weak answer names a committee, a vendor, or “IT.”

Why ownership breaks down with AI

Traditional applications have reasonably clear ownership. A system owner approves changes, a control owner runs the controls, and audit tests both. AI blurs those lines for four reasons.

• The system keeps changing after approval. Models are retrained, prompts are revised, vendors release new versions, and the data the system sees drifts away from the data it was tested on. Approval describes a moment. The risk keeps moving.
• The work is spread across many teams. The business defines the purpose, data teams build or tune, technology deploys, risk and compliance review, and procurement manages the vendor. Each team owns a piece. Unless it is assigned on purpose, no one owns the outcome.
• AI arrives inside other products. Many organizations meet AI first as a new feature in software they already use. No one submitted a use case, so no one was ever asked to own it.
• Performance is probabilistic. A model can be right most of the time and still produce errors that matter. Someone has to decide, ahead of time, what level of error is acceptable for this purpose and what happens when it is exceeded.

None of these problems is solved by a better model. All of them are solved, or at least made manageable, by clear ownership.

Five decisions across the lifecycle

I find it useful to stop thinking about “the AI owner” in the abstract and look instead at the decisions the lifecycle requires. Each decision needs someone with the authority to make it and evidence that it was made.

Figure 1. The lifecycle has many contributors, but each stage returns to the same accountable owner.

Decision	Accountable owner	Supporting roles	Evidence an auditor expects
Approve the use case	Business owner of the process the AI supports	Risk, compliance, privacy, legal, AI governance committee	Intake record, risk rating, approval with conditions and date
Build, buy, or configure	Business owner, with the technology owner	Data science, procurement, information security, vendor management	Requirements, vendor due diligence, testing plan and results
Deploy to production	Business owner	Technology change management, model validation where applicable	Go-live approval, validation or testing sign-off, rollback plan
Accept ongoing performance	Business owner	Model or data team, operations, second-line risk	Monitoring reports, thresholds, review sign-offs, open issues
Escalate, pause, or retire	Business owner, with escalation to senior management or a committee	Risk, compliance, technology, communications	Escalation record, decision, actions taken, retirement evidence

Notice that the accountable owner barely changes. That is the point. Committees advise, specialists contribute, and second-line functions challenge. But one named person in the business carries the outcome from intake to retirement.

Approval: the questions that matter

An approval is only as good as the questions asked before it. These are the ones I look for in an intake and approval record:

1. What decision or task will the system support, and who is affected by its output?
2. What happens when it is wrong? Describe the realistic failure, not the best case.
3. Is a human reviewing outputs before they take effect? If so, can that person realistically catch errors at the volume expected?
4. What data does it use, and is that use permitted under the organization’s privacy commitments and contracts?
5. What does “working as intended” mean in measurable terms, and who decided that threshold?
6. What would make us pause or stop using it?
7. Who is the accountable owner, and have they accepted the role in writing?

Approval should also carry conditions. “Approved, subject to monthly performance review against the agreed threshold and reassessment if the vendor changes the underlying model” is far stronger than “Approved.”

When conditions change

In my experience, AI oversight rarely breaks down at approval. It breaks down later, when conditions change and no one notices or acts. The owner needs defined triggers, agreed before deployment, so that acting is a matter of following the plan rather than winning an argument.

Trigger	What it can look like	Who acts	Expected response
Performance drops below threshold	Error rate, override rate, or complaint volume moves past the agreed limit	Business owner	Investigate, decide whether to continue, restrict, or pause; record the decision
The data changes	New customer segment, new product, new data source	Business owner, with the data team	Re-test before relying on outputs for the new population
The vendor changes the model	New version, new provider, new feature enabled by default	Business owner, with vendor management	Reassess the use case; confirm the conditions of approval still hold
The purpose expands	The tool is used for decisions it was not approved for	Business owner, with AI governance	Treat it as a new use case; return to intake
A regulatory or legal change	New rule, guidance, or contract obligation	Compliance, informing the business owner	Assess the impact; adjust controls or documentation
An incident occurs	Harmful output, data exposure, complaint, or media attention	Business owner, escalating immediately	Contain, notify according to the incident plan, review root cause

What the frameworks expect

None of this is new thinking. The major AI frameworks all make ownership and accountability explicit:

• NIST AI Risk Management Framework (AI RMF 1.0). The Govern function calls for documented roles, responsibilities, and lines of communication for mapping, measuring, and managing AI risk, and for accountability structures that reach senior leadership.
• ISO/IEC 42001. The AI management system standard requires top management to assign roles, responsibilities, and authorities (clause 5.3), and its Annex A controls address AI roles and responsibilities and how concerns are reported.
• EU AI Act. For high-risk systems, providers must design for effective human oversight (Article 14), and deployers must assign that oversight to people with the competence, training, and authority to exercise it (Article 26).
• Model risk management in banking. Supervisory guidance on model risk management (SR 11-7 in the United States) has long expected clear model ownership, independent validation, and ongoing monitoring. Many AI use cases in banks fall squarely within it.

The frameworks agree on the principle. What separates organizations is whether ownership is real: named, accepted, evidenced, and exercised.

What I test as an auditor

When I audit an AI governance program, ownership is one of the first things I examine, because almost every other control depends on it. My questions are practical:

• Is there a complete inventory of AI use cases, including AI features embedded in vendor products?
• Does every inventory entry have one named accountable owner who has accepted the role?
• Can the owner explain the purpose, the limits, and the thresholds without reading from the approval memo?
• Are monitoring results reviewed and signed by the owner on the agreed schedule?
• When a threshold was breached, is there evidence of a decision, not just an alert?
• Have any use cases been paused or retired? A program that has never stopped anything deserves a closer look.

A one-page ownership record

If you take one thing from this article, make it this: for every AI use case, keep a one-page record that answers seven questions.

1. What is it for, and who is affected?
2. Who is the accountable owner?
3. What conditions were attached to approval?
4. What does acceptable performance look like?
5. What are the triggers for reassessment or escalation?
6. When was performance last reviewed, and by whom?
7. What would make us retire it?

If those answers exist and are current, the organization knows who owns the AI decision. If they do not, the policy is describing a program that does not yet exist.

---

This article reflects my professional perspective and is general information, not legal or regulatory advice. Apply it in light of your organization’s obligations and risk appetite.