Your data stays where you put it, including during inference.
Residency promises from AI providers usually cover storage, not processing, and rarely cover support access or telemetry. Data.co runs inference, retrieval, policy, and audit inside the jurisdiction and infrastructure you choose, so the answer to where the data goes is simple.
Residency is about every hop, not just the database.
A request to a hosted model touches a load balancer, an inference cluster, possibly a logging pipeline, and sometimes a human reviewer for abuse monitoring. Each hop may sit in a different country. For data under GDPR transfer rules, national security requirements, or contractual residency terms, each hop matters.
With Data.co, every hop is in your environment. Models run on servers you place, the policy engine runs next to them, and audit records are written locally. app.data.co, which handles accounts and licensing, never receives prompts, documents, embeddings, or records.
Component location.
| Component | Location | Leaves your environment? |
|---|---|---|
| Prompts and responses | Your AI gateway | No |
| Documents and embeddings | Your storage and vector index | No |
| Model inference | Your GPU servers | No |
| Policy decisions | Your policy engine | No |
| Audit log | Your append-only store | No, unless you export it |
| License and billing | app.data.co | Account metadata only |
Sovereignty configurations we support.
Per-region deployments
Separate instances per country or region, each with its own data and audit log, managed from one policy repository.
Single-facility
Everything in one data center or building, for organizations whose requirement is physical control.
Air-gapped
No network path out, with updates delivered as signed bundles.
Residency-aware routing
Policies that deny sending a data class to any endpoint outside its permitted region.
How to confirm it yourself.
- Inspect egress rules: the deployment requires no outbound access to run
- Review audit records for model endpoint per request
- Confirm model weights are stored locally
- Check that telemetry to Data.co is off by default and opt-in
- Test disconnected operation before go-live
Licensing, updates, and egress without a phone-home.
Sovereignty reviews often stop at where data is stored and miss the control-plane dependencies: license checks, update channels, and support tooling that call home. In Data.co Control, the license is a signed file verified offline against a public key you obtain once and confirm out of band. Expiry moves through a warning period and a grace period before gateways stop serving, so a renewal is a file replacement rather than a network dependency.
Software updates arrive as images you can transfer under your own media procedures and verify by checksum, and policy changes can be delivered as bundles signed by a key you hold. Outbound connections are limited by an egress guard to the inference endpoints and MCP servers you configure; any other destination is rejected before a connection opens, and recent attempts are visible to administrators. An optional heartbeat reports only version, license status, health, and policy set version, and it is refused entirely in air-gapped mode.
Bringing a second region online.
- 1
Map obligations
Your privacy and legal teams list which data classes are bound to which jurisdictions, and which model providers are acceptable in each.
- 2
Deploy per region
Install a separate Control runtime and model servers in each region, each with its own license, audit log, and catalog.
- 3
Share policy, not data
Keep one policy repository, with region attributes in the rules, and deliver signed bundles to each deployment.
- 4
Test the boundary
Write policy tests that try to route a bound class to an out-of-region endpoint and confirm the deny before go-live.
- 5
Keep evidence local
Each region's audit log stays in that region; reporting aggregates counts, not content.
Questions buyers ask
Does Data.co collect telemetry from deployments?
Opt-in administrative features may send account-level metadata to app.data.co. Prompts, documents, embeddings, and records are never sent, and the deployment runs without any outbound connection.
Can Data.co support staff access our data?
Not unless you grant access. Support works from information you choose to share. Managed services engagements define access explicitly in your agreement.
Does running locally satisfy GDPR transfer rules?
Keeping processing inside the EU or EEA removes the AI processing step from the transfer question, which can simplify your analysis. Whether your overall setup meets GDPR requirements is a determination for your privacy team and counsel.
Can we run different regions with different models?
Yes. Each deployment has its own model catalog, so you can meet local requirements on model provenance or language.
What happens if our license expires while disconnected?
The runtime warns ahead of expiry, keeps enforcing through a grace period while reporting a degraded state, and only then stops serving. Renewal is a new signed file loaded locally.
Can users in one region query data held in another?
Only if your policies allow it. Cross-region access is a policy decision with region attributes on the data, and many teams deny it by default and add narrow exceptions.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.