The EU AI Act: an operator's compliance playbook (2026 edition)

Why this exists, and who it's for

Most of what is written about the EU AI Act is written for lawyers, by lawyers, and it reads like it. It walks the recitals, it parses the definitions, and it stops exactly at the point where an operator's questions begin. The questions an executive actually has are blunter. Does this apply to the system my team is shipping next quarter? If it does, what do I have to build before go-live, and who on my org chart owns it? When is the deadline, and what does missing it cost? This piece answers those four questions and not many others.

The cost question is the one that focuses the mind, so take it first. The Act is Regulation (EU) 2024/1689, adopted on 13 June 2024, and its penalty framework in Article 99 is tiered to the seriousness of the breach. Deploy a prohibited practice and the exposure is up to €35,000,000 or 7% of total worldwide annual turnover, whichever is higher. Breach most of the other operative obligations — the high-risk requirements, the transparency duties, the deployer duties — and the cap is €15,000,000 or 3%. Even supplying incorrect or misleading information to a regulator or notified body carries up to €7,500,000 or 1%. These are GDPR-class numbers, computed on group turnover, applied to a body of law that was unfamiliar to most boards eighteen months ago. That is the stake.

The Act does not only bite the people who build models. It is written around two roles, and the second one catches almost everyone. A provider develops an AI system and places it on the market under its own name. A deployer uses an AI system under its own authority in a professional context. If your company bought a CV-screening tool, a fraud-scoring service, or a customer-facing chatbot and switched it on, you are a deployer, and the Act assigns you obligations that no amount of vendor paperwork transfers away. So this playbook is for both audiences: the provider building or fine-tuning a system, and — more commonly — the operator who procured one and now owns the consequence of running it. If you sit on either side of that line and you operate in, or sell into, the European market, the next seven sections are the working reference.

A word on what this is not. It is not legal advice, and it does not replace counsel on a specific system — the Act turns on facts, and facts are where the judgement lives. What it gives you is the operator's map: the structure of the regime, the classification logic you can run yourself, the obligation set per tier, and the timeline you are managing against. Read it the way you would read a well-sourced internal briefing before you brief the board.

A note on method

The snapshot date for this edition is 1 June 2026. The Act's obligations switch on in phases that run from 2025 through 2027, and the implementing detail — harmonised standards, Commission guidance, delegated acts adjusting thresholds — is still being written. Everything below reflects the legal text and the publicly known position on that date. Subsequent editions will preserve the previous one at a dated URL so anyone citing this piece can pin the version they referenced.

The primary source is the Regulation itself. Every date, threshold, risk category, article number and penalty figure in this playbook is taken from Regulation (EU) 2024/1689 as published in the Official Journal of the European Union, not from secondary summaries. Where this piece names an article — Article 5 for prohibited practices, Article 6 and Annex III for high-risk, Article 50 for transparency, Article 51 for systemic-risk GPAI, Article 99 for penalties, Article 113 for the application dates — the article text was checked against the Official Journal. We do not paraphrase a sub-clause we have not read.

Where the law is unsettled, this piece says so rather than inventing precision. Harmonised standards are still in development; Commission guidance on several provisions is expected to evolve; the systemic-risk compute threshold can be amended by delegated act. In each of those places the playbook states the principle and flags that the operational detail is moving. The aim is a document an operator can act on without being misled by false certainty — the parts that are fixed in the legal text are presented as fixed, and the parts that are still being filled in are labelled as such.

This edition is written and signed by Consulting Huber. It carries an operator's bias on purpose: it is organised around the decisions an executive has to make and the controls an organisation has to stand up, not around the doctrinal structure a legal commentary would follow. For the doctrinal structure, read the Regulation. For the question of what to do on Monday, read on.

The Act in one page

Strip the recitals away and the architecture is simple. The EU AI Act is a risk-based product-safety regulation for AI. It does not regulate the technology in the abstract; it sorts AI systems into risk tiers by what they are used for, and it attaches a proportionate set of obligations to each tier. The higher the risk to health, safety or fundamental rights, the heavier the duties — up to and including outright prohibition. Most systems fall into the bottom tier and carry no new obligations at all. The regime's weight is concentrated on a defined band of high-risk use cases and on a handful of practices it bans outright.

