Keeping the Craft: Deskilling, Judgement and the Architect Who Still Can

The three preceding chapters gave the security architect an AI team: assistants in Modes 1 to 3 that draft decision records, policies and threat models (Chapter 12), an agent team that reviews pull requests under a mandate manifest (Chapter 13), and a review protocol that does not trust the proposer (Chapter 14). This chapter deals with the condition on which all three depend. An architect who can no longer do the craft without AI cannot verify what AI proposes, because verification needs the knowledge that authorship used to exercise. The chapter concerns Shift 4, from sole author to conductor of an AI team, and it argues that the shift is safe only if the conductor can still play. It sets out what the evidence says about deskilling, defines judgement in security architecture and the conditions under which it can be trusted, and prescribes the practices that keep it: deliberate practice, no-AI exercises, seeded-error drills, apprenticeship by design, autonomy paced to the skills available to supervise it, and reporting that measures the craft without surveilling the people who hold it.

The chapter builds on the conclusion of AI Red Team, Chapters 6 and 15, that skills erode when AI does most of the work while supervision and the degraded mode after a stop still need them (170, Nordqvist, 2026), and on the conclusion of AI Threat, Chapters 6 and 14, that automating junior work removes the route by which experts are made (171, Nordqvist, 2026). Those volumes drew the conclusions for analysts, caseworkers and claims handlers. This chapter draws them for the person who designs the boundaries the analysts and agents work within.

Figure 15.1: The craft-keeping cycle, in which unassisted practice, AI-assisted work, seeded-error drills, review-quality measurement and mentoring feed the competence records that pace the autonomy of the architect's agents.

The ironies of automation, again

Lisanne Bainbridge observed in 1983 that automation takes over the tasks that are easy to specify and leaves people to monitor the system and to take over when it fails, and that both of those remaining tasks need skills which the automation itself erodes (106, Bainbridge, 1983). Operators who rarely control a process lose the fluency to do so; people who watch a system that almost always works become poor at noticing when it does not; and the moments of intervention are, by construction, the difficult ones. AI Threat, Chapter 14, set out her four ironies in full and applied them to claims handling and casework (171, Nordqvist, 2026). Applied to the security architect, they take a sharper form, for three reasons.

The first is that the architect's residue is the hardest part of the work. When an agent drafts the threat model, the first version of the egress policy and the mapping of a control to an article of DORA, the architect is left with the judgement calls: whether the trust boundary is in the right place, whether a supplier's stop path really lies outside the supplier's system, whether a permission is broader than the task requires. These are the calls an architect learned to make by drawing hundreds of data-flow diagrams and writing hundreds of rules by hand.

The second is that the architect's interventions cluster in the worst moments. When a stop path is used, under the design of AI Platform and Security, Chapter 19, and of Chapter 10 of this book, the agents that drafted and reviewed are among the things stopped (169, Nordqvist, 2026). The architecture work does not stop with them. An incident that requires a boundary to be redesigned in an afternoon, or a supervisor's question that must be answered from first principles, arrives exactly when the assistance is unavailable or untrusted. AI Red Team, Chapter 6, described this degraded mode and drew the conclusion that the people who supervise security AI must keep the skill to work without it (170, Nordqvist, 2026).

The third is that the adversary works on the residue. Attackers look for what defenders do not see: the trust relationship nobody modelled, the delegated token whose scope nobody questioned, the technique outside the catalogue an assistant was trained on. A threat model that lists the familiar ATT&CK and ATLAS techniques for a familiar architecture is the kind of output generative AI produces well. The architect's value lies in the threat the list omits, and recognising an omission is harder than checking an item.

Raja Parasuraman and Dietrich Manzey's integrative review explains why good intentions do not protect against this. They found that complacency, the failure to monitor automation adequately, and automation bias, the tendency to follow automated advice in place of vigilant search for information, both arise from how attention is allocated, occur in naive and expert participants alike, cannot be prevented by training or instructions, and affect teams as well as individuals (107, Parasuraman & Manzey, 2010). A systematic review of automation bias in clinical decision support by Kate Goddard and colleagues found the same pattern in practice: users accepted incorrect advice they would not otherwise have followed, and the effect depended on their experience, their confidence and trust in the system, the complexity of the task and their workload (201, Goddard et al., 2012). Experience and workload moderate the bias in that review, and the review queues of Chapter 14 are a high-workload, high-trust setting by design.

