EU AI Act Art.9 Conformity Assessment Documentation Package: The Developer's Complete Guide (2026)

Post #5 in the EU AI Act Art.9 Risk Management System 2026 Series

The previous four posts in this series built the operational foundation of a compliant risk management system: the RMS structure and governance, the risk identification methodology, the testing requirements, and the continuous monitoring architecture. This final post addresses what you do with all of it: how to package the evidence into the documentation set that enables conformity assessment.

The documentation package is not a formality at the end of the process. It is the object that an assessor — internal or external — evaluates. If the documentation is incomplete, inconsistent, or fails to map evidence to regulatory requirements, the conformity assessment fails regardless of whether the underlying engineering was sound. The package is the product.

This post covers the structure of the Annex IV technical documentation as it relates to Art.9, the Art.43 assessment route decision, what assessors actually examine, the Art.47 Declaration of Conformity, Art.49 registration requirements, and a comprehensive checklist for the August 2026 deadline.

What Conformity Assessment Under the EU AI Act Actually Evaluates

Conformity assessment under Art.43 determines whether a high-risk AI system complies with the requirements of Chapter III Section 2 — the set of obligations that includes Art.9 (risk management), Art.10 (data governance), Art.11 (technical documentation), Art.12 (record-keeping), Art.13 (transparency), Art.14 (human oversight), and Art.15 (accuracy, robustness, cybersecurity).

The conformity assessment is not a product test. It is a documentation and process audit. An assessor does not run the model and observe its outputs to determine compliance. The assessor reviews whether you have established and followed the processes required by the regulation, and whether you have documented that you have done so. Evidence of compliance is documentation of process, not demonstration of outcome.

This has a practical implication: a system that performs extremely well technically but lacks the required documentation will fail conformity assessment. A system with adequate performance that has rigorous documentation of its risk management processes will pass. The documentation is primary.

Art.9 is the backbone of the conformity assessment. Most of the other Chapter III Section 2 requirements — data governance, transparency, human oversight — are documented within or referenced from the RMS. When an assessor evaluates an Art.9 system, they are evaluating whether the RMS covers the full scope of obligations and whether the documentation proves that the described processes were actually followed.

The Annex IV Documentation Structure

Art.11 requires providers of high-risk AI systems to establish technical documentation "before the AI system is placed on the market or put into service." Annex IV specifies what this documentation must contain. For Art.9 compliance, the relevant sections are where the RMS evidence lives.

Section 1: General Description of the System

The general description must cover the intended purpose, the AI system's overall performance metrics, the foreseeable misuse cases, the categories of persons and groups it affects, and the hardware and software components.

For Art.9 purposes, the intended purpose statement in this section must be precise enough to bound the risk management scope. Every risk identified in the RMS derives from a foreseeable use or misuse of the system. If the intended purpose is vague, the risk identification is unbounded — assessors will treat a vague intended purpose statement as a documentation deficiency because it makes the scope of the risk analysis unverifiable.

The foreseeable misuse cases documented here must match the misuse scenarios in your risk register. If you list five foreseeable misuse scenarios in the general description but only three appear in the risk register, the assessor will ask why two were not analysed. Consistency between this section and the RMS documentation is a common failure point.

Section 2: Detailed Description of System Elements

This section covers the design decisions — the algorithms used, the architecture, the training approach, the data preprocessing steps, and how the system outputs are generated and presented to the end user.

From an Art.9 perspective, this section must document the technical choices that were made in response to identified risks. If risk identification found that the model produces overconfident predictions in certain input regions, and you addressed this with a calibration layer and confidence thresholding, that design decision must appear here. The documentation must trace risk mitigation measures to the design elements that implement them.

The training data description is particularly scrutinised. Art.10 requires data governance documentation, and that documentation feeds directly into this section. The description must cover data sources, the data governance processes applied, the representativeness assessment methodology, and the outcome of that assessment. Gaps between what training data covers and what the intended purpose requires are a primary source of risk findings that must appear in the risk register.

Section 3: Information on Testing and Validation

This is where the testing evidence from the pre-deployment phase — covered in the third post in this series — is formally documented. The section must contain the testing methodology, the metrics used, the validation datasets (with lineage and representativeness information), the results, and the interpretation of results relative to the performance thresholds established during system design.

