Design Authority, Decision Forums and Gates Instead of Meetings

A security architect who must be present at every decision has become a queue, and a queue is not a control. Chapter 16 placed the role among its neighbours. This chapter describes how the architect delegates routine decisions without losing accountability for them: decisions are tiered and routed to the lowest tier that can take them with evidence, pipeline gates enforce, observe and remember, a design authority handles exceptions and contested items, and every exception is a record that expires. It also takes up the question that earlier volumes left open, namely who decides when an AI may change the architecture without per-action approval. The chapter concerns Shift 2, from gatekeeper to boundary designer, because the architect stops saying yes or no at a gate and instead writes the decision rights and the boundaries that apply whoever, or whatever, makes the change. It also concerns Shift 3, from periodic to continuous, at machine speed, because a fortnightly board cannot sit in the path of decisions that adversaries and agents now make in minutes.

Figure 17.1: Decision tiers and the autonomy line. The tier policy routes each class of decision to the lowest tier that can take it with evidence; exceptions expire and fail the gate when they do; agent-proposed architecture changes cross the autonomy line only as far as the policy allows.

The chapter builds on four conclusions from the earlier volumes. AI Governance, Chapter 13, concluded that decisions are tiered by risk class, that the tier policy is itself data changed by pull request, and that governance as code changes what forums are for without removing them (168, Nordqvist, 2026). Architecture as Code (Chapter 9C) concluded that risk is a versioned record with an owner and expiring exceptions (167, Nordqvist, 2025). AI Governance, Chapter 12, concluded that control functions keep their independence through gates and records rather than meetings. AI Governance, Chapter 24, concluded that patch decisions must be delegated in advance. The open question the chapter answers is the one AI Platform and Security, Chapter 18, and AI Governance, Chapter 13, raised: when may an AI act without per-action approval, and who decides, when the action is a change to the architecture itself (169, Nordqvist, 2026).

From meetings to gates

Forums fail in three ways that have nothing to do with the quality of the people in them. They are slow, because a decision waits for the next session. They are inconsistent, because the outcome depends on who attended and what the agenda left time for. And they forget, because the reasoning lives in minutes that nobody queries. Conway observed in 1968 that organisations design systems that copy their own communication structure (77, Conway, 1968), and a review board that every change must pass through leaves its mark: teams batch their work to fit the cycle, route around the board when they can and present the board with finished designs that are expensive to change.

The evidence on external approval is consistent with this. Forsgren, Humble and Kim, analysing survey data from many thousands of technology professionals, found that heavyweight change approval by an external body was associated with slower delivery and showed no benefit for stability, while peer review and automated checks in the delivery pipeline were associated with better outcomes (81, Forsgren et al., 2018). Kim and colleagues draw the same practical conclusion in the DevOps Handbook, replacing approval by distant reviewers with review by peers and checks that run on every change (82, Kim et al., 2016). The deployment pipeline that Humble and Farley describe is the mechanism: the path every change takes to production is the natural place to check it (80, Humble & Farley, 2010). These sources describe software delivery in general. This book applies their conclusion to security architecture decisions, and the application is its own, as a conclusion of this chapter.

A gate does three things a meeting does badly. It enforces: a change that fails the rule does not proceed, whatever the mood of the room. It observes: every decision is logged with the rule version and the input that produced it. And it remembers: the record is queryable years later, when a supervisor, an auditor or a court asks why a boundary stood where it did. These three properties are the reason to move routine decisions to gates. They are not a reason to remove forums.

What is lost if the forums disappear is everything a rule cannot contain. A gate applies a threshold; it does not set it. A waiver names an approver; somebody with a mandate to approve must exist. NIS 2 Article 20 requires the management bodies of essential and important entities to approve cybersecurity risk-management measures and oversee their implementation (6, European Union, 2022), and DORA Article 5(2) makes the management body of a financial entity responsible for the ICT risk-management framework (9, European Union, 2022). As an architectural implication, someone with authority must still decide appetite, policy, precedent and residual risk, and the architect's task is to make sure that those decisions reach people who hold that authority, with evidence, and that nothing else does. The conclusion this chapter draws is that the architect should move every decision that a rule can take to a gate, and every decision that needs judgement to a forum that is built to take it.

