Introduction: Operations with AI

IT operations is the function that keeps services running every day: it sees what the estate is doing, finds out what has gone wrong, changes the estate without breaking it, brings services back when they fail and keeps the whole fit for the next year. This book asks what happens to that function when AI takes part in it, and what happens when the operator's own AI becomes one of the most privileged workloads that the organisation runs. It concerns all five functions of the operations loop that Chapter 4 defines: O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain. This chapter states the question, the thesis, the vocabulary and the rules of the book, introduces the two fictional organisations that run through it, and gives each kind of reader a path.

The book is written for the people who answer for services: chief information officers and heads of operations, site reliability engineering (SRE) and platform leads, incident commanders and on-call engineers, service-desk leads, resilience officers, architects, and the boards and supervisors who receive the evidence. It is also written for the works councils, unions and data protection officers who must agree how on-call rotas and operations tools treat the people who use them. Its subject is European enterprises and public authorities, so the law that governs their operations is part of the argument from the start.

The book on one page: the five functions of the operations loop with the chapters that treat them, and the mandates, observer, stop path and register outside the loop

Figure 1.1: The five functions of the operations loop with the chapters that treat them, and what sits outside the loop.

Two nights, one outage

Two organisations, a Nordic regional authority and a German insurance group, receive on the same night a release that breaks sign-in to a public portal. The scenario is illustrative; it is not one of the book's incident records, and it is told here to show what the rest of the book is about. The organisations are fictional and are introduced below.

At the regional authority, an engineer starts the release at 01:50 under a change record that names the author, the reviewer and the rollback plan. At 02:10 the portal's objective for sign-in begins to burn its error budget, and the observability stack pages the engineer on call, who opens an incident. The operations assistant retrieves three past incidents and the change that went out twenty minutes earlier, and proposes the change as the likely cause. It is a Mode 4 application at Level 0 Advisory: it suggests, and a person acts. The duty manager, acting as incident commander, approves the rollback, the engineer runs the catalogued runbook, and a synthetic sign-in from outside the platform confirms recovery at 02:41. The timeline is written by the people involved, the next morning, from the tickets and the chat. It is slow work, and it is accurate about who did what.

At the insurance group, the same release reaches a customer portal. At 02:10 the IT-operations agent, a Mode 5 agent with an identity and permissions of its own and a mandate for restarts, certificate renewal and scaling, sees the service failing its health check and restarts the affected pods under a catalogued runbook. The restart works for a few minutes. The agent confirms success by calling the health endpoint that the restart has just reset, and the observability vendor's assistant, trained on the same baselines, groups the repeated alerts into one and lowers their priority. Two further restarts follow before the policy decision point stops the runbook on its rate limit and pages the incident commander at 02:34. By then the logs that would have shown the cause have been overwritten by the restarts, and the group's page target of five minutes has been missed by twenty. Hansa Mutual can later prove exactly what the agent did, because the agent's actions are logged outside it. What it cannot prove, without work, is whether the service was ever healthy between the restarts.

The two nights differ in speed, and the faster night is not the better one. The first shows slow, bounded and well-evidenced operation with one thing missing: it will not scale. The second shows operation at machine speed with the same failure the SRE literature and the human-factors research on automation have described for decades, a loop that closes itself and reports success on its own evidence (217, Bainbridge, 1983). The questions of this book are the questions that separate the two nights. What may the system do on its own, and who set that limit? What verified that the action worked, and was the verifier independent of the actor? Who could stop it, and did the stop work when the platform did not? What can the organisation show afterwards, to itself and to a supervisor, about what was tested, when and with what result?

Operations with AI in 2026

IT operations has several shapes today, and the book uses the word in the widest sense. Service management is the discipline of ITIL 4, a framework of service management practices, and of ISO/IEC 20000-1, which describe practices and a management system for services (121, PeopleCert, 2023) (48, ISO/IEC, 2018). Site reliability engineering is the practice, set out by Google's engineers, of running production as an engineering problem with objectives, error budgets, a cap on toil and blameless review (112, Beyer et al., 2016). Platform engineering offers the estate as an internal product to the teams that build on it (273, CNCF TAG App Delivery & Platforms Working Group, n.d.). Managed operations buys parts of all of this from a provider. Chapter 2 gives the history and what each practice got right; Chapter 3 describes the pressures that strain the inherited shape.

