Learning Paths, Certification, Hiring and Upskilling

Chapter 21 gave the competence framework: six domains, four levels and the evidence that demonstrates each competence. A framework describes a destination. This chapter describes the journey and its gates: how people reach the role, what they learn and in which order, what a certificate tells an employer, how to hire and interview for judgement, and when to grow a security architect rather than buy one. It concerns Shift 4, from sole author to conductor of an AI team, because the person who conducts an AI team must be able to verify what it proposes, and verification is learned through practice and cannot be bought as a credential. It also concerns Shift 1, from documents to code, because learning paths, hiring profiles, exercises and competence records are, like the role charter of Chapter 4, artefacts in version control.

The chapter builds on three conclusions of the earlier volumes. Architecture as Code (Chapter 18) managed competence as a skills matrix by level, holding that certifications validate knowledge while practical demonstration shows capability (167, Nordqvist, 2025). AI Governance, Chapter 14, concluded that AI literacy is role-specific and must be evidenced, that upskilling is the strategy and hiring is for scarce specialisms, and that assessment results are personal data (168, Nordqvist, 2026). AI Threat, Chapters 6 and 14, concluded that reliance on AI reduces effort and checking, and that automating junior work removes the route by which experts are made (171, Nordqvist, 2026), a conclusion that rests on findings such as Lee and colleagues' survey, in which knowledge workers who trusted the AI more reported less critical thinking (111, Lee et al., 2025). The chapter answers how competence is evidenced when AI does much of the visible work: by demonstration, with and without the tool. How anyone becomes a security architect when junior work has been automated it answers only in part, with the measures an organisation controls; the wider outlook belongs to Chapter 23. Apprenticeship inside a working team stays in Chapter 15.

Four starting points converging on the role along learning paths, with certification, practical demonstration and the hiring gate marked

Figure 22.1: Four starting points converge on the role through a gap assessment and a learning path by level; certification is a side check on knowledge, and the practical demonstration, unassisted and assisted, is the gate that both the learning path and the hiring route pass.

Four starting points

People reach the role from four directions in practice, and each brings part of the framework and lacks another.

The security engineer brings the adversary and code domains. The engineer must add design at the scale of an estate, the law that turns obligations into controls, and the people domain: writing for a board, holding a decision right, being overruled with a record. The characteristic failure is to treat a boundary as a configuration, not as a decision that other teams depend on.

The enterprise architect brings design and people. The enterprise architect must add the adversary domain, in the vocabulary of MITRE ATT&CK and ATLAS, and enough code to read a policy rule and a pipeline. The characteristic failure is a boundary drawn well and tested by nobody.

The developer brings code and a feel for how systems fail under change, and must add the adversary domain, the law and design across systems that other teams own. The characteristic failure is to treat every problem as a coding problem and to underrate evidence.

The auditor brings the law, the discipline of evidence and an independence the role needs. The auditor must add design and code. The characteristic failure is finding fault without owning a design. The move from assurance to design is recorded and followed by the cooling-off period described under careers below.

Starting point Usually strong in Add first Failure to watch
Security engineer Adversary, code Design at estate scale, law, people A boundary treated as a configuration
Enterprise architect Design, people Adversary, code A boundary nobody tests
Developer Code Adversary, law, design across teams Every problem treated as a coding problem
Auditor Law, evidence Design, code Fault found without a design owned

ENISA's Cybersecurity Architect profile, with its user manual for planning training and recruitment, gives these starting points a shared vocabulary, as SFIA 9 and the NICE Workforce Framework do; Chapter 21 treats the profile and maps it to the other two (41, ENISA, 2022) (42, ENISA, 2022) (43, SFIA Foundation, 2024) (33, Petersen et al., 2020). No starting point is better than another. The gap is individual while the framework is common, so every path begins with a gap assessment against the six domains, recorded in the competence record of Chapter 21, not with a course catalogue.

Learning paths

A learning path sequences practice, projects and review by framework level. Four principles carry it.

