We use cookies to improve your experience and analyse site traffic.
We use cookies to improve your experience and analyse site traffic.
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.
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.
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.
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 CI/CD pipeline. 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.
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.
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.
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.