EU AI Act documentation by role: what providers keep

Which EU AI Act documents each role must produce and keep

The documents you owe under the EU AI Act depend on your role: provider, deployer or provider of a general-purpose AI model. If a customer, contract or regulator is asking for AI Act evidence now, first establish which role you hold for each system. Providers of high-risk systems keep technical documentation, QMS records and the EU declaration of conformity available for 10 years after placing on the market or putting into service, under Articles 18 and 47. Logs under your control are kept for at least six months under Articles 19 and 26(6), unless other Union or national law sets a longer period. Deployers focus on logs, fundamental rights impact assessments where Article 27 applies, and worker and affected person notices under Article 26.

The organization owns these documents. An implementation partner can help draft the technical file, set up log retention and assemble the evidence, but the partner does not sign off on compliance. Where a conformity route requires it, only an independent notified body issues the outcome. Most Annex III systems use internal control under Annex VI, so the provider's own declaration rests on evidence the provider holds and can produce on request. Confirm with your counsel and notified body, if any, which route applies to each system before you commit budget.

The 2026 Digital Omnibus changes when these documents must exist. Under Regulation (EU) 2026/1744, the high-risk rules apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems, instead of 2 August 2026 and 2 August 2027. Work backward from those dates to decide when each technical file, risk management record and log design must be in place, and confirm the current consolidated text on EUR-Lex before fixing internal deadlines.

What each role must produce, and for how long

A provider that places a high-risk AI system on the EU market, or puts it into service under its own name, must draw up technical documentation before that happens and keep it up to date under Article 11(1). The documentation has to show compliance with the Section 2 requirements and contain at least the elements listed in Annex IV, which are grouped under nine headings. The provider owns this file. An implementation partner can help assemble it, but the provider remains accountable for its accuracy.

General description and development process: the intended purpose, the elements of the system, and how it was designed, built and tested.
Monitoring, control and metrics: how the system functions and is overseen, and why the chosen performance metrics fit its purpose.
Risk management and lifecycle changes: the risk management system, plus records of changes made over the system's life.
Harmonised standards and declaration: which harmonised standards were applied, and a copy of the EU declaration of conformity.
Post-market monitoring: the post-market monitoring system and plan.

Under Article 18(1), the provider must keep the technical documentation, QMS documentation, relevant notified body records and the declaration available to national authorities for 10 years after the system is placed on the market or put into service. Article 47(1) requires a written, machine-readable, physical or electronically signed EU declaration of conformity for each high-risk system, kept for the same period. Confirm with counsel how the 10-year clock applies to systems that are updated or withdrawn.

How long to keep logs and why the periods differ

Providers and deployers keep two different kinds of record for different lengths of time, and the difference follows from what each record proves. Under Article 18(1), a provider keeps its technical documentation, QMS documentation, notified body decisions and the EU declaration of conformity for 10 years after the system is placed on the market or put into service. Article 47(1) sets the same 10-year period for the declaration itself. These are the records an authority would ask for when it reviews how a system was built and whether it met the requirements. By contrast, Articles 19 and 26(6) require logs under the provider's or deployer's control to be kept for a period appropriate to the intended purpose, and for at least six months unless other Union or national law provides otherwise. The six-month floor is a minimum for operational records, not a ceiling.

The organization sets the log period, and it should be able to justify the number it chooses. Start from the intended purpose in the system's documentation: a log that supports incident investigation, complaint handling or a dispute about an individual decision may need to live far longer than one that only supports debugging. Then check other retention duties that apply to the same data, such as employment records, financial or credit records, medical records, and data protection rules that limit how long personal data may be kept. Where a log contains personal data, the shortest period that still serves the purpose is usually the easiest to defend. Record the chosen period, the reasoning and the owner of the decision in the AI governance policy or the QMS.

