Operations
The AI Register Your Clients Will Be Asked For Before They Are Asked for Anything Else
An AI register for a small business is a list of every agent running, with an owner, a risk tier and the controls that tier needs. Why clients will be asked for one, and how an MSP keeps it without maintaining it.

An AI register is a list of every automated agent a business runs, with a named owner, a risk tier and the controls that tier calls for. It is the first thing an insurer, an auditor, a bigger customer's procurement team or a nervous board will ask a small business for, and almost none of them have one. For an MSP, that is the cheapest piece of governance work there is, and the one that gets you asked back.
The register comes before the policy, before the training, before anyone argues about which framework to follow. You cannot govern what you cannot list.
Why the question arrives earlier than the client expects
Nobody asks a twenty-person firm whether it has an AI policy. They ask what AI it is running, usually in a form. A cyber insurance renewal. A supplier questionnaire from a larger customer. A due diligence checklist when the owner thinks about selling. The question is always the same shape: list the automated systems that make or act on decisions, say who is responsible for each, and say what happens if one of them is wrong.
The client's answer is usually "we have a few automations, I think, let me ask". That answer costs them the contract, the premium or the valuation, and it costs you nothing to prevent, because you are the one who knows what is running in their tenant.
What goes on the register
A register does not need to be clever. It needs to be complete and it needs to be current. For every agent, four things.
Who owns it: a named person, not a team. The one who gets the call when it misbehaves.
What it does on its own: from suggesting a thing a person then does, through acting with someone's approval, to acting unattended. This is the axis most people get wrong, because an automation that sends an email without anyone looking is a very different thing from one that drafts it.
What data it touches: nothing personal, internal business data, personal data, or the special categories. The register should say which, because that decides what controls are needed.
What happens if it is wrong, and whether it can be undone: trivial or serious, instantly reversible or not at all. An invoice chaser that sends a reminder a day early is an inconvenience. One that sends a final demand to the wrong customer is not.
Those four questions give a tier. Tier 1 needs a named owner. From tier 2, human review and an audit log. From tier 3, a kill switch and disclosure. A workflow is scored by its riskiest step, not its average one, because the average is what people quote when they want the number to look lower.
The register nobody maintains
Here is the problem with every register built in a spreadsheet. It is accurate on the day it is written. By March someone has added a workflow, someone else has left, and the spreadsheet says an agent is owned by a person who now works for a competitor. A register you have to maintain by hand is a register that is out of date by the first renewal.
The way round it is to have the register fill itself. abi. Governance keeps the register against the client's map, and the entries are created by the work rather than typed in afterwards. When abi. Agent Studio builds a workflow, the agent is added to the register as part of building it, scored from what its steps actually do. When you mark it live, the entry moves from draft to active. When abi. reads an automation the client already runs, anything nobody owns comes back as a finding. Nobody fills in a form.
For an MSP holding several client maps, that means every client has a current register you did not have to remember to update, and the question "what AI are we running" becomes a page you can export rather than an afternoon of asking around.
Your own rules on top
Some clients need more than the default. A regulated client, a client whose insurer has a specific requirement, a client whose own customers impose a standard. Policy Studio lets you add rules: raise a tier, add a control, require something the industry expects. Rules can only tighten. You can make the register stricter for a client, never more permissive, and you can simulate a rule against everything on the register before you publish it, so you can see what it would catch before it catches anything.
That is a managed governance offer in one sentence: we keep your register current, and we hold it to a standard you choose.
What this is not
A register is not a certificate. abi. Governance is a structured self-assessment, and a status of confirmed means the owner and escalation checks passed and nothing prohibited was declared. It does not mean every listed control is actually in place, which is why the register shows the evidenced count beside the required count. If a client's auditor wants evidence that the kill switch works, someone has to show them the kill switch. The register tells you which ones to go and check.
It is not legal advice, either, and an MSP should say so to the client in the same breath. The register's job is to make the question answerable. Whether the answer is good enough is a conversation with whoever is asking.
Where to start
Start with the client that has been asked. There is always one: the renewal that came back with a new section, the questionnaire sitting in someone's inbox. Map their business, read in whatever automations already run, and hand them the register before the deadline. It is a small job. It is also the first governance deliverable most of them will ever have seen, and the next one is already on the list.
View more articles
Learn actionable strategies, proven workflows, and tips from experts to help your product thrive.