The tier policy as data

The unit of delegation is the class of decision, not the individual decision. "Add an egress destination to a workload's allow-list" is a class; so is "grant a time-limited exception to a supplier control" or "change the policy that defines the allow-list". A class has a tier, a decider, the evidence required, a time limit and an owner. The tier policy is the file that lists the classes, and it is data in version control, read by the gates and by the forums, and changed only by pull request.

AI Governance, Chapter 13, defined four tiers that this book reuses (168, Nordqvist, 2026). Tier 1 is the pipeline gate, which decides routine matters against thresholds that someone else has already set. Tier 2 is the design authority, which decides exceptions, precedent and what the policy cannot settle. Tier 3 is the AI governance board, which decides high-risk go-live, residual risk within delegated appetite, and changes to policy. Tier 4 is the management body, which sets appetite and accepts risk beyond it. The security architect's tier policy is a specialisation for architecture decisions: it adds classes the AI governance policy does not carry, such as boundary changes, identity and egress rules and supplier controls, and it must agree with the governance policy, because a decision that the AI governance board has reserved for itself cannot be delegated downwards by a security file.

Three design rules keep the policy honest. First, a class qualifies for tier 1 only if a machine can check the evidence it needs. A decision that depends on reading a supplier's intent, weighing a political risk or judging whether an argument is sound is not a gate decision, however routine it feels. Second, a class that loosens a boundary is never delegated as far as a class that tightens one. Adding a deny rule is cheap to undo and unlikely to cause harm; widening an allow-list is the change an adversary wants. Third, the policy names a maximum autonomy level for an AI that proposes a change in each class, a point the section on AI-proposed change returns to.

Writing the reasoning behind the policy as an Architecture Decision Record, in the form Nygard proposed (63, Nygard, 2011), or as an AI Decision Record where AI systems are affected, gives the policy its own history. The policy file says what is delegated; the record says why, who approved it and when it is due for review.

Worked example: Hansa Mutual's tier policy for architecture decisions

Illustrative example. Hansa Mutual's security architecture team of six in Hamburg keeps the policy below in governance/decision-tiers/security-architecture.yaml. It is the result of the redesign described later in this chapter and is recorded as AIDR-0558. Five classes have moved from the fortnightly board to pipeline gates; the rest are routed to the design authority or upwards. The agent_proposal field is the autonomy line for changes proposed by an AI.

# governance/decision-tiers/security-architecture.yaml (illustrative)
policy: security-architecture-decision-tiers
version: 2.0.0
owner: head-of-security-architecture
approved_by: group-ai-governance-board      # AIDR-0558
review_due: 2027-05-31
tiers:
  1: {decided_by: pipeline-gate, record: evidence-log}
  2: {decided_by: security-design-authority, record: adr}
  3: {decided_by: group-ai-governance-board, record: aidr}
  4: {decided_by: executive-board, record: board-minute}
classes:
  - id: C1-egress-within-approved-destinations
    tier: 1
    gate: egress-policy-check
    direction: tighten_or_within_catalogue
    agent_proposal: {max_level: 3, requires: [rollback_tested]}
  - id: C2-baseline-restoring-change
    tier: 1
    gate: baseline-drift-check
    direction: restore
    agent_proposal: {max_level: 3, requires: [rollback_tested]}
  - id: C3-known-exploited-patch
    tier: 1
    gate: kev-standing-approval
    sla_hours: 24
    agent_proposal: {max_level: 2}
  - id: C4-new-egress-destination
    tier: 2
    max_wait_working_days: 5
    agent_proposal: {max_level: 2}
  - id: C5-supplier-control-exception
    tier: 2
    max_duration_days: 90
    agent_proposal: {max_level: 1}
  - id: C6-high-risk-system-boundary-change
    tier: 3
    max_wait_working_days: 10
    agent_proposal: {max_level: 1}
  - id: C7-change-to-this-policy
    tier: 3
    agent_proposal: {max_level: 0}
  - id: C8-change-to-stop-path
    tier: 3
    agent_proposal: {max_level: 0}
  - id: C9-risk-beyond-appetite
    tier: 4
    agent_proposal: {max_level: 0}
