The AI Act now applies to almost every business that touches an EU user, not just AI developers

A Slovak marketing agency running client campaigns through a chatbot widget. A German HR platform screening CVs with a ranking model. A US software vendor whose SaaS tool scores loan applicants for a Portuguese bank. None of these companies builds AI models. All three are inside the scope of the EU Artificial Intelligence Act, and as of 27 July 2026, the rulebook that defines what they owe changed again.

The EU AI Act, formally Regulation (EU) 2024/1689, is not a law aimed narrowly at OpenAI, Google, or Anthropic. It is a horizontal product-safety and fundamental-rights regulation that reaches anyone whose AI output lands in front of someone in the European Union, regardless of where that company is incorporated, how big it is, or whether it wrote a single line of model code. The scope question is the one most businesses get wrong first, because they read “AI regulation” and assume it means “regulation for AI labs.”

The confusion is understandable. The Act runs to 113 articles and thirteen annexes, uses at least six distinct actor categories, and applies its obligations on a staggered calendar that has itself been rewritten twice since the regulation entered into force on 1 August 2024. Layered on top of that base complexity, the European Commission’s Digital Omnibus on AI, published as Regulation (EU) 2026/1744 in the Official Journal on 24 July 2026 and in force since 27 July, shifted the highest-profile deadline by sixteen months and quietly closed a different set of dates on schedule.

This piece works through the practical questions in the order a compliance team actually needs them answered: who counts as a provider, deployer, importer or distributor; what makes something an “AI system” under the legal definition rather than the everyday one; which of the four risk tiers a given use case falls into; what the eight prohibited practices actually forbid; what Annex III’s high-risk categories cover in the sectors most businesses touch, including employment, credit and marketing; what general-purpose AI model providers owe versus what downstream companies owe; and what the amended timeline now requires by which date. Two tables anchor the sector-by-sector and tier-by-tier detail. A dedicated FAQ closes out the specific questions that come up most often in this exact conversation: does my company count, what do I have to do first, and what happens if I do nothing.

One caution before any of that: the AI Act is dense EU legislation with active political amendment, ongoing Commission guidelines, and a Code of Practice still being refined. Nothing here substitutes for legal advice on a specific system. What follows is a factual map of the regulation as it stands after the Digital Omnibus, built from the consolidated text, the Commission’s own guidance, and the law firms and compliance trackers following the file week by week through 2026.

Two features of the current moment make this article worth reading in full rather than skimming for a single headline date. The first is that the regulation genuinely operates on more than one calendar at once, so a single “AI Act deadline” does not exist; a business can be liable today under one article, liable from August 2026 under another, and not liable until December 2027 under a third, all for the same product. The second is that the Digital Omnibus itself did not settle every open question about the Act’s future; a parallel Data Omnibus touching the GDPR remains under negotiation, harmonised technical standards are still being finalised, and the political debate over whether this round of simplification went too far or not far enough is very much still active, in Brussels and in the national capitals implementing the framework locally. Reading the scope and obligations questions in isolation from that broader, still-moving context risks planning a compliance program around a snapshot that is already several steps out of date by the time it is built.

A 2021 draft written before ChatGPT became today’s rulebook

Understanding why the AI Act is structured the way it is, with a use-case-based risk system bolted onto a separate general-purpose AI chapter, requires going back to a moment before the technology that now dominates the conversation existed in public form at all. A full-fledged draft of the AI Act was published in April 2021, initiating a trilogue process in which the Commission assisted the Council of the EU and the European Parliament to negotiate a final version of the text; finding a compromise proved difficult, as the legislative actors diverged in opinion on multiple fronts, from the Act’s scope to its enforcement mechanisms.

When the European Commission proposed the Act in April 2021, it built the legislation around a straightforward principle: regulate AI according to the risks of its use rather than the technology itself, so that an AI system used to screen job applicants could create significant risks and therefore face strict obligations, while a spam filter would not; the proposal deliberately focused on applications rather than underlying models, and did not fully anticipate the emergence of increasingly capable general-purpose systems.

That gap became impossible to ignore once generative AI entered public consciousness. The earliest hint that the use-case structure had a gap came under the Slovenian Council presidency in November 2021, which floated the idea that general-purpose AI might need its own treatment; the French presidency pressed the question through 2022 and advanced a proposal to treat GPAI models independently from other AI systems, and by the Council’s general approach in late 2022, around the same time ChatGPT was capturing public imagination, member states had agreed that providers of general-purpose systems should shoulder certain obligations.

The political urgency ChatGPT generated shaped what came next: in its June 2023 negotiating position, the Parliament introduced a dedicated tiered regime for foundation models, and those two positions were reconciled in the trilogue that closed in December 2023, producing the layered GPAI architecture described earlier in this piece: baseline transparency and copyright duties for all providers, with a heavier layer for models carrying systemic risk. A compromise was ultimately reached in December 2023, but it was not until June 2024, more than three years after the initial draft, that the text was formally signed, motivated in large part by the rapid spread of generative AI, especially after the launch of ChatGPT in November 2022, which spurred the EU to add obligations for GPAI model providers that were never part of the regulation’s initial draft.

This history matters for a practical reason: it explains why the Act reads, in places, like two regulations stitched together, a use-case risk ladder designed for narrow, purpose-built systems, and a separate model-level chapter grafted on in response to a technology wave the original drafters had not fully foreseen. Businesses navigating both the Annex III sector analysis and the GPAI provider analysis are, in effect, navigating the seam between the Act’s original 2021 architecture and its 2023 retrofit.

The regulation nobody finished reading before it started applying

Regulation (EU) 2024/1689 was published in the Official Journal on 12 July 2024 and entered into force on 1 August 2024. From that date, a countdown began that was always going to be staggered rather than a single cutover. Chapter I (general provisions) and Chapter II (prohibited practices) applied first, from 2 February 2025. Chapter V, covering general-purpose AI models, followed on 2 August 2025, alongside the penalty framework in Chapter XII. The bulk of the regulation, including the high-risk rules in Chapter III, was originally set to apply from 2 August 2026.

That original 2 August 2026 date became the organizing deadline for enterprise AI governance programs throughout 2025 and into 2026. Compliance budgets, board reporting, vendor contracts and internal risk committees were all built around it. In May 2026 alone, the EU provisionally agreed material changes through the Digital Omnibus on AI, postponing key compliance deadlines, and published draft guidance on high-risk system classification and transparency requirements.

The reason for the delay was not political cold feet about AI risk. The European Commission introduced the Digital Omnibus, a legislative simplification package covering the AI Act, GDPR and Data Act, arguing that the compliance ecosystem was not ready: the harmonised standards needed to guide companies had not been finalized in time. A law that tells providers to build a quality management system and pass a conformity assessment is only workable once the technical standards defining what “compliant” looks like actually exist. By late 2025, those standards were behind schedule, and the Commission judged that forcing an August 2026 deadline without them would create legal uncertainty rather than safety.

What makes this moment specifically worth writing about now, in the closing days of July 2026, is that the political back-and-forth is over. The amending regulation is law. Regulation (EU) 2026/1744 is in the Official Journal as of 24 July 2026 and enters into force on 27 July, closing a series that followed the file from the call for evidence to the Commission proposal, through the trilogues, the provisional agreement of 7 May, and the Council’s final green light of 29 June 2026. Every business that spent 2025 building toward 2 August 2026 now needs to know precisely which parts of that plan still apply on that date and which parts got sixteen months of breathing room.

Placing on the market and putting into service, the two triggers that start every obligation

Before any risk classification or actor category matters, the AI Act asks a threshold question: has an AI system been placed on the market, put into service, or used within the Union. These are defined legal concepts, not casual phrases, and they determine the moment obligations attach.

“Placing on the market” refers to the first time an AI system or GPAI model is made available on the Union market, whether for payment or free of charge. “Putting into service” refers to first use for its intended purpose, including internal use by the provider itself. A company that builds an AI-powered internal analytics tool and never sells it has still put that system into service the moment employees start using it for its designed purpose. This matters because plenty of businesses assume internal-only tools sit outside the regulation. They do not, if the use case rises to a prohibited or high-risk classification.

The distinction between these two triggers and mere “use” also determines which obligations apply to which actor. Providers are judged against the placing-on-the-market and putting-into-service moments. Deployers are judged against the moment of use. A single company can be both, if it builds a tool and also uses it, and the obligations from both roles stack rather than substitute for each other.

The AI system definition that decides whether any of this applies to you at all

Every question in this article rests on one prior determination: is the technology in question an “AI system” under the Act’s own legal definition. Not every piece of software that a marketing team calls “AI” meets that bar, and not every tool that looks like ordinary automation is safely outside it.

The Act defines an AI system as a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments. That single sentence, lifted nearly verbatim from the OECD’s own 2024 revised definition, carries seven load-bearing components that the European Commission has since had to clarify in dedicated guidelines, because the legal text alone left too much room for dispute.

The most contested of those components is “inference.” The Commission clarifies that although the phrasing “infers, how to generate outputs” might suggest inference belongs to the deployment phase, it should instead be understood as primarily referring to the build phase, where a system derives outputs through AI techniques, including logic- and knowledge-based approaches, that enable inference. In plain terms: a system counts as inferring even if, once deployed, it behaves in a fixed and predictable way, so long as the technique used to build it involved deriving rules or patterns from data or logic rather than a human explicitly hand-coding every output.

This has real consequences for the “is it AI or is it just software” question that trips up smaller companies constantly. A spreadsheet formula that averages last quarter’s sales is not an AI system. A regression model trained on historical sales data to forecast next quarter, even a simple linear one with no adaptive learning after deployment, sits closer to the line and, according to some technical guidance, may fall outside scope only if it relies exclusively on basic mathematical optimisation without any adaptive component. Systems that rely exclusively on simple mathematical optimisation or long-established methods, such as standard linear or logistic regression without adaptive components, fall outside the scope, but once these methods are combined with techniques such as reinforcement learning, they are generally treated as AI systems.

Recital 12 of the Act supplies further interpretive texture, distinguishing autonomy (some degree of independence from human involvement) from adaptiveness (self-learning capability after deployment) and treating the latter as optional rather than mandatory for AI-system status. Legal scholars have criticized this looseness, arguing it leaves considerable ambiguity for edge cases, but for the vast majority of commercial tools built on modern machine learning, generative language models, computer vision, or recommendation engines, the classification question resolves quickly: if the system was trained on data to produce outputs it was not explicitly programmed line-by-line to produce, it is almost certainly an AI system under Article 3(1).

Why this determination matters practically: a business that misclassifies its own tooling as “just software” and skips the AI Act analysis entirely carries the same exposure as one that does the analysis and gets the risk tier wrong. The starting question, before providers, deployers, or risk tiers enter the conversation, is always whether Article 3(1) applies at all.

Providers carry the heaviest legal weight of any actor in the chain

The AI Act organizes obligations around actor roles rather than industries, and the provider role carries by far the most extensive duty set. A provider is a natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model, or that has an AI system or model 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.

The “under its own name or trademark” clause is the detail that catches companies off guard. A business does not need to write a single line of model code to become a provider. If it takes a third-party foundation model, wraps it in a branded interface, and ships it as “[Company] Assistant,” it has placed that system on the market under its own trademark, and the provider obligations attach to it, not only to the underlying model’s original developer. This is precisely the scenario the Act’s Article 25 addresses under “responsibilities along the AI value chain”: a distributor, importer, deployer, or other third party becomes a provider, inheriting the full Article 16 obligation set, in specific circumstances including putting its own name or trademark on a high-risk AI system already placed on the market, or making a substantial modification to a high-risk system such that it remains high-risk.

For providers of high-risk AI systems, Article 16 lists the core obligation set in full: ensure that their high-risk AI systems are compliant with the requirements set out in Section 2; indicate on the system, or its packaging, or accompanying documentation, their name, registered trade name or trademark and contact address; have a quality management system in place complying with Article 17; keep the technical documentation referred to in Article 18; when under their control, keep the automatically generated logs referred to in Article 19; ensure the system undergoes the relevant conformity assessment procedure under Article 43 before being placed on the market or put into service; draw up an EU declaration of conformity under Article 47; affix the CE marking under Article 48; comply with registration obligations under Article 49; and take necessary corrective actions and provide information as required under Article 20.

Each of those items is itself a small compliance program, not a checkbox. The quality management system under Article 17 covers a strategy for regulatory compliance, techniques for design control and verification, testing procedures, and risk management. The technical documentation under Article 18 must exist before the system is placed on the market and describe the system’s purpose, design choices, data used, and performance metrics in enough detail that a market surveillance authority could reconstruct why the provider believes it meets the essential requirements. Registration under Article 49 means the system’s existence is entered into a public EU database before deployment for most Annex III use cases, a transparency mechanism with few parallels in prior EU product law.