Confirm sector-specific retention rules with your legal team before setting any log period, particularly in banking, insurance, healthcare, employment and the public sector, where national or sectoral law may require longer retention. Ask counsel to check whether the logs fall under a provider's or deployer's control, since that determines whose duty applies. Confirm also how the organization will delete logs at the end of their period, and whether deletion is itself logged, so that the retention rule can be shown to an assessor.

What changes the documentation effort for your organization

Documentation effort under the AI Act depends less on the size of the organization than on a few structural facts: how many systems it runs, which role it holds for each, and what it already has in place. The cards below cover the decisions that move the workload most, and what to check before you scope the work.

Number and risk tier of AI systems

Start with a count of AI systems and a risk tier for each. Only high-risk systems carry the full Annex IV technical documentation set, the QMS records and the EU declaration of conformity, while transparency-regulated systems mainly need disclosure duties. Systems you have documented as not high-risk still need a recorded rationale, so the inventory itself is a documentation cost. Confirm the tier for each system against the Article 6 and Annex III analysis before you estimate effort.

Provider, deployer or both

The same system can require provider documentation for one purpose and deployer records for another. A provider writes technical documentation and keeps it for 10 years, while a deployer keeps logs under its control and runs an impact assessment where Article 27 applies. Map the role for each system in writing, because a company that customizes a high-risk system or changes its intended purpose may take on provider duties. Settle this before any document is drafted.

Reliance on a third-party general-purpose model

If your system is built on a general-purpose model from another provider, you need that provider's model documentation and training data summary to support your own file. Ask the model provider for the documents it will supply and under what terms, since you cannot write Annex IV content about training data you cannot see. Self-hosting an open-weight model shifts some duties to you as a model or system provider. Confirm which duties apply in your contract and deployment setup.

Existing QMS to extend

Providers of high-risk systems must run a quality management system, and an existing management system such as ISO/IEC 42001 or a documented software quality process can supply much of the structure. The effort falls mainly on mapping existing procedures to the AI Act's QMS elements and adding AI-specific records. Ask whether your current procedures already cover design controls, data governance, and post-market monitoring, and whether their owners and review dates are recorded. Gaps in those areas drive most of the extra work.

Notified body involvement

Most Annex III systems use internal-control conformity assessment, but some biometric systems and Annex I products require a notified body. Where one is involved, the documentation must support its review, and changes it approves must be tracked and retained with the decisions it issues. Ask early whether your system falls in that group and which body is available for it, because its review timetable can set the pace of the whole file. The assessor reviews the file, but your team still prepares it.

Maturity of logging and version control

Logs must be kept for at least six months under Articles 19 and 26(6), and technical documentation must be kept current through every lifecycle change. Systems that already record inputs, outputs, model versions, and configuration changes in retained, tamper-resistant storage need far less rebuilding than systems that rely on ad hoc records. Check whether logs can be tied to a specific model and configuration version, and whether change records link to the affected documentation. Those links are often the hardest part to retrofit.

How to build the documentation file in order

This sequence turns the role and risk decisions for each AI system into a documentation file that an authority can inspect, with the logs, notices and declaration that support it. Each step closes with an output you can check before moving on.

