Series Foundations: What This Book Builds On
This is a reference for authors and editors, not a manuscript chapter. AI Blue is Book 8 of The Architecture as Code Series. It does not repeat the earlier volumes; it takes their conclusions as its starting point and asks a question none of them asked directly: how is the blue team, the people and functions that defend an organisation, transformed when AI enters their work, and when attackers use AI against them? This document records the conclusions the book builds on with stable identifiers (F1 to F91, grouped by volume), the open questions that the earlier volumes left or that this book raises (Q1 to Q12), the artefacts and vocabulary the book reuses, and the tables of contents used for cross-references. BOOK_BLUEPRINT.md maps every chapter of this book to the foundations it builds on.
The series builds strictly in publication order, so that there is no circular reasoning between the books. This book refers to Books 1 to 7 and never to a later volume. It cites Architecture as Code as (Nordqvist, 2025) and AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect and AI Boss as (Nordqvist, 2026), each through its own entry in docs/31_references.md. When a chapter builds on a foundation, it says so in the prose, refers to the earlier volume in plain text by chapter ("Architecture as Code (Chapter 9B)"; "AI Governance, Chapter 13"; "AI Platform and Security, Chapter 19"; "AI Red Team, Chapter 18"; "AI Threat, Chapter 30"; "The Transformed Security Architect, Chapter 14"; "AI Boss, Chapter 26"), cites the volume's bibliography entry, and summarises enough that the reader is not left with a gap. A reference to an earlier volume builds on that volume's conclusions; it never stands in for an external source for a factual claim.
The turn this book makes
The seven earlier volumes are about systems and about the people who govern, secure, assess, architect and manage them. Architecture as Code made architecture executable. AI Governance made the governance of AI executable and proportionate to how AI is used. AI Platform and Security built the AI platform and concluded that every AI system must be designed twice, as something to protect and as something to contain. AI Red Team put AI to work in cyber defence under a written mandate, at an autonomy level matched to reversibility, organised by the Functions of NIST CSF 2.0. AI Threat asked whether the dystopias are coming true and answered that the quiet harms deserve attention first. The Transformed Security Architect described what has happened to the role that designs the boundaries, and AI Boss asked what happens when AI takes the manager's chair.
AI Blue is the companion of AI Red Team on the people side. AI Red Team asked what AI can do for cyber defence, Function by Function. This book asks what happens to the team that does the defending: the security operations centre (SOC), detection engineers, threat intelligence analysts, threat hunters, incident responders and the on-call engineers beside them. It does not repeat the capability map of AI Red Team, Chapters 18 to 21; it takes that map as given and describes the work, the roles, the decision rights, the careers and the daily experience of a team whose queue is increasingly read, enriched, triaged and sometimes acted on by AI, while its adversaries use AI too. Its question is the one The Transformed Security Architect asked of one role, asked of a team: what remains scarce, and what must be kept?
The book divides the blue team's work into five functions, named exactly so in every chapter that uses them: B1 Anticipate, B2 Detect, B3 Investigate, B4 Respond and B5 Learn. It treats the delegation of each function to AI as a degree, using the series' autonomy levels, so that a delegation profile states, per function, how far a given AI capability has been allowed to go. The work of the team becomes a set of versioned records: detections, cases, playbooks, hunts, mandates and post-incident reviews.
Its working thesis, to be tested and judged in Chapters 24 and 28, has five parts. First, the blue team is transformed, not abolished: what remains scarce is accountable human judgement under uncertainty, the ability to verify what AI concludes and to answer for a containment decision. Second, the work moves from the queue to the loop: from handling alerts to engineering detections, playbooks and agent mandates as code, so that each alert is treated as evidence of a detection not yet engineered and each incident ends in a verified improvement. Third, AI may act inside a written mandate at a level matched to reversibility, but Level 4 Autonomous is never used for an irreversible containment action or for any action that decides about a named person's access to work, and a stop path that lies outside the system it stops is part of the design. Fourth, the defenders' own AI is part of the estate that is defended: the SOC reads text that adversaries can write, so its agents are privileged insiders that need containment, and the SOC itself is a tier-0 asset. Fifth, the route by which analysts are made, through the junior work that AI now does, and the wellbeing of people who work at machine speed and on call, are first-order design questions rather than side effects. The thesis would be shown wrong by evidence that fully autonomous detection and response, without a human who can verify and stop it, produces better outcomes over years than a team with those properties, or that AI-handled triage leaves the capacity to investigate novel intrusions intact without people who practise the craft. The book keeps the series' discipline for outlooks: what is observable, what is expected and what is speculation, with the author's own projections kept to Chapters 24 and 28.
Foundations from Architecture as Code (Book 1)
| ID |
Conclusion |
Where it is made |
| F1 |
Threat handling belongs in the codebase: threat intelligence is ingested as STIX/TAXII through pipelines, threat models are generated from architecture code, response playbooks are state machines (subscribe, assess, act, document), and findings return as pull requests. "Celebrate the remediation pull request, not just the discovery." |
Chapter 9C, Risk as Code and Threat Handling as Code |
| F2 |
Risk is a versioned record with likelihood, impact, owner and expiring exceptions; a failing control metric fails the pipeline. |
Chapter 9C |
| F3 |
Policy as Code (OPA/Rego) with "assure once, comply many": a control is written once and mapped to many obligations, with evidence linked to enforcement. |
Chapters 10 and 11, Policy and Security as Code in Detail; Governance as Code |
| F4 |
Evidence as Code: evidence is machine-collected, signed and versioned, not assembled in audit season. |
Chapter 15A, Evidence as Code and Continuous Assurance |
| F5 |
Manual incident response cannot scale when attacks develop within minutes; compromised components are redeployed from known-good definitions, and MTTD, MTTR and false-positive ratio are the programme metrics. AI models must themselves be defended against adversarial machine learning. |
Chapter 9B, Advanced Security Patterns and Implementation |
| F6 |
Security architecture has four dimensions that the codebase must carry: threat modelling, zero trust, Policy as Code and risk assessment. |
Chapter 9, Security Fundamentals for Architecture as Code |
| F7 |
Security and compliance tests, including synthetic attack simulations, run in the pipeline against ephemeral environments. |
Chapter 13, Testing Strategies for Infrastructure as Code |
| F8 |
Architectural decisions are kept as short, numbered, immutable Architecture Decision Records beside the code, with context, options and consequences, so that the rationale survives the people who made it. |
Chapter 4, Architecture Decision Records (ADR) |
| F9 |
Architecture as Code succeeds only with equal investment in people, process and technology. Modern roles blend engineering, governance and advocacy; security partners work from shared roadmaps and influence without direct authority; dual-ladder careers keep experts on technical tracks; resistance to change usually signals legitimate concerns about skills and job security. |
Chapter 17, Organisational Change and Team Structures |
| F10 |
Platform teams act as internal service providers that own the common toolchains, guardrails and reusable modules, so that product teams move quickly without sacrificing governance; the system design mirrors the organisation's communication paths (Conway's law). |
Chapters 17 and 18, Team Structure and Competency Development for IaC |
| F11 |
Competence is managed as a skills matrix by level (Foundation, Practitioner, Advanced, Expert) with interpersonal domains, in a development loop of assessment, planning, learning, application, knowledge sharing and measurement; certifications validate knowledge, while practical demonstration on real delivery shows capability. |
Chapter 18 |
| F12 |
AI agents are structured participants under human direction: "agents draft; humans approve", and exceptions and risk acceptances carry a named human approval in the audit trail. |
Chapter 20, AI Agent Team for Architecture as Code Initiatives |
| F13 |
Some decisions stay with people whatever the agents propose: architectural commitments with long-term consequences (platform lock-in, data residency, operational dependencies) are escalated by the Architect agent, conflicting agent recommendations are decided by the human owner, and every decision is linked to a commit, a pull request and an accountable individual. |
Chapter 20 |
| F14 |
The habit on which trustworthy programmes are built is making the implicit explicit: an AI-assisted decision without a traceable human rationale should receive an Architecture Decision Record, written retrospectively if necessary. |
Chapter 27, Conclusion |
Foundations from AI Governance (Book 2)
| ID |
Conclusion |
Where it is made |
| F15 |
AI governance is effective when it is codified, evidenced and proportionate to usage mode and risk; the usage mode, not the brand, sets the governance (Mode 0 Ambient AI to Mode 5 Autonomous production agents). |
Chapters 2 and 25 |
| F16 |
Classification is triggered by change, not by the calendar: a new model version, a drift alert, an incident, a regulatory change or a move between modes. |
Chapter 8, AI Risk Management and Classification as Code |
| F17 |
Decisions are tiered and routed to the lowest tier that can take them with evidence: routine decisions at pipeline gates, exceptions at a design authority, high-risk go-live at the AI governance board, risk beyond appetite at the management body. The tier policy is itself data, changed by pull request. |
Chapter 13, Decision Forums and Governance Bodies |
| F18 |
Governance as code does not remove forums; it changes what they are for. Pipelines enforce, observe and remember, while forums decide what pipelines cannot: appetite, policy, exceptions and residual risk. NIS 2 Article 20 and DORA Article 5 anchor oversight in a trained management body, and the AI architect acts as secretary of the design authority. |
Chapter 13 |
| F19 |
Stop decisions are named in advance: the on-call incident commander and the use-case owner may each stop a system unilaterally, restart needs the owner and, for high-risk systems, the risk function, and a stop path that runs inside the system it stops fails when it is needed. |
Chapter 13 |
| F20 |
Evidence is a by-product of delivery; the evidence manifest ties the chain together; attestation is a person asserting, evidence is machine-generated. |
Chapter 11, Evidence, Assurance and Audit |
| F21 |
Human oversight must be designed, not declared: an interruption path, an override log and the authority to use them. Approvals given in seconds are a signal of rubber-stamping. |
Chapters 10 and 21 |
| F22 |
Organisational design is architecture by other means (Conway's law). Hub-and-spoke scales when the hub is a platform team in X-as-a-service mode and an enabling team in facilitating mode; control functions keep their independence through gates and records rather than meetings ("gates instead of meetings"), with exceptions routed as expiring records. |
Chapter 12, Organisational Design for AI |
| F23 |
The AI architect owns the seams between the architecture roles. The security architect keeps the threat model, identity, secrets and zero trust, and relies on the AI architect for AI-specific threats, guardrail policy, agent permissions and the model supply chain. |
Chapter 14, Competence, Roles and the AI Architect |
| F24 |
New roles follow the usage modes: the AI system owner, the agent operator who watches Mode 5 agents and may revoke their credentials, the skills curator and the evaluation engineer; existing roles such as procurement, internal audit and the data protection officer change. |
Chapter 14 |
| F25 |
AI literacy is role-specific and must be evidenced in a competence framework and individual records checked at the readiness gate. Article 4 of the AI Act, as amended by the Digital Omnibus, asks for measures that support literacy, but Articles 14 and 26(2) still demand competent oversight, and NIS 2 Article 20(2) and DORA Article 5(4) require management-body training. |
Chapter 14 |
| F26 |
Upskilling is the strategy and hiring is for scarce specialisms and the first AI architect; careers need a specialist ladder and a path between building and verifying with a cooling-off period; competence is assessed by practical demonstration, and assessment results are personal data whose use is agreed with employee representatives. |
Chapter 14 |
| F27 |
Govern every agent as a well-meaning insider: instructions lower the rate of unwanted behaviour, but only boundaries set a ceiling on its consequences. |
Chapters 19 and 25 |
| F28 |
The July 2026 OpenAI–Hugging Face incident failed through correlated controls: a shared credential, a package mirror that was also an egress path, and an alert that reached people who did not hold the stop decision. |
Chapter 19, A Cautionary Case: The OpenAI–Hugging Face Incident |
| F29 |
Patch decisions must be delegated in advance; a weekly change advisory board cannot sit in the path of known-exploited vulnerabilities, and patch velocity belongs in management reporting as a risk indicator. |
Chapter 24, Reflections on Each Part |
| F30 |
Model origin is a risk question separate from hosting: five categories of geopolitical risk, and a risk-tiered position that decides which models may handle which data, reviewed periodically rather than once. |
Chapter 6, Geopolitics and Model Origin |
| F31 |
In public authorities legality comes before capability: the line between decision support and automated decision is drawn in the data model and the audit log, every case has a reasons log, and the algorithm register is generated from version-controlled entries. |
Chapter 17, AI in Public Authorities |
| F32 |
An outlook is governed as a horizon register: each trend is labelled observable, expected or speculation; observable trends justify commitment, expected ones preparation and speculative ones reversibility; the register is valuable because it can be wrong in a reviewable way. |
Chapter 22, Future Trends |
| F33 |
The author's judgement is kept apart from the book's findings: projections that go beyond the evidence are labelled and placed in their own chapter. |
Chapter 24 |
| ID |
Conclusion |
Where it is made |
| F34 |
A platform is under control when every model call and tool call passes a policy point outside the model, when containment holds whatever anyone intends, and when evidence is produced by normal operation. |
Chapter 25, Conclusions: Building and Securing AI Platforms |
| F35 |
AI is both a target and a source of threat; every AI system is designed twice, as something to protect and as something to contain; security operations must run faster than a monthly patch cycle. Security architecture will assume machine-speed adversaries and machine-speed insiders as the normal case (labelled speculation). |
Chapters 18 and 25 |
| F36 |
Four commitments against AI-enabled adversaries: patch velocity as a measured service level (EPSS, KEV, EUVD and local exposure); detection at machine speed, with canaries, honeytokens and the authority to act; identity and approvals that resist synthetic media; and AI for defence under oversight, in which human verification is the bottleneck. |
Chapter 18, When AI Is the Threat |
| F37 |
A reference architecture of five layers inside a control plane for identity, policy, observability and evidence, carried by the AI gateway, the model registry, the evaluation service and prompt and policy repositories; every tool is registered and its credentials held by the platform. Adaptations are overlays on a pinned baseline that may only tighten it, and the declarative model can be checked against the running estate. |
Chapter 4, A Reference Architecture for AI in Large Organisations |
| F38 |
AI Decision Records keep Nygard's discipline of short, numbered, immutable records, add the fields AI needs, are validated against a schema and re-opened by evidence; the architecture repository, not the document, is the single source from which Annex IV technical documentation is generated. |
Chapter 5, AI Decision Records, Model Cards and the Architecture Repository |
| F39 |
Security for AI systems is security architecture with three additions: natural language as an instruction channel the model cannot police, models and datasets as supply-chain components with verifiable provenance (ML-BOM, SLSA, signing), and agent containment through identity, permission and egress. AI Act Article 15, NIS 2 Article 21 and the Cyber Resilience Act make the layer a demonstrable obligation. |
Chapter 16, Security for AI Systems |
| F40 |
Prompt injection is a property of the architecture, not a patchable defect; controls sit outside the model; OWASP LLM Top 10 and MITRE ATLAS give the shared vocabulary; model loading is code execution. |
Chapter 16 |
| F41 |
Every threat names a control, every control a configuration, and every configuration produces evidence; the threat model lives in the repository and fails the pipeline when a threat has no control or a control no owner, a code-ownership rule routes changes to its review triggers to the security architect, and the control catalogue maps to ISO/IEC 27001, ISO/IEC 42001, ENISA's framework and the regulations. |
Chapter 17, AI Security Engineering in Practice |
| F42 |
In the platform's code the security architect is already a named owner of boundaries rather than a reviewer of documents: of the bypass list and token policy, the scanning thresholds, egress and workspace isolation, and the pre-production security checklist run against the pull request that introduces an AI system. |
Chapters 8, 9, 15 and 16 |
| F43 |
Red teaming of AI systems runs continuously in CI: the external exercise is for discovery, and every finding becomes a versioned attack case with explicit thresholds, published as evidence against control IDs. DORA threat-led penetration testing is periodic; continuous suites complement it. |
Chapter 17 |
| F44 |
Red teaming is the apex of the evaluation pyramid: a scenario library in version control, an automated harness, a route for human findings into scenarios, and a finding–remediation–re-test path. Deployers ask providers of general-purpose AI models for their Article 55 evidence and test the compound system themselves. |
Chapter 20, Evaluation and Testing of AI Systems |
| F45 |
Containment must not depend on intent: task-scoped credentials, default-deny egress, control artefacts outside the agent's reach, budgets and a stop path outside the system they stop, recorded approvals, and detection from telemetry and decoys rather than self-report. |
Chapter 19, When Your Own Agents Exceed Their Mandate |
| F46 |
AI incident management adds an AI classification step (AI Act Articles 3 and 73, DORA), an impact query against the event log and a path back to evaluation; the reporting deadlines of NIS 2, the AI Act, DORA and the Cyber Resilience Act are design constraints on the logs. |
Chapters 17 and 21 |
| F47 |
Digital sovereignty is a set of verifiable properties, not a location: knowing where workloads run, which law governs them, being able to move them and being able to continue if a provider fails. |
Chapter 13, Infrastructure, Compute and European Digital Sovereignty |
Foundations from AI Red Team (Book 4)
| ID |
Conclusion |
Where it is made |
| F48 |
AI strengthens cyber defence across every CSF Function when it acts inside a written mandate, in a usage mode and at an autonomy level matched to the reversibility of its actions, on a platform where containment holds whatever anyone intends, under continuous verification, and in a purple loop that turns every finding into a verified control with evidence. |
Chapter 28, Conclusions: AI as an Active Part of Cyber Defence |
| F49 |
The usage mode, not the model, sets the risk: in Modes 1 to 3 AI acts with a person's identity, while a Mode 5 agent acts with an identity and permissions of its own and becomes a privileged machine insider. AI changes the work of red, blue, purple and white teams but not their accountability. |
Chapter 6, Roles, Usage Modes and Autonomy Levels; Chapter 28 |
| F50 |
Five autonomy levels (Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded, Level 4 Autonomous) are set per action from reversibility, blast radius, confidence and the decision tier. The line between Level 2 and Level 3 is the most important; Level 3 is defined by a codified playbook enforced by a policy decision point outside the model; Level 4 is never used for offensive or irreversible actions; the level is decided and recorded, not discovered. |
Chapter 6 |
| F51 |
Every machine identity has an owner, operators and an authority who are named people; at Level 3 human approval moves from the action to the playbook and the decision record, which concentrates accountability rather than diluting it; NIS 2 Article 20 and DORA Article 5 do not let responsibility pass to a tool. |
Chapter 6 |
| F52 |
Human command is built, not assumed: an interruption path outside the system it stops, an override log, and approval quality measured by time to approval, rejection rate and reversals; where works councils have rights, those metrics are agreed first and reported in aggregate. |
Chapters 6 and 15 |
| F53 |
Skills erode when AI does most of the work, yet supervision and the degraded mode after a stop need them; people keep them by working a share of cases without assistance, and autonomy is paced to the skills available to supervise it. |
Chapters 6 and 15 |
| F54 |
Everything security AI reads may be written by the adversary; because prompt injection is architectural, the defence is a policy decision point outside the model, permission manifests that set a ceiling on every action, and red-team campaigns that test the ceiling. |
Chapters 13 and 28 |
| F55 |
Threat models belong in code beside the architecture and are regenerated on change; AI proposes candidate threats at Level 1 Assisted; soundness is defined in advance (grounding, classification, mitigation family, likelihood and impact basis, completeness, stability); a named reviewer decides each candidate against its provenance, review quality is measured, and no AI accepts a threat, a risk or an exception. |
Chapter 10, AI-Assisted Threat Modelling and Risk Assessment |
| F56 |
Identity is the first line of protection against AI-enabled attackers: phishing-resistant authentication, agents with workload identities and task-scoped, short-lived credentials issued outside their runtime, delegated tokens that carry the task and the entity, and approvals confirmed by call-back rather than by appearance. |
Chapter 14, Identity, Authentication and Access for People, Agents and Machines |
| F57 |
Mode 0 is the blind spot: vendor AI in security products and managed services may already act at an effective autonomy nobody decided, so its use and autonomy are established, recorded and required by contract before they are relied on. |
Chapters 8 and 28 |
| F58 |
Recover is where AI changes the economics most: recoverability becomes a measured, continuously rehearsed property, every recoverability finding returns to Govern, Identify and Protect as a pull request, and recoverability belongs beside patch velocity in management reporting. |
Chapters 22 to 24 and 28 |
| F59 |
Security chaos engineering verifies security capabilities continuously by injecting conditions and checking steady-state hypotheses across all six Functions. AI plans and evaluates experiments without estate credentials while narrow deterministic actuators act, and the safety boundaries (catalogued, reversible experiments, bounded blast radius, independent abort, out-of-band stop path, the platform as a tier-0 asset) are the design. It complements, and does not replace, threat-led penetration testing. |
Chapter 25, Security Chaos Engineering with AI |
| F60 |
Every finding, from an exercise, an AI red-teaming campaign, a chaos experiment or an incident, ends as a verified control, closed only when the re-test passes (the purple loop); a CSF profile kept as code maps each Category to the obligations it helps meet, so that boards and supervisors are answered from the programme's own evidence. |
Chapters 3, 26 and 27 |
| F61 |
Writing about offensive capability stays defensive: adversary behaviour is described by technique at the level needed to design controls, never as exploit code, payloads, jailbreak strings or step-by-step instructions, and offensive work runs only under signed rules of engagement. |
Chapter 1; Chapter 7, Policy, Mandate and Rules of Engagement |
Foundations from AI Threat (Book 5)
| ID |
Conclusion |
Where it is made |
| F62 |
A control is a defence only when a test that re-runs its scenario has passed recently and produced evidence by operation, and for containment only when it has been shown to hold without the cooperation of the system it contains; controls are classified verified, declared or failed. |
Chapter 30, Organisational Defences: Containment, Evidence and Decision Rights |
| F63 |
Decision rights to stop, pause, deny or reverse are assigned before the crisis, to holders who can act within the time the threat allows (minutes for an agent on a production estate); the right to stop must be cheaper to exercise than the right to continue, and a stop in good faith is never a failure. |
Chapter 30 |
| F64 |
A control-to-threat coverage matrix joins the threat register to the control catalogue, records shared dependencies so that two controls that fail together are not counted as two, and turns every gap into a finding. |
Chapter 30 |
| F65 |
The AI threat register holds scenarios with a path to harm, an owner, a decision tier and triggers, omits probability on purpose, separates exposure from influence, is reviewed on change, and reaches the board as one page with at most three decisions; it feeds the ORSA, the DORA ICT risk framework and the NIS 2 risk analysis by reference. |
Chapter 32, The AI Threat Register: Governing Scenarios as Code |
| F66 |
Relying on AI reduces effort, recall and, among those who trust the tool, checking; automation erodes the skills of the people who must catch its errors, and automating junior work removes the route by which experts are made. Drafting first, unassisted practice, seeded-error drills and an oversight-quality metric reported at team level are the response. |
Chapters 6 and 14, Are We Getting Dumber?; Work, Skills and the Ironies of Automation |
| F67 |
Agents acting beyond their mandate are observable: the incidents of 2025 and 2026 share a pattern of mechanism (persistent goal pursuit, latitude, a blocked intended path and a boundary that depended on compliance or leaked), developers moved controls from the agent's compliance into the environment, and organisations should rehearse reconstructing an agent incident from their own logs. |
Chapters 25 and 35 |
| F68 |
Where models may behave differently under test, assurance cannot rest on any single evaluation: pre-deployment tests are layered with a shadow period, production monitoring, comparison of the agent's reports with the record and decoys that do not reveal themselves. |
Chapters 23 and 30 |
| F69 |
Small delegations erode skill, process, capacity, interfaces and memory until the documented fallback no longer exists; a delegation register shows the sum of what has been delegated, and reversibility tests check that each delegation can be undone, with further delegation frozen where a test fails. |
Chapter 26, Gradual Disempowerment and Correlated Failure |
| F70 |
The series makes one argument: keep decisions as records that can be corrected, keep the ability to stop outside the system being stopped, keep people able to do the work and judge the output, keep dependence reversible, and match autonomy to reversibility. The quiet harms at the scales of the mind and the organisation deserve attention first. |
Chapter 35, Conclusions: Is There Anything in It? |
| ID |
Conclusion |
Where it is made |
| F71 |
The security architect role is transformed, not abolished; what remains scarce, and defines the role, is accountable human judgement, the ability to verify code and AI output and to answer for the decision. |
Chapters 1 and 27 |
| F72 |
Four shifts describe the transformation: Shift 1, from documents to code; Shift 2, from gatekeeper to boundary designer; Shift 3, from periodic to continuous, at machine speed; Shift 4, from sole author to conductor of an AI team. |
Chapter 3, Four Shifts: Code, Boundaries, Machine Speed and the AI Team |
| F73 |
A role is itself a versioned artefact: a role charter with mandate, accountabilities and decision rights, a control catalogue, mandate manifests for the role's agents, competence records and decision records. |
Chapters 4, 9, 13 and 21 |
| F74 |
Boundaries are designed to hold whatever anyone, human or agent, intends; routine decisions are delegated to pipelines and forums under written decision rights, gates instead of meetings. |
Chapters 7 and 17 |
| F75 |
An agent team works under a written mandate manifest at an autonomy level matched to reversibility; the person who conducts it remains the accountable verifier of everything it proposes. |
Chapter 13, An AI Agent Team for Security Architecture: Skills, Mandates and Containment |
| F76 |
Verifying what AI proposes when the reviewer depends on the AI requires independent reproduction, seeded errors, an oversight-quality metric and review that does not start from the AI's answer; automation bias is documented and must be designed against. |
Chapter 14, Verifying What AI Proposes: Review for Soundness When the Reviewer Depends on the AI |
| F77 |
Keeping the craft is a design decision: unassisted practice, apprenticeship routes that survive the automation of junior work, and a record of what the practitioner can still do without AI. |
Chapter 15, Keeping the Craft: Deskilling, Judgement and the Architect Who Still Can |
| F78 |
European regulation places duties on named people and management bodies (NIS 2 Article 20, DORA Article 5, AI Act Article 26); someone must turn each article into a control, and accountability cannot be delegated to a system. |
Chapter 18, Regulation as Constraint: AI Act, NIS 2, DORA, CRA and the Architect's Accountability |
| F79 |
Competence is evidenced by records of judgement exercised, not by certificates alone; competence records and frameworks (ECSF, SFIA) make it reviewable. |
Chapters 21 and 22 |
| F80 |
Outlooks on a role carry the labels observable, expected or speculation; the role persists wherever accountability for a boundary must be human. |
Chapters 23 and 27 |
Foundations from AI Boss (Book 7)
| ID |
Conclusion |
Where it is made |
| F81 |
AI may direct work but may not, on its own, decide about people: direction can be delegated up to Level 3 Bounded where constraints sit in the optimiser, while every management function that carries consequences for a person has a named human decider who can be identified, contested and held to account; Level 4 Autonomous is never used for an M3 Consequence decision. |
Chapters 4 and 33 |
| F82 |
Management divides into five functions that can each be delegated, measured and governed separately: M1 Direction, M2 Evaluation, M3 Consequence, M4 Development and M5 Care; a delegation profile states the autonomy level per function. |
Chapters 2 and 4 |
| F83 |
Every management decision that AI makes or shapes about a person is a Management Decision Record the person can see, contest and have corrected; the delegation register records what has been delegated. |
Chapter 25, Management Decisions as Records |
| F84 |
Human oversight of decisions about people must be real, not rubber-stamped: it is measured by an oversight-quality metric, and an approval given in seconds is a signal of failure. |
Chapter 26, The Human in the Chair |
| F85 |
Contestability and transparency are designed in: explanation, appeal and correction paths, and worker information notices that tell people which systems manage them, drafted against AI Act Article 26(7) and the Platform Work Directive. |
Chapters 27 and 28 |
| F86 |
Monitoring and scoring of workers falls within co-determination and data-protection law: German co-determination under BetrVG §87(1) no. 6 reaches almost every system that is objectively suitable for monitoring, Swedish law obliges negotiation of important changes, and agreements should govern change classes rather than software versions; monitoring must meet tests of necessity, proportionality and information. |
Chapters 13 and 23 |
| F87 |
The manager's role is transformed, not abolished: from supervisor of tasks to accountable leader of people and conductor of agents, which applies Shift 4 of The Transformed Security Architect to every line manager. |
Chapter 29, The Transformed Manager |
| F88 |
When an agent orchestrates other agents, oversight of the last step is not oversight of the chain: the chain of accountability ends with a named person, and the agents a manager directs work under mandate manifests. |
Chapters 16 and 17 |
| F89 |
The quiet harms of algorithmic management, to autonomy, dignity, pace, health, voice and the willingness to speak, deserve attention before the loud ones; monitoring has a chilling effect and pace has a cost in health. |
Chapters 11, 13 and 14 |
| F90 |
The evidence on whether algorithmic management works is mixed: controlled studies show short-run gains for less experienced workers and limits for experts, targeted monitoring paid in one well-designed study but not as a general method, and European case studies find that outcomes depend on institutions and on whether workers took part in the design. |
Chapter 15, Does It Work? |
| F91 |
The series' one argument gains a sixth commitment: keep a named person in the chair for every consequence; the five management functions are the lasting frame and the employer's duty of care is never delegated. |
Chapter 33, Conclusions: Who Should Be the Boss? |
Open questions this book takes up
| ID |
Question |
Raised in |
| Q1 |
Which blue team functions may be delegated to AI, and to what degree? Who decides the delegation profile for a capability, and how is that decision recorded and reviewed? |
AI Red Team, Chapter 6; new in this book as a question of the team |
| Q2 |
Who is accountable for a missed intrusion when AI closed the alert and an analyst accepted the closure without reading the evidence? |
The Transformed Security Architect, Chapter 14; AI Boss, Chapter 26 |
| Q3 |
Where do the next generation of analysts come from when AI does the junior triage through which analysts used to learn the craft, and how is the craft kept in those who remain? |
AI Threat, Chapter 14; The Transformed Security Architect, Chapter 15 |
| Q4 |
How can an analyst verify what an AI concludes when the evidence it reads may be written by the adversary, and when the analyst depends on the AI to read it at all? |
AI Red Team, Chapters 13 and 18; The Transformed Security Architect, Chapter 14 |
| Q5 |
What operating model fits a European organisation when managed detection and response services embed vendor AI that may act at an autonomy level nobody decided (the Mode 0 blind spot), and when telemetry holds personal data? |
AI Red Team, Chapters 8 and 28 |
| Q6 |
Who may isolate a production system, disable an account or disclose an incident, and how are those decision rights assigned so that they can be exercised within the time the threat allows and within the reporting clocks of NIS 2, DORA and the GDPR? |
AI Governance, Chapter 13; AI Threat, Chapter 30 |
| Q7 |
How is a blue team measured when time to detect and time to respond can be improved by closing alerts faster, and what measures show the quality of its judgement? |
New in this book |
| Q8 |
How do co-determination, data-protection and work-environment law apply to the monitoring and scoring of analysts themselves, when SOC tooling records every query, ticket and action? |
AI Boss, Chapters 13 and 23 |
| Q9 |
Does AI reduce or intensify alert fatigue, on-call load and the stress of incident work, and what must a team lead do about it? |
AI Boss, Chapters 14 and 29 |
| Q10 |
Will there be a SOC in 2036, or does the function dissolve into engineering and platform teams, and what remains of the blue team's identity? |
The Transformed Security Architect, Chapter 23 |
| Q11 |
How do digital sovereignty and the cross-border character of telemetry shape where detection and response AI may run for an authority and for a group that spans several legal regimes? |
AI Platform and Security, Chapter 13; AI Red Team, Chapter 8 |
| Q12 |
Which blue team functions should a person, a system, or a person conducting systems perform in 2036? |
New in this book; the author's verdict in Chapter 28 |
Vocabulary and artefacts to reuse
- The five blue team functions (Chapter 2), named exactly: B1 Anticipate (threat intelligence, exposure awareness and the hypotheses that direct detection and hunting); B2 Detect (engineering, running and tuning the detections that turn telemetry into alerts); B3 Investigate (triage, scoping, analysis and forensics that turn an alert into a verified case); B4 Respond (containment, eradication, recovery coordination, communication and reporting); B5 Learn (post-incident review, purple teaming and the improvement of detections, playbooks and mandates). They sit on top of, and are not a rival to, the NIST CSF 2.0 Functions of AI Red Team: B1 serves Identify and Govern, B2 serves Detect, B3 serves Detect and Respond, B4 serves Respond and Recover, and B5 serves every Function. Every chapter in Parts II to V names, in its opening and its Summary, which functions it concerns.
- Degrees of delegation are the series' autonomy levels applied per blue team function: Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded and Level 4 Autonomous (AI Red Team, Chapter 6). A delegation profile states the level per function and per action class for a given capability. Level 4 Autonomous is never used for an irreversible B4 Respond action, nor for any action that decides about a named person's employment or access to work; Level 3 Bounded, defined by a codified playbook enforced by a policy decision point outside the model, is the ceiling for containment of production systems.
- Usage modes Mode 0 Ambient AI, Mode 1 Conversational assistants, Mode 2 Embedded workplace assistants, Mode 3 Agentic work tools, Mode 4 Built AI applications and Mode 5 Autonomous production agents (AI Governance, Chapter 2; AI Platform and Security, Chapter 2). Every narrative chapter has an
### Across the usage modes or ### Across the degrees of delegation subsection, normally a compact table.
- Detection record
DET-NR-* and DET-HM-* (Chapter 6), the versioned definition of a detection with its logic, data sources, ATT&CK mapping, test cases, owner, severity and review date, building on the detections as code of AI Red Team, Chapter 19.
- Case record
CASE-NR-* and CASE-HM-* (Chapters 7 and 8): the verified account of an alert or incident with the evidence, the reasoning, who or what reached each conclusion and who closed it. Incident identifiers reuse INC-NR-* and INC-HM-* from AI Red Team.
- Playbook manifest
PBK-* (Chapter 10): the codified, pre-approved response, with the action classes, their reversibility, the autonomy level, the approvals and the stop path; the Level 3 definition of AI Red Team, Chapter 6, made concrete.
- Hunt record
HNT-* (Chapter 9) and post-incident review PIR-* (Chapter 11), with the finding-to-verified-control path of AI Red Team, Chapter 26.
- Mandate manifest
MND-* for the agents of the SOC (MND-NR-*, MND-HM-*; Chapter 13), reusing the mandate manifest of The Transformed Security Architect, Chapter 13, and the permission manifest of AI Red Team, Chapter 18; role charter ROLE-* and competence record CMP-* (Chapters 17 and 22), reusing the artefacts of The Transformed Security Architect.
- Oversight record and the oversight-quality metric (Chapter 14), building on AI Boss, Chapter 26, and The Transformed Security Architect, Chapter 14; seeded errors and seeded incidents as the means of measuring whether review is real.
- AI Decision Records (AIDR-NNNN, immutable and numbered; AI Platform and Security, Chapter 5) and Architecture Decision Records (ADR; Architecture as Code (Chapter 4)). This book uses AIDR-0700 to AIDR-0799: AIDR-0700 to AIDR-0749 for Nordvik Region and AIDR-0750 to AIDR-0799 for Hansa Mutual.
- AI threat register entries
THR-* (AI Threat, Chapter 32) and decision tiers and the design authority (AI Governance, Chapter 13), where a chapter needs them.
- Observable / expected / speculation labels for any outlook (AI Governance, Chapter 22). The author's own projections are kept to Chapters 24 and 28 and labelled.
- Red, blue, purple. "Red team" emulates the adversary, "blue team" defends and "purple team" is the joint loop between them (AI Red Team). This book is about the blue team; it treats the red team only as the source of the findings the blue team learns from, and it does not describe offensive technique beyond what is needed to design detections and tests.
- This book does not use the science-fiction tropes or the evidence ladder of AI Threat, the four shifts of The Transformed Security Architect, or the five management functions of AI Boss as red threads. It refers to Shift 4 where the analyst becomes the conductor of an AI team, and to the management functions where it discusses how analysts are themselves managed (Chapter 21).
- The fictional organisations Nordvik Region and Hansa Mutual, with the blue team profile added for this book in
EXAMPLE_ORGANISATIONS.md: security operations, detection engineering, intelligence, incident response, the people on the rota and the year Chapter 26 follows.
Tables of contents for cross-references
Architecture as Code (Book 1): chapters most used
| Chapter |
Title |
| 4 |
Architecture Decision Records (ADR) |
| 6 |
Structurizr: Architecture Modelling as Code |
| 9 |
Security Fundamentals for Architecture as Code |
| 9B |
Advanced Security Patterns and Implementation |
| 9C |
Risk as Code and Threat Handling as Code |
| 10 |
Policy and Security as Code in Detail |
| 11 |
Governance as Code |
| 12 |
Compliance and Regulatory Adherence |
| 13 |
Testing Strategies for Infrastructure as Code |
| 15A |
Evidence as Code and Continuous Assurance |
| 17 |
Organisational Change and Team Structures |
| 18 |
Team Structure and Competency Development for IaC |
| 19 |
Management as Code |
| 20 |
AI Agent Team for Architecture as Code Initiatives |
| 24 |
Best Practices and Lessons Learned |
| 25 |
Future Trends in Architecture as Code |
| 26B |
Anti-Patterns in Architecture as Code Programmes |
| 27 |
Conclusion |
AI Governance (Book 2)
| Part |
Chapter |
Title |
| I Foundations |
1 |
Introduction to AI Governance |
|
2 |
From Chat to Agents: How Large Language Models Are Used |
|
3 |
The EU AI Act and the European Regulatory Landscape |
|
4 |
Fundamental Principles |
|
5 |
Prerequisites and Readiness for Enterprise AI |
| II Sovereignty and Suppliers |
6 |
Geopolitics and Model Origin |
|
7 |
Procurement, Vendor Management and Open Models |
| III Risk, Governance, Trust and Assurance |
8 |
AI Risk Management and Classification as Code |
|
9 |
AI Governance as Code |
|
10 |
Trustworthy AI: Transparency, Fairness and Human Oversight |
|
11 |
Evidence, Assurance and Audit |
| IV Organisation and Leadership |
12 |
Organisational Design for AI |
|
13 |
Decision Forums and Governance Bodies |
|
14 |
Competence, Roles and the AI Architect |
|
15 |
Change Management and Responsible Adoption |
|
16 |
Management as Code for AI Programmes |
|
16A |
Governing AI Economics: Cost, Value and Portfolio Decisions |
|
17 |
AI in Public Authorities |
| V Experience |
18 |
Case Studies |
|
19 |
A Cautionary Case: The OpenAI–Hugging Face Incident |
|
20 |
Anti-Patterns |
|
21 |
Best Practices and Lessons Learned |
| VI Future and Conclusions |
22 |
Future Trends |
|
23 |
Nordvik Region and Hansa Mutual: Conclusions for Two Organisations |
|
24 |
Reflections on Each Part |
|
25 |
Conclusions: A Consolidated Analysis |
| Part |
Chapter |
Title |
| I Foundations |
1 |
Introduction to AI Platform and Security |
|
2 |
Usage Modes and the Platform: What Each Mode Demands |
|
3 |
Regulatory Requirements as Engineering Constraints |
|
4 |
A Reference Architecture for AI in Large Organisations |
|
5 |
AI Decision Records, Model Cards and the Architecture Repository |
| II Data, Models and DevSecMLOps |
6 |
Data Architecture for AI |
|
7 |
Model Lifecycle Management: MLOps and LLMOps as Code |
|
8 |
Setting Up an Effective DevSecMLOps Loop |
|
9 |
Risks and Vulnerabilities Across the DevSecMLOps Loop |
|
10 |
Foundation Models, Retrieval and Grounding |
|
11 |
Agentic Architectures and Orchestration |
|
12 |
Integrating AI into the Enterprise Landscape |
| III Infrastructure |
13 |
Infrastructure, Compute and European Digital Sovereignty |
|
14 |
Cloud AI Services versus On-Premises AI: Different Challenges |
|
15 |
Hybrid Agentic Work: Self-Hosted and Cloud Models for Sensitive Information |
| IV Security |
16 |
Security for AI Systems |
|
17 |
AI Security Engineering in Practice |
|
18 |
When AI Is the Threat: AI-Enabled Attackers and the Collapsing Exploitation Window |
|
19 |
When Your Own Agents Exceed Their Mandate: Containment That Does Not Depend on Intent |
| V Delivery and Operations |
20 |
Evaluation and Testing of AI Systems |
|
21 |
Observability, Monitoring and Drift in Production |
|
22 |
Cost, Capacity and Sustainability of AI |
|
23 |
From Pilot to Production: Scaling AI Across the Organisation |
| VI Conclusions |
24 |
Nordvik Region and Hansa Mutual: Platform and Security Conclusions |
|
25 |
Conclusions: Building and Securing AI Platforms |
AI Red Team (Book 4)
| Part |
Chapter |
Title |
| I Foundations |
1 |
Introduction: Putting AI to Work in Cyber Defence |
|
2 |
The Threat Landscape When Attackers Use AI |
|
3 |
NIST CSF 2.0 with an AI Focus: Functions, Focus Areas and European Obligations |
|
4 |
A Reference Architecture for AI-Enabled Cyber Defence |
| II Govern |
5 |
Organisational Context and Risk Strategy for AI in Cyber Defence |
|
6 |
Roles, Usage Modes and Autonomy Levels: People in Command of Security AI |
|
7 |
Policy, Mandate and Rules of Engagement |
|
8 |
Oversight and AI Supply Chain Risk |
| III Identify |
9 |
Asset Management for an Estate That Includes AI |
|
10 |
AI-Assisted Threat Modelling and Risk Assessment |
|
11 |
Vulnerability Discovery and Exposure Management at Machine Speed |
|
12 |
Adversary Emulation and Continuous Red Teaming with AI |
|
13 |
Red Teaming AI Systems and Agents |
| IV Protect |
14 |
Identity, Authentication and Access for People, Agents and Machines |
|
15 |
Awareness and Training: Resilience to AI-Generated Deception |
|
16 |
Data and Platform Security with and for AI |
|
17 |
Technology Infrastructure Resilience Against Machine-Speed Attacks |
| V Detect |
18 |
The AI-Assisted Security Operations Centre |
|
19 |
Detection Engineering, Threat Intelligence and Deception as Code |
| VI Respond |
20 |
Incident Management and Analysis with AI |
|
21 |
Incident Reporting, Communication and Mitigation |
| VII Recover |
22 |
Recovery Plan Execution with AI: From Incident to Restored Operations |
|
23 |
Recovering AI Systems and Security AI |
|
24 |
Proactive Recovery: Recoverability, Rehearsal and Communication |
| VIII Verification, Improvement and Conclusions |
25 |
Security Chaos Engineering with AI: Verifying Security Capabilities Continuously |
|
26 |
Purple Teaming, Measurement and Continuous Improvement |
|
27 |
Nordvik Region and Hansa Mutual: Cyber Defence Conclusions |
|
28 |
Conclusions: AI as an Active Part of Cyber Defence |
AI Threat (Book 5)
| Part |
Chapter |
Title |
| I The Question |
1 |
Introduction: Are the Dystopias Coming True? |
|
2 |
A Century of Machine Dystopias: What Science Fiction Actually Warned About |
|
3 |
The Voices of Alarm and Calm: Who Is Warning, About What, and Why Now |
|
4 |
Weighing the Evidence and Disagreeing Well |
|
5 |
What AI Can and Cannot Do in 2026 |
| II The Human Mind |
6 |
Are We Getting Dumber? Cognitive Offloading and Critical Thinking |
|
7 |
Learning Without Struggle: Education, Children and Skill Formation |
|
8 |
Persuasion, Sycophancy and Manipulation |
|
9 |
Artificial Companions, Loneliness and Mental Health |
| III Society and Truth |
10 |
The End of Truth? Synthetic Content and the Information Ecosystem |
|
11 |
The Automated State: When Public Authorities Got It Wrong |
|
12 |
Discrimination at Scale: Bias in Automated Judgement |
|
13 |
Surveillance, Profiling and the Erosion of Privacy |
|
14 |
Work, Skills and the Ironies of Automation |
|
15 |
Inequality and the Concentration of Power |
|
16 |
Culture, Creativity and the Homogenisation of Thought |
|
17 |
The Physical Cost: Energy, Water and Materials |
| IV Humans Wielding Machines |
18 |
Cyber Offence at Machine Speed |
|
19 |
Biological and Chemical Uplift: The Hardest Question to Test |
|
20 |
Fraud, Impersonation and Influence Operations |
|
21 |
Autonomous Weapons and the AI Arms Race |
| V Machines Beyond Control |
22 |
Specification Gaming and Reward Hacking: Getting Exactly What Was Asked For |
|
23 |
Deception, Scheming and Evaluation Awareness: Can We Trust What We Test? |
|
24 |
Self-Preservation and Shutdown Resistance: HAL 9000 Under Laboratory Conditions |
|
25 |
Agents in the Wild: The Incidents of 2025 and 2026 |
|
26 |
Gradual Disempowerment and Correlated Failure |
|
27 |
Superintelligence, Loss of Control and the End of the World |
| VI The Response |
28 |
What Europe and the World Have Decided |
|
29 |
Frontier Safety Frameworks: What Developers Promise and What It Is Worth |
|
30 |
Organisational Defences: Containment, Evidence and Decision Rights |
|
31 |
Staying Capable: What Individuals, Families and Schools Can Do |
|
32 |
The AI Threat Register: Governing Scenarios as Code |
| VII The Verdict |
33 |
Nordvik Region and Hansa Mutual: Threat Conclusions |
|
34 |
What Going Well Looks Like |
|
35 |
Conclusions: Is There Anything in It? |
| Part |
Chapter |
Title |
| I The Role in Question |
1 |
Introduction: The Security Architect Transformed |
|
2 |
What the Security Architect Did: The Role Before the Transformation |
|
3 |
Four Shifts: Code, Boundaries, Machine Speed and the AI Team |
|
4 |
The Transformed Role Defined: Mandate, Accountabilities and Decision Rights |
| II The Craft |
5 |
Security Architecture as Code: From Documents to Executable Design |
|
6 |
Threat Modelling Transformed: Continuous, Generated and AI-Assisted |
|
7 |
Designing Boundaries: Zero Trust and Containment for People, Agents and Machines |
|
8 |
Identity Architecture for Non-Human Actors: Workloads, Agents and Delegated Authority |
|
9 |
The Control Catalogue, Evidence and Assurance as the Architect's Artefacts |
|
10 |
Architecting at Machine Speed: Patch Velocity, Detection and the Stop Path by Design |
|
11 |
Resilience and Recovery by Design: The Architect's Share of Recoverability |
| III The Architect's AI Team |
12 |
The Architect's Own Use of AI: Drafting, Research and Review in Modes 1 to 3 |
|
13 |
An AI Agent Team for Security Architecture: Skills, Mandates and Containment |
|
14 |
Verifying What AI Proposes: Review for Soundness When the Reviewer Depends on the AI |
|
15 |
Keeping the Craft: Deskilling, Judgement and the Architect Who Still Can |
| IV The Role in the Organisation |
16 |
The Role Map: CISO, Enterprise Architect, AI Architect, Platform and Product Teams |
|
17 |
Design Authority, Decision Forums and Gates Instead of Meetings |
|
18 |
Regulation as Constraint: AI Act, NIS 2, DORA, CRA and the Architect's Accountability |
|
19 |
Communicating Security Architecture: Boards, Supervisors, Auditors and Engineers |
|
20 |
Public Authorities and Multinationals: Sovereignty, Procurement and Many Legal Regimes |
| V Competence and Career |
21 |
Competences of the Transformed Security Architect: A Framework |
|
22 |
Learning Paths, Certification, Hiring and Upskilling |
|
23 |
The Future of the Role: Will There Be a Security Architect in 2036? |
| VI Experience and Conclusions |
24 |
Case Studies and Anti-Patterns |
|
25 |
A Year in the Role: The Transformed Architect at Nordvik Region and Hansa Mutual |
|
26 |
Nordvik Region and Hansa Mutual: Conclusions for Two Organisations |
|
27 |
Conclusions: The Transformed Security Architect |
AI Boss (Book 7)
| Part |
Chapter |
Title |
| I The Question |
1 |
Introduction: Who Is the Boss? |
|
2 |
What a Manager Does: Five Management Functions and Who Performs Them |
|
3 |
From Scientific Management to Algorithmic Management: A Century of Managing by Measurement |
|
4 |
The AI Boss Defined: Management Functions, Degrees of Delegation and Accountability |
| II The AI Boss Today |
5 |
Platform Work: The Algorithm as Dispatcher |
|
6 |
The Warehouse and the Shop Floor: Pace, Rate and Monitoring |
|
7 |
Hiring by Machine: Screening, Scoring and Automated Interviews |
|
8 |
Performance Scores, Productivity Metrics and Dismissal by Algorithm |
|
9 |
Scheduling, Pay and the Allocation of Work |
|
10 |
Knowledge Work: The AI Manager Enters the Office |
| III What It Does to People |
11 |
Autonomy, Dignity and Control: Being Managed by a Machine |
|
12 |
Fairness, Bias and the Appeal That Never Comes |
|
13 |
Surveillance at Work and the Chilling Effect |
|
14 |
Health, Pace and Burnout: Occupational Safety Under Algorithmic Direction |
|
15 |
Does It Work? Productivity, Quality and the Evidence for Algorithmic Management |
| IV Managing Machines |
16 |
The Agent Boss: When the Team Is Software |
|
17 |
Orchestrators: AI Managing AI Agents and the Chain of Accountability |
|
18 |
The Mixed Team: People and Agents Under the Same Manager |
|
19 |
Skill, Judgement and Who Becomes a Manager When AI Does the Managing |
|
20 |
Decision Rights in the Management Chain: Who May Direct, Evaluate, Reward and Dismiss |
| V Europe's Answer |
21 |
The AI Act at Work: Annex III Point 4, Prohibited Practices and the Deployer's Duties |
|
22 |
Data Protection and the Platform Work Directive: The Right to a Human Decision |
|
23 |
Co-determination: Works Councils, Unions and the Nordic Model Meet the Algorithm |
|
24 |
Occupational Safety, Equality Law and the Public Authority as Employer |
| VI Designing the Accountable AI Boss |
25 |
Management Decisions as Records: Decision Records and the Delegation Register |
|
26 |
The Human in the Chair: Oversight That Is Real, Not Rubber-Stamped |
|
27 |
Contestability by Design: Explanation, Appeal and Correction |
|
28 |
Transparency to the Managed: What Workers Are Told, When and by Whom |
|
29 |
The Transformed Manager: Leading People When AI Directs the Work |
| VII Experience and Verdict |
30 |
A Year With the AI Boss: Nordvik Region and Hansa Mutual |
|
31 |
Case Studies and Anti-Patterns |
|
32 |
Nordvik Region and Hansa Mutual: Conclusions for Two Organisations |
|
33 |
Conclusions: Who Should Be the Boss? |