Providers established outside the EU face one further requirement: appointing an authorised representative established within the Union, who acts as the point of contact for market surveillance authorities and the AI Office. If a company is established or located outside the EU, it will have to appoint an authorised representative within the EU. This mirrors a structure familiar from GDPR’s Article 27 representative requirement and from product-safety regulations more broadly: the EU wants a legally reachable entity inside its jurisdiction even when the underlying company has no physical presence there.

Deployers are not passive users, Article 26 gives them their own binding duties

The single most common misunderstanding among businesses evaluating their AI Act exposure is the assumption that “we just bought a tool, we didn’t build one” is itself a compliance answer. It is not. A deployer is any natural or legal person, a company, a public authority or another body, that uses an AI system under its own authority, except where the use is a purely personal, non-professional activity, and buying, licensing or otherwise putting a high-risk AI system to work makes an organisation its deployer, with a distinct set of obligations separate from, and additional to, the provider who built it.

Article 26 sets out that deployer duty set in detail, and its structure is worth understanding obligation by obligation because most enterprise AI risk sits here, in procured tools, not in internally built models. Deployers must take appropriate technical and organisational measures to ensure they use the high-risk AI system in accordance with the provider’s instructions for use, and must assign human oversight to persons who possess the necessary competence, training, and authority to intervene, pause, or override the system’s outputs. The oversight duty is not satisfied by nominating someone on an org chart; the Act requires that the person actually holds the authority and the support needed to act on that oversight in practice, and explicitly prohibits pressure to ignore or bypass those oversight mechanisms.

Monitoring and record-keeping form the operational core of Article 26. Deployers must retain automatically generated logs for an appropriate period, generally at least six months, monitor operation, inform the provider or distributor and suspend use if risk emerges, and report serious incidents. For sectors like banking, this converts into concrete practice: a bank deploying a third-party credit-risk model must preserve automated decision logs for at least six months and ensure they remain accessible for audit or regulatory inspection.

Two further Article 26 duties deserve specific attention because they surface most often in employment contexts, which is one of the highest-traffic high-risk categories under Annex III. Before putting a high-risk AI system into service at the workplace, deployers who are employers must inform workers’ representatives and the affected workers that they will be subject to its use, in accordance with applicable Union and national law on information of workers and their representatives. And separately, deployers must meet transparency duties toward affected individuals, including disclosing AI use, deepfakes, and emotion recognition where required, and must stand up a right-to-explanation process for people affected by decisions the system produces.

The line between deployer and provider is not fixed once a contract is signed. A deployer who makes a “substantial modification” to a high-risk AI system acquires all the obligations of a provider, including conformity assessment, CE marking, and the full technical documentation burden; substantial modification includes fine-tuning a model on your own data in a way that shifts its capabilities significantly, adding new use cases not covered in the provider’s instructions, or integrating the system into a larger pipeline that materially changes how it functions. This is a live risk for exactly the kind of customization that makes an off-the-shelf tool useful: a company that takes a vendor’s HR screening model and retrains it on its own historical hiring data has very plausibly crossed into provider territory, whether it intended to or not.

Article 26 does not carve out an SME exemption. Article 26 does not provide a general exemption for SMEs, although the Act includes supportive measures and potentially lighter obligations for small and medium-sized enterprises depending on their role in the AI value chain. The obligations attach regardless of company size; what differs for smaller companies is the fine calculation, covered later in this piece, and access to support structures like the regulatory sandbox.

Importers and distributors inherit obligations they rarely expect

Two further actor categories round out the value-chain structure, and both matter more than their names suggest to any EU-based company that resells or distributes AI-enabled products built elsewhere.

An importer, under the Act, is the entity established in the Union that places on the market an AI system bearing the name or trademark of a company established outside the Union. Before doing so, importers must verify that the provider has carried out the required conformity assessment, that the technical documentation exists, that the CE marking is affixed, and that the system is accompanied by the required instructions for use. If an importer has reason to believe a system does not conform, it must not place it on the market until conformity is achieved, and must inform the provider and the relevant market surveillance authority.

Distributors, defined as any entity in the supply chain other than the provider or importer that makes an AI system available on the Union market, carry a lighter but still real duty: before making a system available, they must verify that it bears the required CE marking, that it is accompanied by the required documentation and instructions for use, and that the provider and importer, where applicable, have complied with their respective obligations. Distributors that identify non-conformity must likewise take corrective action or withhold the system from the market.

For a marketing agency or systems integrator that packages a third-party AI tool into a client-facing product without modification, the distributor obligations are usually the relevant frame rather than the provider ones, provided no substantial modification and no rebranding under the agency’s own name has occurred. The moment either of those two things happens, the analysis shifts back to the provider or deployer-as-provider scenarios described above.

Article 25 codifies exactly when that shift occurs, and it is worth reading in its own terms rather than through secondary summary, because the triggering conditions are specific rather than a general “if you touch it, you own it” principle. Any distributor, importer, deployer or other third party is considered to be a provider of a high-risk AI system, and becomes subject to the full Article 16 provider obligations, in specific circumstances defined by the Act, and once those circumstances occur, the provider that initially placed the AI system on the market or put it into service is no longer considered a provider of that specific system for the purposes of the Regulation. Critically, this shift does not sever the relationship between old and new provider entirely: the initial provider must closely cooperate with the new provider and make available the necessary information, and provide the reasonably expected technical access and other assistance required to fulfil the obligations set out in the Regulation, in particular regarding compliance with the conformity assessment of high-risk AI systems. In practical terms, a vendor whose contract silently omits this cooperation duty, or whose commercial terms treat model access as proprietary and non-transferable, can leave a rebranding or fine-tuning customer unable to actually complete the technical documentation and conformity assessment that Article 25 now makes that customer solely responsible for. Reviewing vendor contracts for this specific cooperation clause, not just for general liability or indemnification language, is one of the more overlooked items in an otherwise conventional AI procurement checklist.

Extraterritorial reach means location in Bratislava or Boston changes nothing

If there is one fact that changes how a business should read every subsequent section of this article, it is this: the AI Act does not care where a company is headquartered. The act has extraterritorial reach, and US companies providing AI systems to users in the European Union are in scope regardless of physical presence in the EU.

The statutory language is precise on this point. The AI Act applies to providers placing on the market or putting into service AI systems, or placing on the market general-purpose AI models, in the EU, irrespective of whether the providers are established or located within the EU or not; to deployers of AI systems that have their place of establishment in the EU or that are located within the EU; and to providers or deployers of AI systems that have their establishment or location outside the EU where the output produced by the AI system is used in the EU.

That final clause, “output… used in the EU,” is the one with the widest practical reach, because it does not require the provider to have sold, marketed, or targeted the EU at all. The operative question is not where a company is incorporated, it is whether its AI outputs reach EU users, and that includes US businesses with no EU office, no EU employees, and no formal EU presence. A San Francisco startup whose API is called by a European customer’s application, producing outputs a person in Berlin or Bratislava then sees or acts on, is within scope on that basis alone.

For general-purpose AI model providers specifically, the extraterritorial logic is the same and the practical consequence is the same authorised-representative requirement described above. The AI Act has broad extraterritorial reach, applying to providers and deployers of GPAI models and AI systems located within the EU, providers outside the EU that place GPAI models or AI systems on the market in the EU, providers outside the EU that put AI systems into service in the EU, and providers and deployers of AI systems outside the EU when the system’s output is used inside the EU.

Two consequences follow for any business, EU-based or not, evaluating exposure. First, “we don’t sell into Europe” is not the same question as “does our output reach anyone in Europe,” and the second question is the legally relevant one. Second, a company that is purely a downstream deployer of someone else’s foundation model, with no EU establishment, can still find itself squarely inside the deployer obligations of Article 26 the moment its own use of that model, wherever the company itself sits, produces outputs used by people inside the Union.

Four risk tiers replace a single one-size-fits-all rulebook

Having established who counts as an actor and where the geographic line sits, the next question is what obligations actually attach, and that depends entirely on risk classification. The AI Act takes a risk-based approach: different requirements apply according to the level of risk an AI system poses, across four tiers: unacceptable, in which case AI systems are prohibited; high risk, in which case AI systems are subject to extensive requirements; limited risk, which triggers only transparency requirements; and minimal risk, which does not trigger any obligations.

Most of the Act’s substantive text addresses high-risk AI systems specifically, since these are the systems regulated in the greatest depth; a smaller section handles limited-risk systems, subject to lighter transparency obligations under which developers and deployers must ensure end-users know they are interacting with AI, such as with chatbots and deepfakes; and minimal risk is left largely unregulated, covering the majority of AI applications on the market, from spam filters to AI-enabled video games. The bulk of compliance effort, cost, and legal risk concentrates in the high-risk tier, which is why the sector-specific detail later in this piece focuses there.

It is worth being precise about what “risk tier” means procedurally, because it is not a self-assessment exercise done once and forgotten. Classification happens at the point a system is designed for a particular intended purpose, and a system’s tier can shift if that intended purpose changes, if a deployer substantially modifies it, or if the Commission itself amends Annex III through a delegated act, a power it retains under Article 7 and exercises subject to periodic review.

This point about shifting classification deserves emphasis because it cuts against the intuitive assumption that a risk tier, once assigned, is a fixed label a company can file away. A minimal-risk internal analytics tool that a company later repurposes to screen job applicants does not carry its original “minimal risk” classification into that new use; the classification attaches to intended purpose, not to the underlying technology, so the same piece of software can be minimal risk in one deployment and high-risk in another, entirely depending on what a company decides to use it for. This is precisely why the actor-role and inventory work described later in this piece needs to be revisited whenever an existing tool is repurposed for a new business function, rather than treated as a one-time classification exercise performed only when a tool is first procured.

Eight practices the AI Act bans outright, with no exceptions for good intentions

At the top of the risk pyramid sits a short, absolute list. Unlike every other classification in the Act, prohibited practices carry no conformity-assessment escape route and no grandfather clause. There is no grandfather clause for prohibited practices; unlike some high-risk provisions with transitional arrangements, Article 5 applies to all AI systems regardless of when they were placed on the market. These bans have applied since 2 February 2025, are unaffected by the Digital Omnibus, and remain the earliest and most stable part of the entire regulation.

Article 5(1) lists eight prohibited practices: subliminal or purposefully manipulative or deceptive techniques that materially distort behaviour to cause significant harm; exploiting vulnerabilities of a person or group based on age, disability, or social or economic situation; public-authority social scoring based on social behaviour over time, where scoring leads to detrimental or unjustified treatment in unrelated contexts; individual criminal-offence risk assessment based solely on profiling or personality traits, without human assessment based on objective, verifiable facts; untargeted scraping of facial images from the internet or CCTV to build or expand facial recognition databases; emotion inference in workplaces and educational institutions, subject to narrow medical or safety exceptions; biometric categorisation systems that infer sensitive attributes such as race, political opinion, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation; and real-time remote biometric identification in publicly accessible spaces for law enforcement purposes, subject to narrow, judicially authorised exceptions.

Two of these deserve elaboration for the business audience most likely to encounter them without realizing it. The vulnerability-exploitation prohibition, Article 5(1)(b), is not limited to obviously predatory schemes; the Commission’s own example is an AI system embedded in a mobile game that uses subliminal visual or audio patterns to influence children’s purchasing behaviour without their awareness, which places a meaningful slice of gamified marketing and in-app monetization design squarely in scanning range of this prohibition. The emotion-recognition ban, similarly, reaches recruitment technology directly: a video interview platform that analyses facial expressions, vocal tone, or body language to assess candidates is prohibited outright, and companies should strip any emotion inference features from recruitment AI immediately, along with reviewing employee monitoring systems for social scoring characteristics to ensure performance metrics are based on work outputs rather than behavioural profiling.

Enforcement here is already live and moving. In early 2026, the European Commission launched its first formal investigations into potential prohibited AI practices under Regulation (EU) 2024/1689, confirming that this earliest tranche of the Act is not a dormant legal theory but an active enforcement front, well ahead of the high-risk deadline that dominates most compliance planning.

Two guidance points worth noting for anyone assessing whether a system falls into this list. The European Commission has published a comprehensive document outlining AI practices considered unacceptable, interpreting the prohibitions in a balanced manner intended to protect fundamental rights and safety while still fostering innovation and providing legal clarity, and covering the open-source exclusion under Article 2(12) as well as the material scope of “placing on the market,” “putting into service” and “use.” And unlike the fixed list in most product-safety law, this one is designed to move: the European Commission will assess the need to amend the list of prohibited practices once a year and share its findings with EU lawmakers under Article 112.

Annex III turns eight sectors into automatic high-risk classification

Below the prohibited tier sits the high-risk category, and this is where Annex III does the practical work of telling a business whether its specific use case is caught. A system falls under Annex III when it is one of eight listed use-case categories, covering biometrics, critical infrastructure, education and vocational training, employment, essential services, law enforcement, migration, or administration of justice, and performs the specific function that category’s text describes. Both conditions have to be met: the sector and the specific function within it.

