We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Compliance checklistEU

EU AI Act Compliance checklist

Check each AI tool, decide which duties apply, and give every action an owner and evidence link.

Start with your use case and role. Then check risk, notices, model duties and what you must keep after release.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 21, 2026
7 sections9 primary sources
Overview

Use one checklist for each AI system or model. Record what it does, who supplies and uses it, and why the AI Act applies. Follow the sections that match your role and use case.

Section 1

1. Identify the tool and your role

Create one record for each AI system, general-purpose AI (GPAI) model or product that integrates a model. State whether you supply it to the EU market, first put it into use, use it in the EU, or use its output in the EU.

Record the role before assigning obligations. The AI Act distinguishes providers, deployers, importers, distributors, authorised representatives, product manufacturers, downstream providers, and affected persons. A company can hold more than one role for the same AI value chain.

The original Article 5 prohibitions have applied since 2 February 2025 and most GPAI duties since 2 August 2025.

Regulation (EU) 2026/1744 was published on 24 July 2026 and entered into force on 27 July. The general application date remains 2 August 2026. Chapter III Sections 1-3, except Article 6(5), apply from 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Article 6(1) product-linked systems.

  • System or model identity: product name, version, intended purpose, deployment context, EU market or EU-use trigger, and whether the item is an AI system, general-purpose AI model, or both.
  • Role evidence: provider or deployer analysis, importer or distributor involvement, authorised representative need for non-EU providers, and any downstream provider integrating a GPAI model.
  • Out-of-scope checks: purely personal non-professional deployer use; systems or models developed and put into service solely for scientific research and development; pre-market research, testing, or development except real-world testing; exclusively military, defence, or national-security use; and the limited Article 2(12) exclusion for open-source AI systems.
  • Check data protection, privacy, consumer protection, product safety, labour, sector and fundamental-rights law even for minimal-risk or out-of-scope uses.
Section 2

2. Check the risk category

Screen for prohibited uses first. Stop or redesign a prohibited use before deployment. For high-risk systems, collect the evidence in the next section. Check transparency duties for their specific triggers, including where the system is also high-risk.

For minimal or no risk, keep your reasoning and review it when the purpose, data, users or integration changes.

For Annex III systems, do not rely only on the sector label. Record the intended purpose, whether the system materially influences decision-making, whether profiling of natural persons is performed, and whether a narrow-task or preparatory-task exception is being claimed.

  • Screen prohibited uses: manipulation or deception causing significant harm, exploitation of vulnerabilities, social scoring, criminal-risk assessment based solely on profiling or personality traits, and untargeted scraping of facial images.
  • Also screen workplace or education emotion inference, sensitive biometric categorisation and real-time remote biometric identification for law enforcement. Check the precise legal conditions and exceptions, including permitted medical or safety emotion-recognition uses.
  • From 2 December 2026, also screen the new Article 5(1)(ba) and (bb) prohibitions concerning specified non-consensual intimate material and child sexual abuse material.
  • High-risk route A: the AI system is a product, or safety component of a product, covered by listed Union harmonisation legislation and the product requires third-party conformity assessment.
  • High-risk route B: the AI system falls within Annex III areas such as biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration or border control, or administration of justice and democratic processes.
  • Annex III exception record: establish no significant risk of harm, match at least one Article 6(3) condition, and confirm that the system does not profile natural persons. Conditions cover a narrow procedural task, improvement of completed human work, properly reviewed decision-pattern detection, or preparation for an Annex III assessment.
  • Annex III exception record: document the assessment before market placement or service entry and retain the Article 49(2) registration record.
  • GPAI model route: decide whether the item is a general-purpose AI model, whether open-source exemptions apply, and whether systemic-risk classification or notification duties are triggered.
  • Transparency route: identify direct human interaction, synthetic audio/image/video/text generation, emotion recognition, biometric categorisation, deepfake generation, or AI-generated public-interest text.
Section 3

3. Collect high-risk system evidence

Before supplying or first using a high-risk AI system, assemble the provider evidence. It must let authorities and any required assessor check compliance. Give deployers the instructions they need to use and monitor the system.

For product-linked systems, first distinguish Annex I Section A from Section B. Section A systems use the relevant sector-law assessment with applicable AI Act requirements included. Amended Article 2(2) limits which AI Act provisions apply directly to Section B systems, including machinery; check the relevant sector rules before assigning this standalone evidence list.

Record any applicable delegated-act limitation under Article 2(13), rather than assuming that overlapping product controls waive AI Act duties.

