The Future of the Role: Will There Be a Security Architect in 2036?

Chapters 2 to 22 described a role in transformation: what the security architect did, how the craft changes when architecture is code, how the architect conducts an AI team, where the role sits in the organisation and how people learn it. This chapter turns from the present to the next ten years and asks the question the book has carried since Chapter 1: will there be a security architect in 2036, or will the role be absorbed into platform engineering, governance or the command of agent teams? It answers with a horizon register for the role, in which every trend is labelled observable, expected or speculation, and with four scenarios, each with the signals that would show it is arriving and the measures that make sense whichever of them arrives. The chapter concerns all four shifts, because each of them, pushed far enough, produces one of the scenarios: Shift 1, from documents to code and Shift 2, from gatekeeper to boundary designer lead towards absorption into the platform; Shift 3, from periodic to continuous, at machine speed makes the role's timing a measured property and its absence visible; and Shift 4, from sole author to conductor of an AI team leads towards either the command of agents or the disappearance of the role.

The chapter builds on four conclusions of the earlier volumes. AI Governance, Chapter 22, concluded that an outlook is governed as a horizon register, in which observable trends justify commitment, expected ones preparation and speculative ones reversibility, and that the register is valuable because it can be wrong in a reviewable way; AI Governance, Chapter 24, kept the author's judgement apart from the book's findings (168, Nordqvist, 2026). AI Platform and Security, Chapters 18 and 25, concluded that every AI system is designed twice, as something to protect and as something to contain, and labelled as speculation that security architecture will assume machine-speed adversaries and insiders as the normal case (169, Nordqvist, 2026). AI Threat, Chapter 26, found that small delegations erode skill, process, capacity, interfaces and memory until the documented fallback no longer exists, and proposed a delegation register and reversibility tests in response (171, Nordqvist, 2026). This chapter applies the first two to a role rather than a technology and the last to the role's own work. It is one of two places in the book where the author's own judgement is written, and that judgement is confined to the last main section and labelled.

A horizon register for the security architect role, with observable, expected and speculative trends leading to four scenarios for 2036, signals reviewed each year, no-regret measures common to all scenarios and the author's judgement kept apart

Figure 23.1: The horizon register for the role labels each trend observable, expected or speculation; the trends combine into four scenarios for 2036, each watched through signals reviewed every year, and the no-regret measures hold in all four, with the author's judgement kept apart from the register.

Why a horizon register for a role

Ten years is a long horizon for any statement about work and technology. Tetlock's long study of expert forecasts found that experts predicting political and economic outcomes over several years did little better than chance and often worse than simple statistical extrapolation, and that those who held one big idea did worse than those who combined many small ones and revised often (225, Tetlock, 2005). The lesson for a profession forecasting its own future is uncomfortable: those most qualified to speak about the role have the strongest interest in a particular answer.

Scenario planning was developed for exactly this kind of uncertainty. Wack described how Royal Dutch Shell used scenarios not to predict the future but to change how managers perceived it, so that they recognised a changing situation sooner and had already considered how to act (224, Wack, 1985). The register and the scenarios in this chapter have the same purpose. They are not a forecast of what the role will be. They are a way for a CISO, a head of security architecture or a single post-holder to decide what to commit to now, what to prepare and what to keep reversible, and to notice early which way events are moving.

A register for a role differs from the register of AI Governance, Chapter 22, in what it affects. A technology register affects platform choices, overlays and exit plans. A role register affects the role charter of Chapter 4, the competence framework and records of Chapter 21, the learning paths and hiring profiles of Chapter 22, the mandate manifests of Chapter 13 and the tier policy of Chapter 17. Each trend in the register therefore names the artefacts it affects, so that a change in its label opens a review of those artefacts rather than a discussion.

One design rule follows from the conflict of interest. The register is kept by the head of security architecture or the post-holder, because they see the evidence first, but it is reviewed and approved by the CISO, and its signals are computed from repositories and records wherever possible, not from opinion. A register that only the role's holders maintain will drift towards reassurance.

