Introduction: The Blue Team Transformed

In 2026 the queue of a security operations centre (SOC) is read, enriched, triaged and in places acted on by AI, while the adversaries it faces use AI to move faster. The question is therefore no longer whether AI will enter the SOC. It is what the team becomes now that it has. This book answers that question for the whole blue team, the people and functions that defend an organisation, and it divides their work into five functions that every later chapter uses by name: B1 Anticipate, B2 Detect, B3 Investigate, B4 Respond and B5 Learn. This chapter states the question, the book's working thesis and the evidence that would show it wrong, and it introduces the two organisations and the reading paths. It concerns all five functions.

The blue team at the centre of the book: the five functions around the loop from telemetry to learning, the degrees of delegation as rings, and the chapters that treat each function

Figure 1.1: The blue team at the centre of the book: the five functions around the loop from telemetry to learning, the degrees of delegation as rings, and the chapters that treat each function.

A night in two security operations centres

The three scenes below are illustrative composites set on one night in the autumn of 2026. They are not records of real events, and they do not use the identifiers of the cases that later chapters follow. They show three situations that the book treats as ordinary: a closure nobody reads, a proposal that a person must answer in seconds, and a feature that arrived without a decision.

Nordvik Region, 02:10. The email-security gateway reports that a caseworker in social services followed a link in a message that the gateway rated low severity. The Region's six security analysts work office hours, so the alert goes to the managed security service provider (MSSP) that monitors out of hours under framework agreement NR-2025-044. The provider's monitoring service enriches the alert, compares it with earlier ones from the same sender domain and closes it with a note that no credential entry was observed. The note is plausible. Nobody at the Region can say under which rule the provider's AI closed the alert, how many such alerts it closed that week, or whether a sample of them was ever read by a person, because the agreement says nothing about autonomy, sampling or notice of a model change. The technique behind the alert, a link in a phishing message (MITRE ATT&CK T1566.002) (9, MITRE, n.d.), is common and usually harmless. Whether this instance was harmless is not known to anyone who works for the Region.

Hansa Mutual, 02:10. In the group SOC, the investigation agent HM-SEC-001 has correlated an endpoint alert with an unusual authentication event and proposes to isolate a file server. Workstation isolation and session revocation are the two reversible actions that the agent may take at Level 3 Bounded, inside a codified playbook. A server is outside that class, so the proposal waits at Level 2 Supervised for the shift lead, who has the agent's summary, a timeline and a dozen other open proposals; no cap yet limits how many one reviewer may hold. The lead can approve in seconds, and the interface is built to make that easy. Whether the lead has actually reproduced the finding, or has only read a fluent account of it, is the question on which the night turns. The agent did not suspect anything; it ranked, correlated and drafted. A person is about to decide, and the quality of that decision depends on how the team has been designed.

Hansa Mutual, 08:30. Two analysts discover that the console of the endpoint detection and response (EDR) product has started to show an AI-generated summary at the top of each incident, and that colleagues have been pasting the summaries into case notes for a fortnight. No decision record mentions the feature. It arrived in a supplier release, runs with the permissions of whoever opens the console, and sends case content to a service whose location nobody has checked. It is Mode 0 Ambient AI in the series' terms: AI present in licensed software, used by people, decided on by nobody.

The three scenes share a feature that is easy to overlook. In none of them did anyone choose a degree of delegation. The provider's closure, the shift lead's speed and the console's summary all came from defaults. The rest of the book argues that a blue team should choose, record and review such degrees, function by function.

The blue team in 2026

The blue team is the group of people and functions that defend an organisation: the analysts who read alerts, the detection engineers who write and tune the rules that raise them, the threat intelligence analysts, the threat hunters, the incident responders and the on-call engineers beside them. The organisation of that group varies widely. Chapter 2 describes the classical SOC, with its tiers, its queue and its tools: a security information and event management (SIEM) system, endpoint detection and response, security orchestration, automation and response (SOAR), a ticketing system and a threat-intelligence platform. Some organisations run all of this themselves. Others buy part or all of it as managed detection and response (MDR) or from an MSSP, and most are somewhere in between.