Annex III is the definitive reference list of high-risk AI use cases, the eight sectors where AI deployment triggers the Act’s most demanding compliance obligations, and any AI system falling within an Annex III category carries the heaviest compliance obligations for both the provider and the deployer. The classification is not a suggestion or a risk-management best practice; it is a binding legal determination that pulls in the full Article 16 provider obligation set and the full Article 26 deployer obligation set described earlier in this piece.

There is a limited carve-out. Article 6(3) allows a provider to argue that a system listed in Annex III does not pose a significant risk of harm to health, safety, or fundamental rights, considering its intended purpose, output nature, and conditions of use, but the provider must document this assessment and notify the relevant market surveillance authority before placing the system on the market. Critically, this exception never applies if the system profiles natural persons, which eliminates the escape route for a large share of commercially deployed systems, since profiling individuals is precisely what most Annex III tools do.

The biometrics category, listed first in Annex III, is narrower than its name suggests and worth detailing precisely because so many commercial products brush against it without triggering it. Annex III covers, in so far as their use is permitted under relevant Union or national law, remote biometric identification systems, excluding AI systems intended to be used for biometric verification whose sole purpose is to confirm that a specific natural person is who they claim to be; AI systems intended to be used for biometric categorisation according to sensitive or protected attributes based on inference of those attributes; and AI systems intended to be used for emotion recognition. What falls outside this category is just as important as what falls inside it: standard facial recognition for device unlock, a one-to-one verification rather than remote identification, photo beauty filters, basic age-gate tools that do not categorise by sensitive attributes, and sentiment analysis of text, which analyses language rather than biometric data, are all excluded. The distinguishing line in practice is scale and cooperation: a login system that compares a face to a stored template for identity verification is not remote biometric identification unless it operates at scale on a population without their direct cooperation, and the scope only expands into high-risk territory once the system starts inferring attributes such as political opinion or sexual orientation.

Critical infrastructure, the second Annex III category, is defined by cross-reference to existing EU resilience law rather than by a fresh AI-specific definition. “Critical infrastructure” carries the meaning given to it in Article 2, point 4, of Directive (EU) 2022/2557, and Annex III itself limits the category to AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity. The crucial qualifier here is “safety component”: the AI system must directly affect the safe operation of the infrastructure in question, not merely support administrative functions around it, which means a utility’s AI-powered customer billing chatbot sits outside this category even though the utility itself operates critical infrastructure, while an AI system directly controlling grid load balancing or water treatment dosing sits squarely inside it.

Employment and recruitment tools face the most immediate high-risk exposure

Of the eight Annex III categories, employment is the one most business readers of this article are likely to touch directly, whether as an internal HR function or as a vendor selling into one. The employment category covers AI systems used in recruitment or selection of natural persons, including advertising vacancies, screening applications, evaluating and filtering candidates, in promotion and termination decisions, in task allocation, in monitoring and evaluating performance and behaviour, and in evaluating creditworthiness of persons for employment purposes.

This is the single largest concentration of enterprise AI risk anywhere in Annex III, because CV screening, applicant-tracking-system ranking, and performance-monitoring dashboards have become nearly ubiquitous corporate software over the past several years, often adopted without any formal AI Act risk review because the tools were procured as “HR software” rather than flagged internally as “AI systems.”

The obligations that attach are the full Article 16 and Article 26 sets described above, plus the workplace-specific worker information duty under Article 26(7). A recruiter using a third-party CV-ranking tool is a deployer; the vendor that built the ranking model is the provider; and if the recruiter’s HR team retrains the ranking weights on the company’s own historical hiring data to “improve accuracy,” that retraining plausibly converts the employer into a provider in its own right, with the full conformity-assessment and technical-documentation burden that status carries.

Task allocation and performance monitoring, the later stages of the employment lifecycle listed in Annex III alongside recruitment, deserve equal attention because they are frequently rolled out with even less formal AI Act review than hiring tools, precisely because they are marketed as productivity or workforce-management software rather than as HR technology. A logistics company using an algorithmic system to assign delivery routes and shifts to drivers, or a call centre using AI to score agent performance against call transcripts, sits inside the same Annex III employment category as a CV-screening tool, triggering the identical Article 16 and Article 26 obligation set, including the worker-notification duty and the human-oversight requirement discussed earlier. The commercial framing of these tools as operational efficiency software rather than as “AI in employment” is precisely the gap that leads many companies to miss this classification during procurement, since the internal purchasing decision is typically made by an operations team rather than HR, and neither team is necessarily the one running the AI Act risk review.

Credit scoring and insurance pricing carry obligations that survived every delay

If employment is the category most companies encounter without noticing, credit and insurance is the category where the Digital Omnibus changed the least, and that stability is itself the headline. Annex III covers AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud, as well as AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance.

Credit scoring AI and algorithmic lending decision tools are high-risk because they determine access to loans and essential services, and similarly, AI underwriting insurance that affects pricing could be high-risk under the essential-services category. This is precisely the pairing that Article 27 singles out for the Fundamental Rights Impact Assessment obligation described later in this piece, which makes credit and insurance one of the very few Annex III sub-categories where private-sector deployers, not only public bodies, face a mandatory pre-deployment fundamental-rights review regardless of the Digital Omnibus timeline changes.

Education, essential services and law enforcement complete the high-risk map

The remaining Annex III categories round out the picture, and each carries its own specific function test. The education and vocational-training category covers AI deciding school admissions, exam scoring, or job training outcomes; the essential-services category covers AI for social benefits, credit scoring, insurance, and healthcare triage; and the law-enforcement category covers AI for crime prediction, evidence evaluation, and polygraph or lie-detection tools.

The essential-services category further covers AI systems intended to evaluate and classify emergency calls by natural persons, or to be used to dispatch, or establish priority in the dispatching of, emergency first-response services, including police, firefighters, medical aid, and emergency healthcare patient triage. A municipal 112 dispatch system using AI to triage incoming emergency calls, in other words, sits inside Annex III on exactly the same legal footing as a bank’s credit-scoring model.

Every Annex III system inherits the full obligation set regardless of which of the eight sectors it falls into: Article 9 risk management, Article 12 logging, Article 13 transparency, Article 14 human oversight, and Article 26 deployer responsibilities all attach uniformly. The sector determines whether a system is caught; once caught, the compliance architecture is the same wherever the use case sits.

Because the Article 6(3) exception mentioned earlier is so frequently misunderstood as a broad opt-out, it is worth returning to it with the specific procedural detail a provider actually needs. The exception is available only where the system genuinely does not pose a significant risk given its intended purpose, the nature of its outputs, and its conditions of use, and the burden of proof sits with the provider, who must document the reasoning and notify the relevant market surveillance authority before the system reaches the market.

Deployers should escalate to the provider and, if unresolved, may need to notify market surveillance authorities, since operating without adequate Article 13 information creates compliance risk for the deployer as well. This means the exception cannot be invoked quietly and forgotten; it creates an ongoing paper trail that a national authority can, and under the Act’s transparency architecture is expected to, review.

Table one: the four risk tiers and what each one actually requires

Table 1. The four AI Act risk tiers, their trigger conditions, and the obligations each carries

This table matters because the four tiers do not share a single compliance deadline any longer. The Digital Omnibus decoupled the high-risk timeline from the transparency and prohibited-practice timelines, so a business can simultaneously be fully liable today for a prohibited-practice violation, obligated from 2 August 2026 for a transparency violation on the same product, and not liable until December 2027 for a high-risk violation on a different feature of that same product. Treating “the AI Act deadline” as a single date is the single most common planning error visible across current compliance commentary.

General-purpose AI models carry a separate obligation track of their own

Parallel to the risk-tier structure sits a distinct set of rules for general-purpose AI models, the foundation models that power everything from chatbots to coding assistants to image generators. A general-purpose AI model is defined in Article 3(63) as an AI model that displays significant generality and is capable of competently performing a wide range of distinct tasks. Providers of these models face obligations under Article 53 that apply regardless of which downstream application eventually uses the model.

Providers of general-purpose AI models must maintain technical documentation and make it available to authorities and to providers of AI systems who intend to integrate the model into their own systems; they must put in place a copyright policy and provide a public summary of training content; and open-source models are exempt from some of this documentation, unless they are classified as posing systemic risk. Downstream companies that build products on top of someone else’s foundation model are explicitly outside this specific obligation set. Downstream actors like system providers, deployers, importers, and so on are not subject to these GPAI obligations; rather, they should consider whether the risk-based obligations under Articles 5, 16 to 27 and 50 apply instead.

This is a genuinely useful piece of clarity for the many small businesses building applications on top of large commercial models: the heavy GPAI-specific documentation and copyright-policy burden sits with the foundation-model developer, not with every company that calls its API. What the downstream company inherits instead is the ordinary provider-or-deployer analysis described earlier in this piece, applied to whatever product it builds and however it uses the underlying model’s output.

One nuance affects companies that integrate a model deeply into their own branded product. A general-purpose AI model is also considered to be placed on the market if that model’s provider integrates the model into its own AI system which is made available on the market, unless the model is used for purely internal processes not essential for providing a product or service to third parties, the rights of natural persons are not affected, and the model is not a general-purpose AI model with systemic risk. The practical takeaway is that “internal tool” status is a genuine exemption path, but only if all three conditions hold simultaneously, and the moment the tool starts affecting people outside the company or touches a systemic-risk model, that exemption disappears.

This three-part test is worth applying concretely, because “internal” is a word companies use loosely and the Act does not. A company’s internal knowledge-base search tool, built on a foundation model and used only by employees to find internal documents faster, plausibly meets all three conditions: it is not essential to any product sold to third parties, it does not affect the rights of any natural person outside the company, and it does not rely on a systemic-risk model in any way that changes that analysis. The same foundation model, wired instead into a customer support chatbot answering client questions, fails the first condition immediately, because the tool has become essential to a service the company provides to third parties, regardless of how the company internally labels the project. The distinction that matters legally is not where the model runs or who built the interface around it, but whose rights are affected by its output and whether that output forms part of what the company actually sells or delivers externally.

Systemic risk providers face a second, heavier layer under Article 55

A small subset of general-purpose AI models carries additional obligations because of their scale and potential for widespread harm. Providers of general-purpose AI models with systemic risk must evaluate their models using standardised protocols, identify and reduce systemic risks, and report any serious incidents to the AI Office and national authorities, and must also ensure their AI models and infrastructure are secure.

Providers of GPAI models with systemic risk must assess and mitigate systemic risks, in particular by performing model evaluations, keeping track of, documenting, and reporting serious incidents, and ensuring adequate cybersecurity protection for the model and its physical infrastructure under Article 55. The classification threshold for “systemic risk” itself is defined by a computational scale test, and, according to the Commission’s preliminary guidelines, no publicly available model currently meets the modification threshold of one third of the GPAI model classification thresholds, which the Commission has read as confirming that downstream European industry is unlikely to be caught by this specific tier under current thresholds.

For the overwhelming majority of businesses this article addresses, systemic-risk obligations are simply not their concern; they belong to a handful of frontier AI labs. What matters practically for everyone else is understanding that this tier exists and operates on a separate enforcement track from both the high-risk Annex III rules and the general GPAI transparency obligations, which brings the discussion to how providers, of any size, are expected to demonstrate compliance in the absence of finished harmonised standards.

The Code of Practice turned a vague obligation into a concrete compliance route

Because Article 53 and Article 55 set out obligations in fairly abstract statutory language, the AI Office coordinated the development of a voluntary Code of Practice to give GPAI providers a concrete way to demonstrate compliance. The final version of the Code of Practice, covering transparency, copyright, and management of systemic risks for providers of GPAI models, was published on 10 July 2025.

The Code lays down a total of twelve commitments, one each for the transparency and copyright chapters, which apply to all GPAI model providers, and ten for the safety and security chapter, which applies only to providers of GPAI models with systemic risk, currently a small group of roughly five to fifteen companies worldwide. Signing is not mandatory, but the incentive structure makes non-signing materially more burdensome. Non-signatories must demonstrate compliance through alternative means, which requires building a bespoke compliance framework and explaining to the AI Office why that framework is equally robust to the Code’s requirements, and the AI Office has been explicit that non-signatories face a higher burden of proof.

Enforcement of these GPAI obligations follows its own two-stage timeline, distinct from the Annex III high-risk calendar. From 2 August 2025, the obligations for providers of GPAI models entered into application, but from 2 August 2026, the Commission’s enforcement powers enter into application, meaning the Commission can conduct audits, request access to models and documentation, issue corrective orders, and impose fines only from that later date. This one-year grace period between “the rule applies” and “the rule is enforced with penalties” gave the industry, and the AI Office itself, time to build out the compliance and evaluation infrastructure the Code describes before real financial consequences began attaching to it.