The first is practice on real artefacts: pull requests, a live threat model, a tender annex that will be sent. The second is fast feedback. Ericsson and colleagues found that expert performance develops through deliberate practice: tasks pitched at the learner's limit, informative feedback, repetition and correction of errors (108, Ericsson et al., 1993). Kahneman and Klein add that intuitive expertise develops only with regular environments and feedback on outcomes (109, Kahneman & Klein, 2009). Security architecture supplies little of it: a flawed boundary can stay invisible until an incident or a test reveals it. The path therefore manufactures feedback. A learner compares an unaided threat model with the findings of a red-team exercise (AI Red Team, Chapters 12 and 13) (170, Nordqvist, 2026), replays the July 2026 OpenAI–Hugging Face incident of AI Governance, Chapter 19, to see where their own boundaries would have stopped it (168, Nordqvist, 2026), and has every design reviewed by a senior colleague who writes down what they would have changed.

The third is levels gated by demonstration. A learner moves from Foundation to Practitioner in a domain when the competence record holds the evidence Chapter 21 specifies, assessed by a more experienced colleague, not when a course is completed. As a default, expect twelve months from Foundation to Practitioner in a domain with about fifteen per cent of the learner's time protected; adapt it to the starting point and the organisation's risk appetite.

The fourth is protected unassisted practice. An assistant can now draft the threat model, the policy rule and the decision record. Unrestricted assistance during practice lowers unaided performance afterwards, while a tutor that withholds direct answers largely avoids the harm (Chapter 15) (114, Bastani et al., 2025). AI Threat, Chapters 6 and 7, drew the organisational conclusion that learning tasks should be reserved for unaided work and checked by an experienced person (171, Nordqvist, 2026). For a learner the rule is first draft by the learner, then the assistant, used as reviewer or tutor, with the two compared. Supervised practice with the architect's own Mode 3 tools, under the mandate manifest of Chapter 13, belongs on the path because the tool is part of the job, but only after the learner can do the task without it. Chapter 15 treats keeping the craft in a working team.

Practical guide: A twelve-month learning path from enterprise architect to security architect

Purpose. Bring an enterprise architect to Practitioner level in the adversary, code and AI domains within twelve months, with evidence the competence record can hold.

Roles. The learner; a mentor at Advanced level or above, internal or contracted; the CISO or head of security architecture, who owns the path and its resources; an assessor who is not the mentor.

  1. Month 0: assess the gap. Assess the learner against the six domains of Chapter 21 by practical demonstration, record it, and set a target level per domain for month twelve. Agree protected time (default fifteen per cent) and mentor hours (default four a month).
  2. Months 1 to 3: adversary and code. The learner builds an unassisted threat model of one live system in the vocabulary of STRIDE, ATT&CK and ATLAS, reviewed by the mentor, and writes one policy rule that is merged through the normal review. Evidence: the threat model, the pull request, the mentor's notes.
  3. Months 4 to 6: the AI domain. The learner classifies the estate's AI systems by usage mode, writes a containment profile for one agent or tool before it is changed, and starts supervised work with an agentic tool under a mandate manifest, drafting first. Evidence: the profile and the drafts compared with the assistant's.
  4. Months 7 to 9: law and supplier boundaries. The learner maps one obligation to a control end to end, for example NIS 2 Article 21 to the control catalogue and its evidence, writes a security annex for a live tender, and presents one design to a decision forum. Evidence: the mapping, the annex as sent, the forum record.
  5. Months 10 to 12: consolidate. The learner leads one design on a real change, acts as reviewer in a seeded-error review (Chapter 14), and is assessed by demonstration, once unassisted and once with the tool.
  6. Throughout. Each quarter the learner repeats an earlier task without the assistant and records the result.

Definition of done. The record shows Practitioner in design, code, adversary and AI, no domain below Foundation, one artefact per quarter in version control, and one assessment in which the learner caught the seeded errors in AI output. Learner and mentor agree the plan for year two.

Worked example: Nordvik Region's learning path for its post-holder

The illustrative record below is the learning path that answers the competence-plan half of the commission recorded as AIDR-0500. It is financed in the 2027 budget and decided as AIDR-0532. The post-holder's starting point is the security coordinator's: the work was policy documents, the coordination of the annual procured penetration test and answers to supplier questionnaires. That makes the starting point closest to the auditor path, strong in law and in evidence, weaker in code and design.