AI is arriving in each of these shapes, and the arrival is observable in the sense of the series' labels: it is happening now and is documented. Observability platforms ship anomaly detection, event correlation and alert summaries, often switched on by default (Mode 0 Ambient AI). Incident tools ship assistants that retrieve past incidents, rank hypotheses and draft status updates. Engineers use agentic work tools (Mode 3) to draft infrastructure code and runbooks, so that a large share of the change that operators review begins as a machine's draft. Remediation agents (Mode 5) restart, scale, renew certificates and in some organisations roll back. Service-desk assistants resolve requests. Capacity and cost tools propose rightsizing. In the DevOps Research and Assessment (DORA) programme's 2024 survey announcement, more than 75 per cent of respondents said that they rely on AI for at least one daily professional responsibility, and as AI adoption increased it was accompanied by an estimated decrease in delivery throughput of 1.5 per cent and in delivery stability of 7.2 per cent (251, Harvey & DeBellis, 2024). The announcement describes an association in a survey, not a measured cause, and Chapter 3 reads the figures with that limit. The abbreviation DORA in the rest of this book means the Digital Operational Resilience Act, Regulation (EU) 2022/2554; the research programme is called by its full name where it is meant, and Chapter 20 introduces its four key metrics.

At the same time, operations has become the place where AI systems themselves are run. A model that a provider updates without notice, a prompt and a retrieval index that change like configuration, inference capacity that is scarce and costly, and an incident in which an assistant acts outside its mandate are all operations matters (Chapters 13 to 15). The operator is therefore both the user of AI and its keeper.

What is expected is the delegation of routine, reversible classes of operations action to agents, class by class, as evidence accumulates. What is speculation, on the evidence of the sources examined in Chapters 6, 7 and 27, is the unattended operation of whole estates, including recovery from novel failure. The book holds the three apart, because most of the confusion in the field comes from describing the second as if it were the first.

Why a book on operations

The earlier volumes of the series treated operations from the outside. AI Platform and Security described how an AI platform is built and run (297, Nordqvist, 2026). AI Red Team put AI to work in cyber defence, including the Recover Function (298, Nordqvist, 2026). AI Blue described the team that defends (302, Nordqvist, 2026), and AI Purple the loop that verifies the defence (304, Nordqvist, 2026). None of them took as its subject the function that keeps services running every day. Three reasons make it a book and not a chapter.

Operations holds the most powerful credentials in the estate. An agent that can restart, deploy, scale and delete in production is in effect an administrator, and the control plane it uses is Tier 0, a conclusion that AI Platform and Security, Chapter 17, drew for the AI platform and that this book extends to the whole estate. The observability pipeline holds logs that contain personal data and a map of every service and dependency. The runbook library is a set of instructions that an agent will execute, so an unauthorised edit is an action. The operator's AI is the best-placed asset in the organisation for an error to do damage and for an adversary to use, and Chapters 16 to 18 treat it as such.

Operations is where loops are closed without a person in them. Auto-remediation was the first widely accepted form of delegated machine action, which means that decades of experience of what automated operations does to the people who supervise it can be set beside the new agents. Bainbridge argued in 1983, about industrial process control, that automation leaves the operator to monitor the automatic system and to take over when it fails, that taking over requires manual and cognitive skills, and that skills which go unused deteriorate (217, Bainbridge, 1983). Parasuraman and Manzey's review found that complacency and automation bias affect both novice and expert users and are not removed by practice alone (218, Parasuraman & Manzey, 2010). These are findings about other domains and other automation; Chapters 25 and 26 say what they imply for operators and what remains unmeasured.

European regulation now treats operations as a duty of the management body. DORA Article 5 places the management body of a financial entity in charge of the risk management of information and communication technology (ICT), and NIS 2 (Directive (EU) 2022/2555) Article 20 does the same for the management bodies of essential and important entities, with approval of the measures, oversight of their implementation and training (2, European Union, 2022) (3, European Union, 2022). The same instruments, with the AI Act and the GDPR, set the clocks for reporting an incident, the duties to log, test and keep records, and the rules for third-party providers (1, European Union, 2024) (6, European Union, 2016). The Data Act's Chapter VI adds the mechanics of switching between cloud-type services (16, European Union, 2023). Chapter 23 maps the articles to the five functions. Two conclusions of that chapter matter here. The instruments state outcomes (continuity, tested recovery, recorded and reported incidents, managed providers, competent oversight) and say little about how far a machine may act, apart from Article 14 of the AI Act and Article 22 of the GDPR; the autonomy budget of this book is a design that makes the outcomes demonstrable when an agent acts, not a legal requirement. And a statement about law in this book describes an organisational and architectural implication; it is not legal advice.

The traditional shape of operations was set by scarcity of attention: queues of tickets, runbooks read by people, change advisory boards, on-call rotas. AI loosens that constraint. It does not remove what operations was always for, which is services that are available, correct and recoverable at an acceptable cost, and a named person who is accountable when they are not.

The working thesis

