GitHub Best Practices for EU AI Act Compliance Evidence

Article 9 of EU AI Act Regulation 2024/1689 requires a continuous risk management system active throughout the entire lifecycle of your AI system. For engineering teams, "lifecycle" means every code change, every model update, every deployment. The only practical way to satisfy that is to generate compliance evidence automatically from the tools engineers already use -- starting with GitHub.

This guide covers how to structure your GitHub workflow so that pull requests, branches, commits, and code reviews generate artefacts that constitute EU AI Act compliance evidence. No manual reporting. No separate compliance workflow.

Why PR Names and Descriptions Matter for Compliance

When a compliance system reads your repository to collect evidence, it looks for structured, parseable information. A PR titled "fix stuff" tells an auditor nothing. A PR titled with the right structure tells an automated system -- and a human auditor -- exactly which regulatory obligation was addressed, by whom, and what changed.

More importantly, well-named PRs create a human-readable change log that can be assembled into the Annex IV Section 5 "Changes to the System" documentation required under Article 11.

Recommended PR Title Convention

Use a structured format that captures the type of change, the regulatory reference if applicable, and a clear description:

# Format: type(scope): description [art:N]
feat(risk-mgmt): add drift detection threshold for model v2.1 [art:9]
fix(logging): ensure inference timestamps written to S3 for all endpoints [art:12]
docs(annex-iv): update training data section after dataset refresh [annex:iv]
chore(monitoring): configure Datadog alert for accuracy degradation >5% [art:72]
refactor(oversight): expose override flag in admin UI for human reviewers [art:14]
test(conformity): add adversarial test suite for demographic parity [art:15]

The key elements:

Type: feat / fix / docs / chore / refactor / test -- standard conventional commits
Scope: Use the compliance area as scope (risk-mgmt, logging, monitoring, oversight, conformity) rather than only the technical module
Article tag: Append [art:N] or [annex:N] at the end for PRs directly addressing a regulatory obligation. Not required for every PR -- only those with compliance relevance

PR Description Template

The PR description is where you capture the compliance context. Use a standard template in your repo's .github/PULL_REQUEST_TEMPLATE.md:

## Summary
<What this PR does and why>

## Compliance relevance
- [ ] This PR addresses an EU AI Act obligation
- Relevant article(s): Art. __ / Annex __
- Obligation: <brief description of the requirement addressed>
- Evidence generated: <what artefact this PR produces that satisfies the requirement>

## Testing
- [ ] Unit tests updated/added
- [ ] Risk assessment updated if model behaviour changed
- [ ] Annex IV documentation updated if system architecture changed

## Reviewer checklist
- [ ] Change does not introduce new data sources without data governance review
- [ ] Logging coverage is not reduced by this change
- [ ] Human oversight mechanisms remain functional

Branch Naming for Traceability

Branches named after Jira tickets or generic features are harder to trace back to compliance evidence. Add a compliance prefix for branches that address regulatory requirements:

# Standard feature branch
feature/add-drift-detection

# Compliance-scoped branch (preferred for audit traceability)
compliance/art9-drift-detection-v2
compliance/art12-inference-logging-s3
compliance/annex-iv-update-dataset-v3

Code Review as Compliance Evidence

Article 14 requires human oversight mechanisms to be designed into high-risk AI systems. Code review is one of the most defensible pieces of evidence that a human was involved in validating changes to the system before deployment. To make this evidence-ready:

Require at least one approved review for any PR touching model inference, training data, logging, or risk management logic
Use GitHub's required reviewers for specific directories (CODEOWNERS) to enforce that a designated reviewer with compliance responsibility approves model-related changes
Do not allow force-merges that bypass reviews for compliance-relevant code paths
The review approval record (reviewer name, timestamp, approved commit SHA) is a verifiable Article 14 evidence artefact

Tagging Releases for Annex IV Section 5

Every release of your AI system that changes model behaviour, data sources, or compliance-relevant functionality should be tagged in GitHub. The tag message should reference what changed and its compliance significance:

git tag -a v2.3.0 -m "Model retrain on dataset v4.1.
Art.9: risk assessment updated for new input distribution.
Annex IV: Section 2 (training data), Section 5 (changes) updated.
Art.12: logging schema unchanged -- existing coverage maintained."

GitHub Actions for Compliance Checks

The most powerful compliance evidence comes from automated checks that run at every PR and every merge. Consider adding workflow steps that verify:

That Annex IV documentation has been updated when model-related files change (fail the check if docs/annex-iv.md has not been touched in a PR that modifies model/)
That logging coverage is not reduced (run a test that verifies all inference endpoints write to the compliance log)
That risk management documentation is current (timestamp check against the last model change)

These automated checks generate timestamped, signed run records in GitHub Actions -- which are strong Article 9 evidence artefacts.

What This Produces for an Audit

A repository structured this way generates, for every release:

A traceable list of all changes with compliance relevance labelled (Article 9, Article 12, Article 14, Annex IV)
Human review records for compliance-sensitive changes (Article 14 evidence)
Automated check results showing logging and documentation coverage (Article 12 evidence)
A release tag with compliance change summary (Annex IV Section 5 evidence)
All timestamps cryptographically fixed by GitHub's commit graph

This is exactly the evidence an Article 43 conformity assessment requires, generated automatically as a byproduct of good engineering practice.

Frequently Asked Questions

Does GitHub commit history count as EU AI Act compliance evidence?

Yes -- with the right structure. GitHub commits are cryptographically signed by the repository and carry timestamps verified by GitHub's infrastructure. A commit that references an EU AI Act article obligation, linked to a PR with a compliance review and a passing CI check, is a defensible and verifiable evidence artefact. The key is structure: the obligation must be identifiable in the record, not inferred from it.

Is a GitHub Actions test result sufficient for Article 9 risk testing evidence?

It is a strong contributing evidence artefact. A GitHub Actions test run produces a timestamped, versioned, signed record that specific tests ran against a specific commit SHA and passed or failed. Combined with the test code (which documents what was tested) and the PR review (which shows a human approved the test coverage), this constitutes meaningful Article 9(9) testing evidence.