The provider / deployer distinction is the hinge. Article 3(3) defines a provider as a party that develops an AI system or 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, whether for payment or free of charge. Article 3(4) defines a deployer as a party that uses an AI system under its own authority, except where the use is personal and non-professional. The two roles carry different obligation sets, and the heaviest duties — conformity assessment, technical documentation, the engineering of the system itself — sit with the provider. But deployers are emphatically caught too. A deployer of a high-risk system must operate it according to instructions, assign competent human oversight, monitor it, keep the logs it generates, and inform the people it affects. The common board-level error is to assume that buying a system from a vendor exports the risk along with the invoice. It does not. The procurement contract allocates commercial liability between the parties; it does not relieve the deployer of the duties the Act places on deployers directly.

The reach is extraterritorial. The Act follows the output, not the office. A provider or deployer established outside the European Union is in scope where the output produced by the AI system is used in the Union. A US firm that scores European job applicants, or a model provider whose system is put into service in a member state, cannot sit outside the regime by sitting outside the geography. If your AI touches the European market — through users, customers, or the use of its output inside the Union — assume you are in scope until counsel tells you otherwise. That single assumption is the safe operating default, and it is the premise the rest of this playbook runs on.

The four risk tiers, with worked examples

The Commission's taxonomy sorts every AI system into one of four tiers. The legal hooks for three of them sit in Articles 5, 6 and 50; the fourth tier is everything the first three do not catch. The tiers are not a spectrum you negotiate — they are categories, and your system is in exactly one of them per use case. Here is each tier with one concrete example an operator will recognise, anchored to its article or annex.

1. Unacceptable risk — prohibited (Article 5)

A short, closed list of practices the Act bans outright. There is no compliance path for these; they are off the table in the European market regardless of how well the system performs or how carefully it is governed. Because this is step one of classification, it is worth having the whole list in front of you. Article 5(1) prohibits eight practices:

• Subliminal, manipulative or deceptive techniques that materially distort behaviour and cause (or are likely to cause) significant harm.
• Exploiting vulnerabilities of age, disability, or a specific social or economic situation to materially distort behaviour and cause significant harm.
• Social scoring — evaluating or classifying people over time based on behaviour or personal characteristics, leading to detrimental or disproportionate treatment.
• Predicting the risk that a person will commit a criminal offence based solely on profiling or personality traits.
• Building or expanding facial-recognition databases through untargeted scraping of facial images from the internet or CCTV.
• Inferring emotions in the workplace or in education institutions (except for medical or safety reasons).
• Biometric categorisation that infers sensitive attributes — race, political opinions, trade-union membership, religious or philosophical beliefs, sex life or sexual orientation.
• “Real-time” remote biometric identification in publicly accessible spaces for law enforcement — banned except in narrowly listed cases, with safeguards.

Worked example. A vision startup builds a facial-recognition database by scraping faces indiscriminately from the open internet and public CCTV feeds. That is the practice banned by Article 5(1)(e) — untargeted scraping of facial images to build or expand facial-recognition databases. It does not matter that the model is accurate or that the data was “public”. The practice itself is prohibited, the exposure under Article 99 is the top €35M / 7% band, and prohibitions have been in force since 2 February 2025. This is the tier where the only correct engineering decision is not to build the thing.

2. High risk (Article 6, Annex I and Annex III)

Permitted, but only behind the heaviest set of obligations in the Act. A system is high-risk on one of two routes: Article 6(1), where the AI is a safety component of a product already regulated under EU harmonisation legislation listed in Annex I; or Article 6(2), where the use case falls within one of the eight areas enumerated in Annex III. High-risk systems must satisfy a defined regime — risk management, data governance, technical documentation, logging, human oversight, transparency to deployers, and conformity assessment before they reach the market. This is the tier most enterprise AI work lands in, and the tier this playbook spends the most time on.

Worked example. A company deploys an AI tool that screens and ranks CVs to shortlist candidates for interview. Recruitment and selection sit squarely inside Annex III, point 4 — employment, workers management and access to self-employment. That makes the tool high-risk. The provider that built it owes the full Article 6(2) regime; the employer that runs it owes the deployer duties, including competent human oversight and informing affected workers. The fact that it is “just a screening aid” does not move it down a tier — the use case is what classifies it.

