When sovereignty becomes a design constraint
Sourcing starts with a risk register now For a decade the infrastructure question had one default answer: put it in the …
Why Pharma Has the Hardest Residency Problem
Of every industry with a data-residency posture to defend, pharmaceutical and life-sciences organizations carry the most stringent rules — and they carry them across multiple overlapping jurisdictions simultaneously.
A multi-site clinical trial running in 2026 might involve patient data from twelve countries. Each country has its own data-protection authority, its own clinical-trial regulator, and its own rules about which categories of data may leave the jurisdiction under what conditions. EMA (European Medicines Agency) for the EU. FDA for the US. PMDA for Japan. NMPA for China. ANVISA for Brazil. MHRA for the UK. Plus GDPR overlaid on all EU sites, HIPAA on US sites, and country-specific health-data laws on every other site.
A pharma organization that runs AI workloads — for clinical-data analysis, trial-protocol design, regulatory-submission drafting, patient-recruitment optimization, real-world-evidence studies — is, in practice, running those workloads across data that cannot uniformly leave any of those jurisdictions. The architectural response is not “host everything in one region.” It is workload-specific data flow with audit evidence per jurisdiction.
This is why the horizontal data-residency argument lands hardest in pharma. The general case is “data sovereignty matters more than vendors admit.” The pharma case is “data sovereignty is contractually obligated by hundreds of trial agreements simultaneously, and one residency violation is a regulatory submission delay measured in months.”
The Specific Data Categories That Matter
┌──────────────────────────────────────────────────────────────┐
│ │
│ Data category Residency posture │
│ ─────────────────────── ────────────────────────── │
│ │
│ Patient PII Must stay in country of │
│ collection (most jurisdictions);│
│ limited cross-border transfer │
│ under specific legal basis │
│ │
│ Clinical-trial source Country of trial site + │
│ data country of sponsor; data │
│ processing agreements per │
│ country regulator │
│ │
│ Anonymized / aggregated Looser residency, but │
│ trial outputs re-identification risk │
│ creates uncertainty │
│ │
│ Regulatory submissions Per-jurisdiction (EMA, FDA, │
│ etc.); content must align │
│ with that regulator's format │
│ and expectations │
│ │
│ Manufacturing / GMP Site-specific; some data must │
│ data stay at the manufacturing site │
│ for inspection purposes │
│ │
│ Adverse-event reports Multi-jurisdictional reporting; │
│ residency rules vary by │
│ severity and jurisdiction │
│ │
│ IP / molecule data Internal classification; │
│ often controlled at the trade- │
│ secret level rather than the │
│ regulatory level │
│ │
└──────────────────────────────────────────────────────────────┘
Each row has different residency rules. Each row may produce input for an AI workload — analyzing the data, drafting documents from it, finding patterns across it. The AI workload inherits the strictest applicable residency rule of any input it touches.
This is what most mid-market pharma organizations get wrong: they classify the workload uniformly (e.g., “our AI assistant runs on EU infrastructure”) instead of classifying the data flowing through the workload per request. A single chat session with a clinical-research assistant might include data subject to three different jurisdictional rules over the course of an hour. The infrastructure choice is necessary but not sufficient; the residency must be enforced per request.
The Three Failure Modes Most Common in Pharma
┌──────────────────────────────────────────────────────────────┐
│ │
│ Failure 1 — Consumer AI in a researcher's hands │
│ ────────────────────────────────────────────────── │
│ Researcher pastes a de-identified case report into │
│ ChatGPT to draft a summary. The de-identification is │
│ thinner than the researcher believes (specific dates, │
│ rare condition combinations, study-site clues). Data │
│ leaves jurisdiction. No audit. Detection is unlikely. │
│ │
│ Failure 2 — Multi-region trial data joined in the cloud │
│ ────────────────────────────────────────────────────── │
│ Trial sites in EU, US, and Japan upload data to a │
│ single analysis platform "for unified analytics." The │
│ joined dataset is, in practice, a cross-border transfer │
│ that violates trial agreements. Detection is by audit, │
│ months later. │
│ │
│ Failure 3 — Submission AI calling a US-hosted model │
│ ────────────────────────────────────────────────── │
│ AI tool used to draft an EMA submission calls a │
│ US-only foundation-model endpoint. EU patient context │
│ in the prompt. The submission lands; the inference │
│ trail is a Schrems II problem buried in the audit logs │
│ nobody reviews. │
│ │
└──────────────────────────────────────────────────────────────┘
All three are routine. All three are detectable only by an architecture that enforces residency at the point of data flow — not by trusting the researcher, the analyst, or the application developer to remember the rules.
What the Architecture Looks Like in Pharma
The horizontal architecture from the data-residency piece applies directly, with a pharma-specific configuration:
┌──────────────────────────────────────────────────────────────┐
│ │
│ Pharma Application / Researcher Workbench │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────┐ │
│ │ Policy Gateway │ │
│ │ ────────────────────── │ │
│ │ Classifies every request by: │ │
│ │ - data category │ │
│ │ - jurisdiction of origin │ │
│ │ - applicable trial agreement │ │
│ │ - submission destination │ │
│ └──────────────┬─────────────────────┘ │
│ │ │
│ ┌─────────────┼─────────────┬─────────────┐ │
│ ▼ ▼ ▼ ▼ │
│ EU-hosted EU-only JP-hosted Local model │
│ Anthropic Mistral endpoint (Ollama or │
│ endpoint vLLM, inside │
│ the perimeter) │
│ │
│ Each routing decision recorded with: │
│ - data category │
│ - jurisdictional rule applied │
│ - destination region │
│ - human and agent identity │
│ - approval (if applicable) │
│ │
└──────────────────────────────────────────────────────────────┘
The classification step is the part most pharma organizations skip. It requires explicit metadata on the data: where it came from, which trial agreement governs it, what category it falls into. Most pharma data warehouses do not carry this metadata at the row level today. Getting that classification in place — at ingestion, not retrofit — is often the largest single uplift in a residency-driven AI rollout.
Once the classification is in place, the policy gateway uses it to enforce routing at every model call. A request with EU patient PII routes to EU endpoints only. A request with Japanese trial data routes to JP endpoints. A request with US-only data can be routed more flexibly. The audit chain records each decision, producing the compliance evidence regulators expect.
The Submission Workflow, Specifically
AI-assisted regulatory-submission drafting is one of the most valuable pharma AI use cases — and one of the most residency-sensitive. A submission to EMA, FDA, or PMDA requires the right format, the right tone, the right references, and the right data inclusions per regulator. AI tools can produce dramatic productivity gains here.
The residency wrinkle: the model used to draft an EMA submission should not see context from a US-only data source, and vice versa. The submission workflow has to split context by destination regulator and route accordingly.
Submission target: EMA Submission target: FDA
────────────────── ──────────────────
AI Drafter Session AI Drafter Session
Context: EU-trial data only Context: US-trial data only
Routes to: EU model endpoints Routes to: US or EU endpoints
Audit: EMA-scoped trail Audit: FDA-scoped trail
The policy gateway is what makes this real. The submission application requests context; the gateway returns only the context allowed for the destination; the model call routes to the allowed destination; the entire flow is audit-trailed against the submission record.
Where Open-Source Models Earn Their Place
For the strictest pharma workloads — the ones touching the most sensitive patient data or the most jurisdictionally-constrained clinical trial information — running an open-source model inside the perimeter is increasingly the answer.
Open-source models in 2026 (Llama, Qwen, DeepSeek, Mistral’s open variants, plus the deeper Mistral commercial tier hosted in-region) are good enough for a large class of pharma tasks: summarization, classification, extraction, drafting from existing context. They are not as capable as the frontier proprietary models for the hardest reasoning tasks. But for residency-strict workloads, they have a property no API-accessible model has: the inference never leaves the perimeter at all.
The Calliope workbench and Astrolift runtime both support inference via Ollama or vLLM endpoints hosted inside the customer’s cloud. The same policy gateway routes appropriate requests to those endpoints. A submission-drafting workload that needs to stay 100% inside the EU perimeter can route to local Mistral models running inside the EU Astrolift install. No external inference. No Schrems II concern. Full residency.
The Practical Rollout
For a mid-sized pharma organization with multi-region trials:
Weeks 1–4 Classification baseline
─────────────────────────
Map data sources to residency
classes. Tag at ingestion
going forward. Backfill where
feasible. Most pain lives here.
Weeks 5–10 Stand up the platform
─────────────────────────
Astrolift in EU primary cloud
+ secondary regions as needed.
Zentinelle policy gateway with
pharma-specific evaluators.
Local inference (Mistral /
Ollama) deployed.
Weeks 11–18 Migrate AI workloads
─────────────────────────
Submission drafter. Clinical
data analytics. Research
assistant. Adverse-event
workflows. Each migrated with
residency policy and tested
against trial agreements.
Weeks 19–22 Compliance walkthrough
─────────────────────────
External audit refresh.
GDPR Article 30 evidence review.
Per-regulator submission of
control-effectiveness reports.
Five to six months from start to a residency-defensible AI posture for a mid-sized pharma. The single most variable factor is the classification work in weeks 1–4; organizations with mature data-catalog discipline move faster.
The Question Worth Asking
For pharma specifically, the diagnostic question is:
For each of your active clinical trials, can you produce evidence that AI tools used in connection with that trial have honored every data-residency clause in the trial agreement and every applicable data-protection law in every site country?
Almost no mid-market pharma organization can answer yes today. The architecture that produces a defensible yes is the one outlined above: BYOC runtime, classified data, policy-gated inference, audit-chained evidence.
The cost of getting this wrong is not abstract. A residency violation in connection with a clinical trial can delay regulatory submission, require breach notification, and in the worst cases, void the trial site’s data contribution to the submission. The math of building the architecture versus risking one violation is straightforward.
Where to Go Next
- The horizontal data-residency piece — the architectural argument independent of vertical.
- Astrolift — multi-region BYOC runtime suitable for pharma’s multi-jurisdictional reality.
- Zentinelle.ai — the policy gateway and audit chain that produce GDPR Article 30 evidence as a side effect.
- AI for Pharma: Accelerate Research, Protect Data — the broader pharma pitch.
- calliope.ai/contact — for a pharma-specific residency conversation.
