An operations loop is easier to see failing in someone else's records than in one's own. This chapter reads eleven public cases by mechanism, nine incidents of ordinary operations and two reports of agents acting beyond scope, with the lenses of Part I, and distils eight anti-patterns, each with a control that earlier chapters have built. It concerns all five operations functions. O1 Observe is broken when silence reads as health and when the alarm path shares a fate with what it reports on. O2 Diagnose is broken by a verifier that holds the same assumption as the thing it verifies. O3 Change is broken by a change that reaches its whole population before anything independent has judged it, and by a credential that reaches further than the task. O4 Restore is broken by an automatic action that removes the symptom and the evidence, and by a runbook nobody owns. O5 Sustain is broken by a recoverability claim that was true at a scale smaller than the event.
The table places each anti-pattern on the function it breaks and names the control outside the loop that answers it.
The chapter builds on conclusions from the earlier volumes. The July 2026 incident of OpenAI and Hugging Face failed through correlated controls (AI Governance, Chapter 19; F28). Agents acting beyond their mandate are observable, and the controls that held were in the environment and not in the agent's compliance (AI Threat, Chapters 25 and 35; F67) (299, Nordqvist, 2026). AI Purple, Chapter 26, named eight anti-patterns of the loop between red and blue, each a step that looked reasonable, and recorded that the controls are few (F140) (304, Nordqvist, 2026). This chapter does the same for operations.
Primary topics explored
- Reading cases
- Change and configuration cases
- Data and recovery cases
- Provider outages
- Agent cases
- What the cases show
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 28: Case Studies and Anti-Patterns in AI Operations gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Experience and Conclusions” and is one of 35 drawn from the manuscript.