Guide · Evidence management

Updated 6 October 2026 · after the Digital Omnibus

AI Act evidence: an assurance workflow from first draft to authority pack

Which evidence an AI system needs for its role and risk class, who owns it, how long you must keep it, and how to maintain it so that a request from an authority does not turn into a project.

Open the evidence matrix See the product

Evidence per role and risk class
Status model DRAFT → FINAL
Retention: duty vs. recommendation
Authority pack under Art. 21 and 74

app.simpleact.de

Governance Hub

Owners, reviews and evidence per object

Workflows

In review

Overdue

Evidence

RISK_ASSESSMENT

AI-based Application Screening

FINAL

OwnerReviewerDue dateApproval

ANNEX_IV_DOSSIER

Service Chatbot "Lia"

IN REVIEW

OwnerReviewerDue dateApproval

COMPLIANCE_CHECKLIST

Marketing Copy Generator

DRAFT

OwnerReviewerDue dateApproval

Short answer

The evidence you need depends on role and risk class. For minimal risk, AI literacy records (Art. 4) and an inventory entry usually suffice. High-risk providers keep technical documentation, QMS records and the declaration of conformity for ten years (Art. 18, 47); deployers keep logs for at least six months (Art. 26(6)). An assurance workflow keeps it approved, versioned and retrievable.

What this is about

Prove it, don’t claim it: what evidence management means under the AI Act

The AI Act (Regulation (EU) 2024/1689) phrases many obligations not as outcomes but as proof: technical documentation must be “kept up to date” (Art. 11(1)), records must be “kept at the disposal” of authorities for ten years (Art. 18), an assessment under Art. 6(3) must be documented before placing on the market and provided on request (Art. 6(4)), and logs must be kept for at least six months (Art. 19, Art. 26(6)). Meeting an obligation you cannot evidence leaves you little better off in an inspection than not meeting it at all.

Assurance is therefore not an extra documentation project but a way of working: every piece of evidence is linked to a requirement and has an owner, an approval status, a version and a date for its next review. That is what separates it from a file sitting somewhere on a shared drive.

The timetable makes this urgent, but not frantic. Art. 4 (AI literacy) has applied since 2 February 2025 and the transparency obligations under Art. 50 since 2 August 2026. Following the Digital Omnibus (Regulation (EU) 2026/1744), the high-risk obligations in Chapter III, Sections 1 to 3 apply to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028 (Art. 113(c)). Evidence created at the last minute rarely convinces – especially for a risk management system that is meant to run “throughout the entire lifecycle” (Art. 9).

This page covers the lifecycle of the evidence itself. How to prepare for a specific audit and follow up on actions is covered in the audit playbook; who holds which role and who approves is covered in the AI governance framework. Both are linked below.

Technical documentation, QMS and declaration of conformity (Art. 18, 47): 10 yrs; Technical documentation, QMS and declaration of conformity (Art. 18, 47)
Automatically generated logs at provider and deployer (Art. 19, 26(6)): ≥ 6 mo; Automatically generated logs at provider and deployer (Art. 19, 26(6))
High-risk obligations for Annex III systems (Art. 113(c)): 2 Dec 2027; High-risk obligations for Annex III systems (Art. 113(c))

Legal basis

Where the AI Act requires evidence

The key provisions for evidence, retention and disclosure – with the role they apply to and the record that follows from them in practice.

Scroll the table sideways →

