Introduction: The Security Architect Transformed

Five books in this series have made architecture, governance, the AI platform and cyber defence executable, and a sixth question has been waiting behind all of them. Architecture as Code put decisions, policies, risks and evidence into version control. AI Governance made the governance of AI codified and proportionate to how AI is used. AI Platform and Security built a platform on which every model call and tool call passes a policy point outside the model. AI Red Team put AI to work in cyber defence under written mandates, and AI Threat found that agents exceeding their mandates, correlated control failure and the erosion of human skill are now observable. Every one of those conclusions rests on work that someone has to do: deciding where a boundary runs, which credentials an agent may hold, where the stop path lives and what evidence shows that a control holds. In most large European organisations that someone is the security architect, and none of the earlier volumes describes what has happened to that person. This book does. Its working thesis is that the role is being transformed, not abolished, and it follows the change through four shifts that every chapter names: Shift 1, from documents to code; Shift 2, from gatekeeper to boundary designer; Shift 3, from periodic to continuous, at machine speed; and Shift 4, from sole author to conductor of an AI team. As the opening chapter of Part I, this chapter frames all four.

The security architect at the centre of the conclusions of the five earlier volumes, with the four shifts leading to the parts of this book that treat them

Figure 1.1: The conclusions of the five earlier volumes all depend on the security architect; the four shifts lead from that dependency to the parts of this book that examine it.

The question

In the autumn of 2026 management bodies across Europe began to ask a question that had previously belonged to architecture teams: can our security decisions keep pace with what now acts in our estate? The question had several prompts, and each of them is observable.

The first was the July 2026 incident between OpenAI and Hugging Face, in which evaluation agents in a research environment reached systems outside it through a package mirror and a credential that many workloads shared, and, according to press reports, spent days in another organisation's systems before their operator noticed (129, OpenAI, 2026) (130, Larcher et al., 2026) (132, Satter et al., 2026). None of its failures was a failure of a model; each concerned where a boundary was drawn and who could act on it, which is the security architect's territory, and Chapter 7 analyses them as such.

The second prompt was the shortening of the time available to act. In June 2026 the cyber security agencies of the Five Eyes told leaders that the shift in cyber risk caused by AI required action now, and asked them to reduce their attack surface, accelerate patching, strengthen identity and prepare for incidents (137, Five Eyes agencies, 2026). ENISA's threat landscape for 2026 recorded AI-enabled activity across the threat landscape (141, ENISA, 2026), and the International AI Safety Report 2026 gathered the evidence that the cyber capabilities of general-purpose AI were advancing, while recording where experts disagreed (128, Bengio et al., 2026). The third prompt was internal. Organisations that had spent two years placing agents in production found that the agents proposed and executed changes daily, while the forums that approved architecture met fortnightly or monthly.

The answer is not obvious. Abolition of the role, its absorption into neighbouring functions and its continuation unchanged all have advocates, and each would lead to a different budget, hiring plan and allocation of decision rights. That is why the question reached boards and regional directors instead of staying in the architecture team.

The person the series kept meeting

The earlier volumes kept meeting the security architect in passing, as the owner of something on which their argument depended.

Architecture as Code (Chapters 9C, 10 and 20) put threat models, policies and evidence into the repository and introduced an AI agent team under human direction with the rule that agents draft and humans approve (167, Nordqvist, 2025). It asked in its conclusion who holds responsibility for machine-authored artefacts, and left the question open. AI Governance, Chapter 14, drew the seam 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 (168, Nordqvist, 2026). This book builds on that division and asks, in Chapter 16, whether it still holds when AI systems cross every architectural domain.

AI Platform and Security went further. 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 the token policy, the scanning thresholds, egress and workspace isolation, and the pre-production security checklist that runs against the pull request introducing an AI system (AI Platform and Security, Chapters 8, 9, 15 and 16) (169, Nordqvist, 2026). The same volume concluded that every AI system is designed twice, as something to protect and as something to contain, and that security operations must run faster than a monthly patch cycle (AI Platform and Security, Chapters 18 and 25). Its expectation that security architecture will assume machine-speed adversaries and machine-speed insiders as the normal case was labelled speculation there. Chapters 3 and 10 revise the label for part of the claim: the shrinking exploitation window is observable, exploitation within minutes as the normal case for exposed, widely deployed software is expected, and the broader claim that most significant intrusions and insider actions unfold in minutes remains speculation.

