EU AI Act Compliance: What Businesses Actually Need to Do

The EU AI Act is not primarily a technical standard — it is a risk-classification legal framework that assigns obligations based on what an AI system does, to whom, and in what role you stand relative to it. Compliance means answering three questions in order: which risk tier does this system occupy, am I a provider or a deployer, and what date does the relevant obligation bite.

That last question changed materially in 2026, and a great deal of published guidance is now out of date.

The current timeline

The Act entered into force on 1 August 2024, and its obligations were always staged. That staging was amended by the Digital Omnibus on AI — Regulation (EU) 2026/1744 of 8 July 2026, published in the Official Journal on 24 July 2026 and in force since 27 July 2026. It entered into force on the third day after publication rather than the usual twentieth, expressly to settle the position before the Act’s general application on 2 August 2026.

The deferral is in Article 113(3)(c) of the Act as amended, which now sets Chapter III Sections 1–3 to apply from 2 December 2027 for systems high-risk under Article 6(2) and Annex III, and from 2 August 2028 for those high-risk under Article 6(1).

The part organisations get wrong: Article 50 was not deferred. If your product talks to people, generates synthetic media, or performs emotion recognition, 2 August 2026 is still your date. The deferral buys engineering time on the heaviest obligations. It does not buy time on the ones that apply to ordinary commercial chatbots.

There is one transitional worth knowing about, because it is easy to read the 2 August 2026 date as absolute. Article 111 gains a new paragraph 4, giving providers of systems that generate synthetic audio, image, video or text and that were already on the market before 2 August 2026 until 2 December 2026 to comply with the Article 50(2) marking duty. New systems get no such grace.

Verified against the Official Journal text on 29 July 2026. Note for anyone re-checking these dates: the consolidated AI Act text on EUR-Lex lags OJ publication, sometimes by months. Its absence is not evidence that an amendment has not been made — search for the amending regulation directly.

The risk classification logic

01 / Unacceptable risk — prohibited

Banned since 2 February 2025. The list includes social scoring by public authorities, untargeted scraping of facial images to build recognition databases, emotion inference in workplaces and educational settings, biometric categorisation to infer protected characteristics, predictive policing based solely on profiling, exploitation of vulnerabilities, subliminal manipulation causing harm, and real-time remote biometric identification in public spaces for law enforcement (with narrow, authorised exceptions).

If you are building in this category, there is no compliance path. Stop.

Note the two that catch commercial organisations off guard: emotion recognition in the workplace and biometric categorisation. Sentiment analysis applied to employee communications is closer to this line than most HR technology buyers realise.

02 / High risk — the compliance core

Two routes into this tier. Annex I: the AI system is a safety component of a product already regulated under EU harmonisation legislation — medical devices, machinery, lifts, toys, vehicles. Annex III: the system falls within a listed use case:

• Biometrics (identification, categorisation, emotion recognition where not prohibited)
• Critical infrastructure management and operation
• Education and vocational training — admission, evaluation, proctoring
• Employment and worker management — recruitment, screening, promotion, termination, task allocation
• Access to essential private and public services — credit scoring, health and life insurance pricing, emergency triage, benefits eligibility
• Law enforcement
• Migration, asylum and border control
• Administration of justice and democratic processes

Most consequential business AI lands in employment, credit, or essential services.

What a provider must have in place:

• A risk management system running across the full lifecycle, not a one-off assessment
• Data governance covering training, validation and testing sets — relevance, representativeness, error examination, bias examination
• Technical documentation sufficient for an authority to assess conformity
• Automatic logging of events across the system’s lifetime
• Instructions for use that let a deployer actually comply with its own obligations
• Human oversight designed into the system architecture
• Appropriate accuracy, robustness and cybersecurity, with declared metrics
• A quality management system
• Conformity assessment, EU declaration of conformity, CE marking
• Registration in the EU database before placing on the market

What a deployer must do — lighter, but not nothing:

• Use the system in accordance with the instructions for use
• Assign human oversight to people with the competence, training and authority to exercise it
• Ensure input data is relevant and sufficiently representative for the intended purpose
• Monitor operation and suspend use plus inform the provider where a risk emerges
• Retain automatically generated logs for at least six months
• Inform workers’ representatives before putting a high-risk system into use in the workplace
• Where the deployer is a public body or provides essential services, complete a fundamental rights impact assessment
• Inform individuals subject to decisions made by a high-risk system

03 / General-purpose AI models

The tier most commentary published before 2025 omits entirely. GPAI obligations have applied since 2 August 2025. Every GPAI provider must maintain technical documentation, provide information to downstream providers integrating the model, put in place a policy to comply with EU copyright law, and publish a sufficiently detailed public summary of training content using the Commission’s template.

Models presenting systemic risk — assessed on capability, with a compute threshold as one indicator — carry additional duties: model evaluation including adversarial testing, systemic risk assessment and mitigation, serious incident tracking and reporting to the AI Office, and cybersecurity protection.

The General-Purpose AI Code of Practice offers a voluntary route to demonstrating compliance. Signing it is not mandatory; declining it means demonstrating adequacy some other way.

04 / Limited risk — transparency

Applying from 2 August 2026 under Article 50: systems interacting with people must disclose that fact unless it is obvious; synthetic audio, image, video and text must be marked in a machine-readable format; deep fakes must be disclosed; emotion recognition and biometric categorisation systems must inform the people exposed to them.

05 / Minimal risk

No specific obligations. Spam filters, AI in games, inventory optimisation. General product liability, consumer protection and data protection law still apply — the AI Act is additive, not a replacement.

Where the standards actually come from

The Act sets out requirements in legal language. The operational detail is being written by CEN-CENELEC JTC 21, whose harmonised standards will carry a presumption of conformity: implement the standard, and you are presumed to meet the corresponding requirement.

