EU AI Act Article 18 Documentation Keeping for High-Risk AI Systems

Executive summary

Article 18 is not the same thing as logging, and it is not the same thing as deployer monitoring. It is the obligation to retain a defined documentation set for ten years and make it available to competent authorities when needed. The documentation itself is largely defined by Article 11 and Annex IV, while Article 18 tells you how long to keep it and who may ask for it.

“Providers shall keep the technical documentation referred to in Article 11, the EU declaration of conformity and, where applicable, the certificate issued by the notified body, at the disposal of the national competent authorities for 10 years after the high-risk AI system has been placed on the market or put into service.”

— Regulation (EU) 2024/1689, Article 18(1)

For compliance officers and AI governance leads, the operational challenge is proving continuity across versions, releases, and evidence sources. A verifiable evidence layer like Decision Ledger helps create tamper-evident, hash-chained records that connect model changes, approvals, and decision events to the documentation bundle you may need later. This is particularly valuable when models are updated frequently: you can show which documentation applied to which release, who approved it, when it was frozen, and that it has not been altered since.

What Article 18 requires

The core retention duty is straightforward: retain the technical documentation, the declaration of conformity, and any certificate issued by a notified body for ten years. The retention window begins when the high-risk AI system is placed on the market or put into service, not when development starts. In other words, the clock tracks the regulatory lifecycle, not the engineering project timeline.

That matters because teams often organize records around sprint cycles and repositories instead of legal milestones. Article 18 pushes you toward a lifecycle model: identify the “market/serve” date for each release that underwent (or inherited) conformity assessment, freeze the relevant evidence set, and keep it retrievable for the full retention period. If you later make a substantial modification that triggers a new conformity assessment, expect to capture and retain a new documentation set for that modified system from its new “placed/put into service” date.

What goes into the retained documentation set is defined by Article 11 and Annex IV. In practice this typically includes:

• A general system description, intended purpose, and high-level architecture.
• Design and development records, including model lineage, training/validation methodology, and configuration baselines.
• Risk management documentation, controls mapping, and residual risk rationales.
• Data governance information: training/validation dataset sources, preprocessing, known limitations, and data quality assessments.
• Testing and performance evidence: accuracy / robustness / cybersecurity metrics and test protocols relevant to intended purpose.
• Human oversight design, user information, and system limitations communicated to deployers.
• Post-market monitoring plan and procedures for incident handling and corrective actions.
• The EU declaration of conformity and, where applicable, the notified body certificate demonstrating the completed conformity assessment.

A useful way to operationalize the obligation is:

• Retain the Article 11 / Annex IV technical documentation package for the exact version placed on the market or put into service.
• Retain the EU declaration of conformity that corresponds to that version.
• Retain any notified body certificate and related assessment reports.
• Keep these artifacts at the disposal of national competent authorities for ten years.
• Govern retention against the system lifecycle, including substantial modifications.

For a practical, step-by-step view of how to turn this into evidence, see the audit readiness checklist.

Article 18 vs Article 12 vs Article 19 vs Article 26

These provisions are related, but they solve different problems:

• Article 18 is about retention of documentation for ten years and accessibility to authorities.
• Article 12 is about logging capability in the high-risk AI system itself. It focuses on the system’s ability to generate logs to support post-deployment monitoring and incident analysis. See the overview of Article 12 record-keeping.
• Article 19 is about automatically generated logs and their preservation in the provider workflow. This is an operational logging duty distinct from documentation retention. Review Article 19 automatically generated logs.
• Article 26 focuses on deployer obligations, including operational use, incident reporting, and monitoring responsibilities in production environments. See Article 26 deployer obligations.

This distinction matters in procurement and architecture discussions. Internal logs help engineering teams answer “what happened?”; a verifiable audit trail helps evidence teams answer “can we prove what happened, and can we retrieve the relevant record later?” Your architecture often needs both: operational logs for SRE and safety monitoring, and a cryptographically verifiable evidence bundle for Article 18-style retention and authority requests.

Evidence model

CertifiedData’s Decision Ledger is built for evidence-readiness around Article 18-style retention workflows. It does not replace the underlying technical documentation; it helps preserve integrity, traceability, and retrieval of the evidence set around it. The aim is to make it simple to demonstrate that a documentation bundle you present later is the same bundle that existed at release time.

The evidence model typically uses:

• RFC 8785 canonicalization for stable JSON representation, ensuring that semantically identical documents serialize identically before hashing.
• SHA-256 hashing to create content fingerprints for each artifact and for the bundle manifest.
• Ed25519 signatures for authenticity and non-repudiation of signed records by identified custodians or approvers.
• Hash-chained records to show sequence and tamper-evident linkage across releases and updates.
• Public-key verification so auditors can validate records independently of your internal systems.

In practice, that means your Article 18 bundle can include versioned documentation, approvals, and supporting artifacts that are easier to verify later. For example, the release approver signs a manifest that enumerates each document (model card, risk management file, validation report), includes their SHA-256 digests, and records the “placed/put into service” date. The manifest is then linked to the prior release via a chain hash. Months or years later, an auditor can recompute hashes, verify the Ed25519 signatures, and check chain continuity to confirm nothing changed.

If you want to see what that looks like, start with the Decision Ledger demo or download a sample evidence bundle. Synthetic dataset certificates can also be part of the broader documentation set when they describe training-data origin, generation method, or fingerprinting details. They may support the Article 11 / Annex IV package, but they are not by themselves Article 18 retention compliance; they complement, not replace, your technical file.

Implementation pattern

A workable implementation pattern usually starts with three questions:

1. What is the exact system name and version that entered service?
2. Which documents belong to the Article 18 retention set for that release?
3. How do we prove the retained package has not been altered over time?

A common approach:

• Capture scope: define the release identifier, intended purpose, and “placed/put into service” date as required metadata.
• Freeze evidence: enumerate the documents that constitute the Article 11 / Annex IV technical file plus the EU declaration of conformity and any notified body certificate.
• Canonicalize and hash: produce RFC 8785–canonical JSON manifests and compute SHA-256 digests for each artifact and the bundle manifest.
• Sign and chain: have accountable owners sign with Ed25519 keys, link to the prior record using a chain hash, and record a trusted timestamp.
• Store and retain: persist the artifacts in your DMS or object store, and persist the signed, hash-chained evidence record in Decision Ledger.
• Drill retrieval: run periodic retrieval and verification tests so you can demonstrate timely access and independent verification on demand.

This pattern lets you preserve the operational convenience of internal storage and the audit-readiness of verifiable records. Many teams integrate it into change control: when a release is approved, the CI/CD pipeline writes the evidence manifest, signs it, and posts to the ledger. That produces a consistent audit trail for each declared “market/serve” event and mirrors the lifecycle focus of Article 18. If you are comparing approaches, pricing can help you evaluate whether you need a narrow retention layer or a broader evidence program integrated with Decision Ledger.

Tip: treat “substantial modification” as a first-class trigger. If product or safety leads determine a change is substantial, create a new evidence bundle, re-run conformity workflows as required, and start a new ten-year retention horizon for that release. Record the rationale for the modification classification in the evidence set so the reasoning is traceable later.

FAQ