The three chapters of the Code translate into distinct, checkable commitments rather than a single general promise of good behaviour. Signatories commit to maintaining up-to-date, comprehensive documentation for every GPAI model distributed within the EU, except for models that are free, open-source, and pose no systemic risk, which operationalises the Article 53 transparency duty described earlier. The copyright chapter ensures alignment with EU copyright law, particularly the requirement for prior authorisation unless specific exceptions apply, such as text and data mining; signatories are required to develop and regularly update a robust copyright policy that clearly defines internal responsibilities, ensure that data collected via web crawling is lawfully accessible, respect machine-readable rights signals like robots.txt, and avoid accessing websites flagged for copyright infringement, with technical safeguards to minimise the generation of infringing content and terms of service that clearly prohibit unauthorised use. The safety and security chapter, reserved for systemic-risk providers, is the most operationally demanding of the three: to verify that security measures are effective, signatories must use independent external reviews where internal capacity is insufficient, conduct red-teaming to identify security gaps in networks and facilities, run bug bounty programmes for public-facing endpoints where appropriate, test insider mitigation protocols including personnel integrity assessments, facilitate issue reporting through secure third-party communication channels, monitor systems actively with intrusion detection, and respond rapidly to threats using trained security teams for incident handling and recovery.

Article 4 AI literacy has no fine of its own, yet it shapes every other penalty

Stepping back from the technical model-level rules to something that applies to literally every business using AI in any capacity, Article 4 imposes what is probably the most widely underestimated obligation in the entire regulation, precisely because it carries no standalone fine. Article 4 requires that providers and deployers of AI systems take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, education and training, and the context the AI systems are used in. This obligation has applied since 2 February 2025, the same date as the Article 5 prohibitions, and is fully live today.

No fixed curriculum exists, and none is coming. Neither the Act nor the European Commission has mandated any specific training content; organisations are expected to build their AI literacy actions based on the technical knowledge, experience, education and training of their staff, the context in which the AI systems are used, and the persons on whom the systems are used. This flexibility is deliberate rather than an oversight. The Commission’s approach to the AI literacy requirement is flexible, enabling organisations to take a proportionate approach to training staff and others using AI systems, rather than treating it as one more task to tick off a compliance to-do list.

What the requirement does insist on is genuine substance over box-checking. Simply relying on an AI system’s instructions for use, or asking staff to read them, is often ineffective and insufficient; Article 4 is intended to provide training and guidance appropriate to each target group’s level and type of knowledge, given the context and purpose of the AI systems in use, and there is no one-size-fits-all approach, since the AI Office does not intend to impose strict requirements or mandatory trainings.

The financial consequence, though indirect, is real and growing more visible as enforcement matures. No direct fines or sanctions apply for violating the AI literacy requirement itself, but from 2 August 2025, providers and deployers may face civil liability if staff who have not been adequately trained cause harm to consumers, business partners, or other third parties through AI misuse, even though no direct fine attaches to Article 4 on its own. More significantly for enforcement practice, a lack of AI staff training or guidance will likely be treated by regulators as an aggravating factor in wider enforcement actions for other breaches of the Act, which is probably more likely in practice than standalone enforcement of the literacy requirement itself.

Practical scope for this training is broader than most companies initially assume, precisely because it does not attach only to formally classified high-risk systems. All staff need a minimum level of literacy covering what AI is, what its risks are, what the regulations say, and what internal usage policies are; this training does not need to be long, four to six hours is usually enough for the baseline level, but it must be practical, use real cases, and be adapted to the sector, since a generic introductory AI course does not meet Article 4 requirements if it fails to address risks and the regulatory framework specifically. Role-specific depth then layers on top: AI deployment managers, technical teams and the executive team need additional, specific training, with technical staff needing to understand risk assessments and technical documentation, leadership needing to understand legal responsibilities and oversight duties, and departments like HR, legal or customer service that use AI intensively needing training specific to the risks in their area.

There is also a Shadow AI dimension worth flagging for any business assuming a formal AI usage ban solves the problem. Given the prevalence of generative AI usage in everyday life and popular recommendations to use it for work tasks such as adjusting email tone, it is important that all staff are aware of the risks of AI and the dos and don’ts of using it for work, and even organisations that ban AI use for work purposes typically still see it occur on employees’ personal devices, making Shadow AI potentially more risky than sanctioned use, and a reason to include everyone in an AI literacy program regardless of official policy.

Transparency duties under Article 50 turn chatbots, deepfakes and AI text into disclosures

Sitting in the limited-risk tier, but affecting a strikingly broad swath of ordinary commercial activity, are the transparency obligations of Article 50. These are the rules that determine when a business must simply tell people they are dealing with AI, without triggering the heavier high-risk machinery.

Article 50 establishes four transparency obligations addressing different actors along the value chain: providers of AI systems intended for direct interaction with persons must design those systems so users are informed of the artificial, non-human nature of the interaction; providers of systems generating synthetic audio, image, video or text content must ensure outputs are marked as artificially generated or manipulated in a machine-readable format; deployers of emotion-recognition or biometric-categorisation systems must inform exposed persons of the system’s operation; and deployers of deepfakes, and of AI-generated text published to inform the public on matters of public interest, must disclose the artificial origin of the content.

The carve-out for editorially reviewed content is narrow and worth flagging specifically for any publisher, agency, or content team assuming a light human pass exempts them. The exception for editorially reviewed AI text is narrow: simply having a human “check” AI-generated content is not sufficient, and only genuine, substantive editorial oversight with clear accountability qualifies for exemption from the labelling obligations.

Practical scope-mapping matters here because the same organization is frequently both a provider for some systems and a deployer for others under this single article. A focused compliance program should inventory every generative AI system a company provides or deploys in the EU, separate the two roles since different duties attach to each, and classify each system against Article 50: does it generate synthetic media, triggering the marking duty; does it power a chatbot or interactive assistant, triggering disclosure; does the company publish its deepfake output or public-interest text, triggering labelling.

For any business that publishes AI-generated content, the practical first step is to inventory content production workflows, identify where AI-generated content is published externally across website, social media, marketing materials, or reports, plan disclosure from the outset for deepfake imagery, audio or video, and assess for text whether it is published to inform the public on matters of public interest and whether the human-review and editorial-responsibility carve-out genuinely applies.

The Article 50 timeline itself illustrates the same staggered-date pattern seen elsewhere in the regulation. Article 50 transparency obligations were originally scheduled to apply from 2 August 2026, but timing relief has since firmed up: the Digital Omnibus package gives providers of generative AI systems already on the market until 2 December 2026 to meet the specific Article 50(2) machine-readable marking duty. That relief is route-specific rather than blanket: it covers certain synthetic-content systems already placed on the market before 2 August 2026, while the general chatbot-disclosure and deepfake-labelling duties still land on the original 2 August 2026 date.

This transparency regime is also extraterritorial in exactly the way the earlier scope discussion described. The draft guidelines give worked examples confirming that a third-country provider of a generative AI system is subject to the marking duty where the system’s outputs are intended for use in the EU, and a third-country advertiser using an AI-generated deep fake of a celebrity in an advertisement displayed in the EU is a deployer within scope. An agency producing AI-generated marketing visuals for a client whose ads run in EU markets cannot treat its own location as a reason to skip the Article 50 disclosure analysis.

The Commission has continued refining implementation support through 2026 rather than leaving the statutory text to stand alone. On 10 June 2026 the Commission published the final Code of Practice on marking and labelling AI-generated content, developed through a multi-stakeholder process involving more than 180 participants and six independent experts appointed by the AI Office, though signing that Code reduces administrative burden without guaranteeing compliance, since market surveillance authorities remain competent to assess Article 50 compliance independently regardless of signatory status.

The Digital Omnibus rewrote the calendar three weeks before the old deadline

Return now to the political story that made this the right moment to publish an article like this one. The Digital Omnibus process began in earnest well over a year before its conclusion, and tracking its progress matters because so much secondary commentary written earlier in 2026 describes the delay as merely proposed, when as of the date of this article, it is settled law.

The Omnibus proposal was framed around deferring the AI Act obligations for high-risk AI systems from August 2026 until such later date when measures to support compliance, such as harmonised standards, common specifications, and Commission guidelines, are available, published by the Commission on 19 November 2025. The initial mechanism proposed was conditional rather than a fixed date: the Commission proposed that the high-risk rules would only apply once it adopted a Decision confirming completion of the standards work, with a six-month transition period for Annex III systems and twelve months for Annex I systems after that, with a backstop in case no such Decision was made, setting the latest application dates at 2 December 2027 for Annex III and 2 August 2028 for Annex I.

That conditional structure did not survive negotiation. The final position removed the conditionality: application dates are no longer linked to standards completion and will simply apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. This is a materially different outcome from what was floated in late 2025, and it matters for any compliance team that built its roadmap around the earlier, more contingent version of the proposal: the dates are now fixed, not conditional on standards readiness, which removes both the risk of a further slip and the possibility of an earlier-than-expected activation tied to faster-than-anticipated standards work.

The negotiation itself moved in fits and starts through the first half of 2026. The second political trilogue between the European Parliament, the Council of the EU, and the European Commission on 28 April 2026 ended without agreement, a genuine risk point at which the original 2 August 2026 deadline might have simply arrived unchanged. Political agreement was finally reached on 7 May 2026, followed by a further stretch of formal ratification: on 16 June 2026, the European Parliament formally endorsed the provisional agreement reached in May, and on 29 June 2026, the Council of the EU gave its final green light to the AI Act simplification package.

Regulation 2026/1744, what actually changed and what stayed exactly the same

The formal legislative text that resulted carries its own citation and its own precise entry-into-force date, both worth recording accurately given how much secondary commentary still refers to the changes as pending. Regulation (EU) 2026/1744 of 8 July 2026, amending Regulation (EU) 2024/1689 together with Regulations (EU) 2018/1139 and (EU) 2023/1230, was published in the Official Journal of the European Union on 24 July 2026, entering into force on the third day following publication, 27 July 2026. The legislator provided for entry into force “as a matter of urgency” on that accelerated third-day schedule given the proximity of the 2 August 2026 deadline it was amending.

The substantive changes worth internalizing fall into three groups. First, the timeline deferrals already described: the most consequential change is a delay to the application of the high-risk AI rules; the original AI Act set 2 August 2026 as the general application date, including for standalone high-risk AI systems listed in Annex III, covering areas such as employment, education, critical infrastructure, law enforcement and credit scoring, and the Digital Omnibus resolves this by deferring the stand-alone high-risk AI obligations to 2 December 2027, while for AI systems embedded in products already subject to EU product safety legislation listed in Annex I, such as medical devices, machinery or toys, the deadline shifts further to 2 August 2028.

Second, a new prohibition was added to the fixed Article 5 list, expanding it beyond the original eight practices described earlier. A new prohibited AI practice was introduced relating to AI systems used for creation of non-consensual sexual and intimate images and child sexual abuse material, applicable from 2 December 2026, prohibiting the placing of such AI systems on the EU market and their use. This “nudifiers” and CSAM prohibition sits alongside the pre-existing eight practices in Article 5 of the AI Act.

Third, watermarking and content-marking transition relief, already covered above in the Article 50 discussion, along with expanded AI Office supervisory powers. An authority empowered to seal premises, to impose daily penalties of up to five percent of worldwide turnover, and to act within a five-year limitation period is a materially strengthened enforcement instrument compared to the Act’s original architecture, though the resources clause supporting that authority remains subject to the ordinary budgetary procedure rather than a guarantee. One further, more symbolic addition is worth noting for anyone tracking where EU law is heading on autonomous AI specifically: in Annex XIV, in a table of administrative codes intended for notified bodies, EU law names agentic AI for the first time, without defining, regulating, or classifying it, merely acknowledging that it exists and will require its own assessment competences, a first textual foothold for future rulemaking.

Fourth, and easy to overlook amid the high-risk headline, SME relief was folded into the same package. Relief for SMEs and small mid-caps means companies with fewer than 750 employees and €150 million turnover will benefit from lighter technical documentation requirements for high-risk AI systems.

What stayed exactly the same is arguably the more important message for a business trying to plan around this. August 2 is not cancelled: transparency rules still land on that date, even as the Digital Omnibus defers the AI Act’s high-risk obligations to 2027 and 2028; the temptation is to read the delay as a reprieve and stand down, and that reading is wrong on the facts and the strategy. The pre-existing Article 5 prohibitions, the general-purpose AI rules, and the Article 50 transparency duties keep their original schedule, meaning the new consolidated calendar reads: 2 August 2026 for general application and transparency, 2 December 2026 for the new intimate-imagery and CSAM prohibition and the content-marking transition, 2 December 2027 for Annex III high-risk systems, 2 August 2028 for Annex I embedded systems, and 2 August 2030 for pre-existing high-risk systems used by public authorities.

The general-purpose AI model track, discussed earlier in this piece, runs on its own separate calendar that the Digital Omnibus left untouched, and is worth setting out in one place for anyone trying to reconcile it against the newly amended high-risk dates above.

Table 2. GPAI obligation tiers and their applicable dates

