The Pressure on Operations: Complexity, Dependency, Cost and Machine-Speed Change

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.

Figure 3.1: Six pressures on the operations loop. The table below gives the function on which each one lands.

The table gives the function on which each pressure lands.

Pressure	Lands on	How
Complexity and dependency	O2 Diagnose; O4 Restore	More paths to trace; shared fate
Change volume	O3 Change	Review load
Telemetry volume and cost	O1 Observe	The cost of seeing
People and skills	O2 Diagnose; O5 Sustain	Attention; on-call burden
Compute and energy	O5 Sustain	Capacity and energy
Duty and adversaries	O4 Restore; O3 Change	Reporting clocks; shorter time to exploit

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).

Reading the evidence: three grades

A statement that operations is under pressure can mean three different things, and the chapter keeps them apart. The grades are a simplification of the evidence ladder of AI Threat, Chapter 4 (299, Nordqvist, 2026), fitted to operations.

Grade	What it rests on	Example in this chapter	How far it carries
Measured	Telemetry or records from the issuer: a post-incident report, a published dataset with a stated method, the text of an instrument	The mechanism and timeline of the AWS DynamoDB disruption of October 2025	Applies to the case or the sample; says nothing about other estates without an argument
Surveyed	Self-reported answers from a stated group of respondents, often self-selected and often run by a vendor	The Grafana Labs observability survey; the DevOps Research and Assessment (DORA) programme's survey of professionals	Describes what respondents report; sensitive to who answered and how the question was framed
Argued	Reasoning from mechanism, with no measurement behind the specific claim	The book's own claim that review capacity does not scale with AI-authored change	Is only as strong as its premises, which the chapter states

Two cautions follow. A measured incident report is a measurement of one failure, chosen by its visibility; it is not a sample of failures. And "DORA" in this book means Regulation (EU) 2022/2554, the Digital Operational Resilience Act (2, European Union, 2022); the research programme that publishes the annual State of DevOps reports is written "the DevOps Research and Assessment (DORA) programme" in this chapter and "the four key metrics" from Chapter 20 onwards.

Complexity and dependency

What outage reports show

The strongest measured evidence for the pressure of dependency comes from the issuers' own reports on large provider failures. Three from 2025 are enough to show a pattern, and each is read here for its mechanism, not its drama.

Amazon Web Services reported that on 19 and 20 October 2025 the regional endpoint of its DynamoDB database service in the US-EAST-1 region stopped resolving in DNS. The cause was a latent race condition in the DNS management system: a delayed component applied an older plan over a newer one, and a cleanup process then deleted the older plan, which removed every address for the endpoint. The DNS impact ran from 23:48 Pacific time on 19 October to 02:40 on 20 October, and the overall event ended at 14:20 on 20 October. Services that depend on DynamoDB, among them instance launches, load balancers, serverless functions, container services and sign-in to the console, were affected (75, AWS, 2025). A database endpoint was the root, and the visible damage was in services that most customers do not think of as depending on it.

Google Cloud's status record for 12 June 2025 describes a different mechanism with a similar shape. A quota-policy check had been added to a central service, Service Control, on 29 May without error handling and without a feature flag. On 12 June a policy change containing unintended blank fields replicated globally within seconds; regional instances read the blank fields and crashed in a loop in every region. The record lists roughly 90 affected products, and notes that in one region restarting tasks overloaded the underlying database because the service lacked randomised exponential back-off, which prolonged recovery there (76, Google Cloud, 2025). The status page and the incident summary on the same page give different durations, so this chapter uses the mechanism and not a figure.

Cloudflare reported that on 18 November 2025 a change to database access controls caused a query to return duplicate rows, which roughly doubled the size of a generated bot-management feature file; the file exceeded a limit in the proxy software, which failed, and the file was propagated across the network every five minutes. Core traffic was largely restored about three hours and ten minutes after the start at 11:20 UTC, and Cloudflare states that the outage was not caused by a cyber attack. Its first suspicion had been a distributed denial-of-service attack, which the report records as wrong (77, Prince, 2025).

Three things recur. The first fault was small, a record, a policy row or a permission. It propagated through a mechanism built to make operation efficient: global replication, a regional endpoint that many services share, an automated distribution of a configuration file. And the people diagnosing it began with a hypothesis that did not fit, in one case an attack, because the visible symptom looked like the symptom of something more familiar. None of this shows that providers are unreliable; the same reports show fast recovery of an enormously complex system. It shows that the estates that customers build on top of such providers inherit failure modes they cannot see and cannot test.

