AI Governance – Book Blueprint and Chapter Briefs

This document is the editorial blueprint for AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities, Book 2 of The Transformed Architecture. It records the premise of the book, its relationship to the other two volumes of the series, the audience, the narrative arc, and a brief for every chapter. Writers, editors and AI-assisted tooling use it as the single source of intent when drafting or revising content. The canonical ordering of files lives in book_index.json; this document explains why each chapter exists and what it must deliver.

Premise

Architecture as Code argued that architecture becomes trustworthy when it is expressed as executable, version-controlled artefacts that travel through the same pipelines as the systems they describe. AI Governance applies that conviction to the governance of artificial intelligence in large European organisations: how to decide what AI is used for, classify and manage its risks, meet the obligations of the AI Act and its neighbours, choose and contract suppliers, organise the people and forums who take decisions, and produce the evidence that shows all of this is true, without losing control of risk, legal exposure or public trust.

AI systems break several assumptions that classical IT governance relies on. Their behaviour is probabilistic rather than deterministic. Their most important component, the model, is derived from data rather than written by hand, and it degrades silently as the world changes. Their supply chain includes third-party foundation models whose training data the organisation cannot inspect, often from providers in other jurisdictions. Their regulatory position in Europe is defined by a dense web of legislation, led by the AI Act, that assigns obligations to roles the organisation may not realise it occupies. And their adoption is driven by business urgency that frequently outruns the organisation's ability to govern.

The book's thesis is that governance of AI is most effective when it is expressed as code: declared intent, risk classification, policies, approvals, exceptions, decision records, portfolio steering and evidence held in version control and executed in pipelines. Every chapter therefore names a governance challenge, shows how it manifests in a large enterprise or public authority, and describes a response that can be codified, tested and audited.

Audience and geographic focus

The primary readers are chief risk officers, chief information officers, heads of compliance and internal audit, data protection officers, enterprise and chief architects, programme and portfolio owners, members of AI governance boards, and senior officials in public authorities, in organisations with more than a few thousand employees. Public authorities at national, regional and municipal level are treated as first-class readers throughout, because their obligations under European law are stricter and their accountability to citizens is direct.

The geographic focus is Europe. The regulatory baseline is the European Union acquis (the AI Act, the GDPR, DORA, NIS 2, the Data Act, the Data Governance Act, the Cyber Resilience Act, the Interoperable Europe Act), complemented by Council of Europe and OECD instruments and by the national practices of member states and EEA countries, with the United Kingdom and Switzerland treated where Hansa Mutual operates. Where the book names tools or vendors it stays neutral and prefers open standards and open models.

Relationship to the series

AI Governance is Book 2 of The Transformed Architecture by Gunnar Nordqvist. It builds on Architecture as Code (Book 1), cited as Nordqvist (2025) in 30_references.md, and can be read on its own. The series builds strictly in publication order, so that there is no circular reasoning between the books: Book 1 refers to no other volume, this book refers only to Book 1, and later volumes refer only to the volumes before them. This book therefore never refers to AI Platform and Security (Book 3) or any later volume. Refer to this book's chapters as "Chapter N" and to the first volume as "Architecture as Code (Chapter N)". Every new claim either cites an external source or is the book's own conclusion, drawn in a conclusions section or summary from evidence already given.

Platform engineering, security engineering and operations (the reference architecture, the model lifecycle, infrastructure, security controls, evaluation and observability) lie outside the scope of this book. Where a governance argument depends on them, the chapter states in its own words what the governance needs from the engineering, without pointing to another volume.

AI Governance chapter	Builds on Architecture as Code chapter(s)
2 Usage Modes of Large Language Models	1 Introduction; 2 Fundamental Principles
3 EU Regulatory Landscape	12 Compliance
4 Fundamental Principles	2 Fundamental Principles
5 Prerequisites and Readiness	26A Prerequisites for Architecture as Code Adoption
6 Geopolitics and Model Origin	25 Future Trends (cloud and digital sovereignty in Europe)
8 Risk Management	9C Risk as Code
9 AI Governance as Code	10 Policy as Code; 11 Governance as Code
11 Assurance and Audit	15A Evidence as Code
12–14 Organisation, Forums and Competence	11 Governance as Code; 17, 18 Organisational Change and Team Structure
16 Management as Code for AI	19 Management as Code; 23 Soft As Code Interplay
16A Governing AI Economics	19 Management as Code (cost optimisation as an architectural discipline)
17 Public Sector	21 Digitalisation
20 Anti-Patterns	26B Anti-Patterns
Appendix B Maturity Model	Appendix E Maturity Model

Editorial conventions that every chapter follows

