EU AI Act Compliance Checklist (2026): Every Deadline, Every Risk Tier, and the €35M Fine Schedule You Should Plan Around

**August 1 2024 — entry into force.** Regulation (EU) 2024/1689 was published in the Official Journal on July 12 2024 and entered into force twenty days later, on August 1 2024. From that date, the clock started ticking on every staged obligation in the Act. No compliance was immediately due — but every internal program and every supplier contract executed after that date should already reference the Act by name. The consolidated text is at https://eur-lex.europa.eu/eli/reg/2024/1689/oj and the Commission's policy hub at https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai.

**February 2 2025 — prohibitions and AI literacy duties bit.** Article 5 prohibitions on unacceptable-risk AI — social scoring by public authorities, manipulative subliminal techniques, exploitation of vulnerabilities, untargeted scraping of facial images, emotion recognition in workplace and education contexts, biometric categorization for protected characteristics, and real-time remote biometric identification in publicly accessible spaces (with narrow law-enforcement exceptions) — became enforceable. Article 4 AI literacy obligations on providers and deployers also took effect: organizations using AI must ensure staff have a sufficient level of AI literacy to operate and oversee the systems. This sixteen months into enforcement, you should already have an AI literacy program documented.

**August 2 2025 — GPAI obligations and the governance regime.** The European AI Office at DG CNECT formally took over its exclusive competence for general-purpose AI on this date. GPAI providers — foundation model labs — became subject to transparency obligations, copyright policy obligations, and (for systemic-risk models above 10^25 FLOPs of training compute) additional adversarial testing, incident reporting, and cybersecurity obligations. The voluntary General-Purpose AI Code of Practice at https://digital-strategy.ec.europa.eu/en/library/general-purpose-ai-code-practice was published as the safe-harbor pathway. Member states' national notification regimes and the AI Board structure were also operational by this date.

**August 2 2026 — high-risk Annex III systems (the big one).** This is six weeks from publication of this guide. Every AI system listed in Annex III — biometric identification and categorization, critical infrastructure management, education and vocational training, employment and worker management, access to essential private and public services and benefits (including credit scoring and life/health insurance pricing), law enforcement use, migration/asylum/border control, and administration of justice/democratic processes — must be fully compliant. That means risk management system (Article 9), data governance (Article 10), technical documentation (Article 11), automatic logging (Article 12), transparency to deployers (Article 13), human oversight (Article 14), accuracy/robustness/cybersecurity (Article 15), conformity assessment, CE marking, and registration in the EU database (Article 49). If you are an HR tech vendor, credit scoring fintech, ed-tech grading vendor, or biometric vendor — this is your deadline.

**August 2 2027 — high-risk Annex I systems and full applicability.** AI systems that act as safety components in products already covered by the EU's New Legislative Framework — Medical Device Regulation, Machinery Regulation, Toy Safety Directive, Lifts Directive, Civil Aviation, Automotive Type-Approval, Marine Equipment Directive, Radio Equipment Directive — must be conformity-assessed under the integrated AI Act + sectoral regime. The longer runway exists because these products are already subject to mature third-party notified-body assessment, and the Commission gave industry an extra year to integrate AI Act obligations into existing technical files. Use the extra time — medical device technical files take six to eighteen months to refresh.

**Ongoing — post-market monitoring, incident reporting, and renewals.** From the moment each system is on the market, providers run Article 72 post-market monitoring plans and Article 73 serious incident reporting on a continuous basis. Article 16 places ongoing duties on providers; Article 26 on deployers. Substantial modifications to high-risk systems trigger a fresh conformity assessment. Treat the August deadlines as the start of compliance, not the end — the Act runs as a living regime, like GDPR, not a one-shot certification.