The thesis has five parts. They are the book's own claims, tested in Parts II to V and judged in Chapters 27 and 31.

  1. Operations is transformed, not abolished: from the queue to the control loop. The work moves from handling tickets and alerts to designing, bounding and verifying closed loops: service level objectives (SLOs) that say what good is, runbooks that are code, mandates that say what an agent may do. The operator becomes the accountable conductor of an operations loop, the series' conductor theme (The Transformed Security Architect, Chapter 3 (300, Nordqvist, 2026)).
  2. Autonomy is matched to reversibility and blast radius, and has a budget. Every action class has a degree of delegation, Level 0 Advisory to Level 4 Autonomous, set by what can be undone, how far a mistake spreads and the agent's evidenced record. Errors consume the budget in the way they consume an SRE error budget (258, Alvidrez, 2017), and a stop path outside the system it stops is part of every design.
  3. The operator's AI is part of the estate it operates. Remediation agents, observability pipelines, runbook libraries and configuration maps are Tier 0 assets and are designed, contained, monitored and tested as the most privileged workloads the organisation runs.
  4. A loop closed by machines alone can hide its own failure: the observer principle. Self-healing removes symptoms and can remove the evidence of the cause; noise reduction can suppress the one alert that matters; an agent can verify its fix with the metric it just changed. What verifies an operations action must be independent of what performed it, the observer must not depend on the system observed, and the stop path must work when the platform does not.
  5. Resilience is a claim that needs evidence. "Recoverable" is a statement with a scope, an objective, a measurement, a date and a result. Untested is not recoverable, and evidence expires as the estate changes. The same holds for the operator's competence: a skill not exercised decays, so manual operation is kept in practice on purpose.

Parts four and five rest on the series' earlier conclusions. The observer principle is the independence principle of AI Purple applied to operations, and resilience as a claim is its coverage-as-a-claim applied to recovery (304, Nordqvist, 2026). The matching of autonomy to reversibility and the stop path outside the system being stopped are conclusions of the whole series, drawn together in AI Threat, Chapter 35 (299, Nordqvist, 2026).

A thesis that cannot be wrong is not worth stating, so the book says what would show it wrong. Independent incident data over several years, showing that fully autonomous remediation with no human exercise of manual operation and no independent verification yields fewer and shorter customer-impacting incidents and less severe tail events than a loop that keeps those properties, would refute the first four parts. Evidence that operators who do not practise manual recovery handle novel failures as well as those who do would refute the fifth. No such evidence exists in the sources examined for this book, and no study of operators' own wellbeing and skill under autonomous operations agents was found (Chapters 25 and 26). That absence does not support the thesis. It means that the thesis is a design position, to be judged as evidence arrives, and the chapters mark each place where a claim rests on argument and not on measurement.

Five functions and five degrees

The five functions are the red thread of the book. Each has an input, an output and an end, and each draws on several practices of service management without being one; Chapter 4 defines them and maps them to ITIL 4 practices, the NIST Cybersecurity Framework (CSF) 2.0 and DORA Articles 8 to 13, and states that the mappings are the book's own interpretation.

O1 Observe is seeing the state of services and of the estate: telemetry, service level indicators and objectives, the detection of operational anomalies and the cost of seeing. Chapter 5 treats it without AI, and Chapter 6 adds correlation, anomaly detection and the control of alert noise. O2 Diagnose is finding what is wrong and why: triage, change correlation, root-cause analysis and incident command (Chapter 7). O3 Change is altering the estate safely, through releases, configuration and infrastructure as code, with provenance, policy checks and a way back (Chapters 8 and 9). O4 Restore is returning a service to an acceptable state through remediation, rollback, failover and recovery from backup (Chapter 10). O5 Sustain is keeping the estate and the people fit over time: capacity, cost, energy, lifecycle, problem management, learning and the operator's craft (Chapters 11 and 12).

The degrees of delegation are the series' autonomy levels, reused from AI Red Team, Chapter 6, by their exact names (298, Nordqvist, 2026), and applied per function and per action class, because an agent that may restart a stateless web tier may not delete a volume. The levels are these. Level 0 Advisory: the AI suggests, and a person decides and acts. Level 1 Assisted: the AI drafts, and a person reviews and executes. Level 2 Supervised: the AI executes after explicit approval of each action. Level 3 Bounded: the AI executes pre-approved, reversible actions inside a catalogued runbook, under a mandate enforced by a policy decision point outside the agent. Level 4 Autonomous: the AI acts with no per-action approval and no runbook limit. Chapter 4 names eleven action classes, read, annotate, notify, scale, restart, reconfigure, deploy, roll back, fail over, delete and restore-overwrite, and gives each a default ceiling inside an authorised window. In operations Level 4 means in practice reading and annotating and little else.