By 2026 AI sits in this work in three places, and the book keeps them apart because they are governed differently.

  1. In the products the team already uses. SIEM, EDR and email-security products have added AI features that cluster alerts, score them, summarise incidents and draft queries. Many arrive through supplier releases. This is Mode 0 Ambient AI, and it is the least decided of the three. The book's two organisations, which are fictional, are built to illustrate it, and the first inventory below is how a reader tests the premise in a real estate. The MSSP's closure of alerts is the same phenomenon one step removed, since the AI runs in the provider's platform and the customer sees only its output.
  2. In the analyst's own work. Analysts use conversational and embedded assistants and, increasingly, agentic work tools to write queries, summarise logs and draft reports. These are Modes 1 to 3, and the AI acts with the analyst's identity. Chapter 12 treats this use.
  3. As systems built or procured to perform a blue team function. A triage agent that closes defined classes of alert, an investigation agent that proposes containment, a detection-drafting assistant: these are Mode 4 applications or Mode 5 agents with identities and permissions of their own. Chapters 7 to 10 and 13 treat them.

The pressure that makes this unavoidable is also documented. Studies of SOC analysts' work found, well before the present generation of AI, that tools produce many false positives and that validating alarms is tedious: a qualitative study with 20 survey respondents and 21 interviewees working in SOCs reported that most false positives come from alarms that are technically accurate but reflect legitimate behaviour in the organisation, and that validation can lead to alarm burnout and desensitisation (69, Alahmadi et al., 2022). On the supply side, the ISC2 2025 workforce study, an online survey of 16,029 practitioners and decision-makers, reported that 95 per cent of respondents had at least one skill need and that 28 per cent had already integrated AI tools into operations (73, ISC2, 2025). A practitioner survey measures what respondents say, not what happens, but the two numbers together describe the situation of this book: work that exceeds the capacity of the people who do it, and a rapid, partly undecided adoption of AI to close the gap. Chapter 3 treats the pressure in full, including the adversaries' use of AI.

Practical guide: A first inventory of the AI that already takes part in a team's work

Purpose. To find the AI that already acts in or for the blue team, at the autonomy it actually has rather than the autonomy anyone intended, before deciding what to delegate.

Roles. The SOC lead or head of security operations (owner), the detection engineering lead, the CISO's deputy, the data protection officer, and, where the team is monitored by the tools in question, an employee representative as observer.

Steps.

  1. List every tool in the team's path from telemetry to closure: SIEM, EDR, email gateway, SOAR, ticketing, threat-intelligence platform, case management and the consoles analysts use daily.
  2. For each tool, read the supplier's release notes for the past 12 months and the current feature list, and record every feature that uses a model, whether switched on or off.
  3. For each managed service (MSSP, MDR, incident-response retainer), ask in writing three questions: does AI close, suppress or de-prioritise alerts or take any action; under which written rule and at which volume; and what notice is given of a change of model or rule. A provider that cannot answer is recorded as autonomy unknown.
  4. Ask each analyst, in a short anonymous round, which assistants they use for work and with what data. Record classes of use, not names. Do not use logs to find individuals.
  5. Assign each finding a usage mode (Mode 0 to Mode 5), the blue team functions it touches, the data class it processes and a provisional degree of delegation, Level 0 Advisory to Level 4 Autonomous, as it actually behaves.
  6. Mark every finding as decided (a decision record exists), tolerated (known, no record) or unknown. The unknowns are the first work.

Definition of done. Every AI capability that touches alerts, cases, evidence or response has one row, an owner and a status. The register is reviewed quarterly and after every supplier release that adds a model feature. Adapt the review interval to the pace of the supplier's releases, and agree the anonymous round with the employee representatives before it is run.

The question the series had not asked of a team