What the evidence shows

The evidence on generative AI and human thinking is recent, mostly short term and of mixed design. Read side by side, it points in a consistent direction, and its limits matter as much as its findings.

The survey of 319 knowledge workers by Hao-Ping Lee and colleagues, covering 936 real examples of generative AI use at work, found that higher confidence in the AI was associated with less critical thinking and higher confidence in one's own ability with more, and that critical thinking shifted from producing work towards verifying, integrating and stewarding it (111, Lee et al., 2025). For the architect the second finding is the more important: the job moves to verification, and verification is where over-confidence in the tool does most damage. Michael Gerlich's survey of 666 participants found frequent AI use correlated with lower critical-thinking scores, mediated by cognitive offloading (113, Gerlich, 2025), and the MIT Media Lab experiment by Nataliya Kosmyna and colleagues, with 54 participants, found, in a preprint, the weakest neural engagement and poorest recall of their own essays among those who wrote with an LLM (112, Kosmyna et al., 2025).

Field and laboratory experiments add the effect of design. In a randomised trial with nearly a thousand secondary-school students, Hamsa Bastani and colleagues found that unrestricted access to a chatbot improved performance during practice but lowered it once access was removed, while a tutor version that gave hints rather than answers largely avoided the harm (114, Bastani et al., 2025). Erik Brynjolfsson, Danielle Li and Lindsey Raymond found that an AI assistant for customer-support agents raised productivity most for the least experienced workers, with small gains in speed and small declines in quality for the most experienced (96, Brynjolfsson et al., 2025). Fabrizio Dell'Acqua and colleagues found that consultants using AI did better on tasks inside the frontier of what the model could do, and were 19 percentage points less likely to reach a correct solution on a task chosen to lie outside it (95, Dell'Acqua et al., 2023). The frontier is jagged and invisible from inside the task, and recognising which side of it a problem lies on is an act of judgement.

The METR trial of experienced open-source developers by Joel Becker and colleagues, whose figures Chapter 12 reports, is the closest to the architect's own situation (93, Becker et al., 2025). The lesson for this chapter is not the slowdown it measured, which may change with tools and tasks, but the gap between perception and measurement: the developers still believed afterwards that they had been sped up. Experienced professionals could not tell from the inside what the tool was doing to their work.

One study speaks directly to expert deskilling. In an observational study in four Polish endoscopy centres, Krzysztof Budzyń and colleagues compared the adenoma detection rate of experienced endoscopists in standard colonoscopies, performed without AI, before and after AI-assisted colonoscopy was introduced in their centres; the rate fell from about 28 per cent to about 22 per cent (207, Budzyń et al., 2025). It is a single observational study in a perceptual task, but it is the first clinical evidence that experts' unassisted performance can decline within months of routine AI assistance.

Evan Risko and Sam Gilbert's review of cognitive offloading supplies the frame for reading all of this: offloading is usually a rational strategy, and its value depends on whether people judge accurately what they can and cannot do without the external aid (110, Risko & Gilbert, 2016). The problem is not that the architect uses AI. It is that the architect's own estimate of what they could still do unaided is not checked against anything.

What the studies did not measure is as important. None followed security architects, or any architects. Most measured effort, recall or self-report rather than the quality of consequential decisions, and none followed professionals over years. Reduced effort and reduced checking among those who trust the tool are therefore observable in early studies with limited samples. Long-term deskilling of experts who supervise AI is expected, supported by Bainbridge's mechanism, by the automation-bias literature and by the first clinical evidence, but not yet measured over years. The loss of the route by which experts are made is expected as well, and it is the main reason this chapter prescribes apprenticeship by design rather than waiting for the evidence.

What judgement is

The book's thesis rests on a claim that accountable human judgement is the scarce part of the role, and the claim needs a working definition. In security architecture, judgement has three parts.

The first is recognising what matters: seeing, in a design, the trust boundary, the asset, the delegated authority or the dependency on which the security of the whole turns, and seeing what is missing. The second is weighing: choosing between options whose costs and risks are not commensurable, against a risk appetite, under legal constraints and with incomplete information, and preferring reversible over irreversible choices where the evidence is thin. The third is answering for it: being able to state the reasons to a board, a supervisor, an auditor or a court, and to stand behind them. Knowledge feeds all three, and AI can supply much of the knowledge. The recognition, the weighing and the answering remain with a named person, because the role charter of Chapter 4 assigns the decision rights to a person and not to a tool.

