The EU AI Act is the most important AI regulation in the world right now. Not because it is the strictest, though it is close to that. Not because it will produce the largest fines, though it might. It is the most important because it has become the de facto reference model for AI regulation globally. If you are building an AI governance program in 2026, the shape of your program will look a lot like the shape of the AI Act, whether or not you do business in Europe.
This article explains what the Act does, what has changed in the last twelve months, and what a practitioner needs to know to work with it. The next article (article 6) goes into the specific question of provider versus deployer obligations, because that distinction determines what applies to you.
Two acknowledgements before we start. First, the Digital Omnibus on AI reached a provisional political agreement on 7 May 2026, which changes several deadlines that had been widely reported. I will flag those changes as we go. Second, the Act is genuinely long and its implementing acts are still emerging. This is not a substitute for reading the text or getting proper legal advice. It is a practitioner’s map.
The structure
The AI Act is Regulation (EU) 2024/1689. It entered into force on 1 August 2024 and phases in over three years, with some deadlines now deferred to late 2027.
Its central design is a four-tier risk classification.
Tier 1 is unacceptable risk. These uses are prohibited outright. Article 5 enumerates them. They include social scoring by public authorities, real-time remote biometric identification in public spaces for law enforcement (with narrow exceptions), predictive policing based solely on profiling, emotion recognition in workplaces and schools (with narrow exceptions), untargeted scraping of facial images to build recognition databases, and several other specific practices. Two new prohibitions added by the Digital Omnibus take effect 2 December 2026: AI systems generating non-consensual intimate imagery of identifiable individuals, and AI systems generating CSAM.
The prohibited practices have been enforceable since 2 February 2025. Fines for prohibited practices are the highest in the Act: up to €35 million or 7% of global annual turnover, whichever is higher.
Tier 2 is high risk. Article 6 defines high-risk systems in two categories. Annex I systems are AI components of products regulated under existing EU product safety law: medical devices, machinery, toys, in-vitro diagnostics, and others. Annex III systems are AI systems used in specific high-risk domains: biometric identification and categorisation, critical infrastructure management, education and vocational training access, employment and worker management, access to essential services (including credit scoring), law enforcement, migration and border control, and administration of justice and democratic processes.
High-risk systems are subject to extensive obligations under Articles 8 to 15: risk management systems, data governance, technical documentation, record keeping, transparency, human oversight, accuracy and robustness, and cybersecurity. Providers of high-risk systems must undergo conformity assessment, register the system in the EU database, affix CE marking, and maintain post-market monitoring.
The Digital Omnibus has deferred these obligations. Annex III systems now come into force 2 December 2027 rather than 2 August 2026. Annex I systems come into force 2 August 2028. This is a substantial deferral, and it is intended to give organisations more time to build the compliance infrastructure. It does not eliminate the obligations.
Tier 3 is limited risk. This tier is defined by Article 50 and consists mainly of transparency obligations. Users must be informed when they are interacting with an AI system. Deepfakes and manipulated content must be labelled as such (subject to some carve-outs). Generative AI systems must ensure their outputs are marked as machine-generated in machine-readable format. The Omnibus defers the machine-readable synthetic content marking obligation for pre-existing systems from 2 August 2026 to 2 December 2026.
Tier 4 is minimal or no risk. Most AI systems fall here. Spam filters, video game AI, inventory optimisation, and countless other uses. The Act imposes no AI-specific obligations on tier 4 systems, though general law (GDPR, consumer protection, non-discrimination) continues to apply.
Sitting alongside this four-tier structure is a separate set of obligations for general-purpose AI (GPAI) models, defined in Articles 51 to 55.
GPAI: the parallel track
GPAI models are the foundation models that most enterprise AI is now built on. GPT-4, Claude, Gemini, Llama, Mistral, and their competitors are all GPAI models. The Act treats them separately because they are not “systems” in the traditional sense; they are components that can be integrated into many downstream systems.
The GPAI obligations became enforceable on 2 August 2025 for models placed on the market after that date. Models placed on the market before 2 August 2025 must be brought into compliance by 2 August 2027.
All GPAI providers must provide technical documentation to the AI Office and to downstream providers, comply with the EU Copyright Directive, and publish a summary of the content used for training. The summary must follow the template published by the AI Office.
Providers of GPAI models with systemic risk have additional obligations. Systemic risk is presumed for models trained with cumulative compute above 10^25 FLOPs. These providers must conduct model evaluations, perform adversarial testing (red teaming), track and report serious incidents, and ensure cybersecurity protections.
Providers of open-weight models have lighter obligations, being subject only to copyright and training data summary requirements, unless the open model presents systemic risk.
The GPAI Code of Practice, finalised in July 2025, provides voluntary compliance guidance across three chapters: transparency, copyright, and safety and security. Signing the Code is optional, but it creates a “presumption of conformity” that has significant weight in enforcement proceedings. Most major GPAI providers have signed.
The AI Office was granted expanded supervisory competence in the Digital Omnibus. It now has exclusive competence over AI systems where the GPAI model and the AI system are developed by the same provider (with carve-outs for certain regulated products and specific use cases), and over AI systems integrated into very large online platforms or search engines under the Digital Services Act.
Figure 1: The four-tier structure
Figure 1 shows the four-tier risk pyramid with the GPAI parallel track. Each tier has its own compliance date, its own obligations, and its own maximum fine. What the figure makes clear, and what discussions of the Act often miss, is that a single organisation can have systems in multiple tiers at once. A recruitment tool built on GPT-4 might be a high-risk Annex III system consuming a GPAI model, subject to both tracks.
Compliance obligations for high-risk systems
The high-risk obligations are the substantive core of the Act. If you are building or deploying a high-risk system, this is what you have to do.
Risk management system (Article 9). You must maintain a documented risk management system throughout the AI system’s lifecycle. It has to identify and analyse foreseeable risks to health, safety, and fundamental rights. It has to estimate residual risk after mitigations, and it has to be updated as the system evolves.
Data governance (Article 10). Training, validation, and testing data must be relevant, representative, and, to the extent possible, free of errors and complete. You must examine data for possible biases likely to affect health, safety, or fundamental rights, and implement mitigations. Data collection and preparation practices must be documented.
Technical documentation (Article 11). You must maintain technical documentation demonstrating conformity with the Act. Annex IV specifies its contents in detail. It has to describe the system, its intended purpose, its design, its training data, its performance metrics, and its risk assessment.
Record keeping (Article 12). High-risk systems must automatically log operational events. Logs must be retained for a period appropriate to the system’s intended purpose, and must enable post-market monitoring and, where relevant, investigation.
Transparency and information (Article 13). You must provide clear information to deployers about the system’s characteristics, capabilities, limitations, and intended purpose. Instructions for use must enable safe and effective operation.
Human oversight (Article 14). The system must be designed to enable human oversight. Article 14 is specific about what “oversight” means in practice. It has to enable the person overseeing the system to fully understand its capabilities and limitations, to remain aware of automation bias, to correctly interpret its outputs, to decide not to use it in a particular case, and to intervene or stop the system.
Accuracy, robustness, and cybersecurity (Article 15). The system must achieve appropriate levels of accuracy for its intended purpose. It must be resilient to errors, faults, and inconsistencies. It must be protected against attempts to alter its use or performance.
Conformity assessment and CE marking. Before placing a high-risk system on the market or putting it into service, providers must complete a conformity assessment. For most Annex III systems, this can be a self-assessment; for some (particularly those involving biometrics), it must involve a notified body. The assessed system receives CE marking and must be registered in the EU database of high-risk systems.
Post-market monitoring and incident reporting. Providers must operate a post-market monitoring system to track performance in the field. Serious incidents must be reported to national competent authorities within specific timeframes.
Deployers of high-risk systems have their own set of obligations, which article 6 will cover.
What the Digital Omnibus changed
The 7 May 2026 provisional agreement on the Digital Omnibus is worth understanding in its own right, because it changed several things at once.
The most substantive change was the deferral of high-risk deadlines. Annex III systems, which most enterprise AI falls under, moved from 2 August 2026 to 2 December 2027. That is sixteen months. For most organisations, that is the difference between panic and pace.
The Omnibus also added two prohibited practices, effective 2 December 2026: non-consensual intimate imagery and CSAM. These are substantive additions, not clarifications.
The Omnibus clarified AI Office competence in ways that centralise supervision for large-scale GPAI-based systems, while preserving national authority for regulated products and specific sectors.
The Omnibus deferred the machine-readable synthetic content labelling obligation for pre-existing systems by four months (to 2 December 2026). New systems placed on the market after 2 August 2026 must comply from placement.
Regulatory sandbox obligations for member states moved by one year (to 2 August 2027).
These are the major changes. There are others, including simplifications aimed at reducing SME compliance burden, but the ones above are the ones most likely to affect your planning.
Two cautions. First, at the time of writing the Omnibus is a provisional political agreement pending formal adoption. Treat the dates as planning anchors, not certainties. Second, the deferrals apply to specific obligations. Prohibited practices and GPAI obligations are unaffected and enforceable now.
Fines and enforcement
The AI Act’s fine structure under Article 99 exceeds GDPR in most tiers.
Prohibited practices: up to €35 million or 7% of global annual turnover. Most other obligations: up to €15 million or 3% of global annual turnover. Providing false or misleading information: up to €7.5 million or 1% of global annual turnover. For SMEs, the lower of the two amounts applies.
Enforcement is split. The AI Office within the European Commission’s DG CONNECT has exclusive competence over GPAI providers and, following the Omnibus, over certain integrated AI systems. National competent authorities enforce most other obligations. Each member state must designate its authorities and communicate them to the Commission.
Enforcement is not theoretical. The AI Office can request information from providers, demand access to models, order mitigations, and recall models from the EU market. National authorities have market surveillance powers similar to those they exercise under existing product safety law.
Interaction with GDPR
The AI Act does not replace GDPR. Both apply concurrently where AI systems process personal data. National data protection authorities retain jurisdiction over personal data processing aspects; market surveillance authorities enforce the AI Act.
The practical implication is that a compliance programme cannot be built for one regime in isolation. Data Protection Impact Assessments under GDPR often overlap with, but do not substitute for, the Fundamental Rights Impact Assessment required for certain high-risk systems under Article 27 of the AI Act. Documentation obligations under both regimes overlap but are not identical.
For most organisations, integrating AI Act compliance into existing GDPR compliance programs is more efficient than running them separately. The tooling, the accountability structures, and the audit processes benefit from consolidation. The specific obligations remain distinct.
Figure 2: Compliance timeline as of mid-2026
Figure 2 shows the phased compliance timeline as of mid-2026, incorporating the Digital Omnibus deferrals. Note the shape: the enforceable obligations that are already in force (prohibited practices, GPAI models placed on market after August 2025) sit on the left; the deferred obligations (Annex III high-risk systems, Annex I products) sit on the right, with a wider corridor before enforcement. The middle contains obligations arriving in late 2026 and 2027.
What a practitioner should do now
Three things, in order of priority.
Complete your AI inventory. You cannot classify systems you have not identified. The inventory should include every AI system in use or in development, its business owner, its intended purpose, its data flows, and a preliminary risk classification. Most organisations that start this process discover more systems than expected.
Classify against the Act. For each inventory item, determine whether it is prohibited (stop it), high-risk (put full obligations in place), limited risk (transparency obligations), or minimal risk (inventory only). Also determine whether you are a provider, a deployer, or both. Article 6 covers this distinction, but you need to make the call at inventory time.
Focus on GPAI dependencies. Most enterprise AI is built on foundation models. Understand which foundation models you depend on, whether their providers have signed the Code of Practice, what their technical documentation says about capabilities and limitations, and what your fallback strategy is if a model is deprecated, priced out of your budget, or subject to enforcement action.
The next article goes into the provider/deployer distinction in depth. It is the single most consequential classification you will make under the Act, because it determines whether the substantive high-risk obligations apply to you directly or apply to someone else who then imposes indirect obligations on you.