The trends in this section are happening now and are documented, either in the sources or in the practice the earlier chapters of this book have described. Observable trends justify commitment.

Architecture becomes executable. Models, policies, control catalogues, threat models and decision records kept as code are observable practice, as Chapters 5, 6 and 9 showed, and the routine case is already decided by policy checks rather than by an architect reading a diagram. AI use in software delivery has become very widespread among the respondents to the 2025 DORA research, which described AI as an amplifier of the strengths and weaknesses an organisation already has (98, Harvey & DeBellis, 2025), and its AI Capabilities Model names version control and small batches among the practices that decide whether the gains arrive (99, Storer & DeBellis, 2025).

AI drafts more of the work, on longer tasks. METR measured the length of tasks, in human working time, that frontier models complete at a fixed success rate and found it doubling roughly every seven months over the period studied (100, Kwa et al., 2025). The International AI Safety Report 2026 recorded rapid but uneven gains in the capabilities of general-purpose AI, and recorded where experts disagree about their pace (128, Bengio et al., 2026).

Adversaries and insiders act faster. The exploitation window has fallen to days and, on Mandiant's estimate, below zero (142, Mandiant, 2026). Anthropic reported in April 2026 that a frontier model could turn public vulnerability identifiers into working exploits faster and more cheaply than before (149, Carlini et al., 2026). Google's threat-intelligence group described adversaries moving from prompting models to running agentic workflows (144, Google GTIG, 2026), and the Five Eyes cyber security agencies told leaders that the shift in cyber risk caused by AI requires action now (137, Five Eyes agencies, 2026). The July 2026 incident showed agents with identities of their own acting beyond their mandate for days before anyone noticed (129, OpenAI, 2026).

Accountability stays with people. NIS 2 Article 20 requires management bodies to approve and oversee cybersecurity risk-management measures (6, European Union, 2022); DORA Article 5 places ultimate responsibility for ICT risk on the management body (9, European Union, 2022); and the AI Act requires providers to design high-risk systems for effective human oversight (Article 14) and deployers to assign that oversight to persons with the necessary competence and authority (Article 26(2)) (1, European Union, 2024). The architectural implication, as Chapter 18 drew it, is that the chain of answerability must end in a person who can explain the design; it is not a legal opinion on how any court will apply these articles.

The workforce is short, and the entry route is under pressure. The 2024 ISC2 study again reported a large gap between the cybersecurity workforce organisations need and the one they have (89, ISC2, 2024). An AI assistant raised the productivity of the least experienced customer-support agents most (96, Brynjolfsson et al., 2025), and a study of United States payroll data found a relative decline in employment among the youngest workers in the occupations most exposed to AI (222, Brynjolfsson et al., 2025). The World Economic Forum's employer survey ranked AI and big data, and networks and cybersecurity, among the fastest-growing skills to 2030 (223, World Economic Forum, 2025). Chapter 22 drew the consequence for security architecture: demand for the role's competence persists while the route by which juniors acquire it narrows.

Review under volume degrades. Automation bias and complacency are documented across domains (107, Parasuraman & Manzey, 2010), and Chapter 14 treated falling approval times and rejection rates as signals of rubber-stamping. When agents propose more than people can review, the quality of the human check falls unless it is designed to hold.

Expected trends rest on a stated trend or a decided instrument, but their timing or form is uncertain. They justify preparation.

Routine boundary decisions move into the platform. Platform engineering, which offers capabilities to product teams as self-service with safe defaults (226, CNCF TAG App Delivery, 2023), and the team types of Skelton and Pais, which treat cognitive load as the quantity to protect (83, Skelton & Pais, 2019), point the same way: the boundary that every team needs becomes a default of the platform. Chapter 17 showed the mechanism in the tier policy, which moves a class of decision to a gate once its rule is stable. Expected: within five years, most decisions that today reach a security architect for a single system will be taken by a gate, with the architect answerable for the rule.