# learning/paths/LP-NR-2027-01.yaml (illustrative)
id: LP-NR-2027-01
decision: AIDR-0532
holder: {role: ROLE-NR-SA-01, record: CMP-NR-01}
starting_point: security-coordinator      # nearest to the auditor path
framework: competence/security-architect-framework.yaml
targets:                                  # level at month 12
  design: practitioner
  code: practitioner
  ai: practitioner
  adversary: practitioner
  law: advanced
  people: practitioner
resources:                                # financed in the 2027 budget
  protected_time_percent: 15
  training_days: 20
  external_mentor_hours: 48               # call-off under a consultancy framework agreement
quarters:
  - id: Q1
    focus: [code, adversary]
    evidence:
      - merged pull request turning the pre-production checklist into policy as code
      - unassisted threat model of the benefits-explanations service, reviewed by the mentor
  - id: Q2
    focus: [ai]
    evidence:
      - containment profile for the Mode 3 tool under MND-NR-01, written before any change to it
      - reading note on the staff assistant model card against AIDR-0211
  - id: Q3
    focus: [design, law]
    evidence:
      - stop-path and egress annex accepted in one live tender
      - mapping of NIS 2 Article 21 measures to the control catalogue
  - id: Q4
    focus: [people, consolidation]
    evidence:
      - design led on a real change and presented to the regional executive committee
      - assessment by demonstration, unassisted and assisted
no_ai_exercises: {frequency: quarterly, first_draft_by_holder: true}
assessment:
  method: practical demonstration reviewed by the CISO and the external mentor
  record_access: [holder, ciso, hr]
  agreed_with: employee representatives, before the first assessment
  retention_months: 36
deputy:
  source_team: platform
  share_of_time_percent: 20
  targets: {design: practitioner, code: practitioner}

The mentor is external because the Region has no second security architect to learn from. Access to the record is limited and agreed with employee representatives first, because assessment results are personal data. The deputy block answers the single point of failure: a platform engineer spends a fifth of their time on the same framework, so that within a year two people can read a boundary decision and challenge it.

Certifications and their limits

A certification validates that a person held a body of knowledge on the day of an examination. That is a real signal and an inexpensive one to read. It is not a signal of judgement, of the ability to design under uncertainty, or of the ability to verify the output of an assistant.

Instrument What it validates What it does not validate Use it for
Architecture credentials, such as the CISSP-ISSAP concentration Knowledge of a defined body of architecture practice at a point in time Design judgement on your estate; AI and agent boundaries unless the syllabus says so A floor for external candidates and contractors
Method certifications, such as TOGAF and SABSA Command of a method and its vocabulary Whether the method suits an estate that changes daily Shared vocabulary with enterprise architecture
ECSF, SFIA and NICE profiles Nothing: they describe roles and skills Any individual's competence Writing profiles, tenders and gradings
Practical demonstration on real delivery Capability on the work of this organisation Knowledge outside the work shown The gate for levels in the competence record

ISC2 describes CISSP-ISSAP as a concentration for holders of the CISSP credential covering architecture domains such as governance, risk and compliance, identity and access management and security operations (91, ISC2, n.d.). The TOGAF Standard and SABSA are the methods Chapter 2 described as the inherited toolkit, and each has a certification scheme built on it (39, The Open Group, 2022) (38, Sherwood et al., 2005). All are useful, but none was written for an estate in which agents hold identities of their own. An employer can check in an hour by putting the current syllabus beside the AI domain of Chapter 21; where it is silent, the gap is the employer's to fill.

The deeper limit follows from the book's thesis. A knowledge test is the kind of task at which an assistant performs well, so an examination's power to separate people who can do the work from people who can recall the vocabulary weakens as assistants improve. That is the book's own conclusion, not a finding about any examination. Keep certification as a floor that costs nothing to read, with practical demonstration above it as the evidence that decides.

Do not make a named certificate a precondition in an advertisement, because it filters out career-changers and tests the wrong thing; ask for evidence of the competences in the ECSF vocabulary. In the public sector, procurement law points the same way. Directive 2014/24/EU allows selection criteria on technical and professional ability under Article 58, which must relate to the subject of the contract and be proportionate, and an authority that buys consultancy through a framework agreement under Article 33 should ask for evidence of the work it will receive, not only a certificate (18, European Union, 2014). Nordvik applies this to every contracted architect: references to comparable delivery, a sample artefact and a handover that leaves competence behind.

