What is an AI operating model?
Workflow, adoption and value
An AI operating model is the way an organisation structures AI so it can be used repeatedly, responsibly and at scale. It defines who owns what, how new AI use cases are approved, what data and security rules apply, where review points sit, how people are trained, how work is funded, and how live AI systems are monitored. It is not the mechanics of one process. It is the organisational structure around all AI work.
Reviewed by Jackie, Head of Learning & Development, Levellers · Last reviewed 8 June 2026
What this means
Many firms start AI work by experimenting in pockets. One team buys a copilot. Another builds a prompt library. A third automates a task in operations. At first this can look productive. Over time it creates duplication, unclear ownership, uneven risk control and growing confusion about which tools, data and practices are acceptable.
An AI operating model is what turns that scattered activity into a repeatable capability. It tells the business how AI ideas enter the pipeline, who reviews them, who owns the data, who signs off risk, who trains users, who supports live systems and who can stop an AI use case when it is no longer safe or useful.
This is different from workflow automation. Workflow automation is about the mechanics inside a specific process. The AI operating model sits above that level. It governs how the organisation chooses, builds, buys, deploys, supervises and improves AI across many processes, teams and use cases.
Why it matters
An AI operating model matters because AI work does not stay contained for long. Once employees see even modest gains in drafting, search, extraction, analysis or routing, demand spreads quickly. Without structure, a business ends up with too many tools, too many experiments, too little ownership and very little confidence about what is actually running. The result is not just waste. It is slower scaling, inconsistent control and higher operational risk.
There is also a leadership problem to solve. AI adoption often requires changes to business processes, data handling, team capability, security practice and decision rights at the same time. If senior leaders are not aligned on purpose, priorities and risk tolerance, the organisation tends to produce a familiar pattern: interesting pilots, local enthusiasm, weak handoff into live operations and a fog of uncertainty about value.
A good operating model addresses that by creating a repeatable path from idea to live use. It does not need to be bureaucratic. In a smaller firm it can be deliberately light. But it must still answer basic questions. Who can buy or activate AI tools? Which data can be used? Which use cases need legal, privacy or security review? Which cases need formal human oversight? Who owns the effect once the system is live? What gets logged? How are issues escalated? What training is mandatory?
This matters commercially as much as it matters for risk. The firms that get more value from AI usually do not rely on isolated experiments alone. They build management discipline around AI use, which means clearer prioritisation, stronger sponsorship, more consistent human validation, and better linkage between business need, technical choices and adoption by the people doing the work.
There is a regulatory dimension as well. In the UK, data protection, explainability, fairness and accountable decision making remain central issues wherever AI touches personal data or important decisions about individuals. For organisations with EU exposure, the AI Act creates a risk based framework with staged application dates and explicit governance expectations. Even where a firm is not directly captured by specific AI legislation in every case, customers, clients, employees and regulators will still expect clear accountability.
Perhaps the most practical reason is that an operating model prevents AI from being treated as a one off project. AI needs to be run as ongoing capability. Models change. Vendors change. policies change. data changes. staff roles change. a process that works today may be poor fit next year. Without a durable structure around intake, review, ownership, training and monitoring, AI work becomes expensive improvisation.
How it works
Set the purpose before you set the structure
An AI operating model should begin with a plain statement of purpose. Why is the organisation using AI at all? Common reasons include reducing repetitive work, improving speed and consistency in operations, increasing access to internal knowledge, supporting staff with drafting or analysis, and improving specific customer or service processes.
This sounds obvious, but it matters because the operating model should reflect what the business is actually trying to do. A firm that mainly wants safe employee assistance with low stakes internal work needs a different structure from a firm deploying AI into customer decisions, regulated activity or high risk operations. If leaders skip this step, the structure often becomes either too weak to protect the business or too heavy for the work being attempted.
Purpose also sets scope. It should make clear which kinds of AI use are in scope now, which are allowed only under closer review, and which are out of bounds until the firm is more mature. For many small and mid sized organisations, this single act of scoping removes a great deal of confusion. Staff do not need a philosophical essay on AI. They need to know what is approved, what needs review and what is not acceptable.
Define roles and decision rights clearly
The heart of an AI operating model is responsibility. If nobody knows who owns a live AI use case, then nobody really owns the risk, performance or value.
At the top, the board and senior leadership set direction and risk tolerance. They do not need to review every prompt or every workflow, but they do need to decide how ambitious the firm intends to be, what categories of risk are acceptable, and how AI priorities fit with wider business priorities.
An executive sponsor, often a functional leader rather than purely a technical leader, should own the change at enterprise level. In a smaller firm this may be the COO, CFO, CIO, Managing Director or another senior leader who can connect business need to delivery discipline.
Each AI use case should then have a named business owner. This is usually the person who owns the process or service being changed. They are responsible for the business case, service quality, user adoption and whether the live use remains fit for purpose. This responsibility should not sit only with IT or an external provider.
Data responsibilities need naming too. Someone must own the source data, data quality expectations, access rights, retention rules and any special handling conditions. If personal data is involved, privacy and compliance roles need a clear place in the review path. Security roles need the same where model access, external APIs, credentials or write permissions create cyber risk.
Where AI supports decisions about people or important business actions, the organisation also needs implementers or supervisors with defined authority to challenge the system. Human oversight is only credible when the reviewers are trained, engaged and empowered to intervene.
In smaller organisations, one person may carry several of these responsibilities. That is not a problem in itself. The problem is when the responsibilities are implicit rather than explicit.
Create a single intake path for new AI use cases
A practical operating model needs a front door. New AI ideas should not arrive through shadow purchases, ad hoc experiments in personal accounts or isolated work in departmental silos.
The intake path does not need to be elaborate. It can be a lightweight form reviewed monthly. What matters is that each proposed use case is described in a consistent way. A sensible intake asks for the business problem, the process involved, the users, the data involved, the intended level of automation, affected stakeholders, expected value, dependencies, likely risks and proposed measures of success.
The point of this is not paperwork for its own sake. It is comparability. Without a common intake, the organisation cannot prioritise intelligently. Everything sounds urgent and everything sounds valuable. With a common intake, leaders can distinguish between a low risk, high volume process improvement and an ambitious but poorly formed idea that will consume resources without a clear path to live use.
A single intake path also helps because it becomes the start of the evidence trail. The organisation can see what it considered, what it approved, what it rejected, what changed during delivery and what finally went live.
Use risk tiers and review gates
Not every AI use case needs the same degree of review. That is why the operating model should work with risk tiers.
A low risk tier might cover internal assistance where staff use approved tools to draft routine material, search internal knowledge or summarise non sensitive data under clear policy. Review here can be light, focused on tool approval, data handling and user guidance.
A medium risk tier might include AI assisted workflow steps in operations, customer service, sales support or internal analysis where the tool is connected to business data or directly affects service quality. These use cases usually need stronger design review, testing, logging and named business ownership.
A high risk tier covers cases where AI affects people, rights, eligibility, pricing, regulated activity, safety critical operations, high value financial decisions or sensitive data at scale. These cases may need impact assessment, privacy assessment, legal review, stronger security design, formal human oversight arrangements, and tighter approval to go live.
The operating model should define what each gate includes. Typical gates include: initial triage, design approval, data and privacy review, security review, pilot approval, go live approval and post launch review. The key is proportionality. A small firm can run this with one cross functional monthly forum and a few standard checklists. A larger enterprise may need a standing committee structure. The discipline matters more than the ceremony.
Maintain an AI system register and approved tool list
If a business cannot state which AI systems it is using, where they are used, and who owns them, its operating model is incomplete.
An AI register is one of the most practical controls an organisation can create. It should record the use case, owner, model or tool used, vendor where relevant, data involved, key risks, review status, go live date, monitoring measures and review schedule. For small firms this can start as a controlled spreadsheet. Over time it may move into a richer governance platform. The principle is the same.
Alongside the register, most organisations benefit from an approved tool list. This tells staff which AI platforms, copilots, document tools, model providers and integrations are permitted for which types of work. It also clarifies where staff must not place sensitive content, when personal accounts are prohibited and which tools need prior approval.
This is not just governance housekeeping. It prevents fragmented spend, reduces shadow AI, improves vendor oversight and makes training much easier. Users cannot follow good policy if the business has not made the safe path clear.
Decide how centralised or federated the model should be
One of the most persistent AI management questions is whether the capability should be centralised or federated. The honest answer is that there is no universal right model. There is only a fit between the organisation's size, maturity, risk profile and the kind of AI work it is trying to run.
A centralised model concentrates expertise, tooling, standards and governance in one team. This can work well early on because it prevents duplicated work, helps the business choose approved tools, creates a coherent review path and makes scarce expertise easier to share. It is often useful when AI is close to the core of the enterprise and standardisation matters.
A federated model places more ownership in business domains. This can work well when different functions have genuinely different contexts, data, regulatory conditions or user needs. Domain teams are often better placed to judge practical fit because they are closer to the work.
In practice, many organisations benefit from a hybrid or hub and spoke model. A small central team sets policy, tooling standards, security expectations, vendor rules, training patterns and governance. Business units own their use cases, process fit, data context and live service performance. This balance often suits small and mid sized firms because it gives enough control without pulling every decision away from the people who know the work best.
The mature question is not "Which model is correct?" It is what should be central for consistency, and what should stay close to the business for context and accountability?
Fund AI as a portfolio, not as disconnected experiments
An operating model also needs a funding logic. Without it, AI work tends to split into two unhelpful camps. Either everything is treated as innovation and never leaves pilot mode, or everything is pushed into local departmental budgets with no shared investment in core capability.
A stronger pattern is to separate shared capability from domain use cases. Shared capability includes approved tooling, security architecture, review processes, training, reusable integrations, model access patterns, and central support. Domain use cases then draw on that foundation while carrying their own business case and service ownership.
Stage based funding helps as well. Discovery work should be cheap and fast. Pilots should have explicit questions to answer. Scaling should require evidence that the use case is working in live conditions, not just in demonstration. Mature organisations also budget for monitoring, retraining, support, review and retirement. AI needs lifecycle funding, not just launch funding.
A useful side effect of this approach is honesty. It becomes easier to stop weak use cases because they are not protected by vague innovation rhetoric. Each use case has to keep earning its place.
Build role based skills and user discipline
An AI operating model is incomplete if it assumes staff will somehow work out safe and effective use by themselves.
All employees need a baseline level of AI literacy if the business expects them to use AI in routine work. That includes understanding what approved use looks like, what data should not be shared, how to treat generated content, where human checking is required and how to report incidents or concerns.
Managers need more than that. They need to understand where AI fits in their processes, how to supervise human validation, how to measure value, and how to spot when staff are over relying on a tool. Process owners need to know how to frame use cases and interpret operating measures. Compliance and privacy teams need enough literacy to review responsibly rather than react in blanket disbelief. Security teams need to understand AI specific attack surfaces and access patterns. Senior leaders need enough knowledge to set direction and make trade offs without outsourcing every judgement to advisers.
This is why a role based training model is usually better than a single generic course. AI use at work is not one skill. It is a cluster of responsibilities that vary by role.
Monitor the live estate and review it regularly
Once an AI use case goes live, the operating model should move into steady state supervision. That means regular review of performance, incidents, exceptions, complaints, drift, cost, user behaviour and continued business relevance.
A sensible review asks simple questions. Is the use still delivering the intended business value? Is the error pattern acceptable? Are people using the system in the way it was designed? Have data sources changed? Have policies changed? Has regulation changed? Has a vendor changed model behaviour, terms of service or security posture? Is the use still proportionate to its risk?
There should also be a path for escalation and decommissioning. Organisations put too much focus on approval and not enough on stopping. Every operating model should make it normal to pause, restrict, redesign or retire an AI use case that no longer meets expectations.
This is particularly important because AI operating environments change fast. New tools arrive, embedded AI appears inside existing software suites, risks evolve and user behaviour shifts. A static governance document is not an operating model. A living review rhythm is.
Keep it proportionate for the size of the organisation
Senior leaders in smaller firms often worry that an AI operating model sounds like enterprise theatre. It does not have to be.
An 80 person firm does not need multiple committees and heavyweight artefacts. It does need named ownership, a simple use case intake, an approved tool list, an AI register, a light risk tiering method, monthly review points and role based guidance. Those few elements usually create far more control than dozens of disconnected experiments.
A 500 person firm may need a small central function or delegated champions in each domain. A 5,000 person enterprise may need much deeper formalisation. The principle is the same at every size. Make responsibilities visible, make approval proportionate, make records real, and make live review routine.
If the model becomes so heavy that teams avoid it, the design is wrong. If it is so light that nobody can tell who owns a live AI use case, the design is also wrong. Good operating models sit in the middle, enabling progress while keeping the business in control.
For the mechanics inside a specific process, the natural companion piece is Levellers.ai's "What is workflow automation?". For changing the shape of the process itself, see "What is workflow redesign?". The operating model sits above both.
Examples
A regional accountancy firm may decide that all AI use should operate through a small hub and spoke model. One central AI lead maintains the approved tool list, vendor terms, core guidance and AI register. Each service line, such as tax, audit and advisory, nominates a domain owner who proposes use cases and owns live use in that function. Partner review is required for any client facing drafting that relies on AI. This is an operating model because it defines structure, roles and review, not just one tool.
A multi site distributor might run AI across customer service, procurement and finance. The central operations office owns intake, prioritisation and shared integrations. Department heads own use in their teams. Security signs off systems with write access. Finance reviews automations that can affect payments. Every live AI use sits on the register with a named owner and quarterly review date. This prevents local experiments from turning into untracked operational dependencies.
A housing association could use a stricter model because some AI assisted work touches residents directly. Low risk internal knowledge assistance may be broadly allowed in approved tools. Medium risk service triage requires manager review. Any AI use that influences case decisions about residents requires stronger review, clear human oversight and documented explanation standards. The operating model creates these distinctions so that teams are not left to guess.
A manufacturer may centralise standards but federate delivery. The central team approves tooling, security patterns and data access rules. Plant and function leaders own use cases such as maintenance support, quality documentation, supplier correspondence and purchasing workflows. The central team shares templates and checks; the plants own context and live performance. This keeps standards coherent while respecting real operational differences.
Common misunderstandings
"Only large enterprises need an AI operating model." Any organisation that uses AI in more than a few isolated cases needs one. In a small firm it can be lean, but it still needs explicit roles, review points and tool policy.
"It is just a governance document." Governance is part of it, but the operating model also covers intake, ownership, data responsibilities, training, funding, deployment and live monitoring.
"It belongs in IT." IT and data teams are important, but AI use changes business processes and service delivery. Process owners and functional leaders must be part of the structure.
"There is one correct answer to centralised versus federated." The right balance depends on the organisation. Many firms do best with a hybrid pattern that centralises standards and keeps business ownership close to the work.
"Once we have written the model, we are done." The model has to evolve with new tools, new risks, new policies and new business uses. A static document is not enough.
"A strong operating model slows adoption." A poor one might. A good one speeds serious adoption because teams know what they can do, how to get approval and where help sits.
Risks and boundaries
The first risk is under design. Many organisations say they have governance when what they actually have is a loose set of opinions and an unmonitored tool policy. Without named owners, risk tiers, a register and a repeatable intake path, the operating model is not robust enough to carry live AI use.
The second risk is over design. If every small use case needs weeks of committee time, business teams will route around the model and create shadow AI. The safest structure is rarely the heaviest. It is the one that gives staff a practical approved path and keeps attention for the higher risk cases.
A third risk is separating accountability from the business. If technical teams own everything and process leaders own nothing, AI work often becomes detached from the service it was supposed to improve. The opposite is also risky. If business teams buy tools without security, data and privacy review, local convenience creates enterprise weakness.
There is also a blind spot around embedded AI. Many firms focus on custom builds and forget that AI is now appearing inside software suites they already use. An operating model should cover these vendor provided features too, because they still affect data handling, process flow and staff behaviour.
Another boundary is scope. An AI operating model does not replace AI strategy, though it should align to it. It does not replace AI governance, though governance is a major component inside it. It does not replace workflow design, service design or change management either. Those remain companion disciplines.
Finally, the living boundary is regulation and assurance. UK firms need to stay alert to privacy, fairness, explainability and accountable decision making. Firms operating into the EU or using AI in scope activities should also watch the AI Act's staged obligations and supporting guidance. An operating model should make that watchfulness routine rather than reactive.
What to do next
First, appoint an executive sponsor and a small cross functional core team. In a smaller firm this might be only three to five people covering business ownership, technology, data or privacy, and security.
Second, create a basic AI register and approved tool list. If you do only one practical thing this month, do this. It gives immediate visibility into what is already happening.
Third, define three risk tiers and the review gates attached to each. Keep the rules plain. Staff should be able to tell quickly whether a use case is low, medium or high risk and what review it needs.
Fourth, write down who owns what. Name the business owners for live use cases, the people responsible for data and security checks, and the people with authority to pause or stop a live AI use that becomes unsafe or unreliable.
Fifth, establish a simple intake and prioritisation rhythm. A monthly review of new ideas is often enough for a mid sized organisation. Use a standard template so proposals can be compared rather than argued over informally.
Sixth, launch role based guidance and training. Start with managers and the teams already using AI, then widen the baseline across the workforce. People cannot follow standards they have not been taught.
Seventh, choose your structural pattern consciously. If you are early in maturity, a small central team with domain champions is usually easier to control than fully decentralised adoption. If domains differ strongly, let them own context while the centre owns guardrails.
Eighth, review the model quarterly. Look at the register, incidents, training uptake, live performance and blocked proposals. The operating model should adapt as the business learns.
Ninth, once the structure is in place, link it to practical delivery. Use it to support real workflow improvements, pilots and proof of value work rather than treating it as a compliance exercise. For process level mechanics, Levellers.ai's "What is workflow automation?" is the natural next read.
Have a question or a suggestion, or want to understand how we research and review these guides? Read about our editorial standards and how to reach us.
FAQs
What is the difference between an AI operating model and AI strategy?
AI strategy sets direction, ambition and priority. The operating model is how the organisation actually runs AI day to day, including roles, approvals, funding, data responsibilities, delivery and monitoring.
What is the difference between an AI operating model and AI governance?
Governance is one part of the operating model. The operating model is broader. It includes governance, but also intake, ownership, skills, funding, deployment support and live supervision.
What is the difference between an AI operating model and workflow automation?
Workflow automation is about the mechanics inside a specific process. The AI operating model is the organisation wide structure around all AI use, including how those process level automations are approved, owned and monitored.
Who should own the AI operating model?
It should have clear executive sponsorship, but no single technical function should carry it alone. Business leadership, technology, data or privacy, security and compliance usually all need a role.
Do we need a formal AI committee?
Not always. Smaller firms can run effective oversight through a lightweight monthly forum with named accountabilities and standard review criteria. The key is repeatability, not ceremony.
Should AI be centralised or federated?
Usually some of each. Centralise standards, approved tools, core guardrails and shared expertise. Keep business context, process ownership and live accountability close to the teams doing the work.
How much documentation is enough?
Enough to show what is in use, who owns it, what data it touches, what risks were identified, what review was completed and how the live use is monitored. If you cannot answer those questions quickly, you likely need better records.
What about AI features already embedded in software we buy?
They should still sit inside the operating model. Vendor provided AI can affect data flows, process decisions and user behaviour just as much as a custom build.
Can one person hold several roles in a small organisation?
Yes, as long as the responsibilities are explicit. Small firms often combine roles, but they still need clarity on who owns business value, data handling, security checks and live review.
How often should we review the operating model?
Quarterly is a sensible minimum for most organisations using AI actively. High risk environments may review more often, especially when tooling or regulation changes.
Sources
ISO/IEC 42001:2023 - AI management systems (ISO). The concept of an AI management system, continual improvement, organisation wide governance, and the idea that AI should be managed through policies, objectives and processes rather than one off technical work.
ISO/IEC 38507:2022 - Governance implications of the use of AI by organizations (ISO). Board and senior leadership responsibilities, governance of AI use across organisations of any size, and the distinction between enabling and governing AI at organisational level.
Artificial Intelligence Risk Management Framework (AI RMF 1.0) (NIST). A risk based operating structure across the AI lifecycle, including governance, role definition, human oversight, monitoring, documentation and third party management.
AI Principles (OECD). Human centred AI principles, transparency, accountability, robustness, human oversight and lifecycle traceability, which all inform the design of an AI operating model.
OECD Due Diligence Guidance for Responsible AI (OECD). Practical due diligence steps for embedding AI into management systems, identifying impacts, mitigation, tracking and communication, supporting the article's view of AI as ongoing capability.
AI Management Essentials tool (GOV.UK). Concrete organisational checklist items such as AI system records, AI policy, role clarity, impact assessment, risk thresholds, monitoring, data provenance and review frequency.
Organisational roles and functions for explaining AI (ICO). Role design across the decision making pipeline, including product manager, AI development team, implementer, compliance and senior management, plus primary responsibility where third party systems are used.
AI and cyber security: what you need to know (NCSC). The need to treat AI security as an organisational issue, integrate security from inception, and connect leadership, culture, process and technical control in the operating model.
AI Act - Shaping Europe's digital future (European Commission). Current official summary of the EU AI Act, its risk based approach, staged application dates, governance expectations, SME support and the continuing relevance of regulatory awareness for UK organisations with EU exposure.
AI Center of Excellence (Deloitte). The practical question of centralised versus federated AI, the value of a centre of excellence, use case backlogs, and the need to treat AI as ongoing enterprise capability rather than isolated interventions.