Last week’s post identified three gaps that organizations consistently underestimate when moving an AI system from pilot to production: the visibility gap, the resilience gap, and the ownership gap. All three matter, and all three compound, but the ownership gap is worth its own post. Visibility and resilience are solvable once someone is accountable for solving them. Without that accountability, both stay permanently half-built.

When looking at ownership gaps, two assumptions cause most of the damage. One is the phrase “the team owns it”, which sounds like an answer and almost never is. The other is quieter: the assumption that no one needs to own it at all, because the AI is intelligent enough to look after itself. Both leave the system unattended.

Why AI Systems End Up Unowned

The second assumption is the one that’s specific to AI, and it runs through the word “intelligence” itself. When leaders hear “artificial intelligence,” some quietly impute characteristics the system doesn’t have such as judgment, self-awareness, and the ability to notice its own problems and correct them. It’s rarely said out loud, but the reasoning surfaces in staffing and budget decisions: the system is intelligent, so surely it can look after itself. Well…it can’t. An AI system has no awareness of its outputs drifting, no instinct to escalate when something goes wrong, and no sense of when the business need has shifted out from under it. The work has been quietly delegated to the technology, and nobody said so out loud.

The first assumption (“the team owns it”) isn’t unique to AI. It shows up in any long-running initiative that outlives its champion, and that assumption causes failure for three reasons.

First, diffusion of responsibility. This is a well-documented phenomenon in human behaviour, and it doesn’t go away when the work is technical. If everyone is responsible, nobody is responsible. Alerts go to a shared channel such as email or MS Teams, people assume that others are taking care of them, and the problems quietly age.

Second, dependence on whoever cares most. Shared ownership tends to reward the person most invested in the outcome, and that works until that person leaves, gets reassigned, or burns out. The system keeps running without anyone watching it closely, and the drop-off is rarely visible until something breaks.

Third, ownership by proximity. The last person who touched the code becomes the de facto owner, regardless of whether they have the authority or the time to act on what they find. Proximity is not the same as responsibility and accountability. Ownership has to be named, funded with time, and backed by authority, otherwise it’s ceremonial and performative.

What makes all of this more dangerous with AI is how these systems fail. Traditional processes tend to fail loudly: a batch job crashes, a spreadsheet errors, a database rejects bad input, and people get notified. In contrast, AI systems tend to fail quietly. Given incomplete, missing, or ambiguous inputs, they’ll often produce plausible-looking output anyway. An organization used to reacting to broken processes can run for months before noticing an AI system has stopped working correctly. That silent-failure mode turns ordinary ownership gaps into unusually expensive ones.

Assigning Ownership

Both assumptions (nobody needs to own it, or, everyone owns it) are flawed, and the fix is the same for both: AI systems in production need explicit ownership, with responsibilities scoped precisely enough that the work actually gets done.

The word “ownership” hides three distinct jobs that most organizations lump together and assign to whoever built the system: operating the system, maintaining it, and stewarding it. However, these jobs require different skills, different time commitments, and in most cases, different people.

Two of these jobs cover tightly scoped parts of the ongoing work, the day-to-day operation and the technical maintenance. The third sits above both and owns the outcome overall: whether the system is still earning its keep, and whether the other two jobs are actually getting done. Without the overarching role, the scoped roles drift. The three are described below in the order the system encounters them day to day, but the overarching role (the steward) is the one that has to be in place first.

Job 1: The Operator

Day-to-day responsibility for the system doing its job: reviewing outputs, catching anomalies, responding to alerts, and running the recurring checks that monitoring can’t fully automate. The operator sits closest to the business process the system serves, something like a sales lead coordinator for a prospecting pipeline, an HR manager for a document system, a bookings lead for a scheduling workflow.

The operator does not need to understand the AI internals, but they do need to know what “normal” looks like and when to escalate. Missing this role looks like outputs degrading with nobody noticing until a customer complains; alerts firing into a channel no one pays much attention to; or edge cases compounding because no one is triaging them.

Job 2: The Maintainer

Technical responsibility for keeping the system running: model version changes, API updates, dependency maintenance, cost management, and debugging failures that go beyond operator triage. This is usually an internal IT resource or a technical vendor.

The maintainer handles the boring work that decides whether the system is still functional in twelve months: patching when an API changes, investigating cost creep, adjusting prompts when model behaviour shifts. Missing this role looks like small issues compounding into wildly incorrect output; costs drifting upward without anyone pushing back; and the system becoming fragile because no one is doing preventive work.

Job 3: The Steward

Overarching responsibility for the system as a whole. Is it still delivering value? Is it the right shape for what the business needs now? When should it be expanded, consolidated, or retired? And are the operator and maintainer actually doing their jobs?

The steward is usually a business leader with budget authority, often the person who sponsored the project or their organizational successor. They answer the strategic questions the operator and maintainer aren’t positioned to answer, and they own the outcome overall. That means making sure the other two jobs are staffed and getting done: if monitoring lapses or maintenance slips, the steward is the one accountable for catching it before a customer does. Missing this role looks like systems that outlive their usefulness because no one has the authority to retire them; scoped roles drifting because no one is checking in; and strategic drift between what the system does and what the business actually needs.

Where These Roles Live

Most small and mid-sized organizations don’t have a natural home for an AI system. It isn’t IT because it is too operational. It isn’t operations because it is too technical. It isn’t the original sponsor; they’ve already moved on to the next thing. AI systems bridge two worlds, and most org charts have a seam running right through the middle of that bridge.

Three patterns tend to work. The first is an operational owner with technical support: the operator lives in the business, the maintainer is internal IT or a vendor on retainer, the steward is the operator’s leader. This fits most organizations. The second is an embedded engineer model, where the system is critical enough to justify dedicated technical ownership inside the operating team. The third is a vendor-managed model, where the capability exists but the in-house skills don’t.

In very small organizations, one person may have to wear more than one hat. Jobs 1 and 3 (operator and steward) can reasonably combine when a founder or operational lead both runs the workflow day-to-day and owns the strategic direction; the oversight loop is short, and they have both the proximity and the authority. Job 2 is the exception. Maintaining an AI system requires specific technical skills, and asking the operator or steward to also debug model behaviour, manage API costs, and triage infrastructure failures usually means those things don’t get done. If the internal technical capacity isn’t there, a vendor or part-time contractor in the maintainer role is almost always worth the cost.

A Diagnostic

For any AI system currently in production, name the person doing each job. If any of the three names are missing, blank, or described as “the team,” that role isn’t filled and you have a gap that exposes you to risk.

For any AI system being planned, assign the three roles before the build starts. Retrofitting ownership after the fact almost always lands on the builder and overloads them. For any system that’s drifting, identify which of the three jobs has gone quiet and address that gap.

Closing

Ownership is an organizational design problem as much as a staffing one. Splitting it into three jobs makes the design explicit and the gaps visible. Not every system needs three full-time people, but the three jobs still need to be named and staffed with people who have the time, the skills, and the authority to do them.

Next week: change management. Once the ownership structure is in place, how do the people who interact with the system actually adopt it, and what does it take to build institutional competence rather than individual expertise?

Wrap Up

This post is part of a series on the current state of AI, focused on how it can be applied in practical ways to deliver measurable improvements in productivity, cost savings, and response times. If you’d like to explore more, all previous posts are available under Insights; please read them and reach out with any questions or comments you have.