EU AI regulations are not one law. At the center is the AI Act, Regulation (EU) 2024/1689, which sorts AI systems by what they are used for and puts duties on the companies that build and deploy them. Around it sit rules that were not written for AI but apply to it anyway: GDPR for personal data, the Data Act for data access and cloud switching, NIS2 for cybersecurity in critical sectors, and DORA for financial services.
This is the overview we give companies building or buying AI software in the EU, with the AI Act dates as amended by the Digital Omnibus in July 2026. We are engineers, not lawyers. Where a question needs counsel, we say so.
The AI Act in one page
The Act regulates use cases, not technologies. A language model is not high risk. A system that uses one to rank job applicants is. Classification follows what the system does and who it affects, not which model it calls or where it is hosted.
There are four tiers. Prohibited practices, such as social scoring, are banned outright. High risk covers the areas in Annex III, among them biometrics, employment, education, credit scoring and critical infrastructure, plus AI that is a safety component of regulated products. Limited risk carries transparency duties, mainly telling people they are dealing with AI. Everything else is minimal risk. Most business software, including internal copilots, document search and support assistants, sits in limited or minimal.
Your role matters as much as your tier. A provider develops a system and places it on the market under its own name. A deployer uses a system under its own authority. If you build a product on a model API, you are the provider of that AI system, but not of the general-purpose model underneath. Those model obligations sit with the model vendor. A deployer can also become a provider, for example by putting its own name on a high-risk system, substantially modifying one, or changing a system's purpose so that it becomes high risk.
Fines for prohibited practices reach €35 million or 7% of worldwide annual turnover, whichever is higher. Other breaches carry lower ceilings.
The AI Act timeline after the Digital Omnibus
The Digital Omnibus on AI was approved by the European Parliament on 16 June 2026, adopted by the Council on 29 June 2026, and entered into force on 27 July 2026. It moved the high-risk deadlines and left the transparency deadline where it was. Any article that still gives August 2026 as the high-risk date is out of date.
| Date | What applies | Who should care |
|---|---|---|
| 1 August 2024 | The AI Act enters into force | Everyone, as the start of the clock |
| 2 February 2025 | Prohibited practices banned; the AI literacy duty applies | Every provider and deployer |
| 2 August 2025 | Obligations for general-purpose AI models | Model vendors, rarely their customers |
| 2 August 2026 | Article 50 transparency: disclose AI interaction, label deepfakes | Anyone shipping chatbots or generated content |
| 2 December 2026 | Grace period ends for machine-readable marking of AI output in systems already on the market; two new prohibitions apply | Providers of generative AI systems |
| 2 December 2027 | High-risk obligations for Annex III and Article 6(2) systems | HR tech, credit, education, biometrics, critical infrastructure |
| 2 August 2028 | High-risk obligations for safety components of products under Annex I | Medical devices, machinery and other regulated products |
The two new prohibitions cover systems that generate non-consensual intimate imagery of identifiable people, and systems that generate child sexual abuse material.
Three other changes matter for planning. Systems placed on the market before 2 August 2026 are only caught by the high-risk rules if they are substantially modified after that date. The AI literacy duty is softer: providers and deployers must support AI literacy among staff rather than guarantee a specific level. And small mid-caps, meaning companies under 750 employees and up to €150 million turnover, now get relief alongside SMEs. That relief covers simplified technical documentation, proportionate quality management and priority in regulatory sandboxes.
GDPR still does most of the day-to-day work
For most AI features, GDPR (Regulation (EU) 2016/679) creates more work than the AI Act. It applies whenever personal data is processed, and AI systems process it in places teams forget: prompts, retrieval indexes, conversation logs, evaluation sets and fine-tuning data. The articles that come up most in AI projects:
- Article 5, purpose limitation and data minimization: send the model only what the task needs.
- Article 6, a lawful basis for each purpose, including any reuse of data to train or tune a model.
- Article 22, limits on decisions based solely on automated processing that have legal or similarly significant effects on a person.
- Article 28, a processor agreement with every AI vendor that handles personal data on your behalf.
- Article 35, a data protection impact assessment where processing is likely to result in a high risk to people's rights.
The two laws sit side by side. The AI Act does not replace GDPR, and GDPR compliance does not make a high-risk system compliant with the AI Act. They do connect: deployers of high-risk systems are expected to use the provider's documentation when they carry out their data protection impact assessment. For training and using models, the European Data Protection Board's Opinion 28/2024, from December 2024, is the most useful current reading.
A separate Digital Omnibus proposal from November 2025 would amend GDPR and other data laws. As of September 2026 it was still being negotiated, with no final text. Build for GDPR as it stands today.
The Data Act: who controls the data, and how customers leave
The Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025. It is not an AI law, but it reaches AI teams in two ways.
If you make connected products or related services, users have a right to the data their use generates, and they can share it with third parties. Products placed on the market from 12 September 2026 must be designed so that this data is accessible by default. That is an obligation if you make devices, and an opening if you build AI on top of someone else's machine data.
If you sell software as a service, AI software included, you are likely a provider of a data processing service. Customers must be able to switch to another provider and take their data with them, and switching charges must be gone entirely by 12 January 2027. Services custom built for one customer, and not offered at broad commercial scale, carry narrower obligations. Where personal data is involved, GDPR takes precedence.
NIS2 and DORA: security rules that reach your AI system
NIS2
NIS2, Directive (EU) 2022/2555, had to be transposed into national law by 17 October 2024, so the exact rules depend on the member state. It covers medium-sized and large organizations in 18 sectors, including energy, health, transport, digital infrastructure and managed ICT services. Entities in scope must take cybersecurity risk management measures, supply chain security included, and their management bodies must approve those measures and can be held liable. Significant incidents follow a fixed clock: an early warning within 24 hours, a notification within 72 hours, and a final report within a month of the notification.
For a software team, that means two things. If your company is in scope, your AI systems are part of the attack surface and your model provider is a supplier to assess. If you sell to companies in scope, expect their supplier questionnaires to ask about prompt injection, model providers and where data goes.
DORA
DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 to banks, insurers, investment firms and other financial entities. It covers ICT risk management, incident reporting, resilience testing and the management of ICT third-party providers. If you sell AI software to a financial entity, you are one of those providers. Your contract will need the terms DORA lists in Article 30: service descriptions, data locations, incident assistance, termination rights, and for critical or important functions, audit rights and exit plans. Your service will also appear in the customer's register of information.
Two more rules deserve a line. The Cyber Resilience Act covers software and hardware products with digital elements. Its reporting duties have applied since 11 September 2026, the rest follows on 11 December 2027, and pure SaaS is mostly outside it. The revised Product Liability Directive treats software, AI systems included, as a product, for products placed on the market after 9 December 2026.
How the rules stack on one AI feature
Take a support assistant inside a B2B SaaS product that answers questions from customer tickets. Under the AI Act it is limited risk, so since 2 August 2026 users must be told they are talking to an AI. GDPR applies because tickets contain names and contact details. You need a processor agreement with the model vendor, an EU region where possible, minimized prompts and a retention limit on logs. The Data Act treats your SaaS as a data processing service, so customers must be able to export their data and leave. If a customer is a hospital, NIS2 arrives through their supplier questionnaire. If a customer is a bank, DORA arrives through their contract.
Now change one thing. The same team builds a feature that ranks job applicants. That is an Annex III employment use case, so it is high risk from 2 December 2027. The provider then owes risk management, data governance, technical documentation, logging, human oversight and accuracy testing. Article 22 of GDPR matters as well. The model did not change. The use case did.
| Rule | Applies to | What it asks of a software team | Key dates |
|---|---|---|---|
| AI Act | Providers and deployers of AI systems used in the EU | Classification and transparency; for high risk, logging, oversight and documentation | 2 August 2026 transparency; 2 December 2027 high risk |
| GDPR | Anyone processing personal data | Lawful basis, minimization, processor agreements, impact assessments | Has applied since 25 May 2018 |
| Data Act | Connected products, related services, cloud and SaaS providers | Data access by design, data export, switching without charges | 12 September 2026 design; 12 January 2027 no switching charges |
| NIS2 | Medium and large entities in 18 sectors | Security measures, supply chain checks, incident reporting | National laws, transposition deadline 17 October 2024 |
| DORA | Financial entities and their ICT providers | Article 30 contract terms, incident assistance, resilience testing | Has applied since 17 January 2025 |
| Cyber Resilience Act | Software and hardware products with digital elements | Secure development, vulnerability handling and reporting | 11 September 2026 reporting; 11 December 2027 the rest |
| Product Liability Directive | Manufacturers of products, now including software | Liability for defective software, AI systems included | Products placed on the market after 9 December 2026 |
What is engineering, and what needs a lawyer
Most of what these laws ask for is built, not written. That is good news for a software team, because the work can start before anyone writes a legal opinion. The engineering side:
- Logging of inputs, outputs, model versions and prompt versions, with a defined retention period.
- Pinned model versions, so behavior does not change without a deploy.
- A human override that exists in the product, and a record of when it was used.
- AI disclosure in the interface, and machine-readable marking of generated content.
- Data minimization and redaction before anything reaches a model provider.
- EU region endpoints, or self-hosted models where the data requires it.
- Data export and deletion that actually work, for GDPR requests and Data Act switching.
- Technical documentation written alongside the build, not after it.
The counsel side:
- The final classification of any borderline use case.
- Whether you are a provider or a deployer when you rebrand, modify or repurpose someone else's system.
- Lawful basis decisions, and sign-off on impact assessments.
- Contract terms: processor agreements, DORA clauses, allocation of liability.
- Whether NIS2 applies to you under your national law.
What to do this quarter
- 01List every AI feature you ship or use, built or bought.
- 02Classify each one by use case and write down the reasoning.
- 03Check that every chatbot and every piece of generated output carries a disclosure. That duty already applies.
- 04Add logging and version pinning to anything in production. You cannot reconstruct last month's outputs later.
- 05Review AI vendor contracts for processor terms, EU regions and training opt-outs.
- 06Ask customers in finance, health and energy what their DORA and NIS2 teams will want from you.
- 07Put 2 December 2026 and 2 December 2027 on the roadmap if you ship generative or high-risk features.
If you want this applied to your own systems, it is part of our AI readiness assessment. For a single AI feature already in production, a five day review covers it. We are an EU company working under EU law, and we build what we recommend. So the advice arrives with an implementation plan attached, not a slide deck.