Third parties in the aggregate

Uptime Institute's annual outage analysis for 2025 adds a measure at the scale of the industry. Its press release reports that outages from IT and networking causes rose in 2024 and made up 23 per cent of impactful outages, which Uptime links to growing complexity and possible change-management problems and misconfigurations; that nearly 40 per cent of organisations had a major outage caused by human error in the past three years, of which 85 per cent stem from staff not following procedures or from flaws in the procedures; and that, over nine years of tracking public reports, third-party IT and data-centre service providers accounted for about two-thirds of reported outages (74, Uptime Institute, 2025). The last figure carries a condition that matters: it counts outages that were reported publicly, which favours the outages of large providers because they are the ones that reach the news. The report also says that outage frequency and reported severity have fallen for four consecutive years. Both statements are true at once: individual failures have become rarer in the data, and the share that originates in someone else's system is high.

Concentration as a regulatory fact

Concentration is not only an engineering observation. On 18 November 2025 the three European Supervisory Authorities published the list of critical ICT third-party providers designated under DORA. The announcement states that the designation followed a data collection from the registers of information that financial entities maintain, and that designated providers come under direct supervisory oversight of their risk management and governance (7, EBA, 2025). The register is itself a legal duty: DORA Article 28(3) requires a financial entity to maintain a register of information on all contractual arrangements for ICT services provided by third parties, distinguishing those that support critical or important functions (2, European Union, 2022). That regime is observable and in force. It means that for a financial entity such as Hansa Mutual the dependency map of this chapter is not a diagram that an architect may or may not draw; the register is the legal form of it.

Hidden and shared dependencies

The dependencies that hurt most are the ones that nobody listed. A service catalogue names the applications; the paths between them run through identity, DNS, certificates, time synchronisation, the observability pipeline and the network, and these are shared. Chapter 4 treats the control plane and the operator's own tools as Tier 0 for this reason. Both example organisations have a baseline of such failures. Nordvik Region's identity provider stopped issuing sign-ins for 95 minutes when its signing certificate expired in March 2026 (INC-NR-2026-0071), because no certificate inventory existed, and a DNS fault at its national shared-service provider SamDrift made the e-services unreachable from outside for 70 minutes in November 2027 (INC-NR-2027-0298). Hansa Mutual's observability vendor failed to ingest for 3 hours 10 minutes in May 2027, which left the group blind on 14 services with the vendor's status page as the only signal (INC-HM-2027-0572). These records are fictional and illustrative; they are used here for the pattern they share with the real cases above: a shared, small, rarely examined component sits under many services and its failure is detected late, because the thing that would detect it depends on it.

Change volume

What AI-authored change does to review

Operations absorbs change. Every release, configuration push, infrastructure modification and permission change eventually becomes an event that someone must be able to explain when it goes wrong. The volume of change is therefore a pressure on O3 Change and, through the incidents that change causes, on O2 and O4.

The best published evidence on how AI affects the delivery of change comes from the DevOps Research and Assessment (DORA) programme, whose annual surveys are announced by its researchers on the Google Cloud blog. The 2024 report announcement states that more than 75 per cent of respondents said that they rely on AI for at least one daily professional responsibility, and that as AI adoption increased it was accompanied by an estimated decrease in delivery throughput of 1.5 per cent and an estimated reduction in delivery stability of 7.2 per cent (251, Harvey & DeBellis, 2024). The 2025 announcement, based on nearly 5,000 technology professionals and more than 100 hours of qualitative data, reports a reversal for throughput and a persistence for stability: AI adoption now has a positive relationship with software delivery throughput and product performance, and it continues to have a negative relationship with software delivery stability. Its stated interpretation is that AI accelerates software development, but that the acceleration can expose weaknesses downstream, and that without robust control systems, such as strong automated testing, mature version control and fast feedback loops, an increase in change volume leads to instability (117, Harvey & DeBellis, 2025).

This is surveyed evidence, and three limits apply. The respondents are self-selected technology professionals and their answers about throughput and stability are their own reports. The relationships are associations estimated by the researchers' models, not the result of an experiment in which some teams were given AI and others were not. And the programme measures software delivery, which is a subset of operations change; infrastructure, network and identity changes, which have the largest blast radius, are not separated in what the announcements report. What the two reports establish is a direction that has not been contradicted: change volume rises with AI use, and stability does not rise with it unless the surrounding controls are strong.