Daniel Kahneman and Gary Klein, writing from opposite traditions, agreed on when intuitive expertise can be trusted: when the environment is regular enough to be predictable, and when the person has had adequate opportunity to learn its regularities through prolonged practice with timely and clear feedback (109, Kahneman & Klein, 2009). Security architecture meets the first condition only in part and the second poorly. Many regularities are real: certain boundary patterns fail in known ways, and certain combinations of private data, untrusted content and outbound communication are reliably dangerous. Feedback, however, is sparse and delayed. Most designs are never tested by a capable attacker, and when they are, the lesson arrives months later in an incident report written by someone else.

Two conclusions follow. Architects' intuitions must be calibrated deliberately, through feedback the organisation manufactures: red-team findings, security chaos experiments, incident reviews and, as this chapter adds, seeded errors whose answers are known. And AI assistance makes the feedback problem worse, because an architect who did not author a design does not receive even the delayed feedback when it fails. The judgement that must verify the AI is the judgement the AI deprives of practice.

The craft an architect must keep unaided is therefore not everything the role does. It is the set of capabilities without which AI output cannot be checked: drawing trust boundaries and data flows for a new system; deriving threats from them in ATT&CK and ATLAS terms, including the ones no catalogue suggests; writing a policy rule and the tests that prove it; reading a permission or mandate manifest and seeing excess authority; re-deriving a requirement from the article of law it claims to implement; designing a stop path; and explaining a decision to a non-specialist. Chapter 21 places these in the competence framework. This chapter is about keeping them.

Deliberate practice for architects

K. Anders Ericsson, Ralf Krampe and Clemens Tesch-Römer distinguished deliberate practice from work and from play: activities designed specifically to improve performance, which require effort, give feedback and are not inherently enjoyable (108, Ericsson et al., 1993). Their insight matters for architects because ordinary work, however long, does not count. An architect who approves fifty agent proposals a week is working, not practising, and the AI makes it possible to work for years without practising at all.

Architecture as Code (Chapter 18) concluded that competence is managed as a skills matrix by level, from Foundation to Expert, in a development loop of assessment, planning, learning, application, knowledge sharing and measurement, and that certifications validate knowledge while practical demonstration on real delivery shows capability (167, Nordqvist, 2025). Deliberate practice is the learning and application step of that loop for the craft-critical capabilities, and its records are the practical demonstration that the competence records of Chapter 21 rely on.

Deliberate practice for architects takes three forms. Unassisted design work means doing a real piece of architecture from the blank page: a boundary design, a containment profile, a set of policy rules with tests. Drafting first means writing the human version of a threat model or decision record before opening the assistant, then comparing the two; the difference between them is the feedback, and recording which items each version missed turns the comparison into a measurement. Review without the assistant means taking a pull request the agent team has already reviewed, reviewing it unaided, and comparing findings. All three are cheap if scheduled and fail if left to goodwill, because the assisted path is always faster in the week it is chosen.

Practical guide: A quarterly craft-keeping programme for a security architecture team

Purpose. Keep each architect able to perform the craft-critical capabilities unaided, and give the team evidence that it can.

Roles. The head of security architecture owns the programme. Each architect plans and records their own practice. A peer, or for a single post an external peer, gives feedback. Employee representatives are consulted on how results are reported. The owner of the delegation register receives the team-level results.

Steps.

1. List the craft-critical capabilities. Start from the seven in the previous section and add those specific to the estate. Default: no more than ten, each with a short description of what unaided performance looks like.
2. Reserve the time. Default: half a day per architect per fortnight, protected in the calendar and in the team's capacity plan, about five per cent of working time. Reduce it only by a recorded decision of the programme owner.
3. Draft first on substantive work. For every threat model and every AI Decision Record above the lowest risk tier, the architect writes a first version unaided before using the assistant. Default: a one-page draft, timeboxed to two hours.
4. Run one unassisted review per architect per month on a pull request the agent team has already reviewed, and compare findings within a week.
5. Run one seeded-error drill per quarter for the team (see the guide below).
6. Run one degraded-mode exercise per half-year, in which the agent team is stopped through its stop path and the team works its real review queue unaided for a full day.
7. Pair across specialisms. Each quarter, each architect does one unassisted exercise outside their domain, reviewed by the domain owner.
8. Record practice in the competence record (CMP-*) as evidence, in the architect's own words, never as a score.
9. Review the programme every six months against drill results, degraded-mode findings and incidents.