AI literacy for the architect

Article 4 of the AI Act, as amended by the Digital Omnibus on AI, asks providers and deployers to take measures to support the AI literacy of their staff and of others who operate and use AI systems on their behalf, taking into account their technical knowledge, experience, education and training, the context of use and the persons on whom the systems are used (1, European Union, 2024) (2, European Union, 2026). The amendment moved the duty from ensuring a level to supporting it, and the Commission confirms that no particular certificate or governance structure is required (4, European Commission, 2026). The architectural reading, set out in AI Governance, Chapter 14, is that Article 4 became the floor and that the duties which did not soften still demand competence: Article 14 asks providers to design high-risk systems so that overseers understand their limitations and stay aware of automation bias, and Article 26(2) asks deployers to assign oversight to people with the necessary competence, training and authority (1, European Union, 2024) (168, Nordqvist, 2026).

For the security architect the article has a double meaning. The architect is a person on whom the duty falls, as a user of Modes 1 to 3, and also designs what literacy and competent oversight mean for everyone else, through the boundary, the oversight path and the evidence that Articles 14 and 26 rely on. Treat Article 4 for the architect as testable learning objectives, each tied to an artefact in the competence record:

  • Modes and identities. For any system in the estate, state its usage mode, whose identity it acts with and what it can reach. Evidence: the inventory entry and a containment profile.
  • Limits of the technology. Explain what a system the architect has bounded can and cannot be relied on for, from its evaluation record and model or system card. Evidence: a reading note reviewed by the mentor.
  • Automation bias. Explain that complacency and bias affect experienced people as well as novices and are not removed by instruction alone (107, Parasuraman & Manzey, 2010), and design one measure against them. Evidence: the measure as configured.
  • Autonomy from reversibility. Set the autonomy level of an action from its reversibility and write the playbook that bounds it (AI Red Team, Chapter 6) (170, Nordqvist, 2026). Evidence: the playbook and a test of its stop path.
  • Verification. Catch seeded errors in an AI-drafted proposal, unassisted and assisted. Evidence: the review record of Chapter 14.
  • Teaching others. Brief a management body on the AI portfolio's highest risks. NIS 2 Article 20(2) and DORA Article 5(4) require management-body training or knowledge, and the architect often supplies the content (6, European Union, 2022) (9, European Union, 2022). Evidence: the briefing and the board's questions.

Across the usage modes

The architect's own use of AI in Modes 1 to 3 runs under the architect's identity; Modes 4 and 5 are the systems the architect designs for. A learning path touches all of them, and an interview exercise samples them.

Mode What the path practises What the interview exercise samples
Mode 0 Ambient AI Finding AI in licensed software that nobody chose, and recording it Whether the candidate asks where AI already is in the described estate
Mode 1 Conversational assistants Classification discipline: what may go into the approved tool and what may not Use of the approved tool in the assisted sitting, and the data the candidate chooses to share
Mode 2 Embedded workplace assistants Reading what an embedded assistant can see through the user's identity Whether the candidate spots access inherited from the user
Mode 3 Agentic work tools Supervised practice under a mandate manifest, first draft by the learner Verification of the tool's output against seeded errors
Mode 4 Built AI applications Threat modelling and evaluation of a built application, including retrieval and tool use The unaided threat model
Mode 5 Autonomous production agents Designing identity, containment and the stop path for an agent with its own permissions The boundary design and the flawed agent proposal

Hiring profiles

A hiring profile is written from the role charter of Chapter 4 and the framework of Chapter 21, never from a list of tools, so that it says what the post must decide and at what level. A profile that begins with products tests familiarity with last year's estate and screens out people who learn quickly.

It carries five parts: the post and its charter, so that candidates can read the decision rights they would hold; the required level per domain, separating what the post-holder must bring from what the organisation will train in the first year, since a candidate Advanced in design and Foundation in law may be the better hire for a post that depends on design; the ECSF profile, Cybersecurity Architect, so that advertisement and job evaluation share a European vocabulary (41, ENISA, 2022); what screening will not filter on, namely tool names, years of experience and a named certificate; and how candidates will be assessed.