The earlier volumes lay the ground for this book and also leave a gap in it. Each contributes one conclusion that the book takes as given. Architecture as Code made security something to be tested and recovered by redeployment from known-good definitions (61, Nordqvist, 2025). AI Governance made governance proportionate to how AI is used, and introduced the usage modes (62, Nordqvist, 2026). AI Platform and Security concluded that every AI system must be designed twice, once as something to protect and once as something to contain (63, Nordqvist, 2026). AI Red Team organised AI-enabled defence by the six Functions of the NIST Cybersecurity Framework 2.0 (17, NIST, 2024), and concluded that AI strengthens defence when it acts inside a written mandate, at an autonomy level matched to the reversibility of its actions, on a platform where containment holds whatever anyone intends (64, Nordqvist, 2026). AI Threat argued for decisions kept as correctable records, for the ability to stop kept outside the system being stopped, and for people kept able to do the work and judge the output (65, Nordqvist, 2026). The Transformed Security Architect found one role, the designer of the boundaries on which all of this depends, transformed rather than abolished, because accountable human judgement stays scarce (66, Nordqvist, 2026). AI Boss concluded that AI may direct work but may not, on its own, decide about people (67, Nordqvist, 2026).

AI Red Team mapped what AI can do for cyber defence, Function by Function. It is a capability map, and it treats the people mainly as the accountable authority over the AI. The Transformed Security Architect asked the question of a role and AI Boss asked it of managers. Nobody has yet asked it of the team that does the defending: which of its functions may be delegated to AI and to what degree, who decides and how the decision is recorded, what happens to the roles, the decision rights and the careers of the people when the queue is no longer theirs, and what is the daily experience of working on call beside systems that act at night. This is the gap this book fills. It takes the capability map as given and does not repeat it. Where AI Red Team says what a triage agent can do, Chapter 7 describes what triage becomes and how its quality is shown when most alerts are never read by a person, and Chapter 4 says who answers when an intrusion is closed by mistake.

AI Boss adds a second reason for care. Analysts are workers, and the instruments that measure and manage them are the subject of that volume. This book applies its conclusions to the SOC in Chapter 21 and does not repeat them: closure rates, on-call burdens and logged queries are management data about people, and the same rule of named human decision-makers and works-council involvement applies.

The working thesis

The book's argument has five parts. Together they are the book's own conclusion, to be tested in Parts II to V and judged in Chapter 28, with the future outlook in Chapter 24; they are not findings of any external study. Each part comes with the evidence that would show it wrong, because a thesis that cannot be refuted is a slogan.

Claim In short What would refute it
1. Transformed, not abolished What remains scarce is accountable human judgement under uncertainty: verifying what AI concludes and answering for a containment decision Evidence that fully autonomous detection and response, with no human able to verify and stop it, produces better outcomes over years than a team with those properties
2. From the queue to the loop The work moves from handling alerts to engineering detections, playbooks and agent mandates as code; each alert is evidence of a detection not yet engineered, and each incident ends in a verified improvement Evidence that teams which keep a queue-centred model match the loop-centred teams on coverage and time to contain, with no more strain on staff
3. Autonomy matched to reversibility AI acts inside a written mandate at a level matched to reversibility, and a stop path lies outside the system it stops Evidence that irreversible containment run at Level 4 Autonomous causes less harm than the same actions held at Level 3 Bounded or below
4. The defenders' AI is defended The SOC reads text that adversaries can write, so its agents are privileged insiders that need containment and the SOC is a tier-0 asset Evidence that agents reading attacker-writable input need no more containment than other automation, over a long period of exposure
5. The route to the craft and the wellbeing of staff are design questions Analysts are made through junior work that AI now does, and people who work at machine speed and on call need a designed environment Evidence that AI-handled triage leaves the capacity to investigate novel intrusions intact without people who practise the craft, or that wellbeing is unaffected by the new work