The review-capacity argument

The book's own conclusion, which is argued and not measured, is the following. Review of change by a person scales with the number of people who can read a change competently and with the time they have. The authoring of change by an agent scales with compute. When authoring becomes cheap, the number of proposed changes grows, the number of reviewers does not, and the gap is closed in one of three ways: reviews become shallower, the queue grows, or a machine reviews the machine's change. The first hides risk, the second delays the work that the agents were introduced to accelerate, and the third is acceptable only if the reviewing machine is independent of the authoring one, which is the observer principle of Chapter 4. AI Blue, Chapter 6, found the same shape on the defending side: a loop with no cap on open drafts is another queue, with 131 drafted detections in a half-year, 52 merged and 79 open before a cap in the illustrative Hansa year (F94). The Transformed Security Architect reached it for architecture review, where approval time fell while volume tripled (300, Nordqvist, 2026). Chapter 8 develops the answer for operations: provenance of every change, policy as code that checks what a person cannot read, and a limit on the number of open proposals per reviewer.

The cases of the previous section show why the stakes are not abstract. Two of the three provider incidents began with a change that passed whatever checks existed: a policy row with blank fields in the Google case, a database permission change in the Cloudflare case. Uptime's own remark that its rise in IT and networking outages may reflect change-management problems and misconfigurations points the same way, although Uptime states it as a possible link and not as a finding (74, Uptime Institute, 2025). The outlook is labelled. It is observable that AI use in software delivery is widespread (the 2024 and 2025 surveys). It is expected, on the stated trend, that the volume of machine-authored infrastructure and configuration change will keep rising in organisations that adopt Mode 3 agentic work tools. It is expected that sustained review overload follows where review capacity is not redesigned. Whether stability recovers as practices mature is speculation; the 2025 report's own framing, that AI amplifies what is already present in an organisation, is a reason for neither optimism nor alarm.

Telemetry volume and cost

Operations needs to see, and seeing has become more expensive than it was. A service that was a monolith on a few servers is now tens or hundreds of services, each emitting metrics, logs and traces through standard instrumentation such as OpenTelemetry. The cost of O1 Observe is the sum of generating, shipping, storing, indexing and querying that signal, and in a managed service it is charged by volume.

The Grafana Labs Observability Survey 2025 is a useful if partial view. It collected 1,255 responses between 18 September 2024 and 2 January 2025 through the vendor's community, events and third-party conferences. Of respondents, 74 per cent said cost is a top priority when selecting tools; 39 per cent named the complexity and overhead of setting up and maintaining tooling as a challenge, 38 per cent named the signal-to-noise problem, 37 per cent said observability costs too much and 29 per cent said costs are too difficult to predict and budget for (119, Grafana Labs, 2025). It was run by a vendor and recruited through the vendor's own channels and events, so the sample is self-selected and not random. The figures show what a self-selected group of observability practitioners says worries it. They do not show the state of the industry, and they are not a measure of cost.

Two further pressures are the book's own argument, stated with their premises. First, the person is the constraint: if telemetry volume grows with the number of services and the number of people who can read it does not, the share of signal that anyone reads falls, and O1 Observe becomes a store, not a sense. That is the argument for correlation and summarisation by AI in Chapter 6, and it carries the risk that the summariser suppresses the one alert that matters. Second, telemetry is data about people and about the organisation. Application logs routinely contain identifiers, addresses and fragments of casework, and the Region's logs hold special-category data from social-services systems. Retention is therefore bounded by data protection: the GDPR's storage-limitation and security principles apply to operational telemetry as to any personal data (Regulation (EU) 2016/679, Articles 5 and 32) (6, European Union, 2016). Observability cost has a floor set by what must be kept and a ceiling set by what may be kept, and the interval between is where operations decides what to see. Chapter 5 treats the decision.

People

Toil, on-call and the limits of attention

The Google SRE book, written by practitioners and published in 2016, defines toil as work tied to running a production service that is manual, repetitive, automatable, tactical, without enduring value and growing linearly with the service, and states an advertised goal of keeping it below 50 per cent of each engineer's time. Its quarterly surveys of Google's own engineers put the average at about a third, with individual answers from 0 to 80 per cent (253, Rau, 2017). The chapter on on-call from the same book sets a design limit that no more than 25 per cent of an engineer's time be spent on call, and no more than two incidents per 12-hour shift, and warns that stress can impair cognitive functions and that noisy alerts cause serious alerts to be treated with less attention than necessary (118, Spadaccini, 2016). These are the rules of one organisation, offered as practice; they are not findings from a study of operators in general. Their value for this chapter is as a stated standard against which an organisation can compare its own rota, and as evidence that the people who developed site reliability engineering regarded attention as a budget that can be overspent.

