- The August 2026 deadline isn’t aspirational — it’s the statutory application date for high-risk Annex III requirements. If your system is in EU operation after that date and hasn’t gone through Articles 8–17 compliance and EU database registration, it’s non-compliant. Build the compliance activities into your project plan now, not as a pre-deployment sprint.
- Most PMs overestimate how complicated conformity assessment is for Annex III systems. For employment, education, essential services, and most other Annex III use cases, the pathway is self-assessment under Annex VI — no notified body required. The work is substantial, but the process is entirely internal. Only biometric ID systems and Annex I product-safety AI require a third-party notified body.
- The EU AI Act applies to you whether you’re in the EU or not. Article 2 covers any provider whose system is accessed by EU users or whose outputs affect EU residents — a US or UK company serving EU customers has the same obligations as an EU-based provider. Non-EU providers must also designate an EU authorized representative before placing a high-risk system on the EU market.
- Deploying before August 2026 to secure the transitional exemption is a real strategy, but it has a catch. Significant design changes after the deadline void the grandfathering and trigger full compliance obligations. If your roadmap includes post-launch algorithm updates, training data changes, or changes to intended purpose, the exemption is less durable than it looks.
- If your project builds on a GPAI model, your vendor’s compliance posture is now your concern too. As the downstream provider deploying a GPAI model in a high-risk context, you’re responsible for overall system compliance under Article 25. Request technical documentation from GPAI providers, and build vendor compliance verification into your third-party AI management process.
Project managers understand constraints. Budget, scope, resources, time — every project operates within boundaries. For AI projects with EU exposure, the EU AI Act adds a statutory constraint that cannot be negotiated: regulatory deadlines. The Act is not a framework with flexible implementation; it is a directly applicable EU Regulation with fixed application dates, mandatory requirements, and financial penalties for non-compliance.
The EU AI Act was published in the Official Journal on 12 July 2024 (Regulation (EU) 2024/1689) and entered into force on 1 August 2024. It is the world’s first binding horizontal AI regulation — covering AI systems across sectors and use cases, not just specific applications. Understanding the timeline is the minimum required to determine whether your project has EU AI Act obligations, and if so, when those obligations become binding.
The Statutory Timeline: Article 113
The EU AI Act’s application schedule is set out in Article 113. The regulation entered into force on 1 August 2024. Its general application date is 2 August 2026. Specific provisions apply earlier or later:
| Date | What Applies |
|---|---|
| 1 August 2024 | Regulation enters into force. The EU AI Office is established to oversee implementation, in particular for GPAI model providers. |
| 2 February 2025 (6 months) | Chapter I (general provisions) and Chapter II (prohibited AI practices) apply. AI literacy obligations (Article 4) apply. Prohibited systems must have been discontinued by this date. |
| 2 August 2025 (12 months) | Chapter III Section 4 (notifying authorities and notified bodies), Chapter V (GPAI model obligations), Chapter VII (governance), and Chapter XII (penalties) apply. Member states must have designated national competent authorities. GPAI providers must comply with Articles 53–55 obligations. |
| 2 August 2026 (24 months) | General application date. High-risk AI systems under Annex III must comply with the full Article 8–17 requirements. Transparency obligations for limited-risk AI systems under Article 50 apply. Registration in the EU database (Article 49) required. |
| 2 August 2027 (36 months) | High-risk AI systems covered by EU product safety legislation under Annex I (medical devices, vehicles, machinery, lifts, toys, etc.) must comply. These systems are already subject to sector-specific conformity assessment and the AI Act requirements are integrated into those existing procedures. |
One additional transitional provision under Article 113 affects GPAI providers: providers of GPAI models already placed on the market before 2 August 2025 have until 2 August 2027 to achieve compliance — an extended period acknowledging the practical difficulty of retrofitting compliance obligations onto models already in deployment.
What “High-Risk” Means: Annex I vs. Annex III
The EU AI Act uses two annexes to define high-risk AI systems, and the distinction matters for compliance planning because the conformity assessment pathways differ.
Annex I — Product-safety AI (August 2027 deadline): AI systems embedded as safety components in products governed by existing EU product harmonisation legislation. This includes medical devices, in vitro diagnostics, aviation, vehicles, agricultural and forestry machinery, marine equipment, railway interoperability systems, lifts, and toys. These systems were already subject to sector-specific conformity assessment processes. The EU AI Act integrates its requirements into those existing processes, and the combined assessment typically requires a notified body.
Annex III — High-impact use case AI (August 2026 deadline): AI systems meeting the risk threshold in eight application areas: biometric identification and categorization; management of critical infrastructure; educational and vocational training; employment, workers management, and access to self-employment; access to essential private and public services and benefits; law enforcement; migration, asylum, and border control; administration of justice and democratic processes.
Not every AI system in these categories is automatically high-risk. Article 6(3) provides that an Annex III system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights — including by not materially influencing the outcome of decision-making. Providers can self-classify downwards and register the reasoning in the EU database; the classification is subject to challenge by market surveillance authorities.
The Compliance Pathway: What High-Risk AI Systems Must Do
For Annex III high-risk AI systems with an August 2026 application date, the compliance obligations under Articles 8–17 are substantial but well-defined. The following are required before the system is placed on the EU market or put into service:
Article 9: Risk Management System
A documented risk management system that operates as a continuous iterative process throughout the AI system’s entire lifecycle. Not a one-time risk assessment — a system. Required components include: identification and analysis of known and reasonably foreseeable risks associated with the intended purpose and under conditions of reasonably foreseeable misuse; estimation and evaluation of those risks; adoption of appropriate risk management measures; testing to ensure the system performs as intended. Article 9(2)(b) explicitly requires consideration of risks that may emerge from foreseeable misuse, not just intended use. This is a design requirement, not a documentation exercise.
Article 10: Data Governance
Training, validation, and testing data must be subject to data governance practices addressing: the design choices underlying data collection; the origin and collection processes; preprocessing operations (annotation, labeling, cleaning, enrichment); assumptions made about what the data represents; assessment of availability and suitability; examination for biases likely to affect health, safety, or fundamental rights; and identification of data gaps. Article 10(3) requires that data be relevant, sufficiently representative, and as free as possible from errors in view of the intended purpose.
Article 11 and Annex IV: Technical Documentation
Technical documentation must be drawn up before the system is placed on the market and must be kept up to date throughout the system’s lifecycle. It must contain: a general description of the system and its intended purpose; a detailed description of system elements and development process; information on monitoring, functioning, and control; a description of the risk management system; information about post-market monitoring plans; and performance metrics disaggregated by relevant subgroups. Technical documentation must be maintained for ten years after the system is placed on the market (Article 18).
Article 12: Record-Keeping and Logging
High-risk AI systems must be designed to automatically generate logs to the extent technically feasible. Logs must enable, at minimum, recording of each use of the system (start and end date/time), the reference database against which input data was checked, input data that led to results, and the identity of natural persons involved in verification where relevant. Deployers must retain logs for a minimum of six months.
Articles 13 and 14: Transparency and Human Oversight
High-risk AI systems must be accompanied by instructions for use covering: the system’s intended purpose; level of accuracy and performance metrics; known and foreseeable circumstances that may lead to risks; technical capabilities for output explanation; and human oversight measures required. Human oversight must be designed into the system so that natural persons assigned to oversight can understand the system’s capacities and limitations, remain aware of automation bias, interpret outputs correctly, override or disregard outputs, and halt the system. These are architecture requirements to be resolved at design, not training topics to be addressed at deployment.
Article 15: Accuracy, Robustness, and Cybersecurity
High-risk AI systems must achieve an appropriate level of accuracy, robustness, and cybersecurity throughout their lifecycle. They must be resilient to errors, faults, and inconsistencies arising from interaction with people or other systems. For systems that continue to learn after deployment, measures must prevent learning processes from giving rise to outputs that contradict the system’s initial performance or the requirements of the Regulation.
Article 43: Conformity Assessment
There are two conformity assessment pathways, and most Annex III systems do not require a notified body:
- Annex III points 2–8 (employment, education, essential services, law enforcement, migration, justice, etc.): Providers follow the internal control procedure in Annex VI. No notified body involvement. The provider conducts the assessment, verifies compliance with all Article 8–17 requirements, draws up technical documentation, and issues an EU Declaration of Conformity (Article 47). The CE marking is affixed (Article 48).
- Annex III point 1 (biometric identification and categorization): Providers must use the procedure in Annex VII involving a notified body, unless they have applied harmonized standards. For law enforcement biometric applications, the relevant national market surveillance authority acts as notified body.
- Annex I product-safety systems: Providers follow the conformity assessment procedure specified in the relevant sector legislation, with AI Act requirements integrated. These typically involve notified bodies.
For the vast majority of Annex III high-risk AI systems — the employment, education, credit, healthcare triage, and essential services use cases that most PMs encounter — conformity assessment is a self-administered process. It is work-intensive because it requires demonstrating compliance with Articles 9–15, but it does not require engaging a third-party notified body.
Article 49: EU Database Registration
Before placing a high-risk Annex III system on the market, providers must register it in the EU database maintained by the Commission. The registration must include: the provider’s identity and contact details; the AI system’s name, type, and intended purpose; the member states in which the system is placed on the market; and a copy of the EU Declaration of Conformity. Public authority deployers must also register use of third-party high-risk AI systems, including a summary of their Fundamental Rights Impact Assessment findings.
Article 72: Post-Market Monitoring
Compliance does not end at deployment. Providers must establish a post-market monitoring system that actively and systematically collects, documents, and analyses relevant data on system performance throughout the system’s lifetime. Article 73 requires reporting of serious incidents — resulting in death, serious harm to persons, significant disruption to critical infrastructure, or violations of fundamental rights — to market surveillance authorities within 15 days (or immediately for death or widespread serious incidents).
Transitional Provisions: Systems Already in Service
Article 113 contains a critical transitional provision that affects planning for systems currently deployed or under development. High-risk AI systems already placed on the market or put into service before 2 August 2026 are not required to comply with the Act’s high-risk requirements — unless, from that date, those systems undergo significant changes in their design.
This is a grandfathering mechanism for existing deployments: if your high-risk system is operating before the deadline and does not undergo significant design changes, it continues to operate under the pre-Act legal framework. However, any significant change — new intended use, significant modification to the algorithm or training data, material change to the human oversight design — triggers the full compliance obligation from the date of that change.
PMs evaluating whether to accelerate deployment ahead of August 2026 to secure the transitional exemption should be clear-eyed about what that strategy implies: it means committing not to make significant design changes, which constrains the system’s future development roadmap for as long as you want to rely on the exemption. For systems with planned iterative development, the exemption may be less durable than it appears.
There is one additional transitional provision specifically for public authorities: providers and deployers of high-risk systems intended to be used by public authorities must comply by 2 August 2030, regardless of when the system was placed on the market — a further extended timeline reflecting the procurement and implementation cycles of government technology.
Extraterritorial Scope: The EU AI Act Is Not Just for EU Organizations
Article 2 defines the regulation’s scope of application. It covers: providers placing AI systems on the EU market or putting them into service in the EU, regardless of where those providers are established; providers and deployers of AI systems located in a third country where the output produced by the AI system is used in the EU; importers and distributors of AI systems; and product manufacturers placing an AI system on the market under their own name or trademark.
The practical implication: EU AI Act obligations apply to any organization whose AI system is accessed by EU users or whose outputs affect EU residents — regardless of whether that organization is based in the EU. A US or UK company deploying a high-risk AI system to EU customers faces the same obligations as an EU-based provider.
Non-EU providers without an EU establishment are required to designate an authorized representative in the EU (Article 22) before placing a high-risk AI system on the EU market. The authorized representative carries the regulatory interface role: accepting responsibilities on behalf of the provider, providing compliance documentation to national competent authorities on request, and cooperating with market surveillance.
GPAI Models: Obligations Already in Effect
If your project deploys a general-purpose AI model — a large language model, a multimodal foundation model, or another model trained on broad data and capable of a wide range of tasks — the upstream provider of that model has been subject to GPAI obligations since 2 August 2025.
Under Article 53, GPAI model providers must: draw up and maintain technical documentation; draw up and provide documentation for downstream providers; comply with EU copyright law and publish a summary of training data; and establish a policy for complying with the Copyright Directive. For GPAI models with systemic risk — those trained with compute above 1025 FLOPs — additional obligations under Article 55 apply: adversarial testing; incident reporting; cybersecurity measures; and energy efficiency reporting.
The GPAI Code of Practice, developed by the AI Office with input from over 1,000 industry, civil society, and academic representatives, was finalized in July 2025. Providers who sign the Code and adhere to it benefit from a presumption of compliance with Articles 53 and 55 requirements.
If your project builds on a GPAI model API, the upstream provider’s compliance posture is part of your compliance story. Under Article 25, you — as the downstream provider building a high-risk system on top of that model — are responsible for demonstrating overall compliance. Request the provider’s GPAI technical documentation early, and build vendor compliance verification into your third-party AI management process.
Penalties: What Non-Compliance Actually Costs
| Violation | Maximum Fine |
|---|---|
| Prohibited AI practices (Article 5): social scoring, banned biometric applications, manipulation, exploitation of vulnerabilities | €35,000,000 or 7% of total worldwide annual turnover, whichever is higher |
| Provider obligations (Article 16), deployer obligations (Article 26), notified body requirements, transparency obligations (Article 50) | €15,000,000 or 3% of total worldwide annual turnover, whichever is higher |
| Supplying incorrect, incomplete, or misleading information to notified bodies or national competent authorities in response to a request | €7,500,000 or 1% of total worldwide annual turnover, whichever is higher |
For SMEs including start-ups, fines are capped at the lower of the percentage or absolute-amount thresholds — a deliberate concession in Article 99(6) to avoid disproportionate penalties on smaller operators.
Actual enforcement will vary by member state and the circumstances of the infringement. National competent authorities are required to consider mitigating factors including: the gravity and duration of the infringement; the degree of responsibility; mitigating actions taken; good-faith compliance efforts; and whether the infringer cooperated with the investigation. A provider that can demonstrate a structured compliance program and documented risk management will be in a materially different position than one with no governance framework.
Building the Timeline Into Your Project
Compliance is not a phase at the end of your project — it is work distributed across the entire lifecycle.
| Project Phase | EU AI Act Compliance Activities |
|---|---|
| Initiation and chartering | Risk classification: is the system high-risk under Annex I or Annex III? Document classification reasoning (needed for Article 6(3) self-classification or defense against challenge). Assess extraterritorial scope: are EU users or EU-resident affected parties in scope? Identify applicable obligations and deadlines. Plan the conformity assessment pathway: Annex VI self-assessment vs. Annex VII notified body. Confirm whether a FRIA (Article 27) is required. |
| Design | Design human oversight capabilities to meet Article 14(4)(a)–(e) — these are architecture decisions that cannot be retrofitted. Design logging and record-keeping to meet Article 12. Begin technical documentation (Article 11/Annex IV) — this is a living document, not a pre-deployment deliverable. Establish data governance framework for Article 10 compliance. |
| Development and testing | Execute the Article 9 risk management program including bias examination and mitigation. Document data provenance, preprocessing decisions, and representativeness assessments (Article 10). TEVV to demonstrate Article 15 accuracy, robustness, and cybersecurity. Continue maintaining and updating technical documentation. |
| Pre-deployment (conformity assessment gate) | Complete the Annex VI internal conformity assessment (or Annex VII notified body assessment if applicable). Draw up EU Declaration of Conformity (Article 47). Affix CE marking (Article 48). Register in EU database (Article 49). For public authority deployers: complete FRIA (Article 27) and notify market surveillance authority. Designate an EU authorized representative if provider is not EU-established (Article 22). |
| Post-deployment (ongoing) | Execute post-market monitoring plan (Article 72). Maintain logs per Article 12; deployers retain logs for minimum six months. Report serious incidents to market surveillance authorities within 15 days (or immediately for death/widespread harm) under Article 73. Update technical documentation as the system evolves. Reassess compliance if significant design changes are made. |
Right-Sizing for Your Situation
The formality of compliance planning should match the risk level of your system and the proximity of the August 2026 deadline. A high-risk Annex III system deploying to EU customers in 2026 requires a compliance program that is resourced, scheduled, and tracked as project work. A minimal-risk internal tool with no EU exposure requires none of this. The risk classification decision, made at chartering, determines the compliance scope.
The first question is whether the Act applies to your project at all — run the Article 2 scope check before doing anything else. If it does, work through the risk classification checklist: Annex I vs. Annex III, the Article 6(3) exception, the profiling override. For an Annex III system, the Annex VI self-assessment pathway means you don’t need a notified body — but you do need Articles 9 through 15 evidenced before deployment. Start technical documentation now, not pre-launch. It is a lifecycle document and the audit trail depends on it being contemporaneous.
The compliance timeline table in this article is your project plan template. Map each compliance activity — Article 9 risk management system, Article 10 data governance, Article 11 technical documentation, Article 14 human oversight design, Annex VI conformity assessment, Article 49 EU database registration — to a project phase, assign an owner, and schedule a buffer before the August 2026 deadline. The conformity assessment gate is a real go/no-go gate. If it’s not in the plan, it will be skipped in the sprint-to-launch.
At this level the critical coordination points are with legal and compliance, not within the project team. GPAI provider due diligence needs to be a procurement standard — what technical documentation does the upstream provider make available, what is their GPAI Code of Practice status, and what does Article 25 downstream compliance require from you? The FRIA process (Article 27) for public authority deployers needs to be integrated with your legal team’s regulatory notification workflow. And post-market monitoring plans need to connect to your incident management process, not live in a document that no one reads after go-live.
The AI Governance Advisor at app.aipmo.co can help you work through which EU AI Act obligations apply to your specific project, methodology, and deployment context.
Framework References
EU AI Act (Regulation (EU) 2024/1689) — Articles 2, 4, 5, 6(3), 8–17, 18, 22, 25, 43, 47, 49, 72, 73, 99, 113; Annexes I, IV, VI, VII. Territorial scope, prohibited practices, high-risk compliance requirements, conformity assessment pathways, post-market monitoring, penalties, and implementation timeline. Primary source for all article references in this article.
EU AI Act Annex III — Eight high-risk use-case categories: biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, and administration of justice. Reference for Annex III scope determination.
EU AI Act Articles 53–55 — GPAI model obligations: transparency, copyright compliance, training data summaries; additional safety and security obligations for systemic-risk models above 1025 FLOPs.
GPAI Code of Practice (EU AI Office, July 2025) — Voluntary compliance tool for Articles 53 and 55; adherence creates a presumption of conformity for GPAI model providers.
This article is part of AIPMO’s Frameworks series. See also: AI Impact Assessments | AI Risk Classification | The PM’s Guide to NIST AI RMF | ISO 42001 for Project Managers