escalation:
  deadlock_working_days: 10
  security_architect_objection: group-ai-governance-board

Three entries deserve comment. C3 reflects the conclusion of AI Governance, Chapter 24, that a known-exploited vulnerability cannot wait for a weekly change board: the decision was taken in advance, by standing approval, and the gate only checks that the conditions hold. C7 and C8 are at Level 0 Advisory for any AI proposer, because an agent must never change the rule that governs it or the path that stops it. C9 shows that the policy routes upwards as well as downwards: the architect does not decide risk beyond appetite, and the policy makes sure it reaches the body that does.

Pipeline gates

A gate has an owner, a rule, an input, a decision and a record. The owner of the rule is the architect, or the control owner the architect has appointed; the owner of the gate's machinery is the platform team. The distinction matters because it prevents two failures: a rule nobody maintains because the platform team runs the pipeline, and a pipeline nobody can change because the architect owns the rule. In the platform of AI Platform and Security the policy engine already sits outside the model and outside the workload (169, Nordqvist, 2026); architecture gates follow the same pattern with the same tooling. Open Policy Agent, a general-purpose policy engine with a declarative language, is the example used throughout the earlier volumes (62, Open Policy Agent, n.d.), and Chapter 5 shows how security architecture is expressed as code.

The sketch below shows the smallest useful gate rule, which is also the one that makes exceptions expire: it denies any change that relies on an active exception whose expiry has passed.

package gates.exceptions
import rego.v1

# Deny a change that relies on an exception whose expiry has passed.
deny contains msg if {
    some e in input.exceptions
    e.status == "active"
    time.parse_rfc3339_ns(e.expires) < time.now_ns()
    msg := sprintf("exception %s expired on %s", [e.id, e.expires])
}

Four properties distinguish a gate that works from one that decorates the pipeline.

The rule is versioned and tested. A gate rule is code, so it has tests that show what it allows and what it denies, and its version is written into every decision it takes. When a rule changes, the earlier decisions remain interpretable because the record names the version that took them.

The author of a change does not own the rule that gates it. A pull request that changes both a workload's egress and the egress rule it will be checked against must fail review, and the repository's ownership rules should make the second approval come from the rule's owner. This is the technical form of the separation of duties that gives control functions their independence without a meeting.

Bypass is possible, visible and reviewed. Gates that cannot be bypassed will be bypassed in ways nobody sees. A break-glass path for emergencies is part of the design. It records who used it, why and with which compensating measure, notifies the rule's owner immediately and is reviewed at the next design authority session. The override rate of each gate is a measure of the gate's health: a rate near zero for a rule that nobody trusts suggests a bypass elsewhere, and a high rate says the rule is wrong.

The gate is reviewed for staleness. A rule with a review_due date that has passed is itself an exception. The earlier volumes made the same point for controls: a control counts as a defence only when a test that re-runs its scenario has passed recently, a conclusion Chapter 9 applies to the architect's own control catalogue.

Gates also change what a patch decision looks like. A weekly change advisory board cannot sit in the path of a known-exploited vulnerability, because exploitation windows are now measured in days, and the NCSC's guidance for a patch wave expects organisations to update by default (140, NCSC, 2026). The architect's contribution is to ensure that the decision has been taken before the advisory arrives: the standing approval, its conditions and its rollback are written, the gate checks the conditions, and the board sees the aggregate, namely patch velocity as a risk indicator, not each patch. Chapter 10 treats the design of machine-speed response in full.

