All articles
Building Corporate AI

Who Should Own Corporate AI at Your Company

Every corporate AI build eventually runs into the same question: who owns this internally? Most companies are still several rounds in without a good answer. Here is what this role should decide, and why the two people who usually claim it are the wrong ones.

August 19, 2026 6 min read
Who Should Own Corporate AI at Your Company

Every corporate AI build eventually runs into the same question – who owns this project internally? A lot of companies can be several rounds into a project but still do not have a good answer.

This isn't because nobody is responsible. On the contrary, two or three people can be responsible, informally, but none of them were assigned the job on purpose. A 2026 survey of enterprise AI leaders found the single most-cited barrier to governing AI is not a technology gap but the absence of any one accountable owner, with roughly one in six saying no role holds formal accountability at all.

The two people who claim it by default, and why both are usually wrong

IT claims it first, most often, because the project touches systems and IT owns systems. That gets the connections built and the access provisioned.

However, it does not get anyone deciding which source is authoritative when two documents disagree. This is a business judgment, not a systems question, and IT was never asked to make it.

The project sponsor claims it second. They show up at a kickoff, sign off on scope, and reappear at the steering committee update three months later. In between, when someone needs to decide today whether a stale spreadsheet outranks an approved policy memo, the sponsor is in a different meeting, and someone junior makes the call because an answer is needed now.

Both defaults produce the same failure. The system gets built. And nobody is deciding the things only a real owner can decide.

Four things only a named owner can decide: which source wins when two conflict, who is cleared to receive which answer, when the system should hold instead of answering, and what happens when the answer is challenged.

What the owner should decide, that nobody else can

Strip away the org chart and the role comes down to four decisions. Importantly, these are decisions, not tasks:

  • Which source wins when two conflict. Not a technical setting, but a judgment call about the business. This needs to be made before the conflict happens, not during a meeting where two people are already arguing about whose number is right.

  • Who is cleared to receive which answer. Different from who is cleared to see which document, and the distinction is exactly where most companies get into trouble, since access to a dataset and permission to receive a synthesized answer drawn from it are not the same clearance.

  • When the system should hold instead of answering. Someone must define the threshold, and it cannot be the vendor, because the vendor does not know what a wrong answer costs in this specific company.

  • What happens when the answer is challenged. Whether that goes back to the owner, to a committee, or nowhere, and whether the person who receives the answer knows which of those three it is.

None of the above questions are technical. All four require someone with actual standing to make a call and be the one accountable for it.

When the role of the owner is split

The clean version of this story is "nobody owned it." The more common version is worse: two or three people owned different parts of it, and nobody realized the seam between them was where the problem would surface. Here is what that split looked like inside one real company.

A mid-size insurance company built a claims-support system where the underwriting team owned source authority, deciding which policy documents were current, and the compliance team owned permissions, deciding who could see what. Both did their jobs. Neither owned the third question: what happens when a source authority decision and a permissions decision point in different directions at the same time.

A claims adjuster asked the system about coverage terms on a policy that had just been amended. Underwriting's rule said the amended version was authoritative. Compliance's rule said adjusters below a certain seniority could not see amendment details, since amendments sometimes contained information restricted to underwriting review. The system split the difference: it answered from the old terms, because that was the version the adjuster was cleared to see, and said nothing about the fact that a more current, restricted version existed.

The adjuster quoted coverage that was no longer accurate. Nobody had done anything wrong. Nobody owned the seam between the two correct decisions.

That is what an undefined ownership role looks like in practice. Not a dramatic failure, but a quiet gap between two people who were each doing exactly what they were asked to do.

How this maps onto what gets built

Once someone genuinely owns this, the four parts of a minimum viable operating layer stop being an abstract framework and become that person's actual job. They are the one who names the authoritative source for each question, defines the roles and clearances for the decision in scope, decides what the workflow does when the system should hold, and signs off that the source line on every answer is real rather than decorative.

This is not a new list. It is the same four decisions from the section above, now attached to a name rather than a policy document nobody reads.

What a good answer to "Who owns this?" sounds like

Article 13 called this the question that reveals implementation reality faster than any demo, and said the difference in how it gets answered is audible. Here is what that difference sounds like.

A weak answer names a department. For example, IT, or the business unit, or "the AI team", as if a group can make a judgment call a single accountable person has to make.

A weak answer also names a committee, since a committee can review a decision but cannot be the one making it in the moment a claims adjuster is on the phone.

A strong answer names one person, states what that person decides that nobody else can, and states what happens when that person is unavailable or leaves. If the answer stops at a name, it is not finished.

Most companies discover they do not have this answer only after the seam has already failed once. The ones that get it right ask the question before they need it, not after.