Why OpenEvidence's EU/UK Withdrawal push Healthcare Toward Private On-prem or sovereign cloud

When OpenEvidence became unavailable in the European Union and the United Kingdom, my first reaction was this is not just a product availability issue, I told you it will happen.

OpenEvidence has positioned itself as a medical AI system that answers clinical questions using sourced, cited, peer-reviewed medical evidence. Public descriptions and independent medical AI research characterize it not as a standalone general chatbot, but as a retrieval-augmented generation system: an LLM layer connected to curated medical literature, citations, and clinical evidence sources: including licensed/partner content such as NEJM, JAMA, NCCN, and Cochrane. That distinction matters. In healthcare, the difference between “a model answered from memory” and “a system grounded in controlled medical sources” is not cosmetic. It is the product.

So I wanted to understand what really happened.

OpenEvidence appears to have withdrawn from the EU and UK while citing “OpenEvidence is not available in the European Union or the U.K.

On April 2026 in EU

Link 1: https://news.bloomberglaw.com/us-law-week/eu-ai-acts-burdensome-regulations-could-impair-ai-innovation

Link 2: https://drive.google.com/file/d/1wrtxfvcD9FwfNfWGDL37Q6Nd8wBKXCkn/view?pli=1.

At first glance, that explanation sounds simple: Europe has stricter AI regulation, so OpenEvidence paused the region.

So why leave the EU and UK?

“We are not generating a funny image we talk about patient privacy”

I started reviewing the trust and compliance trail, the story became more interesting.

OpenEvidence’s public Trust Center “https://trust.openevidence.com/” looks like a serious vendor with controls such as SOC 2, HIPAA, GDPR, and other security and privacy commitments not the profile of a casual AI wrapper trying to avoid compliance entirely.

I also checked the Data Privacy Framework list “https://www.dataprivacyframework.gov/list ”. On April 2026 OpenEvidence appears to be listed there, meaning it can rely on the EU-U.S. Data Privacy Framework for qualifying transfers from the EU to the United States, assuming the transfer and onward-processing chain is correctly documented.

The more important question is not only whether OpenEvidence itself has a strong compliance. The real question is: who else touches the data, the prompts, the embeddings, the inference calls, the logs, the training infrastructure, and the model-serving layer?

In healthcare the subprocessor chain is often where the real regulatory risk lives.

For the practical review workflow behind this risk, see our guide to GDPR subprocessor management in EU healthcare.

That led me to Baseten Labs who’s public Trust Center https://trust.baseten.co lists compliance areas including GDPR, HIPAA, SOC 2 Type 2, and SOC 3.

It also publicly lists OpenEvidence among companies that review or trust Baseten.

OpenEvidence using Baseten for AI infrastructure, and it’s appears to be more than a minor vendor in the stack. It appears to be part of the core AI delivery infrastructure on the same line as OpenAI and Anthropic which models is using OpenEvidence according the https://www.deploygraph.com/company/openevidence

This is where the situation becomes sharp

Despite Baseten Labs have GDPR eligibility badge in April 2026, I couldn’t find them on https://www.dataprivacyframework.gov/list

It does mean something very specific:

“Baseten is not certified under the EU-U.S. Data Privacy Framework”

The parties would need another lawful transfer mechanism, typically Standard Contract and a clearly documented subprocessor chain.

“For ordinary SaaS data, that is already serious. For healthcare AI, it is much more serious”

EU healthcare data is not normal SaaS data

EU health data is special-category personal data under GDPR Article 9, so it requires a clear legal basis and stronger safeguards.

If a healthcare provider uses an external AI vendor, GDPR Article 28 also requires that vendor — and its subprocessors — to provide sufficient guarantees for compliant processing.

And if data is transferred outside the EU, GDPR Chapter V requires a valid transfer mechanism, such as DPF for certified U.S. companies or SCCs with appropriate safeguards. (The DPF itself survived the Latombe annulment action before the EU General Court in September 2025, though an appeal is pending at the Court of Justice — it stands today, but it is a mechanism to monitor.)

Now add the AI Act. If a medical AI system supports clinical workflows, diagnosis, treatment, or regulated medical-device functions, it may trigger high-risk obligations around documentation, oversight, monitoring, and risk management — applying from December 2027 for stand-alone Annex III systems and August 2028 for device-embedded AI, after the deferral in the June 2026 Digital Omnibus.

That is also why clinical AI deployments usually need a Data Protection Impact Assessment before deployment, not after the architecture is already locked in.

That creates a difficult position for any U.S.-hosted clinical AI provider serving EU healthcare customers.