Confirm role and risk classification for each system
Start from the AI system inventory and record, for each system, whether your organization is the provider, the deployer or both, and whether the system falls under an Annex III category, is an Annex I product component, or sits outside the high-risk rules. Legal or compliance owners make the call, with the technical owner confirming how the system is built and used. The output is a signed classification record per system that names the role and the basis for the risk tier. Where a system is built on a third party's general-purpose model, confirm that role too, because it changes which documents you must hold.
Fix the intended purpose in writing
Write down the intended purpose the provider sets for the system, including the context of use, the people affected and the conditions the system must not be used under. This statement drives the risk analysis, the test design, the instructions for use and the deployer's impact assessment, so it must be settled before development documents are written. Product, legal and the risk owner review it together. The output is a versioned intended purpose statement that every later document cites by version number.
Build the Annex IV technical file during development
Open the technical file when design starts, not at release, and keep it current as the system changes. Organize it under the nine headings of Annex IV, covering the general description, development process, monitoring and control, performance metrics, risk management, lifecycle changes, harmonised standards applied, the EU declaration of conformity copy, and the post-market monitoring plan. Engineering, data science and quality teams each own their sections. The output is a file that a reviewer can follow from requirement to test result, with a named owner and a version history for every section.
Set log and retention rules
Decide which logs the system generates, where they are stored and who can read them, and set retention periods that meet the at least six month minimum for logs under your control, unless other Union or national law requires longer. Providers also need a plan to keep the technical documentation, QMS records and declaration for 10 years after the system is placed on the market or put into service. Deployers set the same kind of rule for logs they control. The output is a retention schedule approved by legal and security, plus a tested process that exports logs for an authority.
Complete impact assessments and worker and person notices
Before first use, complete the fundamental rights impact assessment where Article 27 applies to your deployment, and inform workers' representatives and affected workers before a high-risk system is used at the workplace. Where an Annex III system makes or assists decisions about people, prepare the notice that informs those people. Legal, HR and the business owner sign off, and the privacy function checks overlap with any data protection impact assessment. The output is a dated assessment and a set of notices, each linked to the system version it covers, held in the same record set as the logs.
Draft and sign the EU declaration of conformity
For each high-risk system, prepare a written EU declaration of conformity that follows the content of Annex V and confirm that the conformity assessment route used for the system is complete, whether that is internal control or a notified body process. An authorized signatory, usually a senior officer with authority over the product, signs it. Keep the signed declaration with the technical file and make it available to national authorities on request for 10 years. The output is a signed, dated declaration linked to the technical file version it describes.
Schedule updates on every substantial change
Define in advance what counts as a substantial change for each system, such as a new model version, a changed intended purpose or a material change to training data, and route each change through the same record process. Each change updates the technical file, the risk assessment, the logs schedule and the declaration where needed, and the post-market monitoring plan records what was changed and why. Quality owners review the change log at a set cadence. The output is a dated change history that shows the documentation matched the system in use at each point in its life.

Who writes, who approves and who attests

This table compares, for each AI Act document a provider, deployer or model provider must produce, who inside the organization owns it, what an implementation partner can prepare, and who independently assesses or certifies it. Read it as a split of responsibilities: the organization owns and signs its obligations, DeployOpen prepares systems and evidence, and only an independent body issues reports or certificates. Note that the EU declaration of conformity is signed by the provider itself, not by DeployOpen or an auditor.

Document	Owner inside the organization	What DeployOpen can prepare	Who independently assesses or certifies
Technical documentation	Provider's product or AI lead, with engineering and risk owners signing off content	Document templates mapped to the Annex IV headings, system evidence collection, version control setup	National market surveillance authority on request; notified body only where the conformity route requires one
QMS records	Provider's quality manager, accountable to senior management	Procedure drafting, record-keeping tooling, audit trail configuration in the client's systems	Notified body for systems on that route; otherwise the provider's own internal control, checked by authorities on request
EU declaration of conformity	Provider's legal or compliance officer, who signs it for the provider	Draft declaration populated from the technical file, with a record of the version it refers to	None issues it. The provider signs and keeps it; authorities may request it
Deployer logs	Deployer's system owner and IT operations, who control the log retention settings	Logging configuration in the client's environment, retention rules, log export and access controls	Market surveillance authority on request; no certification route applies to logs alone
Fundamental rights impact assessment	Deployer's legal, data protection and business owners, with the people accountable for the use	Assessment template, evidence intake from the system, documentation of the completed assessment	No certification body; the deployer notifies the market surveillance authority as the Act requires
Worker notice	Employer's HR lead, working with worker representatives and works councils	Notice template and a register of systems used at the workplace; no legal advice on local consultation rules	None; authorities may check that notice was given before use
GPAI technical documentation	Model provider's model development lead and compliance owner	Documentation structure aligned to Annex XI, training and evaluation evidence capture in the client's pipeline	AI Office and national competent authorities on request; no certification route
Training content summary	Model provider's data governance lead and legal owner for publication	Draft summary structured on the AI Office template, data source inventory and provenance records	AI Office on request; the summary is published by the provider, not certified

