Keeping AI infrastructure inside the EU — and why it's getting harder

"EU-hosted" appears on every AI vendor's website now. For teams under GDPR, processing personal data through US-based inference APIs is not a checkbox exercise — it is a legal and architectural commitment. Yet the gap between marketing language and operational reality keeps widening.

This post is a practical look at what data residency actually requires when you add LLM memory, agentic tools, and billing to the stack — and why default-EU routing matters more as products get smarter.

GDPR is not just where the server sits

Article 44 and following govern transfers of personal data outside the EEA. Standard Contractual Clauses and the EU-US Data Privacy Framework provide pathways, but they add legal review, vendor diligence, and ongoing transfer impact assessments — work that startups and mid-size teams often underestimate.

Personal data in an LLM product includes more than user profiles:

• Conversation content and compiled session memory
• API usage logs tied to identifiable tenants
• Support tickets and contact form submissions
• Billing records and payment metadata
• Authentication events from your identity provider

If any of these touch US infrastructure by default — even as a failover or analytics pipeline — your "EU-hosted" claim needs footnotes.

The hidden egress paths

Running a primary API in Frankfurt is necessary but not sufficient. Common leak paths we see in AI stacks:

Model provider routing. Your gateway is in the EU, but upstream LLM calls go to US endpoints because that is the default region in the SDK.

Observability and error tracking. Crash reports and traces often ship to US SaaS by default unless you configure regional endpoints.

Email and notifications. Transactional email providers, webhook delivery, and status pages may process message content outside the EEA.

Payment processing. Billing data has its own compliance surface. European payment providers reduce cross-border transfer complexity for financial metadata.

CDN and static assets. Less sensitive for API products, but still worth documenting in your subprocessor list.

Kortexio's default posture is that customer memory data, usage metadata, and billing for the managed service stay on European infrastructure — not because one checkbox satisfies legal, but because eliminating default egress is easier than auditing every SDK default later.

Why memory makes residency harder

Stateless chat proxies are relatively simple to region-pin. Add persistent memory and the compliance surface grows:

• Retention policies. How long do you keep session wikis? Can enterprise customers set custom retention?
• Deletion guarantees. When a user requests erasure, memory must delete across backups and replicas — not just the primary row.
• Export portability. GDPR Article 20 expects machine-readable export. Memory stores need export APIs, not opaque embedding indices.
• Subprocessors. If memory compaction calls an external model, that provider becomes part of your transfer story.

A Data Processing Agreement (DPA) that lists subprocessors, describes retention, and documents security measures is table stakes for B2B buyers — not an Enterprise-only afterthought.

Agentic tools add jurisdiction questions

When assistants call external tools — ticketing systems, CRMs, shell commands — data may leave your controlled boundary even if the LLM gateway stays in the EU. MCP servers you attach per app need the same diligence as any other subprocessor.

Human-in-the-loop confirmation before destructive actions is both a safety feature and a compliance control: it creates an explicit audit point before irreversible operations run.

What "EU-hosted by default" means at Kortexio

For the managed Kortexio Cloud service:

• Application and API hosting in European data centers
• Billing through a European payment provider
• Identity (Keycloak) deployed in the same regional footprint
• No default routing of customer memory or usage data to non-EU infrastructure

Customers still choose upstream LLM providers via BYOK. That is intentional — model inference jurisdiction follows the provider you configure. Kortexio's obligation is transparent documentation of what we control versus what you configure.

Every customer can request our DPA. Enterprise tiers can negotiate custom retention terms and support SLAs.

Getting harder, not easier

US cloud dominance means SDKs, docs, and defaults assume US regions. New AI features — realtime voice, multimodal pipelines, hosted fine-tuning — often launch US-first. European teams either wait, self-host, or accept transfer mechanisms.

Regulatory attention is increasing simultaneously. NIS2, sector-specific rules, and customer procurement questionnaires ask for evidence, not slogans. "We use AWS eu-central-1" is the beginning of the answer, not the end.

Practical checklist for teams evaluating vendors

1. Map every category of personal data your product processes.
2. Trace each category through inference, storage, logs, email, payments, and support tools.
3. Identify default US routes in SDKs — especially observability and model APIs.
4. Require a current DPA and subprocessor list before production launch.
5. Test deletion and export flows, not just signup.

Conclusion

Keeping AI infrastructure inside the EU is getting harder because products are getting more connected — memory, tools, billing, identity — and because vendor defaults still assume US-first deployment.

Kortexio is built for teams who want persistent memory and agentic capabilities without standing up a compliance archaeology project on day one. Host in Europe by default. Document what leaves. Offer a DPA to everyone.

If you are evaluating Kortexio for a regulated environment, read our DPA or contact us about Enterprise terms.