An AI strategy can be coherent and still produce disconnected pilots. Strategy says where the organisation intends to compete, improve or reduce risk. It does not automatically assign the operating decisions that make the direction executable.
An AI operating model answers a different question: How will people, information, workflows, systems, authority and funding work together repeatedly?
Strategy chooses; the operating model executes
A useful strategy should make choices about outcomes, priorities and boundaries. It might decide that AI will improve service operations, strengthen knowledge work or reduce manual coordination.
Execution then exposes questions the strategy deck cannot settle by itself:
- Who can approve an AI use case?
- Which team owns its business outcome?
- Who maintains the information it depends on?
- Where does the work enter and leave the workflow?
- Which actions require human approval?
- How are exceptions funded and staffed?
- What evidence earns expansion?
If these decisions remain implicit, each pilot invents its own answer. The portfolio becomes difficult to compare, govern and maintain.
The seven parts of an executable AI operating model
Decision rights
Specify who proposes, evaluates, approves, stops and expands an initiative. Decision rights should distinguish business ownership, technical assurance, risk authority and operational intervention.
Accountable ownership
Every capability needs an owner for its result and an owner for its operation. Those may be different people. “The AI team owns it” is inadequate when another function experiences the customer, financial or regulatory consequence.
Workflow integration
The operating model identifies where AI participates in real work: the trigger, inputs, state change, handoff, exception and completion condition. A demonstration becomes a capability only when it can operate inside these conditions.
Information stewardship
Teams need rules for permission, provenance, quality, freshness, correction and retention. The model cannot compensate for unclear source ownership or conflicting systems of record.
Authority and controls
Define what a system may draft, recommend or execute and where a person must review. Connect each control to the consequence it manages. An approval added everywhere creates theatre; an approval missing from a consequential action creates hidden delegation.
Funding and delivery cadence
Separate discovery, bounded implementation, operation and expansion funding. A pilot budget may prove technical possibility while leaving no owner or capacity for monitoring, exceptions and maintenance.
Feedback and evidence
Create a review cadence around outcome, failure, intervention, risk and cost. Evidence should support a decision: continue, change, expand, constrain or retire.
Governance is part of operation
NIST AI RMF describes Govern as cross-cutting and organises AI risk activity through Govern, Map, Measure and Manage. ISO/IEC 42001 uses a management-system approach centred on establishing, implementing, maintaining and continually improving how an organisation handles AI.
Neither source turns an operating model into a single universal org chart. Context matters. The practical implication is that governance must appear in recurring work: approvals, ownership, monitoring, incident treatment and review—not only in a policy document.
A diagnostic for leadership teams
Choose one current AI initiative and ask seven questions:
- Which strategic choice does it serve?
- Who owns the business consequence?
- Which workflow state does it change?
- Which information may it use, and who stewards it?
- Which actions are permitted, reviewed or prohibited?
- Who funds and operates it after the pilot?
- Which evidence decides whether it expands?
If the answers exist only inside the project team, the organisation has a project arrangement, not a dependable operating model.
What changes when the model is working
An effective operating model makes progress less dependent on informal access to a few specialists. Teams can see how an opportunity enters the portfolio, what evidence it needs, who can make each decision and how a deployed capability will be supervised. Exceptions have named destinations instead of disappearing between functions.
It also makes stopping easier. A use case that cannot secure reliable information, a responsible owner or proportionate control can be constrained before technical momentum turns it into an operational obligation. Conversely, a capability that repeatedly produces the intended outcome can expand through an understood decision path rather than through executive enthusiasm alone.
The test is not whether the organisation has created an “AI operating model” diagram. The test is whether two comparable initiatives encounter the same intelligible rules for ownership, authority, evidence and operation—and whether those rules improve as the organisation learns.
What to do next
Do not respond by designing an enterprise-wide bureaucracy. Make the operating decisions explicit around one meaningful workflow, test them and establish the smallest repeatable model.
[Operational Architecture](/operational-architecture/) is the relevant next step when ownership, process and system boundaries are fragmented. The article on [designing an AI operating system before buying more tools](/blog/ai-for-business/design-ai-operating-system-before-buying-tools/) provides the supporting system view. If the initiative itself is not yet bounded, begin with [AI Architecture Advisory](/ai-architecture-advisory/).
Sources and scope
NIST and ISO sources provide governance and management-system context. The seven-part operating model and diagnostic are original netlinkE analysis. They do not represent an official NIST or ISO implementation method.
