The EU AI Act requires organisations deploying high-risk AI systems to maintain auditable change histories with proper attribution and approval controls. Version control governance defines who can change what, under which conditions, and with whose approval, enforced through branch protection, CODEOWNERS files, and structured release management.
Version control governance establishes the rules and enforcement mechanisms that determine who can change AI system artefacts, under which conditions, and with whose approval. Without governance controls, a version control system captures history but provides no assurance that changes were properly reviewed and authorised. This page covers the core governance mechanisms required for EU AI Act compliance: branch protection rules that enforce review requirements at the repository level, CODEOWNERS files that mandate compliance-specific reviewers for fairness-sensitive and security-critical paths, semantic release tagging aligned with substantial modification assessments, and least-privilege access controls with auditable administrative actions. It also addresses the three-repository pattern for achieving compliance-grade traceability across code, data, and model artefacts, signed commits for attribution integrity, and secret management practices. For organisations without access to automated platform features, a procedural alternative using documented review policies and manual enforcement is described.
Version control governance defines who can change what, under which conditions, and with whose approval.
Version control governance defines who can change what, under which conditions, and with whose approval. Without governance, the version control system captures a history of changes but provides no control over whether those changes should have been made. The main branch from which production deployments are made must be protected, with direct commits prohibited by the technical owner. All changes must flow through a pull request or merge request workflow that requires at least one reviewer who was not the author of the change, automated CI pipeline success before merge is permitted, and approval for changes that affect fairness metrics, model architecture, intended purpose, or any -documented parameter.
CODEOWNERS files add a layer of compliance-specific, machine-enforced review to the pull request workflow.
CODEOWNERS files add a layer of compliance-specific, machine-enforced review to the pull request workflow. Paths that affect the model's fairness characteristics, such as feature engineering code, training configuration, post-processing rules, and threshold values, require review from a designated fairness reviewer. Paths that affect security, including authentication, encryption, and access control, require security review. Paths that affect the AISDP documentation require review from the AI Governance Lead or their delegate.
The enforcement is automatic: a pull request that modifies a fairness-sensitive path cannot be merged until the designated fairness reviewer approves it. The Technical Owner configures the corresponding branch protection via the repository API or UI to require status checks to pass, at least one approving review from a CODEOWNERS match, no direct pushes to main, and signed commits. GitHub Branch Protection Rules, GitLab Protected Branches, and Bitbucket Branch Permissions all support this configuration.
The Technical Owner tags candidate releases with semantic version numbers following a major.
The Technical Owner tags candidate releases with semantic version numbers following a major.minor.patch scheme. Major version increments correspond to changes that trigger a substantial modification assessment. Minor version increments correspond to changes that improve the system within its existing compliance envelope. Patch increments correspond to bug fixes and maintenance updates.
Write access to version-controlled repositories follows the principle of least privilege.
Write access to version-controlled repositories follows the principle of least privilege. Data scientists hold write access to model training code and experiment configurations. Data engineers hold write access to data pipeline code. Infrastructure engineers hold write access to infrastructure-as-code definitions.
No single role should have unrestricted write access across all artefact types. Administrative access, meaning the ability to modify branch protection rules, access controls, or repository settings, is restricted by the Technical Owner to designated repository administrators and logged. The version control system's own audit trail, recording who logged in, who changed permissions, and who approved which merge, is retained by the as compliance evidence. This meta-level audit trail is distinct from the version history of the artefacts themselves; it records the governance of the governance system.
Compliance-grade version control means that every artefact in the AI system, including code, data, model, configuration, infrastructure definition, and documentation, has a complete, immutable change history with attribution.
Compliance-grade version control means that every artefact in the AI system, including code, data, model, configuration, infrastructure definition, and documentation, has a complete, immutable change history with attribution. Standard software version control achieves this for code; the compliance challenge is extending the same rigour to artefacts that Git was not designed for.
The three-repository pattern provides the architectural structure. A code repository using Git holds application code, pipeline definitions, configuration files, test suites, and IaC templates. A data repository using DVC, Delta Lake, or LakeFS holds dataset versions, feature store snapshots, and data quality baselines. A model repository using MLflow, W&B, or a cloud-native model registry holds trained model artefacts, evaluation results, and model cards.
Signed commits address attribution integrity by cryptographically binding each commit to a verified identity.
Signed commits address attribution integrity by cryptographically binding each commit to a verified identity. A standard Git commit records an author name and email, but these fields are self-reported and can be spoofed. GPG or SSH commit signing eliminates this weakness.
For compliance purposes, signed commits provide assurance that the change history is authentic: the person who Git records as making a change is the person who actually made it. This matters for accountability under the QMS and for incident investigation. GitHub, GitLab, and Bitbucket all support commit signature verification and can be configured to require signed commits on protected branches.
Secrets such as API keys, database credentials, and encryption keys must never appear in the Git history.
Secrets such as API keys, database credentials, and encryption keys must never appear in the Git history. Tools like git-secrets or truffleHog scan commits for accidentally committed secrets, providing an automated safety net. For configuration files that include encrypted values, Git-crypt or Mozilla SOPS provide file-level encryption within the repository.
In production, the engineering team sources secrets from a dedicated secrets manager such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault, never from the repository itself. This separation ensures that even if the repository is compromised, production credentials remain protected.
Branch protection rules and CODEOWNERS files are platform features requiring GitHub, GitLab, or Bitbucket, but the governance intent can be achieved procedurally through documented review policies and manual enforcement.
Branch protection rules and CODEOWNERS files are platform features requiring GitHub, GitLab, or Bitbucket, but the governance intent can be achieved procedurally through documented review policies and manual enforcement. A documented merge policy states that no code reaches the main branch without at least one approved review from a reviewer listed in the review matrix. That review matrix, equivalent to CODEOWNERS, maps file paths to required reviewers.
A single named repository administrator holds exclusive merge permission to the main branch and verifies that the review matrix requirements are met before merging. The trade-off is the loss of automated enforcement: the process depends on the administrator's discipline, and a lapse in merging without proper review creates a compliance gap with no automatic detection. Organisations using the procedural alternative should implement periodic audits of the merge history to detect any lapses. Signed commits require GPG tooling, which is freely available, and can be adopted regardless of the hosting platform.
Yes. A documented merge policy with a review matrix, a single named administrator with exclusive merge permission, and periodic merge history audits can replicate the governance intent procedurally, though automated enforcement is lost.
Standard Git author fields are self-reported and can be spoofed. GPG or SSH commit signing cryptographically binds commits to verified identities, providing authentic attribution for QMS accountability and incident investigation.
Secrets must never appear in Git history. Use scanning tools like git-secrets or truffleHog for detection, Git-crypt or Mozilla SOPS for encrypted configuration files, and a dedicated secrets manager like HashiCorp Vault for production credentials.
Governance requires branch protection, mandatory reviews, CI pipeline gates, and AI Governance Lead approval for changes affecting fairness, architecture, or AISDP parameters.
CODEOWNERS files map file paths to required reviewers, making compliance review machine-enforced so that fairness-sensitive or security-critical changes cannot merge without designated approval.
A code repository (Git), data repository (DVC/Delta Lake/LakeFS), and model repository (MLflow/W&B) linked through cross-references to provide end-to-end traceability from deployed model to exact code, data, and configuration.
GPG or SSH commit signing cryptographically binds each commit to a verified identity, providing assurance that the recorded change history is authentic for accountability and incident investigation.
A documented merge policy with a review matrix and a single named administrator who verifies review requirements before merging, though this loses automated enforcement and requires periodic audits.
Branch protection rules are enforced at the repository level, not merely by convention. They are documented as part of the qms and remain auditable at all times.
The Technical Owner documents the release tagging scheme in the AISDP, keeping it consistent across all repositories covering code, model, data, configuration, and documentation artefacts. This consistency ensures that any deployed version can be traced back to a single, unambiguous release identifier across the full artefact chain.
Each repository has its own versioning mechanism, but they are linked through cross-references: a model registry entry references the Git commit and the DVC data version that produced it, and a Git commit references the DVC data version it was validated against. This linkage is what makes the version control compliance-grade. Given any deployed model version, the organisation can trace back to the exact code, data, configuration, and pipeline execution that produced it. Given any historical inference, the organisation can identify the model version that processed it and the full provenance chain. This end-to-end traceability is the evidentiary foundation for Annex IV documentation.
CTO of Standard Intelligence. Leads platform engineering and contributes to the PIG series technical content.
Technical Documentation
Technical Documentation Contents