What the research literature has measured on operators is thin. The studies of alarm load and burnout that the bibliography holds concern security operations (214, Sundaramurthy et al., 2015); (215, Tariq et al., 2025), and AI Blue, Chapter 21, concluded that the research on alarm fatigue and burnout is small and mostly qualitative and that whether AI relieves or intensifies the load depends on team design (F110) (302, Nordqvist, 2026). The same caution applies here. The chapter does not claim a measured rate of burnout among operators; Chapter 25 returns to what studies of operators and on-call can support.

Skills

The skills pressure is real in the surveys, with limits on what they cover. ISC2's 2025 Cybersecurity Workforce Study, a survey of 16,029 practitioners and decision-makers, reports that 95 per cent have at least one skill need and that 88 per cent have experienced at least one significant consequence of a skills shortage (216, ISC2, 2025). It surveys the cybersecurity workforce, so it speaks about the neighbouring discipline and not about operations. The public sector shows the pressure sharply in the profile of Nordvik Region: seven platform engineers on a weekly rota, two vacant posts in an IT unit of about 85, and procurement lead times of 9 to 14 months. Chapter 26 treats competence in depth.

The ironies

Two older findings explain why more automation does not relieve the people. Bainbridge's analysis of industrial automation argued that automation takes over the tasks that can be specified and leaves the operator the tasks that cannot, including the monitoring of a system that is meant to need no monitoring, and that the skills required for the residual tasks decay as the automated tasks cease to be practised (217, Bainbridge, 1983). Parasuraman and Manzey's review of research on complacency and bias in the human use of automation found that both occur in novices and in experts (218, Parasuraman & Manzey, 2010). The book's conclusion, which is argued and which Chapters 4, 17 and 26 take further, is that AI in operations does not remove the load on people. It changes the load from handling alerts to verifying machine proposals and handling the rare failure that the machine did not handle, and the second is harder.

Compute, energy and cost

AI services are operated services. They need accelerators, which are scarce and reserved in advance, and they draw power. The International Energy Agency's report on energy and AI states that data centres used around 415 terawatt-hours (TWh) of electricity in 2024, about 1.5 per cent of the world's electricity consumption, of which Europe accounted for 15 per cent after the United States at 45 per cent and China at 25 per cent. Its base case projects that data-centre consumption more than doubles to around 945 TWh by 2030, with AI as the most important driver (120, IEA, 2025). The 2024 figure is measured; the 2030 figure is a projection, expected on the agency's stated base case and therefore sensitive to its assumptions, and the agency itself says that uncertainties widen after 2030.

For an operator the relevant pressure is local and financial before it is global. The two organisations show it in their budgets, which are illustrative. Nordvik's reserved accelerators cost about EUR 1.6 million a year, against observability and service-management tooling of about EUR 0.9 million; Hansa's AI inference and platform budget is about EUR 9 million, with an agent whose spending is capped at EUR 6,000 a month. The point is not the size but the shape: inference is a variable cost that scales with use and can scale with an agent's mistakes, so a loop that retries without a bound is a cost incident as well as an availability one. Chapter 11 treats capacity, cost and energy reporting, and Chapter 15 the economics of running AI, including latency and quality objectives and fallbacks between models and providers.

Duty and adversaries

The clocks

The regulatory pressure on operations is in the first place a pressure of time and of accountability. The instruments the book returns to in Chapter 23 give the following, each quoted here from the live text on EUR-Lex.

• NIS 2 Article 23(4) requires an essential or important entity to submit an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report not later than one month after the notification (3, European Union, 2022).
• DORA Article 19(4) requires a financial entity to submit an initial notification, an intermediate report and a final report for a major ICT-related incident, within time limits laid down in the delegated acts that Article 20 provides for; the Article itself also allows the reporting to be outsourced while the entity remains fully responsible (2, European Union, 2022).
• The AI Act, Article 73(2), requires the provider of a high-risk AI system to report a serious incident not later than 15 days after the provider or deployer becomes aware of it, and Article 73(3) requires a report not later than two days for a widespread infringement or a serious incident of the kind defined in Article 3, point (49)(b) (1, European Union, 2024).
• GDPR Article 33(1) requires notification of a personal data breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of it (6, European Union, 2016).

