Updated 1 October 2026 to reflect the Digital Omnibus, in force since 27 July 2026.
If your AI system falls into a high-risk category, it cannot legally be deployed 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, human oversight mechanisms must be implemented, transparency obligations must be met and, where a deployer owes one, the fundamental rights impact assessment must be documented.
At deployment: for some high-risk systems in specific categories (certain biometric systems, 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.
For high-risk systems, the work starts with knowing which systems you have. Grasp keeps that AI inventory and its decision history current, so you are not reconstructing it later.
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 use the system according to the provider's instructions, implement human oversight in the deployment context, monitor the system in use, keep its logs and report serious incidents. Some deployers must also conduct a fundamental rights impact assessment. The Act does not oblige you to audit the provider's conformity assessment, but asking for the EU declaration of conformity and the instructions for use is sound due diligence.
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. Deployers are not legally required to obtain this file, but asking your vendor for the instructions for use, the EU declaration of conformity and a summary of what the file covers is sound due diligence.
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, a sensible minimum is testing across gender, age, ethnicity, and disability status.
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
The fundamental rights impact assessment (FRIA) in Article 27 is a deployer duty, not a provider one. It applies to deployers that are public bodies or private entities providing public services, and to deployers of AI used for credit scoring or for risk assessment and pricing in life and health insurance. It must be done before the system is first used. Providers instead run the risk management system required by Article 9. Other deployers are not obliged to do a FRIA, though the same analysis is useful preparation for any high-risk deployment.
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 running two unconnected exercises.
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. A yearly review is a sensible minimum, and it must be updated 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 should 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 2 August 2028.
Biometric systems: for the biometric systems listed in Annex III, point 1 (remote biometric identification, biometric categorisation and emotion recognition), a notified body is required unless the provider has fully applied harmonised standards or common specifications. Where it has, internal control is allowed.
For all other Annex III high-risk categories (critical infrastructure, education, employment, essential services, law enforcement, 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 or malfunctions that lead to death or serious harm to health, serious disruption of critical infrastructure, a breach of fundamental rights obligations, or serious harm to property or the environment) must be reported to the relevant national market surveillance authority. Near-misses and non-serious incidents should 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 2 December 2027, following the Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026). AI embedded in regulated products follows on 2 August 2028. Systems already on the market before those dates are caught only once their design changes significantly, with a separate deadline of 2 August 2030 for systems used by public authorities.
Building a complete conformity assessment for a single high-risk system (technical file, oversight mechanisms, monitoring infrastructure, conformity declaration and, where it applies, the FRIA) takes, in our experience, 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.
2 December 2027 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 the instructions for use and the declaration of conformity from third-party providers
- Begin the fundamental rights impact assessment, if you are a deployer that owes one
- 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
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 finds the AI tools in your organisation, researches each vendor against your policy and keeps every decision on record. Talk to us