• It is not enough to say: “We are SOC 2 certified.”
• It is not enough to say: “We are HIPAA compliant.”
• It is not enough to say: “We have a GDPR logo in the Trust Center.”

My view is that the withdrawal was probably not caused by just this particular one issue.

OpenEvidence has not publicly explained the full reason for its EU/UK withdrawal however it might be this complex control Framework EU puts on Healthcare data transfer So this part is my assumption, not a confirmed fact.

OpenEvidence is a clinical AI product, not a generic chatbot.

• Its value depends on retrieval, medical evidence grounding, citations, and workflow trust.
• Its infrastructure appears to include external AI infrastructure providers.
• EU healthcare data requires a strict Article 9 basis, processor guarantees, and transfer controls.
• The AI Act adds another layer of uncertainty around classification, provider/deployer obligations, documentation, and risk management.
• And if a core AI infrastructure provider is not independently covered by DPF, then OpenEvidence would need to prove an alternative transfer and subprocessor chain for EU health-data processing.

This does not prove that Baseten caused the withdrawal. It also does not prove that any party violated GDPR.

But it gives a plausible explanation for why a sophisticated, well-funded, apparently compliance-aware company might decide to pause EU and UK access rather than operate in a gray zone.

“In healthcare, “probably compliant” is not good enough.”

OpenEvidence’s EU/UK withdrawal should not be read as “medical AI cannot work in Europe.”

It should be read as: medical AI must be deployed with sovereignty, auditability, and regulatory architecture from day one.

We have covered the same architectural principle in our analysis of why healthcare needs on-premise AI and in our guide to hybrid AI with European sovereign cloud infrastructure.

Healthcare AI is moving from experimentation to infrastructure. In that phase, the winners will not only be the teams with the best model demos. The winners will be the teams that can answer procurement, legal, clinical safety, data protection, and infrastructure questions with evidence.

OpenEvidence is not magic — it is architecture

There is another part of this story that matters for European healthcare providers.

OpenEvidence is often discussed as if it is a mysterious proprietary AI breakthrough. But based on public information, its architecture appears to follow a known pattern:

• A large language model LLM
• A medical retrieval layer RAG
• RAG sources: PubMed, clinical evidence sources: including licensed/partner content such as NEJM, JAMA, NCCN, and Cochrane.
• Citation grounding
• Search and ranking.

Possible Infrastructure

That is powerful, but it is not impossible to reproduce in a sovereign architecture.

OpenEvidence has not not simply a chatbot.

But real full scale healthcare system: trusted medical sources, retrieval quality, model tuning, user experience, governance, and distribution.

For European hospitals, clinics, insurers, pharma teams, and healthcare technology vendors, that distinction matters. If the public-cloud SaaS version of a clinical AI assistant becomes difficult to use because of GDPR, subprocessors, AI Act uncertainty, or cross-border inference, the answer is not to abandon medical AI.

On-prem, sovereign OpenEvidence-like system is feasible.

Futurion Solutions calculate, provide, Server Hardware with Hight end NVIDIA GPUs, Install it in your clinic and deploy on top of it OpenEvidence-like medical AI system fully on-premises or Hybrid with in AWS European Sovereign Cloud. For organizations that need a packaged private medical AI stack, this is the direction behind MedCore Private AI.

The architecture is straightforward in principle:

• Deploy MedGemma or another open medical/open-weight LLM on the customer’s premises or inside a controlled EU cloud environment.
• Fine-tune the model with the customer’s approved clinical, operational, payer, pathway, or institutional data where legally appropriate.
• Add retrieval-augmented generation over the customer’s own document base: guidelines, protocols, formularies, SOPs, payer rules, drug references, clinical pathways, medical policies, and approved literature.
• Keep embeddings, prompts, outputs, audit logs, and clinical workflow state under the customer’s governance.
• Integrate with existing healthcare systems instead of replacing them.
• Support standards such as FHIR, openEHR, ICD-10 workflows, and structured export packages.
• Add human review, audit trails, role-based access, evidence citations, and monitoring from the start.

This is not just a cheaper version of a U.S. SaaS product.

It can be a better fit for EU healthcare because the model, data, retrieval layer, compliance evidence, and deployment boundary are controlled by the healthcare organization.

General-domain LLMs are trained broadly. They are useful, but they are not medical systems by default. A medical-domain model such as MedGemma, or another carefully selected open model, combined with fine-tuning and private RAG over the organization’s own approved data, can produce a system that is much more relevant to the clinical and administrative reality of that organization than a general LLM answering from internet-scale memory.

The goal is not to copy OpenEvidence’s brand.

The goal is to reproduce the useful pattern — evidence-grounded medical AI — under the customer’s own compliance, infrastructure, and governance model.