Level 4 Autonomous is never used for four kinds of action: an irreversible action on production data; an action outside an authorised change window or freeze on a critical function; an action that disables the observation or the stop path itself; and an action that decides about a named person's access to work. Each rule has a mechanism behind it, and Chapter 4 gives them. The first removes the thing from which a mistake would be repaired. The second leaves a decision about when a mistake is affordable to a person who knows what else is happening. The third removes the means by which the other rules are checked, and the fourth belongs to management and not to operations (AI Boss concluded that AI may direct work but may not, on its own, decide about people (301, Nordqvist, 2026)). A permission that a delegation profile does not name is undelegated, however much the agent's technical access would allow.

The autonomy budget is what makes the degrees a control and not a label. Each Level 3 class carries a budget of points for a period, 90 days by default. An error consumes points: one for a reversal, a failed independent verification or a refused attempt, and the whole budget for a customer-visible effect, so that one such incident returns the class to Level 2 until a named authority decides otherwise. The observer counts the errors and the agent does not. Raising a level is the decision of a named authority and lowering it is immediate.

The observer principle has three tests, developed in Chapter 17. The independence test asks whether the verification shares its failure modes with the action. The dependence test asks whether the observer depends on the system it observes and so goes silent when that system fails. The stop test asks whether the stop path works when the platform does not. If any of the three cannot be answered, the action is not delegated. In the two nights above, the regional authority passed the independence test by using a synthetic sign-in from outside the platform, and the insurance group failed it by letting the agent confirm its own restarts.

Resilience as a claim has six parts: a subject, a scenario, an objective, a measured result, a date and an expiry (Chapter 19). Its status is derived by rule into verified, expired, implemented but unverified, failed, asserted or untested, and only a verified claim may be called recoverable. Chapter 4 sets the principle that evidence expires by clock and by condition, and the register of Chapter 19 fixes the clocks, 180 days by default for restore and failover tests of Tier 1 services, inside the yearly floor that Article 11(6) of DORA sets for financial entities (2, European Union, 2022). Evidence expires by clock and by condition, because a change in a DNS time-to-live, a certificate chain or a model version can invalidate the test that depended on it.

Usage modes and degrees of delegation

Two vocabularies recur and are easy to confuse, and the book keeps them apart. The usage mode says how the AI is deployed and whose identity it uses; the series defines six in AI Governance and AI Platform and Security, Chapter 2 (296, Nordqvist, 2026) (297, Nordqvist, 2026). The degree of delegation says who decides each action. A Mode 5 agent may be held at Level 1 for failover and at Level 3 for restart, and a Mode 3 tool that drafts a change is at Level 1 because a person reviews and executes it.

Usage mode In operations Whose identity acts Typical degree
Mode 0 Ambient AI Anomaly detection and priority suggestions inside the observability, service-management and managed-service tools The provider's; the organisation sees the output and often not the rule Not set by the organisation, which is the blind spot of operations
Mode 1 Conversational assistants An approved enterprise assistant used for drafting and questions, kept from operational data above internal The person's Level 0 Advisory
Mode 2 Embedded workplace assistants An incident summariser or ticket assistant embedded in a tool The person's Level 0 to Level 1
Mode 3 Agentic work tools Engineers' tools that draft infrastructure code and runbooks The person's Level 1 Assisted, never applying change
Mode 4 Built AI applications The operations assistant, the scribe, the change reviewer, the capacity planner, built by or for the organisation The application's own, under the organisation's mandate Level 0 to Level 2
Mode 5 Autonomous production agents A remediation agent with write access to production The agent's own, with permissions of its own Level 2 to Level 3 per class

Modes 1 to 3 act with a person's identity, so the person's own access limits them and the person remains the actor. In Mode 5 the agent is a privileged machine insider, which is the series' conclusion about the usage mode and not the model as the source of risk (AI Red Team, Chapter 6). Every narrative chapter has a subsection that shows how its subject differs across the modes or the degrees, normally as a compact table.

Rules of the book

Six rules govern how the book writes, and a reader who knows them can read each claim for what it is.

Defensive only. Failures and threats are described by mechanism and outcome, at the level needed to design controls, runbooks, observers and tests. The book contains no exploit code, payloads, prompt-injection strings or step-by-step intrusion. Fault injection, game days and restore tests appear only as authorised exercises, scoped in writing, run against the organisation's own or contracted systems, with a stop path outside the system being stopped, and ending in an operational improvement.

Observable, expected, speculation. Every statement about the future of operations, of threats or of the technology carries one of the three labels of AI Governance, Chapter 22. The author's own projections are confined to Chapters 27 and 31 and labelled as such.

No anthropomorphism. An AI system observes, correlates, ranks, flags, drafts, recommends or executes a runbook. It does not notice, understand or judge. The word "decides" is used for a system only where a decision was formally delegated, and the record then says who delegated it, under which profile and at which level.

