TL;DR. The EU AI Act is a tiered risk regime, not a blanket regulation. Four risk tiers - prohibited, high-risk, limited-risk, minimal-risk. Three enforcement dates, 2 February 2025, 2 August 2026, 2 August 2027 - each triggering different obligations. Most mid-market firms are deployers, not providers, and operate in only two of the four tiers. Most of the work in 2026 is to find which AI systems you actually have, classify each one through a structured AI risk classification process, and document the high-risk ones, in that order.
The EU AI Act comes down to four things for most mid-market firms: knowing which of your AI systems are high-risk, documenting them correctly, assigning human oversight, and being ready before August 2026.
The EU AI Act has 113 Articles and 13 Annexes. You probably need to read about thirty of them. Most of those describe what counts as a high-risk AI system, what you have to document about each one, and what happens if you cannot find the system in your environment when the regulator asks.
This piece is for the DPO whose CEO has forwarded them an article with the subject line "Are we ready for this?" It assumes you have read parts of the Act, you have seen the Article numbers, and you are tired of pieces that tell you the EU AI Act is the world's first comprehensive AI regulation for the tenth time and tell you nothing actionable. If you are still working out the broader picture of how the Act sits alongside GDPR, DORA, and NIS2, start with What is AI governance and come back here.
The structure below is the version I wish someone had sent me when I started reading the Act for clients. Four tiers. The deployer-versus-provider distinction. Three dates. Eight Annex III categories. The deployer obligations. The Article 50 transparency obligations. The fine bands. The supervisor architecture. A practical reading list. Done.
The Four Risk Tiers
The Act sorts AI systems into four risk tiers. Different obligations attach to each. The first job for any team starting from cold is to know which tier each of your AI systems falls into.
Prohibited (Article 5)
These are AI practices the Act simply bans, regardless of how careful the deployer is. Article 5 lists the categories: AI systems that deploy subliminal techniques or exploit vulnerabilities of specific groups in ways that materially distort behaviour and cause significant harm; social scoring by public or private actors that produces detrimental treatment in unrelated contexts; real-time remote biometric identification in publicly accessible spaces by law enforcement, with narrow carve-outs; untargeted scraping of facial images from the internet or CCTV to build facial recognition databases; emotion recognition systems in workplaces and educational institutions, with limited exceptions; biometric categorisation that infers race, political opinions, trade union membership, religious beliefs, sexual orientation, or sex life; and predictive policing based solely on profiling.
For most mid-market firms, the prohibited tier is straightforward to clear. Either you do one of these things or you do not, and most do not. The trap is in the workplace emotion-recognition prohibition, some of the recruiting and customer-support AI tools on the market include sentiment or emotion analysis that, depending on configuration, can fall on the prohibited side of the line. This is worth checking specifically on every HR and customer support AI tool in your inventory.
High-risk (Article 6 plus Annex III)
The substantive bulk of the Act lives here. Two paths take an AI system into the high-risk tier.
Article 6(1) - the safety component test. If the AI is a safety component of, or is itself, a product covered by certain Union harmonisation legislation listed in Annex I, medical devices, in-vitro diagnostic medical devices, machinery, toys, lifts, radio equipment, and so on, and that product requires a third-party conformity assessment, the AI is high-risk.
Article 6(2) - the use-case test. If the AI is intended to be used in any of the use cases enumerated in Annex III, the AI is high-risk. We will walk through Annex III below.
The high-risk tier is where most regulated organisations have material exposure. The August 2026 enforcement date applies primarily to this tier, and EU AI Act compliance for most mid-market firms is almost entirely a high-risk tier problem.
Limited-risk Transparency (Article 50)
This tier exists for AI systems that interact with people or generate content in ways where the user might not realise AI is involved. It includes chatbots and other AI systems intended to interact directly with natural persons; emotion recognition systems and biometric categorisation systems where not prohibited; AI systems generating or manipulating image, audio, or video content that resembles existing persons, places, or events (deepfakes); and AI systems generating text published to inform the public on matters of public interest.
The obligation here is informational. The user must be told they are interacting with AI; deepfake content must be labelled as such; AI-generated text on matters of public interest must be flagged. The substantive obligations are lighter than high-risk but they apply to a much wider set of tools than most teams realise, every customer chatbot, every AI-generated article, every synthetic voice agent.
Minimal-risk (No Specific Obligations)
Everything else. Spam filters, recommendation engines for non-essential services, AI in productivity tools that does not fall into any of the above categories. There are no specific Act obligations for minimal-risk AI, though general obligations under GDPR and other regulations still apply.
The distribution of a typical mid-market firm's AI footprint, in our audits: 0% prohibited, 5–15% high-risk (concentrated in HR, finance, and where applicable healthcare or financial-services use cases), 25–40% limited-risk transparency (chatbots, AI-generated content, deepfake-adjacent generation tools), the remainder minimal-risk.
The piece below focuses on high-risk and Article 50 limited-risk, because that is where the documentary work concentrates.
Are You a Deployer or a Provider?
The Act draws a sharp line between two roles, and your obligations depend on which side of the line you sit.
A provider develops an AI system or has an AI system developed and places it on the market or puts it into service under their own name. Most providers are AI vendors - OpenAI, Anthropic, Google, the smaller specialised AI vendors. For a high-risk AI system, the provider carries the heaviest set of obligations: conformity assessment, technical documentation, risk management system, post-market monitoring, registration in the EU database.
A deployer uses an AI system under their authority. Most mid-market firms are deployers. You buy Phenom; Phenom is the provider, you are the deployer. You use ChatGPT for a workflow; OpenAI is the provider, you are the deployer.
Three things change the deployer/provider line. Substantial modification: if you take a provider's high-risk AI system and substantially modify it, you become a provider, heavy fine-tuning, system integration that materially changes the intended purpose, putting your own logo on a third-party AI in a way that obscures the original provider. Putting an AI system on the market under your own name: if you white-label a third-party AI and offer it to your customers as your product, you are the provider. Bringing an AI system into service for your own use: if you build an AI system in-house, even just for internal use, you are the provider for it.
Most mid-market firms are pure deployers for the bulk of their AI footprint, with one or two provider exposures from internal AI projects. The deployer obligations are different from the provider obligations and they are the starting point for any credible EU AI Act compliance programme for the rest of this piece.
What Montro Finds When the Deployer/Provider Line is Drawn |
When Montro works through the deployer/provider determination with a new client, the conversation almost always leads to one surprise. The client arrives expecting to be a pure deployer; they buy AI tools. They do not develop them. But then the inventory is reviewed. Somewhere in the engineering team, someone has built an internal AI tool, a workflow automation that scores incoming support tickets, a content generation tool used by the marketing team to draft outreach, or a performance assessment model used by HR to conduct quarterly reviews. None of them were procured. All of them were built and deployed internally under the firm's own authority. Under the Act, the firm is a provider for every one of them. Not a deployer using someone else's system, but the provider, with the full set of provider obligations: risk management system, technical documentation, conformity assessment, post-market monitoring, and registration. The compliance team did not know the tools existed. The legal team did not know the firm was a provider. The engineering team did not know any of this was relevant to them. |
The Three Enforcement Dates
The single biggest planning error we see is treating the Act as a single August 2026 deadline. It is not. Three dates trigger different obligations.
2 February 2025 - Already in Force
Two sets of obligations have been operationally binding for over a year:
Article 5 prohibited practices. From 2 February 2025, deploying any of the practices listed in Article 5 is a regulatory offence in itself. The European Commission published Guidelines on prohibited AI practices on 4 February 2025.
Article 4 AI literacy. Providers and deployers must ensure their staff and other persons dealing with AI systems on their behalf have a sufficient level of AI literacy, taking into account technical knowledge, experience, education, and the context in which the AI systems will be used.
Article 4 is the most overlooked obligation in the Act. It is not a documentation obligation. It is a competence obligation. Most firms have done nothing on it because there is no checkbox to tick, but the supervisor will reasonably expect, when they next inspect, that a firm operating AI can demonstrate that the people running it know what they are doing. A short structured AI literacy programme - induction module, role-specific training for high-risk AI users, refresh cadence, is sufficient evidence in most cases.
2 August 2026 - The Main Deadline
This is the date most firms are working to. From 2 August 2026, most provisions of the Act apply, including most Chapter III high-risk system obligations. Provider obligations for high-risk AI systems fully enforce. Deployer obligations for high-risk AI systems fully enforce. General-purpose AI model obligations enforce. Article 50 transparency obligations enforce. The penalty regime in Articles 99–101 enforces.
If you have a high-risk AI system in operation on 2 August 2026, you need the deployer obligations satisfied as of that date. If you bring a high-risk system into service after that date, you need the obligations satisfied at deployment.
2 August 2027 - The Catch-Up Date
Existing high-risk AI systems already in operation before 2 August 2026 - that is, AI systems placed on the market or put into service before that date, get an additional year. From 2 August 2027, every high-risk AI system already in operation must be brought into compliance with the Act's provisions.
This date matters for firms with long-deployed AI tools. The HR system that has been running CV screening since 2022 does not enforce on 2 August 2026; it enforces on 2 August 2027. But the firm needs to know which of those existing systems are high-risk to know which date applies. Discovery and classification have to happen anyway, and they have to happen before 2 August 2026.
Annex III, Walked Through
Annex III defines the high-risk use cases under Article 6(2). There are eight categories. For each, an example of the kind of mid-market AI tool that lands in it.
1. Biometrics. Biometric identification, biometric categorisation, emotion recognition. Example: an office building access system that uses facial recognition for entry; a customer service tool that infers caller emotion to route complaints.
2. Critical infrastructure. AI used as safety components in the management and operation of critical digital infrastructure, road traffic, water, gas, heating, electricity. Example: AI in operational technology for utilities or transport. Mid-market exposure here is low except for firms in the infrastructure sector itself.
3. Education and vocational training. AI determining access to education, evaluating learning outcomes, assessing the level of education an individual will receive, monitoring during tests. Example: an EdTech firm using AI to assess student performance; a vocational training provider using AI for admissions.
4. Employment, workers' management and access to self-employment. AI used for recruitment, particularly placing targeted job advertisements, screening or filtering applications, evaluating candidates; AI used to make decisions affecting terms of work, promotion, termination, task allocation, performance evaluation. Example: Phenom, Eightfold, HireVue, Paradox, and most modern recruiting platforms with AI features. Also: AI-driven performance management, AI-assisted scheduling that affects worker compensation.
5. Access to and enjoyment of essential private and public services. AI used by public authorities to evaluate eligibility for benefits; AI used by financial institutions to evaluate creditworthiness or establish credit scores (with carve-outs for fraud detection); AI used for risk assessment and pricing in life and health insurance; AI used to dispatch emergency response. Example: a fintech doing credit scoring; an insurance firm using AI for underwriting; a health insurer using AI for risk pricing.
6. Law enforcement. Specific to law enforcement use cases. Mid-market exposure rare except for tech vendors selling into law enforcement.
7. Migration, asylum and border control management. Specific to migration use cases. Mid-market exposure rare.
8. Administration of justice and democratic processes. AI used by judicial authorities or alternative dispute resolution bodies in researching and interpreting facts and applying the law; AI used to influence the outcome of an election. Mid-market exposure rare.
For most European mid-market firms, the categories that produce real exposure are 4 (employment), 5 (essential services, especially for financial services and insurance), and 1 (biometrics, where the firm has access control or customer-facing biometric systems). The other five categories matter for specific sectors but rarely for general mid-market deployment. Technology scale-ups typically sit in category 4 from their HR tooling and category 5 if they offer essential services to consumers; outside those, exposure is limited.
The mapping work - taking your inventory of AI systems and assigning each to either "out of scope," "Annex III category X," or "Article 6(1) safety component", is the central AI risk classification task.
What "Compliance" Actually Requires for a Deployer
Once you have a high-risk AI system identified, the deployer obligations under Chapter III apply. These are operational, not just documentary.
Use the system in accordance with the provider's instructions for use. The provider is required to publish detailed instructions; the deployer is required to follow them. This sounds trivial. It is not. Many firms deploy AI tools in workflows the provider's documentation does not specifically anticipate, and assess later whether the deployment was within or outside the documented intended purpose.
Assign human oversight. A specific natural person must be responsible for monitoring the AI system's operation, with the competence and authority to act on what oversight surfaces. This is more than a name on a form; it is an operational role.
Ensure relevant input data. Where the deployer controls the input data, the data must be relevant and sufficiently representative for the intended purpose. For HR AI, this means the candidate data, the job descriptions, the historical hiring decisions used for any training or calibration must be assessed.
Monitor operation and report serious incidents. Deployers must keep records of operation, monitor for unexpected behaviour, and report serious incidents to the provider and to the relevant national authority.
Inform affected workers. Where the deployer is using a high-risk AI system in the workplace, workers and their representatives must be informed before the system is put into use.
Conduct a fundamental rights impact assessment. Specific deployer categories, particularly bodies governed by public law and operators of essential services, must conduct a fundamental rights impact assessment under Article 27.
Cooperate with the provider's conformity assessment. Where the provider is conducting post-market monitoring, the deployer cooperates by sharing operational data and incident information.
Register in the EU database. Some deployer categories, primarily public authorities, must register their use of high-risk AI in the EU database under Article 49.
Maintain logs. Deployers must keep logs automatically generated by the AI system to the extent the deployer has control over them, for the period required by national law (or six months by default).
The pattern across all deployer obligations is that they are continuous, not point-in-time. They cannot be satisfied by a documentation exercise in July 2026. They require an AI governance operating model, operational practices that run from go-live onwards.
Article 50 Transparency - The Obligation that Catches Almost Everyone
Article 50 sits in a strange place. It is a lighter obligation than the Chapter III high-risk regime. But it applies to a much broader set of AI systems, and most firms have far more Article 50 exposure than they realise.
AI systems intended to interact directly with natural persons must be designed and developed so that the natural persons concerned are informed they are interacting with an AI system. Every customer chatbot. Every AI-driven email autoresponder. Every AI receptionist or scheduling assistant.
AI systems generating synthetic audio, image, video, or text must mark outputs as artificially generated or manipulated. Marketing teams using AI image generators. Sales teams using AI-generated outbound personalisation. Legal teams using AI document drafts.
Emotion recognition systems and biometric categorisation systems must inform the natural persons exposed to them. Customer support AI doing sentiment analysis on calls. HR AI doing emotion-adjacent assessment.
AI systems generating or manipulating image, audio, or video that constitutes a deepfake must label the content as artificially generated. Any synthetic voice or video used in customer communications.
For mid-market firms, the Article 50 work is largely about implementation: configuring the chatbot to announce itself; updating customer email templates to disclose AI involvement; ensuring AI-generated marketing content carries appropriate metadata. The work is less burdensome than the high-risk regime but it touches more tools, and it is the EU AI Act compliance gap most teams discover last because it sits outside the high-risk classification process entirely.
Penalties - The Three Fine Bands
Article 99 sets the penalty regime in three bands: up to €35 million or 7% of global annual turnover, whichever is higher, for non-compliance with the Article 5 prohibition on prohibited AI practices; up to €15 million or 3% of global annual turnover for non-compliance with most other obligations; provider obligations, deployer obligations, conformity assessment requirements, transparency obligations; and up to €7.5 million or 1.5% of global annual turnover for supplying incorrect, incomplete, or misleading information to notified bodies or national competent authorities.
The fines are sized to be felt. They are also sized similarly to GDPR fines, the upper band is materially higher, but the broad architecture is recognisable to anyone who has lived through GDPR enforcement.
A point worth making to executive committees who have not been through GDPR: regulatory fines in Europe land where the supervisor decides, not on a fixed schedule. Most firms will not be fined; the firms that are fined will be fined materially. The regime is designed to set examples and shape industry practice, not to penalise every infraction.
How National Supervisors Will Enforce
The Act creates a three-layer supervisory architecture.
The AI Office sits within the European Commission's DG CNECT and acts as the central point of coordination for Union-level enforcement. Its remit covers general-purpose AI model oversight, the maintenance of the EU AI database, the development of harmonised standards and codes of practice, and coordination among national authorities.
National competent authorities, designated by each member state, handle most operational supervision. The Act allows each member state to designate one or more authorities. Some have designated their data protection authority (extending the DPA's remit). Some have designated a new dedicated AI authority. Some have designated a sectoral regulator for AI in that sector; for instance, the financial supervisor for AI in banking, the medical regulator for AI in healthcare.
Sectoral regulators continue to enforce the regulations they already enforce, and increasingly incorporate AI risk explicitly. BaFin and ACPR have signalled DORA enforcement will incorporate AI risk in financial services. The European Medicines Agency is integrating AI risk into medical device oversight.
For a European mid-market firm, this means engaging with potentially three layers simultaneously. The data protection authority for GDPR exposures and, where the DPA is also the AI competent authority, for AI Act exposure. The sector regulator for sector-specific AI risk. Where applicable, direct AI Office engagement for general-purpose AI questions or cross-border issues.
A Practical Reading List
If you have a free afternoon and want to read the Act yourself, the sections worth reading in full are: Article 3 (definitions); Article 5 (prohibited practices); Article 6 (high-risk classification rules); Article 26 (deployer obligations for high-risk systems); Article 27 (fundamental rights impact assessment); Article 50 (transparency obligations); Article 99 (penalties); and Annex III (high-risk use cases - short and operationally critical).
Skim the provider obligations chapters (Articles 9–24) unless you are a provider, the general-purpose AI provisions (Articles 51–55) unless you build on or distribute GPAI models, and the supervisory and enforcement architecture (Articles 60–98), useful context, not actionable on first reading. Primary sources: the consolidated text on EUR-Lex; the European Commission's AI Act summary; the AI Office's published guidance once it begins operations; and national competent authority guidance from your member state's designated authority.
The Act is more readable than its reputation suggests. The Articles are written in operative legislative style, but they are operationally specific. A focused two hours with the sections above is enough to develop a working knowledge.
Frequently Asked Questions
Does the Act apply to non-EU companies?
Article 2 sets the scope. The Act applies to providers placing AI systems on the EU market (regardless of where the provider is established), to deployers established in the EU, and - the part US firms most often miss, to providers and deployers located outside the EU when the output produced by the AI system is used in the EU. A US firm whose AI generates output used by EU customers is in scope for at least some provisions.
Does the Act apply to open-source AI?
Mostly carved out at the model level, but with limits. Article 2 carves out AI systems released under free and open-source licences from many obligations, except where the AI is placed on the market or put into service as a high-risk system, falls into prohibited practices, or triggers Article 50 transparency obligations. Most operational uses of open-source AI in mid-market firms; for instance, fine-tuning a Llama model for an internal use case, still attract deployer obligations if the resulting system is high-risk.
What about general-purpose AI like GPT-5 or Claude?
The Act treats general-purpose AI models distinctly from AI systems. Provider obligations for general-purpose AI models, including transparency about training data, copyright compliance, and for the largest models systemic risk assessment, apply to OpenAI, Anthropic, Google, and the other foundation model providers. As a deployer using their APIs, the provider obligations are theirs, not yours. Your obligations are at the AI system level, what you build with the API.
Does this overlap with GDPR?
Yes, materially. Most AI systems that process personal data trigger both regimes. The most important overlap: Article 35 GDPR DPIA obligations for processing likely to result in high risk to data subjects' rights now extend explicitly to AI processing in many cases, and Article 27 EU AI Act fundamental rights impact assessments overlap with DPIA work for some deployer categories. The two assessments are not the same document but they share substantial substrate.
Should I wait for harmonised standards to be published before doing the work?
No. The Act's obligations enforce on the dates above whether or not the harmonised standards are finalised. The standards, when published, will provide a presumption of conformity for specific obligations, meaning a firm that meets the standard is presumed to satisfy the corresponding obligation. They do not create the obligations; the Act does. Waiting for the standards is waiting for an easier route to satisfy obligations that already attach.
Does the Act apply to AI used purely internally?
Yes, where the AI is high-risk under Article 6. The deployer obligations attach to deployment, not to the publicness of the system. An AI used internally by HR for performance evaluation is just as much in scope as an AI used externally. The internal-use carve-outs are limited and specific.
My CEO asked: what one thing should we do this week?
If you do not yet have an AI inventory, get one started. Without an inventory you cannot classify through AI risk classification, and without classification you cannot prioritise. The discovery work takes thirty days at most mid-market firms. Everything else is downstream of it.
