Key facts
| Data planes | EU (Frankfurt), GCC (UAE), APAC (Singapore) and US (Virginia) region-locked planes |
| Processing boundary | Requests, logs, embeddings and stored artefacts stay in the selected plane |
| Deployment tiers | In-region cloud, private endpoint in your VPC, on-prem and air-gapped |
| Failover | Multi-region failover designed to respect the jurisdiction you select |
| Contracts | DPA with GDPR Article 28 terms, SCCs and PDPL alignment; subprocessor list published |
| Latency note | A strict boundary can add round-trip time — measure p50 and p95 before cut-over |
| Data mapping | Pin prompts, embeddings, logs and artefacts to one approved plane |
| Retention | Configurable prompt retention; minimise PHI before prompting |
TL;DR
- Region-locked planes keep requests, logs and artefacts in the jurisdiction you select.
- VPC, on-prem and air-gapped tiers cover in-country processing requirements.
- Validate with de-identified data first, then move protected data behind the proven boundary.
- Embeddings and indexes must follow the same residency as the source records.
- Start free with plugsky-micro and plugsky-lite; a 14-day full-access trial covers larger models.
How it works, step by step
- Classify the workload's data and pick the plane or deployment tier it requires.
- Pin the workspace to that boundary and confirm prompts, embeddings, logs and backups follow it.
- Collect the DPA, subprocessor list and region-scoped audit exports for review.
- Map clinical data flows and assign each an approved plane or deployment tier.
- Pilot on de-identified content and verify audit export before clinical use.
- Confirm on-prem or VPC options where hospital policy requires them.
Try it yourself
Open the data residency checker →
Data residency for healthcare teams: what changes
Healthcare data residency questions come from privacy law, hospital policy and patient trust at the same time. The practical work is mapping clinical data flows — notes, orders, messages — and ensuring prompts, embeddings and logs from those flows stay inside the approved boundary.
A region-locked data plane keeps processing and storage in the jurisdiction you select instead of routing globally by default. Plugsky exposes EU (Frankfurt), GCC (UAE), APAC (Singapore) and US (Virginia) planes; requests, logs, embeddings and stored artefacts stay in the chosen plane. Where in-country processing is mandatory, the same OpenAI-compatible API runs in your VPC, on-prem or air-gapped, putting the boundary under your control.
Architecture and controls
Pin the workload to an approved plane, set prompt retention to the minimum policy allows, and redact identifiers before they reach the model. Keep embeddings and indexes in the same jurisdiction as the source documents, and export region-scoped audit events to the compliance pipeline.
Integration pattern and rollout
Start with a de-identified or low-sensitivity corpus to validate retrieval quality and the operational path, then move to protected data once the boundary is proven. Because the API is OpenAI-compatible, clinical tooling changes only the base URL and model name.
Residency is architecture plus evidence: map every store — prompts, embeddings, logs, backups — to a plane, confirm that failover respects the jurisdiction, and review the DPA, subprocessor list and region-scoped audit exports. Latency and residency trade off, because a strict boundary can mean longer round trips than a globally distributed endpoint.
Limits, evidence and cost
Residency does not equal de-identification, and it does not replace a privacy programme. Where cross-border processing is prohibited, validate the deployment tier and the support model, not just the storage location.
Self-serve pricing is flat monthly with unlimited fair-use usage, so pinning a workload to a plane does not change the billing model — see the live pricing page. Start on the free plan with plugsky-micro and plugsky-lite and no card, and use the 14-day full-access trial to evaluate larger models.
Honest comparison
| Concern | Plugsky residency | Typical global API | Self-hosted |
|---|---|---|---|
| Plane choice | EU, GCC, APAC and US region-locked planes | Few regions, global default routing | Wherever you install it |
| Store coverage | Prompts, embeddings, logs and artefacts follow the plane | Varies by service | You own every store |
| Failover | Designed to respect the selected jurisdiction | Often global | Your DR design |
| Evidence | Region-scoped logs, DPA and subprocessor list | Contract-level commitments | You produce all evidence |
| Operational load | Managed planes with configurable residency | Managed, limited control | Hardware, patching and capacity |
| Clinical data boundary | Prompts, embeddings and logs follow the approved plane | Limited regions | You map every store |
Frequently asked questions
How do we verify data residency?
Check the plane configuration, confirm that prompts, embeddings, logs and backups follow the boundary, review the DPA and subprocessor list, and test failover behaviour.
Which regions are available?
Plugsky exposes EU (Frankfurt), GCC (UAE), APAC (Singapore) and US (Virginia) region-locked planes, plus VPC, on-prem and air-gapped deployment options. See the docs for current detail.
Does residency add latency?
It can. A strict boundary may mean longer round trips than a globally distributed endpoint, so measure p50 and p95 from your own production network before committing.
Do embeddings and indexes need the same residency?
Yes. Vectors and indexes are derived from clinical text, so keep them in the same approved boundary as the source documents.
Can we keep PHI out of prompts?
Redact identifiers before inference where policy allows, and set prompt retention to the minimum. Residency controls location; minimisation reduces exposure.
What about on-prem options?
Where hospital policy requires it, the same OpenAI-compatible API can run on-prem or in your VPC so data never leaves your estate.