Building an AI Act Evidence Pack: What to Collect and When
What goes in an AI Act evidence pack: what to collect, which Article it serves, who owns it and when to refresh.
Most AI Act work will be won by whoever can open a folder, on a regulator's or a customer's request, and show what the system is, what was decided about it and what it has been doing. That folder is an evidence pack. This post lays out what goes in it, who owns each piece and what should trigger a refresh.
Last verified 2026-10-06. This is not legal advice.
What an evidence pack is, and is not
An evidence pack is a maintained set of records that lets you answer the same question repeatedly: show me how this AI system was classified, built, tested, overseen and monitored. The goal is audit-ready by construction: evidence on demand, not assembled in a panic.
It is not a conformity assessment. It supports a conformity effort. For high-risk systems the formal steps (conformity assessment, CE marking, registration under Article 49) are separate duties for the provider.
Under the Digital Omnibus on AI (Regulation (EU) 2026/1744), Annex III high-risk obligations now apply from 2 December 2027, not 2 August 2026. The Commission's timeline and our AI Act timeline page track the dates. That is runway: use it to build the pack while the requirements are still ahead of you. Some duties already apply: AI literacy (Article 4) since 2 February 2025 and Article 50 transparency from 2 August 2026.
Two roles, one pack
The AI Act (Regulation (EU) 2024/1689) treats providers and deployers differently, and a pack should say which hat you wear for each system.
- Providers carry the Article 16 duties: the Articles 9 to 15 requirements, a quality management system under Article 17, conformity assessment, registration, post-market monitoring (Article 72) and serious-incident reporting (Article 73).
- Deployers carry the Article 26 duties: use the system per its instructions, assign competent human oversight, monitor and report, and keep the automatically generated logs under their control for at least six months (Article 26(6)).
- The line can move. Under Article 25, a deployer becomes a provider by putting its name on a high-risk system, making a substantial modification, or changing the intended purpose so that a system becomes high-risk. Role classification is therefore the first artifact.
The pack, section by section
1. Inventory and role classification
One row per AI system: purpose, owner, models used, data categories, users affected, and your role (provider, deployer, or both). Include shadow tools, which inventories routinely miss (see shadow AI).
2. Risk classification memo
Record why the system is or is not high-risk. If it falls under Annex III but you rely on the Article 6(3) derogation (a narrow procedural task, improving a completed human activity, detecting patterns without replacing human assessment, or a preparatory task), the provider must document that assessment under Article 6(4). A system that profiles natural persons is always high-risk. According to Bird & Bird, the Commission's draft guidelines read the derogation conditions narrowly, so write the reasoning down. Use the high-risk checklist to structure the memo.
3. Risk management file (Article 9)
Identified risks, mitigations, residual risk, and how you tested. Keep versions.
4. Data governance record (Article 10)
Where training, validation and input data came from and how it was prepared. The Omnibus adds an Article 4a legal basis to process special-category data for bias detection and correction where strictly necessary; if you rely on it, record why.
5. Technical documentation (Article 11, Annex IV)
The provider's central file. The Omnibus extends simplified technical documentation to small mid-caps as well as SMEs.
6. Logs (Article 12)
Providers retain logs under Article 19; deployers keep those under their control for at least six months under Article 26(6). The pack should hold a retention schedule and a sample of real logs. For what to capture in practice, see LLM observability and prompt analytics.
7. Instructions for use (Article 13)
The information a deployer needs to use the system correctly. Deployers also use it for their GDPR Article 35 DPIA under Article 26(9).
8. Human-oversight design and approvals (Article 14)
Who can intervene, with what authority, and what the interface lets them see. Deployers must assign oversight to competent, trained and authorised people (Article 26(2)), so include the training and the authorization record.
9. Accuracy, robustness and cybersecurity results (Article 15)
Test plans, results, and the dates they were run.
10. Quality management system (Article 17)
Your procedures for the above. Note the standards position: no harmonised standard has been cited in the Official Journal yet, so there is no presumption of conformity from harmonised standards today. The Commission's standardisation FAQ says the first are expected in 2026. The Commission also says an AI management-system standard like ISO/IEC 42001 does not match the Act's QMS requirement. ISO/IEC 42001 is useful structure for organizing the work, but it gives no presumption of conformity.
11. AI literacy measures (Article 4)
Training records, role-based. After the Omnibus, Article 4 asks providers and deployers to take measures to support literacy, with no guaranteed specific level. See AI literacy under Article 4.
12. Transparency and marking records (Article 50)
Record what you disclose and how synthetic outputs are marked. The Commission published a voluntary Code of Practice on marking and labelling AI-generated content on 10 June 2026. Generative systems already on the market before 2 August 2026 have until 2 December 2026 for the machine-readable marking in Article 50(2).
13. FRIA and DPIA cross-reference (Article 27)
Public bodies, private entities providing public services, and deployers of credit-scoring and life or health insurance systems must assess fundamental-rights impact before first use and notify the market surveillance authority (Article 27). It complements the DPIA, so cross-reference the two documents.
14. GPAI supplier documentation (Article 53, Annex XII)
If you build on a general-purpose model, collect what the model provider owes downstream providers: the information set out in Annex XII, plus their public training-content summary and copyright policy. Ask for it in procurement and file the answer. See GPAI obligations.
15. Incident log
Serious incidents, near misses, suspensions and what changed afterward. Deployers must monitor and report risks and serious incidents and suspend use where needed (Article 26(5)); providers report under Article 73.
The pack as a table
| Artifact | Article | Owner | Refresh trigger | Trust Fabric facet that produces it |
|---|---|---|---|---|
| AI inventory and role classification | Art 25 | AI governance lead | New system, new use, role change | Identity, Risk |
| Risk classification memo | Art 6(3), 6(4) | Legal and product | Change of intended purpose | Risk, Compliance |
| Risk management file | Art 9 | Product risk owner | Model or data change, incident | Risk, Monitoring |
| Data governance record | Art 10 | Data owner | New data source or retraining | Data controls, Privacy |
| Technical documentation | Art 11, Annex IV | Engineering | Substantial modification | Evidence, Traceability |
| Logs and retention schedule | Art 12, 19, 26(6) | Platform and security | Logging change, retention review | Auditability, Traceability |
| Instructions for use | Art 13 | Product | Release | Policy, Evidence |
| Human-oversight design and approvals | Art 14, 26(2) | Business owner | Autonomy level change | Human oversight, Access |
| Accuracy, robustness, cybersecurity tests | Art 15 | Engineering and security | Model change, new threat | Security, Monitoring |
| Quality management system | Art 17 | Quality lead | Annual and on standards citation | Compliance, Policy |
| AI literacy records | Art 4 | HR and AI governance | New hires, new tools | Compliance |
| Transparency and marking records | Art 50 | Product and legal | New generative feature | Policy, Evidence |
| FRIA and DPIA cross-reference | Art 27, GDPR 35 | Legal and DPO | New deployment context | Privacy, Risk |
| GPAI supplier documentation | Art 53, Annex XII | Procurement | Model version change | Evidence, Risk |
| Incident log | Art 26(5), 73 | Security and operations | Every incident | Monitoring, Traceability |
The facet column reflects where the Trust and Governance Fabric is designed to produce or support the record.
How to start without boiling the ocean
- Inventory first. A spreadsheet is fine. Classify each system by role and risk.
- Pick one system that is likely high-risk or customer-facing and build its pack end to end. The gaps you find become your template.
- Capture automatically where you can. Records produced as a by-product of running the system are cheaper and more credible than reconstructed ones.
- Set refresh triggers, not calendar reminders: model swaps, new data and changes of purpose force an update.
- Rehearse a request. Ask someone outside the team to find the risk memo and last test result in ten minutes.
Penalties are the reason to bother. Under Article 99, breaches of operator obligations such as the Article 26 deployer duties can reach EUR 15 million or 3% of worldwide annual turnover. Article 99(7) lists the technical and organizational measures in place and cooperation as factors, which is where a well-kept pack helps. See AI Act penalties.
How Swfte supports this
Swfte is built for Europe, with AI Act readiness as a design goal, and the platform is designed to let you produce evidence on demand rather than assemble it afterward. The Trust and Governance Fabric covers thirteen facets, from Identity and Access to Auditability, Traceability and Evidence, and a Trust Profile records identity, owner, risk level, approved models, data residency, human approval rules, retention and audit for each AI system. Swfte provides the technical controls, governance mechanisms and evidence to support deployment within applicable requirements; the exact posture depends on use case, jurisdiction, deployment and configuration. Start from /eu, then see /platform/governance, /platform/sovereignty, /platform/trust-profile and /trust for the current position, including what is still in progress.
This is not legal advice. An evidence pack supports a conformity effort; it is not a conformity assessment, and your obligations depend on your role and use case.