The design authority

Gates decide what rules can decide. The design authority decides the rest: exceptions, deviations from approved patterns, precedent-setting choices and items that two parties contest. AI Governance, Chapter 13, described it as a tier 2 forum, often a specialisation of the architecture board, with the AI architect acting as its secretary (168, Nordqvist, 2026). For security architecture the same body serves, with the security architect as a required voice rather than as its chair or its only expert.

Its working method follows from the gate: it is asynchronous first and synchronous only for what remains. A proposal arrives as a pull request carrying the architecture decision record draft, the threat model and the evidence the class requires. Members review on the pull request within a fixed time limit, five working days is a sound default, and the merged pull request is the decision. A session is held, fortnightly and short, only for items that are contested, that set precedent or that exceed the time limit. A forum run this way takes decisions at the speed of its slowest necessary reviewer, not at the speed of its calendar.

Three rules protect the quality of what it decides. The first is that the mandate is written down: which classes the authority may decide, which it may not, and where it escalates. The second is that quorum is defined by roles whose consent the decision depends on. A design authority that decides a supplier exception without the architect who owns the control is not quorate, however many people attend. The third is that an objection from the security architect is not outvoted: it escalates to the next tier, in Hansa's case the group AI governance board, so that the architect's accountability is never discharged by a majority.

The independence of the control functions needs separate attention. The risk function, the data protection officer and internal audit should not become voting members of a delivery forum, because they would then review their own decisions. They receive the same decision log and evidence the forum produces, they can query it at any time and they can ask for any item to be escalated. Independence is kept by records they can read, not by meetings they must attend, and that is the sense in which the series speaks of gates instead of meetings.

Exceptions as expiring records

An exception is a decision to live with a control gap for a stated time. Treated as a meeting outcome, it tends to become permanent: nobody remembers the reason, the owner has changed role and the compensating control was never tested. Treated as a record, it carries the properties that make it temporary. Architecture as Code (Chapter 9C) introduced this, with risk acceptances that have an owner and an expiry (167, Nordqvist, 2025), and AI Governance, Chapter 13, bounded the duration of waivers by tier (168, Nordqvist, 2026).

An exception record holds the control it departs from, the system and scope, the reason, the risk accepted in the register's terms, the accountable owner, the compensating control and the test that shows it works, the approver and tier, the expiry and the evidence that renewal requires. Four rules apply.

1. Every exception has an expiry, and the expiry is enforced by a gate, as in the rule above, not by a reminder alone. Defaults of 90 days at tier 2 and 180 days at tier 3 are workable starting points; adapt them to the organisation's appetite and to how fast the underlying gap closes.
2. Renewal is a new decision, not an extension. It requires new evidence: the supplier's committed date, a result from the compensating control's test, or a changed risk assessment. A renewal that attaches nothing new is declined by the gate.
3. The compensating control is tested. An exception without a working compensating measure is an unmanaged risk with paperwork.
4. The register is reported upwards. Count, age, distribution by tier and renewals are standing items in the management reporting that Chapter 19 describes, because a growing stock of renewed exceptions is a leading indicator that a control is wrong or a supplier is not delivering.

Worked example: an expiring exception for a supplier control at Nordvik Region

Illustrative example. The Region's internal staff assistant runs on an open-weight model served by a European cloud provider under contract NR-2026-031, EEA only, with customer-held keys (AIDR-0211). The control CTRL-KEY-004 requires rotation of the customer-held key every 90 days. The provider's key-management service supports rotation only every 180 days until a release it has committed to for the first quarter of 2027. The security architect proposes, the CISO approves at tier 2, and the exception is recorded as follows.