Definition of done. The capabilities are listed; time is reserved in the plan; at least two quarters of practice, drills and comparisons have run; one degraded-mode exercise has run; and results reach the delegation register owner at team level. Adapt the defaults to the stakes: a team whose agents act at Level 3 Bounded needs more practice than one whose agents only draft.

The programme lives in version control beside the role charter and the mandate manifest, so that changes to it are reviewed like any other control:

craft_programme:
  id: CKP-HM-SA-2027
  status: illustrative
  owner: head of security architecture
  applies_to: ROLE-HM-*
  linked_mandate: MND-HM-01
  capabilities:
    - id: CC-01
      name: Draw trust boundaries and data flows for a new system
    - id: CC-02
      name: Derive threats in ATT&CK and ATLAS terms, including uncatalogued ones
    - id: CC-03
      name: Write a policy rule and the tests that prove it
    - id: CC-04
      name: Read a permission or mandate manifest and find excess authority
    - id: CC-05
      name: Re-derive a requirement from the legal article it implements
    - id: CC-06
      name: Design a stop path outside the system it stops
    - id: CC-07
      name: Explain a decision to a board or supervisor without notes
  cadence:
    protected_practice_hours_per_fortnight: 4
    draft_first: [threat_model, aidr_above_tier_1]
    unassisted_review_per_architect_per_month: 1
    seeded_error_drill_per_quarter: 1
    degraded_mode_exercise_per_half_year: 1
  evidence:
    recorded_in: competence_record
    form: narrative_with_links
    scores_stored: false
  reporting:
    level: team
    agreed_under: AIDR-0556
  review_months: 6

No-AI exercises and seeded-error drills

Two kinds of exercise give practice the feedback that real work lacks. A no-AI exercise asks whether the team can do the work without its assistance. Its strongest form is the degraded-mode exercise: the agent team is stopped through its stop path, as it would be in an incident, and the architects work the real review queue unaided for a day. The exercise answers two questions at once. It tests the stop path, which a stop path never used is not known to provide, and it tests the reversibility of the delegation. AI Threat, Chapter 26, concluded that small delegations erode skill, process, capacity and memory until the documented fallback no longer exists, and that a delegation register with reversibility tests is the response (171, Nordqvist, 2026). The architects' own delegation to their agents belongs in that register like any other, and the degraded-mode exercise is its reversibility test.

A seeded-error drill asks whether the reviewers still catch what matters. Known flaws are placed in proposals that reach the review queue, and the drill measures how many are found. AI Threat, Chapter 14, introduced seeded errors for claims handlers. For architects the flaws are design flaws: an egress rule broader than its purpose, a permission manifest that grants write where read suffices, a threat model that omits a trust boundary, a decision record that cites the wrong article, a containment profile that relies on the agent's instructions rather than on enforcement outside the agent. They are defensive by construction: each is a mistake an architect must catch, not a technique an attacker could reuse.

Practical guide: Designing a seeded-error drill

Purpose. Measure, with known answers, whether the people who approve AI-proposed architecture changes still catch the errors that matter, and give them feedback.

Roles. The drill designer, a senior architect rotated each quarter, builds the seeds and knows the key. The platform team implements the merge guard. Reviewers take part without knowing which items are seeded. The head of security architecture receives the team-level result. Employee representatives agree the reporting before the first drill.

Steps.