Evidence with an age. No chapter says that something is recoverable, covered or competent without saying what was tested, when and with what result. Every chapter that concerns O3 Change or O4 Restore says what can be undone and who can stop it.

Law as implication. A statement about law is attributed to the instrument and article, which were checked against the live text on EUR-Lex, and is framed as an organisational and architectural implication. Where national law differs, the example names the member state.

People described by what studies measured. On-call, monitoring and measurement of staff are discussed by what studies found, with the population and method. The book never gives instructions for covert monitoring of staff or for defeating the rights of employee representatives, and it never calls anyone lazy, stupid or replaceable.

Two organisations and the series

Two fictional organisations run through every chapter so that a concept can be seen at work in two settings. They are the same in the earlier volumes and acquire an operations profile here. Everything about them is invented, and a real incident or figure is always cited as real.

Nordvik Region is a regional public authority in a Nordic EU member state. Its IT and Digitalisation Unit has about 85 people, led by the Head of IT and Digitalisation, Henrik Dahl. It runs a sovereign regional cloud itself in two halls of its data centre, depends on one national shared-service provider (SamDrift) for DNS, identity federation, round-the-clock network monitoring and its disaster-recovery site, and has seven platform engineers who carry SRE practice. It has no autonomous production agent. Its Tier 1 services include the benefits-triage service, the citizen e-service portal, the case-management system and staff identity. A recorded failover test of the portal on 12 October 2027 measured 5 hours 20 minutes against an objective of 2 hours and failed, and no re-test had run when the book begins. The regional executive committee's question of September 2028, recorded as AIDR-0900, is what operations becomes when the platform team's tools and the providers' AI act on the estate, and what the Region can prove about recovery.

Hansa Mutual is a multinational mutual insurance group headquartered in Germany, with about 1,300 people in Group IT. It operates a hybrid estate across its Frankfurt data centre, two hyperscaler tenancies, a managed service provider that runs night operations for a legacy platform and a software-as-a-service observability vendor. A site reliability function of about 95 people under Tobias Richter keeps a 24-hour incident commander rota. It already runs a Mode 5 IT-operations agent with write access to production, and DORA applies to its EU entities. A restore test of the claims core database on 15 June 2027 measured 5 hours 40 minutes against 4 hours and failed. The executive board's risk committee asked in September 2028 how far that agent's autonomy may reach, recorded as AIDR-0950.

