A high-risk AI system can perform well in testing and still fail an AI conformity assessment. The usual reason is not a missing policy statement. It is the absence of a defensible evidence chain: a clear intended purpose, a documented classification decision, traceable risk controls, test results, quality management records and accountable sign-off.
For compliance teams, this changes the work materially. The EU AI Act does not ask organisations to make broad claims that their AI is trustworthy. It requires providers of high-risk systems to demonstrate compliance with defined obligations before placing the system on the market or putting it into service. That demonstration must remain credible when a regulator, customer, notified body or auditor asks to see the underlying evidence.
What AI conformity assessment means under the EU AI Act
Conformity assessment is the formal process used to establish whether an AI system meets the applicable EU AI Act requirements. It is most significant for high-risk AI systems under Article 6, including systems listed in Annex III where they are used in areas such as employment, education, essential services, law enforcement, migration and administration of justice.
It is not a generic ethical review and it is not completed by running a one-off impact assessment. The assessment must examine whether the system and the provider’s operating arrangements satisfy the relevant legal requirements. These include the risk management system, data and data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, robustness, cybersecurity and quality management.
The first control point is classification. A team cannot select an assessment route until it has established the system’s intended purpose, the provider’s role and whether the system falls within Article 6. That requires more than attaching a product label such as “recruitment AI” or “fraud detection”. The facts matter: who uses the output, what decision it informs, whether people can contest the outcome, the affected population and the conditions of deployment.
A system may be outside the Annex III high-risk category where it does not pose a significant risk of harm and meets the relevant exemption conditions. That judgement must be documented, not assumed. A short, reasoned classification record is far more defensible than an untracked decision made in a product meeting.
Provider, deployer and supply-chain responsibilities
The provider carries the principal conformity assessment obligation. Under the Act, this is generally the party developing an AI system, or having it developed, and placing it on the market or putting it into service under its own name or trademark.
That distinction can become complicated quickly. An organisation that substantially modifies a third-party system, changes its intended purpose, or markets the resulting system as its own may assume provider responsibilities. Procurement teams should therefore not treat a supplier declaration as a complete answer. They need to establish what has been supplied, what evidence supports it and whether local configuration alters the risk profile.
Deployers have separate obligations, including using systems in accordance with instructions, assigning human oversight, monitoring operation and maintaining logs where under their control. They may not conduct the provider’s conformity assessment, but their implementation records can expose whether the provider’s stated controls work in practice.
Choose the correct assessment route
The applicable route depends on the type of high-risk system and the legal framework around it. AI systems that are safety components of products covered by the legislation in Annex I may follow the relevant sectoral conformity assessment procedures, incorporating the AI Act requirements.
For many Annex III high-risk systems, the provider can use the internal control procedure set out in Annex VI. This does not mean self-certification without discipline. It means the provider bears responsibility for applying a structured process, maintaining the required documentation and issuing an EU declaration of conformity when the conditions are met.
In specified circumstances, a notified body assessment under Annex VII may be required or appropriate, particularly where the applicable route calls for independent assessment or where the provider cannot rely on relevant harmonised standards or common specifications. Biometric systems require particular care because the assessment route and applicable conditions can be more demanding.
The operational lesson is simple: do not begin with a template and work backwards. Start with a legal classification, identify the applicable route, then build an evidence plan against the requirements of that route. Assessment dates and implementing measures should also be checked against the current text of the Act and Commission guidance. A compliance plan based on outdated rollout assumptions creates avoidable exposure.
The evidence file that stands up to scrutiny
The technical documentation required by Article 11 and Annex IV is the centre of the assessment record. It should allow a competent reviewer to understand what the system does, how it was developed, what limitations apply and how compliance has been demonstrated.
This is where fragmented spreadsheets fail. A risk register held by compliance, model tests held by data science and supplier records held in procurement do not form a technical file merely because they exist. The organisation needs a controlled system of record that connects evidence to the specific AI system, version, owner, obligation and decision.
A credible file normally brings together the following material:
- the system description, intended purpose, user groups, deployment context and version history;
- the classification rationale and applicability analysis for each AI Act requirement;
- design, development and validation records, including data provenance, data quality measures, testing methodology and performance results;
- the risk management file, showing identified risks, evaluated residual risks, control decisions and acceptance by accountable owners;
- human oversight instructions, transparency information, logging arrangements, cybersecurity measures and incident processes; and
- the quality management evidence, declaration of conformity and procedures for post-market monitoring.
The point is not volume. A 200-page document that cannot identify the current model version, test evidence or control owner is weaker than a concise, governed record with clear references. Evidence should be proportionate to the system’s risk, but proportionate does not mean vague.
Risk management must be continuous
Article 9 requires a risk management system that runs throughout the AI system lifecycle. In practice, teams need to identify reasonably foreseeable risks to health, safety and fundamental rights; assess those risks; implement mitigation; and test whether the controls work.
This requires attention to trade-offs. A stricter confidence threshold may reduce incorrect decisions but increase the number of cases sent for manual review. A human review stage can provide meaningful oversight, but only if reviewers have the authority, training and information to intervene. Recording a control without testing its real-world operation is not risk management.
Risk records should distinguish between inherent risk, control design, control effectiveness and residual risk. They should also state who has accepted the residual risk and on what basis. This makes board reporting more useful and prevents technical teams from quietly carrying legal and operational risk they do not have authority to accept.
Quality management is the operational proof
Article 17 requires providers of high-risk AI systems to establish a quality management system. This is often misunderstood as a certification exercise or a document library. In reality, it is the operating discipline that makes evidence repeatable.
The system should define responsibilities, development controls, data management procedures, testing and validation methods, change management, supplier management, incident handling, corrective action and record retention. ISO/IEC 42001 can provide a valuable management-system structure, but it does not remove the need to map controls directly to EU AI Act obligations.
For a mid-market organisation, the sensible approach is not to recreate an enterprise GRC programme. It is to establish the minimum controlled workflow needed to prove who approved what, which evidence was reviewed, what changed and why the system remains compliant. Pre-seeded control mappings and assessment workflows can reduce setup time, but they must still be tailored to the actual system.
A platform such as Endaxi AIG supports this by keeping the AI inventory, classification decision, risk assessment, control evidence, ownership records and reporting outputs in one auditable environment. The value is operational clarity, not another dashboard.
Prepare for change before it happens
Conformity assessment is not the final gate in a project plan. Once a high-risk AI system is in use, the provider must maintain post-market monitoring, investigate serious incidents and malfunctioning, take corrective action where necessary, and reassess compliance when material changes occur.
Set clear triggers for reassessment. A new training dataset, revised model architecture, new decisioning threshold, different user group, expansion into another Member State or altered intended purpose may each affect the original assessment. The exact impact depends on the change, but no team should rely on informal judgement after deployment.
Build reassessment into change management: log the proposed change, determine whether the risk profile or intended purpose changes, assign legal and technical review, update evidence, and retain the approval record. This is considerably less costly than reconstructing the decision trail during an audit or regulatory enquiry.
The practical test is straightforward. If your organisation had to show the current AI system’s classification, controls, test evidence and accountable approvals by the end of the week, could it do so without chasing five departments? If not, the next useful step is not another policy. It is establishing the evidence workflow before the system changes again.