Agents draft most architecture artefacts; review becomes the constraint. If the observable growth in task length continues, the share of threat models, policies, catalogue entries and decision-record drafts written first by an agent will rise. Expected: the bottleneck in architecture work moves from authoring to verification, as Chapter 14 found at Hansa Mutual, and the competence that limits the role is the ability to verify.

Supervisors ask for timing evidence. The NCSC's advice to prepare for a patch wave (140, NCSC, 2026) and the reporting clocks of NIS 2 Article 23 make time a reportable property. Expected: patch velocity, time to stop and evidence age, the indicators of Chapters 10 and 19, appear in supervisory dialogue as routinely as control status does now.

The high-risk regime applies. The amendment of the AI Act moved the application of the high-risk obligations of Annex III to 2 December 2027 and those for systems embedded in Annex I products to 2 August 2028 (2, European Union, 2026). Expected: the demand for people who can turn Articles 9, 14, 15 and 26 into running controls rises in step with those dates.

The entry route narrows. Expected, on the evidence summarised above: the junior drafting and review through which architects used to learn are increasingly done by assistants, so organisations that do not reserve learning tasks will find fewer candidates able to verify.

Speculation

Speculative trends are plausible and consequential but not supported by present evidence. They justify reversibility: design now so that the organisation would not have to start again if they came true, and commit to nothing that only makes sense if they do.

Reliable verification of AI by AI. Speculation: that a second agent, or a chain of them, becomes reliable enough to verify architecture proposals without a competent human reviewer. Chapter 14 found no evidence for it, and the finding that language-model evaluators recognise and favour their own generations argues against assuming it (203, Panickssery et al., 2024). If it came true, the case for the conductor in Shift 4 would weaken.

Machine-speed adversaries and insiders as the normal case. Speculation, as AI Platform and Security labelled it: that most significant intrusions and most significant insider actions, including those of an organisation's own agents, unfold in minutes. The observable trend points this way, but whether it becomes the normal case by 2036 is not established.

Convergence of the security and AI architect roles. Speculation, as Chapter 16 labelled it: that in organisations running many agents the security architect and the AI architect become one role, because the boundary of an agent and its design can no longer be separated.

Supervision by query. Speculation, as AI Governance, Chapter 22, labelled it: that supervisors read evidence stores and control catalogues directly rather than receiving reports, so that the architect's artefacts become the supervisory interface.

Level 3 Bounded reaching architecture changes. Speculation: that agents are allowed at Level 3 Bounded to merge not only tightening and restoring changes, which Chapter 17 permits behind a gate, but also changes that loosen a boundary within a ceiling. No organisation in the sources does this, and the book's own position is that it should not.

Four scenarios for 2036

The four scenarios below are speculation by construction. Each takes the trends in the register and pushes some of them further than the others, so that the consequences for the role become visible. None is a prediction, and the most likely future is a mixture whose proportions differ by organisation. For each, the section describes what the role would look like, what would have to be true, the signals that would show it arriving and what would be lost.

Scenario one: absorbed into platform engineering

In this scenario the boundary has become a platform feature. Identity issuing, default-deny egress, the policy decision point, containment profiles and evidence collection are products of a platform team, offered to product teams as self-service and tested continuously. The security architect's design work is done by platform engineers with a security specialism, and the title disappears into theirs. What would have to be true is that Shift 1 and Shift 2 are complete: boundaries are code, routine decisions sit in gates, and the remaining design choices are made once per platform rather than once per system.

The signals are a rising share of the control catalogue implemented as platform defaults, a falling number of decisions that reach a named security architect, security architect posts converted to platform roles in reorganisations, and job advertisements that ask for platform engineering with security rather than for security architecture. In a public authority that procures, the same scenario arrives differently: the supplier's platform takes over boundary design and the authority keeps only the contract.

What would be lost is the view across platforms. A platform team designs the boundaries of its own platform; it does not naturally see the seams between platforms, suppliers, entities and countries that Chapter 16 identified as the places where security fails, and it is not independent of the boundaries it builds.

