EU AI Act Conformity Assessment: A Step-by-Step Guide for High-Risk AI Systems
Master EU AI Act conformity assessment for high-risk AI. A practical, article-by-article guide for compliance officers and AI leads in 2025.
Why Conformity Assessment Is the Most Misunderstood Obligation in the EU AI Act
Most enterprises racing toward EU AI Act compliance have heard of the FRIA, the prohibited practices list, and the August 2025 phased deadlines. Far fewer have a clear operational picture of conformity assessment — the formal process that determines whether a high-risk AI system is legally fit for deployment. This gap is significant, because conformity assessment is not a checkbox or a one-time audit. It is a structured, documented, evidence-backed process that providers and, in some cases, deployers must complete before a high-risk system can be placed on the EU market or put into service.
The confusion partly stems from terminology. Some teams conflate conformity assessment with a Fundamental Rights Impact Assessment. Others assume it is synonymous with ISO 42001 certification or a CE-marking exercise borrowed from product safety law. None of those equivalences hold precisely. Conformity assessment under the EU AI Act has its own distinct scope, procedural routes, and documentation obligations that are tied directly to the risk classification of the system and the nature of the organisation deploying or providing it.
This guide walks compliance officers, AI leads, and CTOs through the full process in sequence: what triggers the obligation, which procedural route applies, what evidence must be assembled, and how to maintain conformity after initial assessment. Where Fronterio's workflows map directly to a procedural step, that connection is noted — not as a sales pitch, but because understanding what tooling can automate versus what requires human legal judgement is itself a critical implementation decision.
Which Systems Trigger the Conformity Assessment Obligation
The conformity assessment obligation applies specifically to high-risk AI systems as defined in Annex III of the EU AI Act, and to certain AI systems covered by the Union harmonisation legislation listed in Annex I. Annex III covers eight domains: biometric identification, critical infrastructure management, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border control, and administration of justice. If your organisation provides or deploys an AI system that falls into any of these categories, conformity assessment is not optional.
The classification question is therefore the logical starting point. Article 6 sets out the criteria for high-risk classification, and the interaction with sector-specific harmonisation legislation in Annex I adds a second dimension many teams overlook. A medical AI system that is also a medical device under the MDR, for example, follows a different conformity pathway than a pure Annex III system. Providers of those dual-scope systems must understand which sectoral route applies and whether the AI Act conformity obligations are satisfied by compliance with the sectoral regime or must be met in parallel.
For deployers — the enterprises actually putting third-party high-risk AI into service — Article 26 creates a distinct set of obligations, some of which feed directly into or overlap with the provider's conformity process. Deployers do not typically conduct the full technical conformity assessment themselves, but they carry specific obligations around use-case adherence, monitoring, and documentation that, if neglected, can void the provider's original conformity determination. Understanding where provider obligations end and deployer obligations begin is foundational before any assessment work begins.
The Two Conformity Assessment Routes: Internal vs. Third-Party
The EU AI Act establishes two procedural routes for conformity assessment, and choosing the wrong one is a material compliance error. Article 43 sets out the framework. For the majority of Annex III high-risk systems, the law permits internal conformity assessment — meaning the provider self-assesses against the requirements in Articles 8 through 15 without involving a notified body. This is sometimes characterised as a lighter-touch route, but that framing is misleading. Internal assessment still demands a complete technical file, rigorous testing records, human oversight documentation, and a formal declaration of conformity. The absence of a third-party auditor does not reduce the evidentiary standard; it relocates accountability entirely onto the provider.
The second route — third-party conformity assessment by a notified body — is mandatory for certain high-risk systems, specifically AI systems intended to be used as safety components in products covered by Union harmonisation legislation where those acts require third-party assessment, and for biometric identification systems that are not used exclusively for verification purposes. For these systems, Article 43(1) requires the provider to involve a notified body accredited under the Act. As of mid-2025, the notified body ecosystem for EU AI Act purposes is still forming, and capacity constraints are already emerging — meaning organisations that need third-party assessment should be initiating engagement with notified bodies now rather than waiting for internal readiness to be complete.
One nuance worth emphasising: organisations that hold a quality management system certification — for example, under ISO 9001 or the AI-specific ISO 42001 — can leverage those certifications within the internal assessment route to streamline documentation, but they do not substitute for the substantive technical requirements the Act imposes. Certification of the management system is not certification of the AI system itself.
Building the Technical File: What Evidence Must Be Assembled
The technical file is the evidentiary backbone of conformity assessment. Article 11 specifies that providers must draw up and maintain this file before placing the system on the market, and Annex IV details its required contents. The file must include a general description of the system, its intended purpose, and the version at assessment; detailed information about the system design including architecture, training methodologies, and data governance; the risk management documentation required by Article 9; the data governance measures required by Article 10; the technical documentation on accuracy, robustness, and cybersecurity metrics required by Article 15; a description of the human oversight measures required by Article 14; and the post-market monitoring plan required by Article 72.
For organisations building this file from scratch, the practical challenge is not understanding what belongs in it — the list in Annex IV is clear — but assembling evidence that is current, traceable, and internally consistent across systems that may have been updated multiple times since initial deployment. Model cards, data sheets, test logs, incident records, and monitoring outputs all need to be cross-referenced, version-controlled, and retrievable on demand. This is where the gap between organisations that have invested in structured AI documentation practices and those that have not becomes painfully visible.
Fronterio's auto-evidence ladder is designed precisely for this assembly challenge. It maps each required Annex IV element to a structured evidence collection workflow, prompts owners of each system component to upload or attest to the relevant artefact, and flags gaps before the technical file is considered complete. For compliance officers managing a portfolio of high-risk systems rather than a single deployment, this kind of systematic tracking is not a convenience — it is the only operationally credible approach at scale.
Risk Management, Data Governance, and the Pre-Assessment Requirements
Articles 9 and 10 establish two substantive pre-conditions that must be satisfied before a conformity assessment can be completed. Article 9 requires a continuous risk management system — not a one-time risk register, but an ongoing process of identification, analysis, estimation, evaluation, and mitigation of reasonably foreseeable risks throughout the system's lifecycle. The standard imposed is the risk to health, safety, and fundamental rights of all potentially affected persons, including vulnerable groups. The risk management system must produce documented risk assessments, and the measures adopted to address identified risks must be verifiable.
Article 10 governs data and data governance for training, validation, and testing datasets. It requires that data practices meet standards of relevance, representativeness, and freedom from errors and biases to the extent possible. For systems that have already been built and deployed, this creates a retrospective documentation obligation that can be technically demanding — particularly for systems trained on proprietary datasets or third-party data the provider no longer controls directly. Deployers using third-party high-risk AI also have Article 26 obligations around ensuring the system is used only within its intended purpose and informing the provider if something changes materially about the deployment context.
These two articles together mean that conformity assessment is not a documentation exercise that can be separated from actual system design and data decisions. If the risk management process was not conducted rigorously during development, or if the training data does not meet the Article 10 standard, the conformity assessment cannot simply paper over those gaps. Organisations that discover these deficiencies mid-assessment face a choice between genuinely remediating the system or limiting its deployment scope to avoid triggering the full high-risk classification.
Human Oversight, Accuracy, and the Article 14 and 15 Documentation Requirements
Two of the most technically substantive requirements in the conformity assessment documentation concern human oversight and system performance. Article 14 requires that high-risk AI systems be designed and developed to allow the natural persons to whom oversight is assigned to effectively understand the capacities and limitations of the system, detect and address dysfunctions, and intervene or interrupt the system when necessary. The documentation obligation is not just to assert that human oversight exists, but to demonstrate that the system design — including interfaces, interpretability features, and the training provided to operators — actually enables the oversight function to work as described.
Article 15 sets performance standards for accuracy, robustness, and cybersecurity. Providers must specify the intended accuracy metrics in the technical file and demonstrate through testing that those levels are achieved and maintained. The robustness requirement means the system must be resilient to attempts to alter its output through adversarial inputs, a requirement that has direct implications for organisations deploying AI in adversarial environments such as fraud detection, content moderation, or access control. Cybersecurity documentation must address both the system itself and the infrastructure on which it operates.
For deployers, Article 26 requires that human oversight measures are implemented as specified by the provider — not modified, diluted, or quietly bypassed because the operational team finds them cumbersome. This is an area where the gap between the documented conformity position and the reality of how the system is operated can widen rapidly after go-live. Fronterio's deployer obligations tracker is designed to make this gap visible by surfacing the specific oversight requirements attached to each high-risk system in the organisation's portfolio and tracking whether operational teams have confirmed adherence on a scheduled basis.
Post-Market Monitoring, Incident Reporting, and Maintaining Conformity Over Time
One of the most operationally demanding aspects of the EU AI Act conformity regime is that assessment is not a point-in-time event. Article 72 requires providers to establish and implement a post-market monitoring plan that is proportionate to the nature of the AI technology and the risks presented by the high-risk system. This plan must be documented in the technical file, and its outputs must feed into a continuous loop of assessment, updating, and — where necessary — re-reporting to market surveillance authorities.
Article 73 creates a separate, time-sensitive obligation for serious incidents. Providers of high-risk AI systems must report serious incidents — defined as incidents or malfunctions that directly or indirectly cause death, serious harm to health, property, or fundamental rights — to the national competent authority of the member state in which the incident occurred. The reporting timeline is 15 days for incidents involving a risk to life or health; for other serious incidents, a 10-day window applies for initial notification with a detailed follow-up. These windows are tight relative to the investigation cycles most enterprise incident management processes are designed for.
Fronterio's Article 73 workflow maps the incident detection and classification process to the statutory reporting requirements, providing structured templates for initial notification and follow-up reports, tracking the timeline against the applicable deadline, and maintaining an audit trail of all communications. The post-market monitoring synthesiser aggregates outputs from the ongoing monitoring plan — performance drift signals, operator feedback, incident records, external research on comparable systems — and surfaces them for the technical file update cycle required before any substantial modification of the system is made. Together, these capabilities close the gap between the static compliance exercise many teams envision and the dynamic, lifecycle-spanning obligation the Act actually creates.
The Declaration of Conformity and CE Marking: Completing the Process
Once the technical file is complete, the risk management and data governance processes are documented, the human oversight and performance requirements are evidenced, and the applicable conformity assessment route has been completed, the provider draws up a declaration of conformity under Article 47. This declaration must be signed by or on behalf of the provider, must identify the system clearly, state that it complies with the relevant requirements of the Act, reference the conformity assessment procedure used, and — where a notified body was involved — include the notified body's identification number and certificate reference.
For systems covered by both the EU AI Act and Union harmonisation legislation, the Act requires a single declaration of conformity that addresses all applicable legislative instruments. This single-declaration requirement is straightforward in principle but can create coordination challenges in practice when different teams within the provider organisation own different compliance streams — the legal team owns the AI Act declaration while the regulatory affairs function owns the MDR declaration, for example. Someone needs to own the integration.
After the declaration is drawn up, providers must affix the CE marking in accordance with Article 48. For AI systems that are standalone software products placed on the EU market, the CE marking is affixed to the product itself or its packaging. For AI systems integrated into other products, the marking and declaration obligations interact with those of the product manufacturer. The declaration and the full technical file must be retained for 10 years after the system is placed on the market or put into service — a retention requirement that should be reflected immediately in the organisation's document management and data retention policies rather than treated as a post-project administrative detail.
Frequently asked questions
What is conformity assessment under the EU AI Act?
Conformity assessment under the EU AI Act is the formal process by which a provider of a high-risk AI system demonstrates that the system meets the mandatory requirements set out in Articles 8 through 15 of the Act — covering risk management, data governance, transparency, human oversight, accuracy, robustness, and cybersecurity. The process must be completed before the system is placed on the EU market or put into service, and it results in a technical file, a declaration of conformity, and — for applicable systems — CE marking.
Does every high-risk AI system need a notified body for conformity assessment?
No. The EU AI Act permits internal conformity assessment — without a notified body — for most Annex III high-risk systems. Third-party assessment by a notified body is only mandatory for AI systems used as safety components in products subject to harmonisation legislation that itself requires third-party conformity assessment, and for certain biometric identification systems. However, internal assessment still requires a complete technical file, documented risk management, and a formal declaration of conformity — the absence of a notified body does not lower the evidentiary standard.
What must be in the technical file for a high-risk AI system?
Annex IV of the EU AI Act specifies the required contents: a general description of the system and its intended purpose; design and development documentation including architecture and training methodology; risk management records under Article 9; data governance documentation under Article 10; accuracy, robustness, and cybersecurity metrics under Article 15; human oversight design documentation under Article 14; instructions for use; and the post-market monitoring plan required by Article 72. The file must be kept up to date for 10 years after the system is placed on the market.
What are a deployer's responsibilities in the conformity assessment process?
Deployers do not conduct the full technical conformity assessment — that is the provider's obligation. However, under Article 26, deployers must use high-risk AI systems only within the scope of the provider's declared intended purpose, implement human oversight measures as specified, monitor the system's performance in production, and inform the provider of any material change in deployment context that could affect conformity. Deployers who deviate from the declared use case can inadvertently invalidate the provider's conformity determination and assume provider-equivalent obligations.
How does post-market monitoring relate to conformity assessment?
Post-market monitoring is a mandatory component of the conformity assessment documentation under Article 72. Providers must establish and document a post-market monitoring plan as part of the technical file, and the plan's outputs must feed into ongoing assessment of whether the system continues to meet the Act's requirements. If monitoring reveals performance drift, unexpected impacts, or incidents, the technical file and risk management documentation must be updated accordingly, and substantial modifications may trigger re-assessment obligations.
What is the EU AI Act serious incident reporting deadline under Article 73?
Article 73 requires providers of high-risk AI systems to report serious incidents to the relevant national competent authority. For incidents involving a risk to life or health, the initial notification must be made within 15 days of the provider becoming aware of the incident. For other serious incidents involving harm to fundamental rights or property, initial notification is required within 10 days, followed by a detailed follow-up report. These timelines run from the point of awareness, not from the point at which an internal investigation is complete, making rapid detection and triage capabilities essential.
Can ISO 42001 certification replace EU AI Act conformity assessment?
No. ISO 42001 certifies an organisation's AI management system — the processes, governance structures, and controls used to manage AI development and deployment. EU AI Act conformity assessment certifies that a specific AI system meets the technical and procedural requirements of the Act. An ISO 42001 certification can provide useful supporting evidence within a conformity assessment technical file, and regulators may view it favourably, but it does not substitute for the system-level requirements under Articles 8 through 15 or the documentation obligations in Annex IV.
When must conformity assessment be completed — before or after deployment?
Before deployment. Article 43 requires that the conformity assessment procedure be completed before the high-risk AI system is placed on the EU market or put into service. This means the technical file must be finalised, the applicable assessment route completed, and the declaration of conformity signed prior to go-live. Conducting the assessment retrospectively after deployment has already occurred is a compliance violation, even if the system would have passed. Organisations planning new high-risk AI deployments should build the assessment timeline into the project plan from the outset.
Ready to get started?
Fronterio helps you implement everything discussed in this article, with built-in tools, automation, and guidance.