EU AI Act conformity assessment: what high-risk AI systems actually require
If your AI system falls into a high-risk category, it cannot legally deploy in the EU without passing conformity assessment. Most organisations don't know what that involves until they're already behind.
Conformity assessment is the EU AI Act's proof of work for high-risk AI. It is the structured process that demonstrates — with documentation, testing records, and human oversight evidence — that a high-risk AI system meets the Act's requirements before it goes live.
It is not a certificate you apply for. It is not a third-party audit you book. For most high-risk systems, it is an internal process that your organisation owns, executes, and maintains. The output is a technical file that must be ready for regulatory review at any point and kept current for the lifetime of the system.
If you have not yet confirmed which of your AI systems are high-risk, start with the EU AI Act risk classification guide before reading this one. Conformity assessment only applies to high-risk systems — but for those systems, it is mandatory before deployment in the EU.
What conformity assessment actually means
The term sounds like a one-time approval process. It is not. Conformity assessment under the EU AI Act is an ongoing compliance posture for every high-risk AI system your organisation deploys.
It has three components:
Before deployment — you must be able to demonstrate that the system meets all applicable requirements. This means the technical file must be complete, the fundamental rights impact assessment must be documented, human oversight mechanisms must be implemented, and transparency obligations must be met.
At deployment — for some high-risk systems in specific categories (biometric identification, AI in regulated products), third-party conformity assessment by a notified body is required. For the majority of Annex III high-risk systems, self-assessment is permitted — but the documentation standard is the same.
After deployment — the system must be monitored continuously. When it changes materially — new training data, expanded use cases, vendor updates, new data integrations — the conformity assessment must be updated. A stale technical file is a compliance gap even if the original assessment was complete.
Who is responsible
Responsibility for conformity assessment depends on your role under the Act.
Providers — organisations that develop high-risk AI systems and place them on the EU market under their own name — carry the full conformity assessment obligation. You build the system, you own the file.
Deployers — organisations using high-risk AI systems developed by a third party — have narrower but real obligations. You must conduct a fundamental rights impact assessment for certain high-risk categories. You must verify that the provider has completed conformity assessment and can produce the technical file. You must implement human oversight in the deployment context. You must monitor the system in use and report serious incidents.
The deployer trap: buying a high-risk AI system from a compliant vendor does not transfer the compliance obligation. If your HR platform has AI-powered candidate screening, your organisation is a deployer with its own obligations — regardless of whether the platform provider has completed their conformity assessment. Both parties carry requirements. Neither substitutes for the other.
The technical file: what it must contain
For providers, the technical file is the core deliverable of conformity assessment. For deployers using third-party high-risk AI, requesting and reviewing this file from your vendor is a compliance obligation.
The file must contain:
System description and intended purpose — a clear description of what the system does, the specific task it performs, the context in which it operates, and the categories of persons it affects. Vague descriptions do not meet the standard. The intended purpose determines the applicable requirements and the scope of the impact assessment.
System architecture and design — how the system works, including the logic of the AI model, the data flows, the decision-making process, and any human intervention points. For systems using third-party models or APIs, the documentation must cover the components you deploy, not just the underlying model.
Training data governance — the sources of training data, the collection methodology, the cleaning and preprocessing steps, the bias testing performed, and the demographic representativeness of the data relative to the population the system affects. If the system was fine-tuned on proprietary data, that data's provenance and quality controls must be documented.
Performance metrics and testing results — accuracy benchmarks, performance across demographic subgroups, failure mode analysis, and robustness testing. The metrics must be meaningful for the system's use case. A hiring AI assessed only on overall accuracy, without subgroup performance breakdown, does not meet the standard.
Known limitations — documented conditions under which the system underperforms, produces unreliable outputs, or should not be used. Regulators expect honest limitation documentation. A file that claims no limitations is a red flag.
Bias and fairness assessment — documented testing for discriminatory outputs across protected characteristics relevant to the system's use case. For employment AI, this means testing across gender, age, ethnicity, and disability status at minimum.
Human oversight mechanisms — documented evidence that meaningful human oversight exists in practice, not just in policy. See the human oversight section below.
Version history and change log — a record of every material change to the system since the initial conformity assessment, including the date, the nature of the change, and the re-assessment performed.
Conformity declaration — a signed EU Declaration of Conformity, attesting that the system meets all applicable EU AI Act requirements. This document travels with the system and must be updated when requirements change.
Fundamental rights impact assessment
For high-risk AI systems, providers must conduct a fundamental rights impact assessment (FRIA) before deployment. Deployers are required to conduct their own FRIA for certain high-risk categories — specifically AI used in education, employment, essential services, law enforcement, migration, and justice.
The FRIA is not the same as a GDPR Data Protection Impact Assessment, though there is significant overlap where the system processes personal data. Run them in parallel and integrate the outputs rather than treating them as the same document.
A complete FRIA covers:
Scope of impact — which fundamental rights the system could affect, including the right to non-discrimination, privacy, access to employment, access to essential services, effective remedy, and human dignity. The scope must be specific to the system's use case, not a generic list.
Affected populations — who the system makes decisions about or significantly influences. Identify protected characteristics within that population that are relevant to potential discriminatory outcomes.
Harm scenarios — documented analysis of what happens when the system produces a biased output, a false positive, a false negative, or a system failure. For each scenario, assess the likelihood and the severity of harm to affected individuals.
Mitigation measures — what controls are in place to reduce the probability and impact of each harm scenario. Controls must be specific and verifiable, not policy statements.
Residual risk — the risk that remains after mitigation measures are applied, and the organisational decision to accept that residual risk with documented rationale.
Review schedule — FRIAs are not one-time documents. Define when the assessment will be reviewed: at a minimum annually, and whenever the system, its use case, or its data inputs change materially.
Human oversight: what meaningful actually means
The EU AI Act requires meaningful human oversight for high-risk AI systems. The word meaningful is doing significant work in that requirement.
A human reviewing and rubber-stamping every AI recommendation is not meaningful oversight. A policy that states humans can override the system is not meaningful oversight. Meaningful oversight requires that the human reviewer:
- Has access to the AI system's reasoning, not just its output
- Has the training to understand the system's limitations and when its outputs are unreliable
- Has the authority to override the system's recommendation without organisational consequence
- Actually exercises that authority in practice, with override decisions documented
What oversight mechanisms look like in practice:
For a recruitment AI: reviewers must see the system's reasoning for each candidate ranking, not just the ranking. They must receive training on the types of bias the system has been tested for. Override decisions — where a reviewer selects a candidate the system did not rank highly, or rejects a candidate the system ranked highly — must be logged and periodically audited to confirm oversight is genuine rather than nominal.
For a credit risk AI: every decline decision influenced by an AI assessment must be reviewable by a human with the authority to reverse it. The review must happen before the decision is communicated to the applicant, not as an appeals process after the fact.
For a medical AI: clinicians using AI diagnostic support must be trained on the system's validated performance range, the conditions under which it is unreliable, and the protocol for cases where clinical judgment conflicts with the AI's output. The AI output must be presented as a support tool, not a diagnosis.
Document the oversight, not just the mechanism. Regulators will expect evidence that oversight happens in practice. That means audit logs of human reviews, records of override decisions, training completion records for reviewers, and periodic audits of oversight quality.
Third-party conformity assessment: when it applies
For most Annex III high-risk AI systems, self-assessment by the provider is permitted. Third-party conformity assessment by a notified body is required in two situations:
High-risk AI in regulated products — AI systems embedded in products covered by existing EU product safety legislation (medical devices, machinery, vehicles, toys, lifts) must go through the conformity assessment process required for that product category, which in most cases involves a notified body. These obligations apply from August 2, 2028.
Biometric identification systems — AI systems performing real-time or post-event remote biometric identification of individuals in publicly accessible spaces, to the extent permitted under the Act's narrow law enforcement exceptions, require notified body involvement.
For all other Annex III high-risk categories — employment, education, essential services, law enforcement (excluding biometric identification), migration, justice — internal self-assessment is the standard route, provided the technical file meets the required standard.
Post-market monitoring
Conformity assessment is not complete at deployment. High-risk AI systems must be monitored continuously after they go live, and providers must establish a post-market monitoring system before deployment.
Post-market monitoring covers:
Performance tracking — ongoing measurement of system accuracy and bias indicators in the live environment, compared against the benchmarks established during conformity assessment. Performance in production often differs from performance in testing, particularly as user behaviour, data distributions, and external conditions change.
Incident logging — serious incidents — AI outputs that result in death, serious injury, violation of fundamental rights, or significant property damage — must be reported to the relevant national market surveillance authority. Near-misses and non-serious incidents must be logged internally.
User feedback collection — mechanisms for people affected by the system's decisions to flag concerns, report errors, and request human review. This is both a monitoring mechanism and a transparency obligation.
Re-assessment triggers — defined conditions that require updating the conformity assessment: material changes to the system's functionality, changes to the training data, expansion to new use cases, vendor updates that alter the system's behaviour, or performance degradation detected through monitoring.
The timeline: when obligations apply
High-risk AI system obligations under Annex III apply from December 2, 2027, following the AI omnibus political agreement of May 7, 2026.
That gives most organisations approximately 18 months from today.
Building a complete conformity assessment for a single high-risk system — technical file, FRIA, oversight mechanisms, monitoring infrastructure, and conformity declaration — takes a minimum of three to six months if the organisation has governance infrastructure already in place. Organisations starting from scratch on both governance and conformity assessment need longer.
Eighteen months is not comfortable headroom. It is a planning constraint that requires starting now.
The EU AI Act compliance checklist covers the full compliance roadmap from inventory through to audit-ready governance posture, with timelines mapped to each enforcement date.
Where to start
If your organisation has not yet built an AI inventory, start there. You cannot conduct conformity assessment for systems you have not identified.
If your inventory exists but systems have not been classified by risk tier, start with classification. The EU AI Act risk classification guide covers the full tier structure and the classification process.
If you have classified systems and identified high-risk tools, the conformity assessment sequence is:
- Assign a named owner for each high-risk system
- Request technical documentation from third-party providers
- Begin the fundamental rights impact assessment
- Document existing human oversight mechanisms and identify gaps
- Build the technical file, starting with system description and architecture
- Establish post-market monitoring before the system goes live or before December 2027 for systems already deployed
Conformity assessment is not a compliance box. It is the documented evidence that your organisation made a deliberate, informed decision to deploy a system that affects people's lives — and built the governance to back that decision up.
*Grasp maps every AI tool in your organisation to its EU AI Act obligations, classifies risk automatically, and keeps your compliance evidence in one place. Book a demo →*
