On August 1, 2024, the EU AI Act entered into force as the first horizontal AI regulation in the world. Its obligations are phasing in on a staggered timeline, and the bulk of the rules governing high-risk AI systems were originally set to apply from August 2, 2026.
If your firm has been tracking this, you probably know the deadline: the May 2026 Omnibus agreement pushed that deadline to December 2, 2027 for standalone high-risk systems under Annex III. You may have moved AI governance down a few slots on the priority list.
That instinct is going to cost you.
There’s no shortage of EU AI Act commentary. Most of it covers what the Act says. Very little of it addresses what happens when you apply the Act’s provisions to what law firms are actually doing with AI, that is, the specific mechanisms by which your firm stops being a downstream consumer and starts becoming a regulated entity. I haven’t seen that analysis elsewhere, so here it is.
What you need to know about the Act’s structure
The EU AI Act has three features that set up the rest of my analysis.
First, risk tiering. The Act classifies AI systems into four tiers: unacceptable (banned), high-risk (regulated), limited risk (transparency obligations), and minimal risk (unregulated). The compliance obligations are concentrated at the high-risk tier.
Second, the provider/deployer split. Providers develop or place AI systems on the market, while deployers use the AI systems under their own authority in a professional capacity. Providers carry the heavier compliance burden: risk management systems, technical documentation, conformity assessments, quality management, and more under Articles 8–17. Deployers face lighter obligations under Article 26. Most law firms assume they’re deployers; some of them are wrong.
Third, and this is the part that makes it personal: Annex III explicitly names “administration of justice and democratic processes” as a high-risk use case. Point 8(a) covers AI systems intended to assist judicial authorities in researching and interpreting facts and law, and in applying law to a concrete set of facts, including systems “used in a similar way in alternative dispute resolution.” Recital 61 confirms that this extends to ADR proceedings that produce legal effects for the parties.
That language covers a significant portion of what law firms do with AI every day. The standard assumption at most law firms is: we buy AI tools from vendors, the vendors are providers, we are deployers, our obligations are light. The following sections explain why that assumption doesn’t match the reality of what firms are actually building and doing.
The Omnibus delay is a governance vacuum, not breathing room
The provisional Omnibus agreement reached on May 7, 2026 pushes the Annex III high-risk deadline from August 2, 2026 to December 2, 2027, a deferral of 16 months. Although the formal text hasn’t been adopted yet, the political agreement specifies fixed dates.
This feels like relief. Here’s why it isn’t.
GDPR obligations on the personal data your firm processes through AI tools are already enforceable. The GPAI (General-Purpose AI) obligations have been applicable since August 2025. Article 50 transparency obligations shift to December 2026, not December 2027. AI literacy requirements under Article 4 have applied since February 2025. National bar association rules on technology competence and client confidentiality apply right now. And the Heppner ruling from the U.S. Southern District of New York (February 2026) already established that using consumer AI tools on client matters can waive attorney-client privilege. All of these are irrespective of the EU deadline.
The delay covers the Annex III high-risk compliance stack. It does not cover the data protection, privilege, transparency, and professional responsibility obligations that already exist.
What happens during a 16-month governance vacuum is exactly what’s happening now at firms across the Am Law 200 and their international equivalents. An associate runs a client contract through a consumer AI tool with no data processing agreement in place. A paralegal uses Copilot to summarize deposition transcripts without checking whether the provider retains the input data. A partner drafts an arbitration brief with Claude and doesn’t flag it in the engagement file. These people don’t think they’re doing anything wrong; many of their firms don’t have policies that say otherwise. But every one of these actions creates exposure under obligations that are already enforceable.
The delay means firms won’t build compliance infrastructure until they’re forced to. When December 2027 arrives, they’ll face 16 months of accumulated ungoverned deployment to remediate retroactively. It’s like being told your building inspection got delayed, so you keep adding floors without structural engineering. By the time the inspector shows up, you don’t have a compliance gap. You have a structural problem.
How your RAG pipeline changes your regulatory status
Most firms assume they’re deployers. Article 25 of the AI Act says that assumption doesn’t survive contact with what firms are actually building.
Under Article 25(1)(b), a deployer becomes a provider if they make a “substantial modification” to a high-risk AI system already placed on the market or put into service. Article 3(23) defines substantial modification as a post-market change not foreseen by the original provider that affects the system’s compliance with the Act or alters its intended purpose. This creates significant reclassification consequences: the firm inherits the full provider compliance stack under Articles 8–17, including risk management systems, technical documentation, and conformity assessments.
Consider what mid-market and BigLaw firms are doing with AI right now. They are building retrieval-augmented generation (RAG) pipelines that layer firm precedent databases onto foundation models. They’re creating systematic prompt libraries that structure how AI analyzes case facts, fine-tuning models on proprietary legal data, and integrating AI outputs into client-facing work product through bespoke workflows.
Each of these activities pushes the firms closer to—or past—the substantial modification threshold. A firm that builds a RAG system drawing on its own case law database to generate legal analysis hasn’t simply deployed a vendor’s product. It has modified how that product processes information, what knowledge it draws on, and what outputs it produces. If that modified system is being used for work that touches Annex III 8(a)—researching and interpreting facts and law, applying law to facts—the firm may have crossed from deployer to provider of a high-risk AI system.
To be clear, the “substantial modification” threshold is not completely clear. The Act doesn’t provide a checklist, and the draft guidelines published for consultation in May 2026 don’t fully resolve the ambiguity. Light prompt engineering within a vendor’s platform probably doesn’t trigger reclassification. A full RAG pipeline with proprietary data and customized outputs almost certainly does. Many firms are somewhere in between, and that grey zone is itself a form of regulatory risk, because the Act doesn’t require you to know you’ve become a provider. It just requires you to be compliant as one.
The formula is straightforward:
Deployer + Substantial Modification = Provider.
Provider x High-Risk Use Case = Full Compliance Stack.
Using a general-purpose tool for high-risk purposes triggers reclassification
There’s a second path to accidental provider status that is even easier to stumble into and doesn’t require building anything.
Article 25(1)(c) provides that a deployer becomes a provider when it modifies the intended purpose of an AI system—including a general-purpose system—in a way that makes it high-risk under Article 6. The intended purpose of ChatGPT, Claude, Gemini, or Copilot is general-purpose assistance. The provider’s own documentation says as much. These tools are not documented or marketed for use in the administration of justice.
But a law firm that systematically uses one of these tools to research case law, analyze facts, and apply legal reasoning in matters headed for court or arbitration is using a general-purpose tool for an Annex III high-risk purpose. That purpose falls outside what the provider documented. Under Article 25(1)(c), the firm becomes the provider of a high-risk AI system, with all the compliance obligations that follow.
Think of this as a two-by-two matrix. On one axis: is your use within or outside the provider’s documented intended purpose? On the other: is your use case general or high-risk under Annex III? The dangerous quadrant is obvious—outside intended purpose, high-risk use case—and a lot of legal AI use sits squarely in it.
The May 2026 draft guidelines offered some relief for legal technology vendors specifically. Legal-tech companies whose customers are law firms are likely outside the scope of Annex III 8(a), because attorneys generally don’t act “on behalf of” a judicial authority. But that carve-out helps the vendor, not you. If your firm’s use of the tool falls within Annex III 8(a), the reclassification risk sits with your firm, not your vendor.
This reframes what AI vendor due diligence means for law firms. Evaluating the vendor’s SOC 2 certification or data processing agreement is necessary but insufficient—the Model Gap I’ve written about before. The harder question is whether your firm’s intended use of the vendor’s product falls within the vendor’s documented purpose, and what happens to your regulatory status when it doesn’t.
The transparency-privilege collision
Article 50 of the AI Act imposes transparency obligations requiring that people interacting with AI systems be informed of that fact. For deployers of AI systems that generate content or interact with individuals, disclosure is required. These obligations shift to December 2026 under the Omnibus agreement, well ahead of the Annex III high-risk deadline.
In most industries, transparency is a manageable compliance risk. In legal practice, it collides with something no other regulated industry has to worry about: attorney-client privilege.
The collision runs in both directions.
In February 2026, Judge Rakoff held in United States v. Heppner (S.D.N.Y.) that documents created using a public AI platform were not protected by attorney-client privilege, reasoning in part that the inputs and outputs were not confidential because the tool’s provider reserved the right to use them for training. The UK Upper Tribunal reached a similar conclusion in Hamid , finding that disclosing information to AI tools without adequate confidentiality protections could waive privilege.
So disclosure creates a risk: a firm that reports AI use on a client matter, as the AI Act’s transparency provisions push toward, may hand opposing counsel ammunition to challenge privilege over AI-assisted work product. But concealment creates different risk: a firm that stays quiet about AI use to protect privilege may violate Article 50 transparency requirements in any matter touching EU jurisdiction.
For firms with cross-border practices, which includes most firms this piece is written for, these obligations don’t exist in separate legal universes. The AI Act is EU law. Heppner is U.S. federal law. Hamid is UK law. A firm advising a European client on a dispute with U.S. discovery obligations faces all three simultaneously. There is no jurisdiction-shopping solution. The only solution is a governance framework that accounts for all three at once.
The fundamental rights impact assessment nobody’s doing
Article 27 requires deployers of high-risk AI systems to conduct a fundamental rights impact assessment (FRIA) before deploying those systems. The FRIA is a structured analysis of who is affected by the AI system’s outputs and how, including impacts on due process, non-discrimination, and access to justice.
For a law firm deploying AI in litigation support, ADR, or regulatory proceedings, the “affected persons” analysis gets uncomfortable very fast. If you’re using AI to draft legal arguments, start counting: the opposing party, whose rights depend on the quality and fairness of the arguments raised against them. The tribunal, whose decision-making depends on the reliability of materials presented to it. Your own client, whose interests depend on the accuracy of the work done on their behalf. That’s three categories of affected persons from a single AI-assisted brief.
How many law firms have conducted a FRIA? If I had to guess, I’d put the number at approximately zero.
The Omnibus agreement pushes this obligation to December 2027 with the rest of the Annex III requirements. But a FRIA isn’t a document you produce overnight just before the deadline. It requires an understanding of your AI systems’ outputs, their downstream effects on specific categories of people, and the mitigation measures you’ve put in place. Firms that wait until Q3 2027 to start building this capacity will be writing FRIAs under deadline pressure without the institutional knowledge to do them well. The delay, again, makes the problem worse by giving firms permission to postpone work that takes time to learn.
What this means for your firm
The comfortable narrative about the EU AI Act and law firms goes as follows: the AI Act regulates AI vendors, firms are deployers with lighter obligations, the deadline just got pushed back, so we have time. But every element of that narrative is either incomplete or wrong.
Your firm may already be a provider under Article 25 if it has substantially modified an AI system or used a general-purpose tool for a purpose that triggers high-risk classification. Your Article 50 transparency obligations arrive in December 2026. Your GDPR, privilege, and professional responsibility obligations are live today. And the governance infrastructure you’ll need for FRIA compliance in December 2027 takes months to build.
The firms that will be well-positioned are those that aren’t waiting for enforcement deadlines, but are instead building AI governance now. This includes inventorying their AI systems, classifying use cases against Annex III, auditing their provider/deployer status under Article 25, and putting the documentation practices in place that compliance will eventually require. Risk stratification and proportional deployment, in practice, involve matching governance intensity to the regulatory exposure each system creates, before a deadline forces you to do it all at once.
If you’re not sure where your firm stands, the AI Readiness Diagnostic is a free, ten-question assessment built on NIST AI RMF, ISO 42001, and OWASP frameworks. It won’t solve your compliance problem, but it will tell you whether you have one and where the gaps are.
The alternative is to wait for December 2027, discover your firm has been operating as an unregistered provider of high-risk AI systems for the better part of two years, and try to remediate retroactively.
One of those is a governance strategy. The other is a liability.