A CE marking is not a promise of AI quality

Few symbols in the European product environment are interpreted as broadly as CE. Product slides turn it into a quality seal, a safety certificate or official approval. For AI systems, that shortcut is particularly risky. Legal market access, technical performance and responsible operation are three different questions.

The EU AI Act's conformity logic connects classification, requirements, evidence, assessment, declaration, marking, registration and monitoring. The visible mark is the endpoint of a process, not a substitute for it. Understanding CE therefore means being able to read the invisible evidence chain behind it.

Classification comes before the mark

Every conformity discussion starts with the system, role and intended purpose. Not every AI application is a high-risk AI system. Not every organisation is automatically the provider. A technical or commercial change may alter the legal allocation of responsibility.

A defensible classification records the system boundary, intended purpose, users, affected people, decision influence, product and process integration, and the role of every actor. It also records assumptions and unresolved questions. A model name is insufficient: the same foundation model may power an informal writing aid or a system with material influence over decisions.

Classification is versioned. Expanding the purpose, placing the system on the market under another name or substantially modifying it may require a new analysis. The classification record therefore includes review triggers rather than acting as a permanent label.

Provider is a responsibility role

Provider does not simply mean the developer of a foundation model. The relevant question is who develops or has an AI system developed and places it on the market or puts it into service under its own name or trademark. Integrators and product companies can move into this role in an AI value chain.

Article 25 addresses situations including supply under one's own name or trademark, substantial modification and a change of intended purpose that makes a system high-risk. In those cases, pointing upstream is not enough. Agreements must provide the information, technical access and cooperation needed to perform the new duties while respecting intellectual property and trade secrets.

A RACI chart alone is weak. Accountable roles need decision rights, access to evidence, testing resources and the practical authority to stop release or operation.

Conformity assessment is a procedure, not one certificate

Article 43 provides different conformity-assessment routes. The applicable route depends on the system category and relevant legal conditions. A notified body is therefore neither universally required nor universally absent. Both „CE is merely self-declaration" and „CE always means independent certification" are unreliable claims.

Internal assessment is not self-exemption. Applicable requirements must be translated into controls, tested, reviewed and documented. Where a third party participates, its work does not remove the provider's responsibility. It assesses within a defined mandate and against a particular system and documentation baseline.

The first operational output is a Conformity Route Record: legal basis, system category, standards or specifications used, participating bodies, required artefacts, sequence and release criteria.

Self-assessment still requires evidence

A strong assessment is organised through a traceability matrix. Every applicable requirement receives an identifier and links to a system claim, technical or organisational control, test method, observed result, owner and deviation decision.

The chain is Requirement → Claim → Control → Test → Result → Decision. A missing link creates compliance theatre. A test without a requirement does not explain relevance. A policy without an operational signal does not prove implementation. A model benchmark without intended-purpose context says little about the complete AI system.

Negative evidence stays in the record. It must lead to a limitation, correction, accepted residual-risk decision or stop. How a team handles counter-evidence is a better maturity signal than the number of green cells in a checklist.

Technical documentation must describe the real system

A conformity file can look complete yet describe an idealised architecture. Documentation must match the configuration actually placed on the market or put into service: model and prompt versions, data sources, retrieval corpus, tools, thresholds, interfaces, oversight, logging, security measures and dependencies.

Every assessment therefore has a frozen Evidence Snapshot. Hashes, artefact identifiers and validity periods connect claims to a reproducible state. Dynamic components require controlled change ranges and retest triggers; a screenshot cannot make them stable.

The dossier is best understood as a navigable graph, not a folder of PDFs. From a deployed version, an assessor must be able to reach purpose, requirement, control, test, outcome, release decision and later change.

The EU declaration of conformity assigns responsibility

Article 47 requires an EU declaration of conformity for the relevant system and requires it to be kept up to date. Through the declaration, the provider assumes responsibility for meeting applicable requirements. It identifies the system, provider, relevant legislation and other required information; it is not marketing copy.

The declaration summarises earlier evidence work. It cannot cure missing tests, inconsistent versions or unresolved deviations. Before signature, a formal Readiness Review asks: Are system and scope unambiguous? Is every duty addressed? Do technical documentation, test status and released version match? Are deviations decision-ready? Is the signatory authorised and sufficiently informed?

CE is a precise but limited claim