The table illustrates a pattern that recurs across the entire Act, and that the Digital Omnibus did nothing to change for GPAI models specifically: a rule can be legally binding on one date and functionally unenforced until a later one, a gap that companies without dedicated regulatory counsel routinely misread as “we have more time” when the correct reading is “the obligation already exists, only the penalty machinery is delayed.”

Civil society and industry read the same delay in opposite ways

No account of the Digital Omnibus is complete without the political argument that surrounded it, because that argument shapes how aggressively national authorities are likely to enforce the parts of the Act that did not move, and because a business reading only the industry-friendly coverage of the delay risks underestimating the fundamental-rights scrutiny still very much alive around it.

Digital rights organisations were unambiguous in their opposition from the moment the proposal appeared. 133 civil society organisations and unions urged the European Commission to halt its planned Digital Omnibus, warning that the proposals would weaken core EU laws like the GDPR and AI Act, and describing the package as representing the biggest rollback of digital rights in EU history. Civil society, alongside the European Data Protection Supervisor and the European Data Protection Board, highlighted that the proposal risked weakening fundamental rights, reducing transparency, and undermining accountability across the GDPR, ePrivacy rules, and the AI Act, with the accelerated timeline, lack of evidence-based impact assessments, and deregulatory approach potentially leading to intrusive data collection, profiling, and discriminatory outcomes.

The final agreement did not resolve that criticism. The final agreement significantly weakens several important safeguards in the AI Act, and the delay of application, especially for high-risk systems, means those systems can continue operating without adequate safeguards; there are already known cases with terrible consequences, leaving people exposed to errors, bias, and discrimination for far longer than civil society organisations consider acceptable. On 16 June, the European Parliament adopted the AI Omnibus by a large majority of 423 votes in favour, in a text that critics argue will weaken AI Act protections, delay enforcement of key provisions, and empower industry actors, part of a wider deregulatory trend in which Omnibus proposals amend multiple laws at once, at speed, and without a full impact assessment.

One specific transparency provision became a flashpoint during negotiation and illustrates how granular this fight became. An early Omnibus draft would have deleted a registration requirement entirely, the equivalent of removing the requirement for food companies to list ingredients, since it allows journalists, researchers, and civil society to investigate AI providers and deployers; that deletion was mostly stopped in the final text, though civil society groups continued to flag it as one of several near-misses. Reviewers specifically noted the surviving registration obligation for providers who rely on Article 6(3) to classify systems as “not high-risk,” treating its survival as one of the few genuine wins civil society secured in the final package.

Industry associations tell a very different story about the same text. Major German and European business associations, including EuroCommerce, BDI, Bitkom and VDMA, broadly welcomed the political agreement on the AI Omnibus package, describing it as a step toward greater legal certainty, reduced double regulation and a more innovation-friendly framework for industrial AI, while still warning that important ambiguities remain, particularly around overlaps with sectoral legislation, implementation timelines, and regulatory fragmentation across the single market. Global tech trade association ITI welcomed the delay of key high-risk AI obligations as well as the agreement to address duplicative regulation for industrial AI, calling the high-risk delay and the streamlining of industrial AI rules welcome and necessary steps, while arguing the agreement still does not fully address important challenges around tight deadlines for watermarking and labelling and continued regulatory overlaps.

The gap between these two readings traces back to a genuinely contested policy question that predates this specific Omnibus by years. The proposal sits within a wider push tied to Mario Draghi’s September 2024 report on EU competitiveness, which delivered a stark diagnosis that the productivity gap between the EU and the US is largely explained by the tech sector, with only a handful of the world’s top fifty tech companies based in Europe, and the more fundamental question raised even by supporters of simplification is whether tidier rules will actually sharpen EU competitiveness, since simplification is not the same thing as substantive reform.

Procedural critics add a further layer to this disagreement, arguing the problem is not only the substance of the changes but how quickly they moved. Despite the far-reaching consequences of the proposed amendments in both the AI and Data Omnibus, the Commission did not present a proper justification of how the changes would affect fundamental rights or clear evidence that they were necessary, and did not conduct a robust stakeholder consultation; when preparing the package, the Commission organised so-called reality-check meetings that primarily invited the private sector, leaving out civil society and other public-interest actors.

For a business reading this piece to plan its own compliance calendar, the practical upshot of this ongoing dispute is not that the legal deadlines are uncertain, Regulation (EU) 2026/1744 is now settled law with the dates set out earlier in this piece, but that the political temperature around AI Act enforcement remains genuinely high. National authorities operating in this climate, and a European Parliament that adopted the delay by a large majority while several of its own members and committees voiced open reservations, are unlikely to treat the parts of the Act that did not move, the Article 5 prohibitions, the Article 4 literacy duty, and the Article 50 transparency rules, as areas for lenient enforcement. If anything, sustained civil-society pressure around the high-risk delay makes early, visible compliance with the provisions still on schedule for August 2026 a more valuable signal to regulators than it might otherwise have been.

Other jurisdictions are writing their own rulebook alongside the EU’s

No business operating across multiple markets can treat the EU AI Act as the only relevant AI law, and understanding how it compares to the patchwork emerging elsewhere clarifies both what makes the EU’s approach distinctive and where a company’s compliance work can, and cannot, be reused across jurisdictions.

The 2026 AI regulatory landscape splits into three broad postures: the EU’s binding, risk-tiered law; a US federal approach favouring light-touch rules and preemption of state law; and active US state legislation filling the gap the federal government has left open. The EU AI Act is a single, horizontal regulation governing all AI systems across all sectors, using risk-based classification, binding obligations, and enforceable penalties up to €35 million or 7% of turnover, applying directly in all 27 member states without national transposition, built on a philosophy of regulating the technology itself based on risk regardless of sector; no equivalent single federal AI law exists in the United States, which instead relies on federal guidance such as the NIST AI Risk Management Framework, executive orders, sector-specific agency guidance from bodies like the FTC, FDA, EEOC and CFPB, and a growing patchwork of state-level legislation.

Colorado supplies the closest US analogue to the EU’s approach, and its rocky path through 2025 and 2026 illustrates a broader lesson about how hard risk-based AI regulation is to implement even for a single, comparatively narrow jurisdiction. The Colorado Artificial Intelligence Act adopts a risk-based approach to AI regulation that shares some similarities with the EU AI Act, and was the first comprehensive state law of its kind in the United States, potentially spurring other states to adopt similar legislation and creating a patchwork of state AI laws absent any omnibus federal regulation. The law places obligations on deployers and developers of high-risk AI systems to protect state residents from algorithmic discrimination in the context of employment, education, financial services, government services, healthcare, housing, insurance, or legal services, a sector list that overlaps substantially with Annex III but is not identical to it.

The differences between the two frameworks are as instructive as the similarities. The Colorado AI Act is similar to the EU AI Act in applying a risk-based approach to regulating AI and requiring assessment and management of AI risks, but differs in having a more limited territorial scope and in imposing more extensive requirements specifically on deployers of high-risk AI systems. The EU AI Act empowers national supervisory authorities to enforce its provisions, with significant penalties of up to €35 million or 7% of total worldwide revenue for non-compliance, a divergence in enforcement mechanisms from Colorado’s more consumer-protection-oriented framework that reflects the differing regulatory traditions the two frameworks emerged from. The EU AI Act also has a broader territorial scope, extending its reach to developers and deployers outside the EU if their AI systems are available on the EU market or their outputs affect EU residents, a key difference reflecting the EU’s global regulatory ambitions compared to Colorado’s more localised scope.

Even this closest US analogue to the EU model has proven politically unstable in ways that echo the EU’s own Digital Omnibus experience, if on a smaller scale. Colorado positioned itself at the frontier of AI governance, drawing from international models such as the EU AI Act and from privacy frameworks such as the 2018 California Consumer Privacy Act, but less than a year after Governor Jared Polis reluctantly signed the law, he was supporting a federal pause on state-level AI laws, and Colorado lawmakers delayed the law’s enactment while seeking to repeal and replace portions of it, facing pressure from the tech industry, lobbyists, and concerns about the practical cost of implementation. On 17 March 2026, the Colorado AI Policy Work Group, with strong support from Governor Polis, proposed a new framework to replace the original Act, shifting away from the OECD-aligned, EU-styled AI system definition described earlier in this piece toward more common US regulatory terminology.

The practical consequence for any business operating in both markets is a genuinely fragmented compliance landscape rather than one law with a smaller regional cousin. A single AI system can fall under the EU AI Act because it touches the EU market, under US state laws because of where its users live, and under evolving US federal policy at the same time; compliance is no longer a checklist against one rulebook, but the ability to satisfy several rulebooks with one well-governed program, and to show that work when any regulator asks. California illustrates the same fragmentation on a smaller geographic scale within the US itself: California has taken a fragmented, multi-bill approach rather than passing a single comprehensive act, including an AI Transparency Act requiring providers of generative AI systems with over one million monthly users to disclose AI interaction and offer free detection tools, alongside separate requirements for developers to publish training-data summaries and Civil Rights Department regulations restricting discriminatory AI use in employment decisions.

For a Slovak or other EU-based company whose work reaches US clients or US-based end users, the sensible posture is not to treat the EU AI Act analysis in this piece as a complete compliance answer, but as the most demanding and most stable single reference point currently available, one against which US state-specific gaps, chiefly around consumer notice rights and algorithmic discrimination assessments in employment and credit, can then be layered as an addition rather than a wholesale separate framework.

Provider obligations under Article 16 turn compliance into a paper trail

Returning now to the operational detail a provider of a high-risk system will actually need once the December 2027 or August 2028 deadlines arrive, or sooner for any provider choosing to prepare early given the sandbox and standards work already underway, Article 16’s obligation list translates into a sequence of concrete deliverables rather than an abstract legal duty.

Providers demonstrate compliance by performing official conformity assessments and preparing an EU declaration confirming conformity, and must attach a CE marking on the AI system or its packaging to show it meets all required standards set by the Act; they must also maintain detailed technical documentation and store the logs the system automatically generates during operation, records that help authorities monitor safety and compliance and ensure providers continually manage quality and address issues promptly. A further, frequently overlooked requirement folds in existing EU accessibility law: providers must ensure their high-risk AI systems meet accessibility requirements in accordance with Directives (EU) 2016/2102 and (EU) 2019/882, meaning accessibility compliance work already underway for other reasons can, and should, be coordinated with AI Act documentation rather than treated as a separate track.

Article 16(a)’s opening requirement, that the system comply with “the requirements set out in Section 2,” is easy to read past, but Section 2 is where the substantive engineering and governance work actually lives, spanning Articles 9 through 15. Article 9 requires that a risk management system be established, implemented, documented, and maintained for the high-risk AI system, not as a one-off pre-launch checklist but as a continuous, iterative process running throughout the system’s entire lifecycle and subject to regular review and updating; testing forms a formal part of this process, run throughout development and, in any event, before the system is placed on the market, against pre-defined metrics and thresholds appropriate to its intended purpose. That risk management process must give specific consideration to whether the system is likely to adversely affect persons under eighteen and, as relevant, other vulnerable groups, a requirement that connects directly back to the Article 5 vulnerability-exploitation prohibition discussed earlier in this piece, though applied here as an ongoing design discipline rather than an absolute ban.

Article 14’s human oversight requirement supplies the operational content behind the Article 26 deployer oversight duty described earlier, and is worth reading in the provider’s own words rather than only through the deployer’s downstream implementation of it. Article 14 establishes the principle of human agency and oversight as a cornerstone of trustworthy AI, requiring that AI systems be designed and implemented so they operate under meaningful human control, with individuals supervising the system able to understand its capabilities and limitations, intervene when necessary, and override its decisions to prevent or mitigate risk. The system must be provided to the deployer in a way that lets the person assigned oversight properly understand its relevant capacities and limitations, monitor its operation to detect anomalies and dysfunctions, and remain aware of the tendency toward automation bias, the risk of automatically relying or over-relying on the system’s output, particularly for systems used to provide information or recommendations that influence human decisions. This automation-bias language is directly relevant to the employment and credit-scoring use cases discussed earlier: a hiring manager who simply accepts a ranking tool’s shortlist without genuine independent judgment is precisely the failure mode Article 14 is designed to prevent, and a deployer’s human-oversight documentation should be able to demonstrate that the assigned overseer meaningfully exercises, rather than merely holds, that authority.

Article 10’s data governance requirement supplies the evidentiary backbone behind most of the fairness and non-discrimination concerns this piece has touched on in the employment and credit-scoring discussions. Article 10 requires organisations to document how training, validation, and testing datasets used in a high-risk AI system are sourced, evaluated for quality, and assessed for potential bias, grounded on the straightforward premise that an AI system can only be as trustworthy as the data it was built on. A recruiter deploying a CV-ranking tool cannot simply take the provider’s word that the underlying training data was bias-checked; Article 10 places the documentation burden for that data governance work on the provider in the first instance, but a deployer that later fine-tunes or retrains the tool, and thereby inherits provider status under Article 25 as discussed earlier, inherits this documentation burden along with it.