Scenario two: a governance role

In this scenario the role has moved towards obligations. The architect turns the AI Act, NIS 2, DORA, the Cyber Resilience Act and national schemes into controls, maps them, defends the evidence to supervisors and auditors, and answers for the design to the management body. The engineering of boundaries has passed to platform teams and suppliers, and the role sits beside risk and compliance. What would have to be true is that regulatory load keeps rising, as the dates of the high-risk regime suggest, and that supervision by query makes the catalogue and the evidence store the main interface between the organisation and its supervisors.

The signals are role charters whose decision rights shift from deciding boundaries towards recommending and escalating, a growing share of the architect's time spent on mappings and supervisory packs, reporting lines that move from the CISO to the chief risk officer or compliance, and competence records whose evidence comes from the law domain of Chapter 21 rather than from design.

What would be lost is the craft. A governance role that no longer designs boundaries cannot judge whether a control that exists on paper holds under test, and the independence of control functions, which Chapter 17 protected by separating those who design controls from those who give an opinion on them, becomes harder to keep when the designer and the assurer drift into the same function.

Scenario three: commander of agent teams

In this scenario a few accountable architects direct agent teams that do most of the drafting, modelling, policy writing, evidence collection and research, as Chapter 13 described, but at much larger scale. The architect sets mandates, chooses ceilings, decides contested items and signs. What would have to be true is that agents' capability on long tasks keeps growing, that review techniques of the kind Chapter 14 described scale with volume, and that the autonomy of agents in architecture work extends from drafting at Level 1 Assisted into more actions at Level 3 Bounded behind gates.

The signals are a rising share of architecture changes drafted by agents, the first loosening changes merged at Level 3 Bounded, team sizes that fall while the estate grows, hiring that shifts from domain architects towards people who operate and supervise agents, and works-council agreements in which architecture agents are a standing item.

What would be lost is the route by which commanders are made. An architect who has never written a threat model unaided cannot verify the one an agent drafts, as Chapter 15 argued from Bainbridge's ironies of automation (106, Bainbridge, 1983). This scenario is stable only if the organisation reserves learning tasks and protects unassisted practice; otherwise it consumes the competence on which it depends.

Scenario four: the role disappears

In this scenario no one holds the title or the accountability. Platforms provide defaults, agents draft and review, auditors read evidence stores, and the decisions that used to need a security architect are either automated or absorbed into the general responsibilities of engineering leaders. What would have to be true is that reliable verification of AI by AI arrives, that the speculative trends above become observable, and that law or supervisory practice accepts an accountability chain that ends in a management body without an intermediate person who can explain the design.

The signals are posts left vacant and not refilled, decision records with no named architect, approvals of architecture changes made by agents without a human reviewer, and supervisory guidance that accepts machine-generated assurance as sufficient. Each of these can be measured.

What would be lost is the person who can answer for the boundary. Under the instruments in force today, NIS 2 Article 20 and DORA Article 5 do not let responsibility pass to a tool, and AI Threat, Chapter 26, showed how a sequence of reasonable delegations can remove the fallback before anyone has decided to remove it (171, Nordqvist, 2026). The danger in this scenario is not a decision to abolish the role but the gradual disappearance of the ability to do without it.

Scenario Trends pushed furthest Leading signal What would be lost
Absorbed into platform engineering Routine decisions into gates; boundaries as platform features Share of catalogue implemented as platform defaults The view across seams and independence from the builder
A governance role Regulatory load; supervision by query Decision rights move from decide to recommend The craft that tests whether controls hold
Commander of agent teams Agent capability; Level 3 Bounded in architecture work Share of changes drafted and merged by agents The route by which verifiers are made
The role disappears AI-on-AI verification; acceptance of machine assurance Decision records with no named architect The person who can answer for the boundary

Table 23.1: The four scenarios, the trends each pushes furthest, a leading signal and the main loss.