3. Limited / transparency risk (Article 50)

Systems that interact with people or generate content carry disclosure duties rather than the full high-risk regime. Article 50 requires that people be told when they are interacting with an AI system rather than a human, that synthetic audio, image, video or text be marked as artificially generated or manipulated, and that deepfakes and AI-generated content informing the public on matters of public interest be labelled. These are lightweight, but they are mandatory, and they apply on top of any higher-tier classification.

Worked example. A retailer puts a generative customer-service chatbot on its website. The chatbot is not making high-risk decisions, so it is not Annex III — but under Article 50 the retailer must make clear to customers that they are talking to an AI, not a person. The fix is a one-line disclosure, designed in from the start. The failure mode is discovering at audit that the disclosure was never built, on a system that has been live for a year.

4. Minimal / no risk (no obligations)

The large majority of AI systems. Spam filters, AI in video games, recommendation features that fall outside the higher tiers, inventory-optimisation models — these carry no new obligations under the Act. The point of naming this tier is to stop the over-rotation that follows every new regulation, where teams freeze ordinary software because it contains a model. If a system is not prohibited, not high-risk under Annex I or III, and not subject to an Article 50 transparency duty, the Act imposes nothing on it. Classify honestly, and most of your portfolio lands here.

Worked example. An email platform uses a machine-learning classifier to route spam to a junk folder. It is not in any Annex III category, it makes no decision about a person's rights or access to services, and it does not impersonate a human. It is minimal-risk. No conformity assessment, no logging mandate, no oversight personnel — the correct compliance action is to record the classification reasoning and move on.

One duty that ignores the tiers. The AI literacy obligation in Article 4 is not tied to risk level. Since 2 February 2025, any provider or deployer must ensure a sufficient level of AI literacy among the staff who operate their AI systems — whatever tier those systems sit in. So “minimal risk” means no system-level obligations, not “nothing to do”: the people using even a minimal-risk tool still need to understand what it does and where it can go wrong.

“Which tier am I?” — a classification walkthrough

Classification is a decision you can run yourself before you ever bring in counsel, and running it yourself first makes the legal conversation faster and cheaper. The logic is a short cascade, and you run it per use case, not per system — the same underlying model can be minimal-risk in one application and high-risk in another. Work down the cascade in order and stop at the first tier that catches you.

1. Is the practice prohibited? Check the use against the closed Article 5 list first, because nothing else matters if it is banned. If the system does any of the prohibited things — manipulation causing significant harm, exploiting vulnerabilities, social scoring, profiling-only crime prediction, untargeted facial scraping, workplace or education emotion inference, sensitive-attribute biometric categorisation, or unlawful real-time public biometric ID — you stop here. The answer is do not deploy.
2. Is it high-risk? If not prohibited, test the two high-risk routes. Route one, Article 6(1): is the AI a safety component of a product covered by the Annex I harmonisation legislation? Route two, Article 6(2): does the use case fall in one of the eight Annex III areas below? A yes on either route puts you in the high-risk tier and its full obligation set.
3. Does a transparency duty apply? Whether or not it is high-risk, ask whether the system interacts with people or generates synthetic content. If so, the Article 50 disclosure and labelling duties attach.
4. Otherwise, it is minimal-risk. If none of the above catch the use, the Act imposes no new obligations. Record why, and keep the record.

The hinge of the whole cascade is step two, and specifically the eight Annex III areas. If your use case sits in any of these, treat it as high-risk until counsel says otherwise:

1. Biometrics — remote biometric identification, biometric categorisation by sensitive attributes, and emotion recognition where it is permitted at all.
2. Critical infrastructure — AI used as a safety component in critical digital infrastructure, road traffic, and the supply of water, gas, heating and electricity.
3. Education and vocational training — admission decisions, evaluation of learning outcomes, assessment of the level a person will reach, and monitoring for exam cheating.
4. Employment and workers management — recruitment and selection, promotion and termination decisions, task allocation, and performance monitoring of workers.
5. Access to essential services and benefits — eligibility for public assistance, creditworthiness and credit scoring, life and health insurance risk assessment and pricing, and the dispatch or prioritisation of emergency calls.
6. Law enforcement — assessing a person's risk as a victim, polygraphs, evaluating the reliability of evidence, assessing offending or re-offending risk, and profiling.
7. Migration, asylum and border control — polygraphs, risk assessment, examination of visa, asylum and residence applications, and detection or identification of persons (other than verification of travel documents).
8. Administration of justice and democratic processes — assisting a judicial authority in researching and interpreting facts and the law, and systems intended to influence elections, referenda, or voting behaviour.