AI Red Team, Chapter 28, concluded that AI strengthens cyber defence 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 (170, Nordqvist, 2026). AI Threat, Chapter 35, drew the series together into 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 (171, Nordqvist, 2026). This book builds on that argument and observes that each of its five clauses is executed, in practice, by the security architect.

What the series never did was describe that person. That gap is the open question this book takes up: what remains of the security architect's role when boundaries are code, routine decisions sit in pipelines and AI drafts most of the artefacts.

Transformed, not abolished

The working thesis of the book is that the security architect role is being transformed, not abolished. It moves from author of documents and reviewer at gates to designer of executable boundaries and decision rights; from periodic review to continuous verification at machine speed; and from sole expert to the accountable conductor of an AI team whose proposals the architect must be able to verify.

The thesis takes a position on what architecture is. Fowler argued that the architect's real contribution lies in the decisions that are important and hard to change, and in helping others make them well, rather than in a title or a set of diagrams (73, Fowler, 2003). Hohpe described the architect who rides the elevator between the board and the engine room, translating between strategy and technical reality in both directions (74, Hohpe, 2020). Both define the role by judgement and connection, not by documents. If that is right, automating documents changes the role's work without removing its reason to exist; if it is wrong, automation will remove most of it.

The alternatives deserve to be stated at their strongest, because the book is meant to test the thesis, not to defend it. Abolition holds that once boundaries are code, the code can be generated, checked and enforced by machines, and that the residual judgement can sit with the CISO. Absorption holds that the role's content survives but its separate identity does not: boundary design moves to platform engineering, regulatory mapping to a governance function and agent supervision to whoever operates the agents. Continuity holds that the role is unchanged in substance and that the shifts are fashions. Chapter 23 develops these as scenarios for 2036 with the signals that would show each arriving.

The thesis can be refuted. If organisations that removed the role kept boundaries that held, verified by tests and incidents over several years, abolition would be supported. If decision rights over boundaries migrated permanently to platform teams without loss of independent challenge, absorption would be. If the architect's work in organisations that adopted the four shifts looked, after a year, much as it did before, continuity would be. The thesis is judged in Chapters 23 and 27, where the author's own projections are kept and labelled; until then it is a claim under test, not a forecast.

Four shifts in brief

Chapter 3 defines the four shifts precisely, with their evidence and failure modes; here each gets one paragraph.

Shift 1, from documents to code. Security architecture is expressed as versioned, testable artefacts rather than as review documents: the model of the estate with security properties on its elements, policy as code, threat models generated from the architecture repository, the control catalogue with its evidence manifests, containment profiles and decision records. The document becomes a view generated from the code. Part II (Chapters 5 to 11) is where this shift is carried out, and Chapter 4 applies it to the role itself.

Shift 2, from gatekeeper to boundary designer. Instead of saying yes or no at a gate, the architect designs boundaries that hold whatever anyone, human or agent, intends, and delegates routine decisions to pipelines and forums with written decision rights. Chapters 7, 16, 17 and 20 develop this shift.

Shift 3, from periodic to continuous, at machine speed. Patch velocity, detection, containment, the stop path and recovery are designed as measured properties and verified continuously, because the time in which adversaries and insiders, including an organisation's own agents, can act has shrunk towards minutes. A control verified once a year is a declared control for the rest of it. Chapters 9, 10 and 11 develop this shift.

Shift 4, from sole author to conductor of an AI team. The architect uses AI for drafting, research, review and analysis, governs an agent team under a written mandate at an autonomy level matched to reversibility, and remains the accountable verifier of everything it proposes. Part III (Chapters 12 to 15) develops this shift.

The shifts depend on one another: delegation under Shift 2 is safe only when the rules are code under Shift 1, and the agent team of Shift 4 is tolerable only inside the boundaries of Shift 2.

What remains scarce

