EU AI Act

What the EU AI Act is

The EU AI Act is the European Union’s regulation governing how AI systems may be built and used. Its obligations scale to the risk a system carries, so a low-risk use faces little and a high-risk one faces a great deal. That single idea, obligations that follow risk, is the one to hold on to.

This page explains the Act as this business meets it, in audits and in training. It is not legal advice. The site says of its own audits that they are a diagnostic and not a legal opinion, and no page here substitutes for a qualified lawyer.

Obligations scale with Risk

The site’s article on what an AI audit checks describes the Act’s own risk tiers as running from minimal risk through to the uses it treats as high-risk or bans outright. An audit maps each process in scope against that same scale and does not invent its own. The same logic sets the depth of the check. A process that only speeds up drafting, with a person reading the output before it goes anywhere, needs a light check. A process that talks to a customer directly, or feeds a decision about a person such as a hiring shortlist, needs a fuller one.

The classification that carries the heaviest obligations is the high-risk AI system. A system in that class needs a risk management process and documentation. The classification follows the system and what it does, and it does not follow the size of the organisation or the place it is hosted.

It applies by use case, not by company size

A common assumption is that the Act is written for large enterprises with compliance teams, and that a smaller organisation sits outside it. The site’s governance article says the Act does not draw its line there. It draws it at what the AI is used for. A small organisation using AI for a use case the Act treats as high-risk carries the same core obligations as a large one running the same use case.

Most day-to-day use sits outside the high-risk category altogether. Drafting, summarising and internal search are the article’s examples. But the only way to know which use case is which is to classify each one against the Act, and not to treat small size as an exemption. That is why the glossary page on agentic AI says that classifying each workflow comes before building it.

The dates, as the site reports them

The governance article reports a change to the timeline. Under the Digital Omnibus agreement, the compliance deadline for stand-alone high-risk systems under Annex III moved from 2 August 2026 to 2 December 2027. Product-embedded high-risk systems under Annex I were given a separate extension to August 2028.

The same agreement extended a simplified compliance route to qualifying small mid-cap companies, which the article defines as organisations with fewer than 750 employees and either 150 million euro or less in annual turnover or 129 million euro or less in total assets. The article’s reading is that the extension buys time and eases paperwork, and that it does not remove the requirement to classify a use case correctly and manage the risk it carries. Dates move, so a business should confirm the current position with its own adviser.

Vendor and Deployer

Two roles sit behind most AI use: the vendor that builds a system and the business that deploys it. The governance article says the heaviest obligations, a full risk management system run across a product’s lifecycle, representative training data and built-in logging, generally sit with the vendor developing a high-risk system and not with the small business deploying an existing one.

It then adds the part that matters. The vendor handling compliance is not a defensible answer, because a deployer still carries oversight duties of its own. A business that buys a tool has not bought its way out of responsibility for how the tool is used.

Where it attaches: to the System, not the host

The site’s reviews return to one point from several sides. Whether a business hosts a model itself, calls one through an API, runs a no-code platform, buys off the shelf or builds a custom workflow, the obligations follow the system and its risk. The review of a local model against Claude puts it plainly: a high-risk system still needs a risk management process and documentation whether it runs on a server down the corridor or behind an API.

What changes between options is who is directly accountable for the data path, and how easily a business can show its own answer. Self-hosting or a custom build can make it simpler to document what happens to data at each step. That supports evidencing compliance. It does not remove the obligation, and an off-the-shelf tool used carelessly is not automatically the safer choice either.

The HR example

The clearest case on the site is recruitment. The HR article reports that the Act classifies systems used for recruitment and candidate evaluation as high-risk, covering job-advert targeting, CV filtering and candidate scoring. It also covers systems that decide promotion, termination or task allocation, and performance monitoring, once someone is employed.

That classification puts a documentation and risk-management obligation on the system, whichever supplier or platform runs it. The same HR data is also personal data under GDPR, so the article argues that a curriculum treating the two as separate topics describes half the picture. The HR course takes the question to its end. Its closing discussion covers screening anonymised CVs against published criteria, what the research shows and where the regulation puts the responsibility. Its stated position is that filtering against published criteria is arguable, ranking people is not, and human oversight is the part that can be held responsible.

A link to what should never be delegated

The site’s article on automating a task against automating a decision sets out a ladder of four levels: assist, recommend, execute and never delegate. It observes that the categories the Act names as high-risk, employment decisions among them, map closely onto the never delegate rung.

The article treats that overlap as no coincidence. Both the law and the practical test answer the same question: which decisions carry enough consequence and need enough accountability that no amount of model accuracy changes the answer. A business that has sorted its workflows onto that ladder is most of the way to a defensible position on the regulatory question, because the same factors decide where a step sits.

Generative AI is inside it

The Act is written to cover generative AI as a category and not language models in particular. An image generator and a text assistant raise many of the same questions about accuracy, disclosure and oversight, even though only one of them is a language model. Reading “generative AI” in a regulation and narrowing it in your head to chatbots is a common and avoidable misreading.

Oversight matters more as tools take more steps. A chatbot gives one answer for a person to read before acting. An agent can act on a system with nobody reviewing each step, so oversight has to reach past chatbots to anything acting without a person in the loop. The hallucination page says this is where the Act sets its own obligations to scale with the risk a use case carries.

In an Audit

Every audit assesses the Act at the Identify step, inside the ranking of opportunities and not as a review added at the end. Each candidate is weighed on how often it repeats, what the manual version costs, whether the data exists in a usable state and what regulatory exposure attaches to it. The result includes a compliance checklist covering the EU AI Act and GDPR obligations the recommended opportunities carry.

The limits are stated on the audit page. An audit identifies and checks against those obligations. It does not certify them, and it is not a legal opinion. The audit methodology explains the five steps, and opportunity identification covers the step where the assessment sits.

In Training

The courses do not treat the Act as a module at the end. EU AI Act and GDPR content is built into every foundational programme, and the review of core courses against bespoke training says both formats carry it inside the session. The core courses carry their own governance and safe-use content as part of the day.

The HR article makes the same case for its own field: the Act belongs in the same session as the bias and data-protection material, and not in a separate legal briefing nobody attends. The bespoke training page sets out how the formats differ.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is assuming a small business is outside the Act because of its size, when the Act draws its line at the use. The second is assuming a hosting choice settles compliance, in either direction, when the obligations follow the system.

The third is treating a vendor’s assurance as the end of the matter. A deployer keeps oversight duties of its own. The fourth is treating a delay as a removal. The dates moved and the substance did not.

Where it goes wrong

One failure to avoid is classifying too late, when a tool has been built or bought first and someone asks afterwards what the Act says about it. The site’s answer is to classify each use case before building, and to check the Act and GDPR by what a use does and not by the size of the organisation running it.

Another is leaning on a vendor’s statement as proof. The review of Copilot Chat notes that Microsoft says it is committed to complying with the laws that apply to it, the EU AI Act among them, and lists ISO 42001 for AI management systems. That is Microsoft’s statement about itself. It tells a business what a vendor commits to and does not say whether the business’s own use is compliant.

Where it is taught and where it appears in an Audit

The Act runs through the foundational programmes and through the HR course, which takes recruitment AI as its hardest case. The rest sit in the wider training catalogue.

An audit meets the Act at the Identify step, and the governance article shows how the same five steps apply to governance as a whole. Knowing what the Act asks, and what an audit does and does not promise, is what lets a business decide where to build first and where to stop and take advice from a qualified lawyer.