Where the AI Act requires evidence
Provision	Content	Who	Evidence in practice
Art. 4	Take measures to support the development of AI literacy among staff and other persons acting on your behalf; no particular level of literacy has to be guaranteed.	Providers and deployers	Training plan per audience, materials, attendance. Art. 4 prescribes no form of evidence – documenting it is a recommendation.
Art. 6(3), (4)	An Annex III system without significant risk is not high-risk (conditions a–d); profiling is always high-risk. The assessment must be documented before placing on the market and provided on request.	Providers	Reasoned assessment per condition with date, author and approval; plus registration under Art. 49(2).
Art. 11, Annex IV	Draw up technical documentation before placing on the market or putting into service and keep it up to date; SMEs and small mid-caps may use a simplified form.	Providers	A dossier per system with version history. Every substantive change creates a new version; the old one is kept.
Art. 12, 19	Automatic recording of events over the lifecycle; providers keep logs under their control for at least six months, unless other law provides otherwise.	Providers	Logging concept with events, storage location, retention rule and access rights; aligned with GDPR erasure periods.
Art. 17	Quality management system covering, among others, change management, test and validation procedures, risk management, post-market monitoring, incident reporting, communication with authorities, documentation systems and an accountability framework; proportionate to the organisation’s size (para. 2).	Providers	Written procedures with owners and a review cycle per document. Point (k) explicitly requires systems and procedures for record-keeping.
Art. 18	Keep for ten years after placing on the market or putting into service: technical documentation, QMS documentation, approved changes, decisions of notified bodies, EU declaration of conformity.	Providers	An archiving rule with a start date per system; access has to survive staff turnover and tool changes.
Art. 21	On a reasoned request, provide all information and documentation needed to demonstrate conformity with Chapter III, Section 2, in a language the authority can easily understand; on request, access to the logs.	Providers	A prepared authority pack built from approved versions; clarify translation needs early.
Art. 26	Deployer obligations: use in line with the instructions (para. 1), human oversight (2), input data (4), monitoring and reporting (5), logs for at least six months (6), informing workers’ representatives (7), informing affected persons (11), cooperation with authorities (12).	Deployers	One record per paragraph – many arise during operation: appointments, review logs, notifications, information letters.
Art. 27	Fundamental rights impact assessment before first use for bodies governed by public law, private entities providing public services and deployers under Annex III point 5(b), (c); update on changes (para. 2); notify the market surveillance authority of the results (para. 3); references to the DPIA allowed (para. 4).	Certain deployers	FRIA as a versioned singleton record; file the notification to the authority with date and content.
Art. 47–49	Draw up the EU declaration of conformity, keep it for ten years and update it where needed; CE marking; registration in the EU database before placing on the market (Annex III, except point 2 – national registration there).	Providers; public authorities as deployers (Art. 49(3))	Signed declaration with version, registration evidence and date in the authority pack.
Art. 50	Transparency: telling people they are interacting with AI, machine-readable marking of synthetic content, informing people about emotion recognition and biometric categorisation, disclosing deepfakes; applies since 2 August 2026.	Providers and deployers	Notice texts, screenshots and marking configuration per release as evidence (recommendation).
Art. 72, 73	Post-market monitoring based on a plan that forms part of the technical documentation; reporting of serious incidents to market surveillance.	Providers	Monitoring plan, periodic evaluations, incident files with deadlines and corrective actions.
Art. 74(12), (13)	Market surveillance gets access to the documentation and to training, validation and testing data sets, where appropriate via API; source code only on a reasoned request and under two conditions.	Providers	A data set register with versions and storage location; agree the access route for authorities in advance.
Art. 99(5)	Supplying incorrect, incomplete or misleading information to notified bodies or authorities: fines of up to €7.5 million or 1% of worldwide annual turnover; SMEs face the lower amount.	All operators	Release only approved, final versions; four-eyes check before sending.

Art. 18, 19, 21, 26 and 27 belong to Chapter III, Sections 2 and 3 and, after the Digital Omnibus, apply to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028. Art. 72 and 73 attach to high-risk systems and therefore become relevant in practice from those dates.

How it works

The assurance workflow in eight steps

From a registered system to a disclosed pack. Steps 1 to 6 run once per piece of evidence, step 7 continuously, step 8 when needed.

