We use cookies to improve your experience and analyse site traffic.
This cross-reference index maps every EU AI Act Article, Annex, and AISDP Module referenced in the Practical Implementation Guide to the sections that address it. Assessors use it to verify regulatory coverage, trace compliance requirements bidirectionally, and locate all relevant guidance across the eighteen domain sections.
This index maps every EU AI Act Article, Annex, and AISDP Module referenced in the Practical Implementation Guide to the sections that address it.
This index maps every EU AI Act Article, Annex, and AISDP Module referenced in the Practical Implementation Guide to the sections that address it. Assessors can use it to verify that a given regulatory requirement is addressed and to locate all relevant guidance across the eighteen domain sections. The index covers explicit citations only; Articles, Annexes, and Modules not listed were not directly cited, though this does not necessarily indicate a coverage gap.
Some provisions fall outside the guide's scope by design. The administrative machinery in Articles 64 through 69 is not addressed because it governs the AI Office and Board rather than provider or deployer obligations. Annexes X through XIII (large-scale IT systems, gpai model documentation, transparency information, and systemic risk classification criteria) are referenced only where the GPAI integration domain addresses their downstream implications for high-risk system providers.
Article 9 (Risk Management System) and Article 10 (Data and Data Governance) are the most extensively cross-referenced provisions, each appearing in over fifteen sections.
Article 9 (Risk Management System) and Article 10 (Data and Data Governance) are the most extensively cross-referenced provisions, each appearing in over fifteen sections. This reflects their foundational role: risk management calibrates thresholds, controls, and monitoring parameters across every domain, while data governance underpins model performance, fairness testing, and CI/CD pipeline gates.
Article 12 (Record-Keeping) and Article 15 (Accuracy, Robustness and Cybersecurity) are similarly pervasive, appearing across version control, pipeline, security, and post-market monitoring sections. Article 72 (Post-Market Monitoring) and Article 73 (Serious Incident Reporting) anchor the operational compliance obligations that persist after deployment.
Articles with narrower scope, such as Article 19 (Automatically Generated Logs) or Article 40 (Harmonised Standards), appear in fewer sections but carry equal regulatory weight within their domain. The index enables compliance teams to verify that no Article relevant to their system has been overlooked during aisdp preparation. Risk Management for High-Risk AI covers the Article 9 requirements in depth.
The nine Annexes referenced in the guide serve distinct compliance functions.
The nine Annexes referenced in the guide serve distinct compliance functions. Annex I lists the Union harmonisation legislation that triggers Article 6(1) classification for safety components. Annex III enumerates the high-risk AI system categories under Article 6(2). Together, these two Annexes determine whether a system falls within the high-risk framework.
Annex IV specifies the technical documentation requirements under Article 11, making it the structural blueprint for the AISDP itself. It is the most frequently referenced Annex, appearing across risk assessment, model documentation, architecture, version control, pipeline, security, and conformity assessment sections. Annex V defines the EU Declaration of Conformity format. Annex VI describes the internal control conformity assessment procedure that most high-risk systems follow.
Annex VII covers the alternative conformity route via Quality Management System and technical documentation assessment, used when a notified body is involved. Annex VIII specifies registration information for the EU database. Annex IX addresses registration for real-world testing under Article 60. Version Control and Change Management and Conformity Assessment reference these Annexes extensively.
The twelve AISDP Modules map to the guide's eighteen domain sections through a many-to-many relationship.
The twelve AISDP Modules map to the guide's eighteen domain sections through a many-to-many relationship. No single section produces a complete Module, and no Module draws from a single section. This reflects the reality that compliance documentation is inherently cross-cutting.
Module 1 (System Description and Intended Purpose) draws from the widest range of sections, including system description, architecture, version control, security, registration, and post-market monitoring. Module 6 (Risk Management System) similarly spans risk assessment, data governance, architecture, pipeline, and operational oversight sections.
Module 5 (Testing and Validation) draws primarily from the fairness, architecture, pipeline, and security sections. Module 9 (Robustness and Cybersecurity) concentrates in the security section but extends into risk assessment, architecture, and monitoring. Module 12 (Post-Market Monitoring and Change History) bridges the operational sections with version control and pipeline sections. Understanding these mappings helps teams identify which domain expertise is needed for each Module and prevents the siloed approach where one team prepares a Module without consulting the sections that feed into it.
The index serves three primary workflows.
The index serves three primary workflows. During initial AISDP preparation, teams use the Article-to-section mapping to verify coverage: for each Article relevant to their system, they can locate every section that addresses it and confirm that the guidance has been incorporated into their documentation.
During conformity assessment, assessors use the index in reverse: starting from a specific AISDP Module, they trace back to the Articles it must satisfy and verify that the corresponding sections have been followed. This bidirectional traceability is what makes the index valuable for audit.
During post-market monitoring, the index helps teams trace a detected issue to its regulatory context. A fairness drift alert, for example, implicates Article 10 (data governance), Article 9 (risk management), and Article 72 (post-market monitoring). The index shows which sections address each Article, enabling the team to locate the relevant thresholds, controls, and escalation procedures. Post-Market Monitoring covers the operational response workflow.
The index covers explicit citations in the Practical Implementation Guide.
The index covers explicit citations in the Practical Implementation Guide. Several categories of provisions fall outside its scope. Administrative and institutional provisions (Articles 64 through 69) govern the AI Office, AI Board, and advisory forum rather than provider or deployer obligations.
Penalty provisions beyond Article 99 (which is included) are referenced contextually rather than mapped to specific compliance guidance. Transitional provisions and delegated act procedures are addressed in the guide's timeline and applicability sections rather than in the domain sections that the index maps.
Annexes X through XIII address GPAI-specific requirements. They are referenced only through the GPAI integration section, which describes their downstream implications for providers of high-risk systems that integrate GPAI models. Organisations building or deploying GPAI models directly should consult the Regulation's text and any codes of practice published under Article 56. GPAI Integration covers the integration compliance architecture.
Not necessarily. The index covers explicit citations only. Some provisions (administrative machinery in Articles 64 to 69, transitional provisions) fall outside the guide's scope because they govern institutional processes rather than provider or deployer obligations.
No. Modules map to multiple sections through a many-to-many relationship. Module 1 (System Description), for example, draws from system description, architecture, version control, security, registration, and post-market monitoring sections. Cross-team collaboration is essential.
Start from the AISDP Module under review, trace back to the Articles it must satisfy using the Article-to-section mapping, then verify that the corresponding guidance sections have been followed. This bidirectional traceability is what assessors examine during audit.
Three workflows: coverage verification during AISDP preparation (Article to section), audit traceability during conformity assessment (Module to Articles), and regulatory context tracing during post-market monitoring (issue to relevant provisions).