The first of these are expected to publish during 2026, with prEN 18286 (AI quality management system for AI Act regulatory purposes) among the furthest advanced. The practical consequence for planning is uncomfortable but important: for part of the compliance window, the requirements exist without the standards that operationalise them. Organisations building high-risk systems now are building against a moving target, which is a strong argument for grounding your control set in something stable — ISO/IEC 42001 or NIST AI RMF — and mapping forward as the harmonised standards land.

The extraterritorial reality

Article 2 reaches beyond the EU’s borders in three ways. It applies to providers placing systems on the EU market irrespective of establishment; to deployers established in the EU; and — the broad one — to providers and deployers located anywhere where the output produced by the system is used in the Union.

A US company whose CV-screening model ranks applicants for a Dublin office is in scope. So is a UK insurer pricing policies for customers in Spain. Headquarters location is not the test; where the output lands is.

Enforcement became operational on 2 August 2026

Added 3 August 2026.

The Commission confirmed on 31 July 2026 that its AI Act enforcement framework would operate from 2 August. Three routes now exist:

• Complaints from any natural or legal person.
• Anonymous reporting by eligible insiders under whistleblower protection.
• Downstream escalation, allowing providers who build on a general-purpose AI model to raise alleged breaches by the GPAI provider concerning Articles 53 to 55.

A complaint is not a finding. It opens an assessment, and competence depends on the system, the organisation and the provision involved — not every complaint belongs to the AI Office.

What changes practically is the audience for your evidence. Weak supplier governance and thin internal records were previously a private problem. They can now become the subject of an external complaint made by someone you do not control — a customer, a competitor’s downstream integrator, or your own staff.

What a deployer should retain: requests made to suppliers, the responses received, gaps identified, the operational impact of those gaps, the internal decisions taken about them, and the incident record. An unanswered request to a supplier is evidence, but only if you kept it.

AI literacy, as amended

Added 3 August 2026.

Article 4 was replaced by Article 1(5) of the Digital Omnibus. The obligation did not disappear; the wording softened and became explicitly contextual. Providers and deployers must now “take measures to support the development of AI literacy” of staff and of others operating or using AI systems on their behalf, taking account of technical knowledge, experience, training, the context of use, and the people the systems are used on.

Commission guidance published alongside it is unusually clear about what is not required under Article 4 alone:

• No certificates.
• No employee testing.
• No dedicated AI officer.

That is a lower bar than most vendors selling AI training will tell you. It is also not nothing. The guidance supports keeping internal evidence of what was provided and to whom, and the measures must be proportionate to role, authority and risk.

The trap is generic vendor training disconnected from actual authority. If a named individual holds the power to override or suspend a system, their competence has to match that power specifically — not a general awareness course everyone in the organisation sat through.

One caution for anyone citing this. The Commission’s own AI-literacy page carries conflicting references to 2 and 3 August 2026 for the enforcement date. That inconsistency is on the official page and has not been resolved. Do not silently pick one.

Supplier agreements: what Article 25 now requires

Added 3 August 2026.

Article 1(12) of the Digital Omnibus amended Article 25, and the change matters to anyone integrating third-party components into a high-risk system.

The new word is “AI model.” Article 25(4) previously bound the provider of a high-risk system and third parties supplying “an AI system, tools, services, components, or processes.” It now reads “an AI system, AI model, tools, services, components, or processes.” Model suppliers are explicitly inside the written-agreement duty.

The duty itself is to specify, by written agreement, the “necessary information, capabilities, technical access and other assistance” needed for the high-risk provider to meet its obligations. Four elements, not two — a contract that promises documentation and support but no technical access does not satisfy it.

Article 25(2) was also replaced, and now itemises what an initial provider must hand over when responsibility transfers:

• Technical documentation sufficient to assess compliance with Article 16.
• Information about known limitations and failure modes.
• Targeted technical access, including for testing and validation.

Two limits worth stating precisely, because both are misread:

• The free and open-source carve-out is not new. It was in the 2024 Act and has been retained. It removes the Article 25(4) duty from third parties publishing tools, services, processes or components — other than general-purpose AI models — under a free and open-source licence. It is not a general exemption for deployers who use open-source software.
• These obligations are not immediately enforceable. Chapter III Sections 1–3 apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I products. Entry into force on 27 July 2026 did not switch supplier agreements on. Use the interval to renegotiate contracts, not to assume the duty has already bitten.

The voluntary transparency code

Added 3 August 2026.

The Commission published the first signatory list for the Code of Practice on Transparency of AI-generated Content on 31 July 2026: approximately 190 organisations, with 83 signing the provider section and 152 the deployer section.

Those two figures overlap and must not be added together. Nor does the list establish much on its own:

• Signing a voluntary code is not certification, not an audit, and not Commission approval of the signatory.
• It does not replace Article 50, which is the binding obligation.
• A non-signatory can comply perfectly well by another route, provided its measures meet the legal duty.

For a deployer the useful reading is inverted. A public commitment raises, rather than settles, the evidential question: if your supplier has signed, you now have something specific to hold them to, and if you have signed, you need to show the promised controls actually operate in each covered workflow — including that marks survive your distribution chain.

What this means operationally

Strip out the legal architecture and the Act asks a deployer for five things: know which of your systems are in scope and why; have a named human with real authority overseeing each one; be able to show your working through documentation and logs; tell people when AI is involved in decisions about them; and have a route to suspend a system when it misbehaves.

Those are the same capabilities the AI Human Proof standard specifies, and the same ones NIST AI RMF arrives at from a different direction. An organisation that has built them is substantially ready for the Act regardless of which deadline ultimately governs.