# governance/exceptions/EXC-NR-0007.yaml (illustrative)
id: EXC-NR-0007
status: active
control: CTRL-KEY-004            # customer-held key rotation every 90 days
system: internal-staff-assistant  # AIDR-0211, contract NR-2026-031
reason: supplier key service supports 180-day rotation until release 2027-Q1
risk: {register_ref: RISK-NR-0031, likelihood: low, impact: medium}
owner: chief-information-security-officer
decided_by: {tier: 2, role: chief-information-security-officer, date: 2026-11-12}
compensating_control:
  id: CTRL-KEY-004-C1
  description: alert on every use of the key outside the assistant's service identity
  test: tests/controls/key-use-alerting.yaml
  last_passed: 2026-11-10
granted: 2026-11-12
expires: 2027-02-10               # 90 days; tier 2 maximum
renewal_requires:
  - supplier release notice or dated roadmap commitment
  - compensating control test passed within the last 30 days
disclosure:
  public_access: requestable      # details reviewed under national secrecy rules
  archive: retain-with-system-file

Two fields are specific to a public authority. The disclosure field records that the exception is an administrative record that a resident or journalist may request under the national public-access rules, and that its sensitive details must be reviewed before release; setting it at the moment of decision is cheaper than reconstructing it under a deadline. The archive field attaches the record to the system's file under the archives law, so that it survives the system's retirement. Both follow the Region's character as described in its profile: accountable to elected members and to the public, with a strong tradition of openness.

When AI changes the architecture

The tiers so far assume that a person proposes a change. Agents now propose architecture changes: a pull request that adds an egress rule, edits a policy, adjusts a role binding or drafts a new control. Architecture as Code (Chapter 20) concluded that agents draft and humans approve, with every exception and risk acceptance carrying a named human approval (167, Nordqvist, 2025). AI Red Team, Chapter 6, added that the line between Level 2 Supervised and Level 3 Bounded is the most important line in the scheme: below it a person approves each action, above it the organisation has decided in advance that a class of actions may proceed without per-action approval (170, Nordqvist, 2026). That chapter settled the question for defensive actions such as isolating a host. AI Threat, Chapter 30, answered it for agents in general by assigning decision rights in advance and matching autonomy to reversibility (171, Nordqvist, 2026). The case left open is the one where the action is a change to the architecture itself.

This case is different because the thing being changed is the boundary that constrains the agent, or the controls that would detect its misbehaviour. It is observable that the products agents run in already expose the question as a setting. Agent tools offer approval modes from asking before every action to approving broad classes automatically, and their vendors document how to configure them (120, Anthropic, n.d.), (121, OpenAI, n.d.). Without a written answer, the answer is whatever the product default or an engineer's convenience provides.

The book's own conclusion is that the answer is a tier 3 decision recorded in the tier policy, built on five rules.

1. An agent never changes its own boundary. The classes covering the tier policy, the gate rules that check the agent, its mandate manifest and the stop path are at Level 0 Advisory for any AI proposer, as C7 and C8 show above. This follows the finding of AI Platform and Security that a stop path inside the system it stops fails when it is needed (169, Nordqvist, 2026); the same holds for a rule that the system it governs can edit.
2. Direction decides the ceiling. Changes that tighten a boundary or restore it to the recorded baseline may reach Level 3 Bounded. Changes that loosen a boundary stay at Level 2 Supervised or below.
3. Level 3 requires a tested rollback and a gate outside the agent. The change must be reversible and must pass the same tier 1 gate as a human change, so that the policy engine, not the proposer, enforces the class.
4. Level 4 Autonomous is never used for architecture changes. The effect of a change may reach well beyond the action, and AI Red Team, Chapter 6, already excludes Level 4 for irreversible actions.
5. A human owner is named for each class. The accountable person is the owner of the class in the tier policy, and the change record names them, so that the question of who answered for an AI-proposed change has an answer on the day it is asked. Chapter 14 describes how that person verifies what the AI proposed.

Across the autonomy levels

