AI Act compliance: what applies to you, and what it requires
Most organisations approach the AI Act by asking what they have to do. That is the second question. The first is what they are — because the obligations are assigned by role, and the same piece of software generates completely different duties depending on whether you built it, bought it, or trained the model underneath it.
Get that wrong and everything downstream is wrong with it. Organisations write technical documentation they do not owe, and skip fundamental rights assessments they do. Worse, some discover late that an activity they thought made them a customer has made them a provider, with the full weight of Chapter III attached.
This article works through the classification first, then what each role owes, then the dates. It covers Regulation (EU) 2024/1689 as it applies in 2026 — including what is still unpublished, because pretending otherwise helps nobody.
Short on time? The AI Act Compliance Suite contains the classification procedure that answers this question formally, plus everything downstream from it — risk management, data governance, human oversight, technical documentation and conformity assessment. 42 documents, €590 excl. VAT.
The first question: what are you?
The Regulation recognises several roles. Three matter to most organisations.
A provider develops an AI system or a general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark. Building it yourself is the obvious case; commissioning it and branding it is the one people miss.
A deployer uses an AI system under its own authority, in the course of a professional activity. If you bought a CV-screening tool and run it on your own candidates, you are a deployer.
A provider of a general-purpose AI model sits apart, with its own chapter of obligations. A GPAI model displays significant generality, performs a wide range of distinct tasks competently, and can be integrated into many downstream systems.
Importers, distributors and authorised representatives have their own duties too, but they are narrower and better defined.
The trap in Article 25
This is the provision that catches organisations by surprise, and it is worth reading carefully even if you are certain you are only a deployer.
Under Article 25(1), a deployer, distributor or importer becomes a provider — assuming all provider obligations for the system — in three situations: if it puts its own name or trademark on a high-risk system already on the market, if it makes a substantial modification to such a system, or if it modifies the intended purpose of a system in a way that makes it high-risk.
The third one is the quiet one. Take a general-purpose tool that is not high-risk as sold, and use it for something in Annex III — candidate ranking, creditworthiness, allocation of essential services — and you may have converted yourself into the provider of a high-risk system, with the technical documentation, conformity assessment and registration duties that come with it.
Nothing about that conversion requires you to write a line of code. It requires you to change what the system is for.
The four risk tiers
Most systems sit in the bottom two tiers. The transparency duties in Article 50 apply regardless of tier.
The Regulation sorts AI systems into four levels, and the level determines almost everything else.
Prohibited practices are listed in Article 5 and may not be placed on the market, put into service or used at all. They include social scoring by public authorities, exploitation of vulnerabilities, untargeted scraping of facial images to build recognition databases, and emotion inference in the workplace and in education, among others.
A finding here stops a project rather than reshaping it. Screen every use case against Article 5 before any development budget is committed, because discovering a prohibition after eighteen months of work is not a compliance problem, it is a write-off.
High-risk systems carry the bulk of the Regulation’s requirements. A system is high-risk either because it is a safety component of a product covered by the Union harmonisation legislation in Annex I and requires third-party conformity assessment, or because its intended purpose falls within Annex III — which covers biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential services, law enforcement, migration and border control, and administration of justice.
There is an exception worth knowing. Under Article 6(3), an Annex III system is not high-risk where it does not pose a significant risk of harm — because it performs a narrow procedural task, improves the result of a previously completed human activity, detects decision-making patterns without replacing human assessment, or performs a preparatory task. The exception never applies where the system performs profiling of natural persons. And if you rely on it, you have to document the assessment and register the system anyway.
Limited risk covers systems subject to the transparency obligations of Article 50 — chatbots that must disclose they are machines, synthetic content that must be marked, deep fakes that must be labelled, emotion recognition and biometric categorisation that must be disclosed to the people subject to them.
Minimal risk is everything else, which in practice is most AI in commercial use. No specific obligations under the Regulation, though Article 4 on AI literacy still applies.
Two things people get wrong here. Article 50 transparency obligations apply according to what the system does, not to which tier it sits in — a minimal-risk chatbot still has to say it is a chatbot. And the classification follows the intended purpose as you state it in the instructions for use and the marketing material, not the use you happen to observe.
If you are a provider of a high-risk system
This is the heaviest path in the Regulation, and it runs from design to post-market.
You need a risk management system under Article 9, running across the whole lifecycle rather than as a one-off assessment, and it has to judge two distinct things: each individual residual risk, and the overall residual risk of the system. Both must be acceptable, and the second is not simply the sum of the first.
Data governance under Article 10 governs the training, validation and testing data: design choices, provenance, preparation, assumptions, availability, and — the part that is genuinely hard — examination for bias and mitigation of what you find. Representativeness has to be stated against a named population, not asserted in the abstract.
Technical documentation under Article 11 follows Annex IV point by point, drawn up before the system goes on the market and kept up to date afterwards. Keep the Annex IV numbering in your file: it is read against the Annex, and a reviewer who has to hunt for the correspondence is a reviewer who finds other problems.
Record-keeping under Article 12 means the system logs events automatically over its lifetime, and Article 19 requires providers to retain those logs for at least six months where they are under their control.
Transparency and instructions for use under Article 13, human oversight under Article 14, and accuracy, robustness and cybersecurity under Article 15 complete the requirements. Article 14 deserves particular attention: oversight that cannot in practice depart from the system’s output is not oversight, and automation bias — the tendency to over-rely on a machine that is usually right — is named explicitly in the text.
Then the conformity route. Article 43 offers assessment based on internal control under Annex VI, or assessment involving a notified body under Annex VII, depending on the system. Either way it ends with the EU declaration of conformity under Article 47, the CE marking under Article 48, and registration in the EU database under Article 49 — which applies even to Annex III systems you have assessed as not high-risk under the Article 6(3) exception.
One practical warning about performance figures. The accuracy and robustness levels you declare appear in three places: the test report, the Annex IV documentation and the instructions for use. Three different numbers for the same metric is the single most common finding in this area, and it happens because the three documents are written at different times by different people.
The presumption of conformity, and why it is not available yet
Applying harmonised standards whose references are published in the Official Journal gives you a presumption of conformity with the requirements they cover. Those standards are still being developed by CEN-CENELEC.
Until they are published, that presumption is not available and every requirement is documented on its own terms. This is not a reason to wait — the requirements apply regardless — but it does mean an internal-control conformity assessment today rests on your own reasoning rather than on a standard, and the reasoning has to be written down.
The classification decides which documents are yours. The AI Act Compliance Suite opens with that determination, and three of its procedures are conditional by design — if the classification says they do not apply to you, you close them and move on. 42 documents, €590 excl. VAT.
If you are a deployer
Deployer obligations are lighter but not light, and they are the ones most organisations actually have.
Article 26 requires you to use the system in accordance with the instructions for use, assign human oversight to people with the competence, training and authority to exercise it, and ensure that input data is relevant and sufficiently representative for the intended purpose. You keep the automatically generated logs for at least six months where they are under your control, and you monitor operation — informing the provider and the authority where you identify a risk or a serious incident.
Where you use a high-risk system in the workplace, you inform workers and their representatives before putting it into use. Where the system makes or assists decisions about natural persons, Article 26(11) requires you to inform those people.
Article 27 requires certain deployers — bodies governed by public law, private entities providing public services, and deployers of certain Annex III systems in creditworthiness and insurance — to carry out a fundamental rights impact assessment before first use. The AI Office is due to publish a template for the notification; check its status before assuming the format.
Article 86 gives a person subject to a decision taken on the basis of an Annex III high-risk system’s output the right to obtain an explanation of the role that system played in the decision-making procedure. That is an obligation to be able to explain, which is easier to satisfy if you thought about it at deployment than if you first consider it when someone asks.
And Article 4 requires providers and deployers to take measures ensuring a sufficient level of AI literacy among their staff and anyone operating systems on their behalf. That obligation has applied since 2 February 2025, it is not limited to high-risk systems, and it covers contractors.
If you provide a general-purpose AI model
GPAI providers have their own chapter. Article 53 requires technical documentation of the model following Annex XI, information for downstream providers following Annex XII, a policy for complying with Union copyright law, and a sufficiently detailed public summary of the content used for training.
Article 55 adds a second layer for models with systemic risk — presumed where the cumulative compute used for training exceeds 10²⁵ floating point operations, or where the Commission designates it. Those providers must evaluate the model including adversarial testing, assess and mitigate systemic risks, track and report serious incidents to the AI Office, and ensure adequate cybersecurity for the model and its physical infrastructure. Notification to the Commission is required when the threshold is met.
The dates
The Regulation applies in stages. Two obligations are already in force.
The Regulation entered into force in August 2024 and applies in stages.
Since 2 February 2025, the prohibitions in Article 5 have applied, along with the AI literacy obligation in Article 4. Both are already enforceable, and the literacy one is the more commonly overlooked of the two.
Since 2 August 2025, the GPAI model obligations, the governance provisions and the penalty regime have applied.
Since 2 August 2026, the Article 50 transparency duties have applied. These were never deferred, and the date has passed.
From 2 December 2027, the Annex III high-risk obligations apply. From 2 August 2028, the obligations for high-risk systems that are safety components of products under the Annex I legislation apply.
Those last two dates changed in July 2026. Regulation (EU) 2026/1744, the Digital Omnibus on AI, deferred the high-risk deadlines from their original 2 August 2026 and 2 August 2027 — see what actually moved and what did not, because the deferral is narrower than the headlines suggest and the transparency duties are already live.
Penalties are substantial: up to 35 million euro or 7 per cent of worldwide annual turnover for prohibited practices, up to 15 million or 3 per cent for most other infringements, and up to 7.5 million or 1 per cent for supplying incorrect information to authorities.
Two instruments are still awaited and both affect documentation: the implementing act on the post-market monitoring plan under Article 72(3), and the AI Office template for the fundamental rights impact assessment notification under Article 27(3). Check their status before finalising either document.
Four things to do this week
Before anything else, check your compliance calendar against the timeline as amended by the Digital Omnibus. Two of the dates most programmes are built on changed in July 2026.
If your organisation has not started, these four are the highest return for the least effort, and none requires the programme to exist first.
Inventory the AI systems you actually use, including the ones bought by a department with a credit card. The systems that surface late are the ones nobody assessed, and the inventory is the artefact everything else depends on.
Screen every use case against the Article 5 prohibitions. It takes an afternoon, and a finding here stops a project rather than reshaping it — which is far cheaper before the budget is committed than after.
Check whether anything you do triggers Article 25. If you have rebranded a system, modified one substantially, or repurposed one towards an Annex III use, you may be a provider without having planned to be.
Start AI literacy training. It has applied since February 2025, it covers contractors as well as employees, and it is the obligation most likely to be missed by organisations that consider themselves low-risk.
Frequently asked questions
Does the AI Act apply to us if we only use AI tools we bought? Yes, as a deployer. Article 26 obligations apply, and Article 4 on AI literacy applies regardless of what you deploy. Whether more applies depends on whether the systems are high-risk and whether anything you do triggers Article 25.
We are outside the EU. Does it still apply? It can. The Regulation reaches providers placing systems on the Union market wherever they are established, and deployers established in the Union — and in some cases providers and deployers outside the Union where the output is used inside it. Non-Union providers of high-risk systems must appoint an authorised representative in the Union.
Is ISO/IEC 42001 enough for AI Act compliance? No. It is a management system standard and a good way to organise and evidence the work, but conformity assessment, the EU declaration of conformity, CE marking, registration, the serious incident duties of Article 73 and the GPAI obligations have no ISO equivalent. The AI Act is framework-neutral.
How do we know whether our system is high-risk? Through the Annex I and Annex III test, then the Article 6(3) exception if it might apply. Document the assessment either way — and note that if you rely on the exception for an Annex III system, you still have to register it.
What if our system is not high-risk at all? Then most of Chapter III does not apply. Check Article 50 anyway, because the transparency obligations attach to what the system does rather than to its risk tier, and check Article 4, which applies to everyone.
Where to go next
ISO/IEC 42001 is the management system standard organisations most often use to structure this work: see how an ISO 42001 audit is run and where your AI management system stands today.
The classification determines everything downstream, and it is worth doing formally rather than by intuition.
The AI Act Compliance Suite opens with exactly that: a classification procedure covering role, prohibited-practice screening, risk tier, Article 50 duties and GPAI status. What it concludes tells you which of the other documents are yours — a deployer never touches the Annex IV file or the declaration of conformity, and three of the procedures are conditional by design.
42 documents in total, mapped article by article, cross-referenced to ISO/IEC 42001, €590 excl. VAT. The full contents list shows every document and the article it implements, before you buy. Once you know your role, which conformity assessment route applies covers Article 43 in detail — internal control, the conditional biometric route, and what happens when your AI sits inside an already-regulated product.
Sources
Regulation (EU) 2024/1689 is available on EUR-Lex. The European Commission maintains guidance on the definition of an AI system, on prohibited practices and on transparency obligations; check the current status before relying on any draft.