Platform and Infrastructure Tools
This chapter serves the activity of building and running the AI platform: provisioning infrastructure as code, running containers, training and registering models, serving them, retrieving the data they use and putting a gateway in front of every model call. It treats all four kinds of tool. The artefacts are the registry entries, descriptors, rules, configurations and checks that AI Platform and Security defines (3, Nordqvist, 2026), together with the infrastructure listings of Architecture as Code (1, Nordqvist, 2025). The third-party tools are the infrastructure-as-code engines, the container platform, the MLOps and serving software and the portal framework that those volumes name. The methods are two statements of one organisational idea, the platform team as a product team. The chapter also draws on AI Governance (2, Nordqvist, 2026) for the team topology and the shared-platform agreement, and on AI Operations (10, Nordqvist, 2026) for the way state engines keep declared and actual state together.
A reader meets two kinds of choice here, and the series asks for them to be kept apart: which parts of the platform are an open standard or a replaceable component, and which are a product whose replacement has a price. The series does not recommend products. It records which tool each volume uses in its examples and what that volume says the tool is for. Where a volume names a tool in passing, the chapter says so, and for third-party software the facts come from the tool's own documentation as listed in the bibliography of this book. Some tools the inventory placed here belong more naturally elsewhere, and the findings file for this chapter lists them for the editor.
Figure 6.1: Layers of the AI platform and their tools. Applications reach models only through the gateway; the control plane enforces at the gateway and checks the plans of the infrastructure layer from outside.
Infrastructure as code
Architecture as Code (Chapter 5) places infrastructure as code one layer below architecture as code: the architecture defines the guardrails, and the infrastructure code makes the runtime changes that honour them (1, Nordqvist, 2025). The tools in this family declare resources, compare the declaration with what exists, and apply the difference. They differ in language, in how long they keep state and in whether a comparison runs between invocations.
Terraform
| Kind | Third-party tool (infrastructure-as-code software) |
| Origin | Architecture as Code, Chapters 2 to 5, 7 to 11, 13 to 16, 18, 21, 23 and Appendices A and D; AI Platform and Security, Chapters 8 and 13; AI Operations, Chapters 8, 18, 19 and 32 and Appendix B |
| Purpose | Declarative infrastructure as code, used throughout the examples of the series; terraform test, plan, validate and fmt carry the checks |
| Use when | Infrastructure should be declared in reviewed files, planned before it is applied and compared with reality |
| Inputs | Configuration files, state and provider credentials |
| Outputs | A plan, applied changes and a state that records the binding between remote objects and declared resources |
The product documentation describes Terraform as a declarative tool (139, HashiCorp, n.d.). Three facts from it matter to the platform. State stores the bindings between remote objects and declared resource instances, and Terraform refreshes it against real infrastructure before an operation (140, HashiCorp, n.d.). The plan command has a refresh-only mode that updates state to match changes made outside Terraform (141, HashiCorp, n.d.). And state can hold secrets, so it is treated as sensitive data (142, HashiCorp, n.d.). AI Operations (Chapter 8) draws the consequence for an operator: because Terraform runs only when a person or a pipeline runs it, nothing compares between runs, and state is not the declaration, so adopting a manual change still needs a commit. AI Platform and Security (Chapter 13) uses Terraform to provision inference node pools, and HCP Terraform (the managed service, which Architecture as Code lists for remote state, policy enforcement and collaboration) documents policy enforcement as one of its features (157, HashiCorp, n.d.).
OpenTofu and the other declarative engines
| Tool | Kind and origin | One-line purpose |
|---|---|---|
| OpenTofu | Third-party tool; Architecture as Code, Chapters 4, 14 and 27 (passing); AI Operations, Chapters 8, 18, 19 and 32 and Appendix B | Open-source Terraform-compatible tool with state and plan encryption |
| HCP Terraform / Terraform Cloud | Third-party tool; Architecture as Code, Chapters 4, 9b, 15 and 21 | Managed remote state, policy enforcement and collaboration |
| Pulumi | Third-party tool; Architecture as Code, Chapters 13 and 14 | Infrastructure as code in general-purpose languages, with host-language testing and mocks |
| AWS CDK | Third-party tool; Architecture as Code, Chapters 3, 5, 13 and 14 (passing) | Programmatic infrastructure as code on AWS |
| AWS CloudFormation | Third-party tool; Architecture as Code, Chapters 14 and 16 and Appendix A | AWS-native templates, with legacy resources brought under management through import change sets |
| Bicep | Third-party tool; Architecture as Code, Chapter 3 (passing) | Azure infrastructure-as-code language |
| Crossplane | Third-party tool; Architecture as Code, Chapter 7 (passing); AI Operations, Chapter 8 and Appendix B | Reconciles cloud resources through Kubernetes objects |
| Google Config Connector | Third-party tool; AI Operations, Chapter 8 (passing) | Cloud-provider controller that manages cloud resources as Kubernetes objects |
| pytest | Third-party tool; Architecture as Code, Chapters 5 and 13 (passing) | Python test runner for infrastructure and Pulumi tests |
OpenTofu is the fork created in response to HashiCorp's change of licence, as its documentation states (143, OpenTofu, n.d.), and it documents encryption of state and plan files at rest (144, OpenTofu, n.d.). AI Operations (Chapter 8) distinguishes the engines by how they hold declared and actual state together: Terraform and OpenTofu compare only when run, whereas Crossplane's documentation states that its control plane corrects drift from the desired state (147, Crossplane Authors, n.d.), and Config Connector manages cloud resources as Kubernetes objects (148, Google Cloud, n.d.). The Pulumi documentation describes mocking and testing of Pulumi programs (149, Pulumi, n.d.), the CDK guide describes the AWS toolkit and its pipelines (150, AWS, n.d.), and the CloudFormation guide describes importing existing resources into a stack (151, AWS, n.d.). Bicep and pytest are named in passing; the series makes no claim about them beyond that.
Infrastructure listings in Architecture as Code
| Tool | Kind and origin | One-line purpose |
|---|---|---|
| 14_CODE_1: Terraform service blueprint for a web application landing zone | Artefact; Architecture as Code, Chapter 14 and Appendix A | Reusable Terraform module (modules/web-application) that packages networking, load balancing and tagging |
| 14_CODE_3: Continuous delivery workflow for infrastructure changes | Artefact; Architecture as Code, Chapter 14 and Appendix A | GitHub Actions workflow that plans and applies across development, staging and production, authenticating through OIDC and gated by protection rules |
| 21_CODE_1: Multi-cloud enterprise landing zone | Artefact; Architecture as Code, Chapter 21 and Appendix A | Terraform multi-cloud landing zone with EU data residency and common tagging |
Backend partial configuration (backend.eu-central-1.hcl) |
Artefact; Architecture as Code, Chapter 21 | Partial backend configuration kept out of the template; the backend uses S3-native locking |
| Secure IaC state management and security foundation Terraform module | Artefact; Architecture as Code, Chapter 9b | Remote state hardening and a security foundation module |
Crypto-agility baseline (crypto-agility-baseline.tf) |
Artefact; Architecture as Code, Chapter 12 | Baseline for post-quantum migration that keeps keys and certificates rotatable; it is not itself a post-quantum implementation |
| Serverless infrastructure definition | Artefact; Architecture as Code, Chapter 12 | Serverless YAML template |
Migration assessment automation (infrastructure_discovery.py) |
Artefact; Architecture as Code, Chapter 16 and Appendix D | Python discovery of unmanaged resources, with a generated Terraform import plan and migration playbook |
AI-augmented infrastructure optimiser (ai_optimiser.py) |
Artefact; Architecture as Code, Chapter 12 | Python example of AI-assisted infrastructure optimisation |
These are teaching listings. The volume that publishes them labels their limits, and the chapter repeats three. The backend example is a partial configuration passed to terraform init, which keeps the template free of environment values and relies on a Terraform version that supports S3-native locking. The crypto-agility baseline is explicit that it relies on classical algorithms while keeping rotation possible. And the migration assessment module uses deliberately simple heuristics whose thresholds and tag conventions must be adapted before its output is relied on. None of the listings is a product, and a team that copies one should treat it as a starting point for review.
Testing infrastructure code
| Tool | Kind and origin | One-line purpose |
|---|---|---|
| 13_CODE_B: Terraform configuration generator | Artefact; Architecture as Code, Chapter 13 and Appendix A | TypeScript generator of Terraform configuration with built-in compliance validation, used as a testable unit |
| 13_CODE_C: Terraform configuration generator tests | Artefact; Architecture as Code, Chapter 13 and Appendix A | Vitest tests with GDPR compliance checks and regional restrictions |
| 13_CODE_D: Infrastructure validator | Artefact; Architecture as Code, Chapter 13 and Appendix A | TypeScript validator that checks resources against organisational policy and compliance requirements |
| 13_CODE_E: Infrastructure validator tests | Artefact; Architecture as Code, Chapter 13 and Appendix A | Vitest tests covering mandatory tags, security groups and compliance policies |
| 13_CODE_I: Terratest for GDPR-compliant infrastructure | Artefact; Architecture as Code, Chapter 13 and Appendix A | Go Terratest suite asserting GDPR-relevant properties, data residency and tagging |
13_CODE_K: Kubernetes infrastructure test suite (k8s/tests/infrastructure-validation.yaml) |
Artefact; Architecture as Code, Chapter 13 and Appendix A | Kubernetes manifests that validate resource quotas, Pod Security Admission levels, network policies and encrypted storage classes |
Infrastructure CI workflow (infrastructure-ci) and package.json test scripts |
Artefact; Architecture as Code, Chapter 13 | GitHub Actions workflow and npm scripts for infrastructure tests |
The testing artefacts form a ladder from unit to environment. The generator and its tests treat configuration as the output of code that can be unit-tested; the validator checks a declared resource set against rules (the validator's tests use the mandatory tags Environment, CostCentre and Owner); Terratest and the Kubernetes suite assert properties of what was created. The ladder is the series' answer to a question the platform raises early: how a team knows that the declared infrastructure honours a data-residency rule before a regulator asks. The policy engines that run such checks in a pipeline are in Chapter 5.
Container and service-mesh platforms
The container platform is where the series' declared-state idea becomes continuous. AI Operations (Chapter 8) describes Kubernetes controllers as loops that compare declared and actual state and act on the difference, and the Kubernetes documentation states the controller pattern (146, The Kubernetes Authors, n.d.).
Kubernetes
| Kind | Third-party tool (orchestration platform) |
| Origin | Architecture as Code, Chapters 5, 7, 9, 10, 13, 15, 18 and Appendix A; AI Platform and Security, Chapters 7 and 13; AI Operations, Chapters 2, 4, 8, 9, 10, 16 to 18 and 32 and Appendix B |
| Purpose | Container orchestration on declarative manifests; in AI Operations, controllers, probes, autoscaling and validating admission policy implement self-healing and declared state |
| Use when | Workloads should be described declaratively and reconciled continuously, and inference and pipelines need a common substrate |
| Inputs | Declarative manifests |
| Outputs | Running workloads, and the events and status that observers read |
The concept documentation is the primary source for the platform (145, Kubernetes, n.d.). AI Platform and Security names Kubernetes as the orchestration for inference and pipelines, and AI Operations adds what the platform contributes to control: validating admission policy lets the cluster refuse a manifest that breaks a rule before it runs (158, The Kubernetes Authors, n.d.). The cost is that a controller or reconciler is an actor with an identity, a point AI Operations develops for the operator's own agents and that Chapter 20 takes further.
Docker, Helm and service meshes
| Tool | Kind and origin | One-line purpose |
|---|---|---|
| Docker and Docker Compose | Third-party tool; Architecture as Code, Chapters 6, 7 and 31 | Container runtime and local multi-container composition; Docker's documentation describes an open platform for developing, shipping and running applications (268, Docker Inc, n.d.) |
| Helm | Third-party tool; Architecture as Code, Chapters 7 and 8 | Package manager for Kubernetes charts, which encapsulate organisational standards; a chart is a collection of files describing a related set of Kubernetes resources (269, Helm Authors, n.d.) |
| Linkerd, Cilium | Third-party tools; Architecture as Code, Chapters 7 and 8 (passing) | Alternative service mesh and networking layers; Cilium's documentation lists network policy and service mesh among its functions (271, Cilium Authors, n.d.) |
Architecture as Code (Chapter 7) presents Helm as templating and release management for Kubernetes, with chart repositories that carry organisational defaults, and Docker Compose as a local development environment. The volume names Istio, Linkerd and Cilium as service-mesh options (the Istio documentation describes an open source service mesh that layers transparently onto existing distributed applications (270, Istio Authors, n.d.)) whose policies are generated from declarations. The product documentation cited here supports only the one-line descriptions of the tools; for how the series uses them the chapter claims only what the originating volume says: that the series uses them to encode shared defaults for security, observability and networking so that platform teams define them once.
MLOps and model serving
The MLOps layer is where models become governed artefacts. AI Platform and Security (Chapter 7) compares the model registry to a container registry: an immutable, signed artefact store with metadata, whose history is retained for as long as the decisions made with a model can be challenged.
Model registry entry
| Kind | Artefact |
| Origin | AI Platform and Security, Chapter 7 |
| Purpose | An immutable record that links a model version to its run, data, model card, evaluation and approvals |
| Use when | You must be able to answer which model version made a decision, and promotion should happen through gates |
| Inputs | The tracking run, the training manifest, the data product versions, the model card, the evaluation report and approvals by people who did not build the model |
| Outputs | A registry record that pipelines write, except for the approvals |
| Identifier family | registry://<model>/<version> |
| Full template | Below, from AI Platform and Security, Chapter 7 (Nordvik Region, illustrative) |
# registry://claims-ranker/4.0.0 - Nordvik Region (illustrative)
model: claims-ranker
version: 4.0.0
artefact:
uri: s3://nordvik-models/claims-ranker/4.0.0/model.ubj
signature: sigstore://nordvik/claims-ranker/4.0.0
provenance:
training_run: mlflow://nordvik/runs/8c41f0
training_manifest: models/claims-ranker/training_run.yaml@a91c3e2
data: [{product: claims-register, version: 2026-12}]
documentation:
decision_record: AIDR-0018
model_card: models/claims-ranker/4.0.0/model_card.md
ai_act:
roles: [deployer]
provider: TriageSoft (fictional)
classification: high-risk
change_envelope: models/claims-ranker/change_envelope.yaml
evaluation:
precision_at_100: 0.82
demographic_parity_difference: 0.02
ml_test_score: 4.5
stages:
- {stage: shadow, at: 2027-01-29T16:02Z, approved_by: model-risk/a.lind}
- {stage: champion, at: 2027-02-10T07:30Z, approved_by: head-of-case-management}
previous_champions_warm: [3.2.0, 3.1.1]
retention:
keep_until: last case handled with this version plus 10 years
The approved_by fields name people who did not build the model, and the volume ties the retention line to administrative law, not to storage cost: while a case handled with a version can be appealed, the authority must be able to show what that version was. The template shows a registry in the hands of a deployer who has the provider train inside its platform, so that evidence and approvals stay with the authority.
MLflow, data versioning and the model hub
| Tool | Kind and origin | One-line purpose |
|---|---|---|
| MLflow | Third-party tool; AI Platform and Security, Chapters 7 to 9 | Experiment tracking, model and prompt registry with mutable aliases |
| DVC | Third-party tool; AI Platform and Security, Chapter 8 (passing) | Data version control in the repository; remains open source |
| lakeFS | Third-party tool; AI Platform and Security, Chapter 8 (passing) | Git-like branches over a data lake |
| Hugging Face | Third-party tool; AI Platform and Security, Chapters 9, 14 and 19 (passing) | Model hub |
| HELM | Third-party tool; AI Platform and Security, Chapter 20 | Holistic Evaluation of Language Models |
| Open Source AI Definition | Third-party standard; AI Governance, Chapters 6 and 7 | Definition used to judge open-weight models |
MLflow can tie a training run to the Git commit it was run from (when it is run from a Git repository) and to the datasets logged with it, and the registry entry above points to an MLflow run in its training_run field (153, MLflow, n.d.). Its prompt registry makes each prompt version immutable while aliases such as production stay mutable (154, MLflow, 2026). AI Platform and Security (Chapter 8) draws the consequence: an alias is a pointer, not a version, so a release manifest records the version an alias resolved to, never the alias. DVC keeps pointer files in the repository and lakeFS provides branches over a data lake; lakeFS acquired DVC in November 2025, and DVC remains open source (155, lakeFS, 2025). What matters, the volume says, is that the identifier in a training manifest resolves to the same bytes years later. HELM evaluates models across many scenarios and metrics instead of reporting a single accuracy figure (44, Liang et al., 2022). The Open Source AI Definition is the standard the series uses to judge open-weight models, and as AI Platform and Security (Chapter 13) notes, a release of weights alone settles neither the licence nor the data question (45, OSI, 2024). The model hub is named in passing in the context of supply-chain risk: a model loaded from outside the organisation is code that runs, which is why the readiness check below requires weights from the internal registry only.
Model serving and the self-hosting readiness check
| Tool | Kind and origin | One-line purpose |
|---|---|---|
| vLLM | Third-party tool; AI Platform and Security, Chapters 9, 14 and 15 | Self-hosted inference server with an OpenAI-compatible API (156, vLLM, 2026) |
| llama.cpp | Third-party tool; AI Platform and Security, Chapter 15 (passing) | Local inference engine |
| LM Studio | Third-party tool; AI Platform and Security, Chapter 15 (passing) | Local model server supported by agentic work tools |
Self-hosting readiness check (self-hosting-readiness.yaml) |
Artefact; AI Platform and Security, Chapter 14 | Checklist all of whose items must pass before a model is self-hosted in production |
Self-hosting inverts the cost structure of using a provider, and AI Platform and Security (Chapter 14) records that serving software has had critical vulnerabilities and that tools built for a laptop are deployed to servers with their defaults intact; the readiness check is its response. The volume's list has seven items: licence, exposure, patching, provenance, safety filtering and upgrades, operations and capacity, and the regulatory record. The YAML form is a gate in a pipeline, and the entry below quotes it in full.
# self-hosting-readiness.yaml - all items must pass before production
gate: self-hosting-readiness
platform: onprem-se-1
checks:
licence_reviewed: {owner: legal, evidence: model-card#licence}
no_unauthenticated_endpoint: {owner: security, test: external-scan, expect: zero-open}
patch_sla_days: {critical: 7, known_exploited: 1}
weights_from_registry_only: {signed: true, format: safetensors, trust_remote_code: false}
safety_filters_evaluated: {owner: evaluation, suite: safety-baseline}
monitoring_connected: {owner: platform, on_call: required}
capacity_confirmed: {power_kw_per_rack: required, cloud_fallback: required}
Each key has an owner or a test, and a gate that a pipeline can evaluate; the series' wording is that all items must pass. The volume's prose gives the same default patch times: seven days for critical vulnerabilities, 24 hours where exploitation is known. llama.cpp and LM Studio belong to a different mode of use: AI Platform and Security (Chapter 15) lists them as local servers that agentic coding tools can call, and the answer there is the gateway, not a ban.
Retrieval and data tools
The retrieval layer turns data into answers, and the series treats its configuration as code: versioned, reviewed, tested and promoted. The tools are artefacts; no third-party retrieval product is named as a principal tool.
RAG system configuration
| Kind | Artefact |
| Origin | AI Platform and Security, Chapter 10 |
| Purpose | Codifies ingestion, chunking, embedding, index and retrieval settings for a retrieval-augmented generation system |
| Use when | The orchestration layer should read one versioned file for how a compound system retrieves, generates and checks grounding |
| Inputs | Sources with entitlement attributes, an embedding model, a reranker, a generation model, a prompt template and an evaluation set |
| Outputs | A promoted configuration that the orchestration layer reads |
| Identifier family | rag_system with a version; linked to an AI Decision Record |
| Full template | Below, from AI Platform and Security, Chapter 10 (Nordvik Region, citizen-service assistant) |
rag_system:
name: citizen-service-assistant
version: 2026.03.1
decision_record: AIDR-0014
ingestion:
sources:
- {name: regional-regulations, entitlement_attribute: public}
- {name: case-handling-guidance, entitlement_attribute: caseworker}
chunking: {strategy: structure-aware, max_tokens: 400, overlap_tokens: 40}
embedding: {model: multilingual-embed-v3, hosting: on-premises}
freshness_check_minutes: 60
retrieval:
mode: hybrid
entitlement_filter: before-search
reranker: {model: reranker-small-v2, keep: 6}
generation:
model: eu-hosted-gpai-large
prompt_template: prompts/citizen-service/v7.md
max_context_tokens: 6000
temperature: 0.1
grounding:
checker: entailment-small-v1
unsupported_claim_action: remove-and-flag
transparency:
disclose_ai_interaction: true
evaluation_set: eval/citizen-service/v4.json
thresholds:
faithfulness_min: 0.95
unsupported_claim_rate_max: 0.02
Two design points recur in the volume. The entitlement filter runs before search, so that a user's permissions limit what can be retrieved, and the embedding model is a model like any other, with a version and a lifecycle: changing it means re-embedding the corpus, because vectors from different models are not comparable. The configuration refers to two further artefacts. The retrieval prompt template (prompts/citizen-service/v7.md) carries six rules and an exact abstention text between markers: answers use only the passages, cite each fact by passage identifier, reply with the fixed text when the passages do not contain the answer, never disclose information about another identifiable person, treat passages as reference material and not instructions, and answer in the requested language under 150 words. Because the abstention text is fixed, an evaluation run can count refusals exactly. The evaluation set is a JSON file whose items carry a query, expected sources, a reference answer, a rubric and a language.
Data product descriptor and retention rule
| Tool | Kind and origin | One-line purpose |
|---|---|---|
Data product descriptor (data_product) |
Artefact; AI Platform and Security, Chapter 6 | Describes a data product's owner, schema, quality, lineage and access |
Retention and erasure rule (policies/retention/RET-*.yaml) |
Artefact; AI Platform and Security, Chapter 6 | Declares retention and erasure of personal data across stores and derived artefacts |
| Retrieval prompt template with grounding and abstention | Artefact; AI Platform and Security, Chapter 10 | Prompt template enforcing citations and abstention |
The descriptor is the file the platform reads before it trains. Its fields are the name, domain, owner and version, the outputs and their contract, a classification block (personal data, special categories, pseudonymised), a lawful-basis block that separates operational use from model training because the GDPR does, retention in days, a link to the datasheet and the lineage sources. The retention rule (RET-04 in the volume's example) declares an owner, the data products it applies to, a retention period for each store (training releases, feature-store rows, vector-index chunks, prompt and response logs, semantic cache entries) and the actions to take on erasure or restriction, propagated through lineage: exclude from the next training release, delete and re-index within 72 hours, purge the cache immediately and record the affected model versions for retraining. The datasheet that the descriptor links to is treated in Chapter 4.
Gateways
The gateway is the one component the series asks every platform to keep. AI Platform and Security (Chapter 4) says that a team adapting the reference model may deviate from it by a recorded decision but may not remove the gateway, the registry, the evaluation service or the control plane.
Gateway security configuration
| Kind | Artefact |
| Origin | AI Platform and Security, Chapter 17 |
| Purpose | A gateway policy with a model allow-list, signed models and guardrails |
| Use when | The gateway should be a configuration in the repository, with layers that each assume the previous one failed |
| Inputs | The system, the allowed model versions, the client's workload identity, the schemas and the logging rules |
| Outputs | A gateway that authenticates, authorises, routes, applies guardrails and logs |
| Identifier family | gateway with a system reference |
| Full template | Below, from AI Platform and Security, Chapter 17 |
gateway:
system: ai-system/dispute-assistant
model_access:
allowed_models: [eu-hosted-gpai-large@2026.09, classifier-small@1.4]
require_signed_model: true
client_identity: spiffe://bank.example/ai/dispute-assistant
layers:
- name: input
injection_classifier: {model: injection-detector@3.2, action_on_detect: block}
secret_patterns: {action: reject}
- name: retrieval
entitlement_filter: before_search
untrusted_source_handling: {strip_instructions: true, label_in_prompt: true}
- name: output
schema: schemas/dispute-response-v3.json
leakage_checks: [canary_tokens, personal_data_of_other_customers, url_exfiltration]
action_on_leak: block_and_alert
- name: logging
store_prompt_text: hashed
store_retrieved_chunk_ids: true
store_tool_calls: full_arguments
redaction_before_write: true
The configuration is a defensive control and contains no attack content: it names a detector, a schema and leakage checks. The volume gives the reasoning for its parts. Model access binds the gateway to signed model versions and a workload identity. The input layer pairs a classifier for novel phrasing with deterministic patterns, and neither is trusted alone. Logging that does not leak is the hardest part, because the record-keeping obligation of AI Act Article 12 and the GDPR's data minimisation principle pull in opposite directions; the resolution is to log identifiers and hashes that allow reconstruction from governed stores, as the store_prompt_text: hashed line shows.
Other gateway tools
| Tool | Kind and origin | One-line purpose |
|---|---|---|
| AI gateway and model registry | Third-party tool (generic components); AI Governance, Chapters 6 and 9 | Platform components that enforce approval and logging; generic, no product named |
| LiteLLM | Third-party tool; AI Platform and Security, Chapter 15 (passing) | Library and proxy used by agents to reach models |
Platform onboarding declaration (systems/*/onboarding.yaml) |
Artefact; AI Platform and Security, Chapter 1 | Declares a lower-risk system's mode, data and controls so the platform can onboard it |
AI Governance describes the gateway and registry generically: they are the places where approval and logging are enforced, and no product is named. AI Platform and Security (Chapter 15) lists LiteLLM among the libraries through which agentic tools reach models and, for hybrid work, requires that all model traffic passes the gateway, which accepts a request only when the workspace identity may use the classification of the work; a client setting is a convenience, not a control. The onboarding declaration (kind: PlatformOnboarding) is the intake form for a system: it names the owner, the pinned reference model, the decision record, the intended purpose, the prohibited uses, the usage mode, the AI Act roles of the compound system and the general-purpose model, the risk classification and its review trigger, the components (gateway route, model, vector index) and the data boundary (allowed sources, residency, key holder and contract).
Platform engineering and team design
A platform is also a team that serves other teams, and the series codifies that relationship.
Backstage and the self-service portal
| Tool | Kind and origin | One-line purpose |
|---|---|---|
| Backstage | Third-party tool; Architecture as Code, Chapter 21 | Developer portal framework |
Self-service developer portal (infrastructure_provisioning.py) |
Artefact; Architecture as Code, Chapter 21 | Flask example for self-service provisioning; the TerraformRunner interface is illustrative |
Backstage was created at Spotify, open-sourced in March 2020 and accepted as a CNCF incubating project in March 2022 (152, Cloud Native Computing Foundation, 2022), and the series uses it as an example of a framework for building developer portals. The Flask example is explicit that its provisioning interface is illustrative, since there is no official HashiCorp Python SDK, and it points to a subprocess call, a wrapper or the HCP Terraform API as the real routes.
Team Topologies and platform team artefacts
| Tool | Kind and origin | One-line purpose |
|---|---|---|
| Team Topologies team design | Method; Architecture as Code, Chapters 17 and 18 | Platform and stream-aligned team patterns |
| Team Topologies | Method; AI Governance, Chapters 12 and 14 | Stream-aligned, platform and enabling team types applied to AI |
| Team Topologies | Third-party tool; AI Operations, Chapters 2 and 21 | Team types and interaction modes, including the platform team as X-as-a-Service |
AI team topology (organisation/ai-team-topology.yaml) |
Artefact; AI Governance, Chapter 12 | Topology of platform, enabling and stream-aligned teams as data |
Shared-platform service agreement (agreements/ai-platform/*.yaml) |
Artefact; AI Governance, Chapter 12 | Agreement between platform owner and municipality for a shared AI platform |
| 17_CODE_1: Infrastructure platform team blueprint | Artefact; Architecture as Code, Chapter 17 and Appendices A and C | YAML blueprint of a platform team structure (devops_team_structure.yaml) |
Platform and product team charter (team-structure.yaml) |
Artefact; Architecture as Code, Chapter 18 | YAML team charter |
Team Topologies names four team types and three interaction modes (collaboration, X-as-a-Service and facilitating) (180, Skelton & Pais, 2019), and the series applies them to the AI platform. The AI team topology in AI Governance (Chapter 12) lists an AI platform team of type platform with the interaction mode x-as-a-service, an enabling team limited to engagements of twelve weeks, a stream-aligned team that owns named use cases, control functions with the gates they hold, a RACI for four decisions and sourcing rules, among them the roles that must stay in-house and a maximum supplier share per team. The service agreement in the same chapter is the contractual form for a shared platform: it fixes tenancy and log retention, states that the customer municipality is deployer of each system and the platform provider is neither provider nor deployer of customer use cases, and commits the provider to notify the customer of model changes behind the gateway 60 days in advance. The two Book 1 artefacts, the platform team blueprint and the team charter, are the earlier forms of the same idea.
Platform plans and requirements
| Tool | Kind and origin | One-line purpose |
|---|---|---|
Platform requirements catalogue (PlatformRequirementsCatalogue) |
Artefact; AI Platform and Security, Chapter 3 | Entries that name an article or control, an applicability condition, the control, its evidence and a release gate, which the pipeline reads |
Platform roadmap (PlatformRoadmap) |
Artefact; AI Platform and Security, Chapter 24 | A roadmap as code for each organisation |
First-90-days platform and security plan (PlatformSecurityPlan) |
Artefact; AI Platform and Security, Chapter 25 | Consolidated plan with workstreams, due days and success measures |
These three are the platform's planning artefacts. The requirements catalogue is an excerpt in the volume, which says the full catalogue runs to some sixty entries. In the excerpt, an entry such as the logging requirement for high-risk providers carries source, appliesWhen, control, evidence and gate fields, and the gate (pre-deploy or registry-promotion) says when the pipeline enforces it. The roadmap and the 90-day plan are organised by action, horizon and the decision records they close, and the plan's success measures are 100 per cent of model calls through the gateway and no shared credentials in AI workloads. They are listed here because the inventory assigns them here.
Inventory entries that belong elsewhere
Two entries in this chapter's slice do not belong to it. The Structurizr workspace for an e-commerce platform (06_CODE_5) is an architecture-modelling artefact and is treated in Chapter 4. The Platform Work Directive test of internal allocation systems (AI Boss, Chapter 5) assesses whether an internal offer or allocation system behaves like a platform dispatcher under Chapter III of Directive (EU) 2024/2831; the word "platform" matched, but it is a method for people-management systems and belongs to Chapter 22. Both are recorded in the findings file.
Across the usage modes
The platform tools differ across the usage modes by how many of the platform's layers the organisation operates, which is also the number of tools in this chapter it must run. The table follows AI Platform and Security (Chapters 4 and 15).
| Mode | Platform layers the organisation operates | Tools from this chapter that apply |
|---|---|---|
| Mode 0 Ambient AI | None; the feature lives in supplier software | None directly; an inventory entry and contract terms |
| Mode 1 Conversational assistants | None beyond the channel | The gateway where the service is used through an API |
| Mode 2 Embedded workplace assistants | None of its own | Tenant identity and the suite's audit logs; the model registry still lists the assistant |
| Mode 3 Agentic work tools | Orchestration, as an agent runtime on a workstation or sandbox | The gateway where the tool accepts a custom endpoint (LiteLLM, vLLM or a local server behind it); direct egress blocked |
| Mode 4 Built AI applications | All five layers, partly through external model connectors | Every tool in this chapter: infrastructure as code, Kubernetes, MLflow and registry entries, RAG configuration, the gateway configuration |
| Mode 5 Autonomous production agents | All five, with the agent runtime and tool registry at the centre | The same, with a policy decision on every tool call and the readiness check for self-hosted models |
The gateway is the hardest gap in Modes 1 to 3, so where a tool lets traffic be routed through it, route it. The registry covers every mode, and the platform's inventory should list Mode 2 and Mode 3 agents beside the Mode 5 agents it runs.
Nordvik Region and Hansa Mutual
Nordvik Region mostly procures, and its platform is the reduced variant: the gateway, the registry, evaluation and the control plane stay, and training machinery belongs to its providers. Its deployment is mixed: the benefits-triage system runs in the regional data centre, the citizen-service assistant on capacity that a European hosting provider reserves for it, and the staff assistant through a European cloud provider with customer-held keys under contract NR-2026-031. The registry entry above is its claims ranker (AIDR-0018), and its RAG configuration is the citizen-service assistant (AIDR-0014). Its platform team is in the position of the provider in the shared-platform agreement of AI Governance, which commits Nordvik Region's digital services to supply an AI gateway, an evaluation service, a guardrail library and observability to a municipality (illustrative).
Hansa Mutual runs the full reference architecture as a shared group platform. Its deployment is hybrid, with self-hosted and fallback models in Frankfurt and hosted models behind the same gateway, so it needs the self-hosting readiness check for the former and the gateway routing for both. AI Platform and Security (Chapter 15) shows its coding-agent configuration reaching a self-hosted vLLM through the gateway with a short-lived workload token, and its first-90-days plan includes a drill that switches to the Frankfurt fallback within 48 hours (EXIT-004). Its team topology puts an AI platform team in the platform role with the interaction mode x-as-a-service and a claims operations team in the stream-aligned role.
Summary
The tools of this chapter share one principle: the platform is declared in files that a pipeline can check, and the declaration is kept apart from the system it governs. Three conclusions follow from the volumes above. First, state needs its own care: declared and actual state diverge between runs for the engines that compare only when run, and state can hold secrets, so the platform treats it as sensitive and decides deliberately between engines that compare when run and engines that reconcile continuously. Second, the gateway is the single component that is not optional, because it is the only place where logging, redaction, routing and budgets apply to every AI call; in Modes 1 to 3 the effort goes into making traffic reach it. Third, every promotion has an owner who did not build what is promoted, and every record that a platform produces (a registry entry, a retention rule, a readiness check) carries an owner or a test.
All 69 inventory entries assigned to this chapter are accounted for. The principal tools have full entries, four of them with a quoted template (the model registry entry, the self-hosting readiness check, the RAG system configuration and the gateway security configuration); the platform requirements catalogue, the data product descriptor, the retention rule and the onboarding declaration are described field by field. The rest are named in the family tables with origin and a one-line purpose, and the two entries that belong to other chapters are noted above. Appendix A holds all 69.
Sources
- Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
- Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (2, Nordqvist, 2026)
- Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (3, Nordqvist, 2026)
- Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)
- Liang, P. Holistic Evaluation of Language Models. (44, Liang et al., 2022)
- Open Source Initiative. The Open Source AI Definition, version 1.0. (45, OSI, 2024)
- HashiCorp. What is Terraform?. (139, HashiCorp, n.d.)
- HashiCorp. State. (140, HashiCorp, n.d.)
- HashiCorp. terraform plan command reference. (141, HashiCorp, n.d.)
- HashiCorp. Manage sensitive data in your configuration. (142, HashiCorp, n.d.)
- OpenTofu. Frequently asked questions. (143, OpenTofu, n.d.)
- OpenTofu. State and Plan Encryption. (144, OpenTofu, n.d.)
- Kubernetes. Kubernetes Documentation: Concepts. (145, Kubernetes, n.d.)
- The Kubernetes Authors. Controllers. (146, The Kubernetes Authors, n.d.)
- Crossplane Authors. What's Crossplane?. (147, Crossplane Authors, n.d.)
- Google Cloud. Config Connector overview. (148, Google Cloud, n.d.)
- Pulumi. Testing. (149, Pulumi, n.d.)
- AWS. AWS Cloud Development Kit (CDK) v2 Developer Guide. (150, AWS, n.d.)
- Amazon Web Services. Import AWS resources into a CloudFormation stack. (151, AWS, n.d.)
- Cloud Native Computing Foundation. Backstage project joins the CNCF Incubator. (152, Cloud Native Computing Foundation, 2022)
- MLflow Project. MLflow Documentation. (153, MLflow, n.d.)
- MLflow Project. Prompt Registry. (154, MLflow, 2026)
- lakeFS. lakeFS Acquires DVC, Uniting Data Version Control Pioneers to Accelerate AI-Ready Data. (155, lakeFS, 2025)
- vLLM project. OpenAI-Compatible Server. (156, vLLM, 2026)
- HashiCorp. Policy enforcement. (157, HashiCorp, n.d.)
- The Kubernetes Authors. Validating Admission Policy. (158, The Kubernetes Authors, n.d.)
- Skelton, M. Team Topologies: Organizing Business and Technology Teams for Fast Flow. (180, Skelton & Pais, 2019)
- Docker Inc. Docker overview. (268, Docker Inc, n.d.)
- Helm Authors. Helm: the package manager for Kubernetes. (269, Helm Authors, n.d.)
- Istio Authors. What is Istio?. (270, Istio Authors, n.d.)
- Cilium Authors. Introduction to Cilium & Hubble. (271, Cilium Authors, n.d.)