Record-keeping under Article 12, and the closely related documentation-retention duty under Article 18, add a time dimension to all of the above that is easy to underestimate when planning storage and archival systems. Documentation retention under Article 18 requires high-risk AI system providers to keep key records, technical documentation, quality management system records, and conformity declarations, for ten years after the system is placed on the market, a rule covering documentation and metadata rather than raw personal data, which must still be deleted sooner under the GDPR’s own storage limitation principle. Automatically generated logs under Article 12 must still be retained for an appropriate period even though these logs, ideally anonymised, follow a different retention logic than the ten-year documentation rule, meaning organisations need a genuinely blended data-retention strategy that reconciles the AI Act’s long documentation window with the GDPR’s shorter deletion cycles for personal data, rather than applying a single retention policy to everything an AI system touches. For any company building its documentation infrastructure from the ground up, this is a detail worth designing in from day one: separating personal training data, subject to GDPR’s shorter retention discipline, from the technical documentation and governance records that the AI Act expects to survive for a decade, avoids the far more expensive problem of untangling the two after the fact.

The final piece of Section 2, Article 15’s accuracy, robustness and cybersecurity requirement, closes the loop between the design-stage obligations described above and the ongoing operational reality of running a high-risk system in production. Providers must declare the levels of accuracy their system achieves, ensure it performs consistently across its lifecycle rather than degrading unpredictably, and build in resilience against both unintentional errors and, notably, deliberate attempts to manipulate the system’s behaviour or training data through adversarial inputs. For a bank or insurer running a credit-scoring model, this requirement connects directly to model-risk-management practices already familiar from prudential regulation, while for a smaller company deploying a lighter-weight tool, it typically translates into documented testing against defined accuracy thresholds before launch, plus a monitoring process capable of flagging performance drift once the system is live, rather than a one-time validation exercise treated as sufficient for the system’s entire operational life.

The conformity assessment path most companies will actually use

Conformity assessment sounds like a heavyweight external audit, and for some categories it is, but for the majority of Annex III systems the statutory default is closer to a documented self-declaration. For systems not subject to prior harmonisation legislation, meaning Annex III systems that are not medical devices, machinery or other regulated safety products, conformity assessment may be conducted by means of self-assessment by the provider, provided the required technical documentation is generated and the EU declaration of conformity is issued.

A narrower band of especially sensitive use cases requires independent verification instead. High-risk systems intended for remote biometric identification, and systems intended for use by law enforcement authorities, require conformity assessment by an external notified body; following assessment, the provider then registers the system in the EU AI database managed by the European Commission before deployment. For a marketing agency, an HR software vendor, or a fintech building a credit-scoring tool, self-assessment against documented technical criteria, not a third-party audit, is the applicable path in the large majority of cases, provided the underlying system is not also captured by pre-existing product-safety legislation like the Medical Devices Regulation or the Machinery Regulation.

Notified bodies themselves are not private certification firms operating on their own initiative; they are designated and supervised through a formal national process. A notifying authority in each member state, one of the two national competent authority types described earlier, evaluates a candidate conformity assessment body against defined criteria covering independence, technical competence, and organisational integrity before that body can be listed as a notified body authorised to assess high-risk AI systems in the narrower biometric and law-enforcement categories. Where a notified body is required, the assessment covers both the provider’s quality management system and its technical documentation, mirroring the structure long familiar from CE-marking regimes in other regulated product sectors, from medical devices to machinery, rather than inventing an entirely new certification architecture specific to AI.

Deployer obligations in practice, from human oversight to incident reporting

It is worth consolidating, in one place, the operational sequence a deployer of a high-risk AI system should expect to work through, because the obligations described earlier in Article 26 arrive in a rough chronological order rather than all at once. A structured deployer compliance program moves through obligation by obligation: identifying the responsible function within the organisation for each duty, the documentation to be produced, and the coordination points with related GDPR obligations, since Article 26 sits alongside the closely connected Article 27 fundamental rights impact assessment and Article 49(3) registration duties, which are operationally inseparable from a deployer’s compliance framework.

Before go-live, the practical sequence looks like this: a deployer must begin by thoroughly reading and implementing the provider’s instructions for use, since these become the compliance baseline; before going live, it must identify which staff member or team holds oversight responsibility and ensure they have the training and authority to intervene, pause, or override the system’s outputs, with pressure to ignore or work around oversight mechanisms explicitly prohibited. During operation, logging and monitoring take over as the ongoing compliance activity, and if the system begins producing unexpected outputs, or is involved in an incident causing or potentially causing harm, the deployer must escalate under the incident-reporting duties built into Article 26.

A structured internal timeline, distilled from the compliance checklists now circulating among EU law firms tracking this file, typically runs: classify AI systems, ensure AI literacy under Article 4, and begin training oversight personnel first; then conduct a data protection impact assessment and fundamental rights impact assessment where required, prepare information notices for affected workers or individuals, and establish monitoring and suspension protocols. Suspension is not a passive fallback either: Article 26(5) requires suspending use if deployment poses an unacceptable risk regardless of the provider’s compliance status, meaning a deployer cannot simply point to a compliant provider as a shield if its own use of the system, in its own specific context, produces unacceptable risk.

The Fundamental Rights Impact Assessment nobody outside public services expects to need

Article 27’s Fundamental Rights Impact Assessment deserves separate treatment because its scope is narrower and more specific than most of the general Annex III obligation set, and because private-sector companies frequently assume, wrongly, that it applies only to government bodies.

Article 27 requires specific deployers of high-risk AI systems to conduct a FRIA before first use, and three groups fall in scope: public bodies deploying any Annex III high-risk AI system except critical infrastructure; private entities providing public services deploying those same systems; and any deployer, public or private, using AI systems for creditworthiness evaluation or for life and health insurance risk assessment and pricing. That third category is the one private companies most often overlook: a private bank or insurer running a credit-scoring or life-insurance-pricing model is caught by the FRIA obligation on exactly the same footing as a government agency, regardless of its private-sector status.

The FRIA must be completed before deployment and includes assessing risks, affected groups, and mitigation measures to ensure responsible AI use, identifying how the AI system may affect individuals’ fundamental rights, including privacy, non-discrimination, and access to justice. Its relationship to the far more familiar GDPR Data Protection Impact Assessment is one of overlap rather than substitution. A DPIA conducted under Article 35 of the GDPR complements a FRIA conducted under the AI Act; a deployer may be deemed compliant with certain FRIA obligations that have already been satisfied through an existing DPIA, and organisations can combine FRIAs with existing DPIAs where genuine overlap exists, drawing on assessments already conducted by the provider and using the AI Office’s own template once published.

The specific content a FRIA has to cover is broader than a privacy assessment alone, which is the main reason the two documents cannot simply be treated as interchangeable. The FRIA must describe the deployer’s processes in which the high-risk AI system will be used, the affected persons and groups likely to be impacted, the specific risks to fundamental rights, and the mitigation measures the deployer intends to put in place; the deployer must then notify the market surveillance authority and provide the FRIA’s results before the system’s first use. A credit-scoring deployment, for instance, needs to address not only the data-protection dimension a DPIA would naturally cover, whether personal data is processed lawfully and proportionately, but also the distinct question of whether the scoring model’s outputs risk producing discriminatory access to credit for particular demographic groups, a fundamental-rights question that sits outside the GDPR’s own scope even when the two assessments are run in parallel.

The consequences of skipping this step are concrete rather than theoretical. If the assessment has not been completed, non-compliance carries fines of up to €15 million or 3% of global annual turnover, the same mid-tier fine band that applies to most other Article 26 and Article 16 violations, discussed in full in the penalties section below.

Three fine tiers turn abstract obligations into board-level financial risk

Every obligation described so far in this piece connects to a single enforcement article, and understanding its tiered structure is what turns a legal reading exercise into a board-level financial risk assessment. Non-compliance with the prohibition of the AI practices referred to in Article 5 is subject to administrative fines of up to €35,000,000, or, if the offender is an undertaking, up to 7% of its total worldwide annual turnover for the preceding financial year, whichever is higher.

A second, middle tier applies non-compliance with a broad list of operator and notified-body obligations, other than the Article 5 prohibitions, to fines of up to €15,000,000 or 3% of worldwide annual turnover, whichever is higher, covering provider obligations under Article 16, authorised representatives under Article 22, importers under Article 23, distributors under Article 24, deployer obligations under Article 26, and transparency under Article 50, among others. A third and lowest tier covers the supply of incorrect, incomplete or misleading information to notified bodies or national competent authorities in reply to a request, subject to fines of up to €7,500,000, or, if the offender is an undertaking, up to 1% of its total worldwide annual turnover, whichever is higher.

Crucially, this three-tier fine structure was never touched by the Digital Omnibus’s timeline changes. The Article 99 fines run in three tiers, up to €35 million or 7% for prohibited AI practices, €15 million or 3% for most other breaches including Article 50, and €7.5 million or 1% for supplying incorrect information, and they have been enforceable since 2 August 2025, since the Omnibus left Article 99 itself intact. The Digital Omnibus changed when the underlying high-risk obligations start applying; it did not touch when or how the penalty framework for the obligations that already apply, prohibited practices, GPAI rules, and transparency, gets enforced.

The factors a national authority weighs when setting an actual fine within these ceilings are laid out explicitly in the Act itself. Relevant factors include the nature, gravity, and duration of the infringement and its consequences, the number of affected persons and the level of damage suffered, whether other authorities have already fined the same operator for the same infringement, the size, annual turnover, and market share of the operator, any previous infringements, the degree of cooperation with authorities, and the manner in which the infringement became known, whether self-reported or discovered by regulators.

The SME inversion rule most explainers get backwards

One provision buried inside Article 99 deserves its own dedicated treatment, because getting it wrong changes a company’s realistic exposure estimate by orders of magnitude. Article 99(6) is the most important provision in the penalty framework for small organisations: for SMEs and start-ups, the fine for each tier is capped at the lower of the fixed amount or the percentage of turnover, inverting the calculation that applies to large undertakings, where the fine is whichever of the two figures is higher.

The scale of the difference this produces is significant. For a startup with €2 million in annual revenue, the difference between the standard and SME rule on a middle-tier violation is the difference between €15 million and €60,000; the SME rule does not eliminate the fine, it proportions it, and compliance is still required, with reputational consequences of enforcement action applying regardless of company size. For a Slovak or other smaller EU agency operating with a modest turnover, this inversion is the single most consequential number in the entire fine structure, and it is also the number secondary commentary gets wrong most often, since the intuitive reading of “whichever is higher” from large-company coverage does not carry over correctly to the SME case.

Precision on the exact percentage matters too, since sloppy secondary sources circulate incorrect figures. On the lowest tier, the correct figure is 1%: Article 99(5) of Regulation (EU) 2024/1689, as published in the Official Journal, states “up to 1% of its total worldwide annual turnover,” and some secondary sources incorrectly cite 1.5%, so the primary text should always be verified directly.

Whether a company actually qualifies for this inversion turns on the EU’s standard SME definition rather than on the company’s own sense of its size, which matters because the threshold is stricter than many founders assume. The EU’s SME category, drawn from Commission Recommendation 2003/361/EC and referenced throughout the AI Act’s SME provisions, covers enterprises with fewer than 250 employees and either annual turnover not exceeding €50 million or an annual balance sheet total not exceeding €43 million, with micro and small enterprises subject to even lower thresholds within that band. A company that has scaled past 250 employees, even while still thinking of itself culturally as a small or founder-led business, loses access to both the inverted fine calculation and the priority sandbox access described in the next section, which is a meaningful reason for a growing agency or software company to build its AI Act compliance program on the assumption that undertaking-level fines will eventually apply, rather than assuming SME treatment indefinitely as headcount and turnover grow.

Regulatory sandboxes and other support measures built for smaller companies

The Act does not leave smaller companies to navigate this framework with reduced fines as their only concession. Article 57 requires member states to establish AI regulatory sandboxes, controlled environments where startups and SMEs can develop, test, and validate innovative AI systems under regulatory supervision before facing full market compliance requirements, borrowing the model from fintech regulatory sandboxes that let startups pilot new payment products under regulator oversight before full authorisation.

Access is explicitly weighted toward smaller companies. Member States must give EU-registered SMEs and startups priority access to national AI regulatory sandboxes, provided the eligibility conditions are met; this does not exclude other companies from applying, but means smaller companies move up the queue when capacity is limited, and access itself is free of charge for SMEs, including start-ups, without prejudice to exceptional recoverable costs. Beyond the sandbox itself, further concrete support measures exist under Article 62: Member States must organise specific awareness-raising and training activities on the Act’s application tailored to the needs of SMEs, including start-ups, deployers, and local public authorities, utilise or establish dedicated communication channels for advice and queries, and facilitate SME participation in the standardisation process, while the specific interests of SME providers must be taken into account when setting conformity-assessment fees, reducing those fees proportionately to company size and market size.

