EU AI Act Conformity Assessment: Self-Assessment vs Notified Body

Before a high-risk AI system can be placed on the EU market, it must undergo a conformity assessment — a structured process that demonstrates the system meets the EU AI Act's requirements. Getting this process wrong, or starting too late, is one of the most common strategic errors enterprise compliance teams make.

This guide explains when each route applies, what the assessment requires, and why the supporting documentation is the highest-stakes deliverable in your compliance programme.

What Is a Conformity Assessment?

A conformity assessment is the process by which a provider of a high-risk AI system verifies that the system complies with the requirements set out in Chapter III, Section 2 of the EU AI Act — covering risk management, data governance, technical documentation, logging, transparency, human oversight, and accuracy.

The result of a successful conformity assessment is a declaration of conformity and the right to affix the CE mark to the AI system. The declaration of conformity is the legal assertion that the system meets the Act's requirements. The CE mark makes that assertion visible in the market.

Conformity assessment must be completed before the system is placed on the market or put into service. There is no post-deployment grace period for the assessment itself.

The Self-Assessment Route

For the majority of high-risk AI systems, the EU AI Act permits a self-assessment — formally called "internal control" — under Annex VI. This means the provider conducts the conformity assessment without the involvement of a third-party notified body.

Self-assessment is not a light-touch process. It requires the provider to:

• Establish and maintain a quality management system covering the entire AI system lifecycle
• Complete and maintain full technical documentation as specified in Annex IV
• Apply the harmonised standards or common specifications that cover the requirements of the Act
• Retain all supporting documentation for ten years from the date the system is placed on the market
• Draw up an EU declaration of conformity for each high-risk AI system

The self-assessment route sounds straightforward, but in practice its demands are significant. The technical documentation alone — covering the AI system's design, development, training data, risk management, and operational monitoring architecture — is a substantial undertaking. And the documentation must reflect reality, not aspiration: a conformity assessment based on documentation that does not accurately describe the system's logging infrastructure, for example, creates legal exposure rather than legal protection.

The Notified Body Route

For a narrower category of high-risk AI systems, third-party assessment by a notified body is mandatory. The EU AI Act requires involvement of a notified body for:

• AI systems used for remote biometric identification (with limited exceptions)
• AI systems that are safety components of products covered by Union harmonisation legislation that already require third-party assessment

Notified bodies are organisations designated by EU member states to conduct conformity assessments. They must be accredited and must apply standardised assessment procedures.

The practical challenge with notified body assessment is lead time. Notified bodies for AI are still being designated across EU member states, and capacity is limited relative to demand. Organisations that will require notified body assessment should begin engagement early — not in the months before the December 2027 deadline, but now.

A notified body assessment that begins in late 2027 will not be completed in late 2027. Build notified body engagement into your 2025–2026 compliance timeline.

The Documentation That Makes or Breaks the Assessment

Whether you use the self-assessment or notified body route, the conformity assessment stands or falls on your technical documentation. Annex IV specifies fourteen categories of information that must be included, including:

• A general description of the AI system — its intended purpose, the persons and entities it affects, how it interacts with hardware and other systems
• A description of the design specifications, including how the system was trained and how it generates outputs
• A description of the data governance practices: data sources, pre-processing, known limitations, biases
• A description of the risk management system — the process used to identify, evaluate, and mitigate risks
• A description of the monitoring, functioning, and control measures — including the automatic logging capability required by Article 12
• The validation and testing procedures and results

The logging architecture section of the technical documentation is where many organisations will face their most significant challenge. Article 12 requires that high-risk AI systems automatically generate logs of their operation, sufficient to enable post-hoc monitoring. The technical documentation must describe this capability in sufficient detail that an assessor can verify it works as claimed.

If your logging infrastructure cannot generate a tamper-evident, sequentially-chained record of AI decisions, inputs, and human overrides, the Article 12 section of your technical documentation will be the weakest section — and assessors will find it.

Building the evidence infrastructure first, running it for sufficient time to have a documented operational history, and then completing the technical documentation is the correct order of operations. The alternative — completing documentation that describes a logging capability you plan to build — creates legal risk and assessment risk simultaneously.