Both receive a version of the same question in the same month, both hold a recorded recovery test that failed on time, and both depend on a provider whose AI acts under a rule that the organisation did not set. They differ in size, in the law that binds them, in where the leverage lies (the contract and a few owned runbooks at Nordvik; the platform, policy as code and the agent's mandate at Hansa) and in how their staff are protected (a duty to negotiate and an agreement that metrics are never reported by name at Nordvik; co-determination and an operations annex to the group works agreement at Hansa). Chapter 29 follows named people at both through a year, and Chapter 30 draws conclusions for each.

The book is Book 10 of The Transformed Architecture, and the series builds strictly in publication order. This book refers only to Books 1 to 9, and each earlier volume contributes a conclusion that Chapter 4 and the chapters after it take as given.

Earlier volume What it settled What this book does with it
Architecture as Code (295, Nordqvist, 2025) Architecture, policy and operations as code; delivery pipelines; observability and testing as code Takes operations as the subject and applies "as code" to runbooks, SLOs, mandates and restore tests
AI Governance (296, Nordqvist, 2026) Decision forums, evidence, lifecycle, the usage modes and the three outlook labels Reuses decision rights and labels; does not repeat governance
AI Platform and Security (297, Nordqvist, 2026) Building, containing and running the AI platform; the control plane as Tier 0 Operates everything, with AI as operator and as operated
AI Red Team (298, Nordqvist, 2026) The autonomy levels; Recover with AI; security chaos engineering Takes recovery and chaos engineering as inputs and extends them beyond security
AI Threat (299, Nordqvist, 2026) The evidence ladder; agent behaviour in the wild Limits how far an agent's own report of its work is trusted
The Transformed Security Architect (300, Nordqvist, 2026) The four shifts; the conductor; verifying AI proposals Applies the same method to the operator's agent team
AI Boss (301, Nordqvist, 2026) Algorithmic management; surveillance at work; real oversight Applies to on-call, metrics about people and monitoring of operators
AI Blue (302, Nordqvist, 2026) The five blue team functions; independence in blue verification Security operations stays there; this book meets it at incident roles, shared telemetry and joint exercises
AI Purple (304, Nordqvist, 2026) The purple loop; the independence principle; coverage as a claim The observer principle and resilience as a claim are their counterparts in operations

How to read this book

The book has seven parts and appendices. Part I, The Operations in Question (Chapters 1 to 4), states the question, gives the history and the pressures, and defines the loop. Part II, The Craft (Chapters 5 to 12), treats one function or more per chapter: observation with and without AI, diagnosis, change and safe change, restoration, capacity and cost, and problem management and learning. Part III, Operating AI Systems (Chapters 13 to 15), treats what it means to run AI services: model updates, drift and provider change, incidents involving AI and their reporting, and the economics of tokens, accelerators and latency. Part IV, The Operator's Own AI (Chapters 16 to 18), treats the agent team, the observer principle and the defence of the operator's AI as a Tier 0 asset. Part V, Operations in the Organisation (Chapters 19 to 24), treats resilience as a claim, measurement, operating models, decision rights, regulation and the boundaries with providers. Part VI, People and Career (Chapters 25 to 27), treats on-call and wellbeing, competence and the craft, and the future of operations. Part VII, Experience and Conclusions (Chapters 28 to 31), reads ten public cases and eight anti-patterns, follows the two organisations through a year, draws conclusions for each and judges the thesis. The appendices hold the glossary, code examples, templates and tools, the references and a note on the author.

Four chapters stage a debate in four steps, the case for concern, the case for calm, where the positions meet and what can be done, before a verdict: Chapter 10 on whether AI should remediate production on its own, Chapter 17 on the observer principle, Chapter 26 on whether automation deskills operators, and Chapter 27 on whether anyone will be on call in 2036. Parts II and V carry the book's weight, and Chapters 4, 10, 16, 17 and 19 are the load-bearing chapters. A reader with one hour reads Chapters 1, 4, 10, 17, 19 and 31.

The paths below suit the roles that most often read a book of this kind. They are suggestions and each includes Chapter 4, which defines the terms.

  • The CIO or head of operations reads Chapters 3 and 4 for the pressures and the frame, Chapters 20 to 23 for measurement, operating models, decision rights and regulation, Chapter 15 for the cost of running AI, and Chapters 30 and 31 for the conclusions and the decisions that belong to the board. The question to carry is who is accountable for each Tier 1 service and for each agent that acts on it.
  • The SRE or platform lead reads Chapters 5 to 10 for the craft, Chapters 16 to 19 for the agent team, the observer principle, the defence of the agents and resilience as a claim, and Chapter 28 for the anti-patterns. The question to carry is which runbook to write as a manifest first.
  • The incident commander reads Chapters 7 and 10 for diagnosis and restoration, Chapter 14 for incidents involving AI and the reporting clocks, Chapter 17 for the stop path, Chapter 22 for decision rights and Chapter 25 for the load on the person who commands. The question to carry is what may be stopped without approval, by whom and how.
  • The resilience officer reads Chapters 17 and 19 for independence and evidence, Chapter 23 for the regulatory mapping, Chapter 24 for providers and exit, and Chapter 28 for how claims fail at a scope they never named. The question to carry is which recoverability claim in the register is the oldest.
  • The service-desk lead reads Chapter 6 for alert noise, Chapters 7 and 12 for the assistant, the knowledge base and learning, Chapter 20 for metrics, and Chapters 25 and 26 for the people and their craft. The question to carry is which assistant drafts a message that a person must send.
  • The works council, union or data protection officer reads Chapter 5 for personal data in telemetry, Chapter 20 for metrics about people, Chapter 22 for decision rights, Chapter 23 for the rules on staff, working time and co-determination, and Chapters 25 and 26 for on-call and competence. The question to carry is which measure or tool needs agreement before it is switched on.
  • The public-sector leader reads Chapter 3 for dependency, Chapter 21 for operating models including shared and sovereign operators, Chapters 23 and 24 for regulation and exit, and Chapters 29 and 30 for a public authority's year and conclusions. The question to carry is what the authority could show a supervisor, a court or a citizen about a recovery.

Chapters 2, 3 and 31 suit every reader.

Practical guide: inventorying where AI already takes part in operating a service

Purpose. Most organisations cannot list the places where AI already takes part in operating a service, because much of it arrives inside a vendor's tool and was never procured as AI. The inventory is a one-page record per Tier 1 service, and it is the precondition for every later chapter.

Roles. The service owner holds the inventory. The platform or SRE lead supplies the technical facts. The procurement or vendor manager supplies what the contract says. The head of operations reviews it, the data protection officer reviews the data it touches, and the employee representatives are told what it records about staff.

Steps.

  1. Pick one Tier 1 service and list the tools in its operating chain: observability, alert routing, service management, change pipeline, runbook automation, capacity and cost tools, the service desk and any managed provider that watches or acts on it.
  2. For each tool, find whether it contains AI. Ask the vendor in writing: which features use machine learning or a language model, which are switched on by default, what data they read and where the model runs. Record Mode 0 features separately, because the organisation did not choose them.
  3. For each use, record the usage mode, whose identity acts and the highest action class it can perform, using the eleven classes of Chapter 4. A feature that can silence, group or reprioritise alerts is a reconfigure on the observer and is recorded as such.
  4. Record, for each action class, the degree of delegation in force. Where nobody has set one, write "unset" and not a level.
  5. Record who can stop the use, how, and whether the stop has been drilled, with the date and the result. Write "not tested" where it has not been.
  6. Record whether the provider can change the model or the rule without notice, and where the notice would arrive.
  7. Review the record with the service owner, the data protection officer and the employee representatives, and file it in version control beside the service record.

Default review interval. Quarterly, and after any change of tool, model or provider notice. Adapt the interval to the contract and to the works agreement.

Definition of done. The record lists every tool in the chain, every AI use with its mode and highest action class, an owner and a stop for each, and an explicit entry of "unset" or "not tested" wherever the answer is missing. A record with no blanks has probably been written from the vendor's brochure and not from the estate.

Worked example: an operations mandate summary for one service

A one-page summary of who and what may act on one service is the smallest artefact that makes the thesis concrete. The example is illustrative and fictional. It summarises, for Nordvik Region's citizen e-service portal (SVC-NR-002, Tier 1), the mandate manifest MND-NR-OPS-003 that Chapter 16 sets out in full, and it adds the operations assistant and the scribe of the Region's small agent team. It states the function, the action class, the degree of delegation and who can stop it, and it records the state of the recovery claim on the date of the summary, which is the date on which the runbook runner's mandate takes effect.

operations_mandate_summary:
  service: {id: SVC-NR-002, name: Citizen e-service portal, tier: 1, slo: SLO-NR-002}
  objectives: {availability: "99.9 % per month", rto: PT2H, rpo: PT5M}
  summary_date: 2028-11-14
  decision_records: [AIDR-0900, AIDR-0901, AIDR-0916]
  accountable: {service_owner: "Henrik Dahl", platform_lead: "Maja Lindqvist"}
  agents:
    - {id: NR-OPS-001, role: triager, mode: "Mode 4", function: O2 Diagnose,
       max_level: "Level 0 Advisory", actions: [read, annotate]}
    - {id: NR-OPS-002, role: scribe, mode: "Mode 4", function: "O2 Diagnose, O5 Sustain",
       max_level: "Level 1 Assisted", actions: [read, annotate]}
    - id: NR-OPS-003
      role: runbook runner
      mode: "Mode 4"
      mandate: MND-NR-OPS-003
      function: O4 Restore
      by_class:
        scale: "Level 2 Supervised"
        restart: "Level 2 Supervised"
        reconfigure: "Level 2 Supervised (certificate renewal only)"
        roll_back: "Level 1 Assisted"
        fail_over: "Level 1 Assisted"
        deploy: undelegated
        delete: undelegated
        restore_overwrite: undelegated
  level_4_in_use: [read, annotate]
  never_at_any_level_without_a_named_person: [delete, restore_overwrite, alert_or_monitor_change]
  verification: {probe: OBS-NR-0001, independent_of_agent: true}
  stop:
    holders: [duty manager, platform lead, service-desk lead]
    path: out-of-band revocation at the token service
    last_drill: 2028-11-07
  recovery_claim:
    failover_to_recovery_site: {status: failed, test: RST-NR-2027-002, date: 2027-10-12,
                                measured: PT5H20M, objective: PT2H, retest: not_run}
  consequence: "No level above Level 1 for fail over until a re-test passes"
  review_by: 2029-02-14

Three things in the summary are the book in miniature. No agent holds a degree of delegation above Level 2 for any class that changes production, because the Region has no autonomous production agent and holds that rule. The recovery claim is written as it stands, failed and without a re-test, and it limits what the agent may be given for fail over, a rule that Chapter 19 states for the register in general. And the stop has holders, a path outside the platform and a date, so that "who can stop it" has an answer that can be checked. A reader who can write this page for one of their own services has already done most of what Chapters 4 and 16 ask.

Across the usage modes

The mode sets the identity and the exposure, and the degree of delegation sets who decides; the table in the section on usage modes gives the book's default for each mode in operations. Modes 1 to 3 give an assistant a person's access, so that the person remains the actor and the risk is a draft accepted unchecked (Chapter 7). In Mode 0 a provider's AI acts under a rule the organisation did not set, and in Mode 5 an agent acts under a mandate that the organisation wrote and enforces outside the agent.

Nordvik Region and Hansa Mutual

Nordvik Region's regional executive committee asks what operations becomes and what the Region can prove about recovery (AIDR-0900, dated 2028-09-12, first report due 2029-03-31). The Region's answer begins with an inventory of the kind in the practical guide, because the places where AI already acts on its estate include the ambient classification in its service-management tool, the hosting provider's image updates and the national provider's network monitoring, none of which it chose as AI. Its operations assistant (AIDR-0901) starts at Level 0 Advisory, and the book follows the Region from there with a short, reviewable set of mandates.

Hansa Mutual's executive board risk committee asks how far the IT-operations agent's autonomy may reach (AIDR-0950, dated 2028-09-19, first report due 2029-03-31). Its answer begins with a count of what the agent already does, class by class, and with what verified claim stands behind each class, because Level 3 for restart, certificate renewal and scaling already exists and the question is whether it may extend to rollback and failover. The two questions are the same question in different forms: what may a machine do on its own in operations, who set the limit, and what can the organisation show afterwards.

Summary

This chapter introduced a book about IT operations when AI takes part in it, and it concerned all five functions of the operations loop: O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain. AI is observable in observability, incident assistance and AI-authored change; delegated remediation in routine classes is expected; unattended operation of whole estates is speculation. Operations is a book of its own because it holds some of the broadest credentials in the estate, because it is where loops are closed without a person in them, and because European regulation places it among the duties of the management body.

The thesis has five parts: operations is transformed from the queue to the control loop; autonomy is matched to reversibility and blast radius and has a budget; the operator's AI is part of the estate it operates; a loop closed by machines alone can hide its own failure, which the observer principle answers; and resilience is a claim that needs evidence, as does competence. These are the book's own conclusions, tested in Parts II to V and judged in Chapters 27 and 31, and the chapter named what would show them wrong. The vocabulary is fixed: five functions, five degrees of delegation with four prohibitions on Level 4, an autonomy budget consumed by errors, three tests of the observer principle and a recoverability claim with a date and a result.

Two fictional organisations, Nordvik Region and Hansa Mutual, put the same question in the same month and show different answers. A practical guide offered a first step that needs no AI, an inventory of where AI already takes part in operating one Tier 1 service, and a worked example showed a one-page mandate summary that states for each agent the function, the action class, the degree and who can stop it. The reader can do the first step this week, and the second as soon as the first is done. Chapter 2 turns to how operations organised itself before AI, because every claim about what AI changes is a claim about a difference.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
  2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
  3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
  4. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union. (6, European Union, 2016)
  5. European Parliament and Council of the European Union. Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data (Data Act). (16, European Union, 2023)
  6. Nordqvist, G. (2025). Architecture as Code. The Transformed Architecture, Book 1. (295, Nordqvist, 2025)
  7. Nordqvist, G. (2026). AI Governance. The Transformed Architecture, Book 2. (296, Nordqvist, 2026)
  8. Nordqvist, G. (2026). AI Platform and Security. The Transformed Architecture, Book 3. (297, Nordqvist, 2026)
  9. Nordqvist, G. (2026). AI Red Team. The Transformed Architecture, Book 4. (298, Nordqvist, 2026)
  10. Nordqvist, G. (2026). AI Threat. The Transformed Architecture, Book 5. (299, Nordqvist, 2026)
  11. Nordqvist, G. (2026). The Transformed Security Architect. The Transformed Architecture, Book 6. (300, Nordqvist, 2026)
  12. Nordqvist, G. (2026). AI Boss. The Transformed Architecture, Book 7. (301, Nordqvist, 2026)
  13. Nordqvist, G. (2026). AI Blue. The Transformed Architecture, Book 8. (302, Nordqvist, 2026)
  14. Nordqvist, G. (2026). AI Purple. The Transformed Architecture, Book 9. (304, Nordqvist, 2026)
  15. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. (217, Bainbridge, 1983)
  16. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3), 381-410. (218, Parasuraman & Manzey, 2010)
  17. Beyer, B., Jones, C., Petoff, J. & Murphy, N. R. (eds.) (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media. (112, Beyer et al., 2016)
  18. Alvidrez, M. (2017). Embracing Risk. In: Site Reliability Engineering. O'Reilly Media. (258, Alvidrez, 2017)
  19. PeopleCert (2023). ITIL 4 Management Practices 2023. (121, PeopleCert, 2023)
  20. ISO/IEC (2018). ISO/IEC 20000-1:2018 Information technology: Service management, Part 1. (48, ISO/IEC, 2018)
  21. CNCF TAG App Delivery, Platforms Working Group. CNCF Platforms White Paper. (273, CNCF TAG App Delivery & Platforms Working Group, n.d.)
  22. Harvey, N. & DeBellis, D. (2024). Highlights from the 10th DORA report. Google Cloud Blog. (251, Harvey & DeBellis, 2024)