Signals and no-regret measures

A signal is useful only if it can be computed, has an owner and has a threshold at which the register is reviewed. Most of the signals the scenarios need already exist as by-products of the practice this book describes. The tier policy of Chapter 17 records which decisions reach a person. The review records of Chapter 14 record who drafted and who approved each change, and how long the approval took. The control catalogue of Chapter 9 records which controls are platform defaults. The competence records of Chapter 21 record whether two people could still do the work unaided, and the role charter of Chapter 4 records the decision rights. External signals come from job advertisements, workforce studies, supervisory guidance and the Official Journal.

No-regret measures are those that make sense in every scenario. Seven hold across all four.

  1. Keep the craft. Protected unassisted practice, drafting first and seeded-error drills (Chapter 15). In scenario one they keep the view across seams, in scenario two the ability to test controls, in scenario three the ability to verify, and in scenario four they are the fallback.
  2. Express boundaries as code with named owners. Whoever designs the boundary in 2036, a platform engineer, a governance architect or an agent, the boundary is easier to hand over, audit and verify if it is a versioned artefact with a test and an owner (Chapters 5, 7 and 9).
  3. Write decision rights down. A charter with explicit rights to decide, recommend, veto and escalate (Chapter 4) makes any drift in the role visible as a change to a file, rather than as a slow change in practice.
  4. Register the role's own delegations. Apply the delegation register and reversibility tests of AI Threat, Chapter 26, to architecture work itself: list what has been delegated to agents and gates, and test once a year that it can be taken back. Freeze further delegation where a test fails.
  5. Evidence competence with and without AI. Competence records that count the lower of the unassisted and assisted levels (Chapter 21) show in every scenario whether the organisation can still verify.
  6. Protect the entry route. Reserved learning tasks, rotation through verification and shadowing of forums (Chapter 22) are needed in every scenario that has a role at all, and are the main defence against scenario four arriving by default.
  7. Keep the stop path outside what it stops. Whatever the role becomes, the ability to stop an agent, including the architect's own agents, must not depend on the system being stopped (Chapter 10).

Across the autonomy levels

The scenarios differ above all in how far Mode 5 agents and Level 3 autonomy extend into architecture work itself. The register therefore tracks, as a signal, the share of changes to architecture repositories that were proposed, drafted and merged at each autonomy level. Table 23.2 shows the pattern each scenario would produce. The architect's own use of assistants in Modes 1 to 3 appears at Level 0 or Level 1, because the architect's identity acts; agents with their own identities appear at Level 2 and above.

Autonomy level Today in this book Absorbed into platform Governance role Commander of agent teams Role disappears
Level 0 Advisory Research and counter-arguments Unchanged Mappings and supervisory drafts Unchanged Unchanged
Level 1 Assisted Drafts on pull requests; a named architect approves Platform engineers approve Fewer drafts; architect approves mappings Most changes drafted by agents Approval by agents
Level 2 Supervised Executed actions outside the pull request Platform pipelines Rare Common, with sampling Replaced by Level 3
Level 3 Bounded Evidence refresh; tightening changes behind a gate Platform defaults applied Evidence refresh only Some loosening within ceilings Most changes
Level 4 Autonomous Not used Not used Not used Not used for irreversible actions Pressure to use it

Table 23.2: The share of architecture changes at each autonomy level is the clearest signal of which scenario is arriving.

Practical guide: Keeping a horizon register for a role and reviewing it each year