Level	What the agent does with an architecture change	Who decides	What the tier policy requires
Level 0 Advisory	Suggests a change in conversation or report	A person writes and merges it	Nothing beyond the normal tier of the class; mandatory for the policy, gate rules, mandate manifests and stop path
Level 1 Assisted	Drafts the pull request	A person reviews, edits and merges	Normal tier of the class; the draft is labelled as AI-generated in the record
Level 2 Supervised	Opens the pull request and executes the merge after approval	A named person approves each change	Default for loosening changes and for any class with no recorded ceiling
Level 3 Bounded	Merges changes in a narrow class inside a codified playbook	The playbook, approved in advance at tier 3	Reversible tightening or restoration only, tested rollback, tier 1 gate outside the agent, person informed and able to stop
Level 4 Autonomous	Not permitted for architecture changes	Not applicable	Prohibited in the policy

Taking this decision at tier 3 puts it where residual risk for AI systems is accepted, and recording it as an AI Decision Record lets a supervisor see who set the ceiling and on what evidence. Supervisors' expectations about delegated architecture decisions are expected to develop through practice rather than rule: DORA Article 5 and NIS 2 Article 20 assign responsibility to the management body without prescribing a forum structure (9, European Union, 2022), (6, European Union, 2022), and the Commission's guidance on AI literacy likewise leaves the choice of measures to the organisation (4, European Commission, 2026). An organisation that can show its ceilings, its gates and its sampled decisions will be better placed than one that can show only a charter. The Level 3 ceiling for architecture changes is the book's own position, and organisations with a different appetite may set it lower. Raising it is speculation, because no body of evidence yet shows that agent-merged architecture changes hold up in production.

The review techniques for AI-proposed change belong to Chapter 14, and the mandate manifest that binds the architect's own agents to Chapter 13. The tier policy fixes only the ceiling.

Redesigning a bottleneck board

A review board becomes a bottleneck when its calendar, not its judgement, limits the pace of change. The signs are familiar: items wait longer than they take to decide, most items are approved without change, teams submit late and plan around the cycle, and the board spends its time on the routine because the contested items are few. The remedy is to measure first, then delegate by class, and to keep the independence that justified the board in the first place.

Practical guide: redesigning an architecture review board as a design authority with gates

Purpose. Replace a board that decides every item at a fixed cadence with a design authority that decides exceptions and precedent, and gates that decide the routine.

Roles. The head of security architecture (owner of the redesign), the chair of the existing board, the platform team lead (owner of the gate machinery), the control owners for the classes concerned, and a representative of the risk function as observer. In organisations with employee representation, the works council is informed where the redesign changes how individual reviewers' work is recorded; measures stay at forum level.

Steps.

1. Measure the queue. Take the board's last two quarters of agendas and minutes. For each item record the class of decision, the wait from submission to decision, the outcome and whether the decision changed the proposal.
2. Classify and count. Group items into classes. Compute for each class the number of items, the median wait, and the share approved unchanged. Classes with many items and a high unchanged share are candidates for delegation.
3. Apply the delegation test. A class moves to a gate only if it recurs, is reversible or low in blast radius, can be decided from evidence a machine can check, has an existing policy and has an owner. Classes that loosen a boundary need a stricter test than those that tighten.
4. Write the gate rules and tests. Express each class in the policy engine, with allow and deny tests, and write the tier policy entry with owner, evidence and time limit.
5. Run in shadow. For four weeks the gate decides and the board reviews the same items. Delegate a class only when gate and board agree on at least 95 per cent of at least 20 decisions in that class and every disagreement has been explained. Adapt the thresholds to the appetite for the class.
6. Convert the board. Set the design authority's mandate, quorum and escalation. Move review onto pull requests with a five-working-day limit, hold a 45-minute session fortnightly for contested and precedent items, and keep an escalation route to the next tier when a deadlock exceeds ten working days.
7. Record the decision. Write the redesign as a decision record at the tier that approves the mandate, and route anything beyond the board's mandate upwards.
8. Measure again. Report to the head of security architecture and to the governance board each quarter: median wait by tier, share of items decided at each tier, gate override rate and number of exceptions by age.

