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. The chapter also answers who decides when an AI may change the architecture without per-action approval. It 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 boundaries that apply whoever, or whatever, makes the change, and 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.
The chapter builds on the conclusions of AI Governance, Chapters 12, 13 and 24, that decisions are tiered by risk class in a tier policy that is itself data, that control functions keep their independence through gates and records, and that patch decisions are delegated in advance (162, Nordqvist, 2026), and of Architecture as Code (Chapter 9C), that risk is a versioned record with expiring exceptions (161, Nordqvist, 2025). The open question, raised by AI Platform and Security, Chapter 18, is who decides when an AI may act without per-action approval on the architecture itself (163, Nordqvist, 2026).
Forums fail in three ways that have nothing to do with the quality of their members. They are slow, because a decision waits for the next session; inconsistent, because the outcome depends on who attended; and forgetful, because the reasoning lives in minutes that nobody queries. Because organisations design systems that copy their communication structure (75, Conway, 1968), teams batch work to fit the board's cycle, route around it and present it with finished designs.
Primary topics explored
- From meetings to gates
- The tier policy as data
- Pipeline gates
- The design authority
- Exceptions as expiring records
- When AI changes the architecture
About The Transformed Security Architect
The Transformed Security Architect is Book 6 of The Transformed Architecture. It describes how the security architect role is transformed when architecture is code, when AI drafts and acts, and when adversaries move at machine speed: the craft, the architect's own AI team, the role in the organisation, the competences and the career, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team and AI Threat.
Security architects, CISOs and heads of security architecture, enterprise, solution and AI architects, engineering leads, competence and hiring leads, procurement and programme leaders, and risk, compliance and audit.
Continue with the full chapter
Chapter 17: Design Authority, Decision Forums and Gates Instead of Meetings in The Transformed Security Architect gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Role in the Organisation” and is one of 31 drawn from the manuscript.