AI Act key dates: what your company must do at each regulatory milestone

Updated 4 August 2026: the Digital Omnibus (Regulation (EU) 2026/1744, published in the EU Official Journal on 24 July 2026 and in force since 27 July) postponed the Annex III high-risk obligations from 2 August 2026 to 2 December 2027, and the Annex I ones to 2 August 2028. 2 August 2026 remains a real date, but only for Art. 50 transparency. We've updated the table and sections below accordingly. Source: EUR-Lex, Regulation (EU) 2026/1744.

The complete AI Act timeline

Regulation (EU) 2024/1689 entered into force on 1 August 2024, twenty days after its publication in the Official Journal. But application was structured in a phased way to give companies and Member States time to adapt. The result is an AI Act timeline with four main milestones that every organisation operating in the EU must internalise:

The key point is that the first two milestones have already passed. February and August 2025 are not future dates: they are obligations that have been in force for months and that national authorities —AESIA and AEPD in Spain— can already inspect and sanction.

What each date means for companies

2 February 2025: prohibitions and literacy

This was the first milestone with direct consequences for any organisation using AI. Article 5 prohibits without exception a series of practices that the legislator considered to be of unacceptable risk. These are not high-risk systems subject to compliance; they are systems directly prohibited:

• Subliminal manipulation systems exploiting psychological vulnerabilities.
• Social scoring by public authorities.
• Real-time biometric identification in public spaces by law enforcement, with very specific limited exceptions.
• Emotion inference systems in workplace and educational settings.
• Biometric categorisation to infer race, political opinions, religious beliefs or sensitive biometric data.

Alongside the prohibitions, Article 4 established the obligation of AI literacy: providers and deployers must ensure that people working with or under the supervision of AI systems have a sufficient level of knowledge about their operation, capabilities and limitations. This has been operational since February 2025.

2 August 2025: GPAI and institutional governance

The second milestone activated the full regime for general-purpose AI models (GPAI): GPT-4, Claude, Gemini and any language, image or code model of general use. Providers of these models must maintain updated technical documentation, respect copyright law on training data, publish summaries of the content used for training and comply with acceptable use policies. For models with systemic risk (the most capable ones), obligations are additional and include risk assessments and incident reporting.

At institutional level, the European Commission's AI Office has been fully operational since August 2025, with exclusive competences over GPAI. In Spain, AESIA has been operational since 2024. The authorities exist, they have a mandate and they have enforcement powers. This is not a hypothetical scenario.

2 August 2026: Art. 50 transparency (high-risk is no longer here)

Article 50 on transparency comes into force on this date, unchanged: chatbots and systems that generate or manipulate content must inform users that they are interacting with AI or that content has been artificially generated. Full breakdown: what Article 50 requires and who it reaches outside the EU. What no longer happens on this date is full application of the Annex III high-risk regime — the Digital Omnibus (Regulation (EU) 2026/1744) postponed it to 2 December 2027. Keep reading for that milestone.

2 December 2027: Annex III high-risk (new date)

This is now the milestone that impacts most organisations, with 16 more months of runway than the original deadline. Articles 8 to 15 define the full regime for high-risk AI systems under Annex III: eight categories ranging from biometrics to administration of justice, including education, employment, financial services and access to essential services. For these systems, the AI Act obligations include:

• Documented and updated AI risk management system (Art. 9).
• Data governance over training, validation and testing datasets (Art. 10).
• Complete technical documentation before deployment (Art. 11).
• Automatic event logging during the system lifecycle (Art. 12).
• Transparency and information to users (Art. 13).
• Effective and verifiable human oversight (Art. 14).
• Accuracy, robustness and cybersecurity (Art. 15).

A longer deadline doesn't mean it pays to wait: building the risk management system, data quality controls and technical documentation takes months, and December 2027 arrives sooner than it looks.

2 August 2027: pre-existing GPAI models and national sandbox

