Introduction to AI Platform and Security

This book is about building and securing 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. This chapter explains why such a platform is an architectural and security problem rather than a question of which model to buy, and defines the terms the book relies on.

AI Platform and Security is Book 3 of The Transformed Architecture; it inherits its method from Architecture as Code (72, Nordqvist, 2025) and shares its subject with the sibling volume AI Governance (73, Nordqvist, 2026), which covers regulation, risk, assurance and organisation.

The AI platform landscape: Architecture as Code foundations and four properties of AI systems meet in a secured platform that produces evidence for governance and navigates three tensions

Figure 1.1: The secured AI platform applies the Architecture as Code disciplines to four properties of AI systems that classical practice does not address, produces the evidence that AI governance consumes, and navigates three recurring tensions: speed versus control, autonomy versus accountability, and innovation versus sovereignty.

Why an AI platform is an architectural and security problem

Most organisations begin with a model-selection question: which provider, which model, which licence. It is the smallest part of the problem. A model choice is revisited every few months, whereas the platform around it, with its identity integration, data boundaries, gateways, evaluation suites, logs and stop paths, outlives many such choices. In the estates I have reviewed, incidents and audit findings trace back less to the model than to what it was allowed to see and do.

Outputs that vary: the platform must measure and fence

A large language model (LLM) samples one acceptable answer from many, and produces another when its prompt, sampling settings or version change. The AI Act, Regulation (EU) 2024/1689, builds this into its definition: under Article 3(1) an AI system infers from its input how to generate output (1, European Union, 2024), and ISO/IEC 22989 organises its terminology around the same split between training and inference (25, ISO/IEC, 2022).

For the platform, variability means statistical release gates, versioned test sets and monitoring that catches a gradual fall in quality. For security it is worse. Because an LLM receives instructions and data through the same channel, any text it reads can act as a command; prompt injection, first in the OWASP Top 10 for LLM applications, follows directly (27, OWASP, 2025). A filter cannot list every wording that might steer the model, so the platform places its controls outside the model: on what retrieval may return, on which tools may be called and under whose authority, and on what checks an output must clear before anything acts on it.

Models are built from data: the platform must keep the recipe

Source code is authored; a model is produced from a dataset, training code, hyperparameters and hardware. Sculley et al. showed that data dependencies are costlier than code dependencies because they may be harder to detect (43, Sculley et al., 2015). The platform therefore records the whole recipe, or no release can be reproduced; it watches deployed models, because the world moves while the weights stay fixed; and it defends every ingredient, since a poisoned dataset or a swapped weights file yields a model that looks normal and misbehaves where an attacker intends. Signing, provenance attestations and a machine-learning bill of materials belong to models and datasets as much as to software (31, OWASP, n.d.).

Dependencies the platform cannot open

Most organisations build on foundation models, a term Bommasani et al. introduced for models trained on broad data and adapted to many tasks; they warned of homogenisation, in which many downstream systems inherit the flaws of a few upstream ones (46, Bommasani et al., 2021). A licensee cannot audit the weights and depends on the documentation that Article 53 of the AI Act requires providers of general-purpose AI models to pass on (1, European Union, 2024). What the organisation controls is the assembly around the model; Zaharia et al. noted that leading results increasingly come from such compound AI systems (63, Zaharia et al., 2024). A dependency that cannot be opened can still be wrapped, tested and replaced.

Agents that act

An agent is a system in which a model directs its own sequence of tool calls towards a goal, holding credentials and acting on the organisation's behalf. A prompt injection in a document that an assistant summarises produces a misleading summary; the same injection in a document an agent processes can produce an unauthorised payment. The OWASP Top 10 for Agentic Applications catalogues the resulting risks, from goal hijacking and tool misuse to identity and privilege abuse (102, OWASP, 2025). The answer is containment that the platform enforces regardless of the agent's behaviour: scoped credentials, egress control, budgets, approval gates and stop paths (Chapters 11 and 19).

Attackers have the same tools

Fang et al. (2024) showed that an LLM-based agent exploited 87 per cent of a set of 15 real one-day vulnerabilities when given the public advisory (84, Fang et al., 2024), and in June 2026 the Five Eyes cyber security agencies warned that AI is shrinking the window between vulnerability discovery and exploitation (116, Five Eyes agencies, 2026), and the ENISA Threat Landscape 2026 for Europe reports model improvements already accelerating vulnerability discovery and exploitation (108, ENISA, 2026). Defence must therefore run at machine speed, the subject of Chapter 18.

A working definition of AI Architecture

