The EU AI Act is not a data protection law, and it is easy to confuse with GDPR because both apply to systems built for the EU. It is a separate, risk-based framework regulating AI systems themselves, and a product can need to satisfy both at once. This is a plain-language walk through what the Act actually does, why it exists, and the confirmed, currently in-force deferred deadlines that changed the timeline for high-risk compliance in 2026.

What the EU AI Act actually is

The EU AI Act regulates AI systems based on the risk they pose, rather than regulating a single technology or a single kind of data. It sorts AI systems into four tiers:

This is a fundamentally different question from what GDPR asks. GDPR asks: is personal data involved, and is it being handled lawfully? The EU AI Act asks: what does this AI system do, and how much risk does that create for the people affected by it? A hiring tool that scores candidates using an AI model can need to satisfy both frameworks simultaneously, GDPR because it processes candidates' personal data, and the AI Act because Annex III specifically treats recruiting tools as high-risk. If your product needs the data-protection side of this covered too, our GDPR explainer covers that separate framework in full.

What counts as high-risk

Annex III lists the categories the Act treats as high-risk. These include categories such as recruiting and HR tools, credit scoring, law enforcement tools, education and exam-scoring tools, and border control tools, among others. This is not a complete list, and a system does not need to look dramatic to qualify: an AI tool that screens job applicants, an algorithm that scores loan eligibility, or a system that auto-grades exams can all fall inside Annex III depending on exactly what it does and how it is used.

Why the Act exists

AI systems increasingly make or influence decisions that materially affect people: who gets interviewed for a job, who gets approved for credit, how a student's exam is scored. Left unregulated, these systems can encode bias, operate without meaningful transparency, and leave the person affected with no way to understand or challenge the outcome. The Act's risk-tiered structure exists to put the most scrutiny where the potential harm is greatest, rather than applying the same light-touch rules to a high-stakes hiring algorithm and a low-stakes recommendation widget.

Why a company follows it

For a high-risk system, the Act's obligations are not optional extras, they are conditions for legally placing that system on the EU market. Beyond the direct legal requirement, there is a market-trust dimension similar to GDPR: an EU buyer evaluating a hiring tool, a credit-scoring product, or an education technology platform will increasingly expect a clear, specific answer about how the system meets these obligations, not a vague assurance that "we take AI safety seriously."

The confirmed 2026 deferral: what the dates actually are now

This is the development every team building for the EU market needs to have right, because the deadlines moved in 2026 and it is easy to be working from an outdated date.

The European Commission published a "Digital Omnibus on AI" on 19 November 2025, proposing to defer the high-risk compliance deadline that had originally been set for 2 August 2026. On 7 May 2026, the Council of the EU and the European Parliament reached provisional agreement on the amendments. On 27 July 2026, the Omnibus entered into force. As of this writing, these deferred deadlines are settled current law, not a proposal:

These later dates give teams real runway, but a system that will eventually be high-risk should still be designed to meet these obligations well ahead of the deadline, not scrambled together in the final months. Building the required documentation, logging, and human-oversight mechanisms into a system from the start is materially cheaper than retrofitting them under deadline pressure.

What high-risk compliance actually means in practice

For a system that falls under Annex III or Annex I, the Act's obligations break down into a handful of concrete requirements:

Risk management system across the AI lifecycle

A documented, ongoing process for identifying and mitigating risks, not a one-time assessment before launch. For an exam-scoring tool, this means continuously monitoring for scoring drift or bias against particular student groups, not just checking once at deployment.

Data governance for training, validation, and testing data

The datasets used to build and evaluate the system need documented governance: where the data came from, how representative it is, and what steps were taken to check for and address bias. For a credit-scoring model, this means being able to show the training data was not systematically skewed against a protected group.

Technical documentation

A detailed record of how the system works, what it was trained on, and how it was evaluated, similar in spirit to a regulatory filing. This has to exist and be maintained, not written retroactively if a regulator asks.

Record-keeping and logging for traceability

The system needs to log its operation in a way that lets a specific decision be traced and explained after the fact. For a hiring tool, this means being able to show, for a specific rejected candidate, what inputs and scoring led to that outcome.

Transparency to users

People affected by the system need to be told, in practical terms, that an AI system is involved and, where relevant, how it works. This overlaps with but is broader than the limited-risk transparency obligation described below.

Human oversight

A real person needs the ability to understand the system's output, override it, and intervene, not a symbolic "human in the loop" that rubber-stamps whatever the model produces. For an exam-scoring tool, this means a teacher can review and correct a flagged score, not just see a dashboard after the fact.

Accuracy, robustness, and cybersecurity

The system has to perform reliably within its stated parameters and be resistant to manipulation, including adversarial attempts to game its output.

Limited-risk systems: mostly a transparency question

Most chatbots and copilots fall into the limited-risk tier, not high-risk, unless they are doing something that lands them in Annex III, such as making a hiring decision. For a limited-risk system, the main obligation is straightforward: tell the person they are interacting with an AI system. A customer support chatbot has to disclose it is an AI, not present itself as a human agent. This is a much lighter obligation than the high-risk requirements above, and it is worth being precise about which tier a given system actually falls into rather than assuming the heavier obligations apply by default.

A concrete example
Picture a small HR technology company building an AI resume-screening tool for EU employers. Because recruiting tools sit in Annex III, this system is high-risk, and the team has real runway to the 2 December 2027 deadline, but should not wait. Practically, this means documenting where the training data for the scoring model came from and checking it for bias, building a logging system that can show why a specific candidate was ranked the way they were, and giving the hiring manager a real ability to see and override the ranking, not just a checkbox that says "reviewed." Compare this with a separate customer support chatbot the same company runs: that system is limited-risk, and its only real obligation is telling candidates plainly that they are talking to an AI assistant, not a person.

What GreyScript AI does, and does not, do here

GreyScript AI inventories what a system does and where a person stays in the loop, and designs toward the Act's requirements: documentation, logging, human oversight mechanisms, and the transparency disclosures a system needs at its actual risk tier. We do not declare a system EU AI Act compliant. That determination is a legal one, made by the reader's own counsel, not by an engineering team. See our AI governance and security service for how this fits into a build.

If your system also processes EU personal data, which most high-risk systems do, our GDPR explainer covers that separate, overlapping framework, including the Data Processing Agreement most AI vendors need to have in place. If the same product needs to work in the UK, see our UK GDPR explainer as well.