1
Register and classify the system
Decision point
Record purpose, context, role (provider or deployer) and risk class – with reasons. Without this classification any evidence list is guesswork. Also check whether your own branding, a substantial modification or a change of purpose turns you into the provider (Art. 25(1)).
Who
Business owner, AI lead
Output
Inventory entry with classification rationale
Basis
Art. 3(3), (4) · Art. 6 · Art. 25
2
Derive the evidence required
Role, risk class and additional traits (public body, workplace, personal data, GPAI model) determine the list. The evidence matrix below shows what that looks like – and that a minimal-risk system has a short list.
Who
AI lead, compliance
Output
Evidence list per system
Basis
Art. 16 · Art. 26 · Art. 27 · Art. 50
3
Assign owners and dates
Every item gets a person who drafts it, one who reviews it and one who approves it, plus a due date. Evidence without an owner reliably goes stale.
Who
AI lead, management
Output
Author, reviewer and approver per item
Basis
Art. 17(1)(m)
4
Draft (DRAFT)
Produce the content and add metadata: requirement, source, validity period, system and version. Link evidence held elsewhere (tickets, test reports, logs) rather than copying it.
Who
Author (business, engineering, IT)
Output
Draft with metadata
Basis
Art. 11 · Art. 17(1)(k)
5
Review (REVIEW)
The reviewer checks the draft against the requirement: is the question answered, are statements backed up, does it match the system as it runs? If not, it goes back with a comment.
Who
Reviewer (second person)
Output
Review note or return
Basis
Recommendation (four-eyes principle)
6
Approve and freeze (APPROVED → FINAL)
Decision point
An authorised person approves; the final version is frozen with version number, date and name. The retention clock starts here – for provider records, ten years from placing on the market or putting into service.
Who
Approver (e.g. management, QM)
Output
Final version with approval record
Basis
Art. 18 · Art. 47
7
Maintain: review cycles and triggers
Fixed review dates (recommendation: annually, more often for risk and monitoring records) plus events that trigger a new version straight away: substantial modification, model or data change, incident, monitoring finding, new user group. The new version starts as a draft again.
Who
Author and reviewer
Output
Current version, history retained
Basis
Art. 9 · Art. 11(1) · Art. 27(2) · Art. 72
8
Bundle and disclose
Decision point
When a request arrives: check the reasons and scope, assemble the matching final versions, settle the language and record what was sent. Only approved material goes out.
Who
Compliance, management
Output
Authority pack with dispatch record
Basis
Art. 21 · Art. 26(12) · Art. 74(12)

Who approves and which bodies are involved is a governance question – see the AI governance framework for suggestions. The steps here apply whether you use a dedicated tool, a document management system or a spreadsheet.

Overview

Types of evidence: what providers and deployers keep

The table maps common evidence to its legal basis. “Duty” means the AI Act or the GDPR explicitly requires the record or the underlying measure. “Recommendation” means sensible but not mandatory.

Scroll the table sideways →

Types of evidence by legal basis, role and retention
Evidence	Basis	Provider	Deployer	Retention / currency
AI literacy measures	Art. 4	Duty (measure)	Duty (measure)	No period set; recommendation: for the period of use and beyond
Inventory entry with classification rationale	Basis for Art. 6; no separate inventory duty	Recommendation	Recommendation	Reassess whenever purpose, model or context changes
Assessment under Art. 6(3)	Art. 6(4), Art. 49(2)	Duty if the derogation is used	Recommendation: request the provider’s assessment	Provide on request; no period stated – recommendation: as technical documentation
Technical documentation (Annex IV)	Art. 11, Art. 18(1)(a)	Duty	–	10 years; always up to date
QMS documentation	Art. 17, Art. 18(1)(b)	Duty	–	10 years
Approved changes, notified body decisions	Art. 18(1)(c), (d)	Duty where applicable	–	10 years
EU declaration of conformity	Art. 47	Duty	Recommendation: file a copy	10 years; update where needed
EU database registration	Art. 49	Duty (Annex III; point 2 national)	Duty for public authorities only (para. 3)	Registration evidence in the authority pack (recommendation)
Automatically generated logs	Art. 12, 19, Art. 26(6)	Duty, where under their control	Duty, where under their control	At least 6 months unless other law provides otherwise
Instructions for use	Art. 13, Art. 26(1)	Duty (draw up)	Duty (follow)	Recommendation: keep the version valid during the period of use
Oversight concept, appointed overseers	Art. 14, Art. 26(2)	Duty (measures)	Duty (people, competence)	Update when staff change
Monitoring plan and evaluations	Art. 72, Art. 26(5)	Duty	Contribution via monitoring and reporting	Plan is part of the technical documentation (10 years)
Incident file	Art. 73, Art. 26(5)	Duty (report)	Duty (inform)	No separate period; recommendation: as technical documentation
Fundamental rights impact assessment	Art. 27	–	Duty for certain deployers	Before first use; update on changes
Informing workers’ representatives	Art. 26(7)	–	Duty (employers, high-risk)	Before putting into service; keep the record (recommendation)
Transparency notices	Art. 50	Duty (paras 1, 2)	Duty (paras 3, 4)	Update when interface or output changes
DPIA, record of processing activities	Art. 35, 30 GDPR; Art. 26(9) AI Act	Duty where controller	Duty where controller	Review when the risk changes (Art. 35(11) GDPR)

