Conformity assessment for high-risk AI systems

If your organisation develops or deploys an AI system classified as high-risk, there is one procedure you cannot skip: the conformity assessment. It is the process by which you demonstrate that the system meets the requirements of the EU AI Act before placing it on the market. In the regulated projects I lead, preparing it well makes the difference between launching on time or getting blocked.

What conformity assessment is

The conformity assessment is the process that verifies that a high-risk AI system meets all the requirements demanded of it by the European regulation. Depending on the case, it may be a self-assessment by the provider or require the intervention of a notified body. The result, when positive, enables the CE marking and registration in the European register.

It is not an improvised final exam: it is the culmination of governance that must have accompanied the system throughout its life cycle.

The requirements that are assessed

Risk management and data

It verifies that a risk management system exists and that the training data is adequate, representative and well governed. Here the inventory of AI assets and data quality are the basis on which everything rests.

Technical documentation and transparency

The system must have complete technical documentation, activity logs and sufficient transparency for users to understand its capabilities and limits. Without this documentation, the conformity assessment cannot be passed.

Human oversight and robustness

It is checked that there is effective human oversight and that the system is robust, accurate and secure. Human oversight is one of the pillars I review most, because it is where many projects fail by delegating too much to automation.

How I prepare it in practice

I work on conformity from the design stage, not at the end. Keeping all the evidence alive (risks, data, controls, documentation) is what turns the assessment into an orderly procedure. That continuous management of conformity is exactly what underpins the compliance tool I develop, because reconstructing the evidence at the last minute is unfeasible. It is always worth cross-referencing it with the EU AI Act checklist.

Internal or third-party conformity: how to choose

A recurring question is whether the conformity assessment can be done internally or requires a notified body. The answer depends on the type of system and on whether there are harmonised standards that cover it. Many high-risk systems will be able to self-assess if those standards are followed, while others will require the intervention of a third party. My advice is to clarify this question at the start of the project, because it shapes the timeline and the budget: a third-party assessment involves deadlines and costs that are worth anticipating.

Whatever the route, the underlying work is the same: having the complete technical documentation, the up-to-date risk analysis and the tests that demonstrate the system does what it says and does so safely. Whoever arrives with that in order passes the assessment with relative calm; whoever improvises, suffers.

Safety barriers as evidence

One aspect that assessors scrutinise closely in generative systems is how the model’s behaviour is controlled. It is not enough to say it is safe: you have to demonstrate what barriers prevent harmful outputs and how they are tested. That is why I always link the conformity assessment with the design of guardrails for generative AI, which are, in practice, much of the technical evidence that underpins the robustness of the system.

Documenting those barriers, how they were designed, what edge cases they cover and how they are monitored, turns a generic claim of safety into concrete proof. And it is precisely concrete proof that makes a conformity assessment advance without friction.

My conclusion is that the conformity assessment is not a final exam that you pass by cramming the night before. It is the reflection of continuous work on governance, risks and documentation throughout the system’s entire life cycle. Organisations that understand it this way do not fear the assessment: they experience it as the confirmation of something they were already doing well.

What many companies discover too late is that the conformity assessment is not a final exam, but the last snapshot of a process that should have been documented from the start. If you have kept an orderly record of the data, the tests and the design decisions throughout the project, the assessment consists of organising what you already have. If not, it becomes a forced reconstruction that almost always reveals gaps impossible to plug at the last minute. That is why I insist that compliance is built during development, not when closing it.

It is also worth understanding which assessment route applies to your case. Some systems can self-assess under the provider’s responsibility, while others require the intervention of an independent body. Identifying that route as early as possible avoids surprises in timeline and cost, because the availability of external assessors is not immediate and can shape your market launch date.

Conclusion: conformity is built, not improvised

The conformity assessment of a high-risk AI system is not a last-minute obstacle, but the reflection of how you have governed the system from the start. Whoever integrates the requirements into the design arrives at the assessment with everything ready; whoever leaves them for the end discovers too late that pieces are missing that are hard to manufacture in a hurry.

Frequently asked questions about AI conformity assessment