EU AI Act Conformity Assessment: How It Works

Conformity assessment is the gate between a finished high-risk AI system and the EU market. It verifies evidence rather than creating it, which means the work happens during the build and the assessment confirms it. This guide covers how the process works, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

What is conformity assessment?

The process of demonstrating that a high-risk system meets the Act's requirements before it is placed on the market or put into service.

It results in an EU declaration of conformity, and where applicable CE marking and registration in the EU database. For product-embedded AI, it is integrated into the conformity assessment the product legislation already requires.

Which route applies?

System category	Typical route
Most listed high-risk use areas	Internal control by the provider
Certain biometric categories	Notified body involvement
AI as safety component of regulated products	Existing product route, extended

The route follows the category rather than preference. Establish which applies early, because a notified body route carries lead times that affect the launch date materially.

What evidence must exist beforehand?

Technical documentation, risk management records across the lifecycle, data governance evidence, test results demonstrating appropriate accuracy and robustness, logging design, human oversight design, and quality management system documentation.

Assessment verifies that evidence. Organisations that reach this point without it are not late in a process; they are at the start of one. See EU AI Act high-risk obligations.

What is the quality management system requirement?

An organisational obligation covering how the provider ensures compliance: procedures for design, development, testing, data management, record-keeping, incident reporting, post-market monitoring, and communication with authorities.

It applies across systems rather than per system, which is an advantage — build it once and each subsequent system is cheaper.

What does the declaration of conformity involve?

A written declaration by the provider that the system meets the requirements, identifying the system, the provider, and the requirements met, and kept available to authorities for a defined period.

It is a statement of responsibility rather than a certificate someone else issues, which is why the evidence behind it matters.

What is registration in the EU database?

Many high-risk systems must be registered in an EU database before being placed on the market, with information about the system and its provider. Some public authority deployers carry registration duties too.

Confirm the current requirements for your category, since scope and detail have been subject to implementing measures.

What triggers reassessment?

Substantial modification of the system, and changes to its intended purpose.

Retraining within parameters already documented is generally treated differently from changing what the system does or how it behaves materially, but the boundary needs establishing for each system and recorded. Teams that do not define it end up either reassessing constantly or not when they should.

How does this affect release practice?

Considerably. A system that is retrained frequently needs a defined position on which changes fall within documented parameters and which do not, plus evidence that each release was evaluated.

Build that into the release process rather than deciding case by case. See what is a regression suite for ai.

How long does it take?

Internal control is bounded by how quickly you can assemble and review your own evidence, which for a well-run project is short. Notified body routes involve external scheduling and are not.

Plan the timeline around the route rather than treating assessment as a step at the end.

What does it cost?

Mostly the cost of the evidence, which is engineering work you needed anyway. The assessment itself is modest for internal control routes and material for notified body routes.

The expensive version is discovering at assessment that the evidence does not exist. See AI compliance audit cost.

What are the common mistakes?

Treating assessment as a final formality. Establishing the route late. Retraining without a documented position on substantial modification. And building evidence as a separate workstream rather than as a by-product of engineering.

Who owns this internally?

The provider organisation's product or engineering function, with quality and legal support. It cannot sit purely with compliance, because the evidence is generated by engineering.

What about systems already on the market?

Transitional arrangements apply to systems placed on the market before the relevant dates, with different treatment depending on category and on whether the system is substantially modified afterwards.

Confirm the position for your systems rather than assuming either that they are grandfathered or that they are not.

What should you do first?

Take one system you believe is high-risk and try to assemble the technical documentation today. What is missing is your actual project plan, and it is usually testing evidence and data provenance rather than policy documents.

What about systems you buy rather than build?

A deployer using a system placed on the market by someone else does not perform conformity assessment, but it does need the provider's declaration, the instructions for use, and enough information to operate the system within its intended purpose.

Ask for those before purchase rather than after. A supplier who cannot produce them is selling you a system you may not be able to deploy lawfully in scope, and finding that out during your own review is the expensive route.

How FISTA Solutions helps

FISTA Solutions builds high-risk systems so the evidence exists when it is needed: technical documentation maintained during development, data provenance recorded, evaluation results versioned and dated, logging and oversight designed before launch, and a documented position on what counts as substantial modification. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To prepare a system for assessment, message FISTA on WhatsApp, or read EU AI Act high-risk obligations.