Two European considerations shape it. First, AI used to recruit or select people, in particular to filter applications and evaluate candidates, is a high-risk AI system under Annex III, point 4(a), of the AI Act, and AI used to evaluate performance and behaviour at work falls under point 4(b) (1, European Union, 2024). An organisation that adds AI ranking to its hiring funnel takes on a deployer's duties for a high-risk system. For a post with a small candidate pool the simpler design is human review of every application against the profile; Article 22 of the GDPR in any case restricts decisions based solely on automated processing that significantly affect a person (5, European Union, 2016).

Second, employee representation. In Germany the Works Constitution Act gives works councils co-determination rights over assessment principles and selection guidelines (§§ 94 and 95), as over monitoring devices (Chapter 13), and a right of consent to hiring, which the council may refuse on stated grounds (§ 99) (22, Germany, 2001). Article 88 of the GDPR lets member states set specific rules for employment data (5, European Union, 2016). Consult on the profile, exercise and rubric before the first candidate sits it.

Interview exercises

An interview is a prediction about future work. Schmidt and Hunter's review ranked work-sample tests and structured interviews among the strongest predictors of job performance, well above length of experience (220, Schmidt & Hunter, 1998), and Sackett and colleagues, who revised many estimates downward, placed structured interviews at the top (221, Sackett et al., 2022). A candidate should therefore do a piece of the work under conditions the organisation can score, and discuss their decisions in a structured conversation.