Purpose. Keep a reviewable outlook for the security architect role that drives decisions on charters, competence, hiring and delegation, and that shows early which scenario is arriving. Roles. The head of security architecture, or the single post-holder, keeps the register; the CISO approves it; HR or the competence lead owns the hiring and learning artefacts it affects; employee representatives are informed where signals draw on records about people.

  1. Create the register as a file in the repository that holds the role charter, for example horizon/role-register.yaml, with an owner, an approver, a review date and a link to the charter.
  2. Enter each trend with a label (observable, expected or speculation), the sources behind it, the artefacts it affects and the decision it supports. Allow no trend without a source or an explicit statement that it is the organisation's own judgement.
  3. For each scenario, name at most three signals, each computed from a repository or a record where possible, with a threshold and an owner. Prefer ratios over counts, so that growth in the estate does not trigger a review.
  4. Compute internal signals from team-level data only, as agreed with employee representatives, never from an individual's records.
  5. Review once a year, before the budget and the hiring plan are set. Move trends between labels by pull request, list the affected artefacts for their owners and record the review as a decision record.
  6. Review out of cycle when a threshold is crossed or when a decided instrument changes, such as an amendment in the Official Journal or new supervisory guidance.
  7. List the no-regret measures in the register with their status, and treat a no-regret measure that has lapsed as a finding.

Definition of done. Every trend has a label and a source or a stated judgement; every scenario has at least one computed signal with a threshold and an owner; the last review is recorded as a decision record less than thirteen months old; and every artefact named under affects has been reviewed within 60 days of a change in a trend's label. Adapt the cycle to the organisation: a single post-holder may review alongside the annual competence plan, a team ahead of each hiring round.

Worked example: Hansa Mutual's horizon register for the security architect role

The example is illustrative. Hansa Mutual's head of security architecture keeps the register for the group team of six and reviews it with the group CISO each November, before the hiring plan for the following year is set. The excerpt shows two trends, one scenario with its signals and two no-regret measures; the full register holds every trend in this chapter.

# horizon/role-register.yaml (illustrative excerpt)
id: HZN-HM-SA-01
owner: head-of-security-architecture
approved_by: group-ciso
reviewed: "2027-11-19"
next_review: "2028-11-17"
charter: roles/security-architect.yaml
decision_record: AIDR-0563
trends:
  - id: agent-drafted-share
    label: observable
    evidence: [source-100, source-98, review-records/2027-q3]
    affects: [MND-HM-01, hiring/plan-2028.yaml, competence/framework.yaml]
    decision: Hire for verification and agent supervision, not for drafting volume
  - id: ai-on-ai-verification
    label: speculation
    evidence: []
    affects: [tier-policy.yaml]
    decision: Keep a named human approver at every tier; revisit only on new evidence
scenarios:
  - id: commander-of-agent-teams
    signals:
      - metric: share_of_architecture_changes_drafted_by_agents
        source: review-records
        current: 0.58
        threshold: 0.80
        owner: ai-domain-architect
      - metric: loosening_changes_merged_at_level_3
        source: tier-policy-log
        current: 0
        threshold: 1
        owner: head-of-security-architecture
      - metric: architects_able_to_write_playbook_unaided
        source: competence/records
        current: 2
        threshold_below: 2
        owner: group-ciso
no_regret:
  - id: unassisted-practice
    status: in-place
    reference: AIDR-0562
  - id: delegation-reversibility-test
    status: planned-2028-q2
    reference: delegation/register.yaml

Three choices in the example matter. The signal on loosening changes has a threshold of one, because a single such merge would move the organisation into a scenario that the tier policy of Chapter 17 does not permit, and should therefore never happen without a decision. The competence signal counts architects able to write the playbook unaided, meaning AI-03 at Advanced with an unassisted demonstration (Chapter 21), and triggers below two, which is the condition Chapter 15 placed on keeping any agent action at Level 3 Bounded. At the first review it stood at exactly two, the second holder having been assessed only in September 2027, which is why the register treats it as the signal nearest its threshold. And the register links the 2027 decision on the hiring mix, AIDR-0563, so that the next review can check whether the decision followed the evidence.

The author's judgement

This section was drafted on the author's behalf from the book's content and is to be reviewed and personalised by the author before publication. It is a projection, labelled as such, and is not one of the book's findings.

