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:
- Unacceptable risk. Banned outright. Practices the Act considers too harmful to permit regardless of safeguards.
- High-risk. Subject to the Act's most detailed obligations: risk management, data governance, documentation, logging, transparency, human oversight, and accuracy and robustness requirements, covered in detail below.
- Limited risk. Mainly transparency obligations, most commonly the requirement to disclose that a person is interacting with an AI system rather than a human.
- Minimal risk. Mostly unregulated. The large majority of everyday AI tools sit here.
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:
- 2 December 2027 for stand-alone high-risk AI systems under Annex III (recruiting tools, credit scoring, and the other Annex III categories). This replaces the original 2 August 2026 deadline.
- 2 August 2028 for high-risk AI systems embedded in regulated products under Annex I, such as medical devices, machinery, and vehicles, where the AI system is a safety component of a product already regulated under separate EU product-safety law.
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.
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.