# EU data residency: every byte, every inference, in the EU Inference on EU-resident models, storage in the EU, and a fail-closed guard on any call to a non-EU model. Residency enforced in code and provable per request. ## Every byte, every inference, in the EU. Run AI without your data ever leaving the EU. Inference is served on EU-resident models, your knowledge graph and cache live in the EU, and any call to a non-EU model is blocked at a fail-closed guard unless you explicitly allow it. Residency is enforced in code, and provable on every request. EU-resident · fail-closed egress · provable The last line is the one to read. Refusing is the default. ## "Hosted in the EU" is not the same as staying there. Most AI stacks send your prompts to a US provider, where the CLOUD Act reaches them no matter which region the dashboard names. Even an EU deployment leaks the moment a request falls through to an external model. For regulated data, a residency policy you cannot enforce or prove is a finding waiting to happen. ## Enforced in code, not promised in a policy. Residency is not a region setting on a dashboard. It is where the models run, where the data rests, and what happens on the request that tries to leave. ### EU-resident, end to end Inference runs on EU-resident models, and your knowledge graph, cache and audit trail live in the EU. The application, the data and the models are all EU-resident. ### Fail-closed egress guard A request never reaches an external or non-EU model unless you have explicitly allowed it, with data pseudonymized by the firewall or a recorded acknowledgment. Off by default, enforced in code. ### Provable, per request Every request records the model, provider and region that served it, in a metadata-only audit trail. You answer "where did this run" with the log, not a promise. ## The whole platform keeps data in the EU. Residency is not one feature. It is how every part of the platform behaves by default, and each part is metered on its own. - Inference API: OpenAI-compatible, served on EU-resident models. - Model Router: The fail-closed egress guard that blocks non-EU routing. - Firewall: Pseudonymizes personal data before any external call. - Recall: Per-user facts and documents, stored in the EU. - Audit Trail: The region that served each request, on the record. - Observability: Where the time went, traced inside the region. ## Residency you can hand to a reviewer. Auditors and data protection officers do not want assurances, they want evidence. The platform is built to produce it without anyone assembling it by hand. ### Per-request residency The model, provider and region for every call are written to a metadata-only audit trail you can export. ### No silent egress External or non-EU routing is blocked at the guard unless firewalled or acknowledged, and every override is recorded. ### Sub-processors disclosed The EU infrastructure and services behind the platform are named, so your own GDPR records can reference them. ### Pseudonymized before egress When an external call is allowed, the firewall replaces personal data with tokens before the request leaves the platform. ## Health data sharpens the same three questions. ### Where it is processed Medical imaging and patient records do not leave the EU. Residency fails closed: a request that cannot be served inside the EU fails rather than routing elsewhere. It is not a setting a developer has to remember on every call. ### What is kept Trace payload retention follows your plan, and a workspace can turn payload capture off entirely. Where the firewall runs, what is stored is pseudonymized rather than the original text. ### What you can prove Every request writes a metadata-only entry to the audit trail. When a patient exercises Art. 17, erasure reaches their long-term facts and threads and returns counts, so "we deleted it" becomes something you can put in writing. ## Questions people ask about residency. ### Can a request ever leave the EU? Only if you have allowed it, per request, with the firewall on or an acknowledgment on record. The default is to refuse, and the refusal is written to the trail. ### Where is our data stored? In the EU. The knowledge graph, the cache and the audit trail are EU-resident, as is the application itself. ### How is this different from a region setting? A region setting names where a service is deployed. This is enforced at the egress guard on every request, and recorded, so it is something you can show. ### What about special category data? It stays in the EU like everything else. A request that cannot be served inside the EU fails rather than routing elsewhere, and payload capture can be turned off per workspace. ### Are your sub-processors published? Yes. The EU infrastructure and services behind the platform are named, so your own records can reference them. ## Keep your AI in the EU. Create a key and run on EU-resident models today, or talk to us about your residency requirements.