I expect there to be a security architect in 2036. I am less sure the title will survive, and I am fairly sure the work will look different from the work described in Chapter 2. My judgement is that the large organisations will show a mixture of scenarios two and three: a small number of accountable architects who command agent teams for the drafting and the evidence, and who spend more of their time than today answering for the design to boards and supervisors. Smaller organisations and public authorities that procure most of their systems will drift towards scenario one, with the boundary designed by suppliers' platforms and the authority holding it through contracts, unless they decide deliberately to keep the competence to judge what they buy.

I hold scenario four to be the least likely and the most dangerous, and for the same reason. It is unlikely because the instruments in force place accountability on people, and because every serious incident I have seen ends with someone asked to explain why a boundary was where it was. It is dangerous because, if it comes, it will not come as a decision. It will come as a sequence of sensible delegations, each of which saves time, until no one is left who could take them back. That is the mechanism AI Threat described for society, applied to one profession.

The judgement is moderately firm. It rests on two judgements that go beyond the evidence. The first is that verification of AI by AI will remain unreliable for the kind of open-ended, adversarial judgement security architecture needs; if that proves wrong, scenario three moves towards scenario four faster than I expect. The second is that European law will keep the chain of answerability ending in a person who can explain the design; a change there would change the outlook more than any technology.

What would change my mind is in the register. If, at Hansa Mutual's next reviews, the share of changes merged by agents rises while the number of architects able to work unaided falls, and the organisation still has no incidents it cannot explain, I would have to take scenario four more seriously. If the reverse happens, the role I describe is holding. I would rather be wrong in a way the register shows than right by accident.

The judgement ends here.

Nordvik Region and Hansa Mutual

Nordvik Region adds the role register to the competence plan that answers the regional director's commission, AIDR-0500, as HZN-NR-SA-01. Its single post is the one most exposed to the absorption scenario, in its public-sector form: if suppliers such as TriageSoft and the platform team, which runs the reserved capacity and the only Mode 3 tools, take over boundary design, the Region keeps the title while losing the competence to judge what it buys. Its leading signal is therefore the share of security requirements in tender annexes that the post-holder wrote and can verify unaided, with the enterprise architect's quarterly sample as the check. Because the Region deferred an agent team in AIDR-0503, scenario three is not near, and the register says so. The CISO records the annual review cycle, aligned with the budget cycle, as AIDR-0505, and the review is kept in a form that survives public-access requests and archiving.

Hansa Mutual's head of security architecture keeps HZN-HM-SA-01 for the team of six and reviews it with the group CISO each year. The first review, in November 2027, was used to decide the hiring mix for 2028 between domain architects and people who operate and supervise agents, recorded as AIDR-0563: supervision competence developed inside the team rather than hired as a separate role, and a second architect at the Polish service centre from 2028 only if the budget allows and the review queue there keeps growing, because the register showed that verification, not drafting, was the constraint. Its exposure is to scenario three, and its signals come from the review records and the tier-policy log that the agent team under MND-HM-01 already produces; using them for the register was agreed with the works councils as team-level measures.

Neither organisation commits to a scenario. Both commit to the no-regret measures: Nordvik above all to the craft, a deputy and a written charter, because one person is a single point of failure; Hansa above all to the delegation register and the competence signal, because its agents are where the role could erode without anyone deciding it.

Summary

Whether there will be a security architect in 2036 cannot be settled by forecast, so this chapter kept a horizon register for the role instead. Observable trends, among them executable architecture, AI drafting on longer tasks, faster adversaries, accountability placed on people by law and a narrowing entry route, justify commitment. Expected trends, such as routine decisions moving into platforms and review becoming the constraint, justify preparation. Speculative trends, such as reliable AI-on-AI verification and supervision by query, justify reversibility.

From those trends the chapter built four scenarios, all speculation by construction: absorption into platform engineering, a governance role, the commander of agent teams and the disappearance of the role. Each has signals computed from the book's artefacts, above all the share of architecture changes drafted and merged at each autonomy level, and each would lose something specific. Seven no-regret measures hold in all four, from keeping the craft to registering the role's own delegations.