Definition of done. Every class in the tier policy has a tier, an owner and a time limit; delegated classes have passed shadow running; the median wait at tier 2 is within the stated time limit; the independence arrangements for the control functions are written; the redesign is recorded; and the first quarterly report has gone to the governance board.

Delegation without abdication

Delegation moves the decision, not the accountability. The architect who has written the tier policy and the gate rules remains answerable for whether they are sound, in the way a director who delegates to a committee remains answerable for the choice of committee. NIS 2 Article 20 and DORA Article 5(2) place the final responsibility with the management body (6, European Union, 2022), (9, European Union, 2022); the architect's responsibility is to make that oversight informed, so that the management body can see what has been delegated, on what evidence and with what result. The management review in clause 9.3 of ISO/IEC 27001 gives the same arrangement a place in the management system (23, ISO/IEC, 2022).

Four practices keep delegation honest.

Every class has a named owner role. A class without an owner is a decision nobody answers for. The owner is a role in the tier policy, not a person, so that the record survives reorganisation.

Gate decisions are sampled and re-derived by people. A fixed share of tier 1 decisions in each quarter, five per cent is a workable default, is re-examined by a person who did not take part, with the evidence the gate saw. Disagreements are findings against the rule. The aim is to detect a rule that drifted from its intent, which automation cannot detect in itself.

Approval is measured for quality. Bainbridge observed in 1983 that people who monitor automation are poor at it, since the work leaves them only the rare and hard cases (106, Bainbridge, 1983), and Parasuraman and Manzey describe the complacency and bias that follow (107, Parasuraman & Manzey, 2010). A design authority that approves every pull request in seconds is a gate with a delay. Approval time and the rate of changes requested are signals, reported at forum level, and Chapter 14 returns to this for AI-proposed change.

The architect reports upwards in the management body's terms. The quarterly report names delegated classes, override rates, exceptions by age and sampled disagreements. Chapter 19 treats the communication to boards, supervisors and auditors.

The craft consequence is a change in what the architect does with the working week. The time once spent in the board room goes into writing and testing rules, reviewing the contested items that remain and sampling what the gates have done. That is what Shift 2 describes: the architect designs the boundary and the decision rights, and answers for them, instead of standing at each door.

Nordvik Region and Hansa Mutual

The two organisations reach the same design from opposite sides. Hansa Mutual has a fortnightly security architecture review board in Hamburg, and its six architects measured it over two quarters, 13 sessions. The board saw 187 items. Of these, 131 (70 per cent) fell into five routine classes that were approved unchanged, 41 (22 per cent) were exceptions or precedent, and 15 (8 per cent) were contested or beyond the board's mandate. The median wait from submission to decision was 17 calendar days. The five routine classes became tier 1 gates after shadow running; the board became the security design authority, reviewing on pull requests within five working days and meeting for 45 minutes every fortnight for the 41 and the 15; and decisions beyond its mandate go to the group AI governance board chaired by the chief risk officer, as the tier policy above shows. The redesign and its routing are recorded as AIDR-0558. Hansa has the engineering capacity to write and test the gate rules, and the risk it carries is that a rule is wrong at scale, which is why the sampling and the escalation for objections matter most there. Whether the median wait falls to the target of five working days is a result for Chapter 25 to report, not a claim made here.

Nordvik Region has no standing board to redesign, and its single security architect cannot run a design authority alone. The architect therefore writes a tier policy that routes decisions without creating a new forum: tier 1 to the platform team's pipeline gates for the few classes the Region can check by machine, tier 2 to the chief information security officer together with the enterprise architect, convened on request and asynchronously, tier 3 to the AI governance board and the regional director, and a political tier for deployments that affect residents' rights, which goes to the regional executive committee, as the escalation matrix of AI Governance, Chapter 13, already does. The CISO approves exceptions at tier 2 and records them as expiring entries such as EXC-NR-0007, whose disclosure and archive fields are set when the decision is taken so that the record survives public-access requests and archiving. The tier policy itself is recorded as AIDR-0512. The Region's leverage is the contract, so its most important class is the supplier-control exception, and its most important gate checks that no active exception has passed its expiry. Where Hansa measures and delegates, Nordvik designs a route and writes down who answers at the end of it.

