Start with Maditon
← Back to Resource Center
EU AI Act · Documentation 7 min read

Audit-ready compliance dossier template for the EU AI Act

What a regulator-ready EU AI Act compliance dossier actually contains — section by section, with the Annex IV mapping for high-risk providers.


When a supervisory authority writes to ask “show me your EU AI Act compliance documentation for system X,” you have two outcomes. The first is producing one self-contained document in under an hour. The second is spending three weeks chasing fragments across Google Drive, Slack, and the inboxes of people who left the company. This guide is what the first one looks like.

It’s structured to satisfy Article 11 + Annex IV (technical documentation for high-risk providers), Article 26 (deployer records), and the Article 27 FRIA in one document.

Section 1 — Organisation summary

  • Legal entity, organisation number, registered office
  • Authorised representative in the EU (for non-EU providers)
  • Contact for AI matters — name, email
  • The system’s role in the organisation (revenue product, internal tool, marketing surface)

Section 2 — AI system identity

  • Internal name and version
  • External / trade name if different
  • Date placed on the market (or first deployment)
  • Status (live, withdrawn, recalled)
  • EU database registration ID, if applicable

Section 3 — Intended use and context

  • Description of intended purpose (the substantive answer, not marketing copy)
  • Foreseeable uses outside the intended purpose
  • Reasonably foreseeable misuse
  • Categories of natural persons potentially affected
  • Member States where the system is placed on the market

This is the section the Annex III classification hangs on. Be specific. “Helps with hiring” is not specific. “Ranks candidate applications by predicted job fit using résumé content” is.

Section 4 — Risk classification

  • Risk tier (prohibited / high / limited / minimal)
  • Reasoning (which Annex III categories considered, conclusion, why)
  • If using Article 6(3) carve-out: which path (a/b/c/d), why the system does not profile natural persons
  • Reviewer attribution (name, role, date, reviewer notes)

This section is the AI Act’s evidence of human accountability. The named reviewer with a timestamp is the load-bearing claim.

Section 5 — System architecture (Annex IV, item 2)

  • General description of the AI system
  • Models used, model versions, model providers (especially for GPAI)
  • Data flows: input sources, processing, output destinations
  • Infrastructure: where it runs, who hosts it
  • Integrations with other systems

Section 6 — Data governance (Annex IV, item 3)

For high-risk systems, this is the heaviest section. Cover:

  • Training, validation, and test data — sources, volumes, dates
  • Data labelling, cleaning, augmentation methodologies
  • Examination for bias (gender, age, ethnicity, disability)
  • Identification of data gaps and shortcomings
  • Decisions on representativeness
  • Whether personal data was used, and the GDPR lawful basis

For limited-risk and minimal-risk systems, a shorter version covers data flow and lawful basis.

Section 7 — Performance and accuracy (Annex IV, item 4)

  • Metrics used to evaluate the system
  • Accuracy levels and benchmarks
  • Robustness and cybersecurity test results
  • Known limitations (where the system underperforms)
  • Comparison to alternatives, if relevant

Honest performance disclosure. Overclaiming here is a Tier 3 fineable offence (Article 99(5): supplying incorrect, incomplete, or misleading information to notified bodies or national authorities).

Section 8 — Risk management (Article 9)

  • Known risks identified
  • Foreseeable misuse considered
  • Risks to fundamental rights identified
  • Mitigation measures, by risk
  • Residual risk assessment
  • How risks will be monitored post-deployment

For deployers running a Fundamental Rights Impact Assessment (Article 27), this section largely doubles as the FRIA.

Section 9 — Human oversight design (Article 14)

  • Description of human-oversight measures built into the system
  • Required competencies for human overseers
  • Authority and ability to override or stop the system
  • Training for human overseers
  • For deployers: identity of the assigned human overseer(s)

Section 10 — Transparency to users (Articles 13, 50)

  • What users are told about the system
  • How the disclosure is made (UI screenshots, exact copy)
  • Instructions for use provided to deployers (for providers)
  • Information provided to affected persons (for deployers)

Section 11 — Compliance checklist status

  • The full list of obligations (provider/deployer-specific)
  • Status of each (complete, in progress, not started)
  • Evidence reference (link to underlying document)
  • Outstanding actions with target dates

Section 12 — Reviewer notes and acceptance

  • Reviewer notes attached to the risk classification
  • Reviewer notes attached to each significant decision
  • Final acceptance by named human, with timestamp

Section 13 — Audit log

  • All material actions taken against the system
  • Created, updated, classified, accepted, overridden, deleted
  • Each entry: timestamp, user, action, metadata

Section 14 — Evidence inventory

  • Files uploaded (technical documentation drafts, DPIAs, vendor DPAs, testing reports, post-market monitoring data)
  • Title, type, last update date, storage location

The files themselves don’t need to be in the dossier; the inventory does.

Section 15 — Vendor and supplier information (Article 25, AI Act + Article 28, GDPR)

  • For providers using third-party components: provider information per Article 25
  • For deployers: vendor information, sub-processor list, DPA reference

Section 16 — Conformity assessment (high-risk providers, Article 43)

  • Procedure used (internal control per Annex VI, or third-party assessment per Annex VII)
  • Notified body identity, if used
  • Conformity assessment date and result
  • Declaration of conformity reference and date

Section 17 — Post-market monitoring plan (Article 72)

  • What metrics are monitored
  • Frequency of review
  • Triggers for re-evaluation or recall
  • Reporting channels for serious incidents (Article 73)

The PDF/A-1b format

The dossier should be exported as PDF/A-1b — the ISO archival format. This matters because:

  • PDF/A is the format auditors and regulators expect for long-term storage
  • The format is self-contained — no fonts or images missing if opened in 2040
  • Many supervisory authorities specify PDF/A in their submission portals
  • The Adobe / Microsoft 365 default PDF is not PDF/A — it’ll work today but may degrade

Maditon generates the dossier in PDF/A-1b natively. If you’re producing it by hand, use a dedicated PDF/A export tool (most professional PDF generators offer it).

What’s notably not in this dossier

  • Customer contracts — those live in your CLM
  • Marketing claims — those live in your marketing CMS
  • Source code — never required by the Act
  • Training data itself — only the methodology and governance

Don’t pad the dossier. Auditors look for substance, not volume.

How to produce one in under an hour

You can’t, the first time. The first dossier per system takes 1–3 days of focused effort if you have your records in order. But once the structure exists and the records are kept in a single tool, regenerating an updated dossier on demand should take less than an hour. That’s the architectural goal of the Maditon compliance dossier — one click, archival-quality, current as of the latest reviewer note.