Structuring a Long-Term EU AI Act Documentation Retention Archive for Providers

Treat the archive as an evidence system

Providers of high-risk AI systems must draw up technical documentation before the system is placed on the market or put into service, and keep it up to date (Article 11(1)). Article 18 then lists what the provider must keep: the Article 11 technical documentation, the documentation concerning the quality management system under Article 17, and the documentation concerning changes approved by notified bodies, where applicable. The consolidated Regulation text dated 27 July 2026 carries the same wording as the original 2024 text for these provisions, as of November 2026.

In practice these artifacts sit in different places. Engineering holds design and testing material, quality holds process records, legal or conformity teams hold notified-body correspondence, and security holds operational records. A folder with a retention label does not tell an authority which version of a document applied to which version of a system, or whether the set is complete. The archive therefore needs an index that follows the obligations, not the org chart.

The recitals describe the technical documentation as covering general characteristics, capabilities and limitations, algorithms, data, training, testing and validation processes, and documentation on the risk-management system, drawn up in a clear and comprehensive form. That breadth is the reason the archive has to span several source systems and still present one readable set.

Map obligations to artifact classes and owners

Start by assigning every existing artifact to exactly one class, with a named owner and an origin. The origin matters later, because authored and runtime-generated records need different capture and integrity handling.

• Technical documentation (Article 11): Typical owner: engineering. Mostly authored, with some exports from tooling. Must be kept up to date, so superseded versions are retained.
• QMS documentation (Article 17): Typical owner: quality. Authored procedures, plus records produced when those procedures run.
• Notified-body change documentation: Typical owner: conformity or legal. Authored and received documents, where applicable to the system.
• Automatically generated logs: Typical owner: platform or security. Generated at runtime and held under a separate retention rule from the authored classes.

Define the archive structure

Index first by artifact class, then by AI system, then by version. For each system version, record the date it was placed on the market as archive metadata. The retention clock for documentation is tied to market placement, so retention dates should be computed from that field rather than from the date a file was uploaded.

Versioning follows from the requirement to keep documentation up to date. Updating a document must not overwrite the one it replaces. Keep each superseded version with its effective period, so you can reproduce the technical documentation as it stood at any earlier version of the system. Link each version to the system release it describes and to the approval that authorized the change.

For integrity, store archived records in write-once or append-only storage where your platform allows it, and record a cryptographic hash for each artifact at ingestion. Verify hashes on a schedule and after any migration, and keep the verification results as records too. Restrict write access to a small set of named roles, separate read access for authorities and auditors, and log every retrieval.

Legal hold should be a flag that suspends scheduled deletion for a defined scope, such as one system or one class, with a named approver and a recorded release. Deletion at the end of a retention period should be a controlled, recorded action, never a side effect of storage housekeeping.

• Index: class, then AI system, then version
• Metadata: market-placement date, effective period, owner, approver
• Integrity: hash at ingestion, scheduled verification, append-only storage
• Access: named write roles, separate read paths, retrieval logging
• Legal hold: scoped flag that suspends deletion, with approver and release record

Retention, data protection and continuity

Set retention per class rather than for the archive as a whole. Technical documentation, QMS documentation and notified-body change documentation fall under the Article 18 documentation-keeping provision. Automatically generated logs are governed by the Regulation's separate log provision, so they need their own schedule and should not inherit the documentation clock by default. Confirm each period against the current consolidated text before encoding it in a retention policy, and record the text version your policy was built on.

Logs and some documentation can contain personal data. Long retention periods therefore create a tension with data protection storage-limitation principles. A workable approach is to decide, per class, what personal data the record actually needs, minimize or pseudonymize at capture where the evidential value allows, and document the reasoning for the retention period you apply. Data residency is an architectural choice made at the storage layer, so decide where each class lives before data accumulates. Your data protection officer should sign off on the classes that carry personal data.

Continuity also needs planning. Under Article 18(2), each Member State determines the conditions under which the documentation stays at the disposal of national competent authorities if a provider, or an authorised representative established on its territory, goes bankrupt or ceases activity before the retention period ends. Check the rules in each Member State where you operate or appoint a representative, and decide in advance how the archive would remain accessible, including who holds access credentials and where copies reside.

Runtime evidence versus authored evidence

Authored evidence is written by people at a point in time: design documentation, QMS procedures, conformity materials. It is reviewed and approved before it enters the archive, and its main risks are version drift and missing superseded copies. Runtime evidence is produced by systems as they operate. It arrives continuously, in volume, and its main risks are completeness, tamper resistance and the cost of keeping a long retention period consistent across storage tiers.

The two types need different ingestion paths into the same index. Authored artifacts enter through an approval step. Runtime records should enter through an automated path that stamps system, version and time, hashes the record and writes it to protected storage without manual handling.

Where enforcement evidence belongs is an open design decision for each provider. Policy enforcement in the execution path can produce evidence of what an AI system was allowed to do and what it did, for individual interactions and tool calls. Trussed enforces policy in the execution path and generates audit-ready evidence mapped to the EU AI Act, in a self-managed deployment in the customer cloud with configurable retention and data residency. A provider using such evidence would register it as a runtime class in the archive, with its own retention rule, and link it to the system version it relates to. It supplements the authored documentation and does not replace it.