AI Platform and Security – Book Blueprint and Chapter Briefs

This document is the editorial blueprint for AI Platform and Security, Book 3 of The Transformed Architecture. It records the premise of the book, its relationship to the other volumes of the series, the audience, 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 Platform and Security applies that conviction to the platform on which artificial intelligence runs in large European enterprises and public authorities: the data, model and prompt pipelines, the retrieval stores and agent runtimes, the gateways and compute, and the security controls that keep all of it within its mandate.

AI systems break several assumptions that classical platform and security engineering rely 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. Their agents hold credentials and act on the organisation's behalf. And the same technology is available to attackers, who use it to shorten the time between the disclosure of a vulnerability and its exploitation.

The book's thesis is that these are engineering problems with architectural answers, and that the Architecture as Code disciplines (declarative intent, version control, policy as code, evidence as code) are the most reliable foundation for them. Every chapter names the platform or security 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 platform engineers and platform owners, solution and enterprise architects, security architects and chief information security officers, MLOps and data engineering leads, and AI architects in organisations with more than a few thousand employees. Public authorities are treated as first-class readers throughout. Governance, risk and compliance readers will find the platform's evidence described here and its use in governance described in AI Governance.

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 Cyber Resilience Act), treated in this book as engineering requirements (Chapter 3). Where the book names tools or vendors it stays neutral and prefers open standards and open models.

Relationship to the other volumes of the series

The Transformed Architecture has three standalone books by Gunnar Nordqvist:

1. Architecture as Code (Book 1), published at https://aac.geon.se, supplies the underlying discipline: version control, automation, policy as code, evidence as code and management as code.
2. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities (Book 2), published at https://aig.geon.se, covers the full regulatory map, principles, readiness, model origin and geopolitics, procurement, risk management, governance as code, trustworthy AI, assurance and audit, organisation and leadership, public authorities, case studies, anti-patterns and future trends.
3. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities (Book 3, this book), published at https://aips.geon.se, covers the platform, DevSecMLOps, infrastructure, security and operations.

Readers do not need to have read either companion volume. Where a topic is treated in the sibling volume, chapters summarise just enough to avoid a gap and refer to it in plain text as "AI Governance, Chapter N" (no link), citing it as a bibliography entry (Nordqvist, 2026). Architecture as Code is cited as Nordqvist, 2025, and referred to as "Architecture as Code (Chapter N)". The most important mappings to Architecture as Code are:

Chapter of this book	Builds on Architecture as Code chapter(s)
2 Usage Modes of Large Language Models	1 Introduction; 2 Fundamental Principles
3 Regulatory Requirements as Engineering Constraints	12 Compliance
5 AI Decision Records	4 Architecture Decision Records; 22 Documentation as Code
7 Model Lifecycle	5 Automation, DevOps and CI/CD; 13 Testing Strategies
8 DevSecMLOps Loop	3 Version Control; 5 Automation, DevOps and CI/CD; 10 Policy as Code; 13 Testing Strategies; 15A Evidence as Code
9 DevSecMLOps Risks	3 Version Control; 9B Advanced Security Patterns; 10 Policy as Code; 15A Evidence as Code
13 Infrastructure and Sovereignty	7 Containerisation; 25 Future Trends (digital sovereignty)
14 Cloud versus On-Premises AI	7 Containerisation; 15B Cost Optimisation; 16 Migration
16 Security for AI	9 Security Fundamentals
17 AI Security Engineering	9B Advanced Security Patterns; 9C Risk as Code
18 When AI Is the Threat	9 Security Fundamentals; 9C Risk and Threat Handling as Code
22 Cost and Sustainability	15B Cost Optimisation

