Conformity assessment is how the provider of a high-risk AI system shows, before it reaches the market, that the system meets the EU AI Act's requirements. For most high-risk AI agents it is done by the provider itself under internal control. A deployer should ask for the declaration of conformity, the instructions for use and proof of registration.
What does conformity assessment involve?
Before a high-risk system is placed on the market or put into service, its provider must show that it meets the Act's requirements. Those include a risk management system, data governance, technical documentation, automatic logging, transparency and instructions for deployers, human oversight measures, and appropriate accuracy, robustness and cybersecurity. The provider must also run a quality management system.
The assessment takes one of two routes. For most uses listed in Annex III, including creditworthiness assessment and insurance pricing, it is based on internal control: the provider checks its own quality management system and technical documentation against the requirements. For some biometric uses, a third-party notified body may need to be involved.
Once satisfied, the provider draws up an EU declaration of conformity, affixes the CE marking and registers the system in the EU database before placing it on the market. If the system is later substantially modified, it needs a new assessment.
Who must carry it out?
The provider. That might be a vendor selling an agent platform with a credit capability, or it might be you. A firm that builds its own high-risk agent, puts its name on a bought one, changes an agent's intended purpose so it becomes high-risk, or substantially modifies it, becomes the provider and owns the assessment.
Location does not help. A provider outside the EU that places a high-risk system on the EU market must still complete the assessment and appoint an authorised representative in the EU; the question of whether the EU AI Act applies to companies outside the EU is answered by where the system is used, not where it was built.
What makes conformity harder for an agent?
A conformity assessment fixes a system at a point in time and declares it compliant for an intended purpose. Agents strain both ideas.
The system is assembled after purchase. An agent's behaviour depends on the brief, sources and connections the deployer adds. A provider can assess the platform and its built-in capabilities, but not every configuration a customer will create. The deployer has to stay within the stated purpose, and the instructions for use must say clearly what that is.
Change is constant. Models are updated, sources change, new tools are connected. The Act allows providers to describe pre-determined changes in advance so that they do not count as substantial modification. Anything outside that description may trigger reassessment. For an agent, the boundary between a configuration change and a substantial modification needs to be agreed and written down.
Purpose drift. A support agent that starts answering questions about loan eligibility, and then begins recommending outcomes, may have drifted into a listed high-risk use without anyone deciding it should. Our piece on the EU AI Act for AI agents in customer service shows how that happens.
How do you meet it, as provider or deployer?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Assessment before market | Provider completes internal control or notified body route as applicable | EU declaration of conformity |
| Quality management system | Documented procedures for design, testing, change and incidents | QMS documentation and audit records |
| Technical documentation | Description of system, capabilities, data, testing and controls | Technical file, versioned |
| Registration | Entry in the EU database before use | Registration reference |
| Defined intended purpose | Purpose stated per capability, with out-of-scope uses named | Instructions for use |
| Pre-determined changes | Change types allowed without reassessment listed in advance | Change plan in the technical documentation |
| Deployer stays in scope | Configuration checked against the stated purpose; new capabilities reviewed before enabling | Configuration review records |
| Reassess on substantial modification | Change control flags modifications outside the plan | Change log with reassessment decisions |
What should a deployer ask to see?
- The EU declaration of conformity for the specific capability you will use, not a general platform statement.
- The instructions for use, with intended purpose, accuracy levels and known limits.
- The registration reference in the EU database.
- The provider's list of pre-determined changes, and how you will be told of anything outside it.
- The provider's position on which of your configuration choices would count as substantial modification.
- Evidence of the provider's post-market monitoring and how your feedback feeds it.
If your use falls under the fundamental rights impact assessment duty, ask also for the information you need to complete it; our piece on the Article 27 fundamental rights impact assessment lists the fields.
What will a supervisor or auditor ask?
- Is this agent high-risk? Who is its provider, and where is the declaration?
- Has anything changed since the assessment? Who decided it was not a substantial modification?
- Is your use within the declared intended purpose?
- Have you added capabilities that the assessment did not cover?
What does conformity assessment not cover?
It does not certify how well the agent performs in your operation; it certifies that the provider met the requirements for the declared purpose. It does not cover deployer duties such as oversight, monitoring and notices. It does not apply to agents that are not high-risk. And it does not replace sector validation, such as a bank's own model risk review. Our guides on the EU AI Act and agents that act and AI agent regulation, mapped to controls set out what sits on either side.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Is a CE marking proof that an agent is safe for our use?
No. It shows the provider declares conformity for the intended purpose it described. Whether the agent works on your cases, with your sources and limits, is something you still have to test.
Does every model update trigger a new conformity assessment?
Not if the change was described in advance as a pre-determined change and stays within it. Changes outside that plan that affect compliance or purpose are treated as substantial modification.
Can a deployer do its own conformity assessment?
Only if it becomes the provider, for example by substantially modifying the system or changing its purpose. Otherwise the deployer's role is to check the provider's evidence and stay within it.