If your AI system must comply with more than one framework, you face a choice: maintain separate documentation for each, or build a single documentation structure that satisfies all of them simultaneously.
Most teams choose the first path by default. They write Annex IV documentation for the EU AI Act, a separate AI management system record for ISO 42001, yet another design history file for ISO 13485, and a controls narrative for SOC 2. The result is duplicated content, conflicting versions, and documentation that drifts out of sync within weeks.
The second path is harder to set up but far easier to maintain. It works because the underlying requirements are not as different as they appear.
The Six Frameworks
This guide covers the documentation requirements of six frameworks that commonly apply to AI systems. Each serves a different regulatory or trust purpose, but all demand overlapping evidence.
EU AI Act Annex IV
Regulation 2024/1689 requires providers of high-risk AI systems to prepare and continuously maintain technical documentation across eight sections: general system description, detailed development process, monitoring and control, risk management, lifecycle changes, conformity testing, post-market monitoring, and applicable standards. Article 11 establishes the obligation; Annex IV specifies the content. Documentation must be retained for 10 years after market placement.
ISO 42001 Clause 7.5
ISO/IEC 42001:2023 establishes an AI management system (AIMS) standard. Clause 7.5 requires documented information for the AIMS itself: policies, objectives, risk assessments, and records of AI system development and operation. The standard also requires documentation of responsible AI practices, including bias assessments, transparency measures, and human oversight provisions.
ISO 13485 Clause 4.2
For AI systems deployed in medical devices, ISO 13485:2016 Clause 4.2 requires a quality management system with documented procedures, a quality manual, and records. Clause 7.3 further requires a design and development file (the design history file) covering planning, inputs, outputs, reviews, verification, validation, and transfer. Every design decision must be traceable.
ISO 27001 Clause 7.5
ISO/IEC 27001:2022 Clause 7.5 requires documented information for the information security management system (ISMS). For AI systems, this covers data classification, access controls, encryption standards, incident response procedures, and the risk treatment plan. AI-specific concerns include training data security, model integrity, and adversarial robustness documentation.
SOC 2
SOC 2 Type II reports require documented controls mapped to the Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. For AI systems, auditors expect documentation of model governance, data handling procedures, change management, access controls, and monitoring. The documentation must demonstrate that controls operated effectively over the audit period.
NIST AI RMF
The NIST AI Risk Management Framework (AI 100-1) organizes AI risk practices into four functions: Govern, Map, Measure, and Manage. Each function requires documented evidence of processes, decisions, and outcomes. While NIST AI RMF is voluntary, it is increasingly referenced in US federal procurement, state-level AI legislation, and as a benchmark for responsible AI practices globally.
Where the Requirements Overlap
When you map each framework's documentation requirements to concrete topics, the overlap becomes clear. Six documentation areas appear in nearly every framework:
| Documentation topic | EU AI Act Annex IV | ISO 42001 | ISO 13485 | ISO 27001 | SOC 2 | NIST AI RMF |
|---|---|---|---|---|---|---|
| System architecture and design | Sections 1, 2 | Clause 6.1, A.6 | Clause 7.3 | Annex A.8 | CC6, CC7 | Map |
| Training data provenance and governance | Section 2 | Annex A.7 | Clause 7.3.3 | Annex A.5 | PI1, C1 | Map, Measure |
| Risk assessment and mitigation | Section 4 | Clause 6.1 | Clause 7.1 | Clause 6.1 | CC3, CC9 | Govern, Manage |
| Performance metrics and testing | Sections 3, 6 | Clause 9.1 | Clause 7.3.6-7 | Clause 9.1 | CC4 | Measure |
| Change management records | Section 5 | Clause 8.1 | Clause 7.3.9 | Annex A.8.32 | CC8 | Manage |
| Monitoring and incident response | Sections 3, 7 | Clause 9.1, 10.2 | Clause 8.2.3 | Annex A.5.24-28 | CC7 | Measure, Manage |
The specific framing differs. The EU AI Act frames risk management around "risks to health, safety, and fundamental rights." ISO 27001 frames it around information security threats. SOC 2 frames it around Trust Services Criteria. But the underlying evidence is the same: you identified risks, you assessed their severity and likelihood, you implemented controls, and you can prove it.
EU AI Act Annex IV: The Eight Sections
Because Annex IV is the most prescriptive of the six frameworks, it serves as a useful structural backbone. Here is what each section requires.
1. General Description of the AI System
Intended purpose, version history with key changes per version, hardware and software stack, and a reference to the instructions for use required under Article 13.
Also satisfies: ISO 42001 system scope (Clause 4.3), ISO 13485 device description (Clause 7.3.2), NIST AI RMF context mapping.
2. Detailed Description of System Elements and Development
The technical core. General logic, design choices, architecture, training methodologies, training data provenance and governance, validation and testing data, and pre-trained model lineage including any fine-tuning steps.
Also satisfies: ISO 42001 AI system lifecycle documentation (Annex A.6), ISO 13485 design input/output records (Clause 7.3.3-4), SOC 2 processing integrity (PI1).
3. Monitoring, Functioning, and Control
Capabilities and limitations, performance metrics (accuracy, robustness, cybersecurity), known biases and their impact, and measures taken to meet Article 15 standards.
Also satisfies: ISO 42001 performance evaluation (Clause 9.1), ISO 27001 monitoring and measurement (Clause 9.1), NIST AI RMF Measure function.
4. Risk Management
Methodology, identified risks, and adopted mitigation measures, referencing your Article 9 risk management system.
Also satisfies: ISO 42001 risk assessment (Clause 6.1), ISO 13485 risk management (Clause 7.1), ISO 27001 risk treatment (Clause 6.1), SOC 2 risk assessment (CC3, CC9), NIST AI RMF Govern and Manage functions.
5. Changes to the System
Lifecycle changes assessed for their impact on performance, risk, and compliance. This is the section most teams fail to maintain post-launch.
Also satisfies: ISO 42001 change management (Clause 8.1), ISO 13485 design changes (Clause 7.3.9), ISO 27001 change management (Annex A.8.32), SOC 2 change management (CC8).
6. Conformity Testing
Testing conducted to verify risk management measures are effective, including methodologies, test sets, and results.
Also satisfies: ISO 13485 design verification and validation (Clauses 7.3.6-7), SOC 2 monitoring activities (CC4), NIST AI RMF Measure function.
7. Post-Market Monitoring System
The monitoring plan required under Article 72: what metrics are monitored, at what frequency, what triggers a formal review, and how findings feed back into risk management.
Also satisfies: ISO 42001 continual improvement (Clause 10.2), ISO 13485 post-market surveillance (Clause 8.2.3), ISO 27001 incident management (Annex A.5.24-28), NIST AI RMF Manage function.
8. Applicable Standards
Harmonised standards applied, and where standards were not applied or only partially applied, the solutions adopted to meet Articles 8-15.
Also satisfies: ISO 42001 normative references, SOC 2 complementary framework mappings.
The Currency Problem (Multiplied)
Annex IV documentation must reflect the current state of the system. ISO 42001 requires documented information to be "available and suitable for use, where and when it is needed." ISO 13485 requires design files to be updated "as appropriate" through the product lifecycle. When you multiply this obligation across six frameworks, every change event triggers updates across multiple documentation areas:
| Change event | Documentation sections affected | Frameworks triggered |
|---|---|---|
| Model retrain | Architecture, training data, performance metrics, risk assessment, change log, testing | All six |
| New training dataset version | Data provenance, data governance, change log | EU AI Act, ISO 42001, ISO 13485, SOC 2, NIST |
| Deployment to new market or user group | System description, intended purpose, risk assessment, monitoring plan | EU AI Act, ISO 42001, NIST |
| Third-party model update | Pre-trained model lineage, performance metrics, risk assessment | EU AI Act, ISO 42001, SOC 2, NIST |
| Security incident | Incident response records, risk re-assessment, corrective actions | ISO 27001, SOC 2, NIST, EU AI Act |
| New integration or data source | Architecture, data classification, access controls, risk assessment | All six |
Maintaining six separate documentation systems for these change events is not sustainable. A single source of truth with framework-specific views is the only approach that scales.
The Write-Once Architecture
A practical multi-framework documentation system has three layers:
- Evidence layer: Version-controlled records of what your AI system is, how it was built, what risks were identified, what controls were implemented, and how performance is measured. These records are framework-agnostic. They describe your engineering reality.
- Mapping layer: A cross-reference that connects each evidence record to the specific clauses, sections, or criteria of each applicable framework. One risk assessment record might map to EU AI Act Annex IV Section 4, ISO 42001 Clause 6.1, ISO 27001 Clause 6.1, SOC 2 CC3, and NIST AI RMF Govern.
- View layer: Framework-specific audit packs generated from the evidence and mapping layers. When a SOC 2 auditor needs documentation, you generate a SOC 2 view. When an EU AI Act authority requests technical documentation, you generate an Annex IV view. Same underlying evidence, different packaging.
Who Maintains This and How
Multi-framework documentation is a cross-functional obligation. In practice, it requires collaboration between:
- Engineering: architecture, training methodology, testing results, deployment configuration
- Data science: data provenance, performance metrics, bias assessments, model lineage
- Information security: access controls, data classification, incident response, adversarial robustness
- Legal and compliance: regulatory framing, framework-specific language, retention requirements
- Quality management: process documentation, corrective actions, management reviews
The key insight: each team documents their own domain once. The compliance function maps that documentation to frameworks. No team writes "EU AI Act documentation" or "SOC 2 documentation" as a separate activity. They write accurate engineering records, and the system handles the rest.
Frequently Asked Questions
Can a single documentation structure satisfy both the EU AI Act and ISO 42001?
Yes. The EU AI Act Annex IV requires eight sections of technical documentation covering system description, development process, risk management, and monitoring. ISO 42001 Clause 7.5 requires documented information for AI management system processes. Both frameworks demand architecture descriptions, risk assessments, data governance records, and performance metrics. A unified documentation structure that addresses each topic once, with framework-specific cross-references, satisfies both simultaneously.
Which AI documentation requirements overlap across frameworks?
Six documentation topics appear in nearly every AI governance framework: system architecture and design, training data provenance and governance, risk assessment and mitigation, performance metrics and testing, change management records, and post-deployment monitoring. The EU AI Act Annex IV, ISO 42001, ISO 13485, ISO 27001, SOC 2, and NIST AI RMF all require these topics in some form. The specific framing differs, but the underlying evidence is the same.
How should AI teams manage documentation across multiple compliance frameworks?
Maintain a single source of truth for each documentation topic, structured as version-controlled records tied to your engineering workflow. Then generate framework-specific views or audit packs from that source. This avoids duplication, reduces the risk of conflicting information across frameworks, and ensures that a single change event updates all relevant documentation simultaneously.