18 min readJust now

–

The Velocity vs. Sovereignty Tradeoff

Press enter or click to view image in full size

European enterprises face a false choice: sovereignty or capability. This framing is wrong and costly. Most sovereignty requirements can be satisfied today with US hyperscaler infrastructure. The question is which requirements apply to you.

Frontier models from OpenAI, Anthropic, and Google remain the most capable options for complex reasoning, multi-step agentic tasks, and cutting-edge applications. At the same time, open-weight models from Meta, Mistral, Arcee AI, and others now handle most enterprise workloads effectively. They can be fine-tuned for domain-specific tasks and frequently outperform larger general-purpose models on specialized applications. For many use cases, the performance gap is not the deciding factor.

The real constraint for sovereign deployments is infrastructure. AWS, Azure, and GCP offer managed services, global scale, and integration depth that EU-native providers cannot match. Choosing fully sovereign infrastructure means accepting a higher operational burden, less mature tooling, and smaller talent pools. These are real costs. They are infrastructure costs.

This distinction matters: the model layer is portable, infrastructure is the variable. You can use frontier models on US hyperscaler infrastructure with strong sovereignty controls, accepting residual legal exposure. If requirements tighten later, open-weight models migrate to EU-native infrastructure.

When is full legal sovereignty mandatory? Only in narrow circumstances: explicit statutory requirements like French SecNumCloud mandates, defense procurement, and critical infrastructure designations. Classified workloads. Organizations whose threat model specifically includes the US government legal process. For these cases, there is no workaround.

For everyone else, sovereignty is risk management, not compliance. GDPR does not require avoiding US providers. It requires appropriate safeguards. The AI Act applies the same compliance requirements regardless of provider nationality, though non-EU providers must appoint an authorized representative established in the EU. Most regulated-industry requirements are satisfied by certifications, encryption controls, and contractual protections that US hyperscalers already offer.

The practical implication: unless you face an explicit mandate, accept residual legal exposure as managed risk. This risk has not materialized into actual data disclosure for any major provider’s European customers. When sovereignty-mandated opportunities arise, address them through infrastructure migration. Do not constrain your entire product architecture upfront.

Defining Sovereignty

“Sovereignty” is frequently invoked but rarely defined. This ambiguity benefits vendor marketing solutions that address some concerns while leaving others unresolved.

Data Residency: Where data is stored and processed. Data stays within defined geographic boundaries, typically the EU. All major providers offer this. Necessary but not sufficient.

Operational Sovereignty: Who operates the infrastructure? Physical datacenter access, administrative system access, support, and incident response. Requires personnel subject to EU jurisdiction. Residence requirements provide weaker protection than citizenship requirements.

Technical Sovereignty: Who can technically access data, regardless of policy. Can operators or third parties retrieve customer data even if access is prohibited? Requires architectural controls that eliminate access paths entirely.

Legal Sovereignty: Which jurisdiction’s laws apply? A US company remains subject to US law regardless of where it stores data or who operates systems. The CLOUD Act explicitly asserts extraterritorial jurisdiction, authorizing US authorities to compel US companies to produce data “regardless of whether such communication, record, or other information is located within or outside of the United States.”

True sovereignty requires all four dimensions. Most “sovereign” offerings address data residency and some operational concerns while leaving legal sovereignty unresolved. Legal sovereignty cannot be achieved through technical architecture alone when a US company is involved. It requires the controlling entity to be entirely outside the US jurisdiction.

The Regulatory Landscape

GDPR establishes baseline data protection: lawful basis for processing, data subject rights, and transfer restrictions. Article 48 addresses foreign government access, stipulating that third-country court orders are only acceptable if grounded in international agreements. GDPR does not prohibit US providers, but it creates tension with US laws that compel disclosure.

The CLOUD Act (2018) authorizes US law enforcement to compel US companies to provide data stored abroad. This directly conflicts with Article 48 of the GDPR. US providers are caught between conflicting legal obligations with no clear resolution in sight. Critically, the CLOUD Act’s jurisdiction extends to any provider that is a US person, is incorporated in the United States, or is subject to US jurisdiction through sufficient contacts with the United States.

FISA Section 702 enables US intelligence agencies to collect foreign communications from US electronic communication service providers without individualized warrants. Unlike the CLOUD Act, FISA collection can occur without public legal proceedings. FISA’s scope is limited to providers under US jurisdiction.