The table does not replace a case-by-case assessment. Special rules for financial institutions (Art. 18(3), Art. 19(2)) and for Annex I products (a single set of technical documentation, Art. 11(2)) are not shown.

Status model

The lifecycle of a piece of evidence: from draft to frozen version

Evidence only holds up when it is clear who reviewed and approved it, when – and which version applied at the time.

A four-level status model is enough for most organisations: draft, review, approved, final. What matters is less the number of levels than two rules. First, a final version is never edited. Any change creates a new version that starts as a draft again; the old one stays, with its approval record. Second, whoever drafts does not approve.

The first rule answers a typical authority question: “Which documentation applied on the day of the incident?” If you only have the current version, you cannot answer it. The second rule turns a collection of files into evidence – it reflects the accountability framework that Art. 17(1)(m) requires for the QMS.

Example: a deployer uses a high-risk candidate-ranking system. The appointment of overseers (Art. 26(2)) is final as version 1. One overseer leaves the company; HR creates version 2 as a draft, the team lead reviews it and management approves it. Version 1 remains visible – together with the period during which it applied.

DRAFT

Draft

Work in progress. May be incomplete but is never disclosed. Metadata (requirement, system, author) is set from the first save.

REVIEW

In review

Submitted for review. The reviewer comments or returns it; returns are recorded with a reason.

APPROVED

Approved

Confirmed by an authorised person. Counts as evidence for the linked requirement.

FINAL

Final and frozen

Closed, no longer editable, with version and date. Only this state belongs in an authority pack.

New version

Triggered by a review date or an event. Starts as a draft; the previous version stays as a historical record.

Superseded but retained

Replaced versions stay retrievable until the retention period ends – ten years for provider records.

Triggers for a new version (recommendation): substantial modification within the meaning of Art. 3(23), model or prompt change, new data source, new user group, serious incident, monitoring finding, new instructions for use from the provider.

Interactive

Evidence matrix: which evidence your AI system needs

Choose role, risk class and additional traits – the matrix lists the evidence with its basis, a suggested owner, retention and review rhythm. Duties and recommendations are marked separately.

Your role for this system

Risk class

Additional traits

Public body / FRIA casepublic services or Annex III point 5(b), (c)
Used in the workplaceEmployees are affected
Personal dataGDPR, possibly a DPIA
GPAI model usede.g. a third-party large language model
Art. 6(3) derogationAnnex III system without significant risk

app.simpleact.de

Your evidence list

10 items, 7 of them core

Items: 10
Core: 7
Duty: 7

Core first: an authority will ask for the items marked as core before anything else. Get them to FINAL before you build out the rest.

AI literacy measuresCoreDuty
Training plan per audience, materials and attendance for everyone who operates or uses the system.
Basis
Art. 4
Owner (suggested)
HR
RetentionRecommendation
No period; keep for the period of use
ReviewRecommendation
Annually and for each new system or audience
Inventory entry with classification rationaleCoreRecommendation
Purpose, context, role, risk class and reasons – the starting point of every further evidence list.
Basis
Basis for Art. 6
Owner (suggested)
AI lead
RetentionRecommendation
For as long as the system is in use
ReviewRecommendation
On every change, at least annually
Provider documentsCoreRecommendation
Request and file the instructions for use, declaration of conformity, registration evidence and provider contact.
Basis
Art. 13, Art. 47 (at the provider)
Owner (suggested)
Procurement / vendor management
RetentionRecommendation
For as long as the system is in use
ReviewRecommendation
With every new provider release
Use in line with the instructionsCoreDuty
Technical and organisational measures that ensure the system is used according to its instructions.
Basis
Art. 26(1)
Owner (suggested)
Business owner
RetentionRecommendation
For as long as the system is in use
ReviewRecommendation
When new instructions arrive
Appointment of overseersCoreDuty
Named persons with competence, training, authority and support.
Basis
Art. 26(2)
Owner (suggested)
Business owner
RetentionRecommendation
Each version for the period it applied
ReviewRecommendation
When staff change, at least annually
Operational monitoring and reporting linesCoreDuty
Monitoring based on the instructions, informing the provider, suspending use on risk, reporting chain for serious incidents.
Basis
Art. 26(5)
Owner (suggested)
IT operations
RetentionRecommendation
Notifications: recommendation as incident files
ReviewRecommendation
Quarterly evaluation (recommendation)
Log retention at the deployerCoreDuty
The automatically generated logs under your control, plus a rule on storage and access.
Basis
Art. 26(6)
Owner (suggested)
IT operations
RetentionDuty
At least 6 months (duty), upper limit from data protection
ReviewRecommendation
Check the erasure routine quarterly (recommendation)
Input data checksDuty
How you ensure that input data are relevant and sufficiently representative – to the extent you control them.
Basis
Art. 26(4)
Owner (suggested)
Business owner
RetentionRecommendation
For as long as the system is in use
ReviewRecommendation
With every new data source
Informing affected personsDuty
Notice to people about whom the Annex III system makes or assists decisions.
Basis
Art. 26(11)
Owner (suggested)
Business owner
RetentionRecommendation
Text version per period
ReviewRecommendation
When the procedure changes
Ability to cooperate with authoritiesRecommendation
Contact person, filed deployer records, access to logs and the provider’s contact – so that a request can be answered.
Basis
Art. 26(12)
Owner (suggested)
Compliance
RetentionRecommendation
Correspondence: recommendation as incident files
ReviewRecommendation
Every six months

