EU residency. Tenant isolation. Zero Data Retention with Anthropic.

01EU residency

Every component that touches customer data is hosted inside the European Economic Area. The database, the storage bucket, the application server, the outbound email provider — all EU regions, configured deliberately, named below. Data does not leave the EEA in normal operation.

Where data lives

• Postgres database — Supabase EU region. All customer-data tables sit here; row-level security gates every read at the database level.
• Object storage — Supabase Storage in the same EU region. Used today for persona headshots; will hold customer-uploaded artefacts (e.g. screenshots in approval contexts) at the platform launch.
• Application server — Vercel EU edge regions for the customer-facing app; Belgian / EU-resident VPS for any background-worker tier.
• Outbound email — Resend, configured to the EU region (Frankfurt). See Privacy policy for the sub-processor list.
• Marketing site — hosted at nuya.io via TransIP / Mijn Plesk in the Netherlands.

The one transfer that exists

Inference — the actual model call to Claude — runs on Anthropic infrastructure. Anthropic's data plane processes inference requests in their US datacentres today; the EU plane is on Anthropic's roadmap. Until that lands, every Anthropic call is governed by:

• Standard Contractual Clauses (Module 2: controller → processor) in the underlying agreement
• Zero Data Retention — see the next section
• No use for training — explicitly contracted, not policy-by-default

The transfer mechanism is documented in each customer's Data Processing Agreement; the residency snapshot above is updated whenever the platform topology changes.

02Sub-processors

Today's list (waitlist phase + platform-launch readiness). Each sub-processor has a defined function, a defined region, and a defined data scope. Customers receive the live list as part of their DPA and are notified of changes 30 days in advance.

What's deliberately NOT here: ad pixels, retargeting, third-party heatmaps, social-share trackers, analytics-by-default. The full list of "nothing else" lives in Cookies.

03Security posture

Tenant isolation

Every table that holds customer data carries a company_id (or equivalent tenant_id) and has Postgres row-level security enabled. Read paths join through is_company_member(...); write paths go through SECURITY DEFINER RPCs that re-check the gate inside the function. There is no operator query that crosses tenants. The only path that does is the platform-admin GDPR audit, which is logged separately and permanently in gdpr_operations.

Tenant denormalisation triggers enforce the invariant at write time: a row's company_id is overwritten from the parent's at BEFORE INSERT, so a forged value on the wire silently becomes the correct one. Concrete defence against the "I'll just put a different tenant id in the body" class of mistake.

Audit by trigger

A generic Postgres trigger writes an activity_log row on every state-changing action across every tenant-scoped table. The audit isn't a feature you opt into; it's the only way state can change. Full story on the audit trail page.

Anthropic Zero Data Retention

Before any customer data flows through Anthropic for inference, Archevia BV signs Anthropic's Zero Data Retention agreement. ZDR means:

• No retention of inputs or outputs by Anthropic beyond the request-response cycle
• No use of customer data for model training, ever
• Logs purged on a contractually-named cadence

This is contractual, not policy. The agreement is signed customer-by-customer when each pilot starts; status is named in the customer's DPA addendum.

Secrets handling

Application secrets live in a vault (Doppler is the current path). They never appear in version control, never appear in logs, and never appear in error messages. Per-environment access is gated; rotation is a CLI command, not a redeploy. The CLAUDE.md repo-discipline rule is "secrets never hit the repo" — enforced at code review and at CI scan.

GDPR rights — Article 17 + 15 + 20

Every tenant-scoped action has a deletion path (Article 17) and an export path (Article 15 + 20). Both are implemented as SECURITY DEFINER RPCs with full audit-row capture in gdpr_operations. The customer's right to be forgotten is an operator script away — see the GDPR runbook in docs/gdpr.md in our internal documentation.

What we don't do

• No model fine-tuning on customer data, ever.
• No cross-tenant analytics. We can show a customer their own usage; we can't show "average" numbers across tenants because we don't compute them.
• No silent failure. Every error path either retries cleanly or surfaces to the operator. Sara flagging a team disagreement is the canonical example: the platform never picks a winner you didn't ask for.
• No shadow IT integrations. Every sub-processor is named here, in the DPA, and on the customer's onboarding checklist.

04Data residency vs data sovereignty

Residency is the easier promise: data stays in the EU. Sovereignty is the harder one: data is governed by EU law and isn't subject to extraterritorial access (e.g. the US CLOUD Act when a sub-processor's parent is American). Most agent platforms quietly conflate these.

Our honest position: today, residency is enforced everywhere we can enforce it; sovereignty holds for the database, storage, marketing site, and email path. The Anthropic inference call sits in US infrastructure under SCCs + ZDR + no-training contractual posture — that's the trade-off being made for capability access. Customers with hard sovereignty requirements (e.g. defence-adjacent, certain BE / FR public-sector) should know that's the boundary today; the EU-region inference plane is on Anthropic's roadmap and we'll reflect it here when it lands.

05DPIA, contracts, contact

For each pilot, we produce:

• A Data Processing Agreement per Article 28 GDPR, with the sub-processor list as an appendix and named transfer mechanisms (SCCs / adequacy / ZDR) per sub-processor.
• A Data Protection Impact Assessment when the customer's processing meets Article 35 thresholds — high-risk profiling, large-scale special-category data, systematic monitoring. The DPIA is a customer-collaborative exercise, not a one-pager we hand over.
• A tenant-isolation walkthrough for the customer's CISO — schema map, RLS posture cheat sheet, the cross-tenant audit story, the runbook for Article 17 hard-delete with the customer present.

Trust questions, audit requests, security questionnaires — contact@nuya.io.