1. Choose the capabilities under test from the craft programme. Default: two per drill.
2. Build the error catalogue from real findings. Use past review findings, red-team and chaos-experiment results and incident lessons, so that the seeds resemble errors that occur. Default: at least eight seeds per drill, each validated by a second senior architect.
3. Inject only into a drill channel. Seeds reach reviewers as ordinary-looking pull requests in a drill repository mirrored from the real one, or as agent comments marked in metadata the reviewer does not see. A merge guard at the policy decision point blocks any change carrying the seed marker from reaching a production branch.
4. Set the rate. Default: seeds make up no more than one item in fifty of a reviewer's queue in the drill window, so that the drill does not change the base rate the reviewers expect.
5. Reveal promptly. Default: reveal each seed to the reviewer within one working day of their decision, with the flaw, why it matters and how it could have been seen.
6. Measure detection at team level. Record which seeds were caught, missed or caught for the wrong reason, aggregated per capability.
7. Act on the result. A capability with low detection becomes the focus of the next quarter's practice, and if detection falls below the threshold for an action the agents perform at Level 3 Bounded, the autonomy of that action is reviewed (see the section on pacing autonomy).
8. Retire seeds that leak. Seeds that reviewers have learned to recognise by form rather than substance are replaced.

Definition of done. Seeds are validated and catalogued; the merge guard has been tested; reviewers have received feedback on every seed; the team-level result is recorded; and the next quarter's practice reflects it.

seeded_error_drill:
  id: SED-HM-2027-Q1
  status: illustrative
  designer: rotating senior architect
  capabilities_under_test: [CC-02, CC-04]
  channel:
    repository: arch-review-drill
    mirrored_from: arch-review
    seed_marker: drill-seed
  merge_guard:
    enforced_at: policy decision point
    rule: deny merge to protected branches when seed_marker present
    tested_on: 2027-01-08
  seeds:
    - id: S-01
      capability: CC-04
      flaw: claims-triage tool scope grants write on payment records where read suffices
      source: 2026 review finding
    - id: S-02
      capability: CC-02
      flaw: threat model omits trust boundary between service centre and group platform
      source: red-team finding
  rate_limit: one seed per 50 queue items per reviewer
  reveal_within_working_days: 1
  reporting:
    level: team
    per_capability: true
    individual_results: shown_to_reviewer_only_not_stored
  threshold_for_autonomy_review: 0.8

Worked example: Nordvik Region's no-AI exercise calendar

The following calendar is illustrative. Nordvik Region has one security architect, no agent team (Chapter 13) and a Mode 3 tool under MND-NR-01 on open-weight models on the Region's reserved capacity. There is no agent team to drill against, the seeded-error checks in the architect's own review belong to Chapter 14, and there is no colleague in the unit to learn from. The architect therefore builds feedback from outside: with the security architect of a neighbouring region, under a written exchange agreement between the two authorities, and with the Region's enterprise architect. Because architecture information describes each region's defences, peer exercises use synthetic systems or published designs, never either region's real architecture. The calendar is kept as part of the competence record CMP-NR-01.

competence_record: CMP-NR-01
section: craft_practice_2027
status: illustrative
holder_role: security architect, CISO security unit
role_charter: ROLE-NR-SA-01
mandate_manifest: MND-NR-01
standing_rules:
  - draft every threat model unaided before using the Mode 3 tool
  - re-derive every tender annex requirement from its legal article unaided
calendar:
  - quarter: Q1
    exercise: unassisted threat model of a synthetic benefits case-handling service
    reviewer: neighbouring region security architect
  - quarter: Q2
    exercise: unassisted review of a supplier design document, compared with the tool's review
    reviewer: enterprise architect, digitalisation unit
  - quarter: Q3
    exercise: tool-free day; stop-path design for a procured agent, written from the blank page
    reviewer: neighbouring region security architect
  - quarter: Q4
    exercise: board-style briefing to the CISO without notes on the year's main decision
    reviewer: chief information security officer
peer_exchange:
  agreement: written exchange agreement between the two regional authorities
  material: synthetic or published designs only
  real_architecture_information_shared: false
evidence_form: narrative with links, kept by the holder
use_in_performance_appraisal: false

The calendar costs about twelve days a year. Set against a single point of failure that holds the Region's boundaries mostly through procurement, it is the cheapest insurance the Region can buy, and Chapter 22 builds the deputy from the platform team on the same exercises.

Mentoring when junior work is automated

AI Threat, Chapters 6 and 14, left open the question this section takes up: how anyone becomes a security architect when the junior work through which architects used to learn has been automated (171, Nordqvist, 2026). Security architects have rarely been trained as juniors in the role itself. They came from security engineering, development, operations or audit, and learned the architect's judgement by doing junior architecture work beside a senior: writing the first threat model, answering the supplier questionnaire, reviewing the routine pull request. That is exactly the work the agent team now drafts.