Checks before a document is called complete

A document that exists is not the same as a document that holds up. Each check below asks whether the record can be traced, dated, owned and produced to an authority on request. Together they turn the Annex IV, logging, declaration and impact assessment duties into things an assessor can test.

Version control and change history

Technical documentation must be kept up to date under Article 11(1), so a single current copy is not enough. Check that the documentation sits under version control with a dated change log that records what changed in the system, why, and who approved it. Confirm that each released version can be reconstructed for the period it was placed on the market. Where a change was approved by a notified body, the approval record should sit beside the version it covers. Ask whether a reviewer can pull the documentation as it stood on any past release date.

Log retention evidence

Providers under Article 19 and deployers under Article 26(6) must keep logs under their control for at least six months, unless other Union or national law sets a longer period. A retention policy is not proof that logs survive. Test by picking a date six months back and confirming that the logs from that day can be retrieved, read and tied to a specific system version. Check that rotation, archiving and storage tiers do not silently delete them, and that the period matches any sector rule that applies to your organization.

Dated and signed declaration

Article 47(1) requires a written EU declaration of conformity for each high-risk system, kept for 10 years and given to authorities on request. Check that the declaration carries a date, the system name and version, the provider's identity, and a statement of the standards or specifications applied. Confirm the signature is either a physical signature or an electronic signature that can be verified later. Keep the signed copy in a store that will still be readable after the retention period, and confirm that the version it names matches the technical documentation it refers to.

Traceability to Annex IV headings

Annex IV sets nine headings that the technical documentation must address, from the general description to the post-market monitoring plan. Build a matrix that links each heading to the specific artifact that proves it, such as a risk register, a data governance record, a test report or a monitoring dashboard export. Check that every link resolves to a file that exists and carries the version being documented. A heading with no source artifact is a gap, even if the narrative text is well written. Review the matrix whenever the system changes.

Impact assessment recorded before first use

Article 27(1) requires a fundamental rights impact assessment before the first use of certain Annex III systems by public bodies, private entities providing public services, and deployers of credit scoring and life and health insurance pricing systems. Check that the assessment is completed and dated before the system goes live, not reconstructed afterward. Confirm it records the affected groups, the risks identified, the oversight measures, and what happens if harm occurs. Confirm the assessment is updated when the use case or the system changes, and that the notice to affected people is traceable to it.

Named owner for each document

Every document in the file needs one accountable person, not a team alias, who can answer questions and approve changes. Record the owner's name, role and the date of the last review on the document or in the register that indexes it. Check that the owner is still in post and that the handover for departures is written down. For providers this usually covers the QMS records and technical file. For deployers it covers logs, impact assessments and worker notices. A document without a current owner is a document nobody can defend when an authority asks for it.

Questions teams ask about AI Act documentation

How much effort does an AI Act technical file take, and what drives it?

The effort depends on how many Annex IV elements your system already has documented and how complex the system is. Article 11(1) requires technical documentation drawn up before the system is placed on the market or put into service, kept up to date, and containing at least the Annex IV elements. The main drivers are the number of components and data sources, how much of the risk management system and testing evidence already exists, how often the system changes, and how many harmonised standards you apply. Your costs are mostly internal engineering and compliance time, plus any outside help you buy. Ask any partner to break its estimate down by Annex IV heading, so you can see where the work sits and what is already covered.

Can a small team prepare AI Act documentation without outside help?

A small team can prepare much of the documentation internally if it has clear ownership and someone who understands both the system and the regulation. The work splits across engineering (architecture, data, testing, logs), risk and compliance (risk management, post-market monitoring, declarations) and legal (roles and classification). Outside help is most useful for the classification decision, gap analysis against the requirements, and for building the evidence pipeline, such as logging and version control. Independent assessment is a separate matter: for most Annex III systems, the provider completes internal-control conformity assessment, and only an independent body can issue reports or certificates where a notified body is required.

