How to Own Your AI System: the Ownership Checklist

You own your AI system when your business could keep running it, change it or move it without anyone else's permission, and you keep owning it by checking that this is still true. The first half is usually settled once, at handover. The second half is the part most businesses skip, because nothing prompts it. Ownership lapses quietly, in small steps that each look reasonable on the day they happen.

The earlier posts in this series dealt with the two moments everybody remembers. The questions to ask before you sign cover the contract while it is still negotiable, and the six things you should be able to point at describe what you hold once the system exists. This post covers the long stretch afterwards, when the system is working well and nobody has a reason to look.

It is an AI ownership checklist with dates on it. There are nine checks in three groups, contractual, technical and operational, and each one has a rhythm. None of them needs a specialist.

How do you own your AI system?

You own an AI system by holding its working parts in your company's name and by proving, on a schedule, that you still do. Holding is a list, and the list is short. Proving is the part that has to be repeated, because every item on the list can change without anyone deciding that it should.

A useful habit is to put a date on the claim. "We own our system" is true as of the last time somebody tested it. For many businesses that was handover day, and for a fair number it has never been tested at all.

None of this is an argument against cloud tools or against working with a partner. Renting the tools is fine, and the cost only arrives when the knowledge is rented along with them.

How ownership lapses

Ownership lapses through ordinary events, and four of them account for most of it.

The first is that people move. The person who held admin access changes role or leaves, and the access either goes with them or stays live in the name of somebody who no longer works on the system.

The second is that new tools arrive. A team starts using an AI assistant that was not part of the original build, and everything they teach it accumulates there. Deloitte's 2026 survey of 25,000 UK workers, with fieldwork by Ipsos, puts a figure on how visible that is. Nearly a third (31%) of GenAI users say they use GenAI without their employer's knowledge. That is a share of the people already using these tools and not of all workers, but it still describes a good deal of teaching landing in places the business has never seen.

The third is that terms change. Contracts renew on their own, suppliers update their conditions between renewals, and the arrangement you agreed is gradually replaced by one you have not read.

The fourth is that nothing gets tested. The export worked in the demo, the handover note was accurate when it was written, and nobody has tried either since. The government's Cyber Security Breaches Survey 2025/2026 found that around a third of medium businesses (30%) and nearly half of large businesses (48%) reviewed the cyber security risks posed by their immediate suppliers, and across businesses of every size the figure was 15%. The question is about security risk specifically and the survey leaves out sole traders, so it is a narrow measure, but it is the nearest published reading of how often a business checks a supplier once the contract is running.

The AI ownership checklist

The same table works as a data ownership checklist for any system that holds what your business knows, whether or not there is a model on top of it.

The contractual checks

The contractual checks confirm that the paper still matches the arrangement you believe you have. What a contract should say in the first place is covered in the questions to ask before you sign. The check here is whether it still says it.

Start with the dates. For each agreement, find the last day on which you can give notice and put it in a shared calendar with a named owner. The renewal date is the wrong one to diarise, because by then the decision has already been made for you.

Then read what has changed. The clauses worth re-reading are the ones about what the supplier may do with your data and with the corrections and instructions your team has added since. A setting that was off when you signed can become on by default in a later version.

The third check is confidentiality, which is easy to miss because it concerns people who arrived after the contract did. The rules, instructions and recorded reasoning inside an intelligence system are know-how in the plain sense of the word. The government's guidance on its own knowledge assets says that, when included in a commercial contract or partnership, know-how should be treated as a trade secret, and protected with contractual agreements. That guidance is written for public bodies, and the reasoning carries across. Once a year, list everyone outside the company who can read the store, and confirm that each of them is covered by written terms.

The technical checks

The technical checks all come down to doing the thing for real instead of trusting that it would work. The National Cyber Security Centre's advice on backups applies almost word for word. Test your backups regularly and ensure you know how to restore files from a backup before you have to do it for real. An export that nobody has opened is in the same position as a backup that nobody has restored.

For the restore rehearsal, somebody pulls a fresh copy of the knowledge from wherever the spare is kept, puts it on a machine with none of the usual tools installed, and checks that the pages open, the links work and the history of changes has come too. Then they compare it with the working version to see how far behind it is.

We ran this on our own business memory while writing this post. A fresh copy pulled from the repository into an empty folder arrived in a few seconds. It held about three hundred pages with their full history of changes, they read as plain text, and all but a handful of the several thousand links between them resolved. The rehearsal also found a gap. The copy held away from the working machine was five changes behind, which meant 2 days of work existed in one place only. Nothing had gone wrong, and a check that only runs once something has is too late to be useful.

The third technical check is the model. Model providers retire models on their own schedule, so whether your system could run on a different one will be answered eventually whether you ask or not. Once a year, point a test copy at a second model and compare the answers on a few questions you know well. If it cannot be done without a rebuild, you have at least learned that at a time of your choosing.

The operational checks

The operational checks are about people, because people are how access and knowledge move around a business.

The National Cyber Security Centre puts the access review in a single sentence. Review user accounts and systems for unnecessary privileges on a regular basis, and ensure privileged accesses are revoked when no longer required. Its guidance is written for security teams, and the ownership version is the same list read with a different question in mind. For each account the system depends on, whose name is it in today, and does that person still work here? Run it every quarter, and again whenever somebody leaves or changes role, including somebody at your partner.