The GPAI path is separate. If you build, train or significantly fine-tune a general-purpose AI model — a foundation model that can be adapted to many downstream tasks — you are on a different classification track that runs in parallel to the four tiers above, under Chapter V of the Act. Every GPAI provider carries a baseline set of obligations regardless of risk. On top of that, a GPAI model is classified as carrying systemic risk under Article 51 if it has “high-impact capabilities” — a condition that is presumed when the cumulative compute used to train the model exceeds 10²⁵ floating-point operations (FLOPs). That presumption threshold can be amended by the Commission through delegated acts, so treat the exact number as a moving figure and the principle — the largest, most capable models attract the heavier duties — as the fixed part. Models above the line owe the systemic-risk obligations in addition to the baseline GPAI set. The obligations themselves are in the next section.

Obligations per tier

Classification tells you which tier you are in. This section tells you what each tier actually requires you to build and run. The duties scale with the tier, and the bulk of the engineering and process work lives in the high-risk band.

Prohibited — nothing to build, everything to stop

There is no obligation set for prohibited practices because there is no compliant way to run one. The operator's task here is purely defensive: confirm that nothing in the current or planned portfolio falls inside Article 5, and put a gate in the product process so a prohibited use cannot be built by accident. The prohibitions have applied since 2 February 2025, so this is not a future problem to schedule — it is a present-tense check.

High-risk — the heavy regime

This is where the real work sits. A high-risk system has to satisfy a connected set of obligations across its lifecycle, and most of them are organisational disciplines as much as engineering features. The obligation areas the Act requires of high-risk systems are:

• Risk management — a continuous, documented process that identifies and mitigates risks to health, safety and fundamental rights across the system's lifecycle, not a one-time assessment at launch.
• Data governance — training, validation and test data managed for quality, relevance and representativeness, with the data-handling practices documented.
• Technical documentation — a complete record of how the system was built, what it does, and how it meets the requirements, kept current and available to authorities.
• Logging and record-keeping — automatic recording of events over the system's operation so that its functioning can be traced and monitored.
• Human oversight — designated, competent people able to understand the system's outputs, recognise automation bias, override decisions, and stop the system where needed.
• Transparency to deployers — clear instructions for use so that a deployer can operate the system correctly and meet its own obligations.
• Conformity assessment — the system must be assessed against the requirements before it is placed on the market or put into service.

The split of duties matters operationally. The provider owns the engineering-side requirements — building the risk-management process into the system, the data governance, the documentation, the conformity assessment. The deployer owns the operational-side requirements — running the system per instructions, staffing the human oversight, retaining the logs the system generates, monitoring it in production, and informing the people it affects. Neither side can discharge the other's duties, which is why a clean contractual allocation between provider and deployer is part of getting a high-risk system live, not an afterthought.

Limited / transparency — disclose and label

The Article 50 duties are narrow and concrete. People interacting with an AI system must be told they are dealing with AI. AI-generated or manipulated audio, image, video and text must be marked as such in a machine-readable way. Deepfakes and AI-generated content that informs the public on matters of public interest must be labelled. The work here is small but easy to forget: it has to be designed into the product surface and the content pipeline, not retrofitted under audit pressure.

GPAI — the Chapter V duties

General-purpose AI model providers carry obligations that are distinct from the four-tier system. Every GPAI provider must maintain technical documentation of the model, provide information and documentation to downstream providers who integrate the model into their own systems, put in place a policy to comply with EU copyright law, and publish a sufficiently detailed summary of the content used to train the model. GPAI providers whose model carries systemic risk (the Article 51 classification from the previous section) carry additional duties on top: model evaluation, assessment and mitigation of systemic risks, tracking and reporting of serious incidents, and an adequate level of cybersecurity for the model and its physical infrastructure. The systemic-risk set is deliberately heavier because it attaches to the models with the broadest downstream blast radius.

