Who actually owns enterprise AI?

The proposal reached the executive committee of Kwena Life Assurance, a fictional South African life insurer, last year. A claims-assistance agent would check funeral claims for missing documents, draft the assessor's notes, flag possible exclusions and ask claimants for outstanding paperwork. The pilot results were good. Then the chief executive asked a simple question: "Who owns this?"

The chief operating officer said the claims business would own it, since it was their process. The head of claims said IT would own it, since it was a technology system. The chief information officer said the business would own the outcome but IT would run the platform. The chief information security officer said she would need to approve it before anyone owned anything. The chief risk officer asked whether model risk had seen it. Nobody was wrong, and the meeting ended without an answer.

That meeting happens in most organisations that take AI seriously. This series argues that it ends badly because the question is malformed. No single executive can own an AI system. Ownership splits into distinct kinds, each held by a named person, and governance is the work of making those kinds fit together. This first part sets out the split. Part 2 turns it into decision rights across the lifecycle, and Part 3 explains what a governance council should and should not do.

Why "who owns AI?" has no single answer

An AI system in a regulated business combines several things that are normally owned separately: a business process and its outcomes, a technology platform, an engineering design, data with its own permitted uses, security controls, legal and regulatory obligations, and the live operation where decisions about real people are made. Each has an owner already. Adding a model does not merge them.

