Conformity Assessment, CE Marking, and Life After Launch

Conformity assessment is the procedure by which a provider demonstrates that a high-risk system meets the Articles 8 to 15 requirements, before it is placed on the market or put into service.

The concept is borrowed wholesale from EU product safety law rather than invented for AI, which is useful context: anyone who has taken a medical device or a piece of machinery to market recognises the whole apparatus, and the vocabulary of notified bodies, declarations of conformity and CE marking is the same vocabulary.

What is genuinely new is applying it to software whose behaviour is statistical rather than deterministic, and which can change after it ships. That mismatch produces most of the awkwardness in this part of the Act: a conformity assessment is a point-in-time judgement about a system that may not stay the same.

The Act's answer is the substantial modification concept, which forces reassessment when the system changes in ways that matter, and post-market monitoring, which keeps the provider looking. Both are covered below.

One clarification first: this is a provider obligation. A deployer of a purchased high-risk system does not carry out conformity assessment.

Article 43 routes systems to one of two procedures, and the routing is more favourable than most providers expect.

For high-risk systems in points 2 to 8 of Annex III, which is everything except biometrics, providers follow the conformity assessment procedure based on internal control set out in Annex VI. That procedure does not provide for the involvement of a notified body.

That is the important sentence. Recruitment systems, credit scoring, education tools, worker management, essential services: all self-assessed. There is no external certification gate, and providers who budgeted for one have budgeted for something that does not exist in their case.

For point 1 of Annex III, biometrics, the position differs. Where the provider has applied harmonised standards, or where they exist and were applied, the provider may choose between internal control and the Annex VII procedure involving a notified body's assessment of the quality management system and the technical documentation. Where harmonised standards were not applied, or exist only in part, the notified body route is required.

Annex I systems follow the conformity assessment procedure of the relevant sectoral product legislation, with the AI requirements folded into it, so a medical device runs through its existing medical device route.

The Commission is empowered to adopt delegated acts moving points 2 to 8 into the notified body regime, taking into account how effective internal control proves and whether notified body capacity is adequate. So the current position is favourable rather than permanent.

Self-assessment sounds lighter than it is. The Annex VI procedure requires the provider to verify three things.

That the established quality management system complies with Article 17.

That the technical documentation demonstrates compliance with the Articles 8 to 15 requirements, examined against those requirements.

And that the design and development process, and the post-market monitoring, are consistent with what the technical documentation describes.

No external party checks any of this before the system ships. What happens instead is that a national market surveillance authority can demand the documentation afterwards, and the assessment is then examined with the benefit of knowing what went wrong.

Two consequences worth internalising.

The absence of a gate is not the absence of scrutiny. It relocates scrutiny to a moment when the reviewer is already concerned, which is a worse moment to be discovered underprepared.

And internal control rewards genuine internal separation. Someone other than the development team should perform the verification, because a team assessing its own work against requirements it interpreted is not performing a check. The Act does not prescribe this; ordinary control design does.

A notified body is an independent conformity assessment organisation designated by a Member State's notifying authority and notified to the Commission, competent to assess against a specific scope.

Where the Annex VII route applies, the notified body assesses the quality management system and examines the technical documentation, and issues a certificate where satisfied. Certificates are time-limited and subject to periodic surveillance, so the relationship continues rather than ending at issuance.

One provision surprises people: where a high-risk system is intended to be put into service by law enforcement, immigration or asylum authorities, the market surveillance authority itself acts as the notified body, keeping that assessment inside the public sector rather than with a commercial body.

The practical constraint on this whole route is capacity. Designating notified bodies competent to assess AI systems is slow, since the designating authority must satisfy itself the body has the technical competence, and that competence is scarce. Availability of adequate notified body capacity is one of the factors the Commission must weigh before extending the notified body requirement to other Annex III points, which is a candid acknowledgment of the constraint.

For a provider of a biometric system needing this route, engage early. Capacity is the binding constraint, not your readiness.

The sequence from a classified system to a lawfully placed one.

The requirements work comes first, since conformity assessment assesses against it and there is nothing to assess otherwise.

The technical documentation and quality management system are the artefacts the assessment examines.

Then the procedure, routed by the classification: internal control for most Annex III points, notified body involvement for biometrics without harmonised standards, sectoral procedure for Annex I.

On success, the provider draws up the EU declaration of conformity, affixes the CE marking, and registers the system in the EU database. Only then may it be placed on the market.

After launch the obligations continue rather than stopping, which is the part providers coming from a software background find least familiar.

Three closing acts, each with a distinct function.

The EU declaration of conformity is drawn up by the provider, in writing, and kept for ten years after the system is placed on the market or put into service, available to national authorities. By drawing it up, the provider assumes responsibility for compliance. Where a system is subject to other Union legislation also requiring a declaration, a single declaration covering all applicable acts is drawn up.

