AI operating model for the enterprise: moving a function from people-run to agent-run

What is an AI operating model?

It is the set of decisions that lets a function run with an agent in it: who may start a piece of work, which decisions the agent may take and which stay with a person, what is logged, what counts as a failure, and how the function returns to the previous way of working.

A tool policy says which products people may use. An operating model goes further: it says what happens to the work when an agent does part of it.

What changes when a function is agent-run?

A people-run function is one whose decisions are made by people, even where they already use software. An agent-run function is one where an agent carries out defined work inside those decision rights.

The owner does not disappear. A named person in the organisation stays accountable for the function. The agent has permissions, a record of what it did, and a switch that has been tested. People keep the decisions the design reserved for them.

Why one function at a time?

Decision rights, data, failure modes and regulators are not the same in every function. Software delivery, finance operations and customer administration fail in different ways and answer to different rules.

Taking them together means a rollback has to unwind several functions at once. Taking one means you can stop, look at the pilot record, and either hand the function over or put it back.

Why is software delivery the natural first function?

The work is already staged: specify, change, review, test, release. There is already a record of who changed what. A bad change can be reverted. That gives the operating model somewhere to sit.

The practical version of that function is an AI-enabled SDLC: a policy for assistants, quality gates on AI-assisted changes, and a record an auditor can follow. The longer guide is How to set up an AI-enabled SDLC in a large organisation. Other functions can follow once the pattern is proven there.

Who decides, and who is accountable?

Before a pilot, write three lists: decisions the agent may take on its own, decisions that count only once a person has accepted them, and decisions the agent must not take.

Name the person accountable for the function, and the person who may stop the agent. They can be the same person, but it must be someone in your organisation, never the supplier and never the model. An outcome fee, if you use one, does not move that accountability. How fees work is in How to price and govern agent-run services.

What has to exist before a pilot?

1. Decision rights, as above, agreed by the function owner.
2. Identity and permissions: what the agent may call, on whose authority, and what data stays inside your boundary.
3. A check on the output, so a bad result is rejected or sent to a person.
4. A record of what the agent did and what a person accepted.
5. A rollback that has been tried, not only described.
6. A map to the rules that apply to this function, below.

How do you roll back?

Rollback means the function can return to the previous way of working without reconstructing it from memory. For software delivery that is the last known good release, plus the right to disable the agent. For another function it is the previous procedure, the previous access, and a person who still knows how to run it.

Test the switch before the pilot depends on the agent. Decide in advance what happens to work in flight, and who may make the call. The current team stays beside the agent during the pilot so that knowledge is still in the room.

How does this map to the EU AI Act, ISO/IEC 42001, the NIST AI RMF and UK guidance?

Map the controls you already need. Do not start a second programme for each document. Your counsel decides how the law applies. The notes below are the map, not a legal opinion.

• EU AI Act. Regulation (EU) 2024/1689 (opens in new tab), as amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744 (opens in new tab), in force since 27 July 2026. Where the Act applies, record whether you are provider, deployer or both for that system, and the risk tier. High-risk duties for Annex III systems apply from 2 December 2027, and for Annex I products from 2 August 2028. The dates are in EU AI Act timeline for UK firms.
• UK guidance. There is no single UK AI Act. DSIT's guidance for regulators (opens in new tab) sets out five principles: safety, security and robustness; appropriate transparency and explainability; fairness; accountability and governance; contestability and redress. They are not a statute. DSIT published an AI Risk Management Toolkit (opens in new tab) on 8 September 2026. The fuller picture is AI regulation in the UK.
• ISO/IEC 42001:2023 is a voluntary management-system standard for AI. Mapping a control to it is not certification. The certificate comes from a certification body. See ISO/IEC 42001 readiness.
• The NIST AI Risk Management Framework (AI RMF 1.0) is voluntary. It is organised as Govern, Map, Measure and Manage. We use it as a shared vocabulary alongside ISO/IEC 42001 where a team already works that way.

The same control is written once and cited from each framework that applies. The wider control set is our AI governance consultancy.

How Comonad helps