An operations function that cannot say, within hours, what failed, which services and data were affected and whether the cause may be malicious cannot meet clocks of this kind. That is an architectural implication, not legal advice. Two further provisions bear on operations design. AI Act Article 26(6) requires a deployer of a high-risk AI system to keep the logs automatically generated by the system, to the extent they are under its control, for a period appropriate to the intended purpose and of at least six months, which makes log retention for those systems a requirement and not a cost choice (1, European Union, 2024). And the management body carries the accountability: NIS 2 Article 20(1) requires that the management bodies of essential and important entities approve the risk-management measures, oversee their implementation and can be held liable for infringements, and DORA Article 5(2) makes the management body bear the ultimate responsibility for managing ICT risk. NIS 2 Article 21(2) lists, among the minimum measures, incident handling, business continuity such as backup management and disaster recovery, supply chain security and policies to assess the effectiveness of the measures. Operations is where those measures run.

Adversaries at the same speed

The pressure of adversaries is expressed most directly in the time between disclosure of a vulnerability and its first exploitation. Mandiant analysed 138 vulnerabilities disclosed in 2023 and exploited in the wild and reported an average time to exploit of 5 days, against 32 days in 2021 and 2022 and 63 days in 2018 and 2019. The figure carries conditions that the authors stated: 15 data points were excluded as statistical outliers, without which the 2023 average is 47 days; first exploitation is often undisclosed, so the figures are conservative; and better detection may explain part of the trend (72, Charrier & Weiner, 2024). It is measured evidence of a trend over a stated sample, and it does not show that the interval keeps falling. Whether AI-enabled adversaries will shorten it further is expected by some agencies, among them the National Cyber Security Centre, which reports that AI is showing the ability to exploit technical debt at scale and at pace (68, NCSC, 2026), and is not settled by the data in this chapter. What the figure does establish for operations is a requirement that does not depend on the forecast: if the exploitation of an exposed flaw can precede a monthly patch cycle, patching, configuration change and containment have to run at a speed that the old rhythm of change windows and approvals did not need. AI Platform and Security, Chapter 18, drew the same consequence as patch velocity measured as a service level (F36), and AI Purple, Chapter 3, drew it for periodic testing (F117). Here it lands on O3 Change and O4 Restore: the control that makes fast change safe is not a faster approval but a smaller, more reversible change with an independent check.

What the pressures have in common

The six pressures look different, and they share a structure. Each raises the amount that operations must attend to (paths to trace, changes to review, signals to read, clocks to meet, costs to watch) while the number of people and the hours in a day stay fixed. AI is arriving in operations because it can attend at a scale that people cannot. That explains the speed of its adoption and sets the danger. An organisation that answers a pressure of attention with a machine that attends has solved the first problem and created a second: the machine's work must be verified, the machine must be contained, and the machine's failures are likely to be correlated with the failures of the systems it watches. The thesis of the book follows from that structure. Operations is transformed from the queue to the control loop; autonomy is matched to reversibility and carries a budget; the operator's AI is part of the estate it operates; what verifies an action must be independent of what performed it; and recoverability is a claim that needs evidence. Chapter 4 defines the loop, the budget and the observer principle precisely.

Worked example: a service record with its dependencies and blast radius

The record below is illustrative. It extends the service record SVC-HM-001 of Hansa Mutual's claims core system with the dependencies and blast radius that Chapter 4 will require of every Tier 1 service. It lives in version control beside the service's infrastructure code, so that a change to a dependency is a change to the record. Evidence ages are counted from the date of the map. The platform engineer who drew it takes the recovery evidence from the baseline records of the operations profile, and marks what was never re-tested.

# Illustrative. Fictional organisation and records.
service: SVC-HM-001
name: Claims core system
tier: 1
dora_critical_or_important_function: true
owner: head-of-claims-it
map:
  drawn: 2028-10-10
  next_review: 2029-04-10
  drawn_by: [platform-engineer-hamburg, sre-polish-service-centre]
objectives:
  availability: "99.95 % per month"
  rto: PT4H
  rpo: PT15M
blast_radius:
  markets: [DE, NL, SE, NO, UK, CH]
  processed_in: [DE, PL]
  degraded_mode: "manual routing of claims, 15 minutes to enter"