Article 48 ties the CE marking to conformity of the high-risk AI system. Digital marking may be used for digital systems, subject to the applicable visibility and identification rules. The symbol communicates a legal conformity claim for a specific product or system.

It does not automatically establish:

• authority endorsement or authority execution of every test;

• participation of an independent body in every case;

• error-free operation, universal fitness or absence of risk;

• exceptional ethics, innovation or financial stability of the provider;

• coverage of every future modification or real-world use by the original assessment.

Those limits preserve the meaning of the mark. Trouble begins when sales language converts a bounded legal claim into a general promise of trust or excellence.

Registration is a separate control point

Article 49 provides registration duties in the EU database for relevant high-risk systems. Registration and CE marking are connected, but not interchangeable. A mark does not replace a database entry; an entry does not replace assessment.

A Registration Record captures system identity, accountable party, status, required fields, date, reference and update rules. Before publication, consistency and confidentiality need review. The submitted information must match the technical documentation and the version actually supplied.

Complex products may also fall under other European product regimes. Multiple procedures must not be compressed into one vague compliance claim. A Compliance Mapping records the subject, accountable actor, assessment route and evidence for each applicable regime.

Change can invalidate the claim

Systems do not remain still after market access. Models are replaced, tools receive new permissions, data sources change and customers use features in new processes. The assessed baseline may be left behind without a visible interface change.

A Change Gate therefore considers purpose, role, risk classification, requirements, tests, documentation, declaration, marking and registration together. Substantial modification and intended-purpose changes require particular attention. Rebranding or adopting another system under one's own name can also shift responsibility.

The release question is not merely „Does the build work?" It is „Does the existing conformity claim still hold for this build?" Until that question is resolved, release remains limited or blocked.

Market access does not end evidence work

Article 72 requires active and systematic post-market monitoring for high-risk AI systems throughout their lifetime. CE is therefore not a completion stamp. Operational data, complaints, incidents, drift and changes can confirm or contradict original assumptions.

Monitoring links each deployed version to signals and thresholds. When a signal affects a system claim, triage, corrective action and effectiveness verification follow. Serious issues may require limitation, disabling, withdrawal or further reporting. A conformity file that is not updated after launch gradually stops describing the living system.

Quality also goes further than conformity. A conforming system can still be less accurate, usable or efficient than an alternative. Quality management evaluates utility, robustness, fairness, maintainability and user experience against the intended purpose. Compliance sets boundaries; product quality determines fitness and value within them.

The promise test for product communication

Every claim using „certified", „authority-approved", „safe", „trusted" or „fully compliant" should be decomposed before publication. Which system? Which version? Which requirement? Which route? Which body? Which scope? Which date? Which exceptions?

If the answer cannot be evidenced, narrow the wording. Precise communication may state that conformity assessment was performed for a particular system, a declaration was issued and CE marking was affixed. It should not infer that every output is correct or every future use is permitted.

This discipline protects buyers, providers and advisers. It prevents a legally defined symbol from becoming an invented quality badge.

Method: CLASSIFY → EVIDENCE → ASSESS → DECLARE → REGISTER → MONITOR

CLASSIFY determines system, purpose, risk and roles. EVIDENCE links requirements to controls, tests and results. ASSESS follows the correct route and resolves deviations. DECLARE states the accountable conformity conclusion. REGISTER provides required market transparency. MONITOR checks whether the claim continues to hold under operation and change.

The order matters. Starting with the mark produces symbol management. Starting with classification and evidence produces defensible market access.

Worksheet: Build a Market-Access Evidence Map

1. Define system boundary, intended purpose, version and all actor roles.

2. Justify risk class and conformity route; mark uncertainties.

3. Select eight applicable requirements and link each to a control, test, result and owner.

4. Verify that technical documentation matches the actual product configuration.

5. Design a readiness review for declaration, marking and registration.

6. Simulate a model, purpose or trademark change and decide which steps repeat.

7. Draft an accurate product statement and remove every unsupported quality claim.

Reflection: Which claim about CE would you no longer use after this review? Which change could make today's conformity claim invalid tomorrow?

All materials to download — the topic overview and the worksheet:

Scope: This article explains a professional conformity and evidence model, not legal advice. Whether a system is high-risk, which procedure applies and which additional product, sectoral, data-protection, employment or national rules govern it must be assessed for the specific case. Editorial review date: 17 July 2026.