Decide who owns the AI job before the pilot ends, and name one person rather than a department. AI jobs rarely fail outright. They fade. The output slips a little, the checks get lighter, and one quiet week nobody notices that the job has stopped running altogether.

Why AI jobs fade rather than fail

The fading has a simple cause. During a pilot the job has everybody’s attention. People compare notes, spot odd answers and fix them within the hour. When the pilot ends that attention moves to the next thing, while the work carries on exactly as before.

Nothing announces the decline. A broken machine stops and somebody rings you about it. A drifting AI job keeps producing output that looks perfectly reasonable. So the drift can run for months before anybody raises it.

That makes a person the only real protection. Somebody has to look at the job on a regular day, on purpose, because looking at it belongs to them. No alert will fire for you, since from the outside nothing has broken. Ownership therefore belongs on the plan before the pilot ends, not in a conversation afterwards.

Who owns the AI job, and what that person holds

Ownership here means three specific things, and a job missing any of the three will drift. The owner needs a written boundary, protected time and the authority to change the job or stop it.

Naming a person without those three is a title rather than a role. They do their best for a few weeks. Then they hit the first thing they cannot decide, and they go quietly back to their real work.

The written boundary

Take the boundary first, because the other two rest on it. The boundary is one page and takes half an hour to write. It says what the job covers and what it deliberately does not cover. It names the trigger, the place the output goes, and the person who reads that output before it travels.

That page also carries the stop rule: the condition that halts the job, and where the work goes instead while it is halted. A stop rule without a destination gets ignored, because nobody will stop a job when stopping means the work simply piles up.

Write it in plain language and keep it with the process it belongs to. If the job is part of how the work already runs, keep the page beside the other instructions. A folder of its own is a folder nobody opens.

Protected time, not goodwill

A boundary costs you half an hour once. The second piece costs a little every week, and time is where ownership usually breaks. The owner has a full job already, so the review happens in gaps, and gaps close whenever the business gets busy.

So estimate the time honestly, then put it in the diary as a recurring appointment. Reading a sample of output takes perhaps 20 minutes a week. A monthly look at cost, corrections and complaints takes an hour. That is a little over 2 hours a month, which is small, though only if somebody has actually made room for it.

If the owner’s week is already full, something comes off it. Ownership funded by goodwill lasts about as long as the goodwill does, and goodwill runs out in a busy month.

Authority to change it or stop it

The third piece is authority, and it is the one most often withheld. The owner should be able to change the instructions the tool follows. They should be able to change the review step, and to stop the job outright, without booking a meeting.

Withhold that and drift wins by default. Raising a problem costs the owner more effort than living with it, so small faults go unmentioned until they become large ones.

Draw the edges of that authority clearly. The owner may change how the job works and may stop it. They may not change what the job is allowed to spend. They may not change what information people put into the tool either. Both of those belong in your AI use policy, and they stay with you.

Where the line with your IT partner sits

Ownership of the job is not ownership of the technology, and confusing the two leaves both sides waiting for the other. The owner answers for whether the job does its work well: quality, cost, corrections, whether it still earns its place.

Your IT partner answers for whether it runs safely and can be supported. Accounts and access, the connection to your systems, backups, what happens when the supplier changes something without warning. Knowing when to involve them saves the owner from decisions they should never have to make alone.

Where the job touches personal data, that division needs writing down rather than assuming. The owner sees the output every week, so they will spot a problem first. The response then belongs to whoever answers for data in your business, working from the ICO guidance on artificial intelligence.

How to test a handover

Boundary, time and authority describe an owner. Passing all three to somebody else is the next problem, and most handovers get tested in conversation, which is why they fail.

The builder explains, the new owner nods, and everybody assumes the knowledge moved across. It rarely does. Writing down who owns the AI job is not the same as the new owner being able to run it.

Test it by doing instead. The new owner runs the job for a fortnight while the person who built it answers nothing and only watches. Anything they cannot manage alone shows up inside the first few days.

Then ask four questions and listen for specifics. Can they describe a bad output in a sentence? Do they know where the instructions live and how to change them? Do they know who to ring at the supplier? Can they say what the stop rule is without looking it up?

What happens when the owner leaves

People move on, so build the job to survive it. Name a deputy on day one. Let that deputy run the review for a week each quarter, so the knowledge stays warm in two heads.

Keep the one page current, because that page is the handover. It holds the location of the instructions, the supplier contact and the licence details. It also holds the stop rule and the last few months of review notes.

Then put the job on the same list as a customer account or a supplier relationship when somebody hands in their notice. A job nobody remembers to hand over is the one that fades first.

Put a name against the job on the day it goes live, and write the deputy underneath it. The boundary, the protected time and the authority all need somebody to belong to, and naming that person is the cheapest part of the whole job.