AI Architecture is the practice of designing, governing and operating AI systems, meaning their data, models, prompts, orchestration and the controls that surround them, as codified, version-controlled, evidence-producing architecture, so that their behaviour, risk, cost and legal position remain under the organisation's control throughout their lifecycle.

This book concentrates on designing and operating, and on the security that runs through both; AI Governance concentrates on governing. The relationship to Architecture as Code is inheritance: that book showed that architecture earns trust when it exists as executable artefacts under version control, delivered by the pipelines that deliver the systems themselves (72, Nordqvist, 2025), and AI Architecture applies those disciplines where they are hardest to apply.

What "the platform" means in this book

By the AI platform I mean the shared, centrally operated set of capabilities on which an organisation's AI systems are built, run and observed, together with the controls that constrain them. Chapter 4 describes it as six layers: the data foundation; the model and feature layer with registry and evaluation service; serving and inference, including the AI gateway through which every model call passes; orchestration and agents; application and channel; and a control plane for identity, policy, observability and evidence. Beneath them sits compute and hosting, and around them runs the DevSecMLOps loop, the delivery pipeline that carries data, models, prompts, skills and policy to production with security checks at every stage. The platform is a product with an owner, not a project, and its purpose is to make the safe path the easy one: a team that onboards through it inherits identity, logging, evaluation and policy enforcement.

Purpose, readers and scope

The book's thesis is that the platform and security problems of AI are engineering problems with architectural answers, and that the Architecture as Code disciplines are their most reliable foundation. Every chapter therefore answers its problem with artefacts a pipeline can check and an auditor can read.

The book is written for platform, security, MLOps and architecture practitioners in organisations with more than a few thousand employees, and treats public authorities as first-class readers. Vendors are named as examples, never endorsed. Regulation, risk classification, assurance and organisation are left to AI Governance; where this book depends on them, it summarises the essentials and names the sibling chapter.

How this book fits The Transformed Architecture

Architecture as Code (Book 1), published at aac.geon.se, supplies the discipline: version control for architecture, continuous delivery, architecture decision records, policy as code, evidence as code, testing strategies and management as code (72, Nordqvist, 2025). This book uses those practices without re-teaching them. AI Governance (Book 2), published at aig.geon.se, applies the same discipline to governing AI, from the regulatory landscape and risk classification as code to assurance, organisation and AI in public authorities (73, Nordqvist, 2026).

Where the two books meet

The two volumes meet at the evidence: governance decides what must be true of an AI system, and the platform enforces those decisions and produces proof of enforcement.

Governance asks (AI Governance) The platform provides (this book)
A risk classification per use case (Chapter 8) A declaration in the repository that pipelines check before deployment (Chapters 5 and 8)
Human oversight that can be shown to work (Chapter 10) Approval gates, stop paths and logs of every intervention (Chapters 11 and 19)
Record-keeping and continuous assurance (Chapter 11) Gateway logs, evaluation results and release evidence with defined retention (Chapters 7, 20 and 21)
Supplier and model-origin decisions (Chapters 6 and 7) Registry entries, ML-BOMs and routing rules that enforce them (Chapters 9, 13 and 14)
Incident duties and reporting (Chapters 3 and 11) Detection, playbooks and scoping queries that identify what happened and where (Chapters 16 and 17)

Table 1.1: How governance requirements become platform capabilities.

The series' method also applies to how the books themselves are made. Most of the prose in this volume was drafted by specialist AI agents working under briefs, rules and automated checks that the author wrote, and every change reached the manuscript only after the author had reviewed and approved it. The judgements are the author's, and so is the responsibility. About the Author describes the arrangement and what it means for the reader.

European law as platform requirements

For a platform built in Europe, regulation fixes design parameters such as what must be logged and where data may sit. Chapter 3 turns the law into engineering requirements, and AI Governance, Chapter 3, gives the full regulatory map.

The AI Act grades obligations by risk: Article 5 bans a few practices, Article 6 with Annex III marks out high-risk AI systems, Article 50 imposes transparency duties, and Chapter V covers general-purpose AI models (1, European Union, 2024). Obligations attach to roles: under Article 25, a deployer that rebrands, substantially modifies or repurposes a high-risk system takes on the provider's obligations, so fine-tuning a licensed model for a high-risk use is a change of legal position that the platform's configuration decides. Articles 9 to 15 read like a platform specification, from risk management and automatic logging to human oversight and cybersecurity. As amended by the Digital Omnibus on AI, the Annex III high-risk obligations apply from 2 December 2027 (23, European Union, 2026).