Notes on your selection

Timetable: high-risk obligations apply to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028.

Simplified guidance, not legal advice. Owners are suggestions; special cases (financial institutions, law enforcement, medical devices) are not covered.

Authority request

Putting together the authority pack

A request from market surveillance is not an audit with months of notice. If the evidence lives in a workflow, you assemble the pack from final versions instead of hunting for them.

Providers of high-risk systems must, on a reasoned request, provide all information and documentation needed to demonstrate conformity, in a language the authority can easily understand (Art. 21(1)), and on request give access to the logs under their control (para. 2). Market surveillance also gets access to the documentation and to the training, validation and testing data sets, where appropriate via an API or other remote access (Art. 74(12)). Access to source code is only granted on a reasoned request and under two conditions (Art. 74(13)). Information received is subject to the confidentiality rules of Art. 78 (Art. 21(3)).

Deployers cooperate with the competent authorities in any action they take (Art. 26(12)). In Germany, the AI market surveillance act (KI-MIG) makes the Federal Network Agency (Bundesnetzagentur) the competent authority unless otherwise provided (section 2(1)); BaFin is responsible for AI systems directly connected with regulated financial activities of the firms it supervises (section 2(3)); for Annex I products, the sectoral market surveillance authorities remain responsible (section 2(2)).

A practical sequence (recommendation): log the request and note the deadline; check its reasons and scope – exactly what is being asked for, and for which system? Then pick the matching final versions, flag open drafts rather than sending them, settle the language, have a second person check the content before it goes out and file the dispatch record. Incorrect, incomplete or misleading information can lead to fines of up to €7.5 million or 1% of worldwide annual turnover (Art. 99(5)) – care comes before speed, and a short holding reply beats a rushed pack.

Cover sheet: system, version, role, risk class, contact person, reference to the request
Classification rationale or assessment under Art. 6(3)
Annex IV technical documentation in the valid version
EU declaration of conformity, CE evidence, registration evidence
QMS extract: procedures for changes, tests, monitoring, incidents
Monitoring plan and latest evaluations (Art. 72)
Logs or the route to access them (Art. 21(2))
Data set register with versions and access route (Art. 74(12))
On the deployer side: FRIA and its notification, oversight appointments, information letters
Table of contents with version and approval date per document

The pack contains only what was asked for. “Sending everything” looks thorough, but it exposes every inaccuracy in documents nobody requested and makes the authority’s review harder.

Retention

Retention periods: telling duties from recommendations

Only a few periods are set out in the law. For the rest you need your own, reasoned rule – checked against data protection.

For logs, the minimum period applies only where Union law – in particular data protection law – or national law does not provide otherwise (Art. 19(1)). If logs contain personal data, retention needs a legal basis and an upper limit. A proven approach (recommendation): a documented period per log type, agreed with the data protection officer, and an erasure routine that itself produces evidence.

For providers, the ten-year period starts per system on placing on the market or putting into service. Where there are several versions, it is sensible (recommendation) to tie the period to each version so that older versions are not deleted too early. For the case of a provider going bankrupt or ceasing activity before the period ends, Member States set the conditions (Art. 18(2)).