The timeline

The Act does not switch on all at once. Article 113 phases the obligations in over three years from entry into force, and the staggering is deliberate: the practices judged most harmful are banned first, the model-level and governance machinery comes next, and the bulk of the high-risk regime lands in the middle of the schedule. The dates below are the ones to manage against — each row is a milestone you are either already past or planning toward.

Two practical reads of this table. First, the high-risk obligations that catch most enterprise software — the Annex III use cases — land on 2 August 2026, which from the snapshot date of this edition is close. A high-risk system that is not yet through risk management, data governance, documentation and conformity assessment is on a tight clock. Second, the prohibition and GPAI milestones are already behind us; if your portfolio has not been checked against Article 5 and your foundation-model work against Chapter V, those are not future deadlines you are preparing for — they are present obligations you may already be missing.

Compliance as a delivery capability, not a legal box-tick

Here is the part most of the legal commentary misses, and the part that decides whether AI Act compliance costs you a fortune in recurring consulting fees or becomes a durable property of how you ship. The Act, read by a lawyer, is a set of obligations. The Act, read by an operator who has actually run engineering organisations, is a specification for capabilities you build into the delivery layer underneath your AI — and once you read it that way, most of the high-risk regime stops looking like paperwork and starts looking like engineering you should be doing anyway.

Walk the high-risk obligation set again, this time as a delivery person rather than a compliance officer. The article text confirms the mapping: risk management is Article 9, data governance is Article 10, technical documentation is Article 11, record-keeping and logging is Article 12, transparency and information to deployers is Article 13, human oversight is Article 14, and accuracy, robustness and cybersecurity is Article 15. Now stop treating those as seven separate documents a lawyer assembles after the fact, and treat them as seven properties a well-run delivery pipeline already produces — or can be made to produce with a quarter's work.

• The system registry is your Article 11 documentation. Every team that ships AI should maintain a model-and-system registry: what each system is, what it does, who owns it, what data trained it, what version is in production, and which tier it was classified into and why. Stand that registry up properly and it is not a compliance artefact bolted on for the auditor — it is the technical documentation the Act requires, kept current as a side-effect of normal operations rather than reconstructed under deadline pressure. The single most expensive way to meet Article 11 is to write it from memory the month before an assessment. The cheapest is to never let the registry go stale.
• Evaluation gates are your Article 15 evidence. Accuracy, robustness and cybersecurity are not assertions you make in a paragraph; they are claims you have to substantiate. An organisation that runs evaluation suites in its pipeline — accuracy on held-out and adversarial data, behaviour under distribution shift, red-team probes — and that blocks a release when a metric regresses, is generating the evidence for Article 15 every time it ships. Treat model evaluation as continuous integration for AI: a gate the build has to pass, with the result logged. The compliance story then writes itself, because the testing happened on the way to production rather than as a special exercise afterwards.
• Audit logs satisfy Article 12 by design. The logging obligation is the easiest one to meet if you build it in and the hardest to retrofit. A high-risk system has to record events over its operation so its functioning can be traced. If logging is designed into the system from the first sprint — inputs, outputs, the human-override events, the model version that served each decision — then record-keeping is simply on. If it is an afterthought, you are re-instrumenting a live system under audit, which is exactly the situation no operator wants to be in.
• Human oversight is a product control, not a policy. Article 14 does not ask for a sentence in a handbook saying a human is in the loop; it asks for designated, competent people who can actually understand the output, recognise automation bias, override the decision, and stop the system. That is an interface and a workflow, not a clause. It means override buttons that work, escalation paths that route to someone with authority, and a UI that surfaces confidence and rationale rather than hiding them. Oversight wired into the product surface is real; oversight written into a policy document and contradicted by a UI that offers no override is the kind of gap an assessor finds in an afternoon.
• Change management triggers re-classification. The classification you ran in section 5 is true on the day you ran it. A system that gets a new use case, a materially different training set, or a capability it did not have before can cross a tier boundary — a minimal-risk tool extended into an Annex III use case becomes high-risk, and nobody filed the paperwork because nobody noticed the line had moved. The control is a lightweight change-management step: any material change to an AI system re-opens the classification question before it ships. This is the discipline that keeps the registry honest and stops a quiet feature change from turning into an unannounced compliance breach.