dependencies:
  - id: cloud-a-eu-region
    kind: hyperscaler
    role: primary hosting
    shared_with: [SVC-HM-002, SVC-HM-005, SVC-HM-007]
    own_monitoring: true
  - id: cloud-b-eu-region
    kind: hyperscaler
    role: disaster recovery
    evidence:
      test: RST-HM-2027-004
      date: 2027-06-15
      result: "failed on time: 5 h 40 min against 4 h; RPO 9 min against 15"
      age_months: 16
      retest: none
  - id: SVC-HM-006
    kind: internal-service
    role: group identity and access
    shared_with: all-tier-1
  - id: lumenscope
    kind: saas-observability
    role: metrics, logs, traces, anomaly detection
    register_of_information: HM-PROC-OBS-2026-01
    seen_failure: "INC-HM-2027-0572, 3 h 10 min without ingestion on 14 services"
    independent_probe: none
  - id: alster-managed-services
    kind: managed-service-provider
    role: night operations of the legacy policy platform, not of this service
    relevance: shares the batch scheduler used for settlement hand-offs
actors_on_this_service:
  - HM-OPS-001   # IT-operations agent, Level 3 Bounded for restart and scaling
  - SVC-HM-002   # claims-triage agent, acts within approval rules
unknowns:
  - "DNS and certificate dependencies not yet inventoried"
  - "time to switch off the claims-triage agent without stopping claims intake"

The two lines under unknowns are the useful ones. A map that lists only what is known reproduces the catalogue it was drawn to correct.

Practical guide: drawing a dependency-and-blast-radius map in an afternoon

Purpose. Produce, for one Tier 1 service, a record of what it depends on, what depends on it, what it would take down with it and what evidence exists that recovery works. Roles. The service owner decides the scope and signs the result; a platform engineer or site reliability engineer draws it; an engineer from identity or network contributes the shared services; the head of operational resilience (Hansa) or the IT management office (Nordvik) files it. Time. About four hours for one service, with the people in one room or on one call.

1. Pick the service and write its objective. Take the service record, the availability objective, the recovery time and the recovery point. If the objective is missing, record that as the first unknown.
2. List what the service calls. Use traces, the infrastructure code and the network flow data, not memory. Include identity, DNS, certificates, time, secrets, the observability pipeline, the deployment pipeline and every external endpoint. Default: if a component appears in the trace of 1 per cent or more of requests, it is listed.
3. List what calls the service. Include other services, batch jobs, agents and external parties. Mark every non-human caller that can change state.
4. Mark shared fate. For each dependency, list the other Tier 1 and Tier 2 services that use it. A dependency shared by three or more Tier 1 services is a candidate for Tier 0 treatment (Chapter 4).
5. Mark the provider. For each dependency, record who operates it, under which contract, whether it is on the register of information, and whether the provider uses AI that changes its behaviour without notice.
6. Attach the evidence of recovery. For each recoverability claim, record the restore or failover test, its date, the measured time and point against the objective, and its age. A claim without a test is written as untested.
7. Write the unknowns. Ask the team what it would not be able to say in the first hour of an outage. Record each answer as an unknown with an owner and a date.
8. Draw the blast radius. State which markets, user groups and services lose function if each dependency fails, and what the degraded mode is and how long it takes to enter.
9. Commit the record and set the review. Put it in version control, set a review date of six months at most, and re-draw it after any incident that revealed a dependency not on the map.

Definition of done. The record names every dependency of the service that appeared in traces, each with a provider and a contract; each recoverability claim carries a test, a date and a result or is marked untested; at least one unknown has an owner; and the service owner has signed it. Adapt the 1 per cent trace threshold to the traffic profile of the service, and adapt the review interval to the contract and the organisation's risk appetite.

Across the usage modes

AI changes the pressure in two ways: it adds to it, where assistants author change and agents act on the estate, and it relieves it, where assistants correlate, summarise and draft. Mode 0 matters most to the dependency map, because ambient AI in a provider's monitoring or in a service-management tool is a dependency that nobody listed.