Assign a quality-management owner to each high-risk system and version. EN 18286:2026 has been cited in the Official Journal since 14 October 2026, with presumption of conformity limited to covered requirements. Check Annex ZA conditions and record uncovered obligations before relying on the standard.

  • Risk management: lifecycle process for known and reasonably foreseeable risks to health, safety, and fundamental rights; reasonably foreseeable misuse; residual-risk acceptability; testing; and vulnerable-group impacts.
  • Data governance: data origin, collection, preparation, assumptions, availability, suitability, bias examination, mitigation measures, and data gaps for training, validation, and testing data sets.
  • Technical documentation: intended purpose, versions, interfaces, development methods, design choices, architecture, data requirements, human-oversight measures, validation and testing, cybersecurity, standards used, EU declaration of conformity, and post-market monitoring plan.
  • Logging and records: implement automatic event logging where required and identify provider-controlled logs under Article 19. Retain Article 18 technical documentation, quality-management documentation, notified-body documents where applicable, and the EU declaration of conformity for 10 years.
  • Keep provider-controlled logs for a period appropriate to the intended purpose and at least six months, unless applicable Union or national law provides otherwise, particularly data-protection law. Record that Article 19 decision separately from the 10-year document period.
  • Human oversight and instructions: deployer-facing information on capabilities, limitations, accuracy, robustness, cybersecurity, foreseeable risks, input data, interpretation of outputs, oversight measures, maintenance, and log collection.
  • Conformity and market access: relevant conformity assessment under Article 43, EU declaration of conformity, CE marking, Article 49 registration where applicable, and new conformity assessment after substantial modification.
  • Standards adoption check: record EN 18286 edition and applied clauses, current Official Journal citation, Annex ZA coverage and conditions, named owner, system version, approved QMS procedures and evidence links. Assign remaining actions, including Article 17(2)-(4), and verify the complete Annex IV file before relying on Article 11(1), first-sentence coverage.
Section 4

4. Check GPAI model provider duties

Keep a separate model record for a general-purpose AI model. Where Article 53 applies, the model provider needs technical documentation, information for companies integrating the model, a copyright policy and a public training-content summary.

For GPAI models with systemic risk, meaning models whose capabilities can create large-scale risks across the EU, add evaluation, mitigation, cybersecurity and serious-incident records. Check these model-provider duties separately from any application review.

  • Article 53(1)(a) technical documentation: record training, testing, evaluation results, and the minimum Annex XI information, unless the specific Article 53(2) open-source exception applies.
  • Downstream documentation: information for providers integrating the model so they can understand capabilities and limitations and meet their own AI Act obligations.
  • Copyright and training-content evidence: copyright-policy record and public summary of training content using the AI Office template where applicable.
  • Open-source check: the Article 53(2) exception covers technical documentation and downstream information only when the licence permits access, use, modification, and distribution and the weights, architecture, and usage information are public. Copyright-policy and public training-content summary duties remain. No Article 53(2) exception applies to GPAI models with systemic risk.
  • Systemic-risk screen: record training compute or Commission designation indicators, notification status, model-evaluation evidence, adversarial testing, systemic-risk mitigation, serious-incident process, and cybersecurity protection for the model and physical infrastructure.
  • Representative check: non-EU GPAI providers should record whether an EU authorised representative mandate is required and retained.
Section 5

5. Add the required notices and labels

Check Article 50 for every relevant system, including high-risk systems. Record when users must see a notice, when synthetic outputs need a machine-readable mark, and when content needs a disclosure.

Keep the implementation evidence close to the product artifact: screenshots, UI copy, API fields, machine-readable marking approach, accessibility review, and the release version in which the notice or marker ships.

Track the Article 50(2) marking transition separately: systems placed on the market before 2 August 2026 have until 2 December 2026 to comply with that provider duty. This transition does not postpone the other Article 50 notices or deployer disclosures.

  • Direct interaction: inform natural persons that they are interacting with an AI system unless that is obvious to a reasonably well-informed, observant, and circumspect person in the context.
  • Synthetic content: providers of AI systems that generate synthetic audio, image, video, or text content should record the machine-readable marking and detectability method, plus limits where the system is only assistive editing or does not substantially alter input semantics.
  • Emotion recognition and biometric categorisation: deployers should inform exposed natural persons of the system operation and align personal-data processing with applicable data-protection law.
  • Deepfakes: deployers disclose artificially generated or manipulated image, audio, or video constituting a deepfake, unless the law-enforcement exception applies. Evidently artistic, creative, satirical, fictional, or analogous works still require appropriate disclosure that does not hamper their display or enjoyment.
  • Public-interest text: deployers should disclose AI-generated or manipulated text published to inform the public on matters of public interest unless the law-enforcement or human-review/editorial-responsibility exception applies.
  • Notice quality: provide the information clearly, distinguishably, accessibly, and no later than the first interaction or exposure.
