EU AI Act compliance checklist — article by article.
The EU AI Act imposes a layered set of obligations. This checklist works through the key articles for providers and deployers of high-risk AI systems — what each article requires, what evidence you need on file, and what applies to you.
Who this checklist is for
This checklist covers obligations for providers (who build or place AI systems on the market) and deployers (who use AI systems in their own context). GPAI-only obligations (Articles 53–55) are covered in the final section. Not sure which tier your system is? Use the EU AI Act risk tier classifier →
Article 5 — Prohibited AI practices
Article 5 lists AI practices that are prohibited outright regardless of risk tier, risk management record, or mitigation measures. These are not high-risk obligations — they are absolute prohibitions. If your system falls in these categories, the compliance question is not what documentation you need; it is whether the system can exist at all.
Article 5
Prohibited practices — hard stops
- The system does not use subliminal techniques below the threshold of consciousness to materially influence a person's behavior in a harmful way.
Article 5(1)(a). This includes audio/visual stimuli the user is unaware of.
- The system does not exploit vulnerabilities of persons due to age, disability, or social and economic situation to distort behavior in a harmful way.
Article 5(1)(b). Targeting cognitive biases of vulnerable groups to cause harm is prohibited.
- The system is not used by or on behalf of a public authority to evaluate or classify individuals based on social behavior, creating detrimental treatment (social scoring).
Article 5(1)(c). Applies to public authorities, not private employers acting under commercial law.
- The system does not perform real-time remote biometric identification of individuals in publicly accessible spaces by law enforcement — except within the narrow Article 5(2) exceptions (specific criminal investigation, imminent threat, missing person).
Article 5(1)(d). Exceptions require prior authorisation and post-hoc notification under 5(3).
- The system does not perform biometric categorization of natural persons to infer or deduce sensitive attributes (race, political opinion, religious beliefs, philosophical beliefs, sexual orientation, trade union membership).
Article 5(1)(e).
- The system does not perform emotion recognition in workplace or educational settings.
Article 5(1)(f). Exceptions exist for medical or safety purposes.
- The system is not used to create or expand facial recognition databases through untargeted scraping of biometric data from the internet or CCTV footage.
Article 5(1)(g).
- The system does not make predictions about whether a person will commit a criminal offense based solely on profiling or personality traits.
Article 5(1)(h).
Article 6 + Annex III — Risk classification
Before applying high-risk obligations, every deployer and provider must determine which tier their system falls in. The Annex III categories are the primary classification mechanism. A system is high-risk if it is listed in Annex III or if it is a safety component of a product governed by existing EU product safety law under Article 6(1).
The classification decision is itself an evidence requirement. Article 6(3) allows providers to self-certify that a system listed in Annex III is not high-risk based on its actual function — but that determination must be documented and registered in the EU database.
Article 6 + Annex III
Risk classification evidence
- Classification decision documented — which Annex III categories were assessed, which were accepted or rejected, and the basis for the decision.
Required even for non-high-risk determinations. If a regulator later disagrees, a documented analysis is a better position than no record.
- If the system is a safety component of an existing product regulated under EU product safety law (machinery, medical devices, aviation), confirm whether that regulation independently triggers high-risk classification under Article 6(1).
- If high-risk: system registered in the EU AI Act database (EU database maintained by the Commission).
Article 71. Providers must register before placing a high-risk system on the market.
- Classification reviewed whenever the system's purpose, scope, or deployment context changes materially.
A productivity tool that expands into employment decisions has crossed into Annex III territory.
Article 9 — Risk management system
Article 9 is the core high-risk obligation. It requires a documented, continuous risk management system — not a one-time assessment, not a form, but a defined process with records at each step. The six requirements of Article 9 apply throughout the lifecycle of the AI system.
Article 9
Risk management system
- Risk management system established, documented, and assigned to responsible parties.
Requires a policy or procedure document with version control and named owner — not just a spreadsheet.
- Known and reasonably foreseeable risks identified and analyzed: biased outputs, privacy leakage, misuse, failure under edge conditions, risks to health/safety/fundamental rights.
- Each risk evaluated for likelihood and severity in the context of use — who uses the system, under what conditions, for what decisions.
Ratings must have documented rationale, not just a numeric score.
- Risk mitigation measures in place or planned for each material risk. Residual risks documented and accepted by a named responsible party.
- Pre-deployment testing against intended purpose and foreseeable misuse. Test records including scope, methodology, results, and sign-off.
Article 9(5). Testing must be repeated when the system changes.
- Post-deployment monitoring process defined — not necessarily continuous technical monitoring, but a process to detect and respond to risks that emerge in production.
Particularly required for risks to fundamental rights.
- Risk management records retained and version-controlled as part of the technical documentation file.
Article 10 — Data governance
Article 10 applies to providers of high-risk AI systems trained or validated on data. It requires documentation of data governance practices: what data was used, where it came from, how it was validated, and how potential biases were identified and addressed. This is the most commonly under-documented Article — test plans exist; data provenance records often do not.
Article 10
Data governance documentation
- Training, validation, and test datasets documented: sources, collection methodology, pre-processing steps.
Article 10(2)(a). Requires upstream engagement with data teams that most organisations have not built into their AI development process.
- Data quality criteria defined and applied: accuracy, completeness, representativeness.
- Examination of datasets for possible biases that could affect fundamental rights or produce discriminatory outputs.
Article 10(2)(f). Must cover biases that may arise from the context and likely use of the system.
- Consent and licensing basis for training data documented where applicable.
- Special category data used in training documented with legal basis under GDPR, where applicable.
Article 10(5) allows special category data for bias detection in narrowly defined circumstances.
Article 11 — Technical documentation
Article 11 requires providers of high-risk AI systems to prepare a technical documentation file before placing the system on the market. The file must be retained for ten years. For deployers who have fine-tuned or customised a foundation model for their own context, the boundary between provider and deployer obligations determines what portion of the documentation obligation falls on whom — but the obligation follows responsibility, not title.
Article 11 + Annex IV
Technical documentation file
- General description of the AI system: intended purpose, the persons the system is designed to interact with, how it interacts with hardware/software.
- Design specifications: algorithms used, design choices and their rationale, training approach.
- Development and training methodology: the steps taken to develop the system, including any pre-trained models and transfer learning.
- Testing results: test protocols, pass/fail criteria, actual results, remediation taken.
Signed test records with defined criteria are required — not just a summary statement that testing occurred.
- Article 9 risk management records incorporated into the file.
- Article 10 data governance records incorporated into the file.
- File retained for 10 years after the system is placed on the market or put into service.
This is a legal retention obligation. Organisations that delete documentation after retiring a system may be unable to respond to a regulator request years later.
Articles 12 and 13 — Logging and transparency
Article 12 requires high-risk AI systems to have automatic logging capabilities — events logged must cover the period of the system's operation and be traceable. Article 13 requires that deployers (and the persons subject to the system's output) have access to information that allows them to interpret the system's output and use it correctly.
Article 12
Logging requirements
- System logs automatically-generated operational events to the extent necessary to ensure traceability.
- Logs are retained for the period required by the deployment context (Article 12(1) — at least the period determined by applicable law).
- Logs allow — at minimum — assessment of the period during which the AI system was in operation and the input data against which it was operating.
Article 13
Transparency obligations
- Users (deployers and/or natural persons) provided with information about: intended purpose, level of accuracy and known limitations, expected lifetime, required maintenance.
- Where the system interacts directly with natural persons, those persons informed that they are interacting with an AI system — unless this is obvious from context.
Article 50 also covers chatbot transparency obligations for limited-risk systems.
- Instructions for use provided to deployers — sufficient to use the system correctly and interpret its outputs.
Article 14 — Human oversight
Article 14 requires high-risk AI systems to be designed and built so that natural persons can effectively oversee them during deployment. Human oversight is not a process add-on — it is a design requirement that must be built into the system itself and verified in testing.
Article 14
Human oversight measures
- System designed to allow oversight persons to understand the capabilities and limitations of the system and to monitor its operation.
- System includes the ability for oversight persons to intervene in the operation of the system or to interrupt it through a stop button or similar mechanism.
- System does not drive users to automatically defer to its output — where the system is used to inform a consequential decision, the design must support human judgment rather than substitute for it.
- Oversight measures documented in instructions for use and verifiable in test records.
- For deployers: appropriate human oversight measures implemented as described in the provider's instructions — not delegated to end users without supervision.
Article 26(2). Deployers have a positive obligation to implement the oversight the provider specifies.
Article 15 — Accuracy, robustness, cybersecurity
Article 15 requires high-risk AI systems to be designed to achieve appropriate levels of accuracy, robustness, and resilience against adversarial attacks. These are design requirements with evidence requirements: the levels must be declared in instructions for use, and testing must demonstrate they are met.
Article 15
Accuracy, robustness, and security
- Accuracy levels declared and tested: metrics specified, test methodology documented, results on file.
Accuracy levels and metrics must be stated in instructions for use per Annex IV.
- System tested for resilience against errors, faults, and inconsistencies in input data. Fallback or fail-safe behavior documented.
- System tested for resilience against adversarial inputs — attempts to manipulate the system's behavior through crafted inputs.
Includes prompt injection for systems using LLMs, adversarial examples for image-based systems.
- Cybersecurity measures implemented commensurate with the deployment context: authentication, encryption, audit trails.
Article 26 — Deployer obligations
Article 26 defines obligations that apply specifically to deployers — organizations that use an AI system in their own context without placing it on the market. Deployer obligations are narrower than provider obligations but are not optional. The key practical distinction: the provider's compliance does not substitute for the deployer's obligations.
Article 26
Deployer compliance obligations
- AI system used strictly in accordance with the intended purpose documented by the provider. Any use outside the intended purpose triggers deployer liability as a provider.
Article 26(1). This is the clearest bright line in deployer compliance.
- Human oversight measures implemented as specified in the provider's instructions for use.
Article 26(2). Cannot be delegated to end users without oversight.
- Input data monitored for relevance and representativeness with respect to the intended purpose.
Article 26(4). For deployers who control the data inputs.
- Logs retained for the period determined by applicable law (minimum three years where not otherwise specified by sectoral law).
Article 26(6).
- Data Protection Impact Assessment (DPIA) conducted where Article 35 GDPR is triggered by the AI system's deployment.
Article 26(9). Required for any processing likely to result in a high risk to natural persons.
- Fundamental Rights Impact Assessment (FRIA) conducted before deploying certain high-risk AI systems used by public entities or private entities providing public services.
Article 27. Applies to bodies governed by public law and private bodies providing public-interest services (insurance, banking, education, utilities).
- Serious incidents and malfunctions reported to the provider and — where required — to the relevant national market surveillance authority.
Article 26(5). Deployers who become aware of incidents must notify the provider immediately.
Articles 53–55 — GPAI model obligations
General-purpose AI models — foundation models like GPT-4, Claude, Gemini, Mistral — are subject to separate obligations under Title III of the Act. These obligations fall on the model provider. Organizations that deploy GPAI as the base of a high-risk application benefit from the GPAI provider's obligations but retain their own deployer obligations under Articles 9 and 26 for the application layer.
Articles 53–55
GPAI model provider obligations
- Technical documentation prepared and maintained: training methodology, training data, compute used, capabilities and limitations.
Article 53(1)(a). Must be kept up-to-date.
- Copyright policy published — documentation of policies to comply with EU copyright law, including where the training data was obtained.
Article 53(1)(c).
- Detailed summary of training data published and made publicly available.
Article 53(1)(d).
- For systemic-risk GPAI models (trained with more than 10^25 FLOPs): adversarial testing conducted, serious incidents reported to the Commission, cybersecurity measures appropriate to the scale of risk.
Article 55. Systemic-risk designation may also be triggered by Commission decision on capability grounds.
Next step
Produce the Article 9 evidence record for each high-risk system
The Article 9 risk management record is the foundation document that all other compliance obligations build on. Drel produces a structured, auditable risk management record for each assessed AI system — mapped to the Article 9 requirements above.
See the Article 9 risk management template →Frequently asked questions
- Does this checklist make my system EU AI Act compliant?
- No. This checklist helps you identify what evidence and processes you need on file. Compliance for high-risk systems may require conformity assessment — either self-declaration or third-party assessment by a notified body, depending on the Annex III category. Always verify with qualified legal counsel.
- What is the difference between a provider and a deployer?
- Providers place AI systems on the market or put them into service — they build, develop, or substantially modify systems. Deployers use AI systems in their own context without placing them on the market. A company that fine-tunes a foundation model and makes it available internally may be both a provider (for the customization layer) and a deployer. The distinction matters because obligations differ significantly between the two roles.
- When does the EU AI Act apply?
- The Act entered into force on 1 August 2024. Prohibited practices (Article 5) applied from 2 February 2025. GPAI obligations (Articles 51–56) applied from 2 August 2025. High-risk obligations (Articles 6–50) for Annex III systems apply from 2 August 2026. Some Annex III categories (safety components of existing products) have until 2027.
- Do obligations apply if the AI system is not placed on the EU market?
- The Act applies where the output of the AI system is used in the EU, regardless of where the provider or deployer is based. Non-EU providers whose systems affect persons in the EU are covered. This is analogous to GDPR's territorial scope.
- Does a Fundamental Rights Impact Assessment replace a GDPR DPIA?
- No — they are separate obligations. A DPIA is required under GDPR where processing is high-risk to natural persons. A FRIA is required under Article 27 of the EU AI Act for certain deployers (public bodies and private entities providing public-interest services). Both may be required for the same deployment.
- What is a notified body and do I need one?
- Notified bodies are accredited third-party conformity assessment bodies. They are required for high-risk AI systems in specific Annex III categories where self-declaration of conformity is not permitted — notably biometric identification and some law enforcement uses. For most Annex III categories, providers can self-declare conformity with the requirements after completing internal testing and documentation.