Other instruments apply at the same time: the GDPR with data protection by design under Article 25 and security of processing under Article 32 (2, European Union, 2016), NIS 2 for essential and important entities (4, European Union, 2022), DORA for financial entities, whose register of ICT third-party arrangements now covers AI providers (3, European Union, 2022), and the Cyber Resilience Act for products with digital elements, including AI components an organisation buys (7, European Union, 2024). Public authorities carry more: a public body deploying a high-risk system must complete a fundamental rights impact assessment under Article 27 and register the use under Article 49 (1, European Union, 2024), and archives law sets retention in decades.

The usage modes as a red thread

Chapter 2 defines six usage modes of large language models, compared in its usage-mode matrix, and every later chapter uses them to say where its answer applies.

In Mode 0 people encounter AI they did not choose; Modes 1 to 5 are active use, from conversational assistants and embedded workplace assistants through agentic work tools and built AI applications to autonomous production agents. In Modes 0 to 2 the organisation mostly configures a supplier's service, so the platform contributes identity, egress control and visibility; in Mode 3 it must contain tools that execute code with real credentials; in Modes 4 and 5 it is the system's foundation. Most of this book therefore concerns Modes 3, 4 and 5.

Two organisations that run through this book

Two invented organisations supply the worked examples, so that the decision records, gateway routes and containment profiles of different chapters belong to the same estate. Their names, figures and documents are fictitious.

Nordvik Region

Nordvik Region is a public authority at regional level in a Nordic EU member state, with about 6,000 staff and about 450,000 residents in its area. It coordinates regional health and social care and administers needs-based financial assistance for its municipalities.

Its most consequential AI system is a procured benefits-triage system that orders applications for financial assistance by urgency; that use sits in Annex III point 5(a), making the Region a deployer of a high-risk system with the duties of Articles 26, 27 and 49 (1, European Union, 2024). A caseworker takes every decision. Personal data is normally processed under the public-task basis of Article 6(1)(e) of the GDPR, and health and social-care work brings in special-category data under Article 9 (2, European Union, 2016).

Its platform is a reduced variant of the reference architecture. The triage system runs in the Region's own data centre, the internal staff assistant on an open-weight model served by a European cloud provider inside the EEA with customer-held keys, and workloads that may touch special-category data, such as a case-note summariser for social-services caseworkers, stay on premises. It runs no autonomous production agents and limits agentic work tools to a small platform team. It has few engineers and slow procurement, and much of what it must protect is operated by suppliers it can steer only through contracts.

Hansa Mutual

Hansa Mutual is a Hamburg-based mutual insurer of about 9,500 people. Group IT runs one shared AI platform from headquarters, with self-hosted and fallback models in the group data centre in Frankfurt, and charges the national entities for using it.

Country Entity and role What changes for the platform
Germany Headquarters; the shared AI platform Sets group policy; works councils co-decide on technical systems designed to monitor behaviour or performance, which the Federal Labour Court reads as any system objectively suitable to do so (207, Germany, 2001), (249, Bundesarbeitsgericht (Federal Labour Court of Germany), 2024)
Netherlands, Sweden Insurers National supervisors, works-council or union consultation, national-language consumer information
Poland Claims and operations service centre Handles claims for the German, Dutch, Swedish and Norwegian entities; cross-border data and agent tool calls pass through it
Norway Insurer in the EEA, outside the EU Bound by EU law only after EEA incorporation; until then AI Act controls run as group policy
United Kingdom, Switzerland Insurers outside the EU UK GDPR, or the revised Federal Act on Data Protection and FINMA expectations, instead of the AI Act; their data crosses a border to reach the platform

Table 1.2: Hansa Mutual's footprint (illustrative).

In the EU entities the AI Act, the GDPR and DORA apply directly while supervisors remain national; the British and Swiss entities are outside both the AI Act and DORA; and Norway takes EU law through the EEA Agreement after a delay (1, European Union, 2024), (3, European Union, 2022). Because Hansa builds its own systems on vendor models it is a provider as well as a deployer, and Annex III point 5(c) makes its underwriting-support model for life and health products high-risk.

Its platform is the complete reference architecture, operated once for seven jurisdictions with a baseline policy set and a per-market overlay. Its agents have real authority: a claims-triage agent changes the core claims system inside approval rules, and an IT-operations agent can write to production. Because one gateway incident may trigger DORA reporting in the EU entities and separate processes in the United Kingdom and Switzerland, the platform records which entity every request belongs to.

What the contrast shows the platform architect

The two differ on exactly the axes that shape a platform. Nordvik has one legal regime, Hansa seven. Nordvik buys most of its AI and controls it through contracts; Hansa builds most of its AI and carries the provider's duties that come with building. Nordvik keeps agentic work tools within its platform team and avoids autonomous production agents; Hansa uses every mode and must contain both. Every chapter takes its worked examples from one of them and closes with a short comparison; Chapter 24 draws conclusions for each.