Section 6

6. Plan monitoring and incident reporting

Name the owner and records for monitoring after release. High-risk providers need a documented monitoring system and plan. Deployers need a route to tell providers and authorities about risks and serious incidents.

Incident playbooks should separate high-risk AI system reporting from GPAI systemic-risk reporting, because the recipients and templates can differ.

  • Post-market plan: active and systematic collection, documentation, and analysis of performance data throughout the high-risk AI system lifetime, including deployer-provided data and other sources where relevant.
  • Deployer monitoring: instructions-based monitoring, provider and authority escalation where use may present a risk, suspension of use where required, and serious-incident notification escalation.
  • High-risk serious incidents: provider report to the market surveillance authorities where the incident occurred, or to the AI Office where Article 75(1a) applies; report immediately after causal link or reasonable likelihood is established and within the Article 73 outer deadlines.
  • Investigation record: incident timeline, causal-link analysis, risk assessment, corrective actions, authority and notified-body cooperation, and a control to avoid altering the system in a way that could affect later evaluation before informing competent authorities.
  • GPAI systemic-risk incident record: tracking, documentation, reporting to the AI Office and, where appropriate, national competent authorities, plus possible corrective measures.
  • Retention cross-check: keep technical documentation, quality-management documentation, EU declaration of conformity, authorised-representative documentation where applicable, and incident or monitoring evidence in the owning compliance repository.
Section 7

7. Keep a record you can review

Use the fields below to build your inventory and evidence table. Control access to confidential company records and identify which references may be shared publicly.

Reopen the row when the intended purpose changes, a GPAI model or supplier changes, the system enters a new Annex III use case, a transparency trigger is added, a serious incident occurs, or a competent authority, notified body, customer, or internal approver requests new evidence.

  • Inventory fields: AI system or model name, version, owner, intended purpose, EU trigger, role, users, affected persons, data categories, supplier or model dependency, and release status.
  • Classification fields: prohibited-practice result, high-risk route, Annex III area, Article 6(3) exception reasoning if used, GPAI status, systemic-risk status, Article 50 transparency trigger, and final classification approver.
  • Control fields: required obligation set, implementation artifact, evidence owner, approving function, due milestone, release blocker, and reassessment trigger.
  • Evidence fields: source URL, source-supported claim, policy or procedure link, technical documentation link, test or validation report, data-governance record, human-oversight record, UI notice or marker, conformity artifact, post-market plan, and incident record.
  • Authority-facing fields: EU database registration status where applicable, notified-body involvement, market surveillance authority contact path, AI Office contact path for GPAI matters, and confidentiality or trade-secret handling note.
Next step

Review your AI Act checklist

Check your classification decisions, assigned actions and missing evidence with Sorena.

Research workflow
Research the cited requirements

Check classification, high-risk evidence, model duties and notices against the cited sources.

Explore next step
Talk to Sorena
Discuss your evidence gaps

Check your classification decisions, assigned actions and missing evidence with Sorena.

Explore next step
Primary sources

References and citations

Regulation (EU) 2024/1689 (EU AI Act)
eur-lex.europa.eu8 citations
Referenced sections
  • Primary legal text for scope, operator roles, prohibited practices, high-risk classification, high-risk obligations, GPAI obligations, transparency obligations, post-market monitoring, serious-incident reporting, and evidence retention.
  • Supports the scope check, operator-role definitions, and exclusions that determine whether a checklist row needs AI Act controls.
  • Primary source for prohibited practices, Article 6 high-risk classification rules, Annex III high-risk areas, GPAI systemic-risk classification, and Article 50 transparency triggers.
Show 5 more
  • Supports the high-risk evidence checklist from Articles 9 to 19, Articles 43, 47, 48, 49, and Annex IV.
  • Primary source for GPAI definitions, Article 51 systemic-risk classification, Article 53 provider obligations, Article 54 representative obligations, Article 55 systemic-risk obligations, and Annex XI/XII documentation.
  • Primary source for Article 50 transparency duties for direct interaction, synthetic content, emotion recognition, biometric categorisation, deepfakes, and public-interest text.
  • Primary source for Article 72 post-market monitoring, Article 73 high-risk serious-incident reporting, deployer monitoring duties, and Article 55 GPAI systemic-risk incident duties.
  • Supports the evidence fields by requiring documentation, logging, conformity, registration, transparency, post-market, incident, and authority-cooperation records across the relevant AI Act provisions.