Summary

Decisions that a rule can take belong at a gate, and decisions that need judgement belong in a forum built to take them. A gate enforces, observes and remembers; a forum decides appetite, policy, precedent, exceptions and residual risk. The tier policy turns that division into data: classes of decision, each with a tier, an owner, the evidence it needs and a time limit, changed only by pull request and approved at the tier above. The architect's accountability moves from being present at every decision to being answerable for the policy and the rules, which is why delegation depends on sampling, override rates and reporting to the management body.

The design authority decides exceptions, contested items and precedent, asynchronously first and in a short session for what remains, and the security architect's objection escalates instead of being outvoted. Exceptions are records with an owner, a tested compensating control and an expiry that the gate enforces, and renewal requires new evidence. A board that has become a bottleneck is redesigned by measuring its queue, delegating by class after shadow running and keeping the control functions independent through records they can read.

When an AI proposes a change to the architecture, the open question of the earlier volumes has an answer within the tier policy: a tier 3 decision sets the ceiling per class, an agent never changes its own boundary, only tightening or restoring changes may reach Level 3 Bounded behind a gate outside the agent, and Level 4 Autonomous is not used. That position is the book's own conclusion. Its practical effect is that the question of who decided has a written answer on the day it is asked.

This chapter concerns Shift 2, from gatekeeper to boundary designer, because the architect now designs decision rights and boundaries that hold whoever proposes the change, and Shift 3, from periodic to continuous, at machine speed, because the decisions that cannot wait for a fortnightly session are taken by gates continuously. Chapter 18 turns to the regulation that frames these decisions, the AI Act, NIS 2, DORA and the Cyber Resilience Act, and to what each requires of the architect's accountability.

Sources

1. European Parliament and Council of the European Union (2022). Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union. (6, European Union, 2022)
2. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union. (9, European Union, 2022)
3. European Commission (2026). AI literacy: questions and answers. Shaping Europe's digital future. (4, European Commission, 2026)
4. International Organization for Standardization and International Electrotechnical Commission (2022). ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection: Information security management systems: Requirements. Geneva: ISO. (23, ISO/IEC, 2022)
5. Open Policy Agent Contributors. Open Policy Agent Documentation. Cloud Native Computing Foundation. (62, Open Policy Agent, n.d.)
6. Nygard, M. (2011). Documenting Architecture Decisions. Cognitect blog, 15 November 2011. (63, Nygard, 2011)
7. Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(4), pp. 28–31. (77, Conway, 1968)
8. Humble, J. & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley. (80, Humble & Farley, 2010)
9. Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. (81, Forsgren et al., 2018)
10. Kim, G., Humble, J., Debois, P. & Willis, J. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations. IT Revolution Press. (82, Kim et al., 2016)
11. Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775–779. (106, Bainbridge, 1983)
12. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors, 52(3), 381–410. (107, Parasuraman & Manzey, 2010)
13. Anthropic. Configure permissions and Configure the sandboxed Bash tool. Claude Code documentation. (120, Anthropic, n.d.)
14. OpenAI. Agent approvals & security. Codex documentation. (121, OpenAI, n.d.)
15. National Cyber Security Centre (2026). Preparing for a 'vulnerability patch wave'. NCSC blog, 1 May 2026. (140, NCSC, 2026)
16. Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1. (167, Nordqvist, 2025)
17. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2. (168, Nordqvist, 2026)
18. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Architecture as Code Series, Book 3. (169, Nordqvist, 2026)
19. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 4. (170, Nordqvist, 2026)
20. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. The Architecture as Code Series, Book 5. (171, Nordqvist, 2026)