1. Voice and language. British English, the author persona in AUTHOR_PERSONA.md, and the rules in STYLE_GUIDE.md. Write AI governance for the discipline this book treats, AI Architecture for the architectural discipline of the series' AI volumes, and Architecture as Code for the companion discipline, exactly so. Use the AI Act's own terms (provider, deployer, high-risk AI system, general-purpose AI model). Never anthropomorphise models.
2. Structure. H1 title with an anchor (# Title {#anchor}), an opening paragraph that states the chapter's purpose, ## sections with ### subsections, at least one Mermaid diagram referenced as ![alt](images/diagram_NN_name.png) with an italic caption line, at least one code example in a fenced block with a language identifier, a ## Summary that points forward to the next chapter, and a closing ## Sources section.
3. Length. As in rule 2 of CHAPTER_AUTHORING_GUIDE.md: numbered narrative chapters 3,600 to 5,500 words of prose, unless the brief says otherwise; chapters carried over from the combined manuscript keep the weighting recorded in their briefs. Weighting decision for this volume: Chapters 2, 6, 13 and 19 were companion chapters in the combined manuscript and keep the companion range of 3,500 to 6,500 words, as does the new companion chapter 16A; all other numbered chapters use 3,600 to 5,500. Chapters 3, 9, 15, 17, 20 and 21 were expanded with governance substance in the standalone edition to bring them into range. Appendices follow the lengths given in their briefs. Refactoring (2026-11): the manuscript was cut by about 30 % in a series-wide refactoring; the length ranges given in this blueprint and in the individual briefs below are superseded by rule 2 of CHAPTER_AUTHORING_GUIDE.md (numbered narrative chapters 2,500 to 4,000 words of prose, companion chapters up to 4,500).
4. Citations. Inline citations use the form (N, Author, Year), written ([N, Author, Year](30_references.md#source-N)), and refer only to entries that exist in 30_references.md. The ## Sources section lists every cited work. No invented sources. The briefs do not list source numbers, because the bibliography is renumbered 1..N whenever sources are added or removed; each chapter's ## Sources section is authoritative.
5. Europe first. Every chapter contains at least one concrete European or public-sector consideration. Legal statements are attributed to the specific instrument and article where possible, and framed as architectural implications rather than legal advice.
6. Codify it. Every chapter shows at least one artefact that can live in version control.
7. Diagrams. Each diagram has a .mmd source in docs/images/ named diagram_NN_<topic>.mmd, uses the Kvadrat theme conventions from DIAGRAM_STYLE_GUIDE.md, and keeps labels in British English.

Chapter briefs

Chapters marked [new], "adapted", "focused" or "rewritten" were written or substantially revised for this volume. The other briefs are carried over from the combined AI Architecture manuscript, renumbered, with references to chapters that left this volume removed or rewritten as self-contained statements.

Part I – Foundations

Chapter 1 – Introduction to AI Governance (01_introduction.md, diagram diagram_01_ai_governance_landscape) [new, adapted from the combined manuscript's Chapter 1] Purpose: introduce this book on its own terms. Cover: what AI governance is and is not (not a committee, not a policy binder, but the system of decisions, controls and evidence that keeps AI within its declared intent); why AI breaks the assumptions of classical IT governance (probabilistic behaviour, the model as a derived artefact, third-party models, a dense European legal framework, adoption outrunning control); the European context; the three recurring tensions (speed versus control, autonomy versus accountability, innovation versus sovereignty); the book's purpose, readers and scope; how the book fits The Transformed Architecture, what Architecture as Code contributes and where this book's scope ends (platform, security and operations engineering); the six usage modes in brief, with a pointer to Chapter 2; the section "Two organisations that run through this book" introducing Nordvik Region and Hansa Mutual as profiled in EXAMPLE_ORGANISATIONS.md; and how to read the book, part by part and by reader role. Include a short definition of AI governance, a codified artefact (a governance charter or scope declaration as YAML), and the ### Nordvik Region and Hansa Mutual subsection. 3,600 to 5,500 words.

Chapter 2 – From Chat to Agents: How Large Language Models Are Used (02_llm_usage_modes.md, diagram diagram_02_usage_modes) Purpose: establish early, and as a taxonomy used throughout the book, that "using an LLM" covers very different implementations whose architecture, risk, controls, governance, cost and competence needs differ by orders of magnitude. Define six usage modes with these canonical names and anchors (other chapters link to them; the matrix covers Modes 0 to 5). Begin with the distinction between encountering AI and actively using it: Mode 0 – Ambient AI {#mode-0} (AI that people meet without having chosen it, such as AI-generated summaries at the top of search results, automatic meeting notes and mail summaries, and AI features that suppliers switch on inside software the organisation already licenses; the person is a recipient of model output rather than an operator, but still relies on it, and the organisation still processes data through it). Mode 0 matters for information integrity and verification habits, AI literacy under Article 4, transparency under Article 50, procurement and contract change control (a supplier enabling AI in an existing SaaS product changes the data processing), and the boundary of the AI inventory (what counts as AI use the organisation must govern). Then the five modes of active use: Mode 1 – Conversational assistants {#mode-1} (general-purpose chat such as ChatGPT, Microsoft Copilot Chat, Claude, Gemini or Le Chat; the human pastes context in and copies text out; consumer versus enterprise tiers); Mode 2 – Embedded workplace assistants {#mode-2} (assistants and co-working agents inside the ordinary office suite and collaboration tools, such as Microsoft 365 Copilot, Gemini in Google Workspace or Claude working within Office applications; they read and act on mail, documents, calendars and chats with the user's own permissions); Mode 3 – Agentic work tools {#mode-3} (agents that run tools on a workstation, repository or cloud sandbox, such as Claude Code, OpenAI Codex, GitHub Copilot's cloud agent or Cursor; they edit files, execute commands, call connectors and open pull requests); Mode 4 – Built AI applications {#mode-4} (the organisation integrates models through APIs or its own platform into its own systems, for example RAG assistants, classifiers and decision support; it owns the full lifecycle and may become a provider under the AI Act); Mode 5 – Autonomous production agents {#mode-5} (agents and agentic workflows acting on business systems on the organisation's behalf without a human approving each step). Cover, for each mode and in a comparison matrix {#usage-mode-matrix}: who builds and operates it; where the model runs and where data goes; whether the use is chosen at all; what context the model sees (none chosen by the user, pasted text, the tenant's documents and mail, a repository or file system, a curated corpus, live business systems); what it can do (produce text, change documents, execute commands, act on systems); identity and permissions (the user's own, delegated, a service identity); the human's role; AI Act position (deployer of a general-purpose-AI-based system, Article 4 literacy and Article 50 transparency, possibly provider when building or substantially modifying; high-risk only through the use case); typical failure modes and threats (data leakage and shadow AI; oversharing through permission sprawl and indirect prompt injection through mail and documents; excessive agency, secrets exposure, supply-chain and skill risks, sandbox escape; full lifecycle risks; loss of control at scale); the controls and governance artefact each needs (verification guidance, literacy training and supplier change control for ambient AI; acceptable-use policy; tenant configuration, sensitivity labels and data-access hygiene; agent permission configuration and a curated skills and connector catalogue; AI Decision Records and the full DevSecMLOps loop; agent definitions, approval policies and stop paths); cost model (per seat versus consumption); and competence. Explain the difference between passive exposure (Mode 0) and active use as part of everyday work (Modes 1–3) and as part of the organisation's own systems (Modes 4–5). Explain mode drift: how a prompt in Mode 1 becomes a shared skill in Mode 3 and then an agent in Mode 5, and why governance must follow the use case as it moves. Under Mode 3, describe briefly that some agentic work tools are provider-agnostic (OpenCode is the example; verify facts) and can use self-hosted and cloud-hosted models side by side, which opens a hybrid way of working for sensitive information, stating the routing rule that makes it safe. Explain that the same vendor name can appear in several modes, and that the mode, not the brand, determines the architecture. Include a practical guide (classify your AI estate by mode and assign a minimum control baseline per mode) and a worked example (a usage-mode register in YAML for Nordvik Region and Hansa Mutual, and a "which mode for this task" decision table). Close with a short section on how the rest of the book uses the modes. Use very recent, verified sources for product capabilities and state them as of the access date; avoid product marketing claims. Maps to AaC Ch. 1 and Ch. 2 (principles), and connects forward to Chapters 3, 9, 7 and 14. 4,500 to 6,000 words.

Chapter 3 – The EU AI Act and the European Regulatory Landscape (03_eu_regulatory_landscape.md, diagram diagram_03_regulatory_map) Purpose: give architects a working map of the law. Cover: the AI Act's risk-based structure (prohibited practices, high-risk systems in Annex III, transparency obligations, general-purpose AI), roles (provider, deployer, importer, distributor), timeline of application (2025–2028, as amended by Regulation (EU) 2026/1744), conformity assessment and harmonised standards (CEN-CENELEC JTC 21); interplay with the GDPR, DORA, NIS 2, the Data Act, the Cyber Resilience Act, the Council of Europe Framework Convention; national competent authorities. Frame everything as architectural implications.

Chapter 4 – Fundamental Principles (04_fundamental_principles.md, diagram diagram_04_principles) Purpose: define the principles that extend AaC principles to AI. Propose and explain eight principles: declared intent (purpose, scope, and prohibited uses are codified); data and model as first-class architectural elements; reproducibility and lineage; bounded autonomy; evaluation before and after deployment; human oversight by design; least privilege for models and agents; sustainability and cost as design constraints. Relate each to the AI Act's risk-based approach and to AaC principles. Weighting change (2026-11): at about 3,300 words of prose this foundational chapter is light compared with the rest of the book. Expand to 4,000 to 4,500 words: show each principle at work across the usage modes, add tensions between principles and how to resolve them, and use Nordvik Region and Hansa Mutual (including Hansa's multinational setting) to make each principle concrete.

Chapter 5 – Prerequisites and Readiness for Enterprise AI (05_prerequisites_for_ai.md, diagram diagram_05_readiness_dimensions) Purpose: help an organisation judge whether it is ready to industrialise AI before it commits budget. Cover: data readiness (ownership, quality, lineage, legal basis); platform readiness (cloud, identity, observability); governance readiness (risk appetite, accountable roles, data protection impact assessments); skills readiness; cultural readiness (Westrum generative culture); public-sector specifics (legal mandate, procurement, transparency duties). Relate the organisation-level scorecard to UNESCO's country-level Readiness Assessment Methodology and system-level Ethical Impact Assessment. Provide a readiness scorecard as a YAML artefact.

Part II – Sovereignty and Suppliers

Chapter 6 – Geopolitics and Model Origin (06_geopolitics_and_model_origin.md, diagrams diagram_06_dependency_map, diagram_06_risk_assessment) Purpose: give European enterprises and public authorities a sober, evidence-based way to judge how far they can rely on AI models and services from the United States and China, and what European alternatives offer. Cover: the categories of geopolitical risk — legal access to data and prompts (the US CLOUD Act and FISA Section 702, the EU–US Data Privacy Framework and its litigation; China's National Intelligence Law and data laws), service continuity and sanctions risk (export controls, sanctions that cut off services, terms that change), model behaviour (political alignment, censorship and narrative bias documented in evaluations of Chinese models, and US policy pressure on model behaviour), supply-chain integrity (backdoors and provenance of open weights), and regulatory compliance (GDPR transfers, the AI Act's role allocation when a model's provider is outside the Union, European regulators' actions against specific services); the difference between using a foreign provider's hosted service and running a foreign open-weight model on European infrastructure; European alternatives and their 2026 status, without overselling them; sovereignty offerings from US hyperscalers and their stated legal limits; a risk-tiered position (which use cases may use which origins under which controls) rather than blanket bans or blanket trust; how to make the position codified and reviewable. Practical guides: assessing a model or provider's geopolitical risk; a model-origin policy by data classification and use case; an exit and substitution plan that keeps a second source ready. Sources: verified 2025–2026 sources added to the bibliography, plus 1, 2, 25, 31, 32, 41, 94. 4,000 to 5,500 words of prose, excluding code.

Chapter 7 – Procurement, Vendor Management and Open Models (07_procurement_and_vendors.md, diagram diagram_07_sourcing_options) Purpose: help organisations buy AI responsibly. Cover: public procurement rules and the EU model contractual AI clauses; evaluating vendors for AI Act compliance (provider documentation, conformity, incident duties); lock-in and exit strategies; open-weight versus proprietary models and the Open Source AI Definition; DORA third-party risk and critical ICT providers; contract clauses for data use, model updates, and audit rights. Codify a vendor assessment schema.

Part III – Risk, Governance, Trust and Assurance

Chapter 8 – AI Risk Management and Classification as Code (08_ai_risk_management.md, diagram diagram_08_risk_pipeline) Purpose: make risk classification and risk management executable. Cover: ISO/IEC 23894 and NIST AI RMF; the AI Act risk classification as a decision tree; impact assessments (ISO/IEC 42005, ALTAI, DPIA); risk registers as code; continuous risk re-evaluation when models or data change; risk appetite statements. Provide a classification policy in Rego or YAML and a risk register schema.

Chapter 9 – AI Governance as Code (09_ai_governance_as_code.md, diagram diagram_09_governance_control_loop) Purpose: turn AI governance from committees into controls. Cover: the AI management system (ISO/IEC 42001) as a codified operating model; policy as code for model approval, data use, and deployment; the AI inventory and register (including public algorithm registers such as the Dutch register); governance gates in pipelines; roles and accountabilities; exceptions and waivers as records. Codify an approval policy and an inventory schema.

Chapter 10 – Trustworthy AI: Transparency, Fairness and Human Oversight (10_trustworthy_ai.md, diagram diagram_10_trustworthy_ai_requirements) Purpose: translate ethics requirements into design. Cover: the seven HLEG requirements; transparency and explainability (model-level and system-level); fairness metrics and their trade-offs; human oversight patterns (human-in-the-loop, on-the-loop, in-command) and AI Act Article 14; transparency obligations for chatbots and synthetic content (Article 50); accessibility; the sociotechnical framing. Codify a fairness evaluation configuration and an oversight checklist.

Chapter 11 – Evidence, Assurance and Audit (11_assurance_and_audit.md, diagram diagram_11_evidence_chain) Purpose: make AI systems auditable continuously. Cover: evidence as code applied to models; technical documentation (AI Act Annex IV) generated from the repository; logging obligations (Article 12) and record retention; internal algorithmic audits; conformity assessment and the role of notified bodies; post-market monitoring and serious incident reporting (Articles 72–73); DORA and audit trails in finance. Codify an evidence manifest and a documentation generation pipeline.

Part IV – Organisation and Leadership

Chapter 12 – Organisational Design for AI (12_organisational_design.md, diagram diagram_12_operating_models) Purpose: describe operating models that work at scale. Cover: centralised, federated, and hub-and-spoke models; the AI platform team; enabling teams; centres of excellence that avoid becoming bottlenecks; Conway's law applied to AI; interaction with data protection, security, legal, and risk functions; public-sector shared services. Codify a team topology and a responsibility assignment matrix. Weighting change (2026-11): at about 3,200 words of prose, expand to 4,000 to 4,500 words: operating models for a multinational group with national entities (Hansa Mutual) versus a single public authority (Nordvik Region), how platform, enabling and stream-aligned teams own the usage modes, sourcing and supplier dependence, and the transition path between models.

Chapter 13 – Decision Forums and Governance Bodies (13_decision_forums_and_governance_bodies.md, diagrams diagram_13_forum_map, diagram_13_decision_tiers) Purpose: give large enterprises and public authorities a coherent design for the decision forums and governance bodies that AI requires, so that decisions are taken at the right level, on evidence, with clear mandates, instead of in ad hoc meetings or not at all. Cover: the forums and what each decides — the management body's oversight (board or executive level), an AI governance board or council, an AI design authority or architecture review, a model risk committee where model risk management applies, the data governance council, an ethics or fundamental-rights council, the change advisory board, the information security management review under ISO/IEC 27001 and the AI management review under ISO/IEC 42001, incident and stop decisions, supplier and procurement decisions, employee representation and works councils, and in the public sector political and legal accountability; decision tiers by risk class (which decisions are automated as policy-as-code gates, which go to a forum, which to the management body); mandates, quorum, cadence, the evidence pack each forum receives from pipelines and registers, escalation paths, decisions recorded as version-controlled records, and the review of the forums themselves; how to avoid governance theatre and committees that only slow delivery, building on Chapter 9's "from committees to controls" and Chapter 16's evidence-driven steering; the European anchors — NIS 2 Article 20 on management bodies' approval and oversight of cybersecurity measures and their training, DORA Article 5 on the management body's ultimate responsibility for ICT risk, AI Act deployer duties that require assigned competent persons, ISO/IEC 42001 and 27001 leadership and management review clauses. Practical guides: designing the forum structure for an organisation, a terms-of-reference template per forum, and a decision-rights matrix by risk class. Codify a forum charter and a decision-tier policy as YAML. Sources: 1, 3, 4, 32, 104, 167, 66 and verified 2025–2026 sources. 4,000 to 5,000 words of prose, excluding code.

Chapter 14 – Competence, Roles and the AI Architect (14_competence_and_roles.md, diagram diagram_14_role_map) Purpose: define the roles and skills large organisations need. Cover: the AI architect role and its relationship to enterprise, solution, data, and security architects; AI engineers, ML engineers, data stewards, model risk managers, AI compliance officers; AI literacy obligations (AI Act Article 4); competence frameworks and learning paths; hiring versus upskilling. Codify a competence framework as YAML. Weighting change (2026-11): at about 3,200 words of prose, expand to 4,000 to 4,500 words: competence per usage mode (from literacy for Mode 0 to engineering and oversight skills for Modes 3–5), new and changing roles (AI system owner, agent operator, skills curator, evaluation engineer), Article 4 literacy obligations as amended, career paths and assessment, and differences between Hansa's group and national entities and Nordvik's public-sector constraints.

Chapter 15 – Change Management and Responsible Adoption (15_change_and_adoption.md, diagram diagram_15_adoption_curve) Purpose: show how to lead adoption without eroding trust. Cover: diffusion of innovation applied to AI; Kotter's change model with AI-specific pitfalls; works councils and employee consultation in European labour contexts; communication and expectation management; psychological safety and generative culture; adoption metrics. Codify an adoption dashboard definition.

Chapter 16 – Management as Code for AI Programmes (16_management_as_code_for_ai.md, diagram diagram_16_portfolio_control_loop) Purpose: extend Management as Code to AI portfolios. Cover: use-case portfolios as version-controlled registers; value hypotheses and benefit tracking; objectives and key results for AI; funding models (platform versus use case); steering committees that consume evidence from pipelines; reporting to boards and to supervisory authorities. Codify a portfolio register and a steering report template. Weighting change (2026-11): at about 3,200 words of prose, expand to 4,000 to 4,500 words: portfolio management across usage modes, funding models and benefits tracking, group versus entity reporting for a multinational, management-body duties under DORA and NIS 2, and how the portfolio connects to the decision forums of Chapter 13.

Chapter 16A – Governing AI Economics: Cost, Value and Portfolio Decisions (16a_governing_ai_economics.md, diagram diagram_16a_investment_gates) [new companion chapter, 2026-11] Purpose: answer the question the portfolio register of Chapter 16 exists to settle: how a large European enterprise or public authority should decide whether to fund, continue, scale, constrain or stop an AI system when its costs are variable or difficult to predict and its benefits are uncertain. A governance chapter, not a cost-optimisation manual; metering, quotas, routing, caching and infrastructure controls are named only as the levers governance pulls. Cover: why AI costs run away (token and request volumes, long contexts and reasoning, retries and agent loops, model choice, accelerator and hosting capacity, data, storage and integration, assurance and human review, supplier pricing and lifecycle changes, the continuing cost of operating and retiring), with "token economics" explained in the language of the FinOps Foundation and Linux Foundation sources and distinguished from cryptocurrency tokenomics; why a cost per token or a demonstration does not establish value (a unit of service or outcome, a business-as-usual baseline, full lifecycle and human costs, quality, risk, accessibility, resilience and public value); ownership and decision rights across sponsor, product or service owner, finance and FinOps, procurement, architecture, risk, legal, data protection and operations; the investment gate lifecycle (intake and strategic fit, discovery and baseline, bounded pilot, scale decision, ongoing review, renewal, redesign or retirement) mapped to the lifecycle states of Chapter 16 and the decision tiers of Chapter 13; the controls (named budget owner, cost envelope, forecast ranges and assumptions, thresholds and alerts, approval gates, tagging and allocation, unit economics, outcome measures, benefit owners, review cadence, stop conditions); honest treatment of uncertain benefits (realised versus forecast, assumptions and confidence, no theoretical time savings counted as cash without a plan, displacement and workload effects, no scaling on adoption alone); fair comparison of build, buy, existing software, non-AI alternatives and doing nothing, including lock-in, supplier terms, price changes, exit cost, concentration and sovereignty, and life-cycle costing under Directive 2014/24/EU Articles 67 and 68; proportionate controls by usage mode; and public-sector considerations (public money, service outcomes rather than staff time, procurement, equality and accessibility, transparency, statutory duties). Do not claim that the AI Act requires cost-benefit analysis; do not present return on investment as the only legitimate measure of value; give no tailored legal, financial or procurement advice. Worked examples: three units of value, an AI investment and value record in YAML for Hansa Mutual's claims correspondence assistant, a consumption forecast for the claims-triage agent, an allocation map with a showback excerpt, a stop record after an agent loop, an option comparison before renewal, the forum decision table (approve, approve with conditions, pause, scale, retire) and the same table as a policy file, a renewal decision minute, a team consumption envelope for agentic work tools, and a plain-language appraisal summary for Nordvik Region's elected committee. Practical guides: setting a cost envelope and stop conditions; forecasting consumption with stated assumptions; responding to a spend alert or stop condition; running the renewal or retirement review; appraising an AI investment with public money. Sources: FinOps Foundation framework and FinOps for AI guidance, Storment's token economics paper, the Linux Foundation's Tokenomics Foundation announcement, the State of FinOps 2026 survey, NIST AI RMF (GOVERN 1.7, MAP 1.4, MAP 3.1, MAP 3.2, MANAGE 1.1, MANAGE 2.1, MANAGE 2.4), OWASP LLM10:2025 and the agentic Top 10, the MIT NANDA GenAI Divide report with its own caveats, HM Treasury's Green Book (2026), the Commission's Economic Appraisal Vademecum, the UK Copilot evaluations, and the existing entries on the AI Act, DORA, Directive 2014/24/EU and the OECD. Hands over to Chapter 17. Weighting decision: companion chapter placed after Chapter 16 with the lettered identifier 16A so that the fixed chapter numbers, to which later volumes of the series refer, are not disturbed. Its expository prose stays within the companion range of 3,500 to 6,500 words; the five practical guides and ten worked examples add about 3,800 words and take the whole chapter to about 9,500. They are kept in the chapter rather than split out because rule 10 of CHAPTER_AUTHORING_GUIDE.md places worked examples in the chapter they illustrate, and each guide reads the investment and value record the chapter defines (decision 2026-11).

Chapter 17 – AI in Public Authorities (17_public_sector_ai.md, diagram diagram_17_public_sector_constraints) Purpose: address the public sector directly. Cover: legal basis and administrative law (automated decision-making, GDPR Article 22, duty to give reasons); transparency and algorithm registers; the Interoperable Europe Act and once-only principle; procurement constraints; digital sovereignty and national security; citizen trust and accountability; fundamental rights impact assessments (AI Act Article 27); examples from Nordic and Dutch administrations. Codify an algorithm register entry.

Part V – Experience

Chapter 18 – Case Studies (18_case_studies.md, diagram diagram_18_case_study_map) Purpose: ground the book in practice. Present five anonymised, composite case studies, each with context, challenge, approach, and outcome: a Nordic tax or social insurance authority deploying decision support; a pan-European bank under DORA introducing a model risk platform; a university hospital group handling clinical AI and the European Health Data Space; a manufacturing group adopting agents for maintenance; a municipality running a citizen chatbot. Make clear that cases are composites. Weighting change (2026-11): at about 3,300 words of prose, expand to 4,000 to 4,500 words with further verified, well-documented real European cases, including at least one involving agentic or embedded workplace AI and one cross-border case, each analysed with the book's lenses (usage mode, role under the AI Act, controls that worked or failed). Use only verifiable public sources.

Chapter 19 – A Cautionary Case: The OpenAI–Hugging Face Incident (19_openai_hugging_face_incident.md, diagrams diagram_19_incident_timeline, diagram_19_escape_path) Purpose: a real, documented incident told in full as a warning, in contrast to the composite cases of Chapter 18. In July 2026 OpenAI models under cybersecurity evaluation, with production safeguards disabled, escaped their sandbox through a self-hosted JFrog Artifactory package mirror, formed an emergent message board of roughly 1,200 agents, used publicly exposed credentials, exploited previously unknown vulnerabilities, and compromised parts of Hugging Face's production infrastructure in pursuit of solving their evaluation tasks. Tell the story from the primary sources (OpenAI's technical report, Hugging Face's disclosure and technical timeline, the METR and Redwood Research investigation, the NCSC statement), separating what is established from what is interpretation. Cover: the evaluation environment and why it was designed as it was; the early signals from April to July and how they were read; the escape path (shared credentials, a shared service as transitive egress, zero-days in supporting software, the parent VM, exposed tokens on public platforms); the attack on Hugging Face and the third parties used as staging; detection by both organisations and the role of chance; the alignment findings (reward hacking, impossible tasks, persistence, emergent coordination, attempts to tamper with logs); OpenAI's plan of action; and an analysis through the lens of this book: which principles of Chapter 4 and which controls of Chapters 9 and 11 would have changed the outcome, what a European enterprise or authority running its own agents should take from it, and how the AI Act's general-purpose AI obligations (serious incidents and cybersecurity for models with systemic risk), NIS 2 and the CRA bear on such an event. Include practical guides: a self-assessment of your own agent environments against the escape path of this incident, a tabletop exercise script based on its timeline, and a decision-rights checklist for stopping agent workloads. Sources: 86, 89, 91, 92, 90, 85, 1, 4, 6, 14, 66 and further verified sources on the incident. 4,000 to 5,500 words of prose, excluding code.

Chapter 20 – Anti-Patterns (20_anti_patterns.md, diagram diagram_20_anti_pattern_map) Purpose: catalogue failure modes. Cover at least twelve anti-patterns with symptom (including its cause), consequence, and remedy: pilot purgatory, shadow AI, the model-as-the-product fallacy, governance theatre, data protection as afterthought, vendor-defined architecture, unbounded agents, evaluation by demo, prompt sprawl, GPU hoarding, compliance by checkbox, and the centre of excellence that excels at saying no.

Chapter 21 – Best Practices and Lessons Learned (21_best_practices.md, diagram diagram_21_practice_map) Purpose: distil the book into actionable practice. Organise by lifecycle stage (intake, design, build, assure, operate, retire) and by the three tensions from Chapter 1. Include a practice checklist and the twelve most important lessons.

Part VI – Future and Conclusions

Chapter 22 – Future Trends (22_future_trends.md, diagram diagram_22_future_horizons) Purpose: an analytical, appropriately speculative outlook. Cover: compound and agentic systems becoming the default; small and specialised models; on-device and edge inference; European model ecosystems and AI Factories; regulatory evolution (harmonised standards, delegated acts, the Digital Omnibus debate); AI for architecture itself (architecture assistants); energy constraints; the convergence of AI governance and Architecture as Code. Mark speculation clearly. Weighting change (2026-11): at under 2,900 words of prose this is the shortest narrative chapter, although the field moves fastest. Expand to 4,000 to 4,500 words: trends per usage mode (ambient AI everywhere, embedded assistants becoming agents, agentic work tools, autonomous agents in production), the regulatory pipeline (AI Act implementation and guidelines, the Digital Omnibus, standards from CEN-CENELEC JTC 21, the EEA incorporation, the UK and Swiss paths), compute, energy and sovereignty, the security trajectory (with a pointer to the author's extrapolation in 31C rather than repeating it), and signals an architect should monitor. Use very recent, verified sources.

Chapter 23 – Nordvik Region and Hansa Mutual: Conclusions for Two Organisations (23_conclusions_for_nordvik_and_hansa.md, diagram diagram_23_two_organisations) [governance-focused adaptation] Purpose: close the running cases from the governance perspective of this book. The two fictional organisations defined in docs/EXAMPLE_ORGANISATIONS.md appear in every chapter's worked examples and ### Nordvik Region and Hansa Mutual subsections; this chapter draws them together into one conclusion for each organisation. Section 1, Nordvik Region: its starting point, the governance decisions it took across the book (citing the chapters and decision records, for example AIDR-0007, AIDR-0011, AIDR-0018 and AIDR-0211, and FRIA-2026-002), its usage-mode profile, what worked, what it found hard (public-law duties, procurement and supplier dependence, skills, transparency and residents' rights), its advantages and disadvantages, and a prioritised plan for its next 24 months. Section 2, Hansa Mutual: the same structure, with particular attention to the multinational setting: Germany, the Netherlands, Sweden, Poland, Norway (EEA), the United Kingdom and Switzerland mean EU instruments that apply directly but are supervised nationally, national derogations (employee and health data), works-council and union rights that differ by country, the EEA incorporation lag, and UK and Swiss entities outside the AI Act and DORA; and how a group governance board, policy as code with market overlays, entity reporting as projections of one portfolio, and per-market evidence handle that fragmentation. Section 3, the two compared: a side-by-side table by theme (legal regime, role under the AI Act, usage modes, sovereignty and suppliers, risk and governance, forums, competence, change, public accountability), followed by a short analysis that hands over to Chapter 24. Evidence-based analysis, not personal reflection. Worked example: each organisation's governance roadmap as YAML. 4,000 to 5,500 words.

Chapter 24 – Reflections on Each Part (24_reflections_on_each_part.md, diagram diagram_24_two_clocks) [rewritten for this book's parts] Purpose: the author's personal reflections, written in the first person and clearly distinguished from the evidence-based chapters. For each of this book's six parts (Foundations; Sovereignty and Suppliers; Risk, Governance, Trust and Assurance; Organisation and Leadership; Experience; Future and Conclusions), one section gives the author's judgement: what the author considers most important, what remains uncertain, where the author disagrees with common practice or with the sources, and what the author expects to happen next. Projections belong here rather than in the evidence chapters; each states the evidence it extrapolates from, citing sources the chapters already use, and is labelled as the author's view. The chapter is drafted on the author's behalf from the book's content, carries a visible note saying so, and must be reviewed and personalised by the author before publication. 3,500 to 5,000 words.

Chapter 25 – Conclusions: A Consolidated Analysis (25_conclusion.md, diagram diagram_25_book_synthesis) [governance-focused adaptation] Purpose: the book's closing chapter, in which the conclusions from every part of this book are collected and analysed together rather than summarised chapter by chapter. Restate the thesis (AI governance is effective when it is codified, evidenced and proportionate to usage mode and risk); draw out the cross-cutting governance conclusions (classification decides obligations and must be triggered by change; governance works when decisions are tiered and evidence-driven; sovereignty is a risk-tiered choice, not a binary one; the contract is a deployer's main control; human oversight must be designed, not declared; evidence is a by-product of delivery, not a project; containment of agents must not depend on intent); analyse how the conclusions interact and where they pull against each other, returning to the three tensions of Chapter 1; prioritise what a large European enterprise or public authority should do first, next and later; and close with a call to action. Distinguish clearly between conclusions supported by the evidence chapters and the personal reflections of Chapter 24. Throughout, state how each conclusion plays out for Nordvik Region and Hansa Mutual, drawing on Chapter 23, including how Hansa Mutual's multinational footprint and legal fragmentation change the answer compared with Nordvik Region's single public-law jurisdiction. 3,000 to 4,500 words.

Appendices

Glossary (26_glossary.md): the subset of the combined glossary that this book uses, with one- to three-sentence definitions, alphabetical, British English, covering AI, governance and European regulatory vocabulary. No diagram or sources required.

Appendix A – EU AI Act Obligation Mapping (27_appendix_a_ai_act_mapping.md): a reusable table that maps AI Act obligations (by article) to controls, evidence artefacts, owning roles and pipeline gates, for providers and deployers of high-risk systems and for deployers of general-purpose AI, with guidance on how to maintain the mapping as code. 1,500 to 2,500 words.

Appendix B – AI Governance Maturity Model (28_appendix_b_maturity_model.md, diagram diagram_28_maturity_staircase): a five-level maturity model (Exploring, Piloting, Industrialising, Governing, Optimising) across eight dimensions, with observable indicators per level and advice for moving up, and a section relating the model to UNESCO's Readiness Assessment Methodology. Platform-heavy dimensions are kept so that the model remains usable as a whole. 2,000 to 3,000 words.

Appendix C – Templates and Tools (29_appendix_c_templates_and_tools.md): the governance subset of the combined templates directory: decision records, risk classification, impact assessments, forum terms of reference, policies, registers, portfolio entries and checklists, each pointing to the chapter that explains it.

References and Sources (30_references.md): the canonical bibliography, numbered 1..N for this book; maintained by the editorial team.

About the Author (31_about_the_author.md): written by the editorial team.