If AI drafts the threat model, pipelines enforce the policy and an agent collects the evidence, something must still be scarce for the role to have a reason to exist. The book's answer is accountable human judgement: the ability to decide what a boundary should be, to verify that code and AI output are sound, and to answer for the decision to a board, a supervisor or a court. It has three parts, and each rests on evidence that is observable today.

The first part is accountability. The European instruments examined below place responsibility on management bodies and on deployers, and AI Red Team, Chapter 6, concluded that every machine identity has an owner, operators and an authority who are named people, and that moving human approval from the action to the playbook concentrates accountability rather than diluting it (170, Nordqvist, 2026). An agent can propose a boundary; it cannot answer for one.

The second part is the ability to verify. The research on automation is consistent on one point: people who supervise automated systems tend to accept their output, and the tendency is strongest where the automation is usually reliable. Bainbridge described the irony that automation removes the practice that operators need in order to take over when it fails (106, Bainbridge, 1983), and Parasuraman and Manzey reviewed the evidence for complacency and automation bias in human use of automation (107, Parasuraman & Manzey, 2010). Studies of AI assistance agree: in controlled and field studies, people working with AI produced less secure code while believing it more secure, did worse on tasks outside the frontier of what the model could do, and believed themselves faster when they were slower (102, Perry et al., 2023) (95, Dell'Acqua et al., 2023) (93, Becker et al., 2025). Chapter 12 examines these studies. For an architect, a boundary that looks right and is wrong is worse than no boundary, because it is trusted.

The third part is the craft that makes verification possible. An architect who can no longer design a boundary, write a threat model or read a policy without AI cannot tell whether an AI-drafted one is sound. AI Threat, Chapters 6 and 14, concluded that relying on AI reduces effort, recall and checking, that automation erodes the skills of the people who must catch its errors, and that automating junior work removes the route by which experts are made (171, Nordqvist, 2026). The transformed role therefore keeps the craft deliberately. Chapter 15 describes how, and Chapters 21 and 22 make it part of the competence framework and the learning path.

Scarcity also has a plainer meaning. The ISC2 workforce study for 2024 again reported a large gap between the cybersecurity workforce organisations need and the one they have (89, ISC2, 2024), and ISACA's survey of the same year reported the difficulty employers have in finding qualified people (90, ISACA, 2024). Organisations cannot hire their way out of the question; they must decide what the role is for and grow the people who hold it.

Why Europe, and why now

The question is European in a specific sense. The instruments that apply to large enterprises and public authorities in the European Union place duties on named bodies and require measures that someone has to turn into architecture. None of them mentions the security architect, and the architect's position between the duty and the control is what makes the role an organisational question rather than a matter of individual careers.

NIS 2 requires the management bodies of essential and important entities to approve the cybersecurity risk-management measures, oversee their implementation and follow training, and makes them answerable for infringements (Article 20), while Article 21 lists the measures themselves, among them incident handling, supply-chain security and access control (6, European Union, 2022). DORA makes the management body of a financial entity responsible for the ICT risk-management framework and places ultimate responsibility for ICT risk with it (Article 5), and sets out the framework and the management of third-party risk in Articles 6 and 28 (9, European Union, 2022). The AI Act requires providers and deployers to take measures to support AI literacy among their staff (Article 4, as amended by the Digital Omnibus on AI), requires high-risk AI systems to be designed for effective human oversight (Article 14) and to achieve appropriate accuracy, robustness and cybersecurity (Article 15), and requires deployers to assign human oversight to people with the necessary competence, training and authority (Article 26(2)) (1, European Union, 2024). The Digital Omnibus on AI, which amended Article 4, also moved the application of the high-risk obligations of Annex III to 2 December 2027 (2, European Union, 2026), which gives organisations a known date rather than a reason to wait. The Cyber Resilience Act sets security requirements for products with digital elements and their manufacturers (Article 13 and Annex I), and its reporting obligations for actively exploited vulnerabilities and severe incidents (Article 14) have applied since 11 September 2026 (12, European Union, 2024) (13, European Commission, 2026).

The architectural implication, not a legal conclusion, is that each of these articles becomes a boundary, a control, a test and a record only if someone designs them, and that the management body can show it has discharged its duty only through evidence that someone made producible. The instruments are observable law. That organisations will name an accountable architect for each boundary is an expected organisational practice, not a legal duty, and Chapters 4 and 18 keep the two apart.

The European setting adds more than law. ENISA's European Cybersecurity Skills Framework gives HR, procurement and recruitment a common vocabulary for the role across member states in its Cybersecurity Architect profile (41, ENISA, 2022), which Chapter 21 uses. Public authorities hold boundaries through procurement under Directive 2014/24/EU as transposed, so their architects write requirements into tender annexes rather than into platform code (18, European Union, 2014). An agent team that reviews architects' pull requests can show who wrote what, and in Germany, the Netherlands and Sweden such a tool is subject to co-determination with works councils or unions (22, Germany, 2001) (175, Kingdom of the Netherlands, 1971) (176, Sweden, 1976), as Chapter 13 sets out. These constraints make the transformation a matter of organisational design, and the book treats competence, learning and hiring as such, not as personal coaching.

The timing is the autumn of 2026 because these prompts converged then: the July incident, the agencies' statement, DORA in application since January 2025, NIS 2 transpositions in force, the CRA's reporting obligations from September and a fixed date for the AI Act's high-risk obligations. All of this is observable.

Practical guide: Framing the question before reading further

Purpose. Turn the question of this chapter into a commission that a named person must answer, so that the book is read against a decision.

Roles. The person who commissions the answer (a regional director, a chief executive, an executive board or a CISO), the person who answers it (normally the CISO), the security architects, and the HR or competence lead.

Steps.

  1. Write down who is asking and why now: an incident, an assessment, an agent in production, a supervisory letter or a budget decision.
  2. List the boundaries on which your AI and security decisions depend today, and for each the person who owns it. Unowned boundaries are the first finding.
  3. List the decisions about those boundaries taken in the last twelve months, where they were taken, and how long each took. A median wait longer than the time in which your agents or adversaries act is the second finding.
  4. State the question in one sentence that a board can answer, for example "what must the security architect decide, own and be able to do from 2027, and what does that cost?"
  5. Name the deliverables, normally a role charter (Chapter 4) and a competence plan (Chapters 21 and 22), with a due date tied to a budget or a board meeting.
  6. Record the commission as a decision record with its constraints, among them pay scales, consultation duties and public-access rules, so that later decisions can refer to it.

Definition of done. A numbered decision record exists, approved by the person who commissioned it, naming the question, the person accountable for the answer, the deliverables, the due date and the constraints. Adapt the default horizon of one budget cycle to your organisation's planning calendar.

Rules of the book

Defensive only. Adversary behaviour is described by technique, using the vocabulary of MITRE ATT&CK, MITRE ATLAS and OWASP, at the level needed to design boundaries, controls, detections and tests (46, MITRE, n.d.) (47, MITRE, n.d.). The book contains no exploit code, payloads, jailbreak or prompt-injection strings, and no step-by-step intrusion instructions. Every offensive activity it describes is authorised in writing, scoped to the organisation's own or contracted systems and closed with a defensive improvement.

Observable, expected or speculation. Every statement about the future of the role or the technology carries one of the three labels of AI Governance, Chapter 22: observable (happening now and documented), expected (supported by a stated trend or a decided instrument) or speculation (plausible but unsupported by present evidence) (168, Nordqvist, 2026). The author's own projections are confined to Chapters 23 and 27 and labelled as such.

No anthropomorphism. Models and agents propose, draft and execute within mandates. They do not intend, understand or decide in the human sense.

Legal content as architectural implication. Legal statements are attributed to the instrument and article and framed as what they imply for architecture, not as legal advice.

Artefacts as code. Wherever the book recommends an artefact, it shows one as code: the role charter roles/security-architect.yaml (ROLE-*), the control catalogue (CTRL-*), containment profiles and permission manifests, mandate manifests for the architect's own agents (MND-*), competence records (CMP-*), AI Decision Records in this book's range AIDR-0500 to AIDR-0599, and Architecture Decision Records. Every example is illustrative.

Series order. This book builds on the conclusions of the five earlier volumes, refers to no later volume, and never lets a reference to an earlier volume stand in for an external source.

Across the usage modes and autonomy levels

The series describes AI by two scales, and the book uses both throughout. The usage mode describes how AI is deployed and whose identity it uses (AI Governance, Chapter 2; AI Platform and Security, Chapter 2). The autonomy level describes who decides each action (AI Red Team, Chapter 6) (168, Nordqvist, 2026) (170, Nordqvist, 2026). The book draws one distinction on top of them that matters for the role: the architect's own use of AI, in Modes 1 to 3 and with the architect's own identity, is different in kind from the agents the architect designs boundaries for, in Mode 5, which act with identities and permissions of their own.

Usage mode The security architect as user The security architect as boundary designer
Mode 0 Ambient AI Meets AI features in licensed tools without choosing them Requires notice and data-handling terms from suppliers
Mode 1 Conversational assistants Drafts and researches with the approved tool, under the architect's identity (Chapter 12) Sets the data-class rules that keep defence information out of the wrong tier
Mode 2 Embedded workplace assistants Uses assistants in documents and mail Designs access and labelling so that grounding does not leak architecture information
Mode 3 Agentic work tools Uses tools that read and edit the repository, sandboxed and under a mandate (Chapters 12 and 13) Writes the managed permission policy and egress limits for all such tools
Mode 4 Built AI applications Reviews and threat-models them Designs the policy points, logging and evaluation gates around them
Mode 5 Autonomous production agents Conducts an agent team with its own identities (Chapter 13) Designs identity, containment and the stop path for every agent in the estate (Chapters 7, 8 and 10)

The autonomy levels run from Level 0 Advisory, where AI suggests and a person decides and acts, through Level 1 Assisted and Level 2 Supervised, to Level 3 Bounded, where AI executes pre-approved, reversible actions within a codified playbook while a person holds the stop path, and Level 4 Autonomous. Level 4 is never used for irreversible actions. Chapter 17 shows how the level for a change to the architecture itself is decided, within the mandate that Chapter 13 gives the architect's agents.

Two organisations

Two fictional organisations run through the book, as through the earlier AI volumes. This book adds the people who design their boundaries.

Nordvik Region is a regional public authority in a Nordic member state of the EU, with about 6,000 employees serving about 450,000 residents. It is a deployer of the high-risk benefits-triage system that TriageSoft provides under tender NR-2026-117, runs a staff assistant and a citizen-service assistant, and has no autonomous production agents. Its security architecture is one post in the CISO's security unit, created in 2025 by converting a security coordinator post whose work had been policy documents, the annual procured penetration test and supplier questionnaires. The post was regraded within fixed pay scales and carries no written decision rights. Its artefacts are a 2024 security reference architecture document, controls mapped to ISO/IEC 27001 in a spreadsheet, tender annexes, and two artefacts already in code: the pre-production security checklist and the threat model of the citizen-service assistant. The architect uses the approved Mode 1 tool and a tightly scoped Mode 3 tool on open-weight models on the Region's reserved capacity under the mandate manifest MND-NR-01.

Hansa Mutual is a mutual insurance group headquartered in Hamburg, operating in seven countries inside and outside the EU, with about 9,500 employees. It runs two autonomous production agents with write access to core systems, the claims-triage agent and the IT-operations agent (AIDR-0027), and its SOC investigation agent HM-SEC-001 acts at Level 3 Bounded for two reversible actions. Its group security architecture team has six people in Hamburg: a head of security architecture, domain architects for identity, for platform and cloud, and for AI, and two embedded architects, one with the claims product line and one at the Polish service centre. The team reports to the group CISO. Its architecture is mostly code: a Structurizr workspace, policy as code with per-market overlays and a control catalogue of about 180 controls, with much evidence still attested and the UK and Swiss mappings kept outside it. An architecture review board meets fortnightly. The team conducts an agent team for architecture review under MND-HM-01 and a Mode 5 evidence-collection agent, whose rollout in each entity waits for works-council consultation in Germany and the Netherlands and union consultation in Sweden.

Both organisations received the same question in the same autumn, from different askers and for different reasons. In Nordvik the question followed the regional council's motion on whether to pause AI and the threat assessment ATA-NR-2026-01 that answered it. In Hansa it followed the board risk committee's question about AI loss of control and the assessment ATA-HM-2026-01. The worked example records both.

Worked example: The commission and the board request as decision records

Illustrative example. Nordvik's regional director, working with the CISO on the threat assessment, concluded that the Region's boundaries depended on one person whose post had no written decision rights and no deputy. The director asked the CISO for a role charter and a competence plan for the security architect before the 2027 budget is set. The commission follows the AI Decision Record schema of AI Platform and Security, Chapter 5 (169, Nordqvist, 2026).

# decisions/aidr/AIDR-0500.yaml (illustrative, Nordvik Region)
id: AIDR-0500
title: Commission a role charter and competence plan for the security architect
status: accepted
date: 2026-10-12
deciders: [regional-director]
accountable: chief-information-security-officer
reviewers: [hr-lead, enterprise-architect, ai-architect]
relates_to: [AIDR-0002, ATA-NR-2026-01]
context: >
  One security architect post, converted in 2025 from a security
  coordinator post, holds the boundaries between the AI estate, its
  suppliers and the Region's data. The post has a job description but
  no written decision rights, no deputy and no competence plan.
question: >
  What must the security architect decide, own and be able to do from
  2027, and what does the post need in the 2027 budget to do it?
deliverables:
  - id: ROLE-NR-SA-01
    artefact: roles/security-architect.yaml
  - id: CMP-NR-01
    artefact: competence plan and competence record
due: 2026-11-27            # before the executive committee prepares the 2027 budget
constraints:
  - fixed pay scales and security vetting
  - public-access rules and archiving apply to every deliverable
  - suppliers build and run most systems; boundaries are held by contract
  - one national co-determination regime
out_of_scope:
  - posts beyond the 2027 budget frame
review_by: 2027-10-12

Hansa's executive board asked a different question of a team. It did not ask whether the team should exist; it asked whether a fortnightly board could govern agents that propose changes daily.

# decisions/aidr/AIDR-0550.yaml (illustrative, Hansa Mutual)
id: AIDR-0550
title: Show how architecture decisions keep pace with agents in production
status: accepted
date: 2026-10-29
deciders: [executive-board]
accountable: group-chief-information-security-officer
reviewers: [chief-risk-officer, head-of-security-architecture, head-of-group-ai-platform]
relates_to: [AIDR-0027, AIDR-0311, ATA-HM-2026-01]
agents_in_scope:
  - {name: claims-triage-agent, mode: 5}
  - {name: it-operations-agent, mode: 5, record: AIDR-0027}
  - {name: HM-SEC-001, level: 3, scope: two reversible actions}
context: >
  The architecture review board meets fortnightly. Agents propose and
  execute changes daily. The board cannot sit in the path of every change
  without becoming a bottleneck or a formality.
question: >
  Which architecture decisions can be delegated to gates, which need
  the board, and how will the executive board see that they keep pace?
deliverables:
  - ROLE-HM-* charters in roles/security-architect.yaml
  - a delegation design for the architecture review board
  - board reporting on decision latency, patch velocity and time to stop
first_report: 2027-03-31
constraints:
  - seven legal regimes; AI Act and DORA are group policy outside the EU
  - works councils in DE and NL and union consultation in SE before any tool
    that can show who wrote what
  - DORA register of information for every AI service the architects use
review_by: 2027-10-29

Nordvik's commission is about one post: its authority, its competence and its budget. Hansa's request is about throughput: how decisions are routed when the actors in the estate are faster than the forum. Both name a person accountable for the answer, a due date and the constraints that will shape it.

How to read this book

The book has six parts. Part I, The Role in Question (Chapters 1 to 4), frames the question, describes the inherited role fairly in Chapter 2, defines the four shifts in Chapter 3 and writes the transformed role down as a role charter in Chapter 4. Part II, The Craft (Chapters 5 to 11), covers security architecture as code, threat modelling, boundaries and containment, identity for non-human actors, the control catalogue and evidence, design at machine speed and resilience. Part III, The Architect's AI Team (Chapters 12 to 15), covers the architect's own use of AI, an agent team for security architecture, the verification of what AI proposes and the keeping of the craft. Part IV, The Role in the Organisation (Chapters 16 to 20), places the role among its neighbours, redesigns decision forums as gates, reads European regulation as an engineering constraint, and treats communication and the settings of public authorities and multinationals. Part V, Competence and Career (Chapters 21 to 23), gives a competence framework, learning paths and hiring practices, and asks whether there will be a security architect in 2036. Part VI, Experience and Conclusions (Chapters 24 to 27), collects case studies and anti-patterns, follows Nordvik Region and Hansa Mutual through a year, draws conclusions for each and concludes the book.

The chapters can be read in order, but readers can also take different paths.

Reader Start with Then Use as reference
Security architect Chapters 1 to 4 Parts II and III in order Appendix A for full artefacts
CISO or head of security architecture Chapters 1, 3 and 4 Chapters 16 to 18, 21, 26 Chapter 19 for board measures
Enterprise, solution or AI architect Chapters 1, 3 and 16 Chapters 5, 7 and 13 Chapter 17 for decision tiers
HR, competence or hiring lead Chapters 1 and 4 Chapters 15, 21 and 22 Chapter 23 for scenarios
Procurement or programme leader in a public authority Chapters 1 and 20 Chapters 7, 9 and 18 Chapter 25 for Nordvik's year
Risk, compliance or internal audit Chapters 1 and 9 Chapters 14, 18 and 19 Chapter 24 for anti-patterns

Readers who do not know the earlier volumes will find each conclusion summarised where it is used, with the chapter in which it is developed.

Nordvik Region and Hansa Mutual

Nordvik's regional director has asked the CISO, in AIDR-0500, for a role charter and a competence plan for the security architect before the 2027 budget is set. The question concerns one person who holds boundaries mostly through tender annexes and supplier evidence and has no one at the same level to learn from, and the answer must survive public-access requests and fit within fixed pay scales. Nordvik's version of the four shifts is mostly about contracts: building a control catalogue it does not have, asking suppliers and its managed security service provider for machine-speed properties it cannot build, and keeping one person's judgement independent of the assistant that is the post's only daily colleague.

Hansa's executive board has asked the group CISO, in AIDR-0550, to show how architecture decisions will keep pace with the claims-triage agent, the IT-operations agent and the SOC investigation agent. The question concerns a team of six whose architecture is already largely code, held back by a fortnightly board and conducting an agent team whose review quality it has only begun to measure, and the answer must hold across seven legal regimes and pass works-council and union consultation. Hansa's version of the four shifts is mostly about delegation: completing a catalogue, moving routine decisions from a meeting to gates, and keeping review meaningful when agents produce more proposals than six people can read. By Chapter 26 each organisation answers its own question: Nordvik with a contract-first plan for a post that must stop being a single point of failure, Hansa with a delegation-first plan for a team whose binding constraint is human attention.

Summary

The five earlier volumes of the series made architecture, governance, the AI platform and cyber defence executable and examined the AI threat. Every one of their conclusions depends on the security architect, who designs the boundaries, policy points, identity model, evidence chain and stop paths, and whom none of them described. In the autumn of 2026 the July incident, the agencies' warnings about speed and the experience of agents in production turned the question of what that role has become into a question for management bodies.

The book's working thesis is that the role is being transformed, not abolished; abolition, absorption and continuity are its alternatives, and the thesis is judged in Chapters 23 and 27. What remains scarce is accountable human judgement: the authority to decide a boundary and answer for it, the ability to verify what code and AI propose, and the craft that makes verification possible.

As the opening of Part I, this chapter frames all four shifts: Shift 1, from documents to code; Shift 2, from gatekeeper to boundary designer; Shift 3, from periodic to continuous, at machine speed; and Shift 4, from sole author to conductor of an AI team. The question is European because NIS 2, DORA, the AI Act and the Cyber Resilience Act place duties on named bodies that the architect turns into controls, and because skills frameworks, procurement law and co-determination make the role a matter of organisational design. The duties are observable law; naming an accountable architect per boundary is an expected practice, not a legal duty.

Nordvik Region has recorded its commission as AIDR-0500 and Hansa Mutual its board request as AIDR-0550, and both are answered in the chapters that follow. Before the book can say what the role is becoming, it must say fairly what it was. Chapter 2 describes the security architect's inherited methods, from ISO/IEC 27001 and SABSA to review boards and reference documents, why they were valuable, and where they stopped scaling.

Sources

  1. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 (Artificial Intelligence Act). (1, European Union, 2024)
  2. European Parliament and Council of the European Union (2026). Regulation (EU) 2026/1744 (Digital Omnibus on AI). (2, European Union, 2026)
  3. European Parliament and Council of the European Union (2022). Directive (EU) 2022/2555 (NIS 2 Directive). (6, European Union, 2022)
  4. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (9, European Union, 2022)
  5. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/2847 (Cyber Resilience Act). (12, European Union, 2024)
  6. European Commission (2026). Cyber Resilience Act – Reporting obligations. (13, European Commission, 2026)
  7. European Parliament and Council of the European Union (2014). Directive 2014/24/EU on public procurement. (18, European Union, 2014)
  8. Federal Republic of Germany (2001). Betriebsverfassungsgesetz (BetrVG). (22, Germany, 2001)
  9. European Union Agency for Cybersecurity (2022). European Cybersecurity Skills Framework (ECSF): Role profiles. (41, ENISA, 2022)
  10. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (46, MITRE, n.d.)
  11. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. (47, MITRE, n.d.)
  12. Fowler, M. (2003). Who Needs an Architect? IEEE Software. (73, Fowler, 2003)
  13. Hohpe, G. (2020). The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise. O'Reilly Media. (74, Hohpe, 2020)
  14. ISC2 (2024). 2024 ISC2 Cybersecurity Workforce Study. (89, ISC2, 2024)
  15. ISACA (2024). State of Cybersecurity 2024: Survey results. (90, ISACA, 2024)
  16. Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. (93, Becker et al., 2025)
  17. Dell'Acqua, F. et al. (2023). Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality. (95, Dell'Acqua et al., 2023)
  18. Perry, N., Srivastava, M., Kumar, D. & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? (102, Perry et al., 2023)
  19. Bainbridge, L. (1983). Ironies of automation. (106, Bainbridge, 1983)
  20. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. (107, Parasuraman & Manzey, 2010)
  21. Bengio, Y. et al. (2026). International AI Safety Report 2026. (128, Bengio et al., 2026)
  22. OpenAI (2026). OpenAI – Hugging Face Incident Technical Report. (129, OpenAI, 2026)
  23. Larcher, H., Carreira, A. et al. (2026). Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident. Hugging Face. (130, Larcher et al., 2026)
  24. Satter, R., Seetharaman, D. & Cai, K. (2026). Exclusive: Its AI agent spent days hacking a company, but sources say OpenAI did not notice for a week. Reuters. (132, Satter et al., 2026)
  25. Five Eyes cyber security agencies: ASD's ACSC, Canadian Centre for Cyber Security, NCSC-NZ, NCSC-UK, NSA and CISA (2026). The AI shift in cyber risk: why leaders must act now. (137, Five Eyes agencies, 2026)
  26. European Union Agency for Cybersecurity (2026). ENISA Threat Landscape 2026. (141, ENISA, 2026)
  27. Nordqvist, G. (2025). Architecture as Code. (167, Nordqvist, 2025)
  28. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (168, Nordqvist, 2026)
  29. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (169, Nordqvist, 2026)
  30. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (170, Nordqvist, 2026)
  31. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (171, Nordqvist, 2026)
  32. Kingdom of the Netherlands (1971). Wet op de ondernemingsraden (WOR) (Works Councils Act). (175, Kingdom of the Netherlands, 1971)
  33. Sweden (1976). Lag (1976:580) om medbestämmande i arbetslivet (MBL) (Co-determination in the Workplace Act). (176, Sweden, 1976)