Worked example: a platform onboarding declaration for a lower-risk system

Illustrative example. Every system on the platform begins with a declaration in the repository stating its purpose, legal position, components, data boundary and evidence, and the onboarding pipeline provisions no gateway route until it is complete. Nordvik Region's staff assistant, used by about 3,200 staff, is not high-risk, but its declaration keeps it from drifting into the triage system's territory.

# systems/staff-assistant/onboarding.yaml - Nordvik Region (illustrative)
apiVersion: ai-architecture.example.org/v1
kind: PlatformOnboarding
metadata:
  system: staff-assistant
  organisation: nordvik-region
  owner: chief-digital-officer
  referenceModel: enterprise-ai-platform@2.0.0
  decisionRecord: AIDR-0211
spec:
  intendedPurpose: >
    Help staff draft letters, summarise internal guidance and find policy
    documents. A member of staff reviews and sends every output.
  prohibitedUses:
    - Assessing, ranking or deciding individual benefit applications
    - Processing special-category data about residents
  usageMode: 4
  aiActRole: {compoundSystem: provider, generalPurposeModel: deployer}
  riskClassification:
    category: limited-risk
    reviewTrigger: any change to intendedPurpose or prohibitedUses
  components:
    gateway: routes/staff-assistant
    model: open-weight-general/eu-cloud
    vectorIndex: {name: guidance-v4, entitlements: carried-from-source}
  dataBoundary:
    allowedSources: [intranet-guidance, policy-library]
    residency: eea-only
    keys: customer-held
    contract: NR-2026-031
  security:
    egress: gateway-only
    agentTools: none
  evidence:
    gatewayLogs: required
    retentionMonths: 120

Three fields do most of the work. The prohibited uses keep the assistant outside Annex III point 5, and the reviewTrigger forces anyone who widens the purpose to reopen the classification. The dataBoundary block records the hosting decision of AIDR-0211 in a form the gateway can enforce. And agentTools: none means that a proposal to let the assistant file letters becomes a reviewed change to this file rather than a silent extension. Chapter 5 develops the decision record, and Chapter 8 the pipeline that checks it.

How to read this book

Part I, Foundations (Chapters 1 to 5), covers the usage modes, regulatory requirements, the reference architecture and decision records. Part II, Data, Models and DevSecMLOps (Chapters 6 to 12), builds the core of the platform, from data and the model lifecycle to agents and integration. Part III, Infrastructure (Chapters 13 to 15), decides where the platform runs. Part IV, Security (Chapters 16 to 19), covers models, prompts, agents and AI-accelerated attackers. Part V, Delivery and Operations (Chapters 20 to 23), covers evaluation, monitoring, cost and scaling, and Part VI (Chapters 24 and 25) draws the conclusions. The appendices hold the glossary, code examples (Appendix A), templates and tools (Appendix B), the bibliography and a note about the author.

Role Start with Then read
Platform engineer or platform owner Chapters 2, 4 and 8 Chapters 7, 11, 12, 13 and 21
Security architect or CISO Chapters 2, 3 and 16 Chapters 9, 15, 17, 18 and 19
MLOps, LLMOps or data engineering lead Chapters 6, 7 and 8 Chapters 5, 9, 10, 20 and 21
Solution, enterprise or AI architect Chapters 2, 4 and 5 Chapters 10 to 14 and 23
Technology leader in a public authority Chapters 2, 3 and 4 Chapters 13, 14, 22, 23 and 24

Table 1.3: Suggested routes through the book by role.

Three tensions, seen from the platform

AI Governance, Chapter 1, names three tensions that run through every AI programme, speed against control, autonomy against accountability and innovation against sovereignty (73, Nordqvist, 2026). This book meets each as a platform question. Speed against control is settled by making the approved route faster than the unofficial one, with controls that run as pipeline gates in seconds, as Architecture as Code proposed (72, Nordqvist, 2025); Chapters 8 and 23 build it. Autonomy against accountability becomes a matter of identities, scoped permissions, approval gates, stop paths and logs that let every agent action be reconstructed; Chapters 11 and 19 treat it, against the Article 14 oversight duty (1, European Union, 2024). Innovation against sovereignty is decided per workload, in routing rules, hosting choices and exit plans, set against European initiatives such as the AI Continent Action Plan (15, European Commission, 2025); Chapters 13 to 15 develop it.

Nordvik Region and Hansa Mutual