Scroll the table sideways →

Retention periods for AI evidence
Record	Period	Source	Type
Technical documentation	10 years from placing on the market / putting into service	Art. 18(1)(a)	Duty
QMS documentation	10 years	Art. 18(1)(b)	Duty
Approved changes, notified body decisions	10 years	Art. 18(1)(c), (d)	Duty
EU declaration of conformity	10 years	Art. 47(1), Art. 18(1)(e)	Duty
Logs at the provider	At least 6 months, appropriate to the intended purpose	Art. 19(1)	Duty
Logs at the deployer	At least 6 months	Art. 26(6)	Duty
Assessment under Art. 6(3)	No period; to be provided on request	Art. 6(4)	Recommendation: 10 years, as technical documentation
FRIA	No period; keep up to date	Art. 27(2)	Recommendation: period of use plus a buffer
AI literacy records	No period	Art. 4	Recommendation: period of use plus a buffer
Incident files, authority correspondence	No separate period	–	Recommendation: as technical documentation

Quality criteria

How to recognise good evidence

Six criteria that reviewers – internal and external – apply to evidence. They also work as a checklist for the review step.

Current

It reflects the system as it runs. Art. 11(1) explicitly requires this for the technical documentation. A review date in the future is the simplest signal.

Versioned

Each approved version has a number, date and validity period. Older versions stay retrievable – otherwise you cannot show the state at an earlier point in time.

Linked

It names the requirement (article, paragraph), the system and the owner. A test report without a link to a requirement only proves that someone ran a test.

Approved

A second, authorised person has reviewed and approved it. Self-approval is the first thing an inspector notices.

Retrievable

It sits in a fixed place under a stable name and is accessible to deputies – not in the personal mailbox of whoever wrote it.

Proportionate

Its scope matches the risk. Art. 17(2) allows a QMS proportionate to size, Art. 11(1) a simplified form for SMEs. More pages are not more proof.

Common mistakes

What makes evidence management fail in practice

Everything for every system

Build the same file for a minimal-risk writing assistant as for a high-risk system and you will soon maintain neither. Classify first, then document.

Evidence after the fact

A risk management file written just before an inspection is not a “continuous iterative process” (Art. 9). Dated interim versions are more credible than a perfect final document.

Overwritten versions

Documents are “updated” by replacing the old file. The state at the time of an incident is lost.

Deployers relying on the provider

The provider’s declaration of conformity does not replace your own deployer records: oversight appointments, logs, informing staff. Those only exist in your organisation.

Logs without a rule

Logs are either not kept or kept indefinitely. Both are open to challenge – at least six months under the AI Act, capped by data protection.

Approval without review

The “approved” status is set because a deadline is looming. A two-sentence review note is worth more than a tick with nothing behind it.

Derogation without a file

An Annex III system is treated as not high-risk under Art. 6(3), but the assessment is nowhere on record and the registration under Art. 49(2) is missing.

A pack built from drafts

Under time pressure, work in progress is sent to an authority. Unapproved content is the biggest risk for “incomplete or misleading information”.

In SimpleAct

An evidence file per AI system – with status, version and authority pack

SimpleAct keeps an assurance file per AI system with 16 record types. Three of them exist exactly once per system: the classification profile, the fundamental rights impact assessment and the authority pack. Which registers you fill depends on risk class and role – for a minimal-risk system, the classification profile and a short risk register are enough.

Status DRAFT, REVIEW, ACTIVE, APPROVED and FINAL for classification, FRIA, data set register and QMS artifacts
Classification profile with a version number that increments on material changes
Authority pack: conformity assessment, declaration of conformity, CE, EU database, authority response
QMS artifacts with a review cycle in days and the next review date
Integration warnings where the file no longer hangs together – e.g. a release without a valid validation suite
Governance module: own evidence with status draft, submitted, approved or rejected; only admins approve, finalisation requires approved evidence

Source: SimpleAct product documentation (Assurance, Governance, Controls). According to the docs, assurance is part of the controls feature in the Starter plan; governance workflows are included from Professional. SimpleAct supports evidence management but does not replace a legal assessment.

Open-Source Framework

simpleact-ai-audit-readiness

Open-source audit readiness framework: checklists, evidence gates, and preparation for regulatory audits under the EU AI Act.

