Control · C-046 · Model & System Lifecycle
Model and system documentation
Each AI system's purpose, design, data, test results and limitations are documented to a set standard that allows a validator, auditor or regulator to understand it without its authors.
- Control type
- Directive
- Family
- Risks addressed
- 4
- Audience
- Heads-of · Practitioner
- Frameworks
- Principle 8 · Annex IV · Article 11 · Principle 3
- Responsible AI domain
- Lifecycle stage
- Reviewed
- 2026-11-11
What it does
It makes the system knowable to people other than those who built it. Documentation is what validation examines, what change is assessed against, what a successor inherits and what a regulator asks for. The model owner is accountable; documentation is produced during development, required for approval and updated at each change.
How to implement it
- Set a documentation standard by risk tier.
- Cover intended purpose, design and assumptions, data sources and preparation, evaluation method and results, known limitations, and required oversight.
- For bought systems, obtain the supplier's documentation and record what is missing.
- Make completeness a condition of approval.
- Version documentation with the system and update it on change.
- Store it where validators and auditors can reach it.
Evidence it operates
Design: the documentation standard and templates. Operation: for a sample of systems, documentation that matches the system in production; a completeness check at approval; version history aligned with the change log.
Where it fits
Produced through development and maintained through the system's life. It is the primary control for inadequate technical documentation, and a dependency of independent model validation. For high-risk systems under the EU AI Act the content is prescribed.
Limits
Documentation records what its authors knew and chose to write. It goes stale quickly unless tied to change management. A complete document set can coexist with a poor model, so it is evidence for assurance and not a substitute for it. Suppliers of hosted models often decline to provide what the standard asks for, and the gap has to be recorded and accepted by someone with authority.
Risks this mitigates
Primary mappings
- Inadequate technical documentation Medium
- Sets the documentation standard and makes it a condition of approval. Design, data, testing and limitations are not documented well enough for a validator, auditor or regulator to understand the system.
Supporting mappings
- Missing information for deployers and users Medium
- Provides the source material for those instructions. The people who operate or use a system have not been told its intended purpose, how well it performs, where it fails and what oversight it needs.
- Opaque model logic High
- Records design choices and known limitations. Developers, validators and owners cannot explain why a model produces its outputs well enough to challenge, correct or defend it.
- Overstated AI claims Medium
- Provides the documented performance to check claims against. The organisation misdescribes what its AI does, how well it performs or how it is governed, to customers, investors or regulators.
Framework and clause references
| Framework | Clause | Title |
|---|---|---|
| Code of Practice for the Cyber Security of AI | Principle 8 | Document your data, models and prompts Documentation. |
| EU AI Act | Annex IV | Technical documentation content Its content. |
| EU AI Act | Article 11 | Technical documentation Technical documentation. |
| SS1/23: Model Risk Management Principles for Banks | Principle 3 | Model development, implementation and use Model documentation. |
Related terms
How to cite
Axiom Verity (2026). Model and system documentation. Reference Library, C-046. https://axiom-verity.com/controls/model-and-system-documentation. Reviewed 2026-11-11.
Found an error or a better source? Report a correction.