Mode	Where it adds pressure	Where it relieves pressure	What the map should record
Mode 0 Ambient AI	Provider-side models change behaviour without notice; the organisation cannot test them	Default anomaly detection and ticket classification reduce manual triage	Each provider feature that embeds AI, and the date of the last notice of change
Mode 1 Conversational assistants	Staff paste operational data into tools; log content becomes a data-protection question	Faster search of documentation and drafting of status text	The data classes permitted in the approved tool
Mode 2 Embedded workplace assistants	Incident summaries that look authoritative and are not checked	Summaries of long incident threads	Which summaries enter the incident record, and who verifies them
Mode 3 Agentic work tools	Machine-authored infrastructure and runbook change raises review load	Drafts of runbooks and infrastructure code for review	The identity, permissions and review rule for every agent that drafts change
Mode 4 Built AI applications	Operated AI services add accelerators, energy and quality objectives to the estate	Retrieval assistants for incidents and runbooks	The AI services as services in the catalogue with objectives
Mode 5 Autonomous production agents	Agents with write access are administrators; their errors and retries add change and cost	Execution of catalogued runbooks at machine speed	The agent as an actor on each service, its level, its mandate and its stop path

The degrees of delegation are defined in Chapter 4. The pressure argues for Level 2 Supervised or Level 3 Bounded for reversible, catalogued actions and against Level 4 Autonomous where an action is irreversible on production data, falls outside an authorised change window or freeze on a critical function, or disables the observation or the stop path itself.

Nordvik Region and Hansa Mutual

Both organisations receive the pressures, in different proportions. Nordvik Region depends on one sovereign regional cloud that it runs itself in two halls of its regional data centre and on one national shared-service provider, SamDrift, which supplies the identity federation, external DNS, out-of-hours network monitoring and the disaster-recovery site. Its concentration is therefore of a kind that the Region can name on one line, and that is also its risk: a DNS fault at SamDrift in November 2027 made the e-services unreachable for 70 minutes, and the Region's own monitoring saw it 22 minutes after the provider's status page. Its failover test of October 2027 (RST-NR-2027-002) measured 5 hours 20 minutes against a 2-hour objective and failed, so the Region cannot at the date of the map say that the portal is recoverable within the objective. It has not yet re-tested. DORA does not apply to the Region, and NIS 2 applies as the national transposition determines; the Region plans as if its Tier 1 services are in scope. Its binding constraints are seven platform engineers on a weekly rota, two vacancies and long procurement; its leverage is the contract, which the baseline incident history shows lacking a release-notice period for the benefits-triage supplier and for the hosting provider's container image updates.

Hansa Mutual spreads over its own data centre in Frankfurt, two hyperscaler tenancies, a managed service provider that runs the night operations of its legacy platform and a SaaS observability vendor, and settles claims through external payment networks. Its pressures are concentration and the seams between providers. DORA applies directly: the register of information covers every provider on the map, and the failed restore test of the claims core database in Cloud B (RST-HM-2027-004, 5 hours 40 minutes against 4 hours) has no re-test, so "recoverable" cannot be written for it. Its IT-operations agent, with write access to production, is both a relief to the pressure of attention and a new dependency on the map. The difference in one sentence: Nordvik must ask whether it can prove recovery with a team that cannot grow, and Hansa whether the autonomy it already grants can be extended without adding a failure mode it cannot see.

Observable, expected, speculation

Label	Statement	Basis
Observable	Large provider failures propagate to dependent services that customers did not know they depended on	The AWS, Google Cloud and Cloudflare reports of 2025
Observable	AI use in software delivery is widespread and is associated with lower delivery stability unless controls are strong	The 2024 and 2025 surveys of the DevOps Research and Assessment (DORA) programme (surveyed evidence)
Observable	Critical ICT third-party providers are now designated and supervised under DORA	The ESAs' announcement of 18 November 2025
Expected	Machine-authored change volume keeps rising, and review overload follows where review capacity is not redesigned	The stated trend of adoption and the argument of this chapter
Expected	Data-centre electricity demand more than doubles by 2030 on the International Energy Agency's base case	The agency's projection, with stated uncertainty
Expected	The interval between disclosure and exploitation continues to shorten	Stated by the NCSC, among others; not settled by the 2023 sample
Speculation	That the operator role collapses as agents take over operations	No present evidence; Chapters 27 and 31 consider it

What an organisation can influence is the right-hand side of the argument: the number of dependencies it has recorded, the reversibility of its changes, the age of its recovery evidence and the degree to which the people who must verify machine work have the time and skill to do it.

Summary

Operations is under pressure from six directions, and the evidence for each differs in strength. The measured evidence is strongest for dependency: the reports of AWS, Google Cloud and Cloudflare from 2025 show small faults propagating through shared mechanisms, and Uptime Institute's analysis reports that third-party providers account for about two-thirds of publicly reported outages over nine years, a figure that favours visible failures. The surveyed evidence on change volume, telemetry cost and skills is consistent in direction and limited in method. The argued claims, notably that review capacity does not scale with machine-authored change and that automation moves the load to verification and the rare failure, rest on premises that Chapters 4 and 17 make explicit. The regulatory duty is a fact of text: the clocks of NIS 2 Article 23, DORA Article 19, AI Act Article 73 and GDPR Article 33 and the accountability of the management body under NIS 2 Article 20 and DORA Article 5.