GPAI models placed on the market before August 2025 must reach conformity by this date. Spain must also have at least one AI Act regulatory sandbox operational, under AESIA.

2 August 2028: systems embedded in regulated products (Annex I, new date)

The last major milestone affects AI systems incorporated into products covered by EU harmonised legislation: machinery, medical devices, vehicles, radio equipment, toys and other products regulated by specific directives or regulations. The Digital Omnibus postponed this date by one year, from the original 2 August 2027 to 2 August 2028.

Obligations by system type: prohibited, GPAI and high-risk

Prohibited systems: unacceptable risk

The list in Article 5 admits no nuance or commercial exceptions. If your organisation operates an emotion inference system in the workplace —something some providers of HR and video surveillance tools were offering until recently— that system must be withdrawn. Compliance here is not a preparation programme; it is a verification that the system does not exist in production.

GPAI models: obligations for providers

If your company develops or fine-tunes general-purpose language, image or code models and commercialises them or makes them available to third parties in the EU, you are subject to Chapter V. Obligations range from technical documentation to acceptable use policies and, for models with systemic risk, capability assessments and incident reporting to the AI Office.

If you use third-party GPAI models (OpenAI, Anthropic, Google) but do not develop them, your obligations are those of the deployer, not the provider. But you must be able to demonstrate that the provider complies with the Regulation, which in practice means reviewing contracts and technical documentation of the models you integrate.

High-risk systems: the core of AI Act compliance

The AI Act high-risk requirements are the most demanding block of the Regulation. A system enters the high-risk category if it belongs to one of the eight areas of Annex III or is embedded in a regulated product from Annex I. Classification is the provider's responsibility, and getting the classification wrong —assuming a system is not high-risk when it is— has the same consequences as not complying.

For these systems, compliance is not a document: it is an operational management system with records, periodic reviews and auditable evidence. See the article How to implement an effective Data Governance Framework in the AI Act era to understand how to structure the data layer that supports it.

What companies must do at each milestone: operational view

What should already be done (Feb and Aug 2025)

If not done, it's urgent. Not in the sense of "it needs to be planned": in the sense that it is already auditable. The AI Act obligations 2025 that should be operational are:

• Inventory of AI systems with risk classification. Exhaustive list of all systems with an AI component that the organisation develops, deploys or uses, including SaaS tools with embedded AI.
• Verification of prohibited systems. Specific review of whether any system in production falls under Article 5. If the answer is yes, immediate withdrawal.
• Documented AI literacy programme. Role-adapted, registrable and verifiable training for all staff working with AI systems.
• Internal governance with designated responsibilities. An AI Governance Officer, ad hoc committee or extension of the DPO with a clear mandate on Regulation compliance.
• Review of contracts with GPAI providers. Validate that third-party models integrated comply with Chapter V and document it.

What must be ready for December 2027

For systems classified as high-risk, full compliance with Articles 8 to 15 must be operational by 2 December 2027 (new date after the Digital Omnibus). Critical steps are:

• AI risk management system documented, iterative and linked to the system lifecycle.
• Data governance over datasets (Art. 10): origin, transformations, selection criteria, bias analysis, representativeness metrics.
• Technical documentation before deployment (Art. 11): architecture, training data, performance metrics and known limitations.
• Automatic event logging (Art. 12): record of decisions, inputs and outputs during the system lifecycle.
• Effective and verifiable human oversight mechanisms (Art. 14).
• Registration in the EU database for high-risk systems that require it.

How to prepare controls, lineage, roles and documentation

Managing AI Act compliance in complex environments —multiple systems, multiple teams, multiple jurisdictions within the EU— requires a governance infrastructure that goes beyond a checklist. In practice, the four pillars that support compliance are:

Roles with clear mandate

The AI Act distinguishes between providers (who develop or place the system on the market), deployers (who use it in a specific context) and importers and distributors. This distinction has consequences for the specific obligations of each party. Internally, the organisation needs to assign clear responsibilities: who classifies systems, who maintains technical documentation, who manages audit logs and who responds to AESIA or AEPD in an inspection.