This is the through-line of how we think about AI generally: the models get the headlines, but the value — and now the regulatory exposure — is realised or lost in the delivery layer underneath the AI: the pipelines, the registries, the evaluation harnesses, the oversight controls, the release discipline. The AI Act is, from one angle, a regulator telling you to build that delivery layer well. Organisations that already ship AI with proper evaluation gates, real logging, an honest inventory and disciplined change management will find compliance is mostly a matter of pointing at controls they already run. Organisations that ship AI without those things will experience the Act as a tax — because the Act is, in effect, charging them for the engineering discipline they skipped. Build the capability once and it serves the regulation, the auditor, and the quality of the product at the same time. That is the whole argument: compliance is a delivery capability, and the firms that treat it as one will pay for it once instead of forever.

A 90-day action plan

The strategy above is only useful if it survives contact with a calendar. Here is the plan an operator can actually run in a quarter, banded by week, to get from “we have AI somewhere in the estate” to “we know exactly what we have, what tier each system is in, where the gaps are, and who owns closing them.” It assumes one accountable owner — a transformation lead, a CTO, or an interim brought in for the purpose — and a working group that can pull in legal, security and the relevant product teams. Ninety days is enough to get the inventory and classification right and to start remediation; it is not enough to finish remediating a complex high-risk system, and the plan does not pretend otherwise.

Weeks 1–2 — Inventory every AI system

You cannot classify what you have not catalogued, and almost every organisation underestimates how much AI it is already running — the procured SaaS tool with a model inside, the analytics feature someone shipped last year, the chatbot marketing stood up without telling engineering. Build the registry now. For every AI system, capture: what it does, the business owner, the technical owner, whether it was built in-house or procured, and — critically — your role per system. For each one, decide whether you are the provider (you built it or put it on the market under your name) or the deployer (you procured it and run it under your own authority), because that determines which obligation set lands on you. Many organisations are both, on different systems. The deliverable at the end of week 2 is a single registry, owned and maintained, that says: here is every AI system we touch, and here is our role on each.

Weeks 3–6 — Classify each system by tier

Run every system in the registry through the classification cascade from section 5, per use case. Check it against the Article 5 prohibitions first — anything caught there is an immediate escalation, not a quarter-end item. Then test the two high-risk routes: Annex I safety component, or one of the eight Annex III areas. Then the Article 50 transparency triggers. Everything not caught is minimal-risk — and you record why, because an unjustified “minimal” is the classification an assessor will challenge. Expect most of the portfolio to land in minimal-risk, a meaningful minority in transparency, and a smaller, higher-stakes set in high-risk. The deliverable is the registry with a defensible tier and a one-line rationale against every system, plus a flagged shortlist of the high-risk and GPAI systems that the rest of the quarter focuses on.

Weeks 7–10 — Gap-assess the high-risk and GPAI systems

Take the flagged shortlist and assess each system against the obligation areas that apply to its tier. For a high-risk system, walk the seven Article 9–15 areas — risk management, data governance, technical documentation, logging, transparency to deployers, human oversight, accuracy/robustness/cybersecurity — plus conformity assessment, and mark each as in place, partial, or absent. For a GPAI model you build or significantly fine-tune, assess against the Chapter V baseline (documentation, downstream information, copyright policy, training-content summary) and, if it crosses the systemic-risk threshold, the additional Article 51 duties. Be honest about “partial” — a logging mechanism that captures some events but not the override decisions is partial, not in place. The deliverable is a gap matrix: systems down one axis, obligations across the other, every cell rated.

Weeks 11–13 — Remediate, assign owners, stand up the controls

Turn the gap matrix into a backlog with named owners and dates. Prioritise by exposure — anything near an Article 5 line first, then the high-risk systems closest to a live deadline. In parallel, stand up the durable controls from section 8 so the same gaps do not reopen: the maintained registry, evaluation gates in the pipeline, logging by design, human-oversight controls in the product, and the change-management step that re-triggers classification when a system changes. The point of doing this in the same quarter as the assessment is that the controls are what keep you compliant after the consultants leave; remediation without the controls is a snapshot that decays the moment the next feature ships. The deliverable is an owned, dated remediation backlog plus a running set of controls — the start of compliance as a standing capability rather than a project.

