Infrastructure-as-code ensures the documented deployment environment matches reality. The Software Bill of Materials provides an auditable inventory of every dependency, pre-trained component, and external service. This page covers IaC practices, SBOM generation and scanning, secrets management, GPU resource management, and alternatives for organisations without IaC tooling.
Infrastructure-as-code eliminates environment drift, a common source of audit non-conformities, by defining the deployment environment declaratively. All infrastructure definitions must be version-controlled alongside application code and tagged with composite version identifiers. The Software Bill of Materials is the system's complete ingredient list, required by Annex IV for technical specification documentation. For ML systems, the SBOM extends to ML framework versions, pre-trained model components, and external API dependencies using CycloneDX's ML extension. SBOM generation is automated via Syft, with vulnerability scanning by Grype and cryptographic attestation via cosign. The SBOM enables three compliance capabilities: vulnerability management through continuous scanning, licence compliance through automated conflict detection, and provenance documentation for assessors. Secrets management requires dedicated tools with access logging, rotation policies, and separation between environments. GPU and accelerator configurations are treated as infrastructure changes subject to validation since they can affect numerical precision and model behaviour. Manual infrastructure documentation is a procedural alternative but describes reality rather than defining it, allowing undetected drift.
The Technical Owner defines the deployment environment through infrastructure-as-code using Terraform, CloudFormation, Kubernetes manifests, or Helm charts to ensure that the environment documented in the AISDP corresponds precisely to the actual production environment.
The Technical Owner defines the deployment environment through infrastructure-as-code using Terraform, CloudFormation, Kubernetes manifests, or Helm charts to ensure that the environment documented in the aisdp corresponds precisely to the actual production environment. Environment drift, where the documented infrastructure no longer matches reality, is a common source of non-conformities during audits.
Secrets management uses dedicated tools such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault with access logging, rotation policies, and separation between development and production secrets.
Secrets management uses dedicated tools such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault with access logging, rotation policies, and separation between development and production secrets. No secret should appear in a code repository, a container image, or a log file. Kubernetes ExternalSecret definitions pull credentials from Vault at runtime with one-hour refresh intervals, and Vault access policies restrict each AI system to its own secrets namespace, preventing lateral access to other systems' credentials.
GPU and accelerator resource management requires infrastructure-as-code definitions to specify the accelerator type and count for each workload, ensuring that the training environment documented in the AISDP matches the actual training infrastructure. Inference infrastructure specifies the accelerator configuration that achieves the documented latency and throughput targets. Changes to accelerator configuration, such as upgrading to a newer GPU generation or reducing the GPU count for cost optimisation, are treated as infrastructure changes subject to validation because they can affect numerical precision, inference latency, and in some cases model behaviour.
The SBOM is the AI system's complete ingredient list: every library, framework, pre-trained component, and external dependency with version numbers, licence terms, and known vulnerabilities.
The SBOM is the AI system's complete ingredient list: every library, framework, pre-trained component, and external dependency with version numbers, licence terms, and known vulnerabilities. Annex IV requires documenting the system's technical specifications, and the SBOM is the most machine-readable, auditable form of that documentation.
SBOM generation is automated by the engineering team and integrated into the . Syft from Anchore scans container images and code repositories, producing an SBOM in CycloneDX or SPDX format. CycloneDX is the more ML-friendly format supporting component types beyond software libraries, including machine learning models, datasets, and services. SPDX as an ISO/IEC standard is more established in the broader software compliance ecosystem. The SBOM is generated for every build and stored as a pipeline artefact alongside the container image it describes.
CycloneDX is more ML-friendly, supporting component types beyond software libraries including models and datasets. SPDX is more established in broader compliance. Both are adequate for EU AI Act purposes.
Yes, but manual documentation describes reality rather than defining it, and can drift undetected. Quarterly infrastructure reviews comparing documentation against actual state are required. Terraform is open-source and the only cost is configuration time.
Yes. GPU configuration changes can affect numerical precision, inference latency, and model behaviour. They are treated as infrastructure changes subject to the same validation and review workflow as code changes.
It ensures the documented deployment environment matches reality, preventing environment drift that causes audit non-conformities. Infrastructure changes follow the same review workflow as code changes.
Annex IV requires documenting technical specifications. The SBOM provides the most machine-readable, auditable inventory of all dependencies, pre-trained components, and external services.
Vulnerability management through continuous scanning, licence compliance through automated conflict detection, and provenance documentation for assessors reviewing the system's supply chain.
Using dedicated tools like HashiCorp Vault with access logging, rotation policies, and least-privilege access policies. No secret should appear in code, container images, or logs.
IaC definitions should specify accelerator type and count. Changes to GPU configuration are treated as infrastructure changes subject to validation since they can affect model behaviour.
All infrastructure definitions are stored in the same version control system as the application code, tagged with the same composite version identifiers. Infrastructure changes follow the same review and approval workflow as code changes, with a pull request process and mandatory reviewer approval preventing uncontrolled modifications. Configuration drift detection tools such as AWS Config, Azure Policy, or Open Policy Agent continuously verify that deployed infrastructure matches the declared state. Drift events trigger automated alerts and are logged as potential compliance events.
OPA policies can enforce compliance tags on all AI-related infrastructure resources, verifying that every endpoint carries AISDP version, model version, risk tier, data residency, owner, and last assessment date tags. Data residency enforcement ensures all endpoints are deployed in EU regions for GDPR compliance.
Vulnerability scanning using Grype analyses the SBOM against known vulnerability databases, failing the pipeline if critical or high-severity vulnerabilities are found. The SBOM can be attached to the container image as a cosign attestation, providing cryptographic proof of the image's software composition. The SBOM and vulnerability scan results are retained as Module 9 evidence for the cybersecurity assessment.
CTO of Standard Intelligence. Leads platform engineering and contributes to the PIG series technical content.