In organisations with AI systems managed in multi-entity environments, such as business groups with several subsidiaries, this role assignment must consider both the corporate level —policies and standards— and the local level —implementation and evidence by entity.

Data lineage as the basis for auditability

Article 10 of the AI Act is, in essence, a data governance requirement: training data must be known, documented and traceable. This cannot be improvised at the time of inspection. Lineage must exist before the system enters production, and must be kept updated throughout its operational life.

In environments where training data comes from multiple sources —operational data, historical data, third-party data— end-to-end lineage from the original source to the model is the traceability document that the regulator may request. Without it, the technical documentation of Article 11 is incomplete by definition.

Maintained technical documentation, not created at the last minute

One of the most frequent mistakes in AI Act preparation is treating technical documentation as a one-off deliverable. The Regulation conceives it as a living document that is updated when the system changes: new model versions, changes in training data, new use cases or new limitations identified in production.

Minimum documentation per high-risk system includes: description of purpose and scope, technical architecture, description and metrics of datasets used, validation and testing process, performance metrics and acceptance thresholds, bias analysis, known limitations, and human oversight process.

Logging and continuous auditing

Article 12 requires high-risk systems to automatically generate event logs during their lifecycle. These logs must be sufficient to reconstruct the circumstances of any relevant system decision: what input it received, what output it produced, in what context and with what level of confidence. In practice, this requires integrating logging into the system design itself, not adding it as a subsequent layer.

For deployers, logs must be retained for the period established by the provider and, in any case, a minimum of six months or until the resolution of any ongoing regulatory investigation.

What I've seen in complex and auditable environments

Case 1 — Risk classification in a multi-entity group

In environments with multiple business units —such as airline groups with operations in different European markets— the AI system inventory invariably reveals systems that no one had formally classified. Route optimisation tools, dynamic pricing systems, demand prediction models and HR management platforms with analytical components can fall under Annex III depending on how they are used and what decisions they support.

Risk classification is not a technical exercise: it is a legal-technical exercise that requires cross-referencing the system's functional description with the Regulation's criteria. In practice, legal teams and data teams must work together on this inventory, and the result must be documented with evidence of the methodology used. A system classified as low-risk without documented justification is almost as problematic as a high-risk system without compliance.

Case 2 — Access workflows and logging in Snowflake for auditable systems

Managing data in auditable environments with multiple airlines quickly teaches that traceability is not just an AI Act requirement: it is an operational necessity. Access workflows to training data —who extracted what data, when, for what purpose and under what approval— are exactly the type of evidence that Article 10 formalises as an obligation.

Implementing granular RBAC in Snowflake with query logging and documented approval workflows not only complies with the Regulation: it also reduces response time to any internal or external audit. The data governance infrastructure built to operate well is the same one needed to demonstrate compliance.

Case 3 — Data lineage as evidence of Art. 10 compliance

In BI projects for commercial teams, data lineage is often the first element sacrificed when there is time pressure. The result is that, months later, no one can explain where a specific field in a scoring model or customer segmentation comes from. For the AI Act, that situation is unacceptable in high-risk systems.

Establishing end-to-end lineage from the start —transactional source, dbt transformation, semantic model, training dataset— turns the technical documentation of Article 11 into an artefact generated almost automatically from what already exists in the metadata catalogue, rather than a document created ad hoc for the regulator.

Common errors in AI Act preparation

AI Act enforcement is already a reality, and error patterns seen in the market have a cost beyond fines. These are the most frequent:

• Treating August 2026 as the only date that matters. The obligations of February and August 2025 are already in force. Companies that still don't have their system inventory or documented literacy programme are already in breach.
• Assuming size exempts. The AI Act applies by type of use, not by company size. An SME using a credit scoring or candidate evaluation system has the same obligations as a large corporation for that specific system.
• Delegating all responsibility to the technology provider. If your company deploys a high-risk AI system developed by a third party, you are the deployer and have your own obligations that do not disappear because the provider complies with theirs. Both responsibilities coexist.
• Classifying all systems as low or minimal risk by default. Risk classification must be done with documented criteria, cross-referencing the system's functionality with Annex III. A classification without justification is a classification without value before the regulator.
• Creating technical documentation just before inspection. Article 11 requires documentation before deployment. Documentation drafted retrospectively, even if technically correct, is difficult to defend as evidence of real compliance.
• Ignoring the AEPD as a second authority. In Spain, the AEPD can act on AI systems that process personal data even before the full application of the AI Act, under the GDPR. Many high-risk systems process personal data. This means two authorities with inspection powers, not one.

Conclusion: the AI Act is not a project, it's a date with consequences

AI Act compliance deadlines do not wait. The first two milestones have already passed and the obligations they activated are auditable today. August 2026 is months away, not years. And preparation for Article 10 —data governance over training datasets— requires infrastructure that cannot be built in weeks.

The good news is that organisations already operating with real data governance —documented lineage, roles with authority, controlled access and measured quality— have a solid foundation to adapt. AI Act compliance is not a parallel project: it is the natural extension of mature data governance into the artificial intelligence systems that governance feeds.

Those without that foundation must start now, with clear prioritisation: first inventory and risk classification, then data governance for high-risk systems, then technical documentation and logging. Not everything at once, but everything before the regulator calls.

Checklist: AI Act preparation by milestone

• Complete inventory of AI systems (in-house, deployed and SaaS with embedded AI).
• Risk classification of each system with documented justification (Annex III).
• Verification of absence of prohibited systems under Article 5 in production.
• Documented AI literacy programme, role-adapted and verifiable (Art. 4).
• Internal governance with designated responsibilities (AI Governance Officer or equivalent).
• Contracts with GPAI providers reviewed and Chapter V compliance accredited.
• AI risk management system operational for high-risk systems (Art. 9).
• Data governance over training datasets: origin, transformations and bias analysis (Art. 10).
• Complete technical documentation before deployment for high-risk systems (Art. 11).
• Automatic event logging during the lifecycle of high-risk systems (Art. 12).
• Effective and verifiable human oversight mechanisms (Art. 14).
• Registration in the EU database for systems that require it.

FAQs on AI Act key dates

What are the key AI Act dates every company should know?

After the Digital Omnibus, the main dates are: 2 February 2025 (prohibitions under Art. 5 and AI literacy), 2 August 2025 (GPAI models and institutional governance), 2 August 2026 (Art. 50 transparency only), 2 December 2027 (Annex III high-risk, postponed from August 2026) and 2 August 2028 (high-risk systems embedded in regulated products, Annex I, postponed from August 2027). The first two are already in force.

Which companies are obligated by the AI Act?

The AI Act applies to any organisation that develops, deploys or uses AI systems in the European Union, regardless of where it is established. The criterion is the market where the system operates, not the company's headquarters. This includes companies outside the EU whose systems affect people in European territory.

What are high-risk AI systems under the AI Act?

They are AI systems that may affect fundamental rights or people's safety. Annex III defines eight categories: biometrics, critical infrastructure, education, employment and HR, access to essential services (credit, insurance, housing), law enforcement, border and migration management, and administration of justice and democratic processes.

What is AI literacy as required by the AI Act?

Article 4 requires providers and deployers to ensure that staff working with AI systems have a sufficient level of knowledge about their operation, limitations and risks. Training must be documented, role-adapted and verifiable. Sending an informational PDF does not meet the spirit of the provision according to the Commission and the AEPD.

What fines does the AI Act impose for non-compliance?

Sanctions are graded by type of infringement: up to €35 million or 7% of global annual turnover for breaching Article 5 prohibitions; up to €15 million or 3% of turnover for breaching provider or deployer obligations; and up to €7.5 million or 1.5% for providing incorrect information to authorities. The higher amount between the fixed figure and the percentage of turnover always applies.