The problem is that AI systems blur the joins. A claims-assistance agent reads claims data (the data owner's concern), runs on the platform (the CIO's), was designed by engineering (the CTO's), touches personal information about claimants and beneficiaries, and sensitive details about the deceased (privacy and legal), and influences decisions about payouts (the claims business). When something goes wrong, every owner can truthfully say the failure was somewhere else.

The useful question is not "who owns AI?" but "who owns which part of this system, and who decides what?"

Seven kinds of ownership

For Kwena's claims agent, ownership splits into seven kinds. Titles and structures vary between organisations; the kinds do not.

Nobody owns the claims-assistance agent outright. Each kind of ownership is held by a named person, and each owner's limits are another owner's responsibility. The live process and case authority is highlighted because it holds the rule that adverse decisions about claimants stay with named officials. The board sits above, with oversight rather than ownership.

Kind of ownership	Typical holder	Owns	Does not own
Outcome and acceptable impact	Business executive (here, the head of claims)	What the agent is for, what success means, which harms are unacceptable	The platform or the security controls
Adoption, platform and operations	CIO	Integration, run, support, resilience, cost of the platform	Whether a claim should be paid
Engineering design	CTO or head of engineering	Architecture, build quality, evaluation tooling, release mechanics	The definition of a correct claim outcome
Security and resilience controls	CISO	Control requirements, threat assessment, independent challenge on security	The business case
Data quality and permitted use	Data owner for claims data	What claims data may be used for, its quality and its retention	The model or its prompts
The live process and case authority	Claims operations manager	How the agent is used day to day, and which decisions stay with people	The engineering design
Legal, compliance and model risk	Legal, compliance and model-risk functions	Interpretation of obligations, review, challenge and the right to object	Day-to-day operation

Above all of these sits the board, which does not own the system but retains oversight of how the organisation governs technology and its risks. What the board should see is set out in What an AI value dashboard should show the board.

The data row is the one most often left blank. AI projects expose weak data ownership explains why: many organisations discover that nobody can say who decides what claims data may be used for until an AI system asks.

Two things stand out in the table. First, every "does not own" entry is something another owner does own. That is the point: ownership is a set of interlocking responsibilities, not a single title. Second, the chief executive appears nowhere in the table and everywhere in the outcome. The chief executive owns the decision to pursue AI as part of the strategy and the appetite for risk that comes with it, and holds the executives in the table to account for their parts.

What the frameworks say, briefly

The idea that accountability for AI must be explicit and distributed is not new or exotic. The NIST AI Risk Management Framework (AI RMF 1.0, released January 2023) asks, in its Govern function, that "accountability structures are in place so that the appropriate teams and individuals are empowered", that roles and responsibilities are "documented and are clear to individuals and teams throughout the organization", and that "executive leadership of the organization takes responsibility for decisions about risks" associated with AI.

In South Africa, the King codes have long treated the governance of technology and information as a responsibility of the governing body. King V, released by the Institute of Directors in South Africa on 31 October 2025 for financial years starting on or after 1 January 2026, is voluntary for most organisations, though listing rules can require it (the JSE did so for King IV). According to Clyde & Co's summary (10 November 2025), King V makes the governing body accountable for the effective, compliant and ethical management of data and information, and addresses emerging technologies including AI, with human oversight commensurate with risk. Financial regulators are also paying attention: the Prudential Authority and the FSCA published their first joint report on Artificial Intelligence in the South African Financial Sector on 24 November 2025, covering machine learning and generative AI adoption.

None of these sources tells a company which executive owns which part of an AI system. They tell the governing body that the answer must exist and must be written down. This article is general information about governance design, not legal or regulatory advice. Which obligations apply to your organisation, and how, is a question for your legal and compliance advisers.

The Kwena proposal, re-read

When Kwena's executive committee met again, the chief risk officer brought a one-page ownership statement for the claims agent instead of a question.

Outcome owner: the head of claims. The agent exists to reduce the time between a complete claim and a decision, without increasing wrongful repudiations. She defines what "wrong" means.
Platform owner: the CIO. The agent runs on the shared AI platform, with its availability, cost and support model.
Engineering owner: the head of engineering. Design, evaluation tooling, release process.
Security owner: the CISO. Control requirements for tool access, data handling and logging, and the right to challenge before release.
Data owner: the claims data owner. Which claims data the agent may read, for which purpose, retained for how long.
Process owner: the claims operations manager. How assessors use the agent, and the rule that every repudiation, reduction or delay beyond the service standard is decided by a named claims official, never by the agent.
Review and challenge: legal, compliance and model risk, each with a defined point in the lifecycle at which they can object.

The statement took a week to agree and one meeting to approve. The difficult conversation was not about the model. It was about the process owner's rule, which the outcome owner initially thought would slow things down. It did not, because the agent's value was in assembling complete claims, not in deciding them. The rule only works if the official genuinely decides, with the evidence in front of them, which is the argument of Human-in-the-loop is not a button.

The agent assembles and drafts; it never repudiates, reduces or delays a claim. A named claims official makes every adverse decision with the evidence in front of them, and the claimant keeps a route to review. Writing this chain down was the hardest part of Kwena's ownership statement, and the part that mattered most.

Where shared ownership quietly fails

Distributed ownership has its own failure modes, and they are worth naming early.

Everyone recommends, nobody approves. Every function reviews, comments and signs a register, and no single person can say "this is approved to go live". The release happens by default.
The CISO as gatekeeper of everything. Security becomes the only function with a formal stop, so every concern is routed through it, and it becomes the bottleneck and the scapegoat at the same time.
The council as owner. A governance committee is given "ownership" of AI. Committees coordinate well and own badly, because a committee cannot be accountable in the way a person can. Part 3 deals with this.
The vendor as owner. A supplier's platform comes with a responsibility matrix, and the organisation adopts it as its own. The supplier owns its service. It does not own your claims outcomes.
Ownership by project, not by system. The project team owns the agent until go-live, then disbands. Nobody owns material changes, drift or retirement. Delegation does not remove accountability makes the same point about multi-agent designs: handing work on does not hand accountability on.

A test for your own AI systems

For each AI system in production or near it, ask seven questions and write down a name, not a department, against each:

Who defines what this system is for and which harms are unacceptable?
Who runs the platform it depends on?
Who owns its engineering design and release?
Who sets its security controls and can challenge its release?
Who decides which data it may use?
Who owns the live process, and which decisions are reserved for people?
Who can object on legal, compliance or model-risk grounds, and at which point?

If any answer is "the committee", "IT" or "the vendor", the ownership is not yet designed. If two people give different answers to the same question, you have found your first governance task. The broader framework questions are covered in AI governance: the framework your organisation needs before scaling AI. This test is narrower and faster: it tells you whether the framework has reached a specific system.

Key points

No single executive owns an enterprise AI system; it combines outcomes, platform, engineering, data, security, live operation and legal obligations, each already owned by someone.
Name seven kinds of ownership per system, each held by a named person, with the board retaining oversight.
Frameworks such as NIST AI RMF and South Africa's King V expect accountability to be explicit; they do not choose the owners for you.
Reserve adverse decisions about people, such as repudiations, for named officials, and write that rule down.
Watch for the quiet failures: nobody approves, the CISO as the only stop, the council or vendor as owner, and ownership that ends at go-live.

Next: Part 2, Decision rights across the AI lifecycle. All parts are on the series page.

How CloudNala can help

CloudNala runs AI governance reviews for regulated organisations with AI systems in pilot or production. We take one or two of your real systems, run the seven-question ownership test with your executives, resolve conflicting answers, and produce a one-page ownership statement per system that your executive committee can approve and your risk function can audit against.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book an AI Governance Review or write to us at consult@cloudnala.co.za