The CE marking is affixed visibly, legibly and indelibly, and for digital-only systems it may be affixed digitally, provided it is easily accessible. Where a notified body was involved, its identification number follows the marking. The CE marking is a claim addressed to the market that the product conforms, and affixing it without the underlying work is a distinct kind of exposure.

Registration in the EU database happens before placing on the market, and it is public. The point covered in the previous cursus bears repeating here: a provider relying on the Article 6(3) derogation to conclude an Annex III system is not high-risk still registers. The derogation removes the requirements, not the visibility.

Together these three convert an internal judgement into a public, attributable claim, which is the mechanism by which self-assessment retains some discipline.

A conformity assessment describes a system at a point in time. The substantial modification concept is what keeps that description honest as the system evolves.

A substantial modification is a change not foreseen or planned in the provider's initial conformity assessment, which affects compliance with the Articles 8 to 15 requirements, or results in a modification to the intended purpose. Where one occurs, the system must undergo a new conformity assessment.

One provision matters greatly for machine learning: changes to a high-risk system that the provider pre-determined and included in the initial conformity assessment, including continued learning within predetermined bounds, do not constitute a substantial modification. So a model designed to retrain within a documented envelope, and assessed on that basis, can retrain without triggering reassessment. A model retrained outside anything the assessment anticipated cannot.

The design implication is significant and often missed: define the change envelope in the initial assessment as generously as you can honestly defend. Retraining cadence, data refresh, threshold adjustment, feature changes. Whatever is foreseen and assessed does not trigger a new assessment. Whatever is not, does.

Substantial modification also interacts with grandfathering. A system placed on the market before the applicable high-risk date escapes the requirements unless substantially modified afterwards, so for grandfathered systems the concept determines whether the whole regime switches on.

Article 72 requires providers to establish and document a post-market monitoring system proportionate to the nature of the AI technologies and the risks of the high-risk system.

The system actively and systematically collects, documents and analyses relevant data on the performance of high-risk systems throughout their lifetime, which may be provided by deployers or collected through other sources, and allows the provider to evaluate continuous compliance with the requirements. Where relevant, it covers interaction with other AI systems. A post-market monitoring plan is part of the technical documentation.

For systems already covered by sectoral Union legislation with equivalent monitoring, the AI-specific elements are integrated into that existing system rather than duplicated.

The substantive point for a provider is that post-market monitoring is where the statistical nature of these systems is finally acknowledged. A conformity assessment establishes performance at a moment on a particular distribution. Real use drifts away from that distribution, and only field data reveals it.

Which makes the deployer relationship structurally important. Deployers see the system working on real inputs and are obliged to inform the provider of risks and serious incidents. A provider with no channel for that information has a monitoring system that monitors nothing, and the contract is where the channel is built.

Article 73 requires providers of high-risk systems placed on the Union market to report serious incidents to the market surveillance authorities of the Member State where the incident occurred.

The deadlines are tiered by severity.

The general rule: the report is made immediately after the provider has established a causal link between the AI system and the serious incident, or the reasonable likelihood of such a link, and in any event not later than 15 days after becoming aware of it.

Where the incident is a widespread infringement, or a serious and irreversible disruption of critical infrastructure, the deadline is 2 days.

Where the incident involved the death of a person, the deadline is 10 days.

An initial incomplete report may be submitted where necessary to meet the deadline, with a complete report following.

Three operational implications. The clock starts on awareness, not on confirmation, so an internal escalation route that loses a day is spending a meaningful fraction of a 2-day deadline. Deployers must inform the provider without undue delay, and their internal recognition of an incident is the practical start of the chain. And failure to report is itself an infringement carrying the middle penalty tier, up to 15 million euros or 3 percent of worldwide annual turnover.

Work out which tier applies before an incident. Making that determination while the deadline runs is how the 2-day cases get missed.

With Annex III standalone systems now due on 2 December 2027 and Annex I embedded systems on 2 August 2028, the work has room. Spending it well means front-loading what is slow and cheap and deferring what is fast and expensive.

Slow and cheap, do now: classification, and the documented reasoning behind it. Data governance work, because assembling representative data and examining it for bias has the longest lead time of anything in the Act and cannot be compressed. Deciding the change envelope you will declare in the conformity assessment, since that shapes the architecture.

Medium, start soon: the quality management system, which is the largest single obligation for an organisation without an existing ISO-style system. Establishing the deployer feedback channel that post-market monitoring depends on.

Fast, but dependent on everything above: technical documentation assembly, the conformity assessment itself, declaration, marking and registration.

And two things to settle regardless of timeline: whether a grandfathering position applies to any system you already run, with a documented baseline of what that system was at the cut-off; and your serious incident escalation route, since the reporting deadlines do not wait for a compliance programme to mature.

The honest summary of this cursus: classification decides almost everything, most Annex III systems are self-assessed rather than externally certified, and the obligations that persist after launch are the ones a software organisation is least structurally prepared to carry.