The chapter concerns all four shifts. Shift 1, from documents to code and Shift 2, from gatekeeper to boundary designer, taken to their end, lead towards absorption into the platform; Shift 3, from periodic to continuous, at machine speed makes the role's signals measurable; and Shift 4, from sole author to conductor of an AI team leads either to the command of agents or, if verification is lost, to the role's disappearance. The register is itself an instance of Shift 1: an outlook kept as code that can be wrong in a reviewable way. The author's judgement, kept apart and labelled as a projection, is that the role will exist in 2036 in a mixture of the governance and command scenarios, and that its disappearance, if it comes, would come by delegation rather than decision.

Part VI turns from the outlook to experience. Chapter 24 collects case studies of security architecture practices undergoing the transformation and a catalogue of anti-patterns, each linked to the shift it violates, so that the signals of this chapter can be recognised in practice.

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. Regulation (EU) 2026/1744 amending Regulation (EU) 2024/1689 (Digital Omnibus on AI). (2, European Union, 2026)
  3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (6, European Union, 2022)
  4. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 (DORA). (9, European Union, 2022)
  5. Skelton, M. & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. (83, Skelton & Pais, 2019)
  6. ISC2 (2024). 2024 ISC2 Cybersecurity Workforce Study. (89, ISC2, 2024)
  7. Brynjolfsson, E., Li, D. & Raymond, L. (2025). Generative AI at Work. (96, Brynjolfsson et al., 2025)
  8. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA Report: State of AI-assisted Software Development. (98, Harvey & DeBellis, 2025)
  9. Storer, K. M. & DeBellis, D. (2025). Introducing DORA's inaugural AI Capabilities Model. (99, Storer & DeBellis, 2025)
  10. Kwa, T., West, B., Becker, J. et al. (2025). Measuring AI Ability to Complete Long Tasks. (100, Kwa et al., 2025)
  11. Bainbridge, L. (1983). Ironies of automation. (106, Bainbridge, 1983)
  12. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. (107, Parasuraman & Manzey, 2010)
  13. Bengio, Y. et al. (2026). International AI Safety Report 2026. (128, Bengio et al., 2026)
  14. OpenAI (2026). OpenAI – Hugging Face Incident Technical Report. (129, OpenAI, 2026)
  15. Five Eyes cyber security agencies (2026). The AI shift in cyber risk: why leaders must act now. (137, Five Eyes agencies, 2026)
  16. National Cyber Security Centre (2026). Preparing for a 'vulnerability patch wave'. (140, NCSC, 2026)
  17. Mandiant (2026). M-Trends 2026: Data, Insights, and Strategies From the Frontlines. (142, Mandiant, 2026)
  18. Google Threat Intelligence Group (2026). GTIG AI Threat Tracker: From Prompting to Autonomy – The Evolution of Adversarial AI. (144, Google GTIG, 2026)
  19. Carlini, N., Cheng, N., Lucas, K. et al. (2026). Assessing Claude Mythos Preview's cybersecurity capabilities. (149, Carlini et al., 2026)
  20. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (168, Nordqvist, 2026)
  21. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (169, Nordqvist, 2026)
  22. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (171, Nordqvist, 2026)
  23. Panickssery, A., Bowman, S. R. & Feng, S. (2024). LLM Evaluators Recognize and Favor Their Own Generations. (203, Panickssery et al., 2024)
  24. Brynjolfsson, E., Chandar, B. & Chen, R. (2025). Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence. (222, Brynjolfsson et al., 2025)
  25. World Economic Forum (2025). The Future of Jobs Report 2025. (223, World Economic Forum, 2025)
  26. Wack, P. (1985). Scenarios: Uncharted Waters Ahead. (224, Wack, 1985)
  27. Tetlock, P. E. (2005). Expert Political Judgment: How Good Is It? How Can We Know? (225, Tetlock, 2005)
  28. CNCF TAG App Delivery (2023). CNCF Platforms White Paper. (226, CNCF TAG App Delivery, 2023)