NIS2 Directive (effective October 2024) expands cybersecurity requirements to cloud providers serving critical infrastructure. Mandates supply chain security analysis, with Recital 90 referencing concerns about “undue influence by a third country” — making jurisdictional considerations an implicit factor in supplier risk assessments.

The EU AI Act regulates AI systems by risk classification. Providers bear the primary compliance obligations for high-risk systems, including risk management systems, technical documentation, conformity assessments, CE marking, and post-market monitoring. Deployers have separate but less extensive obligations covering human oversight, monitoring, and log retention. Non-EU providers placing AI systems on the EU market must appoint an authorized representative established in the Union.

SecNumCloud is France’s security certification for cloud services. Its 3.2 version requires no corporate nexus to non-EU jurisdictions — specifically, non-EU entities cannot hold more than 39% of capital collectively or exercise control over the provider. This effectively excludes US hyperscalers, regardless of the technical measures they take.

Comparing AI Deployment Options

Hosted API Providers

OpenAI: US-headquartered, subject to US jurisdiction. EU deployments via Microsoft Azure. Enterprise agreements include data processing addenda, EU residency, and no-training commitments. CLOUD Act and FISA exposure remains.

Anthropic: US-headquartered, subject to US jurisdiction. EU deployments via Amazon Bedrock (including AWS European Sovereign Cloud) and Google Cloud. Similar enterprise protections. Same legal exposure profile as OpenAI.

Mistral AI: French-headquartered, nominally advantageous. However, Mistral has US investors (a16z, Salesforce Ventures) and reported US presence, creating potential CLOUD Act exposure. The legal question is untested. Mistral’s position is stronger than US-native providers, but do not assume categorical immunity.

Google Gemini: US company, subject to US jurisdiction. EU data residency is available via Google Cloud. Same legal exposure as other US providers.

Amazon Bedrock: US company, subject to US jurisdiction. EU deployments available. Provides access to models from Anthropic, Meta, Mistral, Cohere, and Amazon. Same legal exposure as other US providers, with the sovereignty controls described in the AWS European Sovereign Cloud section when deployed there.

Self-Hosted Deployment

Self-hosting separates the AI provider relationship from the infrastructure relationship.

Open-weight models from Meta, Mistral, and others can run on customer-chosen infrastructure. This requires significant technical capability but eliminates the API provider as a jurisdiction concern.

Infrastructure choices remain consequential. Self-hosting on AWS, Azure, or GCP EU regions offers operational simplicity, but the provider remains a US company. Self-hosting on EU-native infrastructure (OVHcloud, Scaleway, T-Systems) reduces US exposure but does not guarantee its elimination. Any EU provider with US operations, US investors, or US revenue may face jurisdictional questions. Due diligence on the corporate structure is required.

Open-weight models on EU-native infrastructure with no US corporate nexus are the only configuration that can achieve sovereignty across all four dimensions. Verify the provider’s corporate structure before assuming this applies.

European Sovereign Joint Ventures: S3NS and Bleu

A different architectural approach has emerged in France: joint ventures between US hyperscalers and European partners, structured specifically to qualify for SecNumCloud certification. These offerings warrant separate analysis because they occupy a distinct position on the sovereignty spectrum—and because their corporate structures provide meaningful protection against US extraterritorial law.

Why These Structures Matter for CLOUD Act and FISA Immunity

The CLOUD Act and FISA Section 702 share a critical limitation: they apply only to entities under US jurisdiction. S3NS and Bleu are neither. Both are French companies, incorporated under French law, majority-owned and controlled by European entities, with no US parent company in their corporate chain. This structural separation places them outside the jurisdictional reach of US surveillance authorities.

This is not a legal technicality. It is the deliberate architectural choice that enables SecNumCloud qualification. ANSSI’s SecNumCloud 3.2 framework specifically requires that non-EU entities cannot collectively hold more than 39% of the capital or exercise control over the certified provider. By satisfying these ownership thresholds, S3NS and Bleu achieve something US hyperscalers structurally cannot: immunity from US legal compulsion over customer data.

The US government cannot serve a CLOUD Act warrant on S3NS or Bleu because neither company is a US person or subject to US jurisdiction. The US government cannot compel FISA Section 702 collection from these providers because they are not US electronic communication service providers. Google and Microsoft, as the technology licensors, do not have access to customer data stored in these sovereign environments — the joint venture operators control the infrastructure, and the technology flows in one direction only.