Jean Lave and Etienne Wenger described learning in communities of practice as legitimate peripheral participation: newcomers learn by taking part in real work, at first in peripheral but genuine tasks, and move towards full participation as their competence grows (208, Lave & Wenger, 1991). Automation removes the periphery. A junior who only watches agents draft and seniors approve is neither peripheral nor participating. The evidence of Brynjolfsson and of Bastani points to the way out: AI can accelerate novices when it scaffolds their work and harm them when it replaces it (96, Brynjolfsson et al., 2025) (114, Bastani et al., 2025).

Apprenticeship by design has four elements. Reserved learning tasks are work the agents could do but the junior does unaided, with a senior's review, during a defined period, as Hansa's graduate policy AIDR-0470 does for claims handlers in AI Threat, Chapter 7 (171, Nordqvist, 2026). Pairing on decisions puts the junior beside the accountable architect when a contested decision is made, with the task of writing its rationale in the decision record. Rotation through review has the junior review agent proposals in parallel with a senior, compare findings and discuss the differences, before the junior approves anything alone. Tutor configuration gives the junior an assistant set to question and hint rather than to answer during the learning period. Chapter 22 owns how people enter the role and the learning paths that lead to it. This chapter owns what a working team does once a junior has joined it.

Worked example: Hansa Mutual's apprenticeship plan for a junior architect at the Polish service centre

The plan below is illustrative. Hansa's group security architecture team adds a junior security architect in 2027, embedded with the team's architect at the Polish service centre, through which the claims-triage agent works. That post falls vacant in January 2027 and is filled from outside from 1 June (Chapter 22), so the apprenticeship starts in September 2027 with the new post-holder as the junior's senior (Chapter 25). The plan is recorded as AIDR-0562, and the junior's competence record is CMP-HM-07. Its first year deliberately includes work the agents could do.

aidr: AIDR-0562
title: Apprenticeship plan for a junior security architect, Polish service centre
status: illustrative
owner: head of security architecture
mentor: security architect embedded at the Polish service centre   # new post-holder from 2027-06-01
start: 2027-09
competence_record: CMP-HM-07
duration_months: 12
lanes:
  unaided:
    - task: threat models for changes to service-centre integrations
      minimum: 10
      months: 1-6
      reviewed_by: mentor
    - task: permission manifests for claims-adapter tool scopes
      minimum: 8
      months: 1-9
      reviewed_by: identity domain architect
  paired:
    - task: write the rationale of contested decisions at the review board
      minimum: 6
      months: 3-12
  parallel_review:
    description: review agent pull requests alongside a senior and compare findings
    months: 4-9
    may_approve_alone: false
  assisted:
    allowed_from_month: 7
    tools: [MND-HM-01 agent team drafts, tutor configuration before month 7]
approvals:
  may_approve_level_3_playbook_changes: false
  sole_approval_from_month: 10
  sole_approval_scope: tier 1 changes only
drills: included in quarterly seeded-error drills from month 4
reporting: team level only, as agreed under AIDR-0556

The plan makes the junior slower in the first six months than an agent-first junior would be. That is its purpose: it builds the competence that later lets the junior approve agent output with judgement rather than presence.

Pacing autonomy to the skills available

AI Red Team, Chapter 6, concluded that autonomy should be paced to the skills available to supervise it (170, Nordqvist, 2026). For the architect's own agents the rule becomes concrete. At Level 1 Assisted and Level 2 Supervised the architect decides or approves each action, and the skill needed is the skill to recognise a wrong proposal. At Level 3 Bounded the agent acts within a playbook without approval of each action, and the review moves to the playbook and its tests, which Chapter 14 identified as needing the deepest scrutiny. A Level 3 playbook can therefore be supervised only by people who could write it unaided.

This yields a gate that belongs in the mandate manifest. An action may be raised to Level 3 Bounded, or kept there, only while at least two named architects hold current evidence in their competence records of writing and testing that playbook unaided, and while the team's detection rate for the related seeds stays above the threshold the programme sets. If either condition fails, the action returns to Level 2 Supervised until it is restored. The same logic freezes further delegation where a reversibility test fails, as AI Threat, Chapter 26, concluded (171, Nordqvist, 2026). Autonomy then rises only as fast as the capacity to supervise it, and falls when that capacity erodes, rather than drifting upwards because the agents are usually right.