There is no size exemption under the Act itself: if an AI system affects people in the European Union, compliance is required whether the company has five employees or five thousand, and a two-person startup selling an AI hiring tool to a single German client carries the same core legal obligations as a much larger enterprise. What differs is the support infrastructure: reduced penalties, regulatory sandboxes, and simplified documentation specifically built to keep compliance a manageable engineering and governance problem rather than a company-ending legal risk.

A sandbox engagement is not a compliance shortcut, but it is a genuinely useful record. Article 57 is relevant to providers and deployers alike, and companies extracting real value from it treat regulators as a resource, structured guidance, documented exits, priority access, rather than an adversary, since the paper trail from a sandbox engagement is reusable compliance evidence afterwards.

What happens after a company exits the sandbox is worth spelling out, since the sandbox’s practical value depends entirely on what a company does with the experience afterward rather than on the testing period itself. Leaving the sandbox does not erase the underlying obligations: an unfit system still faces the full Article 99 penalty regime once placed on the market, and the sandbox’s point is the opposite of a shortcut, it is a structured way to find out whether a system is lawful in dialogue with the regulator, safely, before shipping, rather than discovering it is not after the fact. The exit report a competent authority produces at the end of a sandbox engagement becomes a genuinely reusable asset: it can support the conformity assessment process described earlier in this piece, and, because it documents a genuine, contemporaneous good-faith effort to work through open compliance questions with the regulator rather than around it, it is exactly the kind of cooperation evidence Article 99’s mitigating-factors list rewards if an enforcement question arises later, regardless of whether that later question concerns the specific system tested in the sandbox or a related one built using the same underlying approach.

Slovakia still has no single AI regulator, and that changes how complaints land

For any business operating out of Slovakia specifically, or serving Slovak clients, the national enforcement architecture is worth understanding concretely, because it differs from the single-super-regulator model some other member states have chosen. Slovakia has not created a standalone AI regulator; oversight is instead allocated across existing authorities whose mandates now reference or interact with the EU AI Act.

The Slovak Trade Inspection acts as the lead market-surveillance authority for consumer products and services, empowered to order corrective measures, withdrawals and bans; the Office for Personal Data Protection of the Slovak Republic is the independent supervisory authority for personal-data processing, including automated processing; and the National Security Authority serves as the national cybersecurity authority, and from 1 January 2026, also the market-surveillance authority for “products with digital elements” under the Cyber Resilience Act.

National implementing legislation was still in motion as of the most recent tracking available. Draft acts on the organisation of public administration and state administration in the field of artificial intelligence are the national implementing instruments for the EU AI Act, aiming to institutionalise national AI governance, designate a general national market surveillance authority within the Ministry of Investments, Regional Development and Informatisation, and establish sectoral supervisory authorities, with an anticipated effective date around January 2026, though final content remained subject to change following consultation and parliamentary process. This national fragmentation is not unique to Slovakia. As of the most recent tracking, nine member states had designated both a market surveillance authority and a notifying authority with clarity, twelve had pending legislative proposals or partial designations, and six had yet to designate or establish any competent authority at all, despite the original 2 August 2025 statutory deadline for doing so.

The practical consequence for a business is that a complaint or an incident report in Slovakia may currently route through more than one authority depending on whether the underlying issue is framed as a product-safety question, a data-protection question, or a cybersecurity question, until the dedicated national AI framework is fully operational and a single point of contact, required under Article 70, is unambiguously designated and publicised.

A further layer worth noting for Slovak companies specifically is the role of CERAI, the country’s advisory body on AI, which sits alongside rather than instead of the enforcement authorities described above. While CERAI does not have direct enforcement powers, its outputs inform governmental policy-making and contribute to national alignment with international standards, making it a useful early-warning source for how Slovak implementing legislation is likely to interpret specific AI Act provisions, even though it cannot itself investigate or fine a company. For an agency the size of Webiano or similar Slovak SMEs, the pragmatic reading of this fragmented landscape is that data-processing questions arising from AI use, which cover most of the transparency and content-disclosure obligations discussed throughout this piece, are most likely to reach the Office for Personal Data Protection first, while product-safety-style high-risk AI questions would route through the Slovak Trade Inspection once its AI Act-specific mandate is fully operational.

A marketing and SEO agency runs into the AI Act sooner than it expects

Having covered the general framework in full, it is worth applying it directly to the kind of business most likely to be reading this piece for genuinely practical reasons: a digital marketing, SEO, or content agency using AI tools daily across client work, without building any AI models itself.

The starting point is recognizing where such an agency sits in the actor taxonomy. In the overwhelming majority of cases, an agency is a deployer of third-party AI tools, whether that is a large language model used for drafting, an image generator used for campaign visuals, or a chatbot platform deployed on a client’s website. It becomes a provider only in the narrower scenarios described earlier: rebranding a third-party tool under its own name, or substantially modifying a model in a way that changes its function.

Practical steps for a marketing agency include updating client contracts to ensure agreements address AI usage and compliance responsibilities, training the team to educate staff on responsible AI use and compliance requirements, developing documentation and processes for tracking AI usage in client work, and staying informed as enforcement of the Act takes shape, alongside implementing documentation systems that track AI usage across campaigns, developing frameworks for consistent disclosure of AI-generated content, and creating client education materials about responsible AI use in marketing.

The transparency obligations under Article 50 are the ones most directly relevant to daily agency work, since content production is precisely the activity Article 50 targets. Labelling compliance means following applicable AI-labelling and transparency requirements for marketing materials; where content targets EU consumers, this includes the obligations under the AI Act and the associated Code of Practice, which require clear visible and audible labels for deep-fake content at first consumer exposure, appropriate labelling training for personnel, and, for high-profile content, keeping records of prompts to support the labelling process with human oversight and documentation of how the AI system generated or modified the content.

A wider point worth stressing for any agency reading this specifically because of Article 5’s prohibitions: campaign design choices that lean on psychological persuasion techniques deserve a second look against the manipulation and vulnerability-exploitation prohibitions described earlier, particularly for campaigns targeting minors, financially vulnerable audiences, or using dark-pattern-adjacent gamification. This is not a hypothetical concern layered on for effect; it is the exact fact pattern the Commission itself uses as a worked example of a prohibited practice.

Beyond the EU framework itself, agencies working across markets should be aware that transparency expectations are not solely an EU phenomenon, which affects how a single piece of content gets treated depending on where it runs. The core enforcement trigger for AI content disclosure in other jurisdictions, such as under FTC guidance, remains consumer perception: if content could mislead audiences about its nature or authenticity, disclosure requirements apply regardless of the underlying technology used to create it, and brands are now expected to maintain detailed records of every step in the content-creation process, including original prompts, version histories showing human edits, and clear notation of which elements were AI-generated versus human-created.

Liability does not stop at the agency-client boundary either. Regulators increasingly view agencies as active participants in advertising campaigns, particularly where agencies help develop campaign strategy, manage influencers, or create marketing content, and companies remain responsible for marketing claims disseminated through automated systems, influencers, and digital advertising tools, regardless of whether that content was generated manually or with AI assistance. An agency cannot treat a client’s sign-off as a full transfer of AI Act or advertising-law risk; its own role in producing or directing the content keeps it inside the compliance perimeter.

A chatbot widget deployed on a client’s website deserves its own specific mention, since it is one of the most common AI touchpoints an agency builds or configures directly rather than merely publishing content through. If the agency configures, hosts, or operates the chatbot on the client’s behalf, and particularly if it selects or customises the underlying model, the Article 50(1) disclosure duty, informing the visitor they are talking to a machine, sits with whichever party is properly understood as the provider for that specific deployment, and the agency’s services agreement with the client should say explicitly which of the two carries that duty rather than leaving it to be inferred after the fact. The same applies to AI-generated voiceover, translated ad creative, or synthetic spokesperson content increasingly used in lower-budget video campaigns: each is squarely inside the Article 50(2) marking duty once it reaches an EU audience, and the disclosure has to be genuinely visible or audible at the point of exposure, not buried in a terms-of-service page the viewer never sees.

For SEO and GEO work specifically, the closest the current framework comes to touching search-optimisation practice is indirect rather than direct: the AI Act does not regulate ranking algorithms or search visibility techniques as such, but any AI-written content published to inform the public and later found to be wholly AI-generated without genuine editorial oversight falls under the same Article 50(4) public-interest-text labelling duty already discussed. An agency producing high volumes of AI-assisted articles for clients, in other words, is not automatically exempt from that duty simply because the content is optimised for search engines rather than aimed at a chatbot user; the disclosure question turns on whether a human editor genuinely reviewed and takes accountability for the piece, not on the channel or purpose the content was written for.

Financial services face the compliance load that survived the delay intact

Banking, lending and insurance deserve a return visit here specifically because, unlike employment or general Annex III categories, this sector’s high-risk obligations interact directly with the FRIA requirement described above, and because financial services firms are typically the most mature compliance operations reading this article, with existing GDPR, prudential, and consumer-protection infrastructure to build on rather than starting from zero.

The practical overlap is genuinely useful rather than merely bureaucratic. Existing model-risk-management frameworks that banks already run for prudential purposes, covering model validation, documentation, and ongoing monitoring, map closely onto the Article 16 provider obligations and Article 26 deployer obligations described earlier, meaning a bank’s existing model governance committee is often the right forum to extend into AI Act compliance rather than a wholly new structure. The FRIA requirement specific to credit scoring and insurance pricing, however, remains a genuinely new obligation with no direct prudential-regulation precedent, and is the piece of this sector’s compliance work least likely to already exist inside a firm’s current governance stack.

A further wrinkle specific to this sector concerns the fraud-detection carve-out mentioned earlier in the Annex III discussion: credit-scoring systems used purely to detect financial fraud sit outside the high-risk category, while systems evaluating creditworthiness or establishing a credit score for lending decisions sit inside it. In practice, many fintech risk models blend both functions in a single pipeline, scoring a transaction simultaneously for fraud risk and for creditworthiness, which means a single technical system may need to be assessed, and documented, as high-risk for one output and outside Annex III for another, rather than receiving a single blanket classification. This dual-purpose reality is precisely the kind of edge case Article 6(3)’s significant-risk exception was designed to accommodate, though, as covered earlier, that exception is unavailable wherever the system profiles individual natural persons, which a blended fraud-and-credit model typically does by design.

Healthcare and public administration carry obligations layered on older EU law

Healthcare AI and public-sector AI use cases both illustrate a pattern worth naming explicitly: the AI Act rarely operates as the only relevant law, and frequently layers on top of pre-existing EU regulation rather than replacing it.

For healthcare specifically, AI embedded as a safety component in a medical device sits under Annex I rather than Annex III, meaning its high-risk timeline runs to 2 August 2028 rather than 2 December 2027, and its conformity assessment runs through the existing Medical Devices Regulation framework and its notified bodies rather than a fresh AI-specific process, consistent with the general principle that Annex I systems piggyback on established EU product-safety regimes.

For public administration, the FRIA obligation under Article 27 applies most broadly here, since public bodies deploying any Annex III system except critical infrastructure fall automatically within its scope, without needing to fall into the narrower credit-or-insurance carve-out that brings private companies into the same obligation. Public bodies also face the registration duty under Article 49(3) directly, rather than only through a provider’s registration, reflecting the Act’s general design choice to hold public-sector AI use to a transparency standard at least as strict as, and in several respects stricter than, private-sector use of comparable systems.

Healthcare triage and dispatch systems specifically straddle two different Annex III entries at once, worth flagging because the two carry slightly different obligation profiles even though both land in the high-risk tier. A hospital’s AI-assisted patient triage tool used in emergency care sits under the essential-services category alongside emergency-call dispatch systems, described earlier in the sector mapping, while an AI system embedded as a safety component inside a certified medical device, such as diagnostic imaging software cleared under the Medical Devices Regulation, sits instead under Annex I, with its own longer timeline running to 2 August 2028 rather than the Annex III date of 2 December 2027. The distinction turns on whether the AI functions as a safety component of an already-regulated medical product or as a stand-alone decision-support tool used within a care pathway; hospitals procuring both types of system in parallel, which is increasingly the norm as diagnostic AI and administrative triage AI are adopted together, need to track two separate compliance calendars rather than treating “healthcare AI” as a single undifferentiated category with one deadline.

A practical sequence for building compliance without a dedicated legal team

Pulling together the obligations described throughout this piece, a realistic build sequence for a company without in-house AI Act specialists looks roughly as follows, moving from the fastest wins to the longer-horizon work.

The first and fastest step is the Article 4 AI literacy baseline, since it has no size exemption, applies today, and carries indirect but real liability exposure through civil claims and aggravating-factor treatment in other enforcement actions. A short, role-differentiated training program, covering what AI is, its risks, the regulatory framework, and internal usage policy, satisfies the bulk of this obligation at relatively low cost and immediate effect.