Start with the **prohibited** list (Article 5). If your system does any of seven things — social scoring by public authorities, manipulative subliminal influence, exploitation of vulnerabilities (age, disability, socio-economic), untargeted facial-image scraping to build databases, emotion recognition in workplace or school, biometric categorization to infer race/political opinion/trade union membership/religion/philosophical belief/sex life/sexual orientation, predictive policing solely based on profiling, real-time remote biometric ID in public — stop. The structured walkthrough at https://artificialintelligenceact.eu/article/5/ is the cleanest reading of the article. If you fall in the prohibited bucket, the only compliance step is to remove the system from the EU market; there is no conformity-assessment escape route.

Next, check **high-risk Annex III**. There are eight categories: biometric ID/categorization; critical infrastructure (water, gas, electricity, transport); education and vocational training (admission, grading, monitoring); employment, worker management and access to self-employment (recruitment, task allocation, performance evaluation, termination); access to essential services (creditworthiness scoring, insurance risk pricing for life/health, public benefits, emergency call dispatch); law enforcement (risk assessment, polygraph, evidence reliability); migration/asylum/border (risk assessment, document verification, application examination); administration of justice and democratic processes. If your system is in one of those eight categories, you are high-risk Annex III, and August 2 2026 applies.

Then check **high-risk Annex I** (products already regulated by EU harmonization law). Annex I lists the sector regulations — MDR for medical devices, MDR for in vitro diagnostics, the Machinery Regulation, Toy Safety Directive, lifts, recreational craft, civil aviation security, motor vehicle type approval, marine equipment, agricultural and forestry vehicles, two- and three-wheel motor vehicles, radio equipment. If your AI is a safety component in one of those products, you are high-risk Annex I, deadline August 2 2027, with integrated conformity assessment via your existing notified body.

**Limited-risk** is the Article 50 transparency tier. If your system is a chatbot interacting with humans, you must disclose that the user is interacting with an AI system unless it is obvious. If it generates synthetic audio/image/video/text, the output must be marked in a machine-readable format as artificially generated or manipulated (watermarking). If it is an emotion recognition or biometric categorization system that is not in a prohibited or high-risk context, you must inform the natural persons exposed. If it generates a deepfake, you must disclose that the content is artificially generated or manipulated. The detailed obligations are in Article 50 — read the article-level summary at https://artificialintelligenceact.eu/article/50/.

Everything else is **minimal-risk**. Spam filters, video game NPC AI, inventory optimization, code completion for internal use, recommendation systems that do not touch Annex III categories — no AI Act obligations apply. Voluntary codes of conduct (Article 95) are encouraged but not mandatory. Note that minimal-risk under the AI Act does not exempt you from GDPR, the Digital Services Act, sector consumer protection law, or the Product Liability Directive — those regimes apply independently.

The practical classification artifact is a one-page register: system name, business owner, deployer or provider role, intended purpose, Annex III/Annex I check, Article 50 check, conclusion tier, deadline, owner of the conformity work. Run this exercise across every AI system in your stack — internal, third-party, embedded — and you will surface most of your compliance scope in a day. The official AI Act Service Desk at https://ai-act-service-desk.ec.europa.eu/ accepts classification questions where the article text is genuinely ambiguous; use it before paying outside counsel for the simple cases.

The Act treats general-purpose AI models — foundation models that can be adapted to many downstream tasks — as a distinct regulated object, separate from the AI systems built on top of them. **GPAI provider** obligations (Article 53) include maintaining technical documentation; making information available to downstream providers who integrate the model; implementing a policy to comply with EU copyright law (including the Article 4(3) text-and-data-mining opt-out under the Copyright Directive); and publishing a sufficiently detailed summary of the training content. These apply from August 2 2025 to any provider placing a GPAI model on the EU market — including open-source models, with narrower exemptions.

A GPAI model becomes a **systemic-risk GPAI model** under Article 51 when its cumulative compute used for training exceeds 10^25 floating-point operations, or when the Commission designates it as such based on capability indicators (number of parameters, dataset quality/size, energy consumption, modalities, market reach, registered business users). GPT-4-class and above models cross or approach the threshold; the Commission can also re-set the threshold by delegated act. Once a model is systemic-risk, additional obligations under Article 55 apply: model evaluation including adversarial testing, systemic-risk assessment and mitigation, serious incident reporting to the AI Office, and adequate cybersecurity protection.