"specific requirements for high-risk AI systems and obligations for operators of such systems"
More quoted passages
"harmonised rules for the placing on the market, the putting into service, and the use of AI systems in the Union"
"The following AI practices shall be prohibited"
"The technical documentation of a high-risk AI system shall be drawn up before that system is placed on the market or put into service"
"Providers of general-purpose AI models shall"
"The information referred to in paragraphs 1 to 4 shall be provided to the natural persons concerned in a clear and distinguishable manner"
"Providers shall establish and document a post-market monitoring system"
"provide that authority all the information and documentation necessary to demonstrate the conformity"
European Commission - AI Act regulatory framework
digital-strategy.ec.europa.eu5 citations
Referenced sections
  • Commission overview used for risk-tier framing and practical high-risk provider workflow context.
  • Explains the AI Act as a risk-based framework for AI developers and deployers and provides the public Commission overview used to orient the checklist.
  • Supports the four-level risk framing used in the checklist: unacceptable, high, limited, and minimal or no risk.
Show 2 more
  • Summarizes practical provider steps for high-risk AI systems, including conformity assessment, registration, declaration of conformity, and CE marking.
  • Supports the checklist structure by summarizing how providers, deployers, authorities, and post-market responsibilities interact after high-risk AI systems are on the market.
"risk-based rules for AI developers and deployers"
More quoted passages
"four levels of risk"
"A declaration of conformity needs to be signed and the AI system should bear the CE marking."
"providers have a post-market monitoring system in place"
European Commission - AI Act serious incident template for GPAI systemic-risk models
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Commission source for the GPAI systemic-risk serious-incident reporting template and Article 55 reporting context.
  • Commission source for the reporting template and operational context for serious incidents involving GPAI models with systemic risk.
"providers are required to report relevant information on serious incidents to the AI Office"
More quoted passages
"serious incidents involving general-purpose AI models with systemic risk"
European Commission - Code of Practice on AI-generated content
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Commission source for Article 50 marking and labelling implementation work for AI-generated and manipulated content.
  • Commission page explaining the Article 50 marking and labelling workstreams for AI-generated or manipulated content.
"transparency obligations related to marking and labelling of AI-generated content"
More quoted passages
"marking and labelling of AI-generated content"
European Commission - GPAI provider guidelines
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Commission guidance source for interpreting GPAI provider scope, systemic-risk notification context, significant modifications, and open-source exemptions.
  • Commission guidance source for interpreting GPAI provider scope, significant modifications, open-source exemptions, and enforcement timeline context.
"Guidelines for providers of general-purpose AI models"
More quoted passages
"only those making significant modifications need to comply"
European Commission - Public summary of GPAI training content template
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Official template page for the Article 53(1)(d) public summary of content used to train GPAI models.
  • Supports the checklist item requiring a public summary of content used to train GPAI models under Article 53(1)(d).
"public summary of training content"
More quoted passages
"Template for the Public Summary of Training Content"
Regulation (EU) 2026/1744 - Digital Omnibus on AI
eur-lex.europa.eu
Referenced sections
  • Binding amendment published on 24 July 2026 and entering into force on 27 July 2026; supports the revised Chapter III application dates and the Article 75(1a) serious-incident reporting route to the AI Office. Article 1(2)-(3) supports product-sector routing and Article 1(39) supports the existing-system Article 50(2) transition.

Related guides

Common questions, clear answers | EU AI Act

Clear answers on AI Act scope, risk categories, provider and user duties, general-purpose models, disclosures, rights, assessments and deadlines.

EU AI Act deadlines and compliance calendar

Find the AI Act deadline for your system or model. Check high-risk dates, transparency duties, older-model transitions and the evidence to prepare.

EU AI Act fundamental rights impact assessments

Check who needs an Article 27 fundamental rights impact assessment, what it must contain and how DPIA reuse, notification and registration work.

EU AI Act GPAI model evidence checklist

Collect model documentation, integration information, copyright records and training summaries. Add testing, incident and security records for systemic risk.

EU AI Act monitoring and serious incidents

Set up high-risk AI monitoring, identify serious incidents and check reporting deadlines, recipients, deployer escalation and corrective action.

EU AI Act penalties and fines