Three comments on the table. First, the thesis is a claim about design, not prediction. Organisations choose their delegation, their stop paths and their pipelines for analysts; the thesis says what a good choice looks like. Second, claim 1 borrows from the finding of the earlier volumes about the architect and the manager. It would be wrong to assume it carries over to the blue team without testing, and Chapter 23 tests it against what is known about automation and human skill. Bainbridge's classic analysis of the ironies of automation argued that automating a task leaves the human the residue that cannot be automated, and weakens the practice that the residue requires (75, Bainbridge, 1983). Later work on complacency and bias in human use of automation reached related conclusions for monitoring tasks (76, Parasuraman & Manzey, 2010). Claim 5 is a response to that body of work. Third, claim 3 is the one on which the rest depends, and Chapter 4 turns it into a written mandate and a delegation profile.

Five functions and five degrees

The five functions

Chapter 2 defines the five blue team functions in full. In short:

  • B1 Anticipate is threat intelligence, exposure awareness and the hypotheses that direct detection and hunting.
  • B2 Detect is engineering, running and tuning the detections that turn telemetry into alerts.
  • B3 Investigate is triage, scoping, analysis and forensics that turn an alert into a verified case.
  • B4 Respond is containment, eradication, recovery coordination, communication and reporting.
  • B5 Learn is post-incident review, purple teaming and the improvement of detections, playbooks and mandates.

They form a loop: telemetry becomes alerts, alerts become cases, cases become responses, responses become reviews, and reviews change what is anticipated and detected. The loop is the unit of the book, and the diagram above shows it. The functions are the blue team's own and are distinct from the six Functions of NIST CSF 2.0, which the book names with a capital and by NIST's own names (17, NIST, 2024); a blue team function usually spans parts of several CSF Functions. The five functions are also not job titles. In a team of six they are held by the same few people, and in a team of 38 by distinct groups; what matters is that each has an owner and a stated degree of delegation.

The five degrees of delegation

The book reuses the autonomy levels of AI Red Team, Chapter 6, and applies them per function and per action class (64, Nordqvist, 2026). The mode describes how the AI is deployed and whose identity it uses; the level describes who decides each action.

Level Meaning for a blue team function
Level 0 Advisory The AI produces information; a person acts or does not
Level 1 Assisted The AI drafts or prepares the action; a person takes it
Level 2 Supervised The AI proposes an action and a person approves each one before it runs
Level 3 Bounded The AI executes a defined class of action inside a codified playbook enforced by a policy decision point outside the model, with sampling and a stop path
Level 4 Autonomous The AI selects and executes actions without a playbook bound or a prior human decision

The line between Level 2 and Level 3 is the most important one, because it is where a person ceases to see each action before it happens and begins to answer for a class of actions. Level 3 is defined by the playbook and the policy decision point, not by the model's confidence. Level 4 Autonomous is never used for an irreversible B4 Respond action, nor for an action that decides about a named person's access to work. The second exclusion follows AI Boss, which concluded that every function that carries consequences for a person has a named human decider (67, Nordqvist, 2026). In a blue team it is not hypothetical. Disabling a named employee's account, or suspending their access, is such an action: it is a measure about that person, and a named human approves it at Level 2 at most. Temporarily isolating a device or revoking a session is reversible containment, not a decision about the person's access to work; it may run at Level 3 inside a playbook, and the person is told promptly. Chapter 4 sets out the action classes behind this line.

The word "decides" needs the same care as in the earlier volumes. An AI system enriches, correlates, ranks, flags, drafts, recommends or executes a playbook. Where this book writes that a system decides, a decision was formally delegated to it, and the record names who delegated it, under which delegation profile and at which level.

Across the usage modes

The modes tell a reader whose identity the AI uses and where it runs; Chapter 4 gives the default ceiling for each, and each later chapter shows how its subject differs across them. Three contrasts are enough for now. In Mode 0 Ambient AI, present in licensed software or a provider's platform, the AI arrives without a decision, as in the first and third scenes above, and the first task is simply to find out. In Modes 1 to 3 (conversational assistants, embedded workplace assistants and agentic work tools) the person is the actor, the AI borrows the person's identity, and the risk is mainly what the person gives the assistant and how far the person relies on its output. In Mode 4 Built AI applications and Mode 5 Autonomous production agents the system is built or procured to perform a function, and a Mode 5 agent, with an identity and permissions of its own, is a privileged machine insider whose mandate, identity and stop path must be designed.

