Most outages begin with a change, and most of the changes that operators now review begin as a draft written by a machine. This chapter concerns O3 Change: altering the estate safely, through releases, configuration and infrastructure as code, with provenance, policy checks and a way back. It touches O1 Observe where drift between declared and actual state is detected, and it leaves staged rollout, freezes and blast-radius budgets to Chapter 9, runbook execution to Chapter 10 and change authority to Chapter 22. Its subject is what the pipeline looks like when agents write much of the change, what a reviewer needs to know about a draft that no person wrote, how policy checks are made independent of the author, how review stays real when drafting is cheap, how declared and actual state are kept together by state engines such as GitOps controllers, and what standard, normal and emergency change mean when most change is machine-authored.
The chapter builds on the earlier volumes. Architecture as Code (Chapters 10, 11, 13 and 20) established policy as code, tests in the pipeline and the rule that agents draft and humans approve (F3, F7, F12, F13) (295, Nordqvist, 2025). AI Platform and Security, Chapter 4, gave the control plane in which the declarative model can be checked against the running estate (F37) (297, Nordqvist, 2026), and AI Governance, Chapter 24, concluded that a weekly change advisory board cannot sit in the path of known-exploited vulnerabilities (F29) (296, Nordqvist, 2026). The Transformed Security Architect, Chapter 13, set the mandate manifest and the accountable verifier (F75) (300, Nordqvist, 2026). AI Purple, Chapter 10, concluded that when AI drafts every kind of change the bottleneck is review, so that caps on open drafts, a named reviewer who is not the drafter and seeded errors are design requirements (F126) (304, Nordqvist, 2026).
A change pipeline carries an intention to production as code. The intention is a request that says what should be different and why. It becomes a diff against declared state held in version control, passes checks that do not depend on its author, is approved by a person whose standing is independent of the requester, is released by a pipeline identity inside a window, is verified by something other than the releaser, and ends in a record. The sequence is old. What changes with AI is who sits at the authoring step and how many changes enter it per day.
Primary topics explored
- The change pipeline
- AI-authored change
- Provenance
- Policy as code in the path
- Review load
- State engines and reconciliation
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 8: Change: Releases, Infrastructure as Code and AI-Authored Change in AI Operations gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Craft” and is one of 35 drawn from the manuscript.