Documentation-as-Code: Version-Synced Technical Documentation
How documentation-as-code practices help keep AI Act technical documentation in step with each code change.
Key Takeaways
- 1.Providers of high-risk AI systems must keep technical documentation up to date (Article 11(1)).
- 2.Documentation-as-code keeps the technical documentation in version control next to the code.
- 3.Parts can be generated from code and pipeline data. Judgment calls need people.
- 4.Version control shows what changed and when, not that the content is correct.
The duty applies to providers that place high-risk AI systems on the EU market or put them into service there (Article 2(1)(a)). Annex IV lists what the documentation must contain. Annex III is the Act’s list of high-risk uses, such as hiring. Annex I covers AI in products under EU safety law. Section A of Annex I lists product laws such as those on toys and medical devices. Section B lists other product laws. For Annex III systems, the duty applies from 2 December 2027. For systems under Section A of Annex I, it applies from 2 August 2028 (Regulation (EU) 2026/1744). Systems placed on the market or put into service before those dates fall under Article 111(2), as replaced by Regulation (EU) 2026/1744. Other than the systems in Article 111(1), they are covered only if, from the applicable date, they are subject to significant changes in their designs. For systems intended for use by public authorities, Article 111(2) sets a deadline of 2 August 2030 to take the necessary steps to comply.
For high-risk AI systems related to products under Section B of Annex I, Article 2(2) limits which provisions apply. Only Article 6(1) (classification rules), Article 60a (testing in real-world conditions outside sandboxes) and Articles 102 to 112 (final provisions) apply. Articles 57 to 59 (regulatory sandboxes) apply only in so far as those product laws have integrated the Act’s requirements for high-risk AI systems. Article 11 is not listed there.
The provider obligations are in Article 16. A breach can cost up to EUR 15 million or, for an undertaking, 3% of worldwide annual turnover, whichever is higher (Article 99(4)). For micro, small and medium-sized enterprises (SMEs, Article 3(14a)), the lower amount applies (Article 99(6)).
With documentation-as-code, changes are reviewed in pull requests and each version is tied to a release. Next step: check which of the nine Annex IV points in the table below you can generate from your repository.
Why documents outside the repository drift
Documents in Word files, PDFs or wikis are separate from the code they describe.
A document can describe an old version
Updating is manual work
What documentation-as-code means in practice
Documentation-as-code applies software engineering practices to technical documentation:
Version control
The technical documentation lives in the same Git repository as the code. Each change is a commit with an author, a date and a diff, so you can match a document version to a code version.
Generation where possible
Some sections can be generated from the codebase, as the table below shows. People write the sections that need judgment.
Pipeline checks
Your team can write a pipeline rule that fails a pull request when the model changes but the matching document section does not. The Act does not require it.
Release bundles
Each release bundles the documents with the software version, so you can produce the documentation that matched a given release.
Generation helps with some Annex IV points more than with others
Generation helps somewhat with 4 of the 9 Annex IV points, little with 4 and not at all with 1. The two right-hand columns are our assessment, not the Act’s.
SMEs and small mid-cap enterprises (SMCs, Article 3(14b)) may give the Annex IV elements in a simplified manner. This follows from Article 11(1), as amended by Regulation (EU) 2026/1744. Those that do must use the simplified form that the Commission is to establish. The lower fine amount also applies to SMCs (Article 99(6a)).
| Annex IV point | Possible approach | Generation helps |
|---|---|---|
| 1. General description of the AI system | Names and versions from the manifest, README and release metadata | Some |
| 2. Elements of the system and its development process | Architecture and pipeline descriptions from the code; design rationale written by people | Some |
| 3. Monitoring, functioning and control | Accuracy figures from test results; limitations and human oversight measures written by people | Some |
| 4. Appropriateness of the performance metrics | Metrics from evaluation pipelines; the argument that they fit is written by people | Little |
| 5. Risk management system (Article 9) | Risk register as a versioned file; the risk analysis is done by people | Little |
| 6. Relevant changes through the lifecycle | Git history and changelog give the raw list; the provider selects the relevant changes | Some |
| 7. Standards applied | A maintained list in the repository | Little |
| 8. Copy of the EU declaration of conformity | The signed declaration stored with the release | None |
| 9. Post-market monitoring system (Article 72) | The plan as a versioned document; monitoring data comes from operations | Little |
Example layout: documentation files next to the code
This layout is an example, not a required structure.
your-ai-system/
├── src/
├── docs/
│ └── compliance/
│ ├── annex-iv/
│ │ ├── 01-general-description.md
│ │ ├── 02-development-process.md
│ │ └── ...
│ ├── risk-register.yaml
│ └── oversight.md
├── tests/
│ └── docs/
└── .github/
└── workflows/
└── docs-check.ymlA pipeline can check the documents on every pull request
Scan: analyse the codebase
A scan step can use a tool that detects standard ML framework patterns in the code. Custom wrappers and obfuscated code can be missed.
Generate: refresh the drafts
The pipeline rebuilds generated sections from current inputs, so the diff shows what changed in the documents.
Validate: check completeness
Rules check that the required sections exist and contain the required content. A content check is not a truth check: people review accuracy.
Report: show the result on the pull request
The pull request shows which checks passed or failed, so a reviewer sees the documentation impact before the change is merged.
Plain-text files allow line-by-line review, and branch protection guards the history
Pull requests show the changed lines
Protect the history
Related Reading
Sources & References
- Regulation (EU) 2024/1689 (EU AI Act) — Articles 2, 3, 11, 16, 43 and 99 and Annexes I, III and IV (Annex IV: nine points of technical documentation).
- Regulation (EU) 2026/1744 — Digital Omnibus on AI — dates of application (Article 113) and changes to Articles 2(2), 3, 11(1), 99 and 111(2), and the new Article 60a.
- GitHub Docs — About protected branches — branch protection rules decide whether collaborators can force push to a branch.
- Pro Git — Viewing the Commit History — the commit history lists each commit with its author, date and message; with the patch option it shows the diff.
Frequently Asked Questions
What is documentation-as-code for AI Act documentation?
Documentation-as-code keeps the technical documentation in version control, changes it through pull requests and generates parts of it in a pipeline. The aim is that the technical documentation matches the system as released.
Why do documents outside the repository drift?
Word files and PDFs are separate from the code, so a code change does not update them. Someone must update them, because Article 11(1) requires technical documentation to be kept up to date.
Does documentation-as-code satisfy Annex IV?
No practice satisfies Annex IV by itself. Annex IV sets the content in nine points. Documentation-as-code helps keep that content current and traceable. The provider must ensure that the system meets the requirements of Chapter III, Section 2, which include Article 11 (Article 16(a)).
What tools are used for documentation-as-code?
You can combine Git, Markdown or YAML files and a CI pipeline for checks and generation. A scanner or generator can produce the sections derived from code.
How often should AI technical documentation be updated?
Article 11(1) requires technical documentation to be drawn up before the system is placed on the market or put into service, and kept up to date. Article 11(1) sets no fixed interval. Our suggestion is to review it with each release and after any change to the model, the training data or the intended purpose. A substantial modification requires a new conformity assessment (Article 43(4)). A substantial modification is a change after the system is placed on the market or put into service that the first conformity assessment did not foresee or plan. It affects compliance with the requirements for high-risk AI systems in Chapter III, Section 2 or changes the intended purpose (Article 3(23)). A conformity assessment is the process of demonstrating whether those requirements have been fulfilled (Article 3(20)).
Scanara prepares evidence from your repositories
Scanara reads your connected GitHub repositories and runs rule-based scans for standard AI and machine-learning patterns. It can miss non-standard code. Separately, it generates draft documentation from templates and your assessment answers as evidence for your compliance work. You make the classification decisions.