S3NS (Thales + Google Cloud)

S3NS is a French company majority-owned and controlled by Thales, created in partnership with Google Cloud. In December 2025, its PREMI3NS offering received SecNumCloud 3.2 qualification from ANSSI — the first solution combining US hyperscaler technology with French operational control to achieve this certification.

The ownership structure is designed around SecNumCloud’s requirements. Google Cloud cannot hold more than 24% of share capital or voting rights individually, nor exceed 39% collectively as a non-EU entity. Thales, a French defense and technology company with no US parent, maintains majority control. This places S3NS firmly under French jurisdiction with no path for the US legal process to reach customer data.

S3NS operates three data centers in France, staffed exclusively by S3NS employees. All Google Cloud technologies and updates are quarantined, analyzed, and validated by S3NS before deployment. Google personnel have no operational access to customer data or infrastructure.

PREMI3NS provides access to core Google Cloud services, including Compute Engine, Cloud Storage, Cloud SQL, Google Kubernetes Engine, and BigQuery. Early adopters include companies from insurance (MGEN, Matmut, AGPM), manufacturing (Thales, Birdz), finance (Qonto, BConnect), and services (Club Med). EDF selected S3NS for strategic data storage and processing. Thales itself uses PREMI3NS for internal IT and sensitive engineering workloads.

Bleu (Orange + Capgemini + Microsoft)

Bleu is a joint venture created by Orange and Capgemini to deliver Microsoft Azure and Microsoft 365 services under a “Cloud de Confiance” model. The company launched commercial activities in January 2024 and achieved SecNumCloud Milestone 1 (J1) in November 2025. Full SecNumCloud 3.2 qualification is expected to follow, though the timeline has not been publicly confirmed.

Like S3NS, Bleu’s corporate structure places it outside US jurisdiction. Orange and Capgemini — both French companies with no US parent — own 100% of Bleu. Microsoft is a technology licensor, not an owner or controller. This separation means US authorities have no legal mechanism to compel Bleu to produce customer data, regardless of Microsoft’s role as the underlying technology provider.

Bleu operates from geographically distributed data centers across France, separate from Microsoft’s standard Azure infrastructure. The company targets the French State, public agencies, hospitals, regional authorities, Operators of Vital Importance (OIVs), and Essential Service Operators (OSEs). Orange Business has announced it will migrate 70% of its IT infrastructure to Bleu, providing operational validation at scale.

What These Structures Achieve

Both S3NS and Bleu solve a specific regulatory problem: how to access hyperscaler capabilities while satisfying SecNumCloud requirements that US-owned providers cannot meet.

Legal immunity from US extraterritorial law. The joint venture structure places the operating entity under French law, with majority European ownership and control. US authorities cannot compel these French companies to produce data because they lack jurisdiction over them. This is categorically different from contractual commitments by US providers to challenge requests — it eliminates the legal basis for requests entirely.

Operational sovereignty. French data centers operated by French employees, with no direct operational access by US hyperscaler personnel. Administrative functions, support, and incident response remain under EU jurisdiction.

Technology access with security controls. Organizations gain access to the breadth of Azure or Google Cloud services — something no EU-native provider can match — while maintaining compliance with France’s most stringent security certification.

ANSSI validation. SecNumCloud qualification is not a rubber stamp. ANSSI’s requirements span technical, operational, and legal dimensions. S3NS passed all four milestones of the qualification process (J0 through J3). ANSSI has emphasized that qualification reflects verified compliance with defined criteria, not political considerations.

What These Structures Do Not Resolve

The joint venture model addresses legal and operational sovereignty at the operating company level. It does not eliminate all concerns related to the underlying technology.

Technology dependence. S3NS runs Google Cloud technology. Bleu runs Microsoft technology. The operating companies do not own this intellectual property. They license it, validate it, and operate it — but they depend on continued access to updates, security patches, and new capabilities from their US partners.

Supply chain depth. The technology stack includes components developed in the US. While S3NS quarantines and validates updates before deployment, the fundamental innovation pipeline flows from Google and Microsoft engineering teams.

Theoretical scenarios. In an extreme geopolitical scenario in which US companies are prohibited from licensing technology to European entities, these joint ventures would face challenges to their continuity. This is not a current regulatory concern, but it represents a residual dependency that fully sovereign alternatives would not have.