Assessors look for three things in this section. First, whether the testing scope covers all identified risks — every risk in the risk register that can be addressed through pre-deployment testing should have corresponding evidence here. Second, whether the performance thresholds are justified — the choice of acceptable performance levels is a risk management decision that must be documented with rationale. Third, whether the results are interpreted honestly — if testing revealed edge cases or performance degradation in sub-populations, those findings must appear here, along with how they were addressed or why they were accepted.

The testing documentation must be version-controlled and linked to specific model versions. Assessors will verify that the system placed on the market is the system that was tested. Version mismatches between the tested system and the deployed system are a conformity assessment blocking issue.

Section 4: Monitoring, Functioning, and Control

This section documents the post-deployment monitoring architecture — the subject of the fourth post in this series. For conformity assessment purposes, the documentation must cover the monitoring indicators, the alert thresholds, the human oversight processes triggered by alerts, and the feedback mechanism to the RMS.

The connection between this section and the risk register must be explicit. For each category of post-deployment risk — performance drift, data distribution shift, unexpected failure modes, misuse detection — the documentation must identify the monitoring indicator, the threshold at which investigation is triggered, and the escalation path.

Art.72 (post-market monitoring) establishes the ongoing obligation, but the documentation here establishes that the infrastructure to fulfil that obligation exists before the system is placed on the market. An assessor will look for evidence that the monitoring infrastructure was tested and is operational, not merely planned.

Section 5: Risk Management Documentation

This is the core Art.9 documentation section. It contains the risk management plan, the risk register, the risk management measures, and the evidence that measures were implemented and effective.

The risk management plan must describe the scope, the governance structure (who is responsible for what decisions), the methodology, and the schedule of reviews. The plan is a living document — the version in the conformity assessment package should be the current version, with a version history demonstrating updates.

The risk register must be comprehensive. Every identified risk must have: a description, an identification of the affected persons or groups, an assessment of likelihood and severity, the risk management measures implemented, the residual risk after measures, and a disposition (accepted, mitigated, or escalated). A risk register with open items that have no disposition will block conformity assessment.

The risk management measures documentation must demonstrate that measures are implemented, not merely planned. For technical measures (input validation, output confidence thresholds, human oversight interfaces), the documentation should reference the implementation in Section 2 and testing evidence in Section 3. For procedural measures (user training requirements, deployment constraints), the documentation should reference the instructions for use and deployer obligations under Art.26.

Choosing Your Art.43 Assessment Route

Art.43 specifies two assessment routes for high-risk AI systems. The route you follow determines who conducts the assessment and what documentation is formally reviewed.

Internal Control Assessment

For high-risk AI systems listed in Annex III that are not subject to the third-party assessment requirement, the provider conducts the conformity assessment internally. The provider reviews the Annex IV technical documentation against the Art.9 and related requirements, determines that the system meets those requirements, and prepares the Art.47 Declaration of Conformity.

Internal assessment does not mean informal assessment. The regulation requires the assessment to be conducted systematically, documented, and retained. In practice, internal assessment means an assessment conducted by personnel who were not the primary developers of the system — a degree of independence from the development team that provides meaningful review rather than self-certification.

Assessors under internal control still review the same documentation as a notified body would. The difference is that the decision on compliance is made internally. If the internal assessment finds gaps, the provider must address them before placing the system on the market.

For SME providers, Art.62 provides access to regulatory sandboxes and support mechanisms that can assist with conformity assessment preparation. The documentation requirements are the same, but the support infrastructure is intended to make the process accessible to organisations without dedicated compliance teams.

Third-Party Assessment by Notified Bodies

For certain categories of high-risk AI systems — primarily those intended for use in areas where independent verification is deemed essential, such as biometric identification systems used by law enforcement — Art.43 requires assessment by a notified body designated under Art.44.

A notified body assessment follows a structured process: document submission, technical review, potentially an audit of the provider's quality management system under Art.17, and issuance of a certificate where assessment is positive. The notified body certificate is one of the prerequisites for the Art.47 Declaration of Conformity.

Notified body assessors review Art.9 documentation with particular attention to the risk register completeness, the adequacy of risk management measures relative to identified risks, and the evidence of testing. The previous posts in this series were written with notified body scrutiny as the standard — if your documentation satisfies a notified body examiner, it satisfies the internal assessment standard.