Penalties and enforcement

The penalty framework sits in Article 99, and it is tiered to match the seriousness of the breach. There are three bands.

• Up to €35,000,000 or 7% of total worldwide annual turnover for the financial year preceding the decision — for breach of the Article 5 prohibitions. This is the top band, reserved for the practices the Act bans outright.
• Up to €15,000,000 or 3% of total worldwide annual turnover — for breach of most of the other operative obligations, including the high-risk requirements on providers and deployers, the transparency duties, and the GPAI obligations.
• Up to €7,500,000 or 1% of total worldwide annual turnover — for supplying incorrect, incomplete or misleading information to notified bodies or national competent authorities in reply to a request.

The “or” in each band does real work, and it cuts in opposite directions depending on who you are. For an undertaking — a company — the applicable maximum is the higher of the fixed euro figure and the turnover percentage. A large group with billions in turnover is therefore exposed to the percentage, which can run far above the headline euro cap. For SMEs and start-ups, the position is inverted: the applicable maximum is the lower of the two, so a small company is not destroyed by a percentage of a turnover it does not have. The structure is deliberate — it scales the deterrent to the size of the actor rather than applying a flat number that would be trivial to a multinational and fatal to a start-up.

Enforcement is not a single regulator. It is distributed across a structure that switched on with the governance provisions on 2 August 2025. Each Member State designates national competent authorities and market-surveillance authorities that enforce the Act on the ground within their territory — investigating, requesting information, and imposing penalties. At Union level, the European AI Office inside the Commission has the lead on general-purpose AI models, including the systemic-risk GPAI duties. The European Artificial Intelligence Board coordinates across the Member States to keep enforcement consistent rather than fragmenting into twenty-seven divergent interpretations. For an operator, the practical consequence is that your first enforcement contact is most likely a national authority in a Member State where your system operates, while GPAI questions route to the AI Office.

A realistic word on posture, because alarmism is as unhelpful as complacency. As of the snapshot date of this edition, the regime is young: the prohibitions and governance bodies are live, the penalty framework is operable, but the bulk of the high-risk regime does not apply until 2 August 2026, and the supporting machinery — harmonised standards, notified bodies, the detail of enforcement practice — is still maturing. The reasonable expectation is that early enforcement focuses on the prohibited practices, on egregious or wilful non-compliance, and on the largest actors, rather than on good-faith operators who are visibly working through classification and remediation. That is not a reason to wait. It is a reason to be the kind of operator who, if a regulator does call, can show a maintained registry, a defensible classification, and an owned remediation plan — because demonstrable good faith and a paper trail of diligence are worth a great deal when enforcement discretion is being exercised. The risk is not that you will be fined for being mid-remediation in good faith. The risk is being unable to show you ever started.

Where Consulting Huber fits

Consulting Huber is a practitioner firm, and AI Act compliance is exactly the kind of problem we are built for: part legal-aware classification, part engineering discipline, part change management — and most of it living in the delivery layer rather than in a legal opinion. We are not a substitute for your counsel on a specific system, and we say so plainly; the law turns on facts, and facts are where a lawyer earns their fee. What we do is the operator's half of the work that sits on either side of that legal advice.

Concretely, that is three things. We run the inventory and classification — standing up the registry, walking your portfolio through the cascade, and producing the defensible tier-and-rationale record that turns “we have AI somewhere” into a map you can brief a board from. We build compliance into the delivery layer — the evaluation gates, the logging-by-design, the human-oversight controls, and the change-management discipline that make the obligations a property of how you ship rather than a recurring audit scramble. And we do it on an interim or advisory footing: embedded as the accountable owner for the quarter that gets the capability stood up, or alongside your team as the senior pair of hands that has done it before. The model is capability transfer — when we leave, the registry, the gates and the controls stay, owned and run by your people.

The companion thinking sits across the site: the broader case for the engineering layer is in The Delivery Layer Underneath AI, the value side is in the AI value creation playbook, and the service page for the strategy-and-delivery work is Digital & AI Strategy. If you have a specific system and a 2 August 2026 deadline you are managing against, the most useful next step is a short conversation about where you actually are.