AI Conformity Assessment Framework: CE Marking and EU AI Act Article 43

A conformity assessment is the procedural gate between "we built this AI system" and "we can sell it in the European Union." For high-risk AI systems under the EU AI Act, it is a structured, documented, signed-off verification that the system meets the requirements of Articles 9 through 15 — risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, robustness, and cybersecurity.

It is not a check-the-box exercise. The conformity assessment is the document that travels with the system across its full ten-year retention horizon. When a market surveillance authority opens an investigation, the conformity assessment is the first document they read. When a deployer sues a provider over a faulty system, the conformity assessment is the first document discoverable in litigation.

This article walks the framework end-to-end. The two assessment pathways under Article 43, the technical documentation that Annex IV requires, the role of notified bodies, the CE marking declaration of conformity, and the procedural steps from "system in development" to "system on the market" with the right paperwork in the right order.

Companion reading: /blog/ai-act-compliance-software-guide, /blog/high-risk-ai-systems-checklist, /blog/ai-audit-trail-implementation-guide, /glossary/ai-conformity-assessment.

What Is an AI Conformity Assessment?

A conformity assessment is the process by which the provider (the entity that develops or has developed an AI system and places it on the EU market under its own name or trademark — Article 3(3)) verifies and documents that a high-risk AI system meets the Act's requirements before market placement.

Three things distinguish an AI conformity assessment from analogous regimes (CE marking for machinery, MDR for medical devices, GDPR's DPIA):

1. The unit is the AI system, not the product. A high-risk AI system embedded in a non-AI product is assessed separately. A general-purpose AI model is not assessed as a high-risk system unless it is integrated into one (then the assessment burden falls on the system provider, with provider obligations under Article 53 binding the model provider).

2. It is mandatory pre-market. Unlike GDPR's DPIA (which is conditional and remediable), the conformity assessment is a precondition for market access for high-risk systems. Without a complete assessment and a signed EU Declaration of Conformity, the system cannot lawfully be placed on the market or put into service in the EU.

3. It is iterative across the lifecycle. A substantial modification — new training data, expanded intended purpose, changed risk classification — triggers a fresh assessment. The Act treats the assessment as a living document, not a one-time gate.

The definition lives in Article 43, with cross-references to Articles 9 through 15 (the substantive requirements being assessed), Article 11 and Annex IV (technical documentation), Article 47 (the EU Declaration of Conformity), Article 48 (CE marking), and Article 49 (registration in the EU database).

The Two Assessment Pathways

Article 43 provides two pathways into conformity. The choice is not optional — it is determined by the system's classification and use case.

Pathway 1: Internal Conformity Assessment (Article 43(2))

The default pathway for most Annex III high-risk systems. The provider conducts the assessment internally, applying harmonized standards adopted under Article 40 (or common specifications under Article 41 if standards are not yet available), produces the technical documentation, signs the EU Declaration of Conformity, affixes the CE marking, and proceeds to market.

Eligible systems: the majority of Annex III categories — biometrics (with exceptions for biometric identification), critical infrastructure, education, employment, essential services, law enforcement, migration, and justice — when the provider has applied harmonized standards or common specifications correctly. The exceptions are biometric identification (specifically Annex III.1(a) — remote biometric identification, biometric categorization based on sensitive characteristics, emotion recognition), which is routed to Pathway 2.

Procedural lift: the provider builds the technical documentation, runs the testing and evaluation under Article 9, ensures Articles 10 through 15 are met, and signs. No external body is involved. The complete file is retained for ten years post-market and made available to authorities on request (Article 18).

Strengths: procedurally lighter than third-party assessment. No queue waiting for a notified body. No notified-body fee. Faster time to market.

Weaknesses: the provider carries 100% of the assessment defensibility risk. If the technical documentation is later found insufficient, the provider faces the Article 99 fine regime — up to €15 million or 3% of global turnover for general non-conformity by providers.

Pathway 2: Third-Party Conformity Assessment (Article 43(1) and Article 43(3))

Required for two categories: (a) AI systems used as safety components in regulated products under Annex I (where the existing sectoral conformity-assessment regime governs and the AI Act assessment integrates with it under Article 43(3)); and (b) biometric identification systems and certain other Annex III.1(a) categories where third-party validation is mandated.

Procedural lift: the provider engages a notified body — an independent conformity-assessment body accredited by a national authority and listed in the EU's NANDO database. The notified body conducts a documentary review of the technical documentation, may conduct on-site audits, may sample test the system, and issues an EU technical documentation assessment certificate or an EU quality management system assessment certificate. The provider then signs the EU Declaration of Conformity referencing the certificate.

Strengths: the notified body's certificate is the strongest defensibility evidence available. In a market surveillance dispute, "we engaged X notified body, they reviewed the file, here is the certificate" is a defense most internal documentation cannot match.

Weaknesses: longer timelines (notified-body queues can stretch to 9–18 months for complex systems), higher cost (€50K–€500K depending on system complexity), and a more invasive process — the notified body may inspect facilities, interview staff, and request operational logs.

Article 43 Selection Decision Tree

The harmonized standards point is consequential. As of April 2026, the AI Act harmonized standards are still being finalized by CEN-CENELEC (JTC 21) and ISO/IEC. The expectation is that ISO/IEC 42001:2024 (AI management systems), ISO/IEC 23894:2023 (AI risk management), ISO/IEC 5259 series (AI data quality), and ISO/IEC 24028 (AI trustworthiness) will form the substrate. Until they are formally adopted, Pathway 1 providers must apply common specifications under Article 41, which leaves more interpretive room and weaker defensibility.

The Annex IV Technical Documentation

Whichever pathway you take, the file at the center of the assessment is the technical documentation defined in Article 11 and detailed in Annex IV. The Act prescribes the structure. The provider populates it.

The required sections, in order:

1. General description of the AI system. Intended purpose, name and version of the system, the provider's identity, hardware and software interfaces, deployment forms (cloud, on-premise, embedded), and instructions for the deployer.

2. Detailed description of the elements of the AI system. The methods and steps for development, including reliance on pre-trained models or third-party tools; the design specifications; the relevant input data; the human oversight measures and verifiable interfaces enabling those measures; the technical solutions adopted to ensure continuous compliance.

3. Detailed information about the monitoring, functioning, and control of the AI system. Performance metrics, validation procedures, the type of input/output data, training/validation/testing datasets, the data management practices, and the limits of expected performance.

4. The risk management system per Article 9. A structured representation of the risk management process throughout the lifecycle.

5. A description of any change made to the system through its lifecycle. The change log that distinguishes substantial from non-substantial modifications.

6. List of harmonized standards applied (or common specifications). Including any partial application and the rationale.

7. A copy of the EU Declaration of Conformity. Signed.

8. A description of the post-market monitoring system per Article 72. How the provider collects performance data after market placement.

The technical file is built incrementally during development. Building it after the fact — at the eve of market placement — is the failure mode that consumes most of the procedural time. The mature pattern is to populate Annex IV sections as engineering milestones are reached, not as a documentation sprint.

For Knowlee, the Annex IV-equivalent is AI-SYSTEMS-INVENTORY.md (per-system records covering general description, intended purpose, risk classification, oversight) plus TECHNICAL-COMPLIANCE-MAP.md (the cross-reference between Articles 9–15 and the codebase implementation). Building the file at the runtime layer means that when a system needs a formal Annex IV file, the assembly step is a generation, not an excavation.

The Procedural Steps: From Development to Market

The procedural sequence for a high-risk AI system, from a clean-sheet start to market placement under Pathway 1 (internal assessment):

Step 1 — Classification (Articles 6, 7)

Establish that the system is high-risk under Article 6 and identify the specific Annex III sub-category. Document the classification with rationale. If you claim the Article 6(3) procedural-task exemption, document the rationale and prepare the Article 49 notification.

Step 2 — Risk management system setup (Article 9)

Establish the risk management process for the system. Identify hazards. Estimate risks. Apply mitigations. Document residual risk. This is iterative — it begins at design and continues through retirement.

Step 3 — Data and data governance (Article 10)

Define training, validation, and test datasets. Document provenance, processing, bias evaluation. Justify the GDPR lawful basis where personal data is involved.

Step 4 — Build the system with Articles 11–15 in mind

Implement automatic logging (Article 12). Provide instructions for use (Article 13). Design human oversight controls (Article 14). Demonstrate accuracy, robustness, and cybersecurity (Article 15). The pattern is "compliance by design" — the technical features are built into the system, not added at audit.

Step 5 — Build the technical documentation (Article 11, Annex IV)

Populate the eight Annex IV sections. The file should be substantively complete before you formally start the assessment.

Step 6 — Establish the quality management system (Article 17)

The provider's QMS — not specific to one system but covering the AI program — must be in place. ISO/IEC 42001:2024 alignment is the recognized substrate.

Step 7 — Conduct the conformity assessment (Article 43)

For Pathway 1: review the technical documentation against Articles 9–15 and the harmonized standards (or common specifications). Identify and close any gaps. Run the formal assessment as an internal review with sign-off from the AI compliance officer or equivalent.

For Pathway 2: engage a notified body. Submit the technical documentation. Cooperate with the documentary review and any on-site audit. Receive the certificate.

Step 8 — Sign the EU Declaration of Conformity (Article 47)

A formal document signed by the provider (or authorized representative for non-EU providers under Article 22) declaring that the system meets the Act's requirements. The Declaration must include the system's identity, the provider's identity, the harmonized standards applied, and the certificate number for Pathway 2 systems.

Step 9 — Affix the CE marking (Article 48)

Where the system has a physical form. For purely digital systems, the CE marking is electronic and accompanies the system in its documentation and instructions for use.

Step 10 — Register in the EU AI database (Article 49)

For Annex III high-risk systems, before market placement. The registration is public-facing and serves as the notification to authorities and the public that the system exists and has been classified.

Step 11 — Post-market monitoring (Articles 72, 73)

After market placement, the provider implements the post-market monitoring plan from the Annex IV documentation. Serious incidents are reported under Article 73. Substantial modifications trigger a fresh assessment cycle.

The full sequence is on the order of 6–12 months for a system being built compliance-by-design, longer for systems being retrofitted to compliance after development.

The Role of Notified Bodies

Notified bodies are independent conformity-assessment organizations accredited by a national authority and notified to the European Commission under Article 31. They are listed in the NANDO database.

Their role under Pathway 2 is to provide an independent assessment of the technical documentation and, where applicable, the quality management system. They do not certify ongoing operation — that is post-market monitoring, the provider's responsibility under Article 72. They certify the assessment at a point in time.

A notified body's mandate covers two assessment modules under Annex VII:

• Annex VII.A — Assessment based on internal control plus assessment of the technical documentation. The provider operates an internal control regime; the notified body reviews the technical documentation.
• Annex VII.B — Assessment based on quality management system plus assessment of the technical documentation. Used when the provider's QMS is itself assessed and certified by the notified body, broadening the scope of the assessment.

Engaging a notified body is a competitive process. The notified body cannot have a conflict of interest with the provider, must apply uniform criteria, and must report its assessments to the relevant authorities. The provider chooses among the notified bodies competent for the relevant Annex III category.

The expected cost range is €50K–€500K depending on system complexity, with timelines of 6–18 months for a first assessment. Re-assessments after substantial modifications are typically faster and cheaper, drawing on the prior file.

Substantial Modification and the Re-Assessment Trigger

Article 43(4) defines what triggers a fresh conformity assessment after market placement: a substantial modification, defined in Article 3(23) as a change that affects compliance with the Act's requirements OR the intended purpose for which the system was assessed.

In practice, the modifications that trigger re-assessment include:

• A new training dataset category (e.g., adding facial-image data to a system previously trained on text only).
• An expanded intended purpose (e.g., extending a credit-scoring system to a new product line or geography).
• A change in the high-risk classification (e.g., a system reclassified from limited-risk to high-risk after a feature change).
• A material change in the model architecture (e.g., switching from a fine-tuned LLM to a different base model with different capabilities).

Modifications that typically do NOT trigger re-assessment:

• UI copy changes.
• Performance optimization that does not change behavior.
• Dependency upgrades that do not change the model.
• Backwards-compatible API changes.

The boundary is judgmental. The provider's change-management policy must define the criteria, document each change against the criteria, and trigger re-assessment when the policy says to. Auditors will read the policy. Disagreement between the policy and the change log is itself a finding.

Common Pitfalls

Pitfall 1: Treating the conformity assessment as a launch milestone, not a lifecycle commitment. The assessment binds for the system's full lifetime. Ten-year retention plus continuous post-market monitoring plus re-assessment on substantial modifications is the operational reality.

Pitfall 2: Underestimating the technical documentation effort. Annex IV is substantial. Providers that try to write it in the weeks before market placement consistently miss elements, run out of time, and ship with weak documentation that fails first audit.

Pitfall 3: Mistaking ISO/IEC 42001 certification for a conformity assessment. They are different things. 42001 is a management-system certification covering the provider's AI program. The conformity assessment is per-system. 42001 helps — it establishes the QMS that Article 17 requires, it provides a presumption-of-conformity substrate for some controls, and it accelerates Pathway 2 assessments — but it does not replace the conformity assessment.

Pitfall 4: Not coordinating with sectoral regimes for Annex I products. A medical device with an embedded AI safety component is assessed under MDR plus AI Act simultaneously. The two procedures must align, and the technical documentation must satisfy both. Treating them as separate workstreams is a coordination failure.

Pitfall 5: Skipping the EU database registration. Article 49 requires registration before market placement. Skipping it creates a non-conformity that cannot be remediated retroactively — the system has been placed on the market without registration, which is itself a separate Article 99 fine trigger.

FAQ

What is an AI conformity assessment?

A conformity assessment is the structured, documented verification that a high-risk AI system meets the requirements of Articles 9–15 of the EU AI Act before being placed on the EU market. It is mandatory for high-risk systems and culminates in an EU Declaration of Conformity and CE marking.

Who is responsible for the conformity assessment?

The provider — the entity that develops the system or has it developed and places it on the market under its own name or trademark. Under Article 22, providers established outside the EU must designate an authorized representative in the EU before market placement.

What is the difference between internal and third-party conformity assessment?

Internal assessment (Article 43(2)) is conducted by the provider itself, applying harmonized standards, with no external body. Third-party assessment (Article 43(1) and 43(3)) involves a notified body conducting documentary review and, where applicable, on-site audit. Most Annex III systems use internal assessment; biometric identification systems and AI safety components in regulated products use third-party.

How long does a conformity assessment take?

For a system built compliance-by-design under Pathway 1, the formal assessment phase is typically 4–8 weeks once the technical documentation is complete. Building the technical documentation is the longer phase — often 3–6 months. Pathway 2 assessments add 6–18 months for the notified-body queue and review.

What is included in the EU Declaration of Conformity?

The Declaration must include: the system's identity (name, version, type), the provider's identity, the authorized representative's identity if applicable, the Annex III categorization, the harmonized standards or common specifications applied, the notified-body certificate number for Pathway 2, the date and place of issue, and a signature by an authorized natural person of the provider.

Does CE marking apply to digital-only AI systems?

The CE marking requirement under Article 48 applies to all high-risk systems, but the form differs. For systems with a physical component, the marking is affixed physically. For purely digital systems, the marking is electronic and is included in the system's digital identity (typically a manifest, an "About" screen, or accompanying documentation). The substantive obligation is the same — the visibility differs.

What is Annex IV?

Annex IV defines the structure of the technical documentation required under Article 11. Eight sections covering general description, system elements, monitoring/functioning/control, the Article 9 risk management system, the change log, harmonized standards applied, the EU Declaration of Conformity, and the post-market monitoring plan.

What happens during a notified-body assessment?

The notified body reviews the technical documentation against the requirements, may request clarifications, may conduct on-site audits or interviews, and may sample test the system. The output is a certificate (or a refusal with grounds). The provider's cooperation, the document quality, and the system's actual conformity all influence the timeline and outcome.

How does the conformity assessment interact with ISO/IEC 42001 certification?

ISO/IEC 42001:2024 certifies the provider's AI management system — the program-level QMS. Conformity assessment certifies a specific high-risk AI system. 42001 alignment provides a substrate: the QMS controls satisfy Article 17, and the management-system maturity creates a presumption of conformity for several Articles when the harmonized standards are formally adopted. 42001 is not a substitute for conformity assessment. It accelerates it.

What is a substantial modification?

Defined in Article 3(23): a change to a high-risk AI system that affects its compliance with the Act's requirements, or that changes the intended purpose for which it was originally assessed. Substantial modifications trigger a fresh conformity assessment. Non-substantial modifications are logged in the change register but do not trigger reassessment.

Next Steps

1. Determine your pathway. Use the Article 43 selection table to identify whether your system is Pathway 1 (internal) or Pathway 2 (third-party). For Pathway 2 systems, begin notified-body discussions early — queue times can be material.
2. Build the Annex IV technical documentation incrementally. The mature pattern is populating sections as engineering milestones are reached, not at the eve of market placement.
3. Score yourself against the 25-point high-risk checklist. The 25 controls map directly to the substantive requirements being assessed.
4. Evaluate whether automated AI governance (/blog/automated-ai-governance-platform) can produce the technical documentation as a runtime artifact rather than a manual sprint.
5. For the cross-cutting platform view, the AI Act Compliance Software Guide covers vendor selection. For the operational layer, the Audit Trail Implementation Guide covers the Article 12 evidence the assessment will require.

Conformity assessment is not the gate at the end of development. It is the framework that organizes development from day one. Treat it that way and the procedural step is a generation. Treat it as a milestone and the procedural step is an excavation.