Service scope limitations. SecNumCloud qualification applies to specific certified services. Not every Google Cloud or Microsoft service is available through S3NS or Bleu. Organizations requiring capabilities outside the certified scope must look elsewhere or wait for the service catalog to expand.

Operational Comparison: Capability vs. Sovereignty

The most consequential difference between sovereign joint ventures and full hyperscaler deployments is operational capability. Organizations evaluating these options must understand what they gain and what they give up.

Service catalog breadth. AWS offers over 200 services globally. The AWS European Sovereign Cloud launched in January 2026 with approximately 90 services, including Amazon Bedrock, SageMaker, EC2, Lambda, and core infrastructure services. S3NS PREMI3NS offers IaaS, PaaS, and CaaS services built on Google Cloud technology — described as the broadest SecNumCloud-qualified offering available. Bleu will provide Microsoft 365 and Azure services, with the specific catalog to be confirmed upon full qualification.

Feature lag. S3NS operates a quarantine process where all Google Cloud technologies and updates are received, analyzed, and validated before deployment. This security control — required for SecNumCloud compliance — means new features arrive in PREMI3NS with a delay compared to standard Google Cloud regions. The same pattern will apply to Bleu. AWS European Sovereign Cloud, while not SecNumCloud-qualified, operates with its own release cadence — generally faster than SecNumCloud quarantine requirements but still behind global AWS regions.

AI and machine learning capabilities. This is where differences are most visible. AWS European Sovereign Cloud includes Amazon Bedrock with models from Anthropic, Meta, Mistral, and Amazon, available from launch. S3NS states it is preparing to integrate generative AI solutions into PREMI3NS, but these solutions are not yet available in the SecNumCloud-qualified environment. Bleu’s AI capabilities will depend on Microsoft Copilot and Azure AI integration into the sovereign platform. Organizations building AI-intensive applications face a concrete choice: deploy on AWS European Sovereign Cloud with immediate Bedrock access (accepting that AWS cannot achieve SecNumCloud qualification), or wait for S3NS and Bleu to expand their AI offerings (accepting deployment delays but gaining SecNumCloud eligibility and CLOUD Act immunity).

Geographic footprint. AWS European Sovereign Cloud launched in Brandenburg, Germany, with planned expansion to Belgium, the Netherlands, and Portugal through sovereign Local Zones. S3NS operates from data centers in the Paris region. Bleu operates from distributed data centers across France. Organizations with strict in-country data residency requirements beyond France may find S3NS and Bleu insufficient regardless of their SecNumCloud status.

Operational maturity. AWS brings nearly two decades of experience in cloud operations. S3NS has been operating commercially since 2024, with approximately 60 customers across its offerings as of late 2025. Bleu has been conducting pilot engagements and preparing migrations. These are meaningful reference deployments, but the operational track record is shorter than established hyperscaler regions.

Pricing. Sovereign offerings carry premium pricing reflecting smaller scale, dedicated infrastructure, and specialized operations. The premium is the price of sovereignty controls — whether it represents acceptable value depends on specific compliance requirements and risk tolerance.

AWS European Sovereign Cloud

Given these options, AWS’s European Sovereign Cloud merits examination as the most comprehensive response from a US hyperscaler. AWS launched this offering on January 15, 2026.

Structural Separation: A new German parent company (AWS European Sovereign Cloud GmbH) operates separately from AWS’s standard hierarchy, with its own subsidiaries for infrastructure, certificates, and employment. Financial flows stay within this European structure, though Amazon.com remains the ultimate owner. Infrastructure is in Brandenburg, Germany, with Local Zones planned for Belgium, the Netherlands, and Portugal. Logically isolated from other AWS regions with independent control planes, IAM, and DNS.

Operational Controls: Day-to-day operations exclusively by EU-resident personnel. AWS is transitioning to EU citizenship requirements. The sovereign cloud has no critical dependencies on non-EU infrastructure. In extreme scenarios, EU-resident staff have independent access to source code replicas needed to maintain services.

Service Availability: Amazon Bedrock runs in the European Sovereign Cloud from launch, providing access to models from Anthropic, Meta, Mistral, and Amazon. Additional options include Dedicated Local Zones, AI Factories, and Outposts.

Customer-Controlled Encryption: Customers maintain exclusive control over keys, preventing AWS from accessing plaintext data.