View on GitHub

FAQ

Frequently asked questions about AI evidence and assurance

The main obligation is to take AI literacy measures under Art. 4; the Regulation does not prescribe how to evidence them. A short inventory entry with the reasons for the classification is also recommended. If personal data are processed, GDPR duties apply as well, such as the record of processing activities.

Providers of high-risk systems keep the technical documentation, QMS documentation, approved changes, notified body decisions and the EU declaration of conformity at the authorities’ disposal for ten years after placing on the market or putting into service (Art. 18(1), Art. 47(1)).

At least six months – for providers under Art. 19(1), for deployers under Art. 26(6), in each case where the logs are under their control and other law, in particular data protection law, does not provide otherwise. If the logs contain personal data, the GDPR sets an upper limit.

APPROVED means reviewed and signed off. FINAL means closed and frozen – that version is no longer edited, and changes create a new version. Only final versions belong in an authority pack, because only they show what applied at a given point in time.

Providers must, on a reasoned request, provide all information and documentation needed to demonstrate conformity with the high-risk requirements, in a language the authority can easily understand, and on request access to logs (Art. 21). The authority also gets access to the documentation and to training, validation and testing data sets (Art. 74(12)); source code only under the conditions of Art. 74(13).

Under the KI-MIG, generally the Federal Network Agency (section 2(1)). For AI systems directly connected with regulated financial activities of the firms it supervises, it is BaFin (section 2(3)). For Annex I products, the existing market surveillance authorities remain responsible (section 2(2)).

No. It covers the provider’s obligations. As the deployer of a high-risk system, you keep your own records: use in line with the instructions, appointed overseers, input data, monitoring and notifications, logs, where relevant informing staff and affected persons, and in certain cases a FRIA (Art. 26, 27).

Yes. A provider who considers an Annex III system not to be high-risk documents the assessment before placing it on the market, registers the system under Art. 49(2) and provides the documentation on request (Art. 6(4)). The derogation is excluded where the system profiles natural persons.

The law only fixes that some records must be kept up to date (e.g. Art. 11(1), Art. 27(2)) and that risk management runs continuously (Art. 9). As a recommendation: annual reviews, more often for risk and monitoring records, and immediately after events such as a substantial modification, a model change or an incident.

Yes. SMEs, start-ups and small mid-caps may provide the technical documentation using a simplified Commission form (Art. 11(1)), the QMS is implemented in proportion to size (Art. 17(2)), and SMEs face the lower of the two fine amounts (Art. 99(6)).

More questions? We're happy to help. Send email · Get started

Sources and status

Status: 6 October 2026 · SimpleAct editorial team

This guide is an overview and not legal advice. The text published in the Official Journal of the EU is authoritative. Owners and review rhythms are recommendations to be adapted to your organisation.

Changes

2026-10-06 – Page rebuilt: evidence matrix, legal basis after the Digital Omnibus, status model, retention periods, authority pack and common mistakes.
2026-04-03 – First published as a product page on assurance workflows.

Maintain evidence instead of hunting for it

See in a demo how SimpleAct keeps evidence per AI system with status, version and authority pack – or try it yourself.

Book a demo Try free for 7 days

AI Act evidence: an assurance workflow from first draft to authority pack

Prove it, don’t claim it: what evidence management means under the AI Act

Where the AI Act requires evidence

The assurance workflow in eight steps

Register and classify the system

Derive the evidence required

Assign owners and dates

Draft (DRAFT)

Review (REVIEW)

Approve and freeze (APPROVED → FINAL)

Maintain: review cycles and triggers

Bundle and disclose

Types of evidence: what providers and deployers keep

The lifecycle of a piece of evidence: from draft to frozen version

Draft

In review

Approved

Final and frozen

New version

Superseded but retained

Evidence matrix: which evidence your AI system needs

Putting together the authority pack

Retention periods: telling duties from recommendations

How to recognise good evidence

Current

Versioned

Linked

Approved

Retrievable

Proportionate

What makes evidence management fail in practice

Everything for every system

Evidence after the fact

Overwritten versions

Deployers relying on the provider

Logs without a rule

Approval without review

Derogation without a file

A pack built from drafts

An evidence file per AI system – with status, version and authority pack

Frequently asked questions about AI evidence and assurance

Sources and status

Changes

Further reading

Maintain evidence instead of hunting for it