For Nordvik Region, speed against control is mostly about shadow AI: an approved staff assistant behind single sign-on works where a ban would move use out of sight. Autonomy against accountability is settled for now by keeping a caseworker behind every triage decision and running no autonomous agents, and sovereignty by keeping special-category workloads on premises.

For Hansa Mutual, by contrast, speed against control means writing a control once in the group baseline and varying it per market in an overlay. Autonomy against accountability is a live security problem, because the claims-triage agent's tool calls run through the Polish service centre and must be bound to each claim's market, and sovereignty is decided market by market in routing rules.

Summary

An AI platform is an architectural and security problem rather than a model-selection problem, because four properties of AI systems break classical assumptions. Outputs vary and input text can act as instruction, so the platform needs statistical release gates, quality monitoring and controls placed around the model. Models are produced from data, so the platform must keep the full recipe and defend every ingredient. Foundation models cannot be opened, so the platform wraps, tests and makes them replaceable. And agents act with credentials, so the platform must enforce containment.

AI Architecture responds with the disciplines of Architecture as Code: intent declared in code, policy enforced by pipelines and evidence produced continuously. Nordvik Region and Hansa Mutual show how one set of principles leads to a reduced, sovereignty-minded platform for an authority that mostly procures, and a full group platform with jurisdiction overlays for an insurer that builds and grants its agents real authority.

Chapter 2 recaps the six usage modes and shows why the mode, not the brand of the model, determines the architecture, the risks and the controls the platform must provide.

Sources

  1. Nordqvist, G. (2025). Architecture as Code. The Transformed Architecture, Book 1, published at aac.geon.se. (72, Nordqvist, 2025)
  2. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2, published at aig.geon.se. (73, Nordqvist, 2026)
  3. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
  4. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 22989:2022 Information technology — Artificial intelligence — Artificial intelligence concepts and terminology. Geneva: ISO, July 2022. (25, ISO/IEC, 2022)
  5. OWASP Foundation. OWASP Top 10 for LLM Applications 2025. OWASP GenAI Security Project. (27, OWASP, 2025)
  6. Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F. & Dennison, D. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28 (NeurIPS 2015). (43, Sculley et al., 2015)
  7. OWASP Foundation. CycloneDX Machine Learning Bill of Materials (ML-BOM).. (31, OWASP, n.d.)
  8. Bommasani, R. et al. (2021). On the Opportunities and Risks of Foundation Models. Stanford Center for Research on Foundation Models. (46, Bommasani et al., 2021)
  9. Zaharia, M., Khattab, O., Chen, L., Davis, J. Q., Miller, H., Potts, C., Zou, J., Carbin, M., Frankle, J., Rao, N. & Ghodsi, A. (2024). The Shift from Models to Compound AI Systems. Berkeley Artificial Intelligence Research blog, 18 February 2024. (63, Zaharia et al., 2024)
  10. OWASP Foundation (2025). OWASP Top 10 for Agentic Applications for 2026. OWASP GenAI Security Project, 9 December 2025. (102, OWASP, 2025)
  11. Fang, R., Bindu, R., Gupta, A. & Kang, D. (2024). LLM Agents can Autonomously Exploit One-day Vulnerabilities. arXiv:2404.08144. (84, Fang et al., 2024)
  12. Five Eyes cyber security agencies: ASD's ACSC, Canadian Centre for Cyber Security, NCSC-NZ, NCSC-UK, NSA and CISA (2026). The AI shift in cyber risk: why leaders must act now. Joint statement, 22 June 2026. (116, Five Eyes agencies, 2026)
  13. European Union Agency for Cybersecurity (2026). ENISA Threat Landscape 2026. September 2026. (108, ENISA, 2026)
  14. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026. (23, European Union, 2026)
  15. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (2, European Union, 2016)
  16. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (4, European Union, 2022)
  17. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
  18. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. (7, European Union, 2024)
  19. European Commission. AI Continent Action Plan. COM(2025) 165 final, 9 April 2025. (15, European Commission, 2025)
  20. Federal Republic of Germany (2001). Betriebsverfassungsgesetz (BetrVG) (Works Constitution Act), as last amended on 19 July 2024. Federal Ministry of Justice, Gesetze im Internet. (207, Germany, 2001)
  21. Bundesarbeitsgericht (2024). Beschluss vom 16. Juli 2024 – 1 ABR 16/23 (Technische Überwachungseinrichtung – Headset-System – betriebliche Mitbestimmung – Gesamtbetriebsrat). ECLI:DE:BAG:2024:160724.B.1ABR16.23.0. (249, Bundesarbeitsgericht (Federal Labour Court of Germany), 2024)