Europe just wrote down the thing American compliance teams have spent years refusing to say out loud, and it wrote it down in four numbered tiers.
On June 3, 2026, the European Commission published the Cloud and AI Development Act (CADA), the centerpiece of what Brussels is calling its European Technological Sovereignty Package. It's a mandatory four-tier sovereignty framework for cloud and AI services used by public bodies, and the highest tier, covering defense and national security, would effectively exclude any cloud provider that's subject to foreign law.
The line that cut through the press release noise came from Executive Vice-President Henna Virkkunen: the EU intends to ensure that critical cloud providers don't have a "kill switch." She said plainly that U.S. companies would have difficulty reaching the highest sovereignty tiers because of the U.S. CLOUD Act (18 U.S.C. § 2713), which lets the U.S. government compel American companies to hand over data stored anywhere in the world.
Europe named the problem. What I'm watching now is whether American regulated organizations, the law firms and tribal governments and defense contractors and healthcare systems, are paying the slightest attention.
What CADA Does
Here's the ladder. CADA defines cloud and AI sovereignty in four assurance levels:
Tier 1: Infrastructure physically located within the EU. Minimum baseline. Every public body has to clear it.
Tier 2: Demonstrated independence from third-country operational interference. Providers document what foreign law's able to compel them to disclose.
Tier 3: EU ownership, control, and personnel criteria. The provider's corporate chain has to sit inside EU jurisdiction.
Tier 4: Full supply-chain transparency and control with no third-country interference. Hardware, software, personnel, and legal jurisdiction all EU-originating. Reserved for defense, law enforcement, and border management: roughly 1% of public procurement by volume, and 100% of the workloads nobody can afford to lose.
The Commission estimates U.S. cloud companies currently control more than 70% of the EU cloud market. The EU currently spends €264 billion per year mostly on U.S. proprietary IT products and services. CADA's a structural intervention aimed squarely at that dependency, and whatever you make of Brussels as a regulator, it's the first one to put a number on the exposure instead of a white paper.
Why This Matters to American Regulated Organizations
You're not in the EU. CADA doesn't apply to you. So why am I bringing it up?
Because it's the first formal legal definition of the structural problem American regulated industries've been quietly tolerating for years: extraterritoriality.
The U.S. CLOUD Act (18 U.S.C. § 2713) requires American cloud providers to disclose customer data when compelled by U.S. law, regardless of where that data's stored. So when a tribal government uploads operational data to AWS, a law firm runs a contract review through Microsoft Azure AI, or a defense contractor feeds CUI into a cloud LLM, that data's sitting under a legal regime their own federal government can reach through a provider-level order, with no notice to the customer and no consent from them.
Europe drew a tier around exactly that. It's called Tier 4. It says: if your provider's subject to CLOUD Act jurisdiction, you don't get to use it for your most sensitive work.
American regulators haven't drawn that line. The underlying legal exposure's identical either way.
The Regulatory Reality Your Cloud Provider Won't Discuss
Tribal Nations: OCAP and Data Sovereignty
The First Nations Principles of OCAP (Ownership, Control, Access, and Possession) establish that a tribe owns its data collectively, controls how it's used, has got to be able to reach it at will, and has got to physically possess it. The CLOUD Act runs straight through the Possession principle. A tribal government running administrative AI on any U.S.-headquartered cloud provider has surrendered physical possession to a legal regime it doesn't control, and it did so by operation of law rather than by any decision a council ever voted on.
For a deeper analysis of how OCAP and the CLOUD Act interact, see my post on OCAP Principles and the CLOUD Act: A Compliance Guide for Tribal Governments. For the structural argument on why cloud AI and tribal data sovereignty are incompatible by design, see Tribal Data Sovereignty and the Cloud AI Problem.
Law Firms: ABA Model Rule 1.6
ABA Model Rule 1.6 requires a lawyer to make reasonable efforts to prevent the inadvertent or unauthorized disclosure of client information. That word "reasonable" is doing all the work, and it's a word that moves. As of 2026, with sovereignty-compliant local AI commercially available, running privileged material through a third-party cloud AI service is a harder position to call reasonable than it was two years ago. Europe just published a four-tier framework explaining why.
For the full structural analysis of how privilege breaks in cloud AI workflows, see my post on Attorney-Client Privilege and Cloud AI: The Structural Problem Law Firms Can't Negotiate Away. For law firm AI infrastructure options, see the solutions page.
Defense Contractors: ITAR, DFARS, and CMMC
International Traffic in Arms Regulations (22 C.F.R. Parts 120-130) restrict the export of controlled technical data to foreign nationals. Cloud providers are subject to compelled disclosure under the CLOUD Act, and they don't get to tell you when it happens. If that compelled disclosure touches a foreign national employee or a foreign-jurisdiction data center, you've got an unauthorized export and an empowered official with a bad afternoon ahead. CMMC 2.0 requires protection of Controlled Unclassified Information (CUI) under NIST SP 800-171. Air-gapped local infrastructure is the only control set that fully satisfies the isolation requirement.
See the ITAR and DFARS AI Self-Assessment for a structured evaluation, and the defense contractor AI solutions page.
Healthcare: HIPAA Technical Safeguards
45 C.F.R. § 164.312 requires covered entities to implement technical security measures that prevent unauthorized access to ePHI transmitted over electronic communication networks. A Business Associate Agreement with a cloud AI provider moves contractual liability around. It doesn't move the data, and it sure doesn't move physical control of it. The CLOUD Act can compel disclosure of ePHI from a cloud provider whether or not there's a BAA in the drawer.
For the full HIPAA technical safeguards analysis, see the HIPAA Technical Safeguards for Local AI Deployment post, and the medical practice AI infrastructure page.
What the EU's Framework Reveals About Your Current Setup
CADA's four-tier model is useful precisely because it forces an honest answer to a question most American organizations would rather not be asked: what tier is your current AI deployment sitting at?
If you're using any major cloud AI service, OpenAI's API, Microsoft Azure AI, AWS Bedrock, Google Vertex AI, you're at Tier 1 at best under CADA's framework. The infrastructure may well be domestic. But your provider's subject to U.S. law, it's run by a publicly traded company whose shareholders aren't your clients, and it's operating under terms of service that'll change without asking you first.
For regulated industries handling data with legal protection attached to it, PHI, CUI, client confidences, tribal proprietary data, Tier 1 is a liability with a start date you haven't been told yet, not a compliant posture.
What I'd Put in the Building Instead
I deploy air-gapped inference on site, with the Woven Security & Governance Fabric built in. The system lives in your building. Your data doesn't leave your premises. There's no vendor agreement governing data access because there's no data transmission to govern. The CLOUD Act can't compel production of data a cloud provider doesn't have.
What that system's made of depends entirely on what your work turns out to need, and I don't decide that from a catalog. I'm stack-agnostic on purpose: sometimes the shape is a small bench of machines sitting close to the people using them, sometimes it's one enclosure that grows a leg at a time, sometimes it's serious datacenter-class capacity because the workload genuinely earned it. Whatever motley crew of hardware delivers a hardened, working system for your people is the right answer, and that includes gear you already own that somebody else sold you.
The model layer works the same way. Open-source, open-weight models, chosen for your domain and swapped out as the frontier moves. Nobody holds a meter on you and nobody gets to deprecate the model your workflow depends on. That's the part of sovereignty the CADA tiers are reaching for, and it doesn't survive being locked to one vendor's fixed configuration.
No token fees, no per-query billing, no cloud connectivity required. For a full five-year cost comparison against cloud AI spending, see Cloud AI vs. Local Hardware: The Honest 5-Year TCO.
The hardware's the last thing I arrive with, not the first. I sit on site with your senior people before anybody talks about a purchase: the docketing specialist hand-deriving a deadline cascade off a minute order, the prior authorization coordinator retyping the same clinical history into a fifth payer-specific form, the FSO deciding what counts as CUI this week. Discovery surfaces the use cases already latent in the organization, most of which nobody's said out loud. Then I recommend the stack, we deploy and configure it together on site, and I onboard your team on workflows and agentic orchestration built for your vertical. A deployment that ends at the install is a deployment that quietly dies in the first quarter.
What You Don't Get
Local inference hardware isn't a compliance certification. Buying hardware doesn't make you HIPAA-compliant, CMMC-certified, or ITAR-registered. Those take policies, training, audits, and documented controls across your organization's full operations, and there's no rack on earth that substitutes for any of it.
What local hardware gives you is one specific technical control: your data doesn't leave your premises. That kills exactly one category of risk cloud AI introduces, third-party data custody, and leaves every other compliance obligation sitting right where it was. The compliance resources here break down each framework, HIPAA, ITAR/CMMC, OCAP, and the CLOUD Act, one brief at a time.
If your legal or compliance team tells you a BAA with OpenAI solves your HIPAA exposure, they may well be right about the contractual liability. They're wrong about the technical control. CADA's framework is useful here: the EU explicitly states that data transfer frameworks do not remove sovereignty concerns because sovereignty goes beyond data transfers and relates to operational autonomy.
Read that sentence again. The EU Commission just told the world that contractual frameworks don't solve infrastructure sovereignty problems, which is the sentence I've been repeating to compliance officers for a while now, except now it's got a Commission standing behind it.
The Convergence Happening Right Now
Two things landed in the same week, and anybody working regulated-industry AI ought to have both on the board.
June 2: GIS Reports published a detailed analysis noting that governments worldwide are treating AI as a critical technology and imposing state control over its deployment. The Anthropic case, in which the Pentagon attempted to designate a U.S. AI company a national security supply chain risk for declining to support autonomous lethal weapons, illustrates that frontier cloud AI models are geopolitical assets now. What you query, and through whose pipe, stopped being a purely technical decision.
June 3: The EU published CADA, and the definitions got codified. That's the part that doesn't un-happen.
The direction of travel's clear enough. Regulated organizations that're still deferring the decision to bring AI in-house are deferring into a regulatory corner that's getting more crowded every quarter.