On 2 August 2026, the EU AI Act reached its most anticipated milestone: the date on which most of the regulation was supposed to become applicable. Six days earlier, the EU had quietly moved a large part of it. If you find that confusing, you are in good company, and you have probably also noticed what happened next: a wave of tools, each presenting itself as the way to be "AI Act compliant", often built around one architectural claim or another.

This post does three things. It explains what the AI Act actually requires as of today, what that means for a law firm, and what the increasingly loud cloud versus local debate does and does not decide. Our product appears only at the end, and not as a magic word.

The AI Act in one page

The AI Act (Regulation (EU) 2024/1689) regulates by risk, not by technology. At the top sit prohibited practices, banned outright since February 2025: manipulative techniques, social scoring, emotion recognition in the workplace, among others. Below them sit high-risk systems, such as AI used in hiring, credit scoring or the administration of justice, which carry the heavy regime of conformity assessments, technical documentation and human oversight. Everything else, which is to say most of the AI professionals actually use, carries two lighter kinds of duty: transparency obligations for specific situations, and a general AI literacy obligation.

Two roles determine who owes what. The provider develops the system or places it on the market. The deployer uses it under its own authority in a professional context. A law firm using AI tools is a deployer, and the duties of a deployer attach to the firm, not to the individual associate typing the prompt.

The Act also reaches beyond the EU's borders. It can apply to providers and deployers established in third countries, Switzerland included, when the system or its output is used in the Union.

What 2 August changed, and what it did not

On 24 July 2026, Regulation (EU) 2026/1744, the "Digital Omnibus on AI", was published in the Official Journal. It deferred the obligations for high-risk systems by more than a year: to 2 December 2027 for the standalone high-risk uses listed in Annex III, and to 2 August 2028 for AI embedded in regulated products. The headline deadline, in other words, moved.

What did not move is everything that touches everyday professional use of AI:

  • Transparency (Article 50), applicable since 2 August 2026. AI systems that interact with people must say so. Synthetic content must carry machine-readable marking (generative systems already on the market before 2 August have until 2 December 2026 for this one requirement). Deep fakes must be labelled, and so must AI-generated text published to inform the public on matters of public interest. The European Commission adopted guidelines on all of this on 20 July 2026, and a Code of Practice on marking and labelling was finalised in June. Violations carry fines of up to EUR 15 million or 3% of worldwide turnover.
  • AI literacy (Article 4), applicable since February 2025. Providers and deployers must take measures to support the AI literacy of their staff. The omnibus softened this wording from the original duty to ensure a sufficient level, and no direct fine attaches to it, but it did not make it decorative: documented training remains the first evidence of diligence an authority or a court will ask for.
  • Everything that was never about AI in the first place. Professional secrecy and data protection law did not wait for the AI Act and were not deferred with it.

There is a second thing 2 August switched on, easy to miss in the deferral coverage: enforcement. National market surveillance authorities are now operational, and the Commission gains the power to fine the providers of large general-purpose models. The pattern is worth stating plainly: the obligations that made the headlines moved to 2027 and 2028. The ones that apply to a law firm using AI, and the machinery that checks them, are already here.

What this means for a law firm, concretely

Start with a reassurance: the tools lawyers typically use for research, drafting and document review are not high-risk systems under Annex III. The panic marketing that suggests otherwise is wrong. But three duties are real and current.

First, AI literacy. If people in your firm use AI on client work, Article 4 asks you to support their competence in using it, and in practice that means being able to show that training happened, for whom, and on what. A policy nobody has read does not meet that bar.

Second, transparency where you publish. Advice delivered to a client is not "published", and internal drafts are not either. But a client alert or blog commentary on a legal development, generated by AI and published on your website, is exactly the kind of text Article 50 has in mind. You then have two options: label it, or subject it to real human review with editorial responsibility, which is the carve-out the law provides and the standard a law firm should be meeting anyway. The review must be substantive, a cursory glance before publishing does not qualify, and it is worth keeping a record of it: if the exemption is ever questioned, that record is your proof.

Third, disclosure where you deploy. If a chatbot answers questions on your firm's website, visitors must be told they are talking to a machine.

And in Switzerland?

The AI Act is EU law, and a purely domestic Swiss practice is not its primary addressee. But it crosses the border in two ways. Directly: if your firm serves EU clients or your AI output is intended for use in the Union, obligations can attach regardless of where your office is. And indirectly: Switzerland signed the Council of Europe's AI Convention on 27 March 2025 and has chosen a sectoral approach to implementing it, with a consultation draft expected by the end of 2026. Transparency is one of its core areas. The direction of travel is the same; only the vehicle differs.