The **General-Purpose AI Code of Practice** at https://digital-strategy.ec.europa.eu/en/library/general-purpose-ai-code-practice is the voluntary safe-harbor. Signatories — major frontier labs and several smaller providers — commit to a specified set of transparency, copyright, and safety measures that the AI Office accepts as evidence of compliance with Articles 53 and 55. Non-signatories must demonstrate equivalent compliance by other means. As of mid-2026, signatories include Anthropic, Google, Microsoft, OpenAI, and most major EU providers; a handful of frontier labs have publicly declined to sign and are demonstrating compliance independently.

**Open-source GPAI** gets a partial exemption. Article 53(2) exempts open-source providers from the technical documentation and downstream-information obligations, provided the weights and architecture are publicly released under a free and open-source license and the provider does not place the model on the market under a systemic-risk classification. The copyright policy obligation still applies. The exemption does not extend to systemic-risk models — once a Llama-class or Mistral-class model crosses the 10^25 FLOPs threshold or is designated by the Commission, the full Article 55 regime applies regardless of license.

For **downstream deployers** integrating GPAI into a product, the GPAI provider is responsible for upstream model obligations and you are responsible for the system-level obligations of whatever tier your system falls into. A chatbot built on GPT-5 is a limited-risk system (Article 50 disclosure) unless its intended use places it in Annex III — for example, a recruiting chatbot that screens job candidates is high-risk. The model classification and the system classification are independent. Document both in your conformity file.

Practical advice: if you self-host or fine-tune a model and your training run could plausibly approach 10^25 FLOPs (rare for most enterprises, but possible for serious research labs), get legal review before publishing the model. If you are a downstream deployer, ask your GPAI provider in writing whether their model is classified systemic-risk and obtain the Article 53(1)(b) downstream-information package — it is required for your own technical documentation. Frontier model providers publish this on their developer documentation; a contract addendum should reference the specific URL.

High-risk providers undergo a **conformity assessment** before placing the system on the EU market. Most Annex III systems use the internal-control procedure (Annex VI): the provider self-attests, drawing on its own quality management system, that the system meets the Chapter III Section 2 requirements. For remote biometric identification systems and certain Annex I systems, third-party notified-body assessment (Annex VII) is required. The list of notified bodies is maintained on the NANDO database; expect the supply of qualified notified bodies in the early years to be a real bottleneck, especially for medical AI.

The **technical documentation** (Article 11, Annex IV) is the operational heart of compliance. It must include a general description of the system (intended purpose, version, hardware/software dependencies, user instructions); a detailed description of the design (system architecture, key design choices, classification of relevant Annex III categories, data sheets); validation and testing procedures; risk management documentation (Article 9); data governance documentation (Article 10) covering training/validation/test data sets; the human oversight measures (Article 14); accuracy, robustness, and cybersecurity provisions (Article 15); EU declaration of conformity; and the post-market monitoring plan (Article 72). Plan for a document that runs 100 to 400 pages depending on system complexity.

**Data governance** under Article 10 deserves its own paragraph because it is where most providers underestimate work. Training, validation, and test datasets must be relevant, sufficiently representative, free of errors and complete to the extent feasible, and have the appropriate statistical properties for the intended purpose. Bias examination and mitigation is mandatory. Where personal data is necessary for bias detection and correction, Article 10(5) provides a limited legal basis for processing special-category personal data — a carve-out that GDPR alone does not grant. Document the data lineage, sources, sampling, labeling, and bias testing in the technical file.

**Logging** (Article 12) requires automatic recording of events over the lifetime of the system, with the minimum retention period set by the provider in proportion to intended purpose — generally not less than six months, often longer where sector law requires. The logs must permit ex-post identification of situations that could result in the system presenting an unacceptable risk or undergoing substantial modification. For remote biometric ID, Article 12(3) sets specific minimum logging requirements including timestamps, reference databases used, and persons involved in result verification.

