Owners and backups

By now things are running. A meeting-notes feature a vendor switched on. A proposal workflow someone in sales built and the whole team now uses. Perhaps the build you made the case for in module 6. Each one was useful on the day it started. This module asks what happens to it on day 400, when the person who set it up has moved on and the vendor has changed what sits underneath.

This course promises a first loop without orphaned apps. This lesson is where that promise is kept or broken, and it starts with a name.

How things become orphans

Nobody sets out to create an orphan. It happens in three ordinary ways.

• The maker moves on. A power user builds something useful, the team comes to depend on it, and then they change roles. It keeps running, and nobody else knows how it works.
• A vendor switches something on. An AI feature appears inside software you already pay for. It's running from the first day, and it was never anyone's decision.
• Personal becomes shared. One person's shortcut gets passed round a team, and one day the team can't work without it.

None of these is a failure by the people involved. It's what success looks like before anyone owns it. The trouble starts later, when something goes wrong and the organisation discovers nobody can say whose it is.

The last number matters more than it looks. Most software, AI included, is now bought and run inside the business, not by IT. So ownership can't default to IT, and it can't default to whoever happened to build the thing. It has to be given, on purpose, to a named person.

The rule

The third principle of the Deployment Framework says it in one line:

Shared and high stakes are the two questions from module 6. Low-stakes personal use needs no owner beyond the person using it. Anything shared does. So does the approved tool behind any personal high-stakes use, such as a recruiter ranking CVs: it builds nothing, but something it relies on still needs a name against it.

The owner answers for it. They know what it's for, who depends on it and how it's doing, and they make the call at each review: keep it, fix it or retire it. The owner is usually the person whose work depends on it most. That's rarely IT, and it doesn't have to be the person who built it.

The backup can stop it. Here's the test. If the owner is on a plane, can the backup switch it off and start putting things right without asking anyone? If not, they're a name on a list, not a backup.

The review date is the third part of the rule. It gets its own lesson, because it's the part that stops things quietly outliving their use.

Every output traces back to someone

Principle 3 has a second sentence: every output can be traced to someone who answers for it, either directly or as the owner of the system that produced it.

There are two routes. When a person checks something and sends it, they answer for it directly. That's the output standard from module 2: your name is on it, and you can explain it. When a system acts with nobody in between, such as a chatbot answering customers or an agent sending invoices, the owner of that system answers for what it does.

There is no third route where nobody answers. An airline tried to argue for one in 2024. A customer was told by the chatbot on its website that he could buy a full-price ticket and claim the bereavement discount afterwards. The airline refused, and argued at a Canadian tribunal that the chatbot was a separate legal entity, responsible for its own actions. The tribunal called that a remarkable submission and held the airline to what its chatbot had said.

Who names them

In the framework's grid of who does what, Own is the clearest row. The function leader names the owner and the backup, because the function is where the work, the people who depend on it and the budget all sit. Everyone else has a part:

• IT, security and compliance supply the monitoring, the off switch, the undo and the records. They make owning possible. They don't own everything.
• Builders, inside the organisation or outside it, run and improve what they built.
• The person who runs the loop is kept informed, so the AI list stays complete.
• Everyone reports problems through stop, tell, fix, learn.

None of this is new. IT service management has worked this way for decades: every service has a named service owner. The framework borrows that idea from ITIL openly, and applies it to AI.

Name an owner for everything on your list

Below is everything shared or high-stakes from your AI list in module 3, plus the build from your case in module 6. Add anything that's missing. Then put two names against each one. Anything without both is flagged as an orphan.

When the owner isn't the maker

Often the best owner is not the person who built it. That's fine, and it's often better: makers move on, and the function stays. What matters is the handover. Half an hour is usually enough to cover what it's for, who depends on it, where its data lives and how to stop it.

The maker keeps the credit. The front door in module 6 adopts what people have made by default and names who made it. Owning it properly is how that credit survives the maker's next move.