Conformity assessment
A procedure initiated by the provider before a high-risk system is placed on the market. It results in the declaration of conformity and CE marking. Deployers do not carry out conformity assessment.
Guide · AI audit
Updated 6 October 2026 · after the Digital Omnibus
AI Act audit preparation: a practical playbook
Who audits your AI – and what will they ask for first? This guide separates conformity assessment, requests from authorities and audits, lists the documents for the auditor’s file and shows how to turn gaps into an action plan with owners and due dates.
- Who audits what – five types of review
- Auditor’s file with articles and retention
- Audit playbook: actions, owners, status
- Readiness check with the three largest gaps
app.simpleact.de
Audit Log & Export
247 of 312 entries
ENA
Audit readiness
Audit-readyComplete
Partial
Missing
EU Declaration of Conformity (Art. 47)
PDF · DE/EN · incl. audit history
| Action | Entity | Event | ||
|---|---|---|---|---|
| UPDATE | Risk Assessment | Re-assessment completed | A. Schmidt | 2026-08-18 |
| CREATE | Evidence | Evidence "DPIA report" added | T. Müller | 2026-08-15 |
| UPDATE | Governance | Approved by reviewer | L. Weber | 2026-08-11 |
| CREATE | AI System | System "Chatbot Lia" created | A. Schmidt | 2026-08-02 |
Short answer
The AI Act has no general “AI audit”. Compliance is reviewed through conformity assessment (Art. 43), market surveillance (Art. 74) and reasoned requests from authorities (Art. 21, Art. 26(12)); internal audit and customer audits come on top. Preparing means organising inventory, classification, documentation, logs and oversight so that every requirement can be evidenced.
Context
What people mean by “AI audit” – and what they don’t
Inside a company, anything that looks like scrutiny gets called an audit: a large customer asking about your AI use, an internal audit questionnaire, a conversation with the data protection authority. The AI Act (Regulation (EU) 2024/1689) barely uses the word. It speaks of conformity assessment – the process of assessing whether a high-risk AI system meets the requirements of Chapter III, Section 2 (Art. 3(20)). And it speaks of market surveillance by national authorities (Art. 74). Audits are expressly mentioned, for example, where a notified body regularly checks a provider’s approved quality management system (Annex VII, point 5.3).
For your preparation this distinction is not hair-splitting. A provider has to initiate conformity assessment itself before placing a system on the market. A request from an authority comes from outside, often with a short deadline, and incorrect or incomplete answers can be fined in their own right (Art. 99(5)). A customer audit, by contrast, follows the contract – the AI Act sets neither its scope nor its procedure. Knowing which kind of review is coming tells you which documents you need and in how much depth.
The good news: the documents overlap heavily. An up-to-date AI inventory, a reasoned classification for each system, the technical documentation or the providers’ instructions for use, retained logs, named oversight persons and evidence of AI literacy measures carry you through almost any review. This guide sorts them by type of review, names the articles and shows how to work through missing items as actions with an owner, a due date and a status.
On timing: since the Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026), the high-risk requirements apply to Annex III systems from 2 December 2027 and to Annex I products from 2 August 2028 (Art. 113(c)). Already reviewable today are the prohibitions (Art. 5) and AI literacy (Art. 4), both since 2 February 2025, and the transparency obligations under Art. 50 since 2 August 2026. An audit playbook pays off now – not just before the deadline.
- Retention of technical documentation, QMS documentation, declaration of conformity (Art. 18, Art. 47)
- 10 years
- Retention of technical documentation, QMS documentation, declaration of conformity (Art. 18, Art. 47)
- Logs kept by providers and deployers (Art. 19, Art. 26(6))
- ≥ 6 mo.
- Logs kept by providers and deployers (Art. 19, Art. 26(6))
- High-risk obligations for Annex III systems (Art. 113)
- 2 Dec 2027
- High-risk obligations for Annex III systems (Art. 113)
Legal basis
The provisions that decide what an auditor may see
The table lists the provisions that authorities, notified bodies and your own preparation rely on. Chapter III obligations for high-risk systems become practically relevant from 2 December 2027 (Annex III) or 2 August 2028 (Annex I).
Scroll the table sideways →
| Provision | Content | Applies to | What it means for a review |
|---|---|---|---|
| Art. 3(20), (22) | Conformity assessment is the process of assessing whether the requirements for high-risk AI are met; a notified body is a conformity assessment body that has been notified. | Providers | Makes clear that “audit” is not a legal term of its own. Always ask first which basis a review relies on. |
| Art. 4 | Providers and deployers take measures to support the development of AI literacy among their staff; no particular level has to be guaranteed. | Providers, deployers | Applies since 2 Feb 2025. Auditors ask for measures and evidence: who, which content, when. |
| Art. 6(3), (4) | An Annex III system can be considered not high-risk where there is no significant risk; the provider documents the assessment before placing it on the market, registers under Art. 49(2) and provides the documentation on request. | Providers | A frequent review point: anyone relying on the exception needs a dated, reasoned assessment. |
| Art. 11 · Annex IV | Technical documentation drawn up before placing on the market, kept up to date, with at least the information in Annex IV; SMEs and small mid-caps may use a simplified form. | Providers | The core document of every conformity assessment and authority review. |
| Art. 17 | Quality management system covering, among other things, change management, test and validation procedures, risk management, post-market monitoring, incident reporting, communication with authorities and an accountability framework – proportionate to size. | Providers | Under Annex VII, the subject of regular audits by the notified body. |
| Art. 18, 19 | Keep technical documentation, QMS documentation, approved changes, decisions of notified bodies and the declaration of conformity for 10 years; keep logs for at least six months. | Providers | Auditors ask where things are stored, which versions exist and who has access – not only about content. |
| Art. 21 | Upon a reasoned request, providers supply all information and documentation needed to demonstrate conformity, in a language easily understood by the authority; access to logs where applicable. | Providers | The typical “request from an authority”. Define the routine and the contact person in advance. |
| Art. 26 | Deployers use the system in line with the instructions for use, assign oversight to competent persons, monitor operation, keep logs for at least six months, inform workers and cooperate with authorities (para. 12). | Deployers | For most mid-sized companies the main review point: evidence of proper operation. |
| Art. 43 · Annex VI, VII | Annex III points 2–8: internal control without a notified body. Annex III point 1: internal control or notified body, depending on the use of harmonised standards. New assessment after a substantial modification. | Providers | Decides whether an external assessor is involved at all. |
| Art. 44 | Certificates from notified bodies are valid for at most five years (Annex I) or four years (Annex III); suspension or withdrawal where requirements are no longer met. | Providers | Validity periods and follow-up audits belong in the review calendar. |
| Art. 47–49 | EU declaration of conformity (kept for 10 years), CE marking, registration in the EU database before placing on the market or putting into service. | Providers, public deployers | Formal evidence – quick to check and embarrassing when missing. |
| Art. 72, 73 | Post-market monitoring based on a plan (part of Annex IV); reporting of serious incidents within 15 days at the latest, 2 days for a widespread infringement or critical infrastructure, 10 days in the event of a death. | Providers (deployers via Art. 26(5)) | Auditors want to see that data from operation is actually analysed. |
| Art. 74(12), (13) | Market surveillance gets access to the documentation and to training, validation and testing data sets, where appropriate via API or remotely; source code only upon a reasoned request when other means have been exhausted. | Providers | Data sets and their origin must be retrievable – not merely described. |
| Art. 99(5) | Incorrect, incomplete or misleading information supplied to notified bodies or competent authorities: up to €7.5 million or 1 % of worldwide annual turnover; for SMEs the lower amount. | All operators | An honest gap with an action plan beats a polished answer. |
| KI-MIG § 2 (Germany) | The Federal Network Agency is the competent market surveillance authority unless otherwise provided; BaFin for AI directly connected with regulated financial activities; authorities for Annex I products remain competent. | Everyone in Germany | Tells you where a request will realistically come from. |
Article texts checked on 6 October 2026 in the consolidated version after Regulation (EU) 2026/1744. Summaries are abridged; the wording in the Official Journal prevails.
How it works
From the reason for the review to a closed finding
Seven steps that work for a request from an authority, a customer audit and internal audit alike. The depth depends on the type of review, the order does not.
- 1
Clarify the reason and the basis
DecisionWho is reviewing, on what basis, with which deadline? A request from the Federal Network Agency under Art. 21 calls for a different answer than a supplier questionnaire. With authorities, always ask in writing for the exact question and note the deadline.
- Who
- Compliance, legal
- Output
- Review brief with basis, scope, deadline
- Basis
- Art. 21, 26(12), 74
- 2
Set the scope and a reference date
Which AI systems are affected, in which role (provider, deployer), as of which date? Without a reference date the auditor compares documents from different points in time – the most common cause of follow-up questions.
- Who
- Compliance, IT
- Output
- System list with role and reference date
- Basis
- Art. 3(3), (4) · Art. 25
- 3
Assemble the auditor’s file
Bring inventory, classifications, technical documentation or instructions for use, QMS, logs, oversight concept, literacy evidence, incident register and formal evidence together in one place – versioned, with storage location and owner.
- Who
- System owners, compliance
- Output
- Auditor’s file with a table of contents
- Basis
- Art. 11, 17, 18, 19, 26
- 4
Self-assessment and gap list
Check every requirement against the file: evidenced, partly evidenced, missing. Stay honest – a documented gap with an action is easier for any auditor to place than a claim without evidence.
- Who
- Compliance, internal audit if available
- Output
- Gap list per system and article
- Basis
- Art. 43 · Annex VI
- 5
Set up the audit playbook
DecisionEvery gap becomes an action with an owner, a due date, a priority and a status. Anything deliberately deferred gets a justification. The result is the action plan you can show the auditor.
- Who
- Compliance, business units
- Output
- Action plan with status
- Basis
- Art. 17(1)(a), (m)
- 6
Dry run on a sample
Recommendation: pick one system and review it the way an outsider would – request the documents, retrieve one day’s logs, interview the oversight person. Shows whether the file holds up when it matters.
- Who
- Internal audit or a colleague from another team
- Output
- Dry-run record
- Basis
- Recommendation
- 7
Accompany the review and follow up
Name one contact person, log every document handed over, turn findings into new actions and record the closure. With authorities, approve answers before they are sent.
- Who
- Compliance, management
- Output
- Handover log, findings list, closing note
- Basis
- Art. 21 · Art. 99(5)
For providers with a notified body (Annex VII), this sequence does not replace the body’s procedure – it prepares for it.
Who audits what
Five types of review – and what each one asks for
Before you collect documents, find out who is asking. The basis decides the scope, the deadline and the consequences of an incomplete answer.
Scroll the table sideways →
| Type of review | Typical trigger | Basis | What is requested first |
|---|---|---|---|
| Market surveillance authority (in Germany usually the Federal Network Agency, BaFin in the financial sector) | Complaint (Art. 85), incident report, sweep, tip-off from the market | Art. 74 with Regulation (EU) 2019/1020, Art. 21, Art. 26(12), KI-MIG § 2 | Technical documentation, declaration of conformity, logs; for providers possibly training, validation and testing data (Art. 74(12)) |
| Notified body | Conformity assessment under Annex VII, regular surveillance audits, renewal of the certificate | Art. 43, Art. 44, Annex VII points 3–5 | QMS documentation under Art. 17, technical documentation per system, access to premises used for design, development and testing |
| Internal control by the provider itself | Before placing a high-risk system under Annex III points 2–8 on the market; after a substantial modification | Art. 43(2), (4) · Annex VI | Check of QMS, technical documentation and post-market monitoring – the provider assesses itself and is accountable for it |
| Internal audit | Audit plan, mandate from management or the supervisory board, an incident | Company law, internal policies – not the AI Act | Inventory, roles and responsibilities, classifications, action plan with status |
| Customer or supplier audit | Tender, contract renewal, the customer’s own duties as a deployer | Contract, data processing agreement, purchasing terms | Classification, instructions for use, input for the customer’s DPIA (Art. 26(9)), incident process |
| Statutory auditor, certification body (e.g. ISO/IEC 42001) | Audit of IT-supported processes in the annual audit, voluntary certification | Engagement letter or standard requirements | Management system, roles, risk assessment, control evidence – does not replace conformity assessment under Art. 43 |
In addition, the data protection authority reviews under the GDPR whenever personal data is processed. Many documents (DPIA, records of processing) overlap, but the legal basis is different.
Distinctions
Conformity assessment, request from an authority, audit: three different things
Requests and market surveillance
Triggered from outside, often by a specific event. The authority sets scope and deadline. Incorrect or incomplete information is itself subject to fines (Art. 99(5)).
Surveillance audit by the notified body
The one place where the AI Act expressly speaks of regular audits: the body checks that the approved QMS is maintained and applied, and may carry out additional tests.
Customer and supplier audits
The scope follows from the contract. Often the customer, as a deployer, wants to know whether it can meet its own Art. 26 duties – instructions for use, logs and incident process.
Internal audit
Checks whether your own organisation works: responsibilities, approvals, action tracking. A good dress rehearsal for any external review.
A complaint as the trigger
Any natural or legal person may lodge a complaint with the market surveillance authority. Many requests start here – without any warning to the company.
Auditor’s file
The documents an auditor wants to see first
The order reflects what is requested first in practice: the overview, then the reasoning, then the evidence from operation.
Scroll the table sideways →
| Document | Article | Provider / deployer | Retention |
|---|---|---|---|
| AI inventory with purpose, owner, provider, role | Basis for Art. 4, 6, 16, 26 | both | Recommendation: always current, version the snapshots |
| Classification per system with reasoning and date | Art. 5, 6, 50 | both | Recommendation: as long as the system is in use, plus the documentation period |
| “Not high-risk” assessment under Art. 6(3) | Art. 6(4), Art. 49(2) | provider | Drawn up before placing on the market, provided on request |
| Technical documentation under Annex IV | Art. 11, 18 | provider | 10 years from placing on the market / putting into service |
| QMS documentation | Art. 17, 18 | provider | 10 years |
| Risk management documentation | Art. 9 · Annex IV point 5 | provider | Part of the technical documentation (10 years) |
| Post-market monitoring plan | Art. 72 · Annex IV point 9 | provider | Part of the technical documentation |
| EU declaration of conformity, CE, proof of registration | Art. 47, 48, 49 | provider | Declaration of conformity 10 years |
| Decisions and certificates of notified bodies | Art. 18, 44 | provider (Annex VII) | 10 years; certificate valid for max. 4 or 5 years |
| Automatically generated logs | Art. 12, 19, 26(6) | both, as far as under their control | at least 6 months, longer where other law requires |
| Provider’s instructions for use and evidence of use in line with them | Art. 13, 26(1) | deployer | Recommendation: as long as in use |
| Oversight concept with named persons and authority | Art. 14, 26(2) | both | Recommendation: version the snapshots |
| AI literacy evidence (participants, content, date) | Art. 4 | both | No statutory period; recommendation: for the duration of the role |
| Information of worker representatives, DPIA, FRIA where required | Art. 26(7), (9) · Art. 27 | deployer | Keep DPIA and FRIA current; FRIA result goes to the authority |
| Incident register, reports, corrective actions | Art. 20, 26(5), 73 | both | Recommendation: at least as long as the technical documentation |
| Action plan (audit playbook) with status and justifications | Art. 17(1)(a), (m) (providers) | both | Recommendation: export a snapshot at every review date |
Periods without an article reference are recommendations. Set by law are the 10 years under Art. 18 and Art. 47 and the minimum of six months under Art. 19 and Art. 26(6).
Interactive
Audit readiness check: where would an auditor dig first?
Answer the statements for your organisation or a single system. Choose your role – the check then shows only the statements that apply. The result shows the status per area and the three documents an auditor would most likely request first.
app.simpleact.de
Your result
0 of 16 statements answered
ENA
No answers yet
–
Answer the statements – your result appears here.
Status per area
- Inventory & roles0%
- Classification0%
- Documentation0%
- Operation & logs0%
- Oversight & literacy0%
- Incidents & authorities0%
What an auditor would request first
Answer the statements – the three largest gaps will appear here with a concrete next step.
Self-assessment without warranty. The check does not replace a review, a conformity assessment or legal advice. Your answers are not stored or transmitted.
Building the audit playbook
Turning the gap list into an action plan
An audit playbook is simply an action plan that ties every gap to a person, a due date and a piece of evidence. What matters is that it also shows what was deliberately not done – and why.
Auditors rarely expect perfection. They want to see that you know your gaps and manage them. A plan with twenty open items, each with an owner, a realistic due date and a justification, is more convincing than a checklist where everything is ticked but no evidence sits behind the ticks.
Prioritise with two questions: how serious is the gap for health, safety or fundamental rights? And how quickly would an auditor find it? Missing logs, a missing classification or a high-risk system without a named oversight person stand out in any sample. Wording issues in the technical documentation can wait.
Example: an engineering company deploys an AI tool that pre-screens job applicants (Annex III point 4) and does not keep logs for six months. Action: “Agree log retention with the provider and set it to six months”, owner: head of IT, due in four weeks, high priority, reference Art. 26(6). A second action, “Inform the works council about the deployment” (Art. 26(7)), gets its own line because it has a different owner.
Scroll the table sideways →
| Field | Content | Example |
|---|---|---|
| Action | A concrete, verifiable task – not a topic | “Write down the Art. 6(3) reasoning for ticket routing” |
| Reference | Article, annex or internal policy | Art. 6(4) |
| System | The affected AI system from the inventory | Support classifier v2 |
| Owner | One person who carries out the action – not a team | Product owner, support |
| Due date | The date the owner has committed to | 31 Oct 2026 |
| Priority | High, medium, low – by risk and visibility | high |
| Status | Open, in progress, done, deliberately deferred | in progress |
| Evidence | Where the result sits once done | Classifications folder / version 3 |
| Justification when deferred | Why not now, who decided, when to revisit | “System replaced on 1 Feb 2027; management decision of 2 Oct 2026” |
A status of “done” without evidence is an open item for an auditor. Agree that actions are only closed with linked evidence.
30-day preparation
When the review has been announced: a four-week proposal
A recommendation, not a statutory procedure. With a request from an authority, the authority’s deadline applies – compress the plan accordingly.
Reason, scope, team
Clarify basis and deadline, fix the affected systems and roles, name one contact person. Inform management. Set a reference date for all documents.
Fill the file
Collect inventory extract, classifications, technical documentation or instructions for use, oversight concept and literacy evidence. Record missing pieces as actions straight away rather than collecting them first.
Close the visible gaps
Start with what shows up in every sample: logs, classification reasoning, named oversight persons, incident process. Everything else goes into the plan with a realistic due date and a justification.
Dry run
Review one system as an outsider would: request documents, retrieve the logs for a reference date, interview the oversight person. Feed the results into the plan.
Approval and handover
Freeze the file (dated export), have answers to authorities legally reviewed and approved, prepare the handover list. Hand over only what has been requested.
Buffer and follow-up
Answer follow-up questions and log what was handed over. After the review, turn every finding into an action with an owner and record the closure.
Typical findings
Where reviews get stuck in practice
These points are not statistics but patterns that come up again and again during preparation. Each of them can be fixed before the review.
An inventory without shadow AI
The inventory lists the officially procured systems but not the AI features in office software, CRM or HR tools. The auditor asks in the business unit – and finds more.
Classification without reasoning
“Minimal risk” is in the list, but nobody can say why. Without a check against Art. 5, Annex III and Art. 50, the classification is just a claim.
Art. 6(3) exception without documentation
An Annex III use case is treated as not high-risk, but the assessment was never written down and registration under Art. 49(2) was never checked.
Logs exist but are out of reach
The provider stores logs, the deployer has no access or does not know for how long. Art. 26(6) requires at least six months as far as the logs are under the deployer’s control – that needs to be settled in the contract.
Oversight only on paper
A “human oversight” role is named, but the person knows neither the system’s limits nor their authority to stop it. Art. 26(2) requires competence, training and authority.
Training without evidence
Everyone was “informed”, but there is no attendance list, no content, no date. For Art. 4 what counts is which measures you took – and that can only be shown with evidence.
No incident process with deadlines
Nobody knows who recognises a serious incident, who informs the provider and when the 2-, 10- or 15-day period under Art. 73 starts.
Documents without a version
Technical documentation, instructions for use and classification date from different months and contradict each other. A reference date and a version on every document prevent this.
Handing over more than asked
Out of caution the whole file is sent – including internal drafts and comments. Hand over what was requested and log it.
Timeline
What can be reviewed today – and what comes in 2027
Many companies postpone audit preparation because, after the Digital Omnibus, the high-risk obligations only apply from 2 December 2027 (Annex III) or 2 August 2028 (Annex I). That is only half the story. Market surveillance can already check today whether prohibited practices under Art. 5 are in use, whether AI literacy measures under Art. 4 have been taken and whether the transparency obligations under Art. 50 are met – for example telling people that they are interacting with an AI system, or deployers disclosing deepfakes.
For high-risk systems an early start pays off for a practical reason: technical documentation, risk management and a QMS are not built in four weeks. If you have an inventory and reasoned classifications today, you can build the rest methodically by the end of 2027; if you start in 2027, you will be working under pressure.
- Since 2 Feb 2025: prohibitions (Art. 5) and AI literacy (Art. 4)
- Since 2 Aug 2025: obligations for GPAI models, governance, penalties
- Since 2 Aug 2026: general application, transparency obligations under Art. 50
- From 2 Dec 2027: high-risk obligations for Annex III systems (incl. Art. 9–27)
- From 2 Aug 2028: high-risk obligations for products under Annex I
- Art. 72 and 73 relate to high-risk systems and become practically relevant from these dates
With SimpleAct
Actions, evidence and change history in one place
In SimpleAct’s audit playbook you create actions for each AI system – with an owner, a due date, a priority and a status. Gaps from legal logic and risk assessment become tasks, and the current state can be exported as part of the compliance report.
- Actions per system with title, description, due date, owner and priority (LOW, MEDIUM, HIGH)
- Status OPEN, IN_PROGRESS, DONE or SKIPPED – skipping with a justification in the comment
- Export as PDF or DOCX with inventory, assessments, checklist status and change history
- Audit trail as a hash chain with old and new values; integrity verification you can run yourself
- Evidence register with approval by admins and finalisation gates (Governance)
- Audit readiness score from the Professional plan
Access to the audit playbook requires audit permission. Governance and Legal Logic are marked as PRO modules in the app. SimpleAct structures the preparation; it replaces neither a review nor legal advice.
Open-Source Framework
simpleact-ai-governance-playbook
Open-source playbook: article mappings, action templates, and audit items for the EU AI Act – ready to use in SimpleAct.
FAQ
Frequently asked questions about AI audits
There is no general audit obligation. Providers of high-risk systems must carry out a conformity assessment before placing them on the market (Art. 43). Authorities can request documents as part of market surveillance (Art. 21, Art. 74). Regular audits in the narrow sense are foreseen for notified bodies monitoring an approved QMS (Annex VII, point 5.3).
Under § 2 KI-MIG, the Federal Network Agency is in principle the competent market surveillance authority. For AI systems directly connected with regulated financial activities of the companies it supervises, it is BaFin. For products under Annex I, the existing market surveillance authorities remain competent.
No. Conformity assessment is the provider’s job. Deployers must use the system in line with the instructions for use, assign oversight to competent persons, monitor operation, keep logs for at least six months and cooperate with authorities (Art. 26). Anyone offering a system under their own name or substantially modifying it can, however, become a provider (Art. 25).
In practice usually the overview: AI inventory, roles and classifications. Then, depending on the role, technical documentation and QMS (providers) or instructions for use, logs and the oversight concept (deployers). AI literacy evidence under Art. 4 and the incident procedure are requested almost every time.
Market surveillance gets access to the documentation and to training, validation and testing data sets as far as needed for its tasks – also via API or remotely (Art. 74(12)). Source code only upon a reasoned request, and only where it is necessary for the assessment and other means have been exhausted (Art. 74(13)).
Gaps alone are not a separate offence – incorrect, incomplete or misleading answers to requests for information are (Art. 99(5): up to €7.5 million or 1 % of annual turnover, the lower amount for SMEs). Name gaps openly and enclose the action plan with due dates. Breaching the underlying obligation can be sanctioned separately.
No. A management system under ISO/IEC 42001 helps organise roles, risk assessment and controls, and many documents can be reused. It does not replace conformity assessment under Art. 43 or the duties under Art. 26.
Providers keep technical documentation, QMS documentation, approved changes, decisions of notified bodies and the EU declaration of conformity for 10 years (Art. 18, Art. 47). Providers and deployers keep logs for at least six months as far as they are under their control (Art. 19, Art. 26(6)). For other documents the AI Act sets no period.
Yes. Prohibitions (Art. 5), AI literacy (Art. 4) and transparency obligations (Art. 50) already apply and can be reviewed. And the documents for high-risk systems – technical documentation, risk management, QMS – take months, not weeks.
For every gap, an action with concrete content, reference (article), system, owner, due date, priority, status and evidence. Anything deliberately deferred gets a justification with the decision-maker and a review date. Export the state as of the review date.
More questions? We're happy to help. Send email · Get started
Sources, status and changes
Updated: · SimpleAct editorial team
- Regulation (EU) 2024/1689 (AI Act), EUR-Lex
- Regulation (EU) 2026/1744 (Digital Omnibus), EUR-Lex
- Art. 21 AI Act – Cooperation with competent authorities
- Art. 26 AI Act – Obligations of deployers
- Art. 43 AI Act – Conformity assessment
- Art. 74 AI Act – Market surveillance
- Annex IV AI Act – Technical documentation
- Annex VII AI Act – Assessment of QMS and technical documentation
- German AI Market Surveillance Act (KI-MIG)
This guide gives a general overview and is not legal advice. Whether and which obligations apply to your company depends on the individual case. Examples are marked as such; recommendations are not statutory duties.
Changes
- 2026-10-06 – Page rebuilt: distinction between conformity assessment, requests from authorities and audits, types of review, auditor’s file with retention periods, action plan, 30-day preparation, readiness check; dates after the Digital Omnibus.
- 2026-04-01 – First published as a product page for the audit playbook.
Start your next review with organised documents
Inventory, classification, actions and evidence in one system – with owners, due dates and a traceable change history.