AI governance and ownership

The estate nobody planned

For a few years the question was whether to let staff use AI at work. That question has answered itself. They use it, much of it unapproved. The most capable of them have moved past chatting to building things that touch business data and act on it. And models keep arriving inside software you licensed for entirely other reasons, switched on by a supplier's release note. Nobody set out to build an AI estate. You have one anyway.

A newer arrival sits awkwardly between the two. Collaboration platforms have started shipping agents that belong to a channel or a team rather than to a person, with their own identity and credentials, memory that accumulates across a workspace, and the standing to be handed a task by anyone in the room. No individual's login is being borrowed, which means no individual's accountability is being borrowed either. It arrives switched on, it acts, and when someone eventually asks who owns its behaviour, there is often no answer that survives the question.

The questions have started arriving from outside, too. Regulation is catching up; in the EU, the AI Act's first obligations are already enforceable, and its high-risk regime follows on a published timetable. Insurers, customers and auditors have begun asking what you run, what it can reach and who answers for it.

The facts a regulator wants turn out to be the same facts you want. What exists, who owns it, whether it still works, and how it stops. Establish those once, properly, and the estate stops being something you hope nobody asks about and becomes ground you can build on. It is also a great deal quicker now than it will be after an incident.

• You have just discovered what your staff already built, and banning it would punish exactly the initiative you want more of.
• AI is in use across several teams and systems, no complete list of it exists, and nobody could name an owner for every entry if one did.
• A regulator, customer or insurer has started asking questions about your AI estate that you cannot currently answer.
• Something in the operation is answering questions or making decisions every day, and nobody can say when its accuracy was last checked.
• An agent is doing real work, and the honest answer to "could you switch it off cleanly?" is no.
• You want to move faster on AI, and what is holding you back is not appetite or ideas but the absence of a safe way to say yes.

What we establish with you

The work is shaped around the estate you actually have and the questions actually being asked of you. Most engagements draw on these, weighted to fit.

Estate discovery

Finding what is genuinely running, which is rarely what the asset inventory says. Sanctioned systems, model features that arrived inside software you already license, and the tools teams built or bought on their own. We do this by sitting with people rather than circulating a form, because the entries that matter are the ones nobody thought counted.

The register

One live list rather than a spreadsheet that is accurate on the day it is signed. Each entry carries what the system does, the data and systems it can reach, the person accountable for it, and the date it was last evaluated. We set its shape, seed it from the discovery, and leave your team with the routine that keeps it current.

Ownership and access

Deciding who answers for each system, and giving each one an identity of its own with access to what its job needs and nothing beyond that. This is where most of the useful argument happens, because it makes accountability specific: a person, not a team, not a committee, not the supplier.

Evaluation that catches quiet failure

AI rarely fails with an error message. It goes on producing work that looks much like the work it produced last quarter, while the ground underneath it moves. We define what good looks like for each system in your operation's own terms, build the checks that measure it against cases your experts trust, and set the point at which a result puts a decision in front of a human.

A paved road for builders

A sanctioned way for the people closest to the work to build their own tools: approved platforms, guardrails that live in the platform rather than in a document nobody reads, training tied to what each role actually does, and somewhere to turn when someone gets stuck.

Agents are the hardest case

All of that applies to any AI in the estate. It bites hardest where the software acts. An assistant that answers a question badly wastes someone's time, and the person reading it usually catches the mistake. Software that books, orders, escalates, updates a record or closes a case has already acted by the time anyone reviews it, at machine pace, across systems that trust it.

So every agent gets what a new colleague would get: a named human owner, a scoped identity, a written list of the tools it may call so its reach grows by decision rather than by drift, a defined job with measures attached, and a clean way to be suspended or dismissed. It also needs something a colleague has and most software does not, which is the standing to stop when it is out of its depth. An agent that halts into silence has not stopped safely; it has failed quietly. Stopping means handing the work to the person named for it. An agent nobody can name an owner for is an incident, not an asset.

Starting from what your people built

Where unapproved AI already exists, shutting it down is the understandable move and the expensive one. What people built without asking is a map of unmet demand, drawn by the people closest to the work, and the ones who drew it are usually your best early adopters. Policy should recruit them.

So the inventory runs without blame. What proves useful is kept and brought onto the register properly. The rest is retired with its lessons written down. Nobody is asked to account for having tried something.

Amnesty on its own will not hold, though, because if the sanctioned route stays slower than the unsanctioned one the estate quietly goes dark again inside a year. That is what the paved road is for, and why guardrails deserve as much design attention as the systems they contain. Too loose, and a well-meaning colleague hands a persistent agent the keys to a critical system. Too tight, and the people who could create the most value are locked out of the tools. Access and training are designed together, role by role, so neither happens by default.

Governance built this way is experienced as permission, which is the difference between a policy people route around and one they actually use. What that means for the people themselves is empowering your people.

What you will be able to show

Most organisations reach for a policy document first, and a policy document is not what settles the question. What settles it is a small set of operational facts you can demonstrate on request:

• A current register of every system, what it does, what it can reach and who owns it.
• Scoped identity and permissions for each one, with limits the systems themselves enforce rather than limits people are asked to respect.
• Evaluation records showing what each system was measured against, when it was last measured, and what happened when a measure moved.
• An audit trail of what was seen, done and decided, recorded as the work happens rather than reconstructed afterwards under pressure.
• Stopping that lands somewhere. Any system can be paused or retired cleanly, with the work falling to a designed alternative instead of a scramble.

Where a question is genuinely a legal one, we say so and work alongside your advisers rather than in place of them. Everything above is the operational half, and it is the half that takes time to build. The organisation that can produce it on request is also the one that can say yes quickly, because it already knows what it is agreeing to.

Where this connects

This work establishes the facts. Keeping them true as models change, systems are added and people move on is managed AI and technology, where the register is maintained, evaluations are re-run and systems are retired once the evidence stops justifying them. The distinction is worth being precise about, because established and maintained are scoped, staffed and priced differently.

The engineering underneath, including which models run where and what may cross which boundary, is technology and product delivery. What it means for a team when the new colleague is software is adoption and organisational change. And once several systems have to work one problem together and hand conclusions to each other, the design question changes shape, which is designing the organisation your AI works inside. Where a system reaches into physical operations or safety-critical decisions, we grade it separately for catastrophic risk against a written threshold and a rehearsed response protocol, not only against the register's ordinary fields. One team carries all of it, which is rather the point.