The second step is a full AI system inventory: every tool touching client work, internal operations, or public-facing content that could plausibly meet the Article 3(1) definition, tagged by whether the company is provider, deployer, importer, or distributor for each one, and cross-checked against the Article 5 prohibited list and the Annex III high-risk categories relevant to the company’s sector. This inventory step is the one most frequently skipped by companies assuming “we don’t build AI” answers the compliance question, when in fact it is the deployer analysis, not the provider analysis, that catches the majority of real-world exposure.

The third step is Article 50 transparency mapping for any business publishing AI-generated content or operating chatbots, since this deadline, unlike the high-risk timeline, remains 2 August 2026 and was untouched by the Digital Omnibus delay.

The fourth step, relevant only to the subset of companies whose inventory surfaces a genuine Annex III match, is building toward the December 2027 or August 2028 high-risk deadlines: technical documentation, quality management system design, and, where the FRIA applies, that assessment specifically. Given the now-fixed nature of these dates following the Digital Omnibus, and given that harmonised standards will continue maturing through 2026 and 2027, companies in this category benefit most from starting documentation work early rather than waiting for the deadline to approach, since building a genuine paper trail, rather than a retrofitted one, is precisely what regulators reward under the mitigating-factors language in Article 99.

A fifth step, easy to skip because it produces no visible deliverable of its own, is assigning clear internal ownership before any of the preceding four steps begin. AI Act compliance touches legal, HR, IT security, procurement, and whichever business unit actually uses a given tool, and without a single named owner coordinating across those functions, the most common failure mode is not any one obligation being deliberately ignored, but the inventory step itself never actually happening, because no one owns the job of asking every department what AI tools it has quietly adopted. For a company without a dedicated compliance function, this ownership can sit with existing GDPR or data-protection leadership, extending an existing governance role rather than creating an entirely new one, provided that person is given the explicit mandate and the time allocation the added scope requires.

The GDPR overlap that saves duplicate work if it is planned correctly

Because so much AI Act compliance work touches personal data, coordinating it with existing GDPR infrastructure rather than building a parallel structure is the single most effective efficiency decision most companies can make. Article 26 of the AI Act complements the GDPR: while the GDPR protects personal data, the AI Act focuses on the safety and trustworthiness of AI systems, and organisations must comply with both regulations when their AI system processes personal data.

The FRIA-DPIA relationship covered earlier is the clearest example of this overlap paying off in reduced duplicate work, but the same logic extends further: a company’s existing data protection officer, its GDPR Article 30 records of processing, and its existing DPIA methodology are all reusable scaffolding for AI Act documentation, provided the AI-specific risk dimensions, fundamental rights beyond privacy, safety, non-discrimination, are explicitly added rather than assumed to be already covered by a privacy-only assessment.

The overlap runs in both directions rather than only from GDPR toward the AI Act. A company’s Article 26 logging obligations under the AI Act, covering automatically generated system logs retained for at least six months, sit alongside, and should be designed jointly with, the security and accountability logging many organisations already maintain to satisfy GDPR Article 32’s requirement for appropriate technical measures. Similarly, the worker-notification duty under Article 26(7) for high-risk employment systems dovetails with existing GDPR transparency obligations toward employees whose data is processed through automated means, meaning a single, well-drafted internal notice can often satisfy both regimes at once rather than requiring separate parallel disclosures. The practical risk to watch for is not doing too little on either front, but building two separate, uncoordinated compliance tracks that duplicate effort, diverge over time as each is updated independently, and create the exact kind of inconsistency between a privacy notice and an AI transparency notice that a regulator reviewing both would flag immediately.

Enforcement architecture, who actually knocks on the door first

Understanding which body actually enforces which obligation clarifies where a company’s practical risk sits day to day, distinct from the statutory maximum fines already covered. The AI Office, established within the European Commission, oversees the Act’s enforcement and implementation across member states, with particular responsibility for supervising the most powerful AI models, the general-purpose AI models with systemic risk, while national competent authorities, comprising market surveillance authorities and notifying authorities, supervise implementation and application at national level, with market surveillance authorities specifically responsible for enforcing compliance with prohibitions and high-risk AI rules.

A European AI Board, composed of one representative per member state, contributes to coordination among national competent authorities responsible for the Act’s application, with one of its two sub-groups acting as an administrative cooperation group within the meaning of the EU’s market surveillance regulation, intended to promote consistency in national enforcement across the bloc. For most businesses, this means the first knock on the door, if it comes, arrives from the national market surveillance authority, in Slovakia’s case most likely the Slovak Trade Inspection or, for data-processing-specific complaints, the Office for Personal Data Protection, rather than directly from Brussels, except for the GPAI systemic-risk cases the AI Office handles centrally.

The Digital Omnibus meaningfully expanded what the AI Office itself can do once it does get directly involved, and the scale of those expanded powers is worth stating plainly rather than glossing over. The amended framework gives the AI Office authority to seal premises, to impose daily penalties of up to five percent of worldwide turnover for continued non-compliance, and to act within a five-year limitation period, a materially strengthened enforcement toolkit compared to the Act’s original architecture, though the resources clause meant to staff that authority remains subject to the ordinary EU budgetary procedure rather than a guaranteed allocation, meaning the gap between the AI Office’s formal powers and its practical capacity to exercise them at scale is likely to persist for some time. For a mid-sized company, the realistic reading of this expanded toolkit is that it is aimed squarely at large, non-cooperative GPAI providers and systemic non-compliance, rather than at the kind of documentation gaps a small agency or SME is more likely to be found with; the daily-penalty and premises-sealing powers exist for cases where an operator refuses to engage with a request for information or access, not as a first-response tool for ordinary market surveillance.

The next eighteen months of the calendar, mapped out in full

Consolidating every date scattered through this piece into a single forward-looking sequence, the calendar from the date of publication through 2028 now reads as follows. 2 August 2026: general application date for the bulk of the regulation, including the Article 50 transparency and disclosure obligations for chatbots, deepfakes and synthetic content, largely unaffected by the Digital Omnibus. 2 December 2026: the new Article 5 prohibition on AI-generated non-consensual intimate imagery and CSAM takes effect, alongside the Article 50(2) marking transition deadline for generative systems already on the market before August 2026. 2 August 2027: member states must have at least one national AI regulatory sandbox operational, and the Commission’s deadline arrives for delegated acts relating to sectoral rules under Annex I. 2 December 2027: the deferred high-risk obligations apply to Annex III stand-alone systems, covering employment, credit, education, essential services, law enforcement, migration and justice. 2 August 2028: the deferred high-risk obligations apply to Annex I embedded systems, covering AI as a safety component in already-regulated products like medical devices and machinery. Further out, 2 August 2030 marks the deadline for pre-existing high-risk systems used by public authorities to reach compliance.

Two dates already behind us anchor everything above them: 2 February 2025, when the Article 5 prohibited-practices ban and the Article 4 AI literacy requirement both became applicable, and 2 August 2025, when the general-purpose AI model obligations and the Article 99 penalty framework itself entered into force, with GPAI enforcement specifically activating a year later, on 2 August 2026.

The single most important lesson embedded in that sequence, and in everything covered throughout this piece, is that the Digital Omnibus was a targeted, technical delay to one specific tier of obligations, not a general reprieve from the regulation as a whole. A business that reads “the AI Act got delayed” as a reason to deprioritize AI governance work entirely will find itself, on 2 August 2026, fully exposed on the transparency and prohibited-practice fronts that never moved, while still needing the AI literacy program, the actor-role analysis, and the content-disclosure workflows this piece has walked through in detail, regardless of which Annex III deadline eventually applies to its own high-risk systems.

Two further developments are worth watching over the period this calendar covers, since both could still reshape parts of the picture described in this piece. The harmonised standards whose absence triggered the Digital Omnibus delay in the first place are still being finalised by European standardisation bodies, and their eventual publication will convert several of the currently open-textured Article 16 and Article 17 obligations, what a compliant quality management system or a sufficient technical documentation package actually looks like in granular practice, into far more concrete, checklist-style requirements. Separately, the parallel Data Omnibus covering the GDPR, moving on a slower track than the AI Omnibus and still under negotiation within the Council at the time of writing, could alter exactly how the FRIA-DPIA overlap described earlier in this piece is meant to work in practice, since several of the proposed GDPR amendments touch automated decision-making provisions that the AI Act’s fundamental-rights assessment currently leans on.

For now, the practical answer to the question this piece set out to resolve is this: the AI Act applies far more broadly than “AI company” suggests, its obligations differ sharply depending on whether a business builds, buys, imports, or merely resells AI, its risk tiers carry genuinely different deadlines that no longer move together as a single date, and the safest posture for almost any business touching an EU user is to treat 2 August 2026 as fully live for transparency and literacy, and to treat the 2027 and 2028 high-risk dates as fixed, serious deadlines rather than a reprieve to be revisited only when they draw near.

Straight answers to the AI Act questions that come up most in practice

Author: Jan Bielik CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

Regulation (EU) 2024/1689 (AI Act), consolidated text The official consolidated legal text of the EU Artificial Intelligence Act published on EUR-Lex, the primary source for every article cited throughout this piece.

AI Act Explorer, Article 3: Definitions Reference source for the legal definitions of AI system, provider, deployer, and other actor categories underpinning the scope analysis.

AI Act Explorer, Article 5: Prohibited AI Practices Source for the structure and content of the eight prohibited practices discussed in the unacceptable-risk section.

AI Act Explorer, Annex III: High-Risk AI Systems Primary reference for the eight Annex III high-risk categories, including biometrics, critical infrastructure, employment, and essential services.

AI Act Explorer, Article 16: Obligations of Providers of High-Risk AI Systems Source for the full Article 16 provider obligation list discussed in the provider obligations section.

AI Act Service Desk, Article 26: Obligations of Deployers of High-Risk AI Systems Official Commission source for deployer obligations, including human oversight, monitoring, and worker notification duties.

AI Act Explorer, Article 27: Fundamental Rights Impact Assessment Reference for the FRIA obligation and its scope of application to public bodies and specific private-sector deployers.

AI Act Explorer, Article 53: Obligations for Providers of General-Purpose AI Models Source for the GPAI provider transparency and copyright obligations discussed in the general-purpose AI section.

European Commission, Guidelines for providers of general-purpose AI models Official Commission guidance on GPAI enforcement timelines and the transition from voluntary to binding compliance assessment.

AI Act Explorer, Article 99: Penalties Primary source for the three-tier fine structure, including the SME inversion rule described in the penalties section.

European Commission, AI Act governance and enforcement Official overview of the AI Office, national competent authorities, and the European AI Board’s coordination role.

Regulation (EU) 2026/1744, Digital Omnibus on AI, Official Journal The amending regulation that deferred high-risk obligations and introduced new prohibitions, published 24 July 2026.

Freshfields, EU AI Act unpacked #34: The final Digital Omnibus on AI Law firm analysis of the final Digital Omnibus amendments and their practical impact on business compliance programmes.

Gibson Dunn, EU AI Act Omnibus Agreement, Postponed High-Risk Deadlines Detailed legal analysis of the postponed compliance dates and expanded AI Office enforcement powers.

EDRi, Digital Omnibus moves forward, trampling fundamental rights Civil society perspective on the fundamental-rights implications of the Digital Omnibus, cited for the reactions section.

Corporate Europe Observatory, How Big Tech shaped the EU’s roll-back of digital rights Investigative analysis of industry lobbying positions during the Digital Omnibus negotiation.

Lewis Silkin, The Council and Parliament agree to slim down and delay parts of the EU AI Act Legal commentary detailing the specific provisional agreement reached on 7 May 2026 and its competitiveness rationale.

TechPolicy.Press, ChatGPT didn’t break the AI Act, it showed why adaptive regulation matters Source for the legislative history of how general-purpose AI provisions were added to the Act’s original 2021 draft.

Skadden, Colorado’s Landmark AI Act: What Companies Need To Know Comparative legal analysis of the Colorado AI Act referenced in the cross-jurisdiction comparison section.

Collibra, AI regulatory compliance in 2026: EU AI Act, US orders, and state laws Overview of the fragmented US federal and state AI regulatory landscape compared against the EU’s single framework.

CMS Expert Guide, AI laws and regulations in Slovakia Source for the Slovak national competent authority structure and implementing legislation status.

NicFab Blog, Art. 26 AI Act: Operational Checklist for Deployers of High-Risk AI Systems Practical checklist source for the deployer compliance sequence described in the practical-steps section.

Insites, What digital marketing agencies need to know about the EU AI Act Industry-specific guidance underpinning the marketing and SEO agency application section.

artificialintelligenceact.eu, Article 50: The EU AI Act’s Transparency Rules Practical guide to Article 50 transparency obligations, disclosure requirements, and applicable exemptions.

European Commission, Guidance on AI literacy questions and answers Official Commission FAQ clarifying the scope and flexibility of the Article 4 AI literacy obligation.