The two-person minimum is also why Nordvik Region deferred an agent team in Chapter 13: a single architect cannot provide the redundancy that supervising bounded agent action needs.

Across the usage modes and autonomy levels

The risk of deskilling grows with the share of work done in Modes 2 and 3 and with the autonomy level of the architect's agents. Keeping the craft means a share of work at Level 0 with no assistance at all, and supervision of Level 3 playbooks by people who could write them unaided.

Mode or level	What the AI does in architecture work	Main deskilling risk	Practice that keeps the craft
Mode 1 Conversational assistants	Answers questions, drafts text on request	Recall and research skills weaken	Draft first; verify sources unaided
Mode 2 Embedded workplace assistants	Suggests within documents and tools	Small acceptances become habit	Periodic tool-free days
Mode 3 Agentic work tools	Edits repositories and runs tasks with the architect's identity	Authorship of rules and models lost	Unassisted design work; unassisted reviews
Mode 5 Autonomous production agents	Acts with its own identity, for example evidence collection	Understanding of what the evidence shows fades	Periodic manual evidence checks
Level 1 Assisted and Level 2 Supervised	Proposes; the architect decides or approves	Rubber-stamping	Seeded-error drills; approval-quality metric
Level 3 Bounded	Acts within a playbook	Nobody left who could write the playbook	Two-person unaided-competence gate
Level 4 Autonomous	Not used for architecture work	Not applicable	Not applicable

Reporting without surveillance

The measures in this chapter observe how people work, which makes them a form of workplace monitoring. A drill that feels like an examination teaches people to game it, and a detection rate that reaches an appraisal ends honest participation.

European law gives this concern formal shape. Article 88 of the GDPR allows member states to adopt more specific rules for processing employees' personal data in the employment context, including for the management, planning and organisation of work (5, European Union, 2016). A merge guard that logs who missed which seed is a technical device that can monitor performance, and in Germany it is subject to the works council's co-determination (Chapter 13) (22, Germany, 2001). Article 26(7) of the AI Act requires deployers who are employers to inform workers' representatives before putting a high-risk AI system into service at the workplace, and Annex III, point 4, lists AI systems intended to monitor and evaluate the performance and behaviour of workers among the high-risk systems (1, European Union, 2024). The architectural implication is that the drills and metrics in this chapter should not use an AI system to evaluate individuals at all, and should be designed for consultation from the start rather than adjusted after it.

Three design rules follow. Aggregate by capability, not by person: the team learns that it misses omitted trust boundaries, not who missed them. Give individual results to the individual only: each reviewer sees their own seeds revealed, as feedback, and the result is not stored with their name. Agree the rules before the first drill, in writing, including that results are not used in performance appraisal, and record the agreement beside the programme.

Small teams test these rules. AI Threat, Chapter 14, set a minimum group size of eight for Hansa's oversight-quality metric for claims handlers (171, Nordqvist, 2026). A team of six architects falls below it, so Hansa reports drill results per capability and per quarter, with no breakdown by site or domain, and never for a group of fewer than five reviewers in a drill. For a single post, team-level reporting is individual reporting, so Nordvik's architect keeps the practice record in the competence record under their own control and reports only that the calendar ran.

Nordvik Region and Hansa Mutual

For Nordvik Region, keeping the craft is a problem of isolation. The single post has no one to learn from and no one to be compared with, and the Mode 3 tool under MND-NR-01 is the only help available every day. The architect therefore drafts first, re-derives tender requirements from their legal articles, arranges peer exercises on synthetic designs and records the calendar in CMP-NR-01, as part of the competence plan the regional director commissioned in AIDR-0500. The deputy that Chapter 22 builds from the platform team follows the same exercises, which also begins to reduce the single point of failure.

For Hansa Mutual, keeping the craft is a problem of scale and speed. The agent team under MND-HM-01 produces more proposals than six architects can review in depth, so the team rotates unassisted reviews, runs quarterly seeded-error drills, stops the agent team twice a year for a degraded-mode day and gates every Level 3 Bounded action on two architects who can write its playbook unaided. It designs the apprenticeship of AIDR-0562 and reports drills per capability at team level only, under the agreement with the works councils recorded in AIDR-0556.

