Every operations function described so far stops, at some point, at a boundary that the organisation does not own: a cloud region, a managed service provider's night shift, a software-as-a-service vendor's telemetry, a model provider's fallback. This chapter treats those boundaries and concerns three of the five functions: O1 Observe, because the provider's view of an outage and the organisation's are different measurements and only one is under the organisation's control; O4 Restore, because a recovery that depends on a provider is a claim about the provider as well as the organisation; and O5 Sustain, because contracts, registers, exit plans and switching rights are the lifecycle of a dependency, and a dependency that cannot be left has been accepted without being decided.
The chapter takes over three deferrals. Chapter 15 left open how a fallback provider for an AI service enters the contract set and, for a financial entity, the register of information. Chapter 21 gave the six terms that bring a managed provider's AI under a contract and left the DORA contract provisions and the Data Act's switching terms to this chapter. Chapter 4 fixed that a provider's embedded AI acts at a level the provider chose, which AI Red Team, Chapter 8, called the Mode 0 blind spot.
The chapter builds on the series' conclusions on sovereignty and suppliers. Digital sovereignty is a set of verifiable properties and not a location (AI Platform and Security, Chapter 13) (297, Nordqvist, 2026); a contract right is a promise until the first sample, seed or stop request shows that it works (AI Blue, Chapter 28); and crossing a boundary needs standing consent in the contract, notice before each run and a stop held outside the system stopped on both sides (AI Purple, Chapter 22) (304, Nordqvist, 2026). AI Governance, Chapter 7, treated procurement as governance (296, Nordqvist, 2026); this chapter treats what operations needs from the same contracts.
Primary topics explored
- Concentration
- In an outage
- Provider status as telemetry
- Contracts and registers
- Exit and switching
- Multi-region and multi-cloud
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 24: Across Boundaries: Cloud Providers, Managed Providers, Outages and Exit 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.