On this page
- What GDPR regulated, and the gap it left
- From data governance to decision governance
- The EU AI Act timeline after the Digital Omnibus
- The risk tiers: where your AI features sit
- Provider or deployer: the role question most teams get wrong
- What high-risk compliance requires in practice
- A proposed method for classifying AI features
- Where GDPR and the EU AI Act collide
- Why "we don't sell to Europe" is not a defence
- Healthcare teams have the longest runway and the heaviest load
- What leadership teams should do in the next 12 months
- The difference that matters
- FAQ
When GDPR took effect in May 2018, most technology companies followed the same path. First came emergency legal reviews, then data mapping, new privacy notices, and consent banners. Then came a steady state. GDPR asked three bounded questions about personal data: what you hold, why you hold it, and who can see it. Those answers were expensive to produce, but a company could reach a defensible position and get back to building.
The EU AI Act (Regulation (EU) 2024/1689) asks a different question: what power do your systems exercise over people’s lives? Our position at Ailoitte is that this question cannot be answered by a legal team alone. The answer lives in product architecture: what a model is allowed to decide, what it logs, who can override it, and how its accuracy is measured after launch.
What GDPR regulated, and the gap it left
GDPR is a framework for informational accountability. It gives individuals rights over their personal data: to know how it is used, to access and correct it, to have it erased, and to object to certain processing.
GDPR came closest to regulating AI in Article 22, which limits decisions “based solely on automated processing” that produce legal or similarly significant effects. Article 22 is narrow. It applies to solely automated decisions. Its safeguards mostly take effect after a decision is made. It does not require a company to assess an AI system’s risks before deployment, document how the system was trained, or design human oversight into the workflow.
That leaves a gap. A company can collect data with valid consent and process it lawfully. It can still deploy a model that systematically disadvantages certain applicants for a loan, a job, or a clinical pathway, without breaching any specific GDPR obligation about the model itself. The EU AI Act was written to close that gap between data governance and decision governance.
From data governance to decision governance
The EU AI Act classifies AI systems by the decisions they influence and the people those decisions affect. The sophistication of the model and the sensitivity of the data do not set the risk tier. A modest model that ranks job applicants falls under Annex III. A frontier model that drafts marketing copy usually carries only transparency duties.
One qualification matters. The Act applies only to software that meets its definition of an “AI system” in Article 3(1): a machine-based system that infers from its inputs how to generate outputs. The European Commission’s guidelines on the AI system definition indicate that purely rule-based software may fall outside it. Classification therefore starts with two questions: is this an AI system, and what decision does it influence?
This is why we treat EU AI Act compliance as a product design problem. A GDPR programme can largely be run by legal, security and data engineering teams. EU AI Act obligations reach directly into engineering workflows: risk management, technical documentation, logging, human oversight, accuracy testing and post-market monitoring. A team that assumes its GDPR work gets it most of the way to AI Act compliance will usually find that the hardest work has not started.
The EU AI Act timeline after the Digital Omnibus
The EU AI Act timeline changed in July 2026. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on July 24, 2026, and entered into force on July 27, 2026 (Cuatrecasas). It postponed the high-risk deadlines. It did not cancel them, and it did not move the transparency rules.
| Date | What applies | Status in October 2026 |
|---|---|---|
| February 2, 2025 | Prohibited practices (Article 5). AI literacy (Article 4), since softened by the Omnibus to “support” literacy | In force |
| August 2, 2025 | Obligations for general-purpose AI model providers. Governance and penalty provisions | In force |
| August 2, 2026 | Article 50 transparency duties: AI interaction disclosure, deepfake and AI-text disclosure | In force |
| December 2, 2026 | Article 50(2) machine-readable marking for generative systems already on the market before August 2, 2026. New Article 5 ban on AI that generates non-consensual intimate imagery or child sexual abuse material | Weeks away |
| August 2, 2027 | Deadline for Member States to set up at least one AI regulatory sandbox | Upcoming |
| December 2, 2027 | High-risk obligations for Annex III systems (employment, credit, education, essential services, biometrics and others) | Upcoming |
| August 2, 2028 | High-risk obligations for AI built into products covered by Annex I legislation, such as medical devices and in vitro diagnostics | Upcoming |
Our reading of the delay is simple. Fourteen months is roughly the time it takes to rebuild an AI feature’s architecture properly. It is not enough to finish a classification exercise in late 2027 and then start engineering. For a closer look at what the postponement changed, see our breakdown of what the EU AI Act delay means for your app.
The risk tiers: where your AI features sit
The EU AI Act sorts AI systems into four tiers. The tier sets your obligations, your deadlines, and your exposure to fines. Misclassifying a system in either direction is itself a compliance failure.
| Tier | Examples | What it means for your product |
|---|---|---|
| Prohibited (Article 5) | Social scoring; manipulative techniques that exploit vulnerabilities; emotion recognition in workplaces and schools (outside medical or safety uses); untargeted scraping of facial images; predictive policing based solely on profiling; from December 2, 2026, AI that generates non-consensual intimate imagery | Banned since February 2, 2025. There is no compliance pathway |
| High-risk (Article 6, Annex III and Annex I) | Recruitment and worker management, creditworthiness, life and health insurance pricing, education access and assessment, essential public services, biometrics, and AI safety components of regulated products such as medical devices | Full provider and deployer obligations from December 2, 2027 (Annex III) or August 2, 2028 (Annex I) |
| Transparency (Article 50) | Chatbots, voice agents, generative image, audio and video tools, AI-generated text published to inform the public | Disclosure and labelling duties apply now |
| Minimal risk | Spam filters, most recommendation engines, internal productivity tools | No AI Act duties beyond AI literacy, but GDPR and consumer law still apply |
Two provisions make classification harder than the table suggests.
First, Article 6(3) offers a narrow exit from Annex III. A system is not high-risk if it does not materially influence decision outcomes. Examples include a narrow procedural task or a preparatory step for a human assessment. The exit is closed to any Annex III system that profiles natural persons. A provider that relies on it must document the assessment before launch and register the system (Article 6).
Second, classification follows function, not product category. A healthcare platform that uses AI to suggest documentation wording is likely minimal-risk. The same platform using AI to support triage decisions is likely high-risk. The tier can also change as the product evolves. We recommend making re-classification a release gate for any change to what an AI feature decides or for whom. For a plain-language walkthrough of each tier, see our guide to how the EU AI Act classifies AI products.
Provider or deployer: the role question most teams get wrong
Your role under the EU AI Act matters as much as your risk tier. A company that builds a third-party foundation model into its own product is usually not a passive deployer. If you place an AI system on the market under your own name, you are its provider. Article 25 also turns a deployer, distributor, or importer into a provider of a high-risk system in three cases:
- They put their name or trademark on a high-risk system already on the market.
- They make a substantial modification to a high-risk system.
- They change a system’s intended purpose so that it becomes high-risk. This includes taking a general-purpose AI system into an Annex III use.
The general-purpose model vendor has its own duties under Chapter V of the Act. Those duties cover the model, not your application. If you wrap a large language model (LLM) in a candidate-screening product, you carry the high-risk provider obligations for that product. The model vendor’s compliance does not discharge them.
Deployers carry real duties too, under Article 26. They must use the system according to its instructions and assign human oversight to competent staff. They must keep automatically generated logs for at least six months and inform affected people when a high-risk system makes or supports decisions about them. Public bodies, private providers of public services, and deployers in credit scoring or life and health insurance pricing must also complete a fundamental rights impact assessment under Article 27.
What high-risk compliance requires in practice
High-risk compliance is a set of engineering obligations that run for the life of the system. Each one maps to a concrete build decision.
| Obligation | What it requires | What engineering has to build |
|---|---|---|
| Risk management (Article 9) | A continuous process to identify, evaluate and mitigate foreseeable risks across the lifecycle | A risk register tied to releases, with re-assessment triggers |
| Data governance (Article 10) | Documented data sourcing, labelling, cleaning, bias examination and known gaps | Dataset lineage, versioned training and test sets, bias evaluation reports |
| Technical documentation (Article 11, Annex IV) | Purpose, design, training method, performance metrics and limitations, kept current | Model cards and system documentation generated from the build pipeline, not written once |
| Record-keeping (Article 12) | Automatic logging of events across the system’s lifetime | Tamper-evident decision logs with input, output, model version and reviewer actions |
| Transparency to deployers (Article 13) | Instructions that explain capabilities, limits and correct use | Deployer-facing documentation and in-product guidance |
| Human oversight (Article 14) | People able to understand outputs, spot anomalies, override and stop the system | Review queues, override controls, confidence signals and a stop mechanism that operators actually use |
| Accuracy, robustness, cybersecurity (Article 15) | Declared performance levels maintained; resilience to errors and attacks | Evaluation suites, drift monitoring, adversarial testing |
Human oversight deserves particular attention. An interface that technically allows an override but makes it slow, hidden, or socially costly does not meet the standard of effective oversight. Oversight is a user experience (UX) obligation as much as a legal one. Our analysis of AI in the hiring process shows why recruitment tools are where this tension surfaces first.
A proposed method for classifying AI features
Proposed framework, pending Ailoitte approval. Most classification exercises stall because teams try to classify a whole product at once. We propose classifying each AI feature against four questions. Every answer produces a written record you can show to a regulator, an enterprise buyer, or an acquirer.
| Question | What you decide | Evidence it produces | Owner |
|---|---|---|---|
| 1. Decision | Is this an AI system under Article 3(1)? What decision does it influence, about whom? Does it match Annex III or Annex I? Does the Article 6(3) exit apply? | Classification memo per feature, with the tier and its reasoning | Product lead with legal |
| 2. Role | Are we provider, deployer, or both? Does Article 25 make us a provider? | Role statement per feature and per customer contract | Legal with engineering |
| 3. Data | What is the GDPR lawful basis for training and inference? Is special category data involved? Is a DPIA needed? | Updated record of processing, DPIA, and Article 4a assessment where bias testing needs sensitive data | DPO with data engineering |
| 4. Control | Where can a human understand, override, or stop the output? What is logged, and what is disclosed to users? | Oversight design, logging specification, Article 50 disclosure inventory | Engineering with design |
The method is deliberately simple. Its value is that it makes the classification decision explicit and owned. A verbal conclusion that a feature is “minimal risk” offers no protection when the question is asked formally.
Where GDPR and the EU AI Act collide
GDPR and the EU AI Act apply at the same time to any AI system that processes personal data about people in the EU, which covers most enterprise AI. They do not replace each other. In five places, they create combined obligations, and in some of those places, they pull in different directions.
| Collision point | GDPR says | EU AI Act says | What to do |
|---|---|---|---|
| Data minimisation vs data quality | Collect only what is necessary for a specified purpose | Training data must be relevant, sufficiently representative and examined for bias (Article 10) | Justify dataset scope in the DPIA. Use synthetic or anonymised data where it works. Document why more data was needed where it does not |
| Sensitive data for bias testing | Article 9 restricts special category data | New Article 4a allows it, by exception, to detect and correct bias, with strict safeguards and deletion afterwards | Treat Article 4a as a narrow, documented exception, not a general licence |
| Automated decisions vs human oversight | Article 22 limits solely automated decisions with significant effects | Article 14 requires effective oversight. Article 86 gives a right to an explanation for certain high-risk decisions | Design one review workflow that satisfies both, and do not assume one definition maps to the other |
| Impact assessments | DPIA under Article 35 for high-risk processing | Fundamental rights impact assessment (Article 27) for certain deployers, which may build on the DPIA | Run one combined assessment with two sets of conclusions |
| Erasure vs model memory | Right to erasure under Article 17 | Technical documentation must describe training data composition and governance | Track which records trained which model version. Plan retraining or unlearning for erasure requests |
Incident reporting also runs on two clocks. GDPR requires notice of a personal data breach within 72 hours. The AI Act requires providers of high-risk systems to report serious incidents, generally within 15 days and faster for the most severe cases (Article 73). One event can trigger both.
The interaction is still moving. The European Data Protection Board and the European Commission have announced joint guidelines on the interplay between GDPR and the AI Act (IAPP). Separately, the Digital Omnibus package proposes GDPR amendments, including a legitimate-interest basis for AI development. The Council agreed its negotiating mandate on October 21, 2026, but the amendments are not law (EUTechReg). Plan against the GDPR text in force today.
Why “we don’t sell to Europe” is not a defence
The EU AI Act follows market access, not headquarters. Under Article 2, it applies to providers placing AI systems on the EU market wherever they are based. It also applies to providers and deployers outside the EU when their system’s output is used in the EU. A US or Indian company whose model scores EU applicants is in scope without an EU office.
The Act also sets the reference point for enterprise procurement. Global platforms rarely build separate jurisdictional editions. Buyers increasingly ask vendors to map their controls to the AI Act, the NIST AI Risk Management Framework and ISO/IEC 42001, the international standard for AI management systems. Not every jurisdiction is following the EU: Canada’s proposed Artificial Intelligence and Data Act died when Parliament was prorogued in January 2025 (DLA Piper). Our view is that building to the EU standard once and mapping it to other frameworks costs less than building separate programmes per market.
Healthcare teams have the longest runway and the heaviest load
AI that is a safety component of a medical device, or is itself a medical device, falls under Annex I. Its high-risk obligations now apply from August 2, 2028. The extra time reflects real complexity: these systems face conformity assessment under both the Medical Device Regulation and the AI Act, usually through the same notified body. Teams building clinical decision support should align AI Act documentation with their existing quality management and clinical evaluation files now, not in 2028. Our healthcare software development guide covers the regulatory groundwork, and our analysis of building a GDPR-compliant healthcare application covers the data layer.
What leadership teams should do in the next 12 months
EU AI Act readiness needs named owners at the leadership level, because classification decisions change roadmaps, sales positioning, and valuations.
- CEO and CPO: own classification. Whether a feature is high-risk is a product strategy decision with legal consequences. Approve the classification memo for every AI feature, and make re-classification a release gate.
- CTO and engineering: close the transparency gap now. Article 50 duties already apply. Audit every chatbot, voice agent, and generative output for disclosure and labelling. Finish machine-readable marking before December 2, 2026 if your system was on the market before August 2026.
- Engineering: build the evidence layer before 2027. Decision logging, model versioning, dataset lineage, and override controls are far cheaper to build into a release than to retrofit after an audit request. Our explainer on AI governance covers the operating model, and explainable AI covers the techniques behind meaningful oversight.
- DPO and legal: merge the assessments. Run one combined DPIA and AI Act assessment per high-risk feature, and update supplier contracts to allocate provider and deployer duties.
- CFO: fund governance as a commercial asset. Fines reach EUR 35 million or 7% of worldwide annual turnover for prohibited practices, and EUR 15 million or 3% for most other breaches (Article 99). The nearer cost is commercial: enterprise buyers and acquirers already ask for classification records and oversight evidence in due diligence.
The difference that matters
GDPR changed how companies handle data. The EU AI Act changes how companies build and run systems that make decisions about people. The Digital Omnibus moved the high-risk deadlines, but it did not reduce what those deadlines require. The required documentation cannot be written credibly after the fact, and effective oversight cannot be added to a system designed without it.
The practical question for a leadership team is not whether the Act applies. For most AI products with EU users, it does. The question is whether you can show a regulator, a customer or an acquirer how each AI feature was classified, who owns it, and how a human stays in control. Teams that start that work now will meet the 2027 and 2028 deadlines as a release milestone, not an emergency.
Sunil Kumar is CEO of Ailoitte, an AI-native engineering company building intelligent applications for startups and enterprises. He created the AI Velocity Pods model, delivering production-ready AI products 3x faster than traditional teams. Sunil writes about agentic AI, GenAI strategy, and outcome-based engineering.
About Ailoitte
India
Job Portal
