IT operations was shaped by scarcity of attention: a queue of tickets, a runbook read by a person, a change advisory board that met weekly, an on-call rota that spread the burden over a small team. That shape held while the estate was small enough, the change rate low enough and the providers few enough for people to keep the picture in their heads. This chapter explains why it now strains. Six pressures act on the operations loop at once: complexity and dependency, the volume of change, the volume and cost of telemetry, the limits of people and skills, the cost of compute and energy, and the duty that regulation places on the management body together with adversaries who work at machine speed. The chapter concerns all five operations functions, O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain, which Chapter 4 defines; it shows where each pressure lands and why AI is arriving in operations as a response to them, not only as a product trend.
The table gives the function on which each pressure lands.
The chapter is also an exercise in restraint. Much of what is written about operations under pressure rests on vendor surveys, conference anecdotes and the memory of the worst night of someone's career. Some of it rests on measurement. The chapter therefore grades each claim before using it, says what the source measured, in whom and over what period, and keeps the book's own conclusions apart from what the sources report. It builds on the earlier volumes at several points. The first is machine-speed adversaries and the four commitments against them (F35 and F36, AI Platform and Security, Chapter 18) (297, Nordqvist, 2026); digital sovereignty as verifiable properties and not a location (F47, AI Platform and Security, Chapter 13). The second is recoverability as a measured, rehearsed property (F58, AI Red Team, Chapters 22 to 24) (298, Nordqvist, 2026). The third is the loop that closes defined low-risk classes and leaves a queue plus the review of what it closed (F94, AI Blue, Chapter 6) (302, Nordqvist, 2026). The fourth is the analyst's attention as the scarce resource (F110, AI Blue, Chapter 21). The fifth is the finding that the rhythm of periodic testing assumed exploitation took longer than the interval between tests (F117, AI Purple, Chapters 2 and 3).
Primary topics explored
- Reading the evidence: three grades
- Complexity and dependency
- Change volume
- Telemetry volume and cost
- People
- Compute, energy and cost
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 3: The Pressure on Operations: Complexity, Dependency, Cost and Machine-Speed Change in AI Operations gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Operations in Question” and is one of 35 drawn from the manuscript.