If your system requires notified body assessment, the timeline matters. As of 2026, the notified body ecosystem for AI Act assessments is still developing. Scheduling a notified body assessment requires lead time that may not be available if documentation preparation begins close to the August 2026 deadline.

The Quality Management System and Art.9

Art.17 requires providers of high-risk AI systems to establish a quality management system. The QMS and the RMS are distinct but closely related: the QMS governs how the RMS processes are managed, reviewed, and improved.

For conformity assessment purposes, the QMS documentation is reviewed alongside the Annex IV technical documentation. Assessors look for evidence that the quality management system produces and maintains the RMS documentation, that the review cycles described in the QMS are followed, and that the QMS processes are themselves documented and followed.

The practical integration point is document control. The technical documentation submitted for conformity assessment must be produced under the QMS — version-controlled, reviewed, and approved following the QMS document control process. Documentation that exists outside the QMS process will raise questions about whether it represents the actual state of the system.

For teams implementing Art.9 compliance for the first time, establishing a lightweight but genuine QMS process before beginning conformity assessment documentation preparation is the most efficient path. Writing documentation without document control produces documentation that needs to be redone to pass assessment.

Preparing the Art.47 Declaration of Conformity

The Art.47 Declaration of Conformity is the formal statement that the provider has verified that the high-risk AI system complies with the applicable requirements under the EU AI Act. The Declaration of Conformity is required before placing the system on the market or putting it into service.

The Declaration must contain the provider's identification details, a description of the AI system including its intended purpose, a statement that the system complies with the applicable requirements, the assessment procedure followed (Art.43 route), for third-party assessments the notified body identification and certificate reference, the date of issue and period of validity, and the provider's authorised representative's signature.

The Declaration of Conformity must be maintained for 10 years after the AI system is placed on the market or put into service under Art.18. It must be updated when the system undergoes a substantial modification that triggers a new conformity assessment under Art.45.

A common mistake is treating the Declaration of Conformity as a step that occurs at the end, after all other work is complete. The Declaration is a consequence of completing conformity assessment, not a trigger for it. Draft the Declaration during the final stages of assessment preparation so that it can be signed immediately upon completion of the assessment.

Art.49 Registration Before Market Entry

Art.49 requires providers to register high-risk AI systems in the EU database established under Art.51 before placing them on the market or putting them into service. For most Annex III systems, this means registration in the EU AI database before deployment.

Registration requires providing specified information about the system: provider identity, intended purpose, categories of persons affected, the Annex III classification basis, a description of the system, a summary of the conformity assessment, a declaration of conformity reference, and information on post-market monitoring.

The registration requirement is often overlooked in conformity assessment preparation because it is procedural rather than technical. But non-registration is a compliance violation that can result in penalties under Art.99 and market suspension orders. Include registration in the conformity assessment timeline, not as an afterthought.

The Complete Art.9 RMS Documentation Checklist

The following checklist integrates the deliverables from all five posts in this series. All items are required before placing a high-risk AI system on the market.

Foundation Documents (from Post 1)

• RMS Governance Charter: scope definition, role assignments, decision authority matrix
• RMS Plan: methodology, schedule, escalation paths, version history
• QMS integration map: how RMS processes connect to the quality management system
• Intended purpose statement: precise, bounded, consistent with Annex III classification

Risk Identification Records (from Post 2)

• FMEA workbook or equivalent: all foreseeable failure modes documented
• Misuse scenario analysis: at least five foreseeable misuse scenarios per system
• Fundamental Rights Impact Assessment (FRIA) or assessment equivalents
• Risk register: all identified risks with likelihood, severity, and disposition
• Risk register completeness check: no open items without disposition

Testing Evidence (from Post 3)

• Test plan: testing scope, methodology, metrics, success thresholds
• Dataset documentation: lineage, representativeness assessment, governance
• Test results report: metrics against all identified risk categories
• Bias evaluation evidence: sub-population performance across protected characteristics
• Adversarial testing results: robustness under distribution shift and attack scenarios
• Version link: tested system version = deployed system version (verified)

Monitoring Architecture (from Post 4)

• Monitoring plan: indicators, thresholds, review cadence, human oversight triggers
• Escalation procedures: alert → human review → RMS update → Art.73 reporting path
• Deployer feedback mechanism: process for collecting anomalies from Art.26 deployers
• Infrastructure operational status: monitoring system tested and active before market entry

