Compliance you can verify, not just claims you can read.
Every guarantee on this page maps to a control an auditor can check.
Data goes only where your policy allows. EU by default: enforced, not promised.
Every request is checked against your policy before dispatch; if nothing qualifies, it's blocked at the gate. EU by default. Direct US and China routing is available only when you add it, every destination disclosed. Nothing leaves silently.
Sovereign EU: owned and hosted in the EU
Mistral and Scaleway are French companies on French infrastructure. No foreign-government access regime reaches them. This is the default tier, the only one active until you change it.
Direct US or China: available, opt-in, never hidden
Direct US and Chinese providers are available today. They route only when your policy allows, each flagged by jurisdiction and CLOUD Act exposure, and pseudonymization keeps PII and secrets off the wire. Leaving the EU stays your decision.
Your own endpoints, or your own iron
Bring a private or self-hosted model: same policy, same ledger. Or run the whole data plane yourself with Sluis Edge, so prompts never transit Sluis.
Exactly what we keep, exactly what we erase.
A right-to-erasure request that destroys your evidence isn't compliance; it's a liability. Sluis draws the line precisely: the content goes, the proof that the content was handled correctly stays.
- Request & response content: the prompts and completions held under opt-in retention.
- Cache entries: exact and semantic cache rows for the tenant.
- Provider credentials: stored upstream API keys, decrypted nowhere.
- Content references: every content_ref pointer is nulled.
- The audit metadata chain: audit_log + chain_heads stay intact, so verify-chain still passes.
- Hashes, not content: the SHA-256 links remain; the bodies they covered are gone.
- Routing decisions: which region and provider served each call.
- Token & cost metadata: the real-money micro-euro ledger that backs your budgets.
Retention TTL purge
Retained content and cache rows carry an expiry. A scheduled purge deletes only the rows past their TTL: a cron-able job, not a manual sweep.
Content retention is opt-in
By default Sluis records the metadata, not the message. Storing prompt and response bodies is a per-tenant choice, off until you turn it on.
AEAD-encrypted at rest
Any retained content, and the entire response cache (exact + semantic), is sealed with authenticated encryption. No content key, no cache: the gateway falls back to no-cache.
Strict per-tenant isolation
Keys, policies, audit chains and cache are scoped to a single tenant, derived from the request's key and enforced on the hot path. One tenant can never read another's data or ledger.
Hand the auditor the chain. They can check it without trusting us.
Every call is hash-chained to the one before it. Alter any field and every later link breaks. Export it as JSON Lines and re-verify offline: the proof travels with the data.
$ sluis audit verify-chain --tenant <id> → ok · 1,284,901 entries · genesis intact
The full list. Region and ownership, stated plainly.
These are the only third parties that can ever touch a request, and only when your policy routes to them. We name the legal owner alongside the hosting region, because under the CLOUD Act they are not the same question.
Sensitive data is caught before it reaches a model.
The first gate runs 60 deterministic detectors over every request for PII, PHI and secrets, tagging it before a single token moves downstream. They are built for European data: an EU national-ID pack that checksum-validates 12 countries (the NL BSN, PESEL, codice fiscale and more), IBAN check digits, E.164 phone numbers. Not a US-centric afterthought.
Names defeat pattern matching, so name detection is four layers you switch on deliberately, each a false-positive and latency tradeoff you own: context heuristics, email correlation, a tenant name directory, and Sluis's own multilingual recognition model. That model ships and runs inside your deployment, so a name is never sent to a third party to be scanned.
Work with personal data and secrets. The model never sees them.
A control your auditor can verify: PII and secrets become stable tokens before the prompt leaves your network, so the provider only ever sees tokens. The real values are restored on the way back, and the map that links them is never written to disk.
Everything your reviewers ask for, ready to hand over.
The paperwork that usually takes three weeks of back-and-forth. Request any of it directly; no sales call required to read a DPA.
DPA template
Our standard Data Processing Agreement, with the Art. 28 obligations and EU Standard Contractual Clauses already in place.
Request the DPA→Data-flow & sub-processors
How a request moves through the three gates, where it can egress, and which sub-processor handles each path.
Read the doc→Sub-processor list
The per-tenant disclosure: every provider your keys and policy actually enable, with region and legal owner, exported on demand.
Export for your tenant→Audit export
The full hash-chained ledger as JSON Lines, re-verifiable offline with verify-chain. Bring your own tooling.
See the format→Bring your auditors. We'll bring the chain.
Residency enforced on every request, content you can erase without losing the proof, and a ledger anyone can check offline. The controls are real. Come test them.
Regulated buyer? Ask about Sluis Edge →