Certifications: BSI C5 attestation from Germany’s Federal Office for Information Security. France’s ANSSI has not granted SecNumCloud certification. The French requirements exclude providers with US ownership.

Separately from the European Sovereign Cloud, AWS introduced Mantle in late 2025 as the inference engine for Amazon Bedrock. Mantle implements a zero-operator access design: there is no mechanism for any AWS operator to access customer prompts or completions during inference. This provides meaningful protection against insider threats and is available across all AWS regions. Mantle addresses technical access during inference but does not change the legal jurisdiction analysis.

What Remains Unsolved

Despite substantial investment, fundamental gaps persist for any US-owned provider.

Legal Jurisdiction: Amazon.com is a US corporation. AWS European Sovereign Cloud GmbH is ultimately owned 100% by Amazon.com. US law applies to US companies and their controlled entities regardless of data location or operational structure. AWS would challenge conflicting requests and reports zero European enterprise data disclosures to date. However, CLOUD Act confidentiality provisions may prohibit disclosure of compliance in certain cases, meaning the absence of reported disclosures does not necessarily indicate none exist. AWS’s position reflects litigation choices, not legal immunity.

Intelligence Collection: FISA Section 702 authorizes collection from US providers without public legal process. Technical controls provide resistance, but the opacity of intelligence collection makes assessment difficult.

SecNumCloud Exclusion: France’s highest certification requires no corporate nexus to non-EU jurisdictions. AWS European Sovereign Cloud cannot qualify without severing Amazon’s ownership. Organizations requiring SecNumCloud cannot use AWS.

Contractual vs. Structural Protections: AWS’s sovereignty commitments are contractual and operational in nature. Contracts can be modified, waived under pressure, or breached with civil liability consequences. S3NS and Bleu offer structural protection — the legal basis for US compulsion does not exist. This is a meaningful distinction.

Strategic Implications by Segment

Private Sector: US providers are generally acceptable. Priorities are functionality, time-to-value, and integration. Select based on technical merit.

Regulated Industries: US providers are generally acceptable when appropriate controls are in place. Procurement focuses on compliance documentation. AWS European Sovereign Cloud with Bedrock provides a strong compliance posture. Document residual legal exposure in risk assessments. For most use cases, this is an accepted residual risk.

Public Sector with Sovereignty Mandates: Cannot use US-owned providers regardless of technical controls. Consider S3NS or Bleu, where SecNumCloud is required — these provide both compliance and legal immunity from US jurisdiction. For workloads outside their service catalogs, self-hosted open-weight models on EU-native infrastructure may be necessary.

Defense and Intelligence: Zero US involvement end-to-end is the stated standard. Even S3NS and Bleu may be insufficient given technology licensing relationships with US companies. On-premises deployment with audited supply chains is typical. Yet practice diverges from doctrine: France’s DGSI renewed a three-year contract with Palantir in December 2025, extending a partnership dating to 2016. French domestic intelligence apparently concluded that Palantir’s capabilities outweigh sovereignty concerns — a pragmatic exception that complicates any absolutist position on US technology in sensitive contexts.

Operationalizing This Framework

Contractual Protections

When customers raise sovereignty concerns, these contractual elements address most legitimate requirements.

Data Processing Agreements should specify EU-only residency, prohibited third-country transfers, and subprocessor controls. Audit rights should cover compliance certifications, penetration test results, and third-party audit rights. Notification commitments should require alerting customers to government data requests (where legally permitted) and challenging conflicting requests before compliance. Encryption provisions should specify customer-managed keys that prevent the provider from accessing plaintext. Jurisdiction clauses should specify the EU courts and law applicable to disputes.

These provisions do not eliminate CLOUD Act exposure for US providers. They establish clear expectations and create a record that strengthens any provider challenge to an overreaching request. For organizations requiring elimination of CLOUD Act exposure rather than mitigation, S3NS or Bleu provide structural solutions that contracts cannot.

Qualifying Sovereignty Objections

When a prospect claims they “need sovereignty” or “cannot use US clouds,” these questions distinguish genuine requirements from assumptions that have not been validated.

Which specific regulation requires this? If the answer is vague (”GDPR” without specifics, “our security policy”), the requirement may be assumed rather than verified. GDPR does not prohibit US providers.

Has your legal team reviewed this? Many sovereignty objections originate from procurement or IT without legal validation. A legal opinion changes the conversation. Absence of one suggests the objection is precautionary rather than mandated.