Nordvik must manufacture feedback for one person from outside the organisation; Hansa must stop a capable team from drifting into approval without judgement, in a way that employee representatives in several jurisdictions will accept.

Summary

This chapter concerns Shift 4, from sole author to conductor of an AI team, and it sets the condition on which that shift is safe: the conductor must still be able to play. An architect who cannot do the craft without AI cannot verify what AI proposes, because verification needs the knowledge that authorship exercises. Bainbridge's ironies apply to the architect with particular force: the residue left to the architect is the hardest part of the work, interventions cluster in the moments when the agents are stopped or untrusted, and the adversary works on the omissions that only judgement recognises.

The evidence is early but consistent. Reduced effort and checking among those who trust the tool are observable, and experienced professionals misjudge from the inside what the tool does to their work. Expert deskilling is expected, with its first clinical evidence, as is the loss of the route by which experts are made. Judgement in security architecture means recognising what matters, weighing it and answering for it, and because the field gives sparse and delayed feedback, the organisation must manufacture that feedback deliberately.

The response is a craft-keeping cycle under version control: protected time for unassisted practice, drafting first, reviews without the assistant, seeded-error drills behind a merge guard, degraded-mode exercises that double as reversibility tests, apprenticeship by design with reserved learning tasks, and a gate that keeps an agent's action at Level 3 Bounded only while two architects could write its playbook unaided. All of it is reported by capability at team level, agreed with employee representatives, and never used for appraisal.

Part III has described the architect's AI team: the architect's own use of AI, the agent team, the verification of its proposals and the craft that makes verification possible. Chapter 16 opens Part IV by placing the architect in the organisation, mapping the boundaries between the security architect, the CISO, the enterprise architect, the AI architect and the platform and product teams.

Sources

1. Bainbridge, L. (1983). Ironies of automation. Automatica. (106, Bainbridge, 1983)
2. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors. (107, Parasuraman & Manzey, 2010)
3. Goddard, K., Roudsari, A. & Wyatt, J. C. (2012). Automation bias: a systematic review of frequency, effect mediators, and mitigators. Journal of the American Medical Informatics Association. (201, Goddard et al., 2012)
4. 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. CHI 2025. (111, Lee et al., 2025)
5. Gerlich, M. (2025). AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking. Societies. (113, Gerlich, 2025)
6. Kosmyna, N. et al. (2025). Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task. arXiv. (112, Kosmyna et al., 2025)
7. Bastani, H. et al. (2025). Generative AI without guardrails can harm learning: Evidence from high school mathematics. PNAS. (114, Bastani et al., 2025)
8. Brynjolfsson, E., Li, D. & Raymond, L. (2025). Generative AI at Work. The Quarterly Journal of Economics. (96, Brynjolfsson et al., 2025)
9. Dell'Acqua, F. et al. (2023). Navigating the Jagged Technological Frontier. Harvard Business School Working Paper. (95, Dell'Acqua et al., 2023)
10. Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR. (93, Becker et al., 2025)
11. Budzyń, K. et al. (2025). Endoscopist deskilling risk after exposure to artificial intelligence in colonoscopy: a multicentre, observational study. The Lancet Gastroenterology & Hepatology. (207, Budzyń et al., 2025)
12. Risko, E. F. & Gilbert, S. J. (2016). Cognitive Offloading. Trends in Cognitive Sciences. (110, Risko & Gilbert, 2016)
13. Kahneman, D. & Klein, G. (2009). Conditions for Intuitive Expertise: A Failure to Disagree. American Psychologist. (109, Kahneman & Klein, 2009)
14. Ericsson, K. A., Krampe, R. T. & Tesch-Römer, C. (1993). The Role of Deliberate Practice in the Acquisition of Expert Performance. Psychological Review. (108, Ericsson et al., 1993)
15. Lave, J. & Wenger, E. (1991). Situated Learning: Legitimate Peripheral Participation. Cambridge University Press. (208, Lave & Wenger, 1991)
16. European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). (5, European Union, 2016)
17. Federal Republic of Germany (2001). Betriebsverfassungsgesetz (BetrVG). (22, Germany, 2001)
18. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 (Artificial Intelligence Act). (1, European Union, 2024)
19. Nordqvist, G. (2025). Architecture as Code. (167, Nordqvist, 2025)
20. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (169, Nordqvist, 2026)
21. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (170, 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)