Who Should Own AI in Your Business

Somebody builds something useful. It runs for eight months. Then a connection changes, it stops, nobody notices for three weeks, and the business concludes that this sort of thing does not last.

The build was fine. Nobody owned it.

Unowned is the most common ending

MIT’s Project NANDA published The GenAI Divide in July 2025, reviewing over 300 disclosed AI initiatives. Against an estimated $30 to $40 billion of enterprise investment, roughly 95% of generative AI projects produced no measurable return.

The study covers large organisations rather than businesses your size, and no measurable return frequently means nobody built a way to measure. But the pattern underneath is not about scale. Projects fail after the building stops, and what fails is continuity: nobody was responsible for it still working in month nine.

Why the obvious owners are wrong

IT is the wrong home. They can keep it running and they cannot tell you whether it is producing the right answers, because that requires knowing the process. An IT owned automation gets monitored for uptime and never for correctness, which is the failure that costs you a client.

A committee is worse than nobody. Shared responsibility means the thing that broke in March gets discussed in April and fixed in June. Committees are for deciding, not for owning.

The enthusiast is a trap. Every business has somebody who is genuinely interested and builds things in their own time. Valuable, and they should be encouraged. But they own it informally, alongside their actual job, and when they leave or get busy the whole thing becomes undocumented and unmaintained at once.

The supplier cannot own it either. We build these systems and we are clear about this: an external firm can maintain and improve something, but it cannot notice that the business changed how it quotes in February and the rules are now wrong. Only somebody inside sees that.

The right owner is the process owner

Whoever was accountable for the outcome before the system existed stays accountable after it.

If it handles quoting, the person responsible for quotes owns it. If it routes enquiries, the sales manager owns it. Not because they can fix it technically, but because they are the only person who will notice that the output has drifted from what the business actually needs.

That distinction matters. Ownership here means noticing and deciding, not maintaining. The technical work can sit anywhere. The judgement about whether it is still right cannot.

What owning it actually involves

• Being the named person failures escalate to. Not a shared inbox. A name, on the alert.

• A monthly look, fifteen minutes, at what it did and what it got wrong. Most drift is visible in a sample of ten.

• Deciding when the rules change. New service line, new client type, changed pricing. Somebody has to connect a business change to a system that needs updating, and that connection is the whole job.

• Holding the number. The one you recorded before it was built, checked twice a year, so the thing can be defended when budgets get difficult.

That is a couple of hours a month, not a role. Businesses that treat it as a role over-engineer it and businesses that treat it as nothing lose the system.

The one thing a small company should centralise

Individual systems get individual owners. One thing does not, and it is the item most businesses skip.

Somebody senior should hold the list. What we run, who owns each one, what it touches, and when it was last reviewed. One page, updated quarterly.

Without it you cannot answer a client questionnaire, you cannot assess exposure when a supplier changes terms, and you will eventually discover two systems doing contradictory things to the same records. The list takes an hour to create and is the difference between a set of tools and something a business actually manages.

What to do when the owner leaves

The question nobody asks until it happens.

Reassign it the same week, explicitly, in writing, to the person taking over the process. Not to whoever is least busy. The most common way a working system dies is a departure where the automation was never mentioned in the handover, because it had been working quietly for a year and nobody thought of it as a responsibility.

Put it on the leavers checklist alongside the accounts and the keys. It costs nothing and it prevents the most avoidable failure in this whole article.

The owner needs one thing from you

Authority to stop it.

An owner who can see that a system is producing bad output but has to escalate to switch it off will not escalate. They will work around it, tell the two people who need to know, and the business will carry on believing the process is automated when it is quietly manual again.

Say explicitly, when you assign ownership, that turning it off is their call and nobody will question it. That single sentence is what separates ownership from responsibility without power, and it costs you nothing.

What to do if nobody wants it

A real situation, and usually a signal rather than a staffing problem.

If the obvious process owner does not want to own the system, the reason is normally one of three things. They were not involved in specifying it, so it does not reflect how they actually work. They do not understand what it does well enough to judge its output. Or they suspect it is a step towards replacing part of their team and are not going to say so.

All three are worth surfacing before the system goes live rather than six months later. The third one especially: if that is the plan, say so, and if it is not, say that clearly too, because the assumption will otherwise shape every decision they make about it.

The three questions to ask yourself today

For every automation currently running in your business:

Who gets the message when it fails, by name. When did somebody last look at what it produced. And if that person left tomorrow, who would know it existed.

If any of those has no answer, you do not have a system. You have something that is working at the moment.

Sources

• Aditya Challapally, Chris Pease, Ramesh Raskar and Pradyumna Chari, The GenAI Divide: State of AI in Business 2025, MIT Project NANDA, July 2025.

AI Optimize builds with a named owner, an alert that goes to a person, and a monthly view of what the system actually did. Start at Workflow Automation.