What is your current cloud provider? Organizations running SAP on Azure or analytics on AWS, while claiming they cannot use US clouds for AI, have an inconsistency worth exploring.

What specific threat are you protecting against? If the concern is CLOUD Act disclosure, have they assessed the likelihood and impact? If the concern is intelligence collection, is their data plausibly of interest to US agencies?

Would AWS European Sovereign Cloud satisfy the requirement? If yes, the requirement is addressable with existing solutions. If not, would S3NS or Bleu satisfy it? Understanding the specific gap clarifies whether genuine compliance requirements exist.

Liability and Insurance

Boards ask: if data is disclosed under a CLOUD Act request despite protections, what is our exposure?

Direct liability depends on data type and contract terms. If contracts include indemnification for breaches caused by subprocessor compliance with foreign orders, the SaaS provider may bear liability. Most enterprise contracts carve out liability for lawful government orders that the provider contested in good faith.

Cyber insurance coverage for government-compelled disclosure varies. Review policies with brokers to confirm CLOUD Act scenarios are covered, excluded, or ambiguous. Some insurers now offer specific cross-border data access coverage.

According to their transparency reports, no major cloud provider has publicly disclosed European enterprise or government data under the CLOUD Act. This represents non-zero but low practical risk — nearly eight years without public materialization since the CLOUD Act’s passage in March 2018. FISA is a black hole, and we’ll never know. For organizations requiring certainty rather than acceptable risk, S3NS and Bleu eliminate the legal basis for compulsion entirely.

Competitive Positioning

When a European competitor claims “sovereign AI” and questions your US infrastructure, respond factually.

First, define sovereignty using the four-dimensional framework. Most competitors address one or two dimensions while claiming full sovereignty.

Second, probe their stack for US components. Models trained on US infrastructure, dependencies on US cloud services, US investors with board seats, or US revenue all create potential jurisdictional exposure.

Third, reframe the comparison. The question is not “US versus EU” but “what protections does each option provide against what threats?” AWS European Sovereign Cloud with customer-managed encryption may offer stronger practical protection than a smaller EU provider with less mature security controls. S3NS and Bleu offer both hyperscaler capability and legal immunity.

Fourth, focus on outcomes. Certifications obtained, audits passed, regulated customers served, zero incidents. These matter more than the headquarters location.

Market Validation

Regulated industries in Europe have adopted US hyperscaler infrastructure for sensitive workloads. Major EU financial institutions use cloud services from AWS, Azure, and Google Cloud, with multi-cloud strategies predominating. Healthcare organizations in EU member states process patient data on US cloud infrastructure under GDPR, though adoption varies by country and regulatory interpretation. The European Commission continues to use Microsoft 365; after the European Data Protection Supervisor found compliance issues in March 2024, the Commission implemented corrective measures and was confirmed compliant in July 2025 — demonstrating that US cloud services can satisfy EU requirements with appropriate safeguards.

These precedents establish that US cloud adoption is standard practice in regulated European industries. Organizations claiming a categorical inability to use US providers should be asked to identify the specific regulation or threat model that underlies that position.

Conclusion

US hyperscalers and frontier AI models offer the fastest path to competitive AI capabilities. AWS European Sovereign Cloud and similar solutions provide data residency, operational controls, customer-managed encryption, and compliance certifications that satisfy most European organizations. This combination of capability, scale, and compliance posture is difficult to replicate.

Full legal sovereignty — meaning immunity from US jurisdiction — is necessary for explicit SecNumCloud mandates, defense and classified workloads, and organizations whose threat model specifically includes US government legal process. For these cases, S3NS and Bleu now offer viable paths to hyperscaler capability with genuine legal protection. Their corporate structures place them entirely outside CLOUD Act and FISA jurisdiction — a structural guarantee that US providers cannot match, regardless of their technical controls.

For organizations not facing explicit mandates, the sovereignty question is a matter of risk management. Accepting residual CLOUD Act exposure from US providers is reasonable when that risk is documented, understood by stakeholders, and acceptable given the probability and impact assessment. This approach has been validated by widespread adoption across European regulated industries.

The strategic discipline is distinguishing organizations with genuine compliance obligations or elevated threat models from those with assumptions that have not been validated. Build for the former with appropriate solutions. Help the latter understand their actual requirements and options.