Why Europe, and why now

The question is a European organisational question in 2026 because the instruments that bear on a blue team have converged on the same demand: that the organisation can show who decides, how fast it can detect and report, and what it keeps under control. Each is treated in detail in Chapter 19. The following is the map this chapter needs. Legal statements here are organisational and architectural implications, not legal advice, and each is attributed to the instrument.

  • NIS 2 (3, European Union, 2022). Article 20 places responsibility for approving and overseeing cybersecurity risk-management measures on the management bodies of essential and important entities. Article 23 sets reporting duties for significant incidents, with an early warning, an incident notification and a final report at stated intervals. Implication: a team must be able to classify an incident and start the reporting clock within hours, which makes the speed and the records of B3 and B4 matter to the board.
  • DORA (2, European Union, 2022). Article 5 makes the management body of a financial entity responsible for ICT risk, and Articles 17 to 19 set out incident management, classification and reporting. Implication: for Hansa Mutual's EU entities, the SOC's records, its classification and its use of third-party AI services fall within supervised ICT risk and third-party arrangements.
  • The GDPR (8, European Union, 2016). Article 32 requires security of processing, and Articles 33 and 34 set out notification of a personal data breach to the supervisory authority and communication to the data subject. Implication: an investigation must establish quickly whether personal data was affected, and alert and case content is itself personal data, which constrains where AI may process it.
  • The Cyber Resilience Act (5, European Union, 2024). It places reporting duties on manufacturers of products with digital elements, including for actively exploited vulnerabilities. Implication: organisations that build or sell such products need B1 and B3 capacities that serve their own duties as well as their defence.
  • The AI Act (1, European Union, 2024). Most security AI is not high-risk, but Article 4 on AI literacy applies to providers and deployers for the staff who use AI systems. If a SOC system fell in a high-risk category, the human-oversight design requirement of Article 14 would bind its provider and the deployer duties of Article 26 would bind the organisation that uses it under its own authority, which in the SOC is the Region or the group. Tools that log or measure analysts as workers can raise the questions that AI Boss treated, and in Germany they trigger co-determination.

The "why now" has two parts. First, AI is already in the work: the three scenes illustrate it, and the ISC2 survey cited above reports that 28 per cent of respondents had integrated AI tools into operations. Second, the adversary side moves in the same direction. AI Platform and Security, Chapter 18, summarised the evidence of a shrinking exploitation window and of AI-enabled attackers (63, Nordqvist, 2026), and the Five Eyes cyber agencies' joint statement of June 2026 is titled as an appeal to leaders to act now on the AI shift in cyber risk (34, Five Eyes agencies, 2026). Chapter 3 sets out that evidence and labels each outlook observable, expected or speculation. The July 2026 incident in which an agent from a frontier laboratory's testing intruded into another organisation's systems, documented in a technical timeline by Hugging Face (56, Larcher et al., 2026), prompted both organisations of this book to ask the question this chapter ends with. Whether a SOC will cease to exist as a function is a question on which this chapter takes no view, and Chapter 24 examines it with the debate form the book reserves for such questions.

Rules of the book