The second-person check asks whether anyone other than the builder can change the system. Twice a year, have a member of your own team make one small and safe change, such as adjusting a rule or rewording an instruction, without help. When we built outreach automation for a UK angel investment community, it ran on the Airtable and LinkedIn set-up the team already used and went from kick-off to live production in 4 weeks, with the team running it themselves. It gave them back 4 hours a week. A system the team runs is a system the team can change, and it stays that way only while they keep doing it.

The third check is a short register of new tools. Every quarter, ask each team which AI tools they have started using and where the instructions, corrections and approved examples for each one are stored. The aim is to find out where the teaching is going while it is still easy to move. Nobody needs to be told to stop using anything.

Rehearse the exit

The one check that covers most of the others is to rehearse leaving without actually leaving. The Prudential Regulation Authority expects this of the banks and insurers it supervises when they outsource, and its supervisory statement is direct about it. Firms should take reasonable steps to test exit plans, and the same statement asks for those plans to be reviewed periodically as circumstances change. That is a rule for regulated financial firms, and a mid-market business is under no such duty, but the reasoning transfers. An exit plan that has never been tried is a description of what somebody hoped would happen.

The Friday afternoon test is the thought experiment, and the rehearsal is a small piece of it done for real. Once a year, pick somebody who did not build the system and give them an afternoon. They restore the copy, log in to each account using the company's own credentials, make one small change and write down every question they had to ask along the way.

That list of questions is what the rehearsal produces. A short list means the system is yours in practice, and a long one tells you precisely which parts still live in somebody else's head.

If the system is already built

If the system already exists and you are unsure how much of it you hold, start with the access review, because it costs the least and decides whether the other checks are possible at all. Then run the restore rehearsal.

If those two show gaps larger than an afternoon's tidying, a focused knowledge audit is the proportionate next step. If you have not built anything yet, decide ownership before the first source goes in, and what goes in first, and in what order covers that. For anyone still weighing up whether a system is worth building, the capacity calculator does the hours arithmetic in a couple of minutes.

When a partner still runs it

A partner running the system day to day changes who does the checks, and it should not change the answers. Ask for the access review to be done together and for the restore rehearsal to be carried out by someone on your side. Whether you run it with your own team or alongside someone else, the checks are the same and so is the standard.

It is the standard we hold ourselves to. We would rather be kept because the work is good than because leaving is hard, which is the principle behind owning your intelligence and the way we run our own engagements.

Practical takeaways

1. Put a date on the claim. "We own it" is true as of the last time somebody tested it, so write that date down and decide when the next one is.
2. Rehearse the restore every quarter. Pull a fresh copy onto a clean machine, open it, and measure how far behind the working version it is.
3. Review access whenever someone moves. Leavers and role changes are when accounts drift, on your side and on your partner's.
4. Diarise the notice date. The renewal date is too late, and the terms are worth re-reading each time.
5. Count the questions. Once a year, have someone who did not build the system run an exit rehearsal, and treat every question they have to ask as a gap to close.

Frequently asked questions

How do I make sure I own my AI system?

Hold the working parts in your company's name, then prove on a schedule that you still do. The first half is a list, which covers the knowledge in an open format, the rules the system follows, the accounts it runs on and a clean way out. The second half is the part most businesses skip. Accounts, contracts, tools and people all change after handover without anyone deciding that ownership should change with them, so the claim is only as good as the last time somebody tested it. Put the checks in the diary, and rehearse leaving once a year.

What should you check when an AI contract comes up for renewal?

Check three things before the notice date passes. First, read what the supplier may now do with your data and with anything your team has taught the system, because terms are updated between renewals and a default can change without much fanfare. Second, confirm that what you would receive on leaving is still described and still matches how the system is actually built today. Third, make sure everyone with access to your know-how, including newer partners and contractors, is covered by written confidentiality terms. Diarise the last date for giving notice, because the renewal date itself is too late.

What technical checks show you still own an AI system?

Three, and each one means doing the thing for real. Pull a fresh copy of the knowledge onto a clean machine and confirm that it opens, reads properly and brings its history with it. Compare that copy with the working one to see how far behind it is, since a copy that is weeks old protects very little. Then, about once a year, run the system against a second AI model in a test setting and compare the answers on questions you know well. If any of the three cannot be done without the supplier's help, you have found where the ownership sits.

How do you check ownership while a partner still runs the system?

Run the same checks, with your own person doing the work and the partner watching. Ask for the access review to be done together, with every account shown to be in your company's name. Ask for a restore rehearsal where someone on your team pulls the copy and opens it. And have that person make one small, safe change to a rule or an instruction, writing down every question they had to ask along the way. A good partner will welcome this, because it is evidence that the build was done properly. Reluctance is information too.

What is the first step if the system is already built?

Start with the access review, because it costs the least and decides whether the other checks are possible. List every account the system depends on, whose name each is in and who holds admin rights today. Move anything in a partner's or a former employee's name across to the company. Once you can log in to everything, pull a copy of the knowledge and see whether it opens without the tool that made it. Those two checks will tell you whether the remaining gaps are an afternoon's tidying or a larger piece of work.