All five operations functions are concerned. O1 Observe carries the cost of seeing and the risk that observation depends on what it observes. O2 Diagnose meets more paths to trace and more signals than people can read. O3 Change meets a rising volume of change and a falling time to exploitation. O4 Restore meets shared fate between services and reporting clocks, and it must say, for each recoverability claim, what was tested, when and with what result; for both organisations the last recorded test failed on time and has no re-test. O5 Sustain meets the limits of people and the cost of compute and energy.

The conclusion of the chapter is the book's own. The pressure is of attention, and AI is arriving as a way to attend at scale; an organisation that adopts it without bounding what it may do and without independent verification replaces a shortage of attention with a concentration of risk. The worked example and the practical guide give the reader a first step that needs no AI: a dependency-and-blast-radius map for one Tier 1 service, with the recovery evidence attached and the unknowns written down. Chapter 4 defines the operations loop, the autonomy budget and the observer principle with which the rest of the book answers the pressures described here.

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). (6, European Union, 2016)
5. Charrier, C. & Weiner, R. (2024). How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. Mandiant, Google Cloud Blog. (72, Charrier & Weiner, 2024)
6. Nordqvist, G. (2026). AI Platform and Security. The Transformed Architecture, Book 3. (297, Nordqvist, 2026)
7. Nordqvist, G. (2026). AI Red Team. The Transformed Architecture, Book 4. (298, Nordqvist, 2026)
8. Nordqvist, G. (2026). AI Threat. The Transformed Architecture, Book 5. (299, Nordqvist, 2026)
9. Nordqvist, G. (2026). The Transformed Security Architect. The Transformed Architecture, Book 6. (300, Nordqvist, 2026)
10. Nordqvist, G. (2026). AI Blue. The Transformed Architecture, Book 8. (302, Nordqvist, 2026)
11. ISC2 (2025). 2025 Cybersecurity Workforce Study. (216, ISC2, 2025)
12. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6). (217, Bainbridge, 1983)
13. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3). (218, Parasuraman & Manzey, 2010)
14. Uptime Institute (2025). Uptime Announces Annual Outage Analysis Report 2025. Press release. (74, Uptime Institute, 2025)
15. Amazon Web Services (2025). Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region. (75, AWS, 2025)
16. Google Cloud (2025). Incident report: multiple Google Cloud products experiencing service issues, 12 June 2025. (76, Google Cloud, 2025)
17. Cloudflare (2025). Cloudflare outage on 18 November 2025. (77, Prince, 2025)
18. Harvey, N. & DeBellis, D. (2024). Highlights from the 10th DORA report. Google Cloud Blog, 22 October 2024. (251, Harvey & DeBellis, 2024)
19. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA report. Google Cloud Blog, 23 September 2025. (117, Harvey & DeBellis, 2025)
20. Rau, V. (2017). Eliminating Toil. In Site Reliability Engineering, Google. (253, Rau, 2017)
21. Spadaccini, A. (2016). Being On-Call. In Site Reliability Engineering, Google. (118, Spadaccini, 2016)
22. Grafana Labs (2025). Observability Survey Report 2025. (119, Grafana Labs, 2025)
23. International Energy Agency (2025). Energy and AI. World Energy Outlook Special Report. (120, IEA, 2025)
24. EBA, EIOPA and ESMA (2025). European Supervisory Authorities designate critical ICT third-party providers under the Digital Operational Resilience Act. 18 November 2025. (7, EBA, 2025)
25. National Cyber Security Centre (2026). Preparing for a 'vulnerability patch wave'. NCSC blog, 1 May 2026. (68, NCSC, 2026)
26. Sundaramurthy, S. C. et al. (2015). A Human Capital Model for Mitigating Security Analyst Burnout. SOUPS 2015. (214, Sundaramurthy et al., 2015)
27. Tariq, S., Baruwal Chhetri, M., Nepal, S. & Paris, C. (2025). Alert Fatigue in Security Operations Centres: Research Challenges and Opportunities. ACM Computing Surveys 57(9). (215, Tariq et al., 2025)