An operating model is the answer to four questions about every service: who runs it, who owns it, who may act on it and who is called when it fails. For decades the answers followed from scarcity. Attention was scarce, so tickets queued; skill was scarce, so specialists were pooled into central teams; night cover was expensive, so it was bought. AI loosens the scarcity of attention without removing the other constraints, and the answers shift: the loop that one person can supervise becomes larger, the provider's tooling starts to act with its own rules, and the team that owns the platform acquires a new product, the operator's own agents. This chapter compares the operating models that European enterprises and public authorities actually use, shows what AI changes in team topology and in who owns what, sets out how a managed operations provider is bought when its AI acts, defines the operations conductor as a role, and treats the case of regional and national operators in the public sector. It concerns all five operations functions: O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain, because an operating model decides who performs each of them and under which delegation.
The chapter builds on conclusions of the earlier volumes. Platform teams act as internal service providers and the system mirrors the organisation's communication paths (Architecture as Code (Chapters 17 and 18), F10) (295, Nordqvist, 2025). Hub-and-spoke scales when the hub is a platform team in X-as-a-service mode and control functions keep their independence through gates and records rather than meetings (AI Governance, Chapter 12, F22) (296, Nordqvist, 2026). Managed triage with embedded vendor AI is the Mode 0 blind spot in practice, and the answer is a contract that states levels and actions, sampling, audit rights, evidence, tuning and test rights and notice of model change (AI Blue, Chapters 7 and 16, F97) (302, Nordqvist, 2026). Four operating models recur, an organisation runs a mixture, and the decision is made per stage and recorded with exit criteria (AI Purple, Chapter 19, F133). Chapter 4 defines the autonomy budget and the observer principle used throughout.
Four things are fixed by an operating model, whether anyone wrote them down or not. The first is who performs each of the five functions: who reads the telemetry, who diagnoses, who changes, who restores, who plans capacity and learns. The second is who owns: the named person accountable for a service, an objective, a runbook and, since AI arrived, an agent. The third is who may act, which is the delegation profile of Chapter 4 and the decision rights of Chapter 22. The fourth is who is called, that is, the on-call and escalation structure of Chapter 25. A model that answers the first question well and leaves the other three implicit works until the first incident that crosses a boundary.
Primary topics explored
- What an operating model decides
- The options
- What AI changes
- Ownership: four owners
- Buying operations with AI inside
- The operations conductor
About AI Operations
AI Operations is Book 10 of The Transformed Architecture. It takes IT operations as its subject and asks what happens when AI takes part in it: the five operations functions (observe, diagnose, change, restore, sustain), the autonomy budget and the Level 4 prohibitions, the observer principle, resilience as a claim that needs evidence, operating AI systems, the operator's own AI as Tier 0 and how to defend it, operating models, decision rights, regulation (DORA, NIS 2, the AI Act), and the people involved, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue and AI Purple.
CIOs and heads of IT operations, SRE and platform leads, incident commanders and on-call engineers, service-desk and service-management leads, FinOps and capacity managers, architects, CISOs and heads of resilience and third-party risk, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 21: Operating Models: Platform Teams, SRE, Managed Services and Sovereign Operations in AI Operations gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Operations in the Organisation” and is one of 35 drawn from the manuscript.