Conformity Assessment Package (this post)

• Annex IV Section 1: General description consistent with risk register scope
• Annex IV Section 2: Design documentation with risk mitigation measures traced
• Annex IV Section 3: Testing and validation evidence, complete and version-matched
• Annex IV Section 4: Monitoring architecture documentation
• Annex IV Section 5: Complete risk management documentation package
• QMS document control: all Annex IV documents version-controlled and approved
• Art.43 route determination: internal control or notified body (documented rationale)
• For notified body route: certificate obtained and referenced
• Art.47 Declaration of Conformity: prepared, signed, and filed
• Art.49 registration: submitted to EU AI database

Ongoing Obligations

• Art.18 documentation retention plan: 10 years from market entry
• Art.20 corrective action procedure: process for detecting and reporting non-compliance
• Art.45 substantial modification procedure: criteria and process for re-assessment triggers

EU Hosting and Data Residency in the Documentation Package

One dimension of the conformity assessment documentation that developers frequently underestimate is the infrastructure provenance requirements. When the Annex IV documentation describes the system's data governance (Art.10) and record-keeping (Art.12), the location and jurisdiction of the infrastructure where training data, inference logs, and RMS records are stored becomes a documented fact — one that national competent authorities can inspect under Art.74.

For providers operating in sectors with sector-specific data residency requirements (healthcare, financial services, critical infrastructure), the infrastructure documentation must demonstrate that data processing complies not only with the AI Act but with the overlapping sector regulations. A single system may be subject to AI Act, GDPR, NIS2, and sector-specific obligations simultaneously, and the conformity assessment documentation must address all of them.

European PaaS infrastructure — hosting in EU jurisdictions with contractual guarantees of EU-only data processing — provides the cleanest documentation path for this requirement. When the infrastructure layer is demonstrably EU-resident, the documentation covers this dimension in a single sentence rather than requiring complex cross-border data flow analysis and adequacy determinations.

The August 2026 Deadline: What Must Be Complete

The August 2, 2026 deadline under the EU AI Act applies to the obligations for high-risk AI systems listed in Annex III. By August 2, 2026, providers must have:

1. Completed the conformity assessment under Art.43
2. Established the technical documentation under Art.11 and Annex IV
3. Registered the system in the EU AI database under Art.49
4. Issued the Declaration of Conformity under Art.47
5. Applied the CE marking (where required)

For providers who have followed the work outlined in this five-part series, the documentation infrastructure is in place. The risk management system is operational, the testing evidence exists, the monitoring architecture is live, and the Annex IV documentation is structured around the processes that have been running.

The remaining work is assembly and formal completion: compiling the Annex IV documentation package from the operational records, completing the Art.43 assessment review, preparing and signing the Declaration of Conformity, and submitting registration.

For teams starting today, 53 days is a tight timeline. Prioritise in this order: complete the risk register (no open items without disposition), complete testing evidence (version-matched to the deployed system), complete the monitoring plan and confirm monitoring infrastructure is operational. With these three elements complete, the remaining documentation can be assembled from existing records.

Series Summary: The Art.9 RMS in Five Posts

This five-part series built the complete implementation of a compliant Art.9 risk management system from foundations to conformity assessment:

Post 1 — Foundations: Governance, scope, the iterative lifecycle obligation, and how to structure an RMS that survives a notified body review.

Post 2 — Risk Identification: FMEA methodology, misuse scenario analysis, FRIA, and building a risk register that covers the full scope of foreseeable harms.

Post 3 — Testing Requirements: Pre-deployment testing obligations, metrics and thresholds, bias evaluation, adversarial testing, and the documentation that proves testing was adequate.

Post 4 — Continuous Monitoring: Post-deployment monitoring architecture, drift detection, human oversight triggers, and how monitoring findings feed back into the RMS update cycle.

Post 5 (this post) — Conformity Assessment Package: Assembling the Annex IV documentation, choosing the Art.43 assessment route, the Declaration of Conformity, registration, and the complete checklist for August 2026 readiness.

The EU AI Act does not reward last-minute compliance. The documentation package reflects processes that must have been running throughout development and deployment. If those processes were implemented as described in this series, the conformity assessment documentation is the formalisation of what already exists — not the creation of something new.

The August 2 deadline is 53 days away. The documentation work starts now.