Does a deployer need to keep the provider's technical file?

A deployer does not normally need to hold the provider's full technical file, but it must have enough information to use the system lawfully. Deployers have their own duties: they must keep the logs under their control for at least six months, unless other Union or national law sets a longer period (Article 26(6)), and they must follow the provider's instructions for use. Ask the provider in writing for the instructions for use, the EU declaration of conformity or its availability, and the log fields it generates. Where you customize or fine-tune a system, your role may shift toward provider, which changes the documentation you owe.

How do the 2026 Digital Omnibus dates change when documents must exist?

The 2026 amendment moved the high-risk deadlines back. As amended, the high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems, instead of 2 August 2026 and 2 August 2027. Regulation (EU) 2026/1744 sets these dates, so plan against that text. The shift changes when documents must be ready for market placement, not the substance of what they must show. Keep the record-keeping periods in mind: providers must keep technical documentation and the EU declaration of conformity for 10 years after placing on the market, which runs from the release date, not from the amendment.

Do open-source model providers still owe a training data summary?

Yes, the open-source exemption does not remove the training data summary duty. Article 53(1)(d) requires providers of general-purpose AI models to draw up and publish a sufficiently detailed summary of the content used for training, following the template the AI Office provided. The Commission published that template on 24 July 2025. Open-source providers may have reduced documentation duties under Article 53(2), but the summary still applies. Confirm with counsel whether your model is in scope and whether it has systemic risk, because that decides the extra obligations in the general-purpose AI rules.

What should I ask a partner or consultant to include in a quote?

Ask for a written scope that names the deliverables, the systems covered and the documents produced. A useful quote lists the Annex IV headings or deployer duties it covers, the evidence it will collect, and what the client must supply, such as system owners, code access and data documentation. It should separate one-time work (the first technical file, gap analysis, policy) from recurring work (log review, updates after changes, post-market monitoring). Confirm who holds the final documents, what happens when the system changes, and that the partner prepares evidence without issuing an assessment report or declaration. DeployOpen works from a written scope agreed before work starts and does not publish a price list.

Can an outside party issue the EU declaration of conformity?

No, the provider issues the EU declaration of conformity. Article 47(1) requires a written, machine-readable, physical or electronically signed declaration for each high-risk system, kept for 10 years and given to authorities on request. The provider takes responsibility for the statement, and an outside party such as a consultant or implementation partner can prepare the draft and the evidence behind it. Where a notified body is involved in the conformity assessment, its role is to assess, not to write your declaration. Confirm with your legal team which signatory your organization will name, and keep the signed version with the technical file.

How DeployOpen prepares AI Act evidence for your team

DeployOpen prepares the systems, records and documents that show how an AI system or model meets its role-specific obligations. Your organization keeps ownership of its controls, and an independent assessor or certification body issues any report or certificate.

How we scope

Engagements are fixed-scope, with the AI systems, roles and documents agreed in writing before work starts.
The written scope states whether you act as provider, deployer, or model provider for each system in view.
Scope lists which Annex IV elements, logs, impact assessments or training summaries are in or out of the work.

How we build

We set up technical documentation templates that follow the Annex IV headings for systems you provide.
We configure log retention for at least six months where the Act applies, and confirm longer periods required by other law.
We test that records, declarations and version history can be produced on request, then document the results.

How we hand over

You receive the documentation set, retention schedule, log configuration notes and an index mapping each record to its owner.
Deliverables are stored in your own infrastructure, so the 10-year retention period stays under your control.
We walk your compliance and engineering staff through each record so they can maintain it after handover.

How we support

Ongoing support, upgrades and documentation updates are available as a retainer after handover.
Retainers can keep technical documentation current as systems change, which Article 11 requires.
Confirm with your assessor which records they will request, and we can prepare the evidence to match.

EU AI Act documentation by role: provider, deployer and model provider