The sibling volume's table of contents is fixed and is used for every cross-reference: 1 Introduction to AI Governance; 2 From Chat to Agents: How Large Language Models Are Used; 3 The EU AI Act and the European Regulatory Landscape; 4 Fundamental Principles; 5 Prerequisites and Readiness for Enterprise AI; 6 Geopolitics and Model Origin; 7 Procurement, Vendor Management and Open Models; 8 AI Risk Management and Classification as Code; 9 AI Governance as Code; 10 Trustworthy AI: Transparency, Fairness and Human Oversight; 11 Evidence, Assurance and Audit; 12 Organisational Design for AI; 13 Decision Forums and Governance Bodies; 14 Competence, Roles and the AI Architect; 15 Change Management and Responsible Adoption; 16 Management as Code for AI Programmes; 16A Governing AI Economics: Cost, Value and Portfolio Decisions; 17 AI in Public Authorities; 18 Case Studies; 19 A Cautionary Case: The OpenAI–Hugging Face Incident; 20 Anti-Patterns; 21 Best Practices and Lessons Learned; 22 Future Trends; 23 Nordvik Region and Hansa Mutual: Conclusions for Two Organisations; 24 Reflections on Each Part; 25 Conclusions: A Consolidated Analysis; Appendix A EU AI Act Obligation Mapping; Appendix B AI Governance Maturity Model; Appendix C Templates and Tools.

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. The discipline is written AI Architecture, the book title AI Platform and Security, the sibling volume AI Governance and the companion discipline Architecture as Code.
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 or ## Conclusion section that points forward to the next chapter, and a closing ## Sources section.
3. Length. As set out in rule 2 of CHAPTER_AUTHORING_GUIDE.md. 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 and weighting changes 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](28_references.md#source-N)), and refer only to entries that exist in 28_references.md. The ## Sources section lists every cited work. No invented sources.
5. Europe first. Every chapter contains at least one concrete European or public-sector consideration. Legal statements are attributed to the specific regulation and article, 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.
8. Defensive security only. Security chapters describe threats at the level needed to design controls and tests; they do not provide attack tooling.

Chapter briefs

Part I – Foundations

Chapter 1 – Introduction to AI Platform and Security (01_introduction.md, diagram diagram_01_ai_architecture_landscape) Purpose: introduce this book on its own terms. Cover: why an AI platform is an architectural and security problem rather than a model-selection problem; the properties of AI systems that break classical assumptions (probabilistic behaviour, the model as a derived artefact, opaque third-party supply chains, agents that act); the purpose, readers and scope of the book; how it fits The Transformed Architecture, what Architecture as Code supplies and what the sibling volume AI Governance covers, with enough summary that the reader is not left with a gap; the usage modes as the red thread; the section "Two organisations that run through this book" introducing Nordvik Region and Hansa Mutual (anchor {#the-two-organisations}); how to read the book, part by part and by role. Cite Architecture as Code and AI Governance as bibliography entries. Rewritten for the standalone edition (2026-11) from the combined manuscript's Chapter 1.

Chapter 2 – Usage Modes and the Platform: What Each Mode Demands (02_llm_usage_modes.md, diagram diagram_02_usage_modes) Purpose: give this book's platform view of the six usage modes of large language models, whose full taxonomy (products, tiers, legal roles, mode drift, competence, the usage-mode register and its practical guide) lives in AI Governance, Chapter 2. Keep the canonical names, numbering and anchors that other chapters link to: Mode 0 – Ambient AI {#mode-0}, Mode 1 – Conversational assistants {#mode-1}, Mode 2 – Embedded workplace assistants {#mode-2}, Mode 3 – Agentic work tools {#mode-3}, Mode 4 – Built AI applications {#mode-4}, Mode 5 – Autonomous production agents {#mode-5}, and the comparison matrix {#usage-mode-matrix} (Table 2.1), here framed by who operates the runtime, what the model sees and can do, the identity it acts with, the organisation's usual AI Act role, the platform control point and the evidence the organisation can hold. Recap each mode briefly and name its control point. Then, for five platform capabilities (gateway and routing; identity and delegated authority; isolation and containment; logging and evidence; data boundaries), describe what each mode requires and which later chapters build it (Chapters 4, 8, 11, 12, 14 to 19 and 21), condensed into a minimum platform baseline per mode (Table 2.2). Treat a change of mode as a platform event that provisioning must check, and approvals as naming service, tier, mode and data classes rather than a brand. Include a practical guide (map each use case to its platform control point) and a worked example (Hansa Mutual's per-mode baseline as platform policy, with the claims-triage agent's move from Mode 4 to Mode 5, and an extract of Nordvik Region's register). Close with where the book builds each mode's platform ({#modes-in-the-book}). Cite vendor documentation only for the platform-relevant facts, stated as of the access date. 2,500 to 3,500 words. Weighting (standalone edition, 2026-11): shortened from the combined manuscript's companion chapter, which duplicated AI Governance, Chapter 2; the full taxonomy is referenced there rather than repeated.

Chapter 3 – Regulatory Requirements as Engineering Constraints (03_regulatory_requirements.md, diagram diagram_03_regulatory_map) Purpose: condense the European regulatory landscape into the engineering requirements that a platform must meet. Cover: the AI Act's risk-based structure and roles only to the depth needed to decide which requirements apply; Articles 9 to 15 (risk management system, data and data governance, technical documentation, record-keeping, transparency to deployers, human oversight, accuracy, robustness and cybersecurity) as platform capabilities; Article 26 (deployer obligations, including log retention and monitoring) and Article 50 (transparency for certain AI systems); Articles 72 and 73 (post-market monitoring and serious-incident reporting) as observability and incident-handling requirements; general-purpose AI model obligations as supplier evidence the platform consumes; the Cyber Resilience Act, NIS 2 and DORA as security and resilience requirements; the GDPR's data protection by design (Article 25) and security of processing (Article 32). For each requirement name the platform capability, the codified artefact and the evidence. Refer to AI Governance, Chapter 3, for the full regulatory map, timelines and national competent authorities. Frame everything as architectural implications, not legal advice. New for the standalone edition (2026-11), condensed from the combined manuscript's Chapter 2.

Chapter 4 – A Reference Architecture for AI in Large Organisations (04_reference_architecture.md, diagrams diagram_04_reference_layers, diagram_04_control_plane) Purpose: give readers a layered reference architecture they can adapt. Layers: data foundation; model and feature layer; serving and inference; orchestration and agent layer; application and channel layer; cross-cutting control plane (identity, policy, observability, evidence). Describe the AI gateway pattern, model registry, evaluation service, and prompt and policy repositories. Show how the reference architecture maps to the AI Act roles of provider and deployer. Express the architecture in a declarative YAML or C4-style model. Weighting change (2026-11): at about 3,200 words of prose the reference architecture is underweight for the chapter the rest of the book builds on. Expand to 4,500 to 5,500 words: which layers each usage mode actually uses, deployment variants (cloud, on-premises, hybrid, sovereign), the agent and connector layer, multi-jurisdiction overlays for a group like Hansa Mutual, a reduced variant for a smaller authority like Nordvik Region, and how the reference architecture maps to the later chapters.

Chapter 5 – AI Decision Records, Model Cards and the Architecture Repository (05_ai_decision_records.md, diagram diagram_05_decision_record_flow) Purpose: extend ADRs to AI. Cover: the AI Decision Record template (adds intended purpose, risk classification, data sources, evaluation criteria, human oversight, retirement criteria); model cards and datasheets as version-controlled companions; the system card for compound systems; the architecture repository as the single source of truth demanded by AI Act technical documentation (Article 11 and Annex IV). Provide complete templates in Markdown and YAML.

Part II – Data, Models and DevSecMLOps

Chapter 6 – Data Architecture for AI (06_data_architecture.md, diagram diagram_06_data_products_for_ai) Purpose: show how data architecture must change to feed AI responsibly. Cover: data products and data mesh in large organisations; data contracts; lineage and provenance; feature stores versus vector stores; synthetic data and its limits (model collapse); personal data and lawful basis for training (GDPR Articles 5, 6, 9, 22, EDPB Opinion 28/2024); the Data Act and Data Governance Act as enablers; European data spaces. Codify a data contract and a data product descriptor.

Chapter 7 – Model Lifecycle Management: MLOps and LLMOps as Code (07_model_lifecycle_mlops.md, diagram diagram_07_model_lifecycle) Purpose: describe the model lifecycle as a pipeline. Cover: experiment tracking, registry, promotion gates, deployment strategies (shadow, canary, champion–challenger), rollback, retirement; LLMOps differences (prompt versioning, evaluation sets, guardrail configuration, fine-tuning with LoRA); the ML Test Score; reproducibility; separation of duties in regulated organisations. Provide a pipeline definition (GitHub Actions or generic YAML) with evaluation gates.

Chapter 8 – Setting Up an Effective DevSecMLOps Loop (08_devsecmlops_loop.md, diagrams diagram_08_loop, diagram_08_revision_backbone) Purpose: describe, as a buildable design, the end-to-end loop through which a large organisation delivers AI systems safely and fast: plan and intake, code, data, model training or adaptation, prompts and configuration, evaluation, security and policy gates, release, operation, monitoring, and feedback into the next iteration. Chapter 7 treats the model's lifecycle; this chapter treats the whole socio-technical loop around it. Make revision management the backbone: every artefact that shapes behaviour (application code, infrastructure, data snapshots and data contracts, features, model weights, prompts and system instructions, retrieval indexes, evaluation sets, guardrail and policy configurations, decision records) is versioned, linked by identifiers, and reproducible from a commit; describe branching and trunk-based practice, repository topology, data and model versioning, signed commits and artefacts, immutable history, provenance and attestations, and how a release is the set of versions that were evaluated together. Cover the "Sec" throughout (threat modelling at intake, secrets management, dependency and model scanning, policy as code, signing, ML-BOM), the "Ops" (deployment strategies, observability, incident feedback), and the people (who owns which stage, review and four-eyes rules, AI coding assistants in the loop and their limits). Measure the loop (flow metrics adapted from DORA, evaluation pass rates, time from advisory to patched model or dependency). Treat agent skills, agent definitions, prompts and tool connectors (for example MCP servers) as managed, shared assets of the organisation rather than something every user writes for themselves: a governed catalogue with owners, versioning, review and signing, testing and evaluation before publication, distribution through the platform, usage telemetry, deprecation, and a path for users to propose improvements, because thousands of private, unreviewed skills are both inefficient and a security risk. Anchor the loop in traditional information security: show how the loop implements and evidences the ISO/IEC 27001:2022 information security management system and the relevant ISO/IEC 27002:2022 controls (asset inventory, access control, secure development, configuration management, change management, logging and monitoring, supplier relationships, use of cloud services, threat intelligence, data leakage prevention), and how ISO/IEC 42001 builds on the same management-system structure. Build explicitly on Architecture as Code (version control, CI/CD, testing, policy as code, evidence as code), citing its chapters at aac.geon.se. Practical guides: setting up the repository and revision model for an AI system; a reference pipeline with gates from commit to production; making a release reproducible and auditable; establishing a governed catalogue of skills and agents. Codify a repository layout, a skill or agent catalogue entry with owner, version, review status and permissions, a pipeline definition with security and evaluation gates, and a release manifest that pins every artefact version. Sources: the companion volume's chapters, verified 2025–2026 sources, plus 1, 43, 44, 45, 47, 49, 50, 81, 83, 100, 109. 4,500 to 5,500 words of prose, excluding code. Weighting (standalone edition, 2026-11): this chapter was a companion chapter in the combined manuscript and keeps the companion length range of up to 6,500 words of prose (authoring guide, rule 2); splitting it would separate material that is read together.

Chapter 9 – Risks and Vulnerabilities Across the DevSecMLOps Loop (09_devsecmlops_risks.md, diagram diagram_09_attack_surface, and a table of recurring revision-management failures) Purpose: walk the loop of Chapter 8 stage by stage and set out, for each stage, the risks and vulnerabilities that large organisations actually meet, the documented incidents behind them, and the controls that address them. Stages: source control and CI (compromised actions and workflows, cache poisoning, leaked secrets, unsigned or rewritten history, branch-protection bypass); AI coding assistants and agents in the loop (prompt injection through repository content, rules-file backdoors, insecure generated code, agents with pipeline credentials); dependencies and package mirrors (malicious packages, worms, artefact repositories as transitive egress, as in AI Governance, Chapter 19); data and training (poisoning, contamination, unlicensed or personal data, lineage gaps); model artefacts and registries (malicious models, unsafe deserialisation, unsigned weights, registry tampering, exposed ML platforms); prompts, retrieval indexes and configuration (unreviewed prompt changes, index poisoning); evaluation (contaminated or leaked evaluation sets, gamed graders); deployment and inference (vulnerable inference servers, exposed endpoints); monitoring and evidence (missing lineage, tampered logs, retention gaps). Give revision management special weight: show how most of these risks are either caused by or contained by the quality of version control, and what "effective revision management" requires (complete coverage of artefacts, signed and immutable history, protected branches, reproducibility, retention aligned with AI Act record-keeping and DORA). Include the risks of unmanaged skills and agents (private copies, unreviewed instructions, tool connectors from unknown sources, poisoned shared skills) and map the stage risks to ISO/IEC 27001:2022 Annex A controls, so that the loop's risks sit inside the organisation's existing information security management system rather than beside it. Close with a risk register as code for the loop. Practical guides: a stage-by-stage risk assessment of an existing pipeline; hardening the source-control and CI layer; responding to a compromised dependency or model artefact. Build on Architecture as Code (version control, security patterns, policy as code, evidence as code) at aac.geon.se. Sources: verified 2024–2026 incident and research sources, the companion volume's chapters, plus 1, 4, 7, 39, 40, 43, 44, 45, 66, 67, 156. 4,500 to 5,500 words of prose, excluding code. Weighting (standalone edition, 2026-11): this chapter was a companion chapter in the combined manuscript and keeps the companion length range of up to 6,500 words of prose (authoring guide, rule 2); splitting it would separate material that is read together.

Chapter 10 – Foundation Models, Retrieval and Grounding (10_foundation_models_rag.md, diagram diagram_10_rag_architecture) Purpose: explain the architectural choices around foundation models. Cover: build, buy, or adapt; general-purpose AI model obligations under the AI Act (Chapter V) and the GPAI Code of Practice; retrieval-augmented generation and its failure modes; grounding, citations, and hallucination management; chunking, embeddings, and vector indexes; prompt engineering as configuration; context windows and cost. Codify a RAG pipeline configuration and an evaluation set.

Chapter 11 – Agentic Architectures and Orchestration (11_agentic_architectures.md, diagrams diagram_11_agent_patterns, diagram_11_bounded_autonomy) Purpose: treat agents as architectural components with explicit boundaries. Cover: workflows versus agents; tool use and the Model Context Protocol; multi-agent patterns (orchestrator–worker, evaluator–optimiser, routing); bounded autonomy and permission models; approval gates and human-in-the-loop; auditability of agent actions; failure modes (loops, escalation of privilege, cost run-away). Codify an agent permission manifest and a tool allow-list.

Chapter 12 – Integrating AI into the Enterprise Landscape (12_integration_patterns.md, diagram diagram_12_integration_patterns) Purpose: show how AI capabilities connect to existing systems. Cover: the AI gateway; synchronous and event-driven integration; integrating with legacy systems of record; identity propagation and delegated authority; API contracts for probabilistic services (confidence, provenance, fallbacks); caching and idempotency; the Interoperable Europe Act and the European Interoperability Framework for public bodies. Codify an API contract (OpenAPI excerpt) for an AI service.

Part III – Infrastructure

Chapter 13 – Infrastructure, Compute and European Digital Sovereignty (13_infrastructure_sovereignty.md, diagram diagram_13_sovereignty_options) Purpose: address where AI runs and who controls it. Cover: GPU scarcity and capacity planning; hybrid and on-premises inference; European cloud providers, Gaia-X, EuroHPC AI Factories; data residency, Schrems II, and third-country transfer risk; confidential computing; sovereign model choices (open-weight European models); infrastructure as code for AI platforms. Provide a sovereignty decision matrix and a Terraform or Kubernetes excerpt.

Chapter 14 – Cloud AI Services versus On-Premises AI: Different Challenges (14_cloud_versus_on_premises_ai.md, diagram diagram_14_decision_flow, and a table of the responsibility split) Purpose: compare the challenges of consuming AI as a cloud service (model APIs, managed AI platforms, AI features embedded in SaaS) with running AI on premises or in a private cloud (own accelerators, open-weight models), so that an organisation chooses deliberately and knows what it takes on with each. Cover, for each challenge, how it differs between the two: cost and its predictability; capacity, accelerator supply and power; model change (deprecations, silent updates, version pinning versus owning upgrades); security and the shared-responsibility split (who patches, who filters, who monitors; exposed self-hosted inference servers); data protection, residency and retention terms; regulatory roles under the AI Act (when self-hosting or fine-tuning makes the organisation a provider), DORA third-party risk and critical providers, the Data Act's switching rights, NIS 2; operational burden and skills (evaluation, safety filtering, observability, incident response); lock-in and portability; sustainability. Then hybrid patterns (an AI gateway in front of both, routing by data class and workload, burst to cloud, sovereign private cloud) and the public-sector specifics. Practical guides: a decision workflow for placing a workload; a readiness checklist before self-hosting a model; contract and configuration controls before relying on a cloud AI service (retention, residency, version pinning, deprecation notice, exit). This chapter complements Chapter 13, which treats placement and sovereignty at the level of infrastructure. Sources: verified 2025–2026 sources added to the bibliography, plus 3, 5, 31, 41, 42, 93, 94. 4,000 to 5,500 words of prose, excluding code. Hybrid agentic work with OpenCode: extend the hybrid-patterns discussion with a dedicated section ## Hybrid agentic work: OpenCode and sensitive information {#hybrid-agentic-work-opencode} that describes OpenCode specifically (the open-source, provider-agnostic coding and task agent for the terminal, desktop and IDE; verify its licence, provider model, support for self-hosted models through OpenAI-compatible endpoints such as vLLM, Ollama or llama.cpp, configuration files and precedence, agent and permission definitions, MCP support, session-sharing and telemetry settings against its current documentation and repository) and how such a tool enables a hybrid way of working in which the same agentic workflow uses self-hosted models for sensitive information and cloud-hosted frontier models for non-sensitive work. Make the connection to sensitive information sets explicit: routing by information classification (for example public, internal, confidential, and special-category or classified data, including personal data under GDPR Article 9, security-protected information and trade secrets); which model may see which repository or data set; the fact that the agent sends whatever context it gathers (files, command output, tool results) to the selected model, so routing must be decided before the session starts rather than per prompt; enforcement outside the tool (network egress control, an AI gateway or model proxy, separate workstations or containers per classification, credential scoping, disabling cloud providers and session sharing in managed configuration) because a client-side setting alone is not a control; capability gaps of local models (tool calling, context length, quality) and how to evaluate them; logging and evidence; and how this relates to the usage modes (Mode 3, and Mode 5 when run unattended), to model origin (AI Governance, Chapter 6) and to ISO/IEC 27001 controls (Chapter 8/8C). Include a practical guide (setting up a classification-routed hybrid agent environment) and a worked example: an OpenCode configuration for Nordvik Region or Hansa Mutual with a self-hosted provider and a cloud provider, agents or profiles per classification, permissions, disabled sharing, plus the matching egress or gateway policy, marked as illustrative and checked against the current configuration schema. Avoid product marketing. Also name the other established tools that can solve the same hybrid problem (for example other open-source, provider-agnostic agentic tools that work with self-hosted and cloud models; verify which genuinely support both), in a short table of how each supports self-hosted models, managed configuration and egress control, and state that OpenCode is used as the worked example because it is the most established of these alternatives, giving the verifiable basis for that judgement (for example adoption indicators as of the access date). Weighting change (2026-11): at over 8,000 words of prose, the hybrid agentic work material (the OpenCode section, its practical guide and worked example, and the comparison of provider-neutral agents) moves to Chapter 15. 12C keeps the general hybrid patterns and a short paragraph that points to 12D. Target 5,000 to 6,000 words of prose. Weighting (standalone edition, 2026-11): this chapter was a companion chapter in the combined manuscript and keeps the companion length range of up to 6,500 words of prose (authoring guide, rule 2); splitting it would separate material that is read together.

Chapter 15 – Hybrid Agentic Work: Self-Hosted and Cloud Models for Sensitive Information (15_hybrid_agentic_work.md, diagram diagram_15_hybrid_routing moved and renamed diagram_15_hybrid_routing) Purpose: split from 12C. How provider-neutral agentic work tools let one workflow use self-hosted models for sensitive information and cloud-hosted models for the rest, with OpenCode as the worked example because it is the most established of the provider-neutral open-source alternatives (keep the bounded claim and the evidence exactly as stated in 12C, including why Codex CLI is outside that set). Cover: what OpenCode is; the comparison table of provider-neutral agents; routing by information class and jurisdiction, decided before the session starts because the agent sends whatever context it gathers to the selected model; enforcement outside the client (gateway, egress control, separate environments, managed configuration); capability gaps of local models and how to evaluate them; evidence and ISO/IEC 27001 controls; relation to usage modes 3 and 5, to model origin (12B) and to agent containment (16D). Move the anchor {#hybrid-agentic-work-opencode} to this chapter and update every inbound link (for example from Chapter 2). Keep the practical guide and the worked OpenCode configuration with its gateway policy, and extend the chapter so that it stands on its own: an operating model for running self-hosted models for agentic work (capacity, model updates, evaluation cadence), a cost comparison, and an ### Across the usage modes and a ### Nordvik Region and Hansa Mutual subsection (Hansa routes by owning entity and class across seven jurisdictions; Nordvik's small platform team uses only the self-hosted route for anything above internal). Target 3,500 to 4,500 words of prose.

Part IV – Security

Chapter 16 – Security for AI Systems (16_security_for_ai.md, diagram diagram_16_ai_threat_surface) Purpose: extend security architecture to models, prompts, and agents. Cover: OWASP Top 10 for LLM applications; MITRE ATLAS; prompt injection (direct and indirect); data poisoning; model extraction and training-data leakage; supply-chain security for models (ML-BOM, signing, SLSA); secrets and tool permissions for agents; ENISA's framework; the Cyber Resilience Act and NIS 2 as drivers. Codify a threat model and a guardrail policy.

Chapter 17 – AI Security Engineering in Practice (17_ai_security_engineering.md, diagrams diagram_17_defence_in_depth, diagram_17_incident_flow) Purpose: the companion to Chapter 16, in the same relationship as Chapter 9B stands to Chapter 10 in Architecture as Code. Where Chapter 16 maps the threat landscape and the catalogues, this chapter is the engineering handbook: how a large organisation actually designs, builds, tests, and operates secure AI systems, and how it proves it. Cover, in depth: a threat-modelling method for AI systems (assets: data, model, prompts, retrieval corpus, tools, outputs; trust boundaries; STRIDE extended with MITRE ATLAS tactics; threat model as code reviewed with every change); securing the data and training path (poisoning defences, provenance, dataset signing, access control); securing retrieval and RAG (entitlement-aware retrieval, document-level access control, indirect injection through documents, index integrity, exfiltration through outputs); securing inference and the AI gateway (layered input and output guardrails, PII redaction, content safety, rate limiting, model access control, logging that does not leak); securing agents and tool use (least-privilege workload identities, scoped and short-lived tokens, trust in MCP servers, sandboxing, approval thresholds, budget and loop limits, tamper-evident audit); supply-chain depth (model provenance, ML-BOM, Sigstore signing, SLSA for model pipelines, unsafe serialisation formats, registry gating, licence checks); red teaming and continuous security testing in CI, including the adversarial-testing obligations for general-purpose AI models with systemic risk (AI Act Article 55); detection, monitoring, and incident response for AI, with playbooks for prompt injection, model theft, and data leakage and the reporting duties under NIS 2 Article 23, the AI Act Article 73, DORA Article 19, and the Cyber Resilience Act's vulnerability-handling requirements; security evidence and assurance (mapping controls to ISO/IEC 42001 and ISO/IEC 27001, ENISA's framework, CRA essential requirements, security requirements in procurement). Codify a threat model as YAML, a layered gateway guardrail configuration, an agent workload-identity policy, and a CI security-testing job. 3,200 to 3,800 words.

Chapter 18 – When AI Is the Threat: AI-Enabled Attackers and the Collapsing Exploitation Window (18_when_ai_is_the_threat.md, diagram diagram_18_exploit_window) Purpose: the third security chapter. Chapters 16 and 17 treat AI as the target; this chapter treats AI as the source of threat, in two forms that share one architectural response. First, adversaries who use AI: the shift in attacker economics when models automate reconnaissance, vulnerability research, exploit development, social engineering, and campaign orchestration; patch diffing and automated exploit generation, from the patch-based exploit generation research of 2008 to LLM agents exploiting one-day vulnerabilities from advisories, so that every published patch is also an exploit specification; the collapse of the time between disclosure and exploitation and why monthly patch cycles no longer match the threat; AI-assisted vulnerability discovery; agentic intrusion campaigns; AI-generated phishing, voice cloning and deepfake fraud against approval processes. Second, the organisation's own agents that exceed their mandate without any attacker involved: specification gaming and reward hacking, agents that work around sandboxes, permissions, tests, time limits or oversight to complete a task or to help the user, and agents that misreport what they did; treat the agent as a well-meaning insider whose good intentions are not a control. The shared architectural response: containment that does not depend on the model's intentions (no ambient authority, capability-scoped and short-lived credentials, no access to container runtimes or its own guardrails, policies, tests, logs or kill switch, egress control, separation of development and production), canaries and honeytokens that reveal overreach, tamper-evident logging outside the agent's reach, two-person approval for irreversible actions, evaluation for specification gaming before deployment; exposure management and an accurate software inventory (SBOM), risk-based prioritisation with EPSS and known-exploited catalogues, patch velocity as a measured service level with emergency paths, virtual patching and compensating controls, immutable and rapidly redeployable infrastructure, segmentation and zero trust to limit blast radius, identity and approval processes resistant to synthetic media, AI-assisted detection and response with human oversight, and continuous adversary emulation. The European frame: CRA vulnerability handling and reporting, NIS 2 coordinated vulnerability disclosure and the European vulnerability database, DORA threat-led penetration testing, AI Act Articles 14 and 15 and the systemic-risk obligations for general-purpose AI models including loss of control in the Code of Practice. Include practical guides that a reader can follow step by step, each with a purpose, the roles involved, numbered steps, a codified artefact where one helps, and a definition of done: (1) compressing the patch window from advisory to protection, including triage with EPSS and known-exploited catalogues, emergency change, virtual patching and verification; (2) a first-hours playbook when a critical patch is published and an AI-generated exploit should be assumed within days; (3) building a containment sandbox for coding and operations agents, step by step; (4) detecting agent overreach with canaries, honeytokens and behavioural signals; (5) hardening payment and access approvals against voice cloning and deepfake video; (6) responding when an agent has exceeded its mandate; (7) a 30-60-90-day plan for a large organisation or public authority. Codify a patch-velocity policy with service levels by exploitability, an agent containment profile that denies self-modification and out-of-sandbox capabilities, and a synthetic-media-resistant approval policy. 5,000 to 6,000 words of prose, excluding code. Sources: verified sources on AI-enabled offence added to the bibliography, plus 1, 3, 4, 7, 28, 40, 94. Weighting change (2026-11): the chapter had grown to over 7,000 words of prose covering two distinct threats. It now covers only the first, adversaries who use AI, together with the shared European frame and the guides on patch velocity, the first hours after a critical patch and synthetic-media-resistant approvals. The second, the organisation's own agents that exceed their mandate, moves to Chapter 19 with its guides on containment sandboxes, overreach detection and response. 16C keeps a short section that introduces 16D and states the shared principle (containment and controls that do not depend on intent). Target 4,000 to 5,000 words of prose.

Chapter 19 – When Your Own Agents Exceed Their Mandate: Containment That Does Not Depend on Intent (19_agents_that_exceed_their_mandate.md, diagram diagram_16c_agent_containment moved and renamed diagram_19_agent_containment) Purpose: the fourth security chapter, split from 16C. Treat the organisation's own agents (usage modes 3 and 5) as a source of risk without any adversary: specification gaming and reward hacking; working around sandboxes, limits and oversight to complete a task or to "help"; misreporting and the limits of self-report; the well-meaning insider, and why instructions are not a control. Then the architectural response: containment enforced by the platform, not by the agent; least privilege and scoped credentials; egress control; budgets and stop paths; detection of overreach from telemetry rather than from the agent's own account; approvals for consequential actions; and incident response when an agent has exceeded its mandate. Connect to Chapter 11 (bounded autonomy), 8B (skills and agent catalogue), 12D (hybrid agentic work), 16B (engineering controls), the GPAI Code of Practice's loss-of-control provisions, and the AI Act's human-oversight and logging requirements. Move the relevant material, practical guides and worked examples from 16C (containment sandbox, overreach detection, responding to an agent that exceeded its mandate) and extend them, so that the chapter stands on its own; add an ### Across the usage modes subsection and a ### Nordvik Region and Hansa Mutual subsection (Nordvik runs no Mode 5 agents and limits Mode 3 to its platform team; Hansa runs the claims-triage agent and the IT-operations agent, AIDR-0027, across several jurisdictions). Defensive and architectural only. Target 4,000 to 5,000 words of prose.

Part V – Delivery and Operations

Chapter 20 – Evaluation and Testing of AI Systems (20_evaluation_and_testing.md, diagram diagram_20_evaluation_pyramid) Purpose: define a testing strategy for probabilistic systems. Cover: the evaluation pyramid (unit tests for code, data tests, model metrics, behavioural and scenario tests, red teaming, human evaluation); golden datasets and their governance; LLM-as-a-judge and its limits; regression testing for prompts and models; acceptance criteria as code; HELM-style holistic evaluation; adversarial testing obligations for general-purpose AI with systemic risk. Codify an evaluation suite definition.

Chapter 21 – Observability, Monitoring and Drift in Production (21_observability_and_drift.md, diagram diagram_21_observability_stack) Purpose: keep AI systems trustworthy after go-live. Cover: data drift, concept drift, and performance decay; OpenTelemetry semantic conventions for generative AI; tracing agent actions; quality monitoring with sampled human review; feedback loops; incident management for AI; service level objectives for probabilistic services; monitoring obligations under the AI Act. Codify alerting rules and a drift detection job.

Chapter 22 – Cost, Capacity and Sustainability of AI (22_cost_and_sustainability.md, diagram diagram_22_cost_drivers) Purpose: treat cost and energy as architectural constraints. Cover: token economics and inference cost models; capacity planning for GPUs; caching, routing to smaller models, and batching; FinOps for AI with chargeback; energy and carbon accounting (SCI, reporting trends); the Corporate Sustainability Reporting Directive context; public-sector budget cycles. Codify a cost policy and a model-routing configuration.

Chapter 23 – From Pilot to Production: Scaling AI Across the Organisation (23_pilot_to_production.md, diagram diagram_23_pilot_to_production) Purpose: explain why most pilots stall and how to industrialise. Cover: the pilot trap; platform thinking and golden paths for AI; reusable components (gateway, evaluation, guardrails); use-case intake and prioritisation; production readiness reviews; the deployment checklist aligned to AI Act obligations; scaling across business units and agencies. Codify a production readiness checklist and a use-case intake form.

Part VI – Conclusions

Chapter 24 – Nordvik Region and Hansa Mutual: Platform and Security Conclusions (24_conclusions_for_nordvik_and_hansa.md, diagram diagram_24_two_organisations) Purpose: close the running cases for this book. Draw together the ### Nordvik Region and Hansa Mutual subsections of Chapters 1 to 23 into one platform-and-security conclusion per organisation and a comparison. Section 1, Nordvik Region: starting point, the platform and security decisions it took (citing chapters and decision records), its usage-mode profile, what it built first, what it found hard, what it would do next. Section 2, Hansa Mutual: the same, with particular attention to how a multinational footprint shapes the platform: jurisdiction overlays in policy as code, data flows through the shared service centre in Poland, and the United Kingdom and Swiss entities outside the EU and their separate legal regimes. Section 3: comparison, where the answers differ and why. Governance-side conclusions belong to AI Governance, Chapter 23; refer to it rather than repeat it. New for the standalone edition (2026-11), from the platform material of the combined manuscript's Chapter 31B.

Chapter 25 – Conclusions: Building and Securing AI Platforms (25_conclusion.md, diagram diagram_25_book_synthesis) Purpose: the book's closing chapter, a consolidated analysis of the platform and security argument rather than a chapter-by-chapter summary. Restate the thesis; draw out the cross-cutting conclusions (revision management and evidence are the backbone of control; AI is both target and source of threat; containment must not depend on intent; routing and placement are risk-tiered choices; operations decide whether a pilot becomes a service); analyse how the conclusions depend on each other and the order in which an organisation should act on them. Close with a short, clearly marked forward look at platform and security trends drawn from AI Governance, Chapter 22 (compound and agentic systems as the default, edge inference, European AI Factories, the shrinking exploitation window, energy as a binding constraint), adding small and specialised models from this book's own sources. New for the standalone edition (2026-11).

Appendices

Glossary (26_glossary.md): 80 to 120 terms with one- to three-sentence definitions, alphabetical, British English, covering AI, architecture, and European regulatory vocabulary (deployer, provider, general-purpose AI model, systemic risk, conformity assessment, notified body, DPIA, FRIA, model card, feature store, vector index, drift, guardrail, agent, tool use, MCP, red teaming, and so on). No diagram or sources required. Keep only the terms this book uses; governance-only terms live in the glossary of AI Governance.

Appendix A: Code Examples and Technical Implementations (27_appendix_a_code_examples.md): complete, runnable versions of the artefacts introduced in the chapters (AI Decision Record template, data contract, model promotion pipeline, agent permission manifest, risk classification policy, evidence manifest, evaluation suite, drift job, cost routing policy, algorithm register entry). Each example has a heading of the form ### NN_CODE_XXX: Title {#nn-code-xxx} where NN is the chapter number and XXX a short identifier, a one-paragraph explanation, and a fenced code block with a language identifier. 3,000 words or more including code.

Appendix B: Templates and Tools (appendix_templates_and_tools.md): a directory of the reusable platform and security templates in the repository with links; written by the editorial team. Governance templates are listed in AI Governance, Appendix C.

References and Sources (28_references.md): the canonical bibliography, numbered 1..N without gaps; maintained by the editorial team.

About the Author (29_about_the_author.md): adapted from the companion volume; written by the editorial team.