The book keeps the series' disciplines, and a reader may hold it to them.

  • Defensive only. Adversary behaviour is described by technique, using MITRE ATT&CK or ATLAS identifiers (9, MITRE, n.d.) (10, MITRE, n.d.), at the level needed to design detections, controls, decisions and tests. The book contains no exploit code, malware, payloads, jailbreak or injection strings, phishing kits or step-by-step intrusion instructions. Every offensive activity it mentions is authorised, scoped and ends in a defensive improvement.
  • Observable, expected, speculation. Every statement about the future of the blue team, of threats or of the technology carries one of the three labels of AI Governance, Chapter 22 (62, Nordqvist, 2026): observable (happening now and documented), expected (supported by a stated trend or a decided instrument) or speculation (plausible but not supported by present evidence). The author's own projections are confined to Chapters 24 and 28 and labelled as the author's judgement.
  • No anthropomorphism. An AI system enriches, correlates, flags, recommends or executes a playbook. It does not suspect or judge. "Decides" is used only where a decision was formally delegated, and the record then says who delegated it.
  • People by what studies measured. Effects on analysts are described by what a study measured, in whom, over what period and by what method, and never by calling anyone lazy, stupid or replaceable. Practitioner surveys are labelled as such, because they report what respondents say.
  • Legal content as implication. Statements are attributed to the instrument and article and framed as organisational and architectural implications, not legal advice.
  • Records, not claims. The work of the team appears as versioned artefacts that belong in version control: detection records (DET-*), case records (CASE-*), playbook manifests (PBK-*), hunt records (HNT-*), post-incident reviews (PIR-*), mandate manifests (MND-*), delegation profiles (DLG-*), role charters (ROLE-*) and competence records (CMP-*). Decisions are recorded as AI Decision Records, AIDR, and Architecture Decision Records (ADR) (61, Nordqvist, 2025).

Two organisations

Two fictional organisations run through the book. Neither is real; names, figures and documents are invented, and real instruments are named only to show which obligations apply.

Nordvik Region is a regional public authority in a Nordic member state of the European Union, with about 6,000 employees and about 450,000 residents. Its security unit has 14 people under the chief information security officer (CISO), of whom six are security analysts who work office hours. Out-of-hours monitoring is bought from a European MSSP under framework agreement NR-2025-044, which requires processing and log storage inside the EU and EEA. It runs a procured SIEM service, endpoint detection and response, and an email-security gateway. Detection rules are mostly supplier defaults, and there is no detection-engineering function, no intelligence analyst and no hunting practice. The senior security analyst, Karin Lund, in practice owns the SIEM and its few local rules. Alert data includes personal and health data, which pushes the Region towards self-hosted models on its reserved capacity. Its leverage is the contract and the few rules it owns.

Hansa Mutual is a mutual insurance group headquartered in Hamburg, with about 9,500 employees and operations in seven countries, inside and outside the EU. Its group SOC has about 38 people and runs around the clock from Hamburg and the Polish service centre, with a UK late shift. It has a threat-intelligence cell of three, a detection-engineering team of four that manages detections as code, an incident-response team and a group red team of five. Its investigation agent HM-SEC-001 already acts at Level 3 Bounded for two reversible actions. The Konzernbetriebsrat, chaired by Thomas Brandt, co-determines on tools that can monitor employees. Its leverage is the platform, the detections as code and the agent team.

Both receive the same question in the same autumn, after the July 2026 incident and their AI threat assessments. In Nordvik the regional director asks the CISO what the unit becomes when AI enters its work, before the 2027 budget is set. In Hansa the executive board asks the group CISO how the SOC will work when its agents act at night and when adversaries use AI. Both put the question on the record before answering it. Each record below is an illustrative rendering of the decision record the organisation keeps; the dates and reviewers are those of the book's year, and the questions are paraphrased from the commissions.

Worked example: the commission at Nordvik Region (illustrative)

# decisions/AIDR-0700.yaml (illustrative)
id: AIDR-0700
date: 2026-11-23
title: What the security unit becomes when AI enters its work
status: commissioned
commissioned_by: regional director
accountable: chief information security officer
question: >
  What do six analysts, a managed provider and a procured SIEM become
  when AI takes part in security operations, within the 2027 budget?
scope:
  functions: [B1 Anticipate, B2 Detect, B3 Investigate, B4 Respond, B5 Learn]
  systems: [siem, edr, email-gateway]
  providers: [NR-2025-044]