Check the AI Act fine tiers, smaller-organisation caps, GPAI provider fines and the facts authorities consider when deciding a penalty.

Show all related guides (34)

EU AI Act serious incident reporting steps

Check serious-incident harm, preserve evidence and choose the reporting deadline and recipient for high-risk AI systems and systemic-risk GPAI models.

EU AI Act timeline and phased deadlines

See which AI Act rules apply now and what comes next. Check high-risk dates, older-model transitions and the difference between legal and standards dates.

EU AI Act vs ISO/IEC 42001

Compare AI Act legal duties with ISO/IEC 42001 management-system requirements. See which records can be reused and what certification does and does not cover.

EU AI Act vs NIST AI RMF

Compare AI Act legal duties with the voluntary NIST AI RMF. Map risk records to specific requirements and identify legal steps that need separate evidence.

EU AI Act: Check whether the Act applies

Use five checks to establish AI Act scope, exclusions, your role, risk categories and evidence for the decision.

EU AI Act: Choose a high-risk assessment route

Choose between provider-run internal control, notified-body assessment and a product-law procedure before release.

EU AI Act: Classify a tool before approval

Classify an AI tool or model before purchase or release. Check EU scope, prohibited uses, high-risk rules, transparency and GPAI duties.

EU AI Act: Conformity assessment

Some high-risk systems use a provider-run assessment. Others need an authorised independent assessor or a product-law assessment.

EU AI Act: Does it apply to you?

Check whether the AI Act applies to your system or model, identify your provider or deployer role, and keep evidence for the decision.

EU AI Act: Duties for general-purpose AI models

Check GPAI provider duties for documentation, integrator information, copyright and training summaries, plus extra requirements for systemic-risk models.

EU AI Act: High-risk requirements

High-risk providers must meet system requirements before supply. Deployers must use and monitor the system under the provider's instructions.

EU AI Act: High-risk system checklist

Check the system's risk controls, data, documentation, logs, instructions, human oversight and testing before release.

EU AI Act: Is your use case high-risk?

Find high-risk AI examples in recruitment, banking, education, healthcare, public services and products. Check Article 6 conditions and exceptions.

EU AI Act: Plan your compliance work

Build a compliance plan for each AI tool: your role, the duties that apply, the evidence needed and the person responsible.

EU AI Act: Standards and quality management

Use EN 18286:2026 to organise provider quality-management procedures and keep evidence that they work for each high-risk system.

EU AI Act: Technical file and evidence templates

Build the technical file and provider records for a high-risk AI system, with owners and evidence links for each field.

EU AI Act: When must you disclose AI?

Check Article 50 chatbot notices, synthetic-output marking, biometric notices, deepfake disclosures and public-interest text exceptions.

EU AI Act: Which AI uses are banned?

Check Article 5 prohibited AI practices, the narrow exceptions, evidence to retain and the new content prohibitions from 2 December 2026.

Are you the provider or the deployer? | EU AI Act

Check provider, deployer, importer and distributor roles, when changes create provider duties, and how model and system responsibilities differ.

Do you need a notified body? | EU AI Act

Find the assessment route for high-risk AI, when a notified body is required, and which declaration, CE-marking and registration records you need.

Does this tool count as AI? | EU AI Act

Check whether software counts as AI, how models differ from systems, when embedded AI is high-risk, and which scope and role evidence to keep.

How do you monitor AI after release? | EU AI Act

Understand high-risk AI monitoring under Article 72: the provider plan, deployer feedback, logs, corrective action, incidents and change reviews.

Is this industry use high-risk? | EU AI Act

See which industry AI uses fall under Annex III, when Article 6(3) can apply, and what providers must document and register.

What belongs in the technical file? | EU AI Act

See what Article 11 and Annex IV require in high-risk AI technical documentation, from system identity and testing to monitoring and retention.

What must general-purpose model providers do? | EU AI Act

Check general-purpose model duties, systemic-risk classification, open-source conditions, copyright, training summaries, incidents and application dates.

When must you disclose AI use? | EU AI Act

Check AI interaction notices, technical content marking, biometric notices, deepfake and text disclosures, exceptions, accessibility and deadlines.

When must you report a serious incident? | EU AI Act

Check serious-incident outcomes, reporting roles, 15-, 10- and two-day deadlines, authority recipients, corrective action and the separate model route.

Who needs a rights impact assessment? | EU AI Act

Check who needs an Article 27 fundamental rights impact assessment, what it must cover, and how privacy assessments, notification and registration fit.