Part II treated operations with AI as the operator. This chapter turns the relation round and treats AI as the thing operated. A service that contains a model, a prompt, a retrieval index and a set of tools behaves differently from a service made of code alone: its behaviour can change when nobody has deployed anything, because a provider has replaced a model, an index has gone stale or the world that the model was trained on has moved. The chapter concerns O1 Observe, where quality, drift and freshness become service level objectives that are measured independently of the model under test; O3 Change, where a model, a prompt or an index is released, canaried, pinned and rolled back as configuration with a change record; and O5 Sustain, where provider notices, retirements and deployer duties are kept as a standing part of the service's lifecycle.
The subject is the operation of AI systems in the series' Modes 2 to 5, that is, embedded workplace assistants, agentic work tools, built AI applications and autonomous production agents (AI Governance and AI Platform and Security, Chapter 2). AI Platform and Security, Chapter 21, treated observability, monitoring and drift in production as a capability of the platform (297, Nordqvist, 2026), and AI Platform and Security, Chapter 20, set out the evaluation pyramid and the evaluation of AI systems before release. This chapter takes both as given and asks what the operator does with them: how a change to an AI service passes through the same discipline as any other change, what extra the discipline needs, and what a deployer of a high-risk AI system must be able to show. Incidents that involve AI are the subject of Chapter 14, the cost of running AI of Chapter 15, and the contract terms that make provider change visible of Chapter 24.
A conventional service changes when its code, its configuration or its infrastructure changes. Each of these is recorded in a repository or a change system, and an operator who asks what changed can look for a record. An AI service has the same three sources of change and at least five more, and several of them leave no record in the operator's own systems.
Primary topics explored
- What is different about an AI service
- Versions as configuration
- Provider-side change
- Quality objectives
- Canarying a model
- Deployer duties
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 13: Operating AI Systems: Drift, Model Updates and Provider Change in AI Operations gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Operating AI Systems” and is one of 35 drawn from the manuscript.