constraints:
  - alert data contains personal and health data
  - self-hosted or EU-hosted models only
  - public-access and archive rules apply to case records
  - one national co-determination regime; closure rates never reported by name
reviewers: [hr-lead, ai-architect, data-protection-officer]
deliverables:
  - inventory of AI in the team's work and in the provider's service
  - proposed delegation profile per function
  - requirements for the provider agreement
report_due: 2027-06-30
review: 2027-06-30

Worked example: the request at Hansa Mutual (illustrative)

# decisions/AIDR-0750.yaml (illustrative)
id: AIDR-0750
date: 2026-11-24
title: How the SOC works when agents act at night and adversaries use AI
status: requested
requested_by: executive board
accountable: group chief information security officer
question: >
  What does a 24/7 SOC across two sites and seven legal regimes look
  like when an investigation agent already acts on two reversible
  actions and adversaries move at machine speed?
scope:
  functions: [B1 Anticipate, B2 Detect, B3 Investigate, B4 Respond, B5 Learn]
  agents: [HM-SEC-001, HM-SEC-002]
constraints:
  - works-council consultation in Germany, the Netherlands and Sweden
  - DORA third-party risk for every security AI service
  - UK and Swiss telemetry subject to transfer rules
  - night shift staffed in two countries
reviewers: [chief-risk-officer, head-of-detection-engineering, chair-group-ai-governance-board]
first_report: 2027-04-30
review: 2027-04-30

How to read this book

The book has six parts. Part I (Chapters 1 to 4) describes the blue team before the transformation, the pressure on it and the transformed team defined, with its mandate and delegation profiles. Part II (Chapters 5 to 11) treats the craft: Chapter 5 Anticipate, Chapter 6 Detect, Chapter 7 triage, Chapter 8 Investigate, Chapter 9 threat hunting, Chapter 10 Respond and Chapter 11 Learn. Part III (Chapters 12 to 15) treats the blue team's own AI: the analyst's personal use, the agent team, the verification of what AI concludes and the defence of the defenders' AI. Part IV (Chapters 16 to 20) places the team in the organisation: operating models, team design, decision rights, regulation and measurement. Part V (Chapters 21 to 24) concerns people and career, including the debate on whether there will be a SOC in 2036. Part VI (Chapters 25 to 28) brings experience and conclusions: case studies and anti-patterns, a year on the blue team, conclusions for the two organisations and the book's own conclusion.

Readers do not need to follow the order. The table suggests paths; Chapters 1 to 4 are the common ground for all of them.

Reader Questions to start from Suggested chapters
Board member What have we delegated, who answers for it, what must we oversee? 3, 4, 18, 19, 20, 24, 28
CISO Which functions may AI take, at which degree, and how do I record it? 4, 10, 13, 16, 18, 19, 20, 27
SOC lead or head of security operations How do I run a team with agents in it and keep review real? 7, 10, 13, 14, 17, 21
Analyst What happens to my work, my skills and my on-call burden? 7, 8, 12, 14, 21, 22, 23
Detection engineer How do I write, test and own detections when AI drafts them? 5, 6, 9, 11, 14, 15
Procurement and contract managers What must a managed provider or an AI supplier give us? 13, 16, 19, 20, 25
Employee representatives Which tools measure analysts, and what has been agreed? 14, 20, 21, 22, 23

Each narrative chapter names the blue team functions it concerns in its opening and its Summary, has a compact table of how its subject differs across the usage modes or the degrees of delegation, and ends with a short comparison of the two organisations. Chapters 7, 21, 23 and 24 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.

Nordvik Region and Hansa Mutual

