What Article 18 documentation keeping requires from AI Act providers
Article 18 requires a provider of a high-risk AI system to keep specific documents available to national competent authorities for 10 years after the system is placed on the market or put into service. The five document types are the technical documentation, the quality management system documentation, any changes approved by a notified body, the notified body's decisions, and the EU declaration of conformity. Years after launch, a compliance lead may be asked to show what the system was designed to do, how it was tested, and how its governance changed over time, so the retention window has to be planned from the first release, not from the first audit request. The purpose is authority access: a regulator must be able to inspect the record of the system, not just the system as it runs today.
Two rules extend the duty beyond normal operations. Under Article 18(2), each Member State sets the conditions for keeping this documentation available if the provider or its authorised representative goes bankrupt or stops trading before the 10 years end, so the organization should confirm with its national authority and its contracts how records would be held in that case. Article 18(3) allows financial institutions to keep the technical documentation as part of the records they already hold under EU financial services law, which matters for banks and insurers that want one retention regime. Confirm with your supervisor whether that option applies before relying on it. Importers and authorised representatives carry parallel 10-year duties for the documents they hold under Articles 22 and 23.
In practice, retention fails for three reasons. Versions drift: the technical file describes version 2.3 while the model in production is 2.5, and no one can prove which documentation matched which release. Documents also live in unlinked tools, such as a wiki, a ticket system, a model registry and a shared drive, so the record has no single index. Finally, no one owns the retention clock, and archived material is deleted when a storage policy expires. A workable approach assigns an owner for each document type, keeps every version under change control with its approval history, and stores signed copies in a backup system that can restore by date and verify integrity. Teams can test this with a restore drill that rebuilds a documentation set as it stood on a past release date.
Which providers and documents fall under the 10-year retention rule
Article 18 applies to providers of high-risk AI systems placing them on the EU market, wherever they are established. The cards below separate who carries the duty, which documents it covers, and the scoping decisions that change how much work sits inside the retention period.
Non-EU providers placing systems on the EU market
Article 2 reaches providers outside the EU when their high-risk system is placed on the EU market or its output is used in the EU. These providers owe the same 10-year retention as EU providers, and they must also appoint an EU authorised representative. Check which legal entity signs the declaration of conformity, because that entity is the one whose records authorities will request.
Authorised representatives keep parallel records
The authorised representative that a non-EU provider appoints under Article 22 holds its own 10-year retention duty for the documents it keeps. The representative cannot rely on the provider keeping copies on its behalf. Confirm in the written mandate which documents the representative holds, where they are stored, and who answers an authority request if the provider stops trading.
Importers hold their own records
An EU importer placing a non-EU provider's high-risk system on the market must keep a copy of the EU declaration of conformity and related documents for 10 years under Article 23. The importer's file is separate from the provider's file. Agree in writing which party retains each document, and test that the importer can produce its copy without contacting the provider.
Annex III versus Annex I systems
Annex III systems follow internal-control conformity assessment in most cases, so the provider's own technical documentation and quality records form the core of the retained file. Annex I product systems follow sectoral procedures and may involve a notified body, which adds certificates and notified body decisions to the set. Map each system to its annex early, because the notified body records only apply to certain routes.
Financial institutions and Article 18(3)
Financial institutions may keep the technical documentation as part of the documentation they already retain under Union financial services law, rather than maintaining a separate AI Act set. This only works if the existing records cover every element the AI Act requires and remain available to the competent authority for the full period. Confirm the mapping with the institution's supervisory and compliance teams.
When the 10-year clock starts
The period runs from the date the system is placed on the market or put into service, not from the date the documents were written. A system updated after launch still needs its earlier records retained for the full period. Record the placing-on-the-market date for every system and version, so the retention end date for each file can be calculated when the system is withdrawn.
How the 10-year clock works and when it can end early
The 10-year period starts on the day a system is placed on the market or put into service, not on the day the documentation was written or last edited. Article 18(1) requires providers to keep the technical documentation, QMS documentation, notified body changes and decisions, and the EU declaration of conformity available to national competent authorities for 10 years from that date. Each version of a system that is placed on the market separately carries its own clock. If you release a major update that is a new version on the market, the records tied to that version need their own retention plan, and the older version's records keep their original end date. Build your retention register around version identifiers and market placement dates, not around project folders or document creation dates.
Article 18(2) covers the case where the clock is cut short. If a provider or its authorised representative goes bankrupt or ceases activity before the 10 years end, each Member State must set conditions for keeping the documentation available. The supplied facts do not list those national conditions, so confirm them with the market surveillance authority in every Member State where the system is used before you rely on any particular arrangement. Ask whether an escrow, a custodian, a successor provider or a handover to the authority is recognized, and what the authority expects to receive and in what format. Also check whether the same conditions apply to documents held by your authorised representative or importer under Articles 22(3)(b) and 23(5).
Plan for the early-end case now, while the company still operates. Keep the documentation in a system you can export and hand over without the people who wrote it, record where each record set lives, and write down who holds the access credentials. A self-hosted wiki with version history, such as XWiki, can show who changed a page and when, and a backup platform like Bareos can restore files from a dated point, but neither decides what your national authority will accept. Ask your legal counsel to confirm the handover route for each market, and treat the answer as an input to your retention design.
How an assessor tests retention across the documents
Article 18(1) requires a provider to keep the technical documentation at the disposal of national competent authorities for 10 years after the system is placed on the market or put into service. An assessor starts by asking for the retained set for a named system and then compares it against the version that was placed on the market. The test is not whether a folder exists but whether every version the authority could ask about is still there, readable and tied to a specific release.
- Full window: Confirm the earliest retained version predates placing on the market and that retention runs for 10 years from that date, not from the last update.
- Retrievable form: Check that the set can be produced as a complete package within a reasonable time, in formats an authority can open, with an index that maps sections to the requirements they evidence.
- Version match: Compare the documentation's stated system version, model version and intended purpose against the deployed release and the EU declaration of conformity.
- Superseded versions: Look for earlier revisions of the risk management file, data descriptions and test reports. Missing superseded versions are one of the most common findings because overwritten pages look current.
- Personal storage: Identify whether any section exists only in an engineer's email, laptop or personal drive.
Ask the provider to show how a past version is restored, who approved it and when it was superseded.
The quality management system described in Article 17 generates records over the system's life: policies, procedures, change decisions, audit results, corrective actions and management reviews. Article 18(1) brings these within the same 10-year duty. An assessor checks that the record set is a coherent history rather than a current snapshot, because a QMS is judged on how it operated over time.
- Full window: Request records from the first approval of the procedures through to the present and confirm no period is empty without explanation.
- Retrievable form: Check that approvals, signatures or workflow states are preserved, not only the final text of each procedure.
- Version match: Confirm the QMS procedures in force at each date match the procedures the team said it followed on that date.
- Superseded versions: Look for prior procedure versions and their withdrawal records. Assessors often find procedures edited in place with no history.
- Individual custody: Identify whether audit reports, risk acceptances or change approvals sit only with the person who ran the review.
Ask for a sample of changes and trace each one back to the approval, the test evidence and the version of the procedure in force at the time.
Where a high-risk system needs a notified body, Article 18(1) requires the provider to keep changes approved by the notified body, the notified body's decisions and its related documents for the same 10-year period. An assessor tests this set against the certificate history, because each approved change should be traceable to a decision and to a documentation version. Where the internal-control route applies, this tab may be limited to confirming that no notified body was involved.
- Full window: Confirm every certificate, supplement and approval decision is retained for 10 years from the relevant placing on the market date.
- Retrievable form: Check that the decision and the change request can be produced together, with dates and the scope they cover.
- Version match: Map each approved change to the documentation version and system release it applied to, and confirm the deployed system reflects it.
- Superseded decisions: Look for withdrawn or suspended certificates and the correspondence that led to them.
- Individual custody: Check that the relationship with the notified body does not depend on one contact's inbox or personal records.
Ask the provider to show the chain from a notified body decision to the release that implemented it.
The EU declaration of conformity is the provider's signed statement that a high-risk system meets the requirements. Article 18(1) requires it to be kept for 10 years, and the assessor expects each signed version to match the system it describes. Because the declaration is short, the test focuses on whether the declaration was reissued when the system changed and whether earlier signed versions were kept rather than overwritten.
- Full window: Confirm a signed declaration exists for every version placed on the market and that each is retained for 10 years.
- Retrievable form: Check that signed copies are stored in a read-only or versioned repository with the signatory and date visible.
- Version match: Compare the system identifier, version and intended purpose stated in each declaration against the release notes and the technical documentation.
- Superseded declarations: Look for earlier signed versions and the reason each was replaced.
- Individual custody: Check that the signatory's authority is documented and that the declaration is not held only by the person who signed it.
Ask the provider to produce every signed declaration in date order and to show which release each one covers.
Article 22(3)(b) gives an authorised representative of a non-EU provider a parallel 10-year duty for the documents it holds, and Article 23(5) gives an importer the same duty for the documents it holds. An assessor tests these parties separately because each holds only part of the set, and a gap often appears where the provider assumes the representative or importer keeps the file. Each party's retained set should be checked against its own written mandate or import records.
- Full window: Confirm the representative or importer holds its copies for 10 years from the relevant date and that the mandate or contract sets that duty in writing.
- Retrievable form: Check that the representative or importer can produce its copies to an authority on request, in the EU, without first contacting the provider.
- Version match: Confirm the documents each party holds match the version of the system it imported or represents.
- Superseded versions: Look for copies of earlier declarations and documentation the party received, and whether it still holds them after an update.
- Individual custody: Check that the representative's or importer's records are kept by the organization, not by a single staff member or a departed contact.
Ask each party to show its own retained set and to state how it would produce it within the period set by the authority.
Implementing a 10-year documentation retention process
This sequence turns the Article 18 retention duties into a working process: every document class is inventoried per system, given an owner and a retrieval path, kept under version control, protected against loss of the provider, and proven retrievable before an authority asks for it. Each step ends with a named output that an auditor or authority can inspect.
Inventory every Article 18 document class per system
For each high-risk AI system, list the five document classes Article 18(1) names: the technical documentation, the QMS documentation, changes approved by notified bodies, notified body decisions, and the EU declaration of conformity. Record where each class currently lives, including wikis, ticketing systems, model registries and signing tools. Confirm with your legal or compliance lead whether any Article 18(3) financial-sector arrangement applies, because it changes where the technical documentation is kept. The output is a retention register with one row per system and document class. The step is complete when someone outside the project team can trace each row to a stored, named location.
Assign an owner and retrieval path to each class
Name one accountable owner for each document class in each system, usually a role rather than a person, plus a deputy who can act during absence. Write down the retrieval path: where an authority request arrives, who receives it, who pulls the document, and how it is delivered. Include the case where the provider holds documents that an authorised representative or importer also keeps under Articles 22 and 23, and agree which party answers. The output is an ownership and retrieval matrix signed off by the governance lead. The step is complete when each row names an owner, a deputy and a delivery method.
Set the retention rule from the market placement date
Configure the retention period as ten years counted from the date the system was placed on the market or put into service, not from the date a document was written or last edited. Record that start date in the register for each system, and set a review date for the end of the period so that no record is deleted by an automatic cleanup job before it expires. Ask your backup and archive vendors how they enforce retention holds, and confirm the behavior in your own environment. The output is a retention rule per system and an archive policy that blocks early deletion. The step is complete when a test record shows the end date calculated correctly.
Establish version control and approval records
Keep each document class under version control so that every change records what changed, when, and by whom. Require a named approver for each release of the technical documentation and the QMS records, and store the approval next to the version it authorizes. Notified body changes and decisions should be filed with the approved version they relate to. Wiki platforms such as XWiki keep page history and allow comparison and rollback, while Git repositories or document management systems can provide equivalent history for files. The output is a version log per document class. The step is complete when you can show, for any past release, who approved it and which content it contained.
Write the bankruptcy and cessation hand-over plan
Article 18(2) leaves the conditions for keeping documentation available after a provider goes bankrupt or ceases activity to each Member State, so confirm the rules in each market where the system is placed. Draft a hand-over plan that names a custodian for the archive, states how access credentials and encryption keys are transferred, and lists the authority contacts to notify. Include copies held by the authorised representative or importer where they apply. Confirm with counsel which national conditions must be met. The output is a written hand-over plan with a named custodian, a key escrow arrangement and a contact list. The step is complete when the custodian has acknowledged the role in writing.
Back up and verify the documentation archive
Protect the archive with scheduled backups that are independent of the systems that produce the documents, so a failure in the wiki or repository does not take the backup with it. Use a backup director with a catalog that can restore files from the current backup or from a point before a given date and time. For content-addressed repositories, run integrity checks on a schedule, including data reads where the tool supports them. Store at least one copy outside the primary environment, and confirm the encryption and access controls with the security team. The output is a backup policy, job records and integrity check reports. The step is complete when the verification reports show no unresolved errors for the retention period.
Run a retrieval test and record the result
Once a year, or sooner when a system changes materially, run a retrieval test as if an authority had requested the documentation for a named system and a past release. Time the retrieval, check that the version returned matches the approved release, and confirm that the approval record and the retention start date are present. Record any gap, assign a fix, and retest the item. Ask your auditor which evidence they expect from this test. The output is a tested retrieval runbook and a dated test record. The step is complete when the test has passed for each system and every gap has a closed ticket.
Which evidence shows the documents are kept and retrievable
What is a retention register and what should it list?
A retention register is a single index that lists every Article 18 record for each high-risk system, with the system name, version, placing on the market or putting into service date, storage location, custodian, and the date the 10-year period ends. It shows an authority that you know where each record sits and when it can be released. Keep it current by updating the entry at each substantial modification, new notified body decision, or new declaration version, and by reviewing the end dates at least once a year. Ask any implementation partner to build the register inside your own document system so that it is owned and maintained by your organization.
How do version-history records prove the technical documentation is intact?
Version-history records show every change made to the technical documentation, what changed, when, and by whom, so an authority can see that the file it receives is the one that was in force. A wiki or document platform with built-in version control can provide this. XWiki, for example, keeps each page change under version control, lets users compare any two versions, and supports rollback to an earlier version. Confirm with your platform owner how history is retained, whether it can be exported, and whether deletions are logged, since the retention test depends on those details. Store a read-only export of the approved version at each release as a second copy.
What should a QMS record index contain for authorities?
A QMS record index is a map from each quality management system requirement to the documents and logs that show it operated, with the owner, location and retention end date for each. Quality management records include policies, procedures, design reviews, test results, risk management outputs, and post-market records. The index lets you produce a complete set quickly when an authority asks for it. Review it after each internal audit and after any change to the quality management system, and confirm that the records it points to still open and are readable, not only that the links resolve.
How should notified body correspondence and decisions be archived?
Archive every notified body approval, change approval, decision, and formal exchange in a dated, indexed store that is separate from working mail. Article 18 covers changes approved by notified bodies and their decisions, so each one needs a retrievable record with the certificate reference, scope and expiry. Record the sender, the date received, and the link to the affected system version. Review the archive whenever a certificate is renewed or a change is approved, and keep the original signed files, not only copies of emails. Notified body involvement applies only to some systems, so confirm with your assessment route whether this item applies to you.
How do you keep the signed EU declaration of conformity with its version?
Keep the signed declaration of conformity as a versioned, signed file, with each version tied to the system version, the assessment route used, and the date it was signed. Article 18 requires it to be available for 10 years after the system is placed on the market or put into service. Store the signature evidence and the hash of each signed file in your retention register, and never overwrite a signed version. When the system changes in a way that requires a new declaration, add a new version and keep the earlier one. Ask your legal or compliance lead to confirm the required contents against the Article itself before signing.
What does a cessation hand-over plan need to cover?
A cessation hand-over plan names who receives the Article 18 records if the provider goes bankrupt or stops trading before the 10-year period ends. Article 18(2) leaves the conditions to each Member State, so the plan should identify the competent authority for each market and how records will be transferred to it or to a designated custodian. It should cover the storage location, encryption keys, access credentials, a complete copy of the register and version history, and the contact for the custodian. Test the plan by restoring a sample set to a second location at least once a year. Confirm the national conditions with local counsel, since they differ by Member State.
Which backup and restore checks prove the records can be retrieved?
Retrievable records need backups that restore on request and that have been verified. Backup platforms such as Bareos schedule backup, restore, verify and archive jobs, keep a catalog of backed-up files, and can restore files from the current backup or from an earlier point in time. restic can check repository structure and, with --read-data or --read-data-subset, read pack files back to confirm the stored data is unmodified. Keep a restore log showing the date, the scope, and the result of each test. Confirm the retention period configured in the backup tool matches the 10-year requirement, because backup retention and records retention are separate settings.
Can our own team do this, and what would an implementation partner handle?
Your own compliance and engineering staff can build and run this evidence set if they own each record and the review calendar. An implementation partner such as DeployOpen can plan the structure, deploy the document, version-control and backup systems inside your own infrastructure, configure permissions, and document the restore tests, under a written, fixed scope. The partner prepares the evidence; it does not issue assessment reports or certificates, and the organization remains responsible for the controls. Ask for the scope, deliverables and handover documents in writing before work starts.
How self-hosted tools keep the record intact over 10 years
Article 18 asks a provider to keep its records available for ten years, so the tooling has to preserve history, control who changes what and survive hardware, staff and vendor changes. A self-hosted wiki such as XWiki can hold the controlled documents (the technical documentation, QMS procedures and the EU declaration of conformity) as pages under version control. Every change is recorded with what changed, when and by whom, and any two versions can be compared or restored. Confirm that the platform's version history covers attachments and page deletions, and that the chosen export format keeps authorship and timestamps readable by someone who does not run the platform.
A permission model is what separates the people who draft a document from the people who approve it. In BookStack, abilities come from roles, and permissions can be overridden per role at the shelf, book, chapter or page level, so authors can edit drafts while only a quality or compliance role can publish or archive an approved version. Write this split down as a decision: which roles may edit, which may approve, and who may delete. Review the role assignments at least once a year, and keep a record of each change to them, because an auditor will ask who could have altered an approved document on a given date.
Version history only helps if the underlying data can be restored. Bareos schedules backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, so a restore can target the current backup or one taken before a given date and time. restic offers a check command that, with --read-data or --read-data-subset, reads pack files back to confirm that stored data is unmodified. Plan a restore test for the wiki database and attachments on a fixed schedule, record the result, and confirm with your legal and records teams whether legal holds, litigation freezes and the retention period for your own records require longer or separate archives than your backup rotation keeps.
What keeping Article 18 documentation costs in money and effort
This table breaks down the cost components of keeping Article 18 records for 10 years, showing whether each is one-time or recurring, what drives it, and how to reduce it. No price is given, so use it to structure a request for a quote from a written scope. Open-source licenses remove software spend, but staff time for design, approval and retrieval testing remains.
| Cost component | One-time or recurring | What drives it | How to reduce it |
|---|---|---|---|
| Document system setup | One-time, with later changes | Number of document types (technical documentation, QMS records, notified body records, declarations), integration with engineering tools, and the number of systems in scope | Limit the first build to the Article 18 record types, reuse an existing wiki or document platform, and agree the folder and naming structure before migrating content |
| Retention and access design | One-time design, recurring review | Retention periods per record type, who must be able to produce records for authorities, and how access is granted to staff, auditors and national authorities | Map each record to its retention trigger in one table, use role-based permissions instead of per-document grants, and record who approved the design |
| Version control and approval effort | Recurring, tied to every change | Release frequency of the high-risk system, number of approvers per document, and how often notified body changes or decisions arrive | Use built-in page history so changes are logged automatically, set a fixed approval step per document type, and avoid parallel copies outside the controlled system |
| Backup and archive storage over 10 years | Recurring for the full retention period | Volume of technical documentation and logs, number of backup copies, retention policy length, and whether archives are kept on-premises or in a cloud account | Archive closed versions in separate, read-only storage, deduplicate backups where the tool supports it, and size storage from a documented volume estimate |
| Periodic retrieval testing | Recurring, on a schedule you set | Number of records to test, frequency of tests, and whether the test covers both restore and human readability | Test a sample of records on a fixed schedule, verify backup integrity with the tool's check command, and record each test result as evidence |
| Migration when platforms change | One-time per migration, repeated over 10 years | Vendor or software changes, format changes, retention of version history during the move, and the need to keep old records readable | Choose open formats, keep an export of version history with each migration, and test one restored record on the new platform before retiring the old one |
| External review of the retention design | One-time or periodic, paid to an outside party | Scope of the retention design, whether a qualified advisor or auditor reviews it, and the depth of the review | Ask the reviewer to confirm which records and periods are covered, and keep the scope written so the review can be repeated at lower cost |
| Staff time (all components) | Recurring | Internal skills, number of people who maintain the archive, and turnover of the people who know the system | Document runbooks for backup, restore and migration, and assign named owners who cover for each other. Open-source licenses remove license spend, not the staff time these components need. |
Who keeps the record, who helps, and what the auditor checks
Your organization is the provider, so the obligation to keep the technical documentation, quality management records, notified body changes and decisions, and the EU declaration of conformity for 10 years sits with you. Your team decides what counts as the final version of each document, who approves it, and when a record is retired. Those decisions are governance decisions and cannot be delegated to a vendor.
- Ownership: name an accountable owner for each document set, such as the technical file, QMS records and the declaration.
- Approvals: keep signed or otherwise attributable approval records for every version that was placed on the market or put into service.
- Retention decision: set the 10-year period from the date of placing on the market or putting into service, and document how that date is recorded for each system.
- Continuity: decide who holds the records if the business is sold, restructured or stops trading, and check the Member State conditions that apply under Article 18(2).
- Financial institutions: if you rely on Article 18(3), confirm with your supervisor how the documentation fits the financial services file.
Before you rely on any of this, confirm with your legal and compliance function which retention rules apply to each system you place on the market.
An implementation partner such as DeployOpen can prepare the systems that hold the record. That work is technical and operational: setting up the repositories, configuring backups, running restore and integrity tests, and writing the runbooks your staff follow. The partner works inside your infrastructure and under a written scope. It does not write your declaration, approve your documentation or decide that a record is compliant.
- Repositories: configure version-controlled documentation spaces with role-based permissions, so every change and approval is attributable.
- Backup configuration: set up backup, verification and archive jobs, with catalog retention and access controls that match your retention decision.
- Retrieval tests: run timed restore exercises that show a named document from the 10-year archive can be produced for an authority.
- Runbooks: write the procedures for retrieval requests, legal holds, media migration and the handover if a provider ceases activity.
- Evidence of operation: produce logs and test reports that your team and the auditor can review.
Ask any partner to put these deliverables, exclusions and acceptance criteria in writing before work starts.
An independent auditor, assessor or notified body tests the record and, where the route requires it, issues the certificate. Under the conformity assessment route for your system, the notified body checks the QMS and technical documentation, and it records its own decisions and any approved changes. Authorities can then request the documents directly. The independent party is the only one that can attest to conformity. A partner that prepared the evidence cannot also verify it.
- Sampling: expect the assessor to ask for a specific document version, the approval trail behind it and proof that it was retained unchanged.
- Retrieval: expect a request to produce records from earlier years, which tests whether your archive and runbooks work in practice.
- Changes and decisions: expect questions about notified body changes and decisions, including where they are stored and who can view them.
- Independence: the partner cannot sign the declaration or certify the retention period, and the notified body cannot design the controls it tests.
- Scope: confirm with the assessor, before the engagement, which records they will request and in which format.
Before engaging any assessor, ask them to confirm in writing which documents they expect to see and how they will test retention.
Where providers fail the 10-year documentation test
Article 18 asks providers to keep specific records available to authorities for 10 years after a system is placed on the market or put into service. The failures below tend to surface only when an authority asks for a file that no longer exists, is in the wrong version, or cannot be read. Each card names the gap and the check that closes it.
Retention clock started on the wrong date
The 10 years run from placing on the market or putting into service, not from when the documentation was written or last edited. Teams that start the clock at development completion or at internal sign-off can delete records too early. Check that the retention start date is recorded per system and per version, and that the date rule is written into the documentation retention schedule. Confirm the trigger date with your legal team for systems that were updated in place.
Superseded versions deleted
Technical documentation changes as the system changes, and an authority may ask what the system looked like when it was placed on the market. If older versions are overwritten, the record of what was approved, tested and declared is lost. Use a wiki or document platform that keeps version history with author and timestamp, and confirm that old versions remain retrievable after a rollback. Test a restore of a version from several years back.
QMS records scattered across tools
Quality management records often live in a ticket tracker, a shared drive, a code repository and someone's inbox. When an authority asks for the full set, assembling it can take weeks and gaps appear. Map each required record type to one system of record, assign an owner, and keep an index that links every record to its system version. Review the index on a fixed schedule so it does not drift from the actual files.
No bankruptcy or cessation plan
Article 18(2) leaves member states to set conditions for keeping documentation available if a provider or its authorised representative goes bankrupt or stops operating before the 10 years end. Many providers have no such arrangement, so records sit with a departing employee or a cancelled vendor account. Ask your counsel which national conditions apply in each Member State where the system is placed on the market, and document who holds custody of the records, where they are stored and how an authority would reach them.
Notified body decisions not filed
Where a notified body is involved, Article 18 requires the provider to keep changes it approved, the body's decisions and the EU declaration of conformity. These documents often arrive by email or a portal download and are never added to the technical file. Create a filing step that triggers on each notified body communication, and record the decision reference alongside the system version it covers. Confirm with your notified body how it will issue decisions and how you will obtain copies.
Backups never restored
A backup that has never been restored is an assumption, not evidence that the records can be recovered in 10 years. Archive media fail, encryption keys get lost and catalogs drift from the stored data. Schedule periodic restore tests of the documentation archive to a clean location, and verify that restored files open and match their recorded checksums. Keep the test results as part of the retention evidence.
Questions buyers ask about Article 18 retention cost, effort and outsourcing
How long must a provider keep AI Act documentation after placing a system on the market?
Article 18(1) requires providers to keep the technical documentation, quality management system documentation, changes approved by notified bodies, notified body decisions and the EU declaration of conformity available to national competent authorities for 10 years after the system is placed on the market or put into service. The clock starts at placing on the market or putting into service, not at the end of the system's use, so a system retired early still carries the full 10-year duty. Ask your team to record the placing-on-market date for each system in your inventory, because that date sets when each record can be released. Financial institutions may keep the technical documentation as part of the documentation they already hold under Union financial services law, which can reduce duplication but still has to be confirmed with your supervisor.
What happens to AI Act records if the company stops trading?
Article 18(2) does not let the duty lapse with the company. It requires each Member State to set conditions for keeping the documentation available if a provider or its authorised representative goes bankrupt or ceases activity before the 10 years end. The rules are national, so confirm with the market surveillance authority in each Member State where your system is placed on the market what arrangement applies. Plan for it now: keep records in a system you control, with an export path that does not depend on a vendor staying solvent, and name who holds access if the business stops.
Can an implementation partner hold our AI Act documents for us?
A partner can host, back up and organize the records inside your infrastructure, but the legal duty to keep them stays with the provider. Authorised representatives and importers have parallel 10-year retention duties under Articles 22(3)(b) and 23(5) for the documents they hold, so any party holding copies must be named in your contracts. DeployOpen deploys and supports self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks, so records stay under the client's control. Ask any partner to state in writing who owns each record, where it is stored, who can access it and how it is returned on termination.
What does the internal team need to supply for retention to work?
Retention is mostly a matter of ownership and discipline, not software alone. Your team must decide which roles own each record type, approve who may change controlled documents, and sign off the notified body correspondence and decisions when they arrive. Engineers must tie each model version to its technical documentation and logs, and compliance must keep the register of placing-on-market dates. Expect recurring effort for reviews, access reviews and restore tests, and budget for at least one named owner who can answer an authority request without outside help.
Can self-hosted open-source tools keep AI Act records on their own?
Open-source tools can produce much of the evidence, but they do not satisfy Article 18 alone. XWiki keeps every change under version control with a record of what changed, when and by whom, and lets users compare and roll back versions. BookStack assigns abilities through roles and allows permissions to be overridden at shelf, book, chapter or page level. Bareos schedules backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, while restic's check command can read pack files back to confirm stored data is unmodified. Confirm each tool's archive, retention and export behavior in your own environment before relying on it, and document the retention rules around them.
What drives the effort of AI Act retention up or down?
Effort rises with the number of systems, the number of model versions per system, the volume of technical documentation and logs, and how many parties hold copies. It also rises when records live in email, shared drives or unversioned files, because reconstructing history for an authority takes far longer than retrieving it from version control. Effort falls when you standardize document templates, link each record to a system ID in your inventory, automate backup verification, and set one retention schedule covering all roles. Ask a partner to estimate effort against your system count and record types rather than a generic package.
What should a written quote for AI Act retention include?
A written quote should follow from an agreed scope, not a generic price list. Ask for the list of systems and record types in scope, the retention period applied to each, and the storage location and hosting model. Require a breakdown of one-time work, such as setting up version control, backup jobs and access roles, against recurring work, such as access reviews, restore tests and upgrades. Confirm who owns the records, how exports are delivered, what happens to the records at contract end, and which deliverables are documentation rather than legal certification. DeployOpen does not publish a price list, and quotes follow from the written scope.
How DeployOpen prepares Article 18 retention in your environment
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure so that technical documentation, QMS records and conformity records can be kept, versioned and recovered for the 10-year period. We prepare the systems and evidence; your organization owns its retention obligations and the records themselves.
How we scope
- We agree in writing which record types fall under Article 18 for each high-risk system in scope.
- The written scope names the retention period, storage locations, owners and the systems that hold each record.
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts.
How we build
- We configure version-controlled documentation spaces with role-based access so that every change to a record is attributable.
- We set up backup and archive jobs with catalogs, so older versions of records can be restored by date.
- We schedule integrity checks on backup repositories to confirm stored data remains unmodified over the retention window.
How we hand over
- We deliver a retention map listing each record, its owner, location, retention end date and recovery procedure.
- We document restore tests and their results so your team can show authorities how records are retrieved.
- We provide runbooks covering access, backup, restore and succession, including what happens if the provider ceases activity.
How we support
- Ongoing support, upgrades and integrity testing are available as a retainer after handover.
- We can review retention settings when a system is substantially modified or when notified body decisions change.
- Your auditors or legal advisers make the final determination of what must be kept and for how long.