The work now includes an assistant. A candidate who is excellent unaided and credulous with an assistant is a risk. Assistance helps inside the frontier of what the model can do and harms outside it, where the user cannot see the edge (Chapter 15) (95, Dell'Acqua et al., 2023). The exercise therefore runs in two conditions. Unassisted, it shows what the candidate can design and see. Assisted, it shows what the candidate can verify, and whether they accept what a fluent assistant proposes. The difference between the two scores is information about judgement.

Three exercises carry most of the weight. Design asks for the boundary of a described agent: identity, permissions, containment, policy decision point, stop path, evidence. Review of a flawed AI proposal gives a pull-request description for an agent change with seeded flaws, and asks what the candidate would accept, change or refuse, and why. An unassisted threat model covers a described system in the shared vocabulary, with controls and owners. A structured interview closes with fixed questions on past decisions, including one the candidate reversed and one on which they were overruled.

Practical guide: Designing an interview exercise that tests judgement with and without AI

Purpose. Produce an exercise that separates candidates by judgement rather than recall, runs fairly in two conditions and leaves a record the organisation can review.

Roles. The head of security architecture owns the exercise. Two raters score independently. The HR hiring lead owns the process and the candidate data, the data protection officer reviews the data flows, and employee representatives are consulted where law or agreement requires.

  1. Choose the decision. Pick a decision from the role charter that the post will make, for example the boundary of a Mode 5 agent acting on a core system.
  2. Fictionalise the estate. Write the scenario for a fictional organisation modelled on the real one, so that no confidential configuration is disclosed and no internal candidate has an advantage.
  3. Seed the flaws. Seed five to eight flaws of different kinds: structural (a policy point inside the agent's own process), authority (a credential not bound to the task), evidential (evidence attested, not generated), scope (an obligation mapped for one jurisdiction and assumed for all) and reversibility (a high autonomy level for an irreversible action). Add one decoy, an unusual but sound choice, to see whether the candidate refuses it for no reason. Keep the catalogue in a restricted file.
  4. Write the scoring criteria. Score whether the candidate found each flaw, explained its consequence, proposed a remedy and said how confident they were. Do not score for matching a model answer; several designs are sound.
  5. Run two conditions. Run design and threat model unassisted, about two and a half hours as a default. Run the review in two equivalent versions, one unassisted and one with the approved enterprise tool in a sandbox, in counterbalanced order, about forty-five minutes each.
  6. Calibrate and rotate. Raters score two past answers first and reconcile differences; vary the scenario each round, because answers leak.
  7. Handle the data. Keep unsuccessful candidates' answers and scores for six months by default, or as law and agreement allow, tell candidates what is kept and offer reasonable adjustments.
  8. Close the loop. At six and twelve months compare each hire's exercise scores with their assessment in the competence record, and revise the exercise.

Definition of done. A written exercise with a flaw catalogue, scoring rubric, calibrated raters, agreed data policy and a scheduled review of its predictive value.

Worked example: Hansa Mutual's hiring profile and exercise for the Polish service centre

The post is the security architect embedded at the Polish service centre, through which the claims-triage agent works. It falls vacant in January 2027, and the group hires from outside because no internal candidate has Advanced experience of a Mode 5 agent acting on a core system. The new holder starts on 1 June 2027 (Chapter 27). The decision and the consultation outcome are recorded as AIDR-0584.

# hiring/profiles/HP-HM-2027-01.yaml (illustrative)
id: HP-HM-2027-01
decision: AIDR-0584
post: security architect embedded at the Polish service centre
charter: roles/security-architect.yaml     # embedded service-centre charter
reports_to: head-of-security-architecture
ecsf_profile: Cybersecurity Architect
required_levels:
  design: advanced
  people: advanced
  adversary: practitioner
  code: practitioner
  ai: practitioner
  law: foundation                          # trained in the first twelve months
not_screened_on: [tool names, years of experience, a named certificate]
screening:
  method: human review against the required levels
  ai_ranking_of_candidates: false
exercise:
  id: IX-HM-2027-01
  sittings:
    - name: unassisted-design
      minutes: 150
      parts: [boundary-design-90, threat-model-60]
      ai: none
    - name: proposal-review
      minutes: 90
      parts:
        - {version: A, minutes: 45, ai: none}
        - {version: B, minutes: 45, ai: approved-enterprise-tier-in-sandbox}
      order: counterbalanced
  interview: {minutes: 45, structured: true}
  scoring: criteria-based, two independent raters, calibrated on past answers
  seeded_flaws: 7
  decoys: 1
  catalogue: restricted
candidate_data:
  retention_unsuccessful_months: 6
  consulted: [german-works-council, polish-employee-representatives]

The scenario is a fictional insurer, not Hansa. The proposal under review would let a claims-triage agent act for a new market through a service-centre token. Among its seeded flaws is a token that does not carry the entity on whose behalf the handler acts, so that the claims adapter could not refuse a mismatch between entity and market, the control Hansa's own platform applies. The decoy is a read-only service identity with a broad scope over non-personal telemetry, justified in the proposal. Candidates who find the missing binding, explain its consequence and ask for evidence rather than assertion score highly in either condition. Version B is the telling one: a candidate who accepts an assistant's confident verdict that the proposal is sound has shown what the organisation needs to know before giving them an agent team.

The works council and the Polish employee representatives are consulted on the profile, exercise and rubric before the first interview. The agreement limits the results to the hiring decision and the new hire's learning path, and bars their use for ranking existing staff.

Upskilling or hiring

AI Governance, Chapter 14, concluded that upskilling is the strategy and hiring is for scarce specialisms and for the first AI architect (168, Nordqvist, 2026). For the security architect the same rule holds. The people already in the estate know the systems and suppliers, which no hire brings in a year, and judgement about boundaries is grown on real decisions under review. Four questions settle a case.

Question Points to upskilling when Points to hiring when
Is there a person with a starting point and the appetite? Yes: engineer, enterprise architect, developer or auditor in the estate No candidate with a plausible path within a year
How soon is the competence needed? A year is acceptable The competence is needed now, for a live agent or a supervisory deadline
Is it scarce in the market? Common, and trainable from the framework Rare, and failing without it carries regulatory or operational consequence
What does the team need to learn from the person? The team needs continuity and context The team needs a pattern it has never seen

Upskilling costs protected time, mentor hours and reduced output, and yields a person who stays and knows the estate; a hire costs a search, a premium and a year of onboarding, and yields a pattern the team lacks. The shortages that ISC2 and ISACA report in their workforce studies make external hiring slow and its outcome uncertain (89, ISC2, 2024) (90, ISACA, 2024), which is the observable reason to keep upskilling as the main strategy.

Contracted architects are a third route. The author works as a self-employed consultant in the Kvadrat network (172, Kvadrat, n.d.), which is a reason to state the condition plainly: an engagement that leaves nothing behind buys output and adds dependence. Require pairing with an internal learner, decisions recorded in the architecture repository and a handover the competence record can verify.

The constraints differ by setting. A public authority hires within fixed pay scales and often security vetting, and buys consultancy through framework agreements, which makes short engagements slow. A multinational group can pay market rates and move people, but must decide which competences sit at the centre (shared platform boundaries) and which with the entity (holding a boundary in one market and explaining it to that supervisor).

The entry route

Part of the question is how anyone becomes a security architect at all. Brynjolfsson, Li and Raymond found that an AI assistant raised the productivity of customer-support agents most among the least experienced (96, Brynjolfsson et al., 2025). That helps a junior and endangers how juniors learn, since unrestricted assistance can raise practice performance while lowering unaided performance (114, Bastani et al., 2025), and AI Threat, Chapter 14, concluded that automating junior work removes the route by which experts are made (171, Nordqvist, 2026). A Stanford study found a relative decline in employment among the youngest workers in the occupations most exposed to AI (222, Brynjolfsson et al., 2025). It rests on United States payroll data and is not specific to security, so it supports a hypothesis for this profession and does not establish one.

Observable: the evidence on skill formation and early-career employment points the same way. Expected: the route into security architecture through junior drafting and review narrows as assistants take that work, since the trend is documented and Articles 14 and 26 of the AI Act keep the demand for competent overseers; Chapter 23 treats this as one of its scenarios. Speculation: that simulation and exercise could replace most junior work as the main route into the profession; no evidence for that exists yet.

An organisation need not settle the outlook to act. Four measures apply now. Recruit from the four adjacent starting points rather than for a first job. Reserve learning tasks for the learner, as Hansa's graduate programme does (AIDR-0470; AI Threat, Chapter 7), so that the learner drafts the threat model or the review first (171, Nordqvist, 2026). Give every learner a rotation through verification, including the seeded-error drills of Chapter 15. And let learners shadow the design authority and decision forums, because decisions made in a room are learned there and written nowhere.

Careers that stay technical

A role of deep judgement needs a career that rewards depth. AI Governance, Chapter 14, named two paths that apply to the security architect: a specialist ladder, and a path between building and verifying (168, Nordqvist, 2026).

The specialist ladder lets a security architect rise in grade and pay without line management; the levels of the framework give the steps and the competence record the evidence. For Nordvik, where pay scales are fixed, the record gives job evaluation an evidence base; for Hansa it supports a dual ladder in which an Expert domain architect is not a lesser role than the head of security architecture.

The path between building and verifying matters because an architect who designs a boundary and then assures it marks their own work. Moves between the two are valuable, since a builder knows how a platform fails and an assurer learns what evidence is cheap to produce. Record the move and apply a cooling-off period before a person assures a system they helped to build. AI Governance, Chapter 14, gave twelve months as an example, which is a sensible default, adapted to team size and the independence the supervisor expects.

Nordvik Region and Hansa Mutual

Nordvik cannot easily hire within its fixed pay scales and security vetting, and it has one post. It upskills the post-holder along LP-NR-2027-01 with an external mentor, builds a deputy from the platform team to reduce the single point of failure, and agrees its assessment and retention rules with employee representatives before the first assessment. What it cannot remove alone is the lack of a second opinion.

Hansa hires for scarce specialisms and upskills its embedded architects; for the Polish service centre post it hires from outside under HP-HM-2027-01. Its challenge is consistency: one exercise and one framework must give comparable results across seven jurisdictions and two sites, and the mapping to ECSF is what lets it show each of them that they do.

Summary

This chapter turned the framework of Chapter 21 into practice. People reach the role from four starting points, and a learning path begins with a gap assessment against the six domains, not a course catalogue. It rests on practice on real artefacts, manufactured feedback, levels gated by demonstration and protected unassisted practice, in which the learner drafts first and the assistant comes second. Certifications validate knowledge on the day of an examination and are a floor that is cheap to read; practical demonstration is the evidence that decides.

AI literacy under Article 4 is the floor for the architect, who also designs what literacy and oversight mean for others, so it becomes testable objectives tied to artefacts in the competence record. Hiring profiles are written from the charter and the framework, and interview exercises are work samples run unassisted and assisted, because the difference shows what a candidate can verify. Upskilling is the main strategy and hiring is for scarce specialisms. The entry route is under pressure that is observable in studies of skill formation and early-career employment, and the organisation controls four responses: adjacent starting points, reserved learning tasks, rotation through verification and shadowing of forums.

The chapter concerned Shift 4, from sole author to conductor of an AI team, because an architect who conducts an AI team must be able to verify it, and verification is learned and evidenced by practice. It concerned Shift 1, from documents to code, because learning paths, hiring profiles, exercises and competence records are artefacts under version control. A specialist ladder and recorded moves between building and verifying, with a cooling-off period, give careers a technical place to lead.

Chapter 23 asks whether there will be a security architect in 2036. It keeps a horizon register for the role, in which the effect of AI on entry routes is one of the labelled trends, and four scenarios in all of which the learning and hiring measures of this chapter are no-regret.

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 Commission (2026). AI literacy: questions and answers. (4, European Commission, 2026)
  4. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). (5, European Union, 2016)
  5. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (6, European Union, 2022)
  6. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 (DORA). (9, European Union, 2022)
  7. European Parliament and Council of the European Union. Directive 2014/24/EU on public procurement. (18, European Union, 2014)
  8. Federal Republic of Germany (2001). Betriebsverfassungsgesetz (BetrVG) (Works Constitution Act). (22, Germany, 2001)
  9. Petersen, R., Santos, D., Wetzel, K. A., Smith, M. C. & Witte, G. (2020). Workforce Framework for Cybersecurity (NICE Framework). (33, Petersen et al., 2020)
  10. Sherwood, J., Clark, A. & Lynas, D. (2005). Enterprise Security Architecture: A Business-Driven Approach. (38, Sherwood et al., 2005)
  11. The Open Group (2022). The TOGAF Standard, 10th Edition. (39, The Open Group, 2022)
  12. European Union Agency for Cybersecurity (2022). European Cybersecurity Skills Framework (ECSF): Role profiles. (41, ENISA, 2022)
  13. European Union Agency for Cybersecurity (2022). European Cybersecurity Skills Framework (ECSF): User manual. (42, ENISA, 2022)
  14. SFIA Foundation (2024). SFIA 9: The global skills and competency framework for a digital world. (43, SFIA Foundation, 2024)
  15. ISC2 (2024). 2024 ISC2 Cybersecurity Workforce Study. (89, ISC2, 2024)
  16. ISACA (2024). State of Cybersecurity 2024: Survey results. (90, ISACA, 2024)
  17. ISC2. CISSP-ISSAP: Information Systems Security Architecture Professional. (91, ISC2, n.d.)
  18. Dell'Acqua, F. et al. (2023). Navigating the Jagged Technological Frontier. (95, Dell'Acqua et al., 2023)
  19. Brynjolfsson, E., Li, D. & Raymond, L. (2025). Generative AI at Work. (96, Brynjolfsson et al., 2025)
  20. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation. (107, Parasuraman & Manzey, 2010)
  21. Ericsson, K. A., Krampe, R. T. & Tesch-Römer, C. (1993). The Role of Deliberate Practice in the Acquisition of Expert Performance. (108, Ericsson et al., 1993)
  22. Kahneman, D. & Klein, G. (2009). Conditions for Intuitive Expertise: A Failure to Disagree. (109, Kahneman & Klein, 2009)
  23. Lee, H.-P., Sarkar, A., Tankelevitch, L., Drosos, I., Rintel, S., Banks, R. & Wilson, N. (2025). The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers. (111, Lee et al., 2025)
  24. Bastani, H. et al. (2025). Generative AI without guardrails can harm learning. (114, Bastani et al., 2025)
  25. Nordqvist, G. (2025). Architecture as Code. (167, Nordqvist, 2025)
  26. Nordqvist, G. (2026). AI Governance. (168, Nordqvist, 2026)
  27. Nordqvist, G. (2026). AI Red Team. (170, Nordqvist, 2026)
  28. Nordqvist, G. (2026). AI Threat. (171, Nordqvist, 2026)
  29. Kvadrat AB. Kvadrat – Sweden's largest network of self-employed consultants. (172, Kvadrat, n.d.)
  30. Schmidt, F. L. & Hunter, J. E. (1998). The Validity and Utility of Selection Methods in Personnel Psychology. (220, Schmidt & Hunter, 1998)
  31. Sackett, P. R., Zhang, C., Berry, C. M. & Lievens, F. (2022). Revisiting meta-analytic estimates of validity in personnel selection. (221, Sackett et al., 2022)
  32. 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)