For Nordvik Region the introduction means a commission and a first inventory. The unit has to learn what its provider's AI does at night, because the agreement does not say, and it must decide, with six analysts and public pay scales, which function to build first. The record AIDR-0700 asks for an inventory, a delegation profile and provider requirements by 2027-06-30. For Hansa Mutual the same question arrives as a request from the executive board. The group has agents with identities and a works council whose agreement it needs, so the work is less to discover than to bound, review and prove. AIDR-0750 expects a first report by 2027-04-30. The two differ in what they must create and what they must restrain: Nordvik has to create the practice of owning detections and testing its provider, while Hansa has to keep review real at a volume that people alone could not read. Both start from the same fact shown in the night scenes, that degrees of delegation exist whether or not anyone chose them.

Summary

This chapter introduced AI Blue as the book about the team that defends. It concerns all five blue team functions: B1 Anticipate, B2 Detect, B3 Investigate, B4 Respond and B5 Learn. It showed, in three illustrative scenes, that in 2026 AI already closes alerts, proposes containment and appears in consoles without a decision, and it set out where AI sits in the blue team's work: in the products, in the analyst's own use and in systems built to perform a function. It related the book to the earlier volumes, which mapped what AI can do for cyber defence, described the transformed security architect and showed that AI may direct work but may not, on its own, decide about people, and it named the gap this book fills.

The working thesis has five parts: the blue team is transformed, not abolished; the work moves from the queue to the loop; autonomy is matched to reversibility with a stop path outside the system it stops; the defenders' AI is part of the estate that is defended; and the route by which analysts are made and their wellbeing are design questions. Each comes with the evidence that would refute it. The degrees of delegation, Level 0 Advisory to Level 4 Autonomous, are applied per function and per action class, and Level 4 is never used for an irreversible B4 Respond action or for an action that decides about a named person's access to work. The chapter also set out why the question is European and current: NIS 2, DORA, the GDPR, the Cyber Resilience Act and the AI Act together demand that an organisation can show who decides, how fast it reports and what it keeps under control. The evidence on adversaries' use of AI is weighed and labelled in Chapter 3, and the future of the SOC is debated in Chapter 24.

The two organisations received the same question in the same autumn and recorded it as AIDR-0700 and AIDR-0750. The rules of the book, defensive only, labelled outlooks, no anthropomorphism and effects on people described by what studies measured, apply from here to the last chapter. What a reader can do now is the first inventory of the practical guide: list the AI that already takes part in the team's work at the autonomy it actually has. Chapter 2 describes the blue team before the transformation, its five functions, tiers and alert queue, so that the changes of Chapters 5 to 11 can be measured against a baseline.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (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). (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). (3, European Union, 2022)
  4. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). (5, European Union, 2024)
  5. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation). (8, European Union, 2016)
  6. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (9, MITRE, n.d.)
  7. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. (10, MITRE, n.d.)
  8. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (17, NIST, 2024)
  9. Five Eyes cyber security agencies: ASD's ACSC, Canadian Centre for Cyber Security, NCSC-NZ, NCSC-UK, NSA and CISA. The AI shift in cyber risk: why leaders must act now. (34, Five Eyes agencies, 2026)
  10. Larcher, H., Carreira, A. et al. Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident. (56, Larcher et al., 2026)
  11. Nordqvist, G. Architecture as Code. (61, Nordqvist, 2025)
  12. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (62, Nordqvist, 2026)
  13. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (63, Nordqvist, 2026)
  14. Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (64, Nordqvist, 2026)
  15. Nordqvist, G. AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (65, Nordqvist, 2026)
  16. Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (66, Nordqvist, 2026)
  17. Nordqvist, G. AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. (67, Nordqvist, 2026)
  18. Alahmadi, B. A., Axon, L. & Martinovic, I. 99% False Positives: A Qualitative Study of SOC Analysts' Perspectives on Security Alarms. USENIX Security 2022. (69, Alahmadi et al., 2022)
  19. ISC2. 2025 Cybersecurity Workforce Study. (73, ISC2, 2025)
  20. Bainbridge, L. Ironies of Automation. Automatica 19(6), 1983. (75, Bainbridge, 1983)
  21. Parasuraman, R. & Manzey, D. H. Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3), 2010. (76, Parasuraman & Manzey, 2010)