No agent goes to production without a named owner
Agents are born outside procurement, so nobody triggers the process that assigns a responsible person. The simplest rule is also the one separating companies that know what runs in house from those that will find out later.
In short. The most effective rule on AI agents is also the easiest to check: no agent goes to production without a named person answering for it. It is an organisational rule, it costs little, and it separates companies that know what runs in house from those that will find out when something goes wrong. Nearly three quarters of organisations expect to adopt agents within two years, and around one in five reports a mature governance model for managing them.
An agent differs from a model answering a question, because it plans, uses tools, writes to company systems and produces effects outside the conversation, from opening a ticket to changing a record. Risk moves from the output to the action, and a wrong action isn't fixed by rereading the answer.
Why ownership gets skipped
Agents almost always appear outside formal processes. Somebody switches on a feature inside a platform already in use, a team builds an internal automation, a supplier offers a module that performs operations in place of an operator. None of these looks like buying software, so nobody triggers the process that assigns a responsible person.
The result is that in many organisations the active agents outnumber the recorded ones, the question of who authorised them has no answer, and when something goes wrong the reconstruction starts from people instead of logs. The same dynamic we described for shadow AI applies, with one difference: here the system acts.
What being an owner means
A name on a document means little without concrete powers. An owner who cannot stop the agent is a signature of convenience.
| Power | Why it matters |
|---|---|
| Stop the agent without going through anyone else | Anomalous behaviour has to be interrupted in minutes, not days |
| Change the autonomy limits | Thresholds get tuned through use, not decided once |
| Access the action logs | Without tracing, what happened cannot be reconstructed |
| Approve extension to new systems | An agent gaining access changes its risk profile |
| Answer for the outcome to management | This is what makes responsibility real |
The owner is a business figure. Whoever answers for an agent handling payment reminders sits in the finance function, with IT support on the technical side, because the consequences of a wrong reminder land on the customer relationship rather than on the infrastructure.
The agent inventory
It needs to be separate from the general AI system inventory, because the information to keep is different. For each agent, record purpose, owner, systems it can write to, data it accesses, autonomy limits, how it is stopped, and the environment it runs in.
The part forgotten most often is the list of systems the agent can act on, which is also what separates the risk profiles: an assistant reading documents exposes information, while an agent changing an order or sending a message to a customer produces operational and contractual effects that are hard to undo.
Which framework does your company actually need?
AI Rating measures maturity across the four areas of the model and shows where to start, with priorities and estimated effort.
Start your AI RatingIdentity and permissions
An agent using a person's credentials makes it impossible to tell one's actions from the other's. It is the underlying problem that renders much of the logging useless: the records exist and attribute everything to a human account whose owner was doing something else at the time.
The right direction is a dedicated identity per agent, with least privilege and separation by environment, and it takes work on the identity infrastructure that belongs in the project budget rather than surfacing halfway through. It rarely appears in the initial estimate.
When an agent falls under Annex III
If an agent operates inside a high-risk use case, the high-risk obligations apply to that use case. An agent sorting applications sits in workforce management, and the classification doesn't change because the system is called an assistant.
There is a second step worth knowing. A deployer using an agent differently from what the provider intended can become the provider of a high-risk system, with the obligations that follow. The distinction between intended use and actual use has to be documented, and the place for it is the AI systems register.
Where to start
The entry point is the AI system inventory, extended to agents with the extra fields described above.
The criteria for judging whether an agentic project makes sense are in AI agent PoCs, while the general framing is in AI agents in the enterprise.
To find out which agents are live in your organisation and who answers for them you can book an assessment session.