Meanwhile, the rules with teeth for a Swiss lawyer are the ones that already applied before any of this: professional secrecy under Art. 321 of the Criminal Code, the revised Federal Act on Data Protection, and the GDPR for EU-facing work. Which brings us to the debate every vendor wants to have.

Cloud versus local: what the law actually says

Around these deadlines, a familiar argument has become louder. One camp treats cloud AI as an automatic breach waiting to happen. The other treats local AI as automatic compliance. Both are wrong, and for the same reason: they substitute a judgment about architecture for a reading of the law and the contract.

Because here is the uncomfortable part. The AI Act does not distinguish between cloud and local. Article 50 grants no exemption for keeping the model in your building. Nor does data protection law: under the EDPB's guidelines on controllers and processors, responsibility follows whoever decides the purposes and means of processing, not the room where the server hums. A lawyer running a local model is still the controller of every byte fed into it.

The same honesty is owed about the anonymization tools now sold as compliance shortcuts. If the removal of names is reversible, it is pseudonymization, not anonymization, and the data remains fully personal in law. Removing names does not remove identifiability: a dispute recognisable from its dates, amounts and places is still a dispute about identifiable people. And a client's litigation strategy or balance sheet survives anonymization untouched, because confidentiality is broader than personal data. These tools mitigate; they do not exempt. Anyone selling them as an exit from the rules is selling an alibi.

And no architecture replaces method. A firm without an AI policy, without training, without a map of which tasks are allowed with which data, is not compliant on any infrastructure. A badly run local model can be a worse decision than a carefully contracted enterprise cloud plan. The method comes first. The tool comes after.

What architecture does decide

Once the method exists, though, architecture stops being a slogan and becomes a column in your risk table, the column headed "where".

If client data is processed on infrastructure you own, a specific set of questions does not get answered better; it disappears. Cross-border transfer rules are not satisfied with clauses, because no transfer occurs. There is no third-party processor to bind with an agreement, audit, and list in your records. A foreign authority cannot compel a provider you do not use; no contract with a US hyperscaler survives the CLOUD Act, but geography does. And a "we don't train on your data" clause becomes unnecessary, because a promise about what happens to transmitted data is replaced by the fact that nothing is transmitted. That is the difference between compliance by policy and compliance by physics: one you must trust and re-verify at every contract renewal, the other you can inspect by looking at your own server room.

The honest counterweight, and it deserves to be said just as plainly: running local AI yourself has real, recurring costs. Hardware, security updates, maintenance, someone whose job it is to keep it alive. We wrote about where do-it-yourself automation hits its ceiling; a self-managed model in a corner of the office fails the same way. Local is only an advantage if someone maintains it as a product.

How to decide, at your desk

If you are weighing a cloud assistant against an on-premise system, here is the operative version of everything above. Start from the use-case map your policy requires anyway, and split your work by data, not by tool.

For work on non-confidential material, formatting, boilerplate, public sources, a cloud assistant on a professional plan is a perfectly defensible choice, and we have written about how far you can push it. Nothing in the AI Act should stop you.

For work that touches the substance of a mandate, there are two defensible setups, not one. A negotiated enterprise cloud plan, with training exclusion, retention limits and a signed data-processing agreement, can be run lawfully, at the price of holding your compliance in documents: transfer mechanisms to maintain, sub-processors to track, promises you cannot inspect, and a professional-secrecy exposure under Art. 321 that no contract removes. Or a local system, where those questions do not arise, at the price of a machine in your office and someone whose job it is to maintain it.

Which of the two you choose is a judgement about where you want your risk to live: in paperwork you must trust and renew at every contract cycle, or in an architecture you can walk over and inspect. Everything else, the training, the policy, the review of what goes out, is identical on both, and it is yours.

What nobody can sell you

So, is there a definitive solution to AI compliance for law firms? No. Be suspicious of anyone who claims to sell one, and note that we build AI tools ourselves, so do not exempt us from that suspicion: read the regulation, the Commission's guidelines, and the contract behind whatever tool you use today. Those texts have nothing to sell you, which is what makes them the right referee for every claim a vendor makes, ours included.

What we can say precisely is which part of the problem our architecture removes and which it does not. Legal Intelligence runs entirely on hardware you own, in your office, so the entire "where" column, transfers, third-party processors, foreign jurisdiction, training reuse, is closed by design rather than by contract, and it is maintained as a product, so the cost of local does not land on your staff. What it does not remove is your method: the policy, the training Article 4 still asks of you, the decision of which matters AI may touch. That part was always yours, on any architecture.