**Human oversight** (Article 14) requires that the system be designed and developed in such a way that it can be effectively overseen by natural persons during the period in which it is in use. Oversight measures must enable humans to fully understand the system's capabilities and limitations, remain aware of automation bias, correctly interpret the output, decide not to use it in any particular situation or override or reverse the output, and intervene or interrupt operation. Document the oversight design, the training of overseers, and the operational procedures.

Once the assessment is complete, the provider draws up the **EU declaration of conformity** (Article 47), affixes the **CE marking** (Article 48), and **registers** the system in the EU database (Article 49). The database listing for most high-risk systems is publicly accessible; law-enforcement, migration, and border-control use cases have restricted public view. Registration must be complete before the system is placed on the market — not after. Build the registration step into your release process or risk a Day-One compliance gap that the national market surveillance authority will notice.

Article 50 sits in the limited-risk tier but applies broadly. **Chatbot disclosure (Article 50(1))**: providers of AI systems intended to interact directly with natural persons must design and develop the system so that affected persons are informed they are interacting with an AI system, unless that is obvious from the context. The classic example is a customer support chatbot — you must disclose the AI nature unless the system is presented in a way that no reasonable user would think they are talking to a human. The disclosure must be clear and distinguishable at the latest at the time of the first interaction.

**Synthetic content marking (Article 50(2))**: providers of AI systems generating synthetic audio, image, video, or text content must mark the outputs in a machine-readable format as artificially generated or manipulated. Watermarking, fingerprinting, metadata, and content credentials (e.g., C2PA) are the recognized techniques. The marking must be effective, interoperable, robust, and reliable as far as technically feasible. The Commission encourages alignment with the C2PA standard; expect that to become the de facto compliance baseline, with implementation guidance refining what 'as far as technically feasible' means for short-form text.

**Deepfake disclosure (Article 50(4))**: deployers of AI systems that generate or manipulate image, audio, or video content constituting a deepfake must disclose that the content has been artificially generated or manipulated. The disclosure is on the deployer, not the model provider — the AI image generator is governed by Article 50(2), and the marketer who uses the generator to create a deepfake ad bears the Article 50(4) duty. Exceptions exist for evidently artistic, creative, satirical, or fictional works, where the disclosure may be done in a way that does not hamper the work — but the disclosure obligation does not disappear, only its form.

**Emotion recognition and biometric categorization (Article 50(3))**: deployers of an emotion recognition system or a biometric categorization system must inform the natural persons exposed and process the personal data in accordance with GDPR. Outside the prohibited contexts (workplace, school), these systems are permitted but transparency is mandatory. Document the disclosure mechanism — typically a notice at the point of data capture — and retain evidence of compliance.

**Text generation disclosure (Article 50(4), second paragraph)** is a narrower obligation. Deployers of an AI system that generates or manipulates text published with the purpose of informing the public on matters of public interest must disclose that the text has been artificially generated or manipulated. Editorial review by humans exempts you — if a human editor takes responsibility for the text before publication, the disclosure obligation does not apply. News organizations using AI for first drafts are largely safe under this carve-out; fully automated AI news bots are not.

Operationally, fold Article 50 into your product UX review. The disclosure design should be reviewed by legal and surfaced in your terms of service. For consumer-facing AI products, the disclosure must be visible to the end user in the language of the relevant member state, not buried in English-only documentation. Member state market surveillance authorities have signaled in early enforcement guidance that they will treat hidden or obfuscated disclosures as non-compliance, with fines up to €15 million or 3 percent of global annual turnover.

**Serious incident reporting (Article 73)** is one of the most operationally demanding obligations of the Act. Providers of high-risk AI systems must report any serious incident to the market surveillance authority of the member state where the incident occurred. A 'serious incident' is defined in Article 3(49) as any incident or malfunctioning of an AI system that directly or indirectly leads to death or serious harm to a person's health; serious and irreversible disruption of critical infrastructure; infringement of obligations under EU law intended to protect fundamental rights; or serious damage to property or the environment.

Reporting timelines are aggressive. The general rule: report immediately after the provider has established a causal link between the AI system and the serious incident or the reasonable likelihood of such a link, and no later than 15 days after awareness. For incidents involving death or widespread infringement, the deadline shortens to 10 days. For widespread infringement of fundamental rights, the deadline can be as short as 2 days for the initial report. The provider then conducts the investigation and submits a follow-up report. The reporting flow is coordinated through the AI Board and the Commission.

**Post-market monitoring (Article 72)** requires every high-risk provider to establish and document a post-market monitoring system that actively and systematically collects, documents, and analyses relevant data on the performance of the system throughout its lifetime. The plan must be part of the technical documentation and must allow the provider to evaluate continuous compliance with the Chapter III Section 2 requirements. The Commission will adopt an implementing act specifying the detailed content of the post-market monitoring plan; until then, providers rely on guidance and analogues from sectoral regimes like the Medical Device Regulation's post-market surveillance.

**Substantial modification (Article 43(4))** is a frequent operational trap. If a high-risk AI system that has already undergone conformity assessment is substantially modified — for example, retrained on materially different data, or extended to a new intended purpose — a fresh conformity assessment is required before the modified system is placed back on the market. The threshold for 'substantial' is judgment-based but tied to whether the modification could affect compliance with Section 2 requirements or change the intended purpose. Track model retraining cycles against this threshold from day one of deployment.

**Reporting interaction with GDPR Article 33** (the 72-hour personal data breach notification) is a known practitioner question. The two regimes are independent: an AI incident that involves personal data may trigger both Article 73 of the AI Act and Article 33 of GDPR, with different recipients (national market surveillance vs. national DPA) and different timelines (15 days vs. 72 hours). Stand up the two reporting workflows separately, with shared evidence collection but distinct legal review tracks. Many organizations land the GDPR notification first and use it as the trigger for the AI Act assessment.

**Operational reality:** the AI Office and national authorities have signaled in early 2026 enforcement guidance that they will distinguish between providers with credible post-market monitoring programs (some leniency) and those with no documented monitoring at all (treated as aggravating). Standing up a real post-market monitoring program — metrics, dashboards, owners, escalation rules — before August 2 2026 is the highest-leverage compliance investment you can make this quarter. The AI incident response playbook covers the full process end-to-end.

**Three tiers of fines** apply under Articles 99 and 101. For **prohibited AI practices (Article 5)**: up to €35 million or 7 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. This is the GDPR-style tier — large, multiplicative, designed to bite genuinely global firms. For **non-compliance with most other operational obligations** (high-risk requirements, transparency, post-market monitoring, registration, conformity assessment): up to €15 million or 3 percent of global turnover. For **supplying incorrect, incomplete, or misleading information** to notified bodies or competent authorities: up to €7.5 million or 1 percent of global turnover.

**GPAI-specific fines under Article 101**: the AI Office can impose fines on GPAI providers up to 3 percent of global annual turnover or €15 million, whichever is higher, for non-compliance with the relevant GPAI obligations. The Office can also impose penalties for non-cooperation with information requests or for supplying false information. Procedurally, the Commission follows a procedure analogous to the antitrust process — written objections, right to be heard, judicial review at the Court of Justice. This is not a regime designed for speedy resolution; expect multi-year investigations.

**SME and startup proportionality**: Article 99(7) requires that fines on SMEs (including startups) be set at the lower end of the ceilings. The Act explicitly directs authorities to take into account the size of the operator, the nature, gravity, and duration of the infringement, and whether the operator cooperated and acted in good faith. In practice, expect small fines for first-time non-cooperative SME violators and very large fines for repeat or willful violations by large operators. National authorities have published preliminary fining methodologies modeled on GDPR practice.

**Who enforces what**: GPAI obligations are the **exclusive competence of the European AI Office** at DG CNECT — only the Commission can investigate and fine GPAI providers. High-risk system obligations are enforced by **national market surveillance authorities** designated by each member state. The **AI Board** (composed of one representative per member state plus the European Data Protection Supervisor) coordinates cross-border investigations. Sector regulators retain their roles for Annex I products — medical AI is still primarily an EMA and national competent authority matter, integrated with AI Act obligations. The AI Office advises but does not enforce on the high-risk side.

**Enforcement trajectory in early 2026**: the first AI Office investigations into GPAI providers' compliance with Article 53 transparency obligations were opened in late 2025 — none had resulted in published fines as of June 2026. National market surveillance authorities have spent 2025-2026 building capacity (the German BNetzA, the French CNIL acting in coordination with the French DGCCRF, the Spanish AESIA which was the first dedicated national AI authority). Public guidance has stressed cooperation and remediation over headline fines in year one. Expect the enforcement posture to harden materially in 2027 once the Annex III obligations have been live for a year.

**Practical risk model**: budget compliance work against the operational disruption of a market surveillance investigation, not against the headline fine. An audit triggered by a customer complaint or a serious incident report can mean six to twelve months of document production, legal review, and product holds. The reputational and procurement impact often exceeds the eventual monetary fine. The strongest insurance policy is a well-documented technical file plus a real post-market monitoring program. Run your spend against an AI tools cost benchmark to keep the absolute budget honest.

**Deployer obligations (Article 26)** are the section most non-frontier-AI companies underestimate. If you deploy a high-risk AI system — even one you bought from a third party — you take on real duties: use the system in accordance with the provider's instructions; assign human oversight to natural persons with the necessary competence, training, authority, and support; ensure input data is relevant and sufficiently representative for the intended purpose; monitor operation and inform the provider and the market surveillance authority of any serious incident; retain logs for the relevant period; and (for certain Annex III categories) conduct a fundamental rights impact assessment under Article 27 before first use.

The **fundamental rights impact assessment (FRIA)** under Article 27 applies to deployers that are bodies governed by public law, private operators providing public services, and (for credit scoring and life/health insurance pricing) any deployer regardless of public/private status. The FRIA documents the deployer's processes in which the system will be used, the period and frequency of use, the categories of persons likely affected, the specific harms likely to impact those persons, the human oversight measures, and the actions to take if the harms materialize. The deployer notifies the market surveillance authority of the result.

**Vendor contract terms** to insist on: explicit identification of the system as high-risk Annex III (and which category); the version of the system covered; the Article 13 information package (intended purpose, level of accuracy, foreseeable misuse, human oversight measures, computational and hardware resources needed); the Article 12 logging configuration and retention; commitment to notify the deployer of substantial modifications under Article 43(4); cooperation obligation for Article 73 serious incident investigations; right to audit the technical documentation under NDA; allocation of liability under the AI Liability Directive (when transposed). Bake these into your master services agreement, not the order form.

**Sub-processor management**: AI systems often run on a stack of providers — foundation model API, vector database, observability layer, evaluation tooling. Each is a sub-processor under GDPR and a potential supplier under the AI Act for technical documentation purposes. Maintain a current map of sub-processors with their roles, regions, and certifications. For high-risk deployments, ensure the contract permits sub-processor changes only with notice and right to object, in line with GDPR Article 28 expectations.

**Open-source and self-hosted models**: if you fine-tune or self-host a foundation model for a high-risk application, you become both the GPAI deployer and the high-risk system provider. The provider role carries the full weight of Chapter III Section 2 obligations — risk management, technical documentation, conformity assessment, registration. Many enterprises that thought 'we just fine-tune Llama' are surprised to discover they are providers under the Act. Get legal classification advice before launching the fine-tuned system into the EU.

**Procurement timing for August 2 2026**: if your high-risk system relies on a third-party vendor's compliance, you need that vendor's Article 13 information package, declaration of conformity, and EU database registration in your hands before that date. Audit your suppliers now — vendors that cannot show you a credible compliance roadmap by Q3 2026 should be on the contingency list. The AI acceptable use policy template is a useful starting point for the deployer-side governance documentation you will need to attach to your FRIA.