EU AI Act Art.16 CE Marking, EU Declaration of Conformity & Database Registration: The Provider's Step-by-Step Workflow for August 2026

Post #4 in the sota.io EU AI Act Art.16 Provider Obligations Series

Three actions stand between a compliant high-risk AI system and one that is legally placed on the EU market. The provider must draw up an EU Declaration of Conformity (Art.47), affix the CE marking (Art.48), and register the system in the EU database (Art.49). Art.16 ties all three together as explicit provider obligations — but the sequence matters, the content requirements are strict, and a mis-step in one invalidates the others.

This guide walks through each step in the order the regulation demands, explains what can go wrong, and provides implementation patterns that keep all three records in sync across system updates.

Why the sequence is not optional

Many providers treat CE marking as the final stamp at the end of a compliance project. That framing creates a structural problem: the CE marking can only be affixed after the EU Declaration of Conformity is drawn up, and the EU DoC can only be drawn up after the conformity assessment under Art.43 is completed.

The legal chain runs in one direction:

1. Design and build the high-risk AI system meeting Ch.III Sec.2 requirements (Art.9–15)
2. Complete conformity assessment under Art.43 — self-assessment for most Annex III systems, third-party NB audit for biometric systems and some critical infrastructure
3. Draw up the EU Declaration of Conformity under Art.47 — a formal document certifying the outcome of step 2
4. Affix CE marking under Art.48 — the physical/digital mark that references the EU DoC
5. Register in the EU database under Art.49 — upload the registration record, including a reference to the EU DoC and the CE marking

Starting CE marking discussions before the conformity assessment is complete is not illegal, but affixing the mark is. Providers who skip step 2 and proceed to step 4 expose themselves to market surveillance action under Art.74 once enforcement begins in August 2026.

Step 1: Completing the conformity assessment (Art.43 prerequisite)

The EU DoC cannot be signed until the conformity assessment is done. For the majority of high-risk AI systems listed in Annex III (excluding biometric systems and AI in critical infrastructure sub-categories that require notified body involvement), Art.43(2) permits providers to choose between two routes:

Route A — Internal conformity assessment (Annex VI): The provider self-assesses against the Ch.III Sec.2 requirements. This requires completed technical documentation per Annex IV, a functioning Quality Management System under Art.17, and documented testing results. The self-assessment is valid as long as the technical documentation and QMS are complete and no substantial modification occurs.

Route B — Third-party assessment (Annex VII): A designated notified body (NB) carries out the assessment. Mandatory for emotion recognition systems, real-time remote biometric identification systems, and AI systems listed in Annex III points 1(a) and 1(b) that are subject to additional requirements. CRA Notified Bodies began operations on 11 June 2026 — separate from AI Act NBs, but the operational model is similar.

What the conformity assessment record must document:

• Which Annex III category the system falls under
• Which route (A or B) was chosen and why
• Results of testing against each Art.9–15 requirement
• Date of assessment, version of the system assessed
• Reference to the Annex IV technical documentation version used

If you run Route B, the NB will issue a certificate. That certificate number must appear in the EU DoC.

Step 2: Drawing up the EU Declaration of Conformity (Art.47)

Art.47 defines the EU Declaration of Conformity as a formal document in which the provider declares that the high-risk AI system complies with the applicable requirements. The regulation specifies the required content at Art.47(2):

Mandatory elements of the EU DoC:

1. Provider name and address — the legal entity placing the system on the market, not the developer team name
2. Description of the AI system — name, version, intended purpose as stated in the Annex IV documentation
3. Declaration statement — that the AI system is in conformity with the regulation
4. Reference to the harmonised standards or common specifications applied — if the provider used harmonised standards per Art.40 to demonstrate compliance, they must be listed; if no harmonised standard covers the area, this section references the self-assessment approach
5. Where applicable: name and identification number of the notified body — and certificate number if a third-party assessment was done
6. Date of issue
7. Signature and name of the authorised signatory

Practical implementation — EU DoC as a versioned document:

The EU DoC is not a one-time form. When a substantial modification occurs under Art.6, the existing EU DoC is invalidated and a new conformity assessment must be completed before a new EU DoC can be issued. Building the EU DoC as a versioned, structured document (not a signed PDF filed in a folder) makes this workflow sustainable:

/compliance/
  eu-doc/
    v1.0-2026-07-15-eu-doc.pdf        ← initial release
    v1.0-2026-07-15-eu-doc-signed.pdf ← wet/digital signature version
    v1.1-2026-10-01-eu-doc.pdf        ← post-modification update
  conformity-assessment/
    v1.0-assessment-annex-vi.pdf
    v1.1-assessment-annex-vi.pdf

Link the EU DoC version to the system version in your software release pipeline. A system version bump that constitutes a substantial modification must trigger a new EU DoC before the new version is deployed.

EU DoC in SaaS and cloud-deployed AI:

For cloud-deployed high-risk AI systems, the "placing on the market" moment is the first time a deployer gains access. The EU DoC must exist at that point. For SaaS providers, this typically means the EU DoC must be ready before the first customer activation of a high-risk AI feature — not before the feature is in production, but before a deployer uses it.

Store the EU DoC at a stable, versioned URL accessible to deployers. Art.13(3)(a) requires providers to make sufficient information available in the instructions for use, which includes directing deployers to where the EU DoC can be accessed.

Step 3: Affixing the CE marking (Art.48)

The CE marking under Art.48 serves as a visible declaration that the provider has completed conformity assessment and drawn up the EU DoC. For a physical device, CE marking means the physical mark on the product. For software and AI systems, Art.48(3) permits CE marking on the documentation accompanying the system and in the information provided through the user interface.

What "affixing CE marking" means for a software AI system:

• Documentation: The marking appears on the system documentation, technical specifications, and user-facing instructions
• User interface: The marking may appear in the application (e.g., in an "About" or "Compliance" section)
• Website: The CE marking appears in the product listing or compliance section

CE marking format requirements:

The CE marking must use the form prescribed by EU product law — the stylised "CE" letters in the correct proportions. Providers cannot use a self-designed CE logo or a text-only "CE certified" label. The EU Commission provides the official CE marking vector artwork for download.

Common mistake — CE marking before conformity assessment:

The regulation is explicit: CE marking that does not accurately reflect the state of conformity is a compliance violation that national authorities can act on. This means:

• CE marking on a system for which the conformity assessment is incomplete = violation
• CE marking on a system that was substantially modified without a new conformity assessment = violation
• CE marking without a corresponding EU DoC = violation

Notified body certificate reference:

If the conformity assessment involved a notified body, Art.48(5) requires that the NB identification number appear alongside the CE marking. This number is assigned by the Commission when the NB is designated. For Route A (self-assessment), no NB number is required.

Step 4: Registering in the EU database (Art.49)

Art.49 requires providers of high-risk AI systems to register certain information in the EU database established under Art.71 before placing the system on the market. The database is maintained by the European Commission and provides a public registry of high-risk AI systems.

What must be registered (Annex VIII Part I):

1. Provider name and registration number (VAT or similar)
2. Name and address of authorised representative in the EU (if applicable)
3. Name and version number of the AI system
4. Description of the intended purpose, including Annex III category
5. Status of the system (on the market, withdrawn, recalled)
6. URL of the EU DoC (must be stable and accessible)
7. Technical documentation storage location reference
8. Name of harmonised standard(s) applied or common specifications
9. If applicable: notified body name, certificate number, and certificate status

Registration timing:

Registration must be completed before the system is placed on the market or put into service. For SaaS deployments, "before first deployer access" is the practical threshold. The database registration number becomes a reference point that providers are expected to include in communications with NCAs and during market surveillance checks.

Keeping the registration record current:

The registration must be updated when material information changes:

• New version of the system (if it constitutes a substantial modification and a new EU DoC was issued)
• Change in intended purpose
• Withdrawal or recall
• Change in NB certificate status (if applicable)

Failing to keep the registration current exposes the provider to enforcement under Art.74 and Art.99 penalties for non-compliance with registration obligations.

Infrastructure consideration — the registry runs on EU servers:

The EU AI Act database (EUDB) is operated by the Commission. Access is via an EU-managed portal. The data you submit to the registry is hosted on Commission infrastructure and subject to EU jurisdiction. The registration record references your EU DoC, which itself references your technical documentation. The chain of provenance from registry → EU DoC → technical documentation must be internally consistent.

If your technical documentation is stored in a cloud environment subject to the US CLOUD Act (AWS, Azure, GCP US-parent entities), a US order could compel disclosure of your conformity evidence without notification to EU authorities. Storing technical documentation on EU-jurisdiction infrastructure (Hetzner, OVHcloud, or a sovereign PaaS like sota.io) avoids this compliance chain disruption.

Step 5: Maintaining synchronisation across updates

The three documents (conformity assessment record, EU DoC, registration record) form a compliance triangle. A substantial modification to the AI system invalidates the triangle and requires rebuilding it:

Substantial modification detected
         ↓
Re-run conformity assessment (Art.43)
         ↓
Issue new EU DoC (Art.47) with new version number
         ↓
Update CE marking references to point to new EU DoC version
         ↓
Update EU database registration record (Art.49)
         ↓
Notify deployers of the new version (Art.16(k) + Art.13 update)

Automation pattern — compliance-as-code:

Build your release pipeline to fail if any of these steps are missing on a release tagged as a substantial modification:

# ci/compliance_gate.py
def check_release_compliance(release_tag: str, is_substantial_modification: bool):
    if not is_substantial_modification:
        return True  # Minor updates don't require new EU DoC
    
    checks = [
        check_conformity_assessment_exists(release_tag),
        check_eu_doc_version_matches_release(release_tag),
        check_ce_marking_docs_updated(release_tag),
        check_eudb_update_queued(release_tag),
    ]
    
    failed = [c for c in checks if not c["passed"]]
    if failed:
        raise ComplianceGateError(
            f"Release {release_tag} blocked: missing compliance artefacts: "
            + str([c["name"] for c in failed])
        )
    return True

The gate prevents deployment of a substantially modified system without completing the compliance triangle.

Checklist: CE marking, EU DoC, and database registration

Before first placement on market:

• Conformity assessment completed and documented (Annex VI or VII)
• EU DoC drawn up with all Art.47(2) elements present
• EU DoC signed by authorised signatory and stored at stable URL
• CE marking affixed in documentation and user interface (or product for hardware AI)
• If NB involved: NB identification number included alongside CE marking
• EU database registration record completed (Annex VIII Part I fields)
• Registration record includes URL of EU DoC

After substantial modification:

• New conformity assessment triggered and completed
• Previous EU DoC archived; new EU DoC issued with new version/date
• CE marking references updated to point to new EU DoC
• EU database registration record updated
• Deployers notified per Art.13 and Art.16(k)

Ongoing maintenance:

• EU DoC and registration record updated when NB certificate status changes
• Technical documentation storage location references remain accurate
• URL of EU DoC in registration record remains accessible
• System status in registration updated if withdrawn or recalled

Hosting and jurisdiction implications

Your EU DoC URL and technical documentation storage location are part of the public registry. If these documents become inaccessible — because an infrastructure provider has service disruptions or because a foreign jurisdiction compels their removal — the compliance triangle breaks publicly, in the registry.

Using EU-jurisdiction infrastructure for the compliance documentation chain (EU DoC hosting, technical documentation storage, post-market monitoring data) prevents forced disclosure or access disruption from outside the EU. This is not a theoretical risk: the CLOUD Act has been invoked for business records, and compliance documentation is business records.

Summary

Art.16 compliance requires three sequential, interdependent steps: a completed conformity assessment feeds an EU Declaration of Conformity, which authorises CE marking, which enables EU database registration. Each step is conditional on the previous one being complete. Substantial modifications reset the sequence. Build these steps into your release pipeline as blocking gates, store the EU DoC at a stable URL, and keep the database registration record current. The August 2026 deadline applies to all Annex III high-risk AI systems currently on the market or being placed on the market.

Post #5 (final) in this series will cover Art.16 obligations toward national competent authorities: proactive disclosure duties, information requests under Art.74, and the provider's obligations when a serious incident is detected post-deployment.

See also: EU AI Act Art.43 Conformity Assessment — What Notified Body Auditors Actually Check | EU AI Act Art.16 Post-Placement Provider Obligations | EU AI Act Art.17 QMS Audit Readiness Checklist