Encryption protects your data while it is sitting still. But research means processing, and processing means your text reaches a model somewhere. This page is about that somewhere.

The short version, because it is the part most people are actually asking about:

Every model that runs your research is EU-sovereign. That is not a setting you have to find and switch on — it is the only kind of model we run.

The rest of this page is the detail behind that sentence: what makes it true, the two things that are deliberate exceptions, and what LumaVista strips out of a request before it goes anywhere at all.

Sovereign is the floor, not an option

LumaVista does not maintain a catalog of models from everywhere and then filter it down to the acceptable ones according to your preferences. The catalog only contains EU-sovereign providers in the first place.

The models serving your research run on:

Lyceum — our own inference infrastructure, on hardware we operate.
Mistral — French, EU-incorporated.
Scaleway Generative APIs — French (Iliad), inference pinned to Paris.
OVHcloud AI Endpoints — French (Gravelines), Euronext-listed.

There is no OpenAI, no Anthropic, no Google, no US hyperscaler anywhere in the path your research takes. Not deprioritised — absent. There is no configuration you could get wrong, or forget to set, that would route your research to one, because there is nothing to route to.

This is enforced twice over, deliberately. The catalog contains only sovereign backends, and the platform additionally refuses to start with a research configuration that does not meet a sovereign floor — a deployment that somehow acquired a non-sovereign research backend fails to boot rather than quietly serving from it.

So what is the setting for?

Settings → Privacy & data carries a trust floor with three positions. Given the above, here is what each one actually means for you:

Standard is the default, and it adds no restriction beyond the models the deployment already runs. On our hosted service that means it changes nothing: it sits above a floor the platform is already standing on. It is headroom, not a permission you granted.

The setting exists because LumaVista can also be deployed privately, and an organisation running its own instance chooses which providers to register — including, if it wants, providers outside the EU. There the setting is load-bearing, and the disclosure about where data goes belongs to whoever operates that deployment. It is not ours to make on their behalf.

Sovereign pins the floor explicitly, so it stays true regardless of what the catalog might contain in future. If you want the guarantee written down against your account rather than inherited from ours, set it — and see what it turns off, which is the one reason not to.

Confidential goes further still, and genuinely changes what you get. It currently applies to chat; research projects run at the sovereign floor described above.

Confidential

Everything runs pinned to trusted, attested private hardware — GPU capacity we operate in Germany and Switzerland, dedicated to you for the duration. No third party sees the prompt at any point, including the operator of the machine underneath. Confidential is a strict subset of sovereign: anything that qualifies as confidential already qualifies as sovereign.

Today this applies to chat. In a confidential conversation, retrieval and grounding are switched off — not because they would be impossible, but because retrieving means embedding your message to search against, and the point of a confidential turn is that your text goes to exactly one place. What you get is a conversation nobody can observe; what you set aside, for that conversation, is the assistant’s ability to go and look things up.

Confidential is entitlement-gated. If your plan does not include it, the option is visible but locked, so you can see what exists rather than wondering whether there is a tier above yours. Where it is included, capacity may be on-demand: a private instance spins up on first use, and the interface tells you it is warming rather than pretending to be instant.

Two things that do leave the EU

Honesty is worth more here than a clean claim, so: there are exactly two capabilities that send data outside the EU, and each is off until you specifically turn it on.

Voice chat

Live voice sends both your spoken audio and the assistant’s spoken reply to ElevenLabs, in the United States.

Voice recordings are biometric-adjacent personal data crossing to a US processor. Under GDPR that needs explicit consent as its lawful basis — not a preference you might have left on, and not something folded into a broader setting. So voice chat is off until you turn it on, in Settings → Voice, having read a disclosure that says plainly where your audio goes.

That consent is its own thing. It is not implied by your trust floor and not implied by using typed chat. Withdrawing it is as easy as granting it: turn it off, and voice stops working until you opt in again.

Image generation

Image generation likewise uses providers outside the sovereign set. Setting your floor to sovereign or confidential turns it off outright rather than silently downgrading it — the assistant refuses rather than quietly making an exception for pictures.

Below that floor, whether you are asked to accept anything depends on which generator your deployment uses. The default one needs no separate acceptance. A generator that sends your prompt further afield pauses the first request on its own consent prompt, naming what leaves and where it goes; accept once and later requests run without asking. So this is not a single switch like voice — it is per generator, and the trust floor is the part that applies to all of them.

Why these are separate switches

Bundling them into a general “allow external processing” preference would mean a user who wanted to try voice once had thereby loosened something much broader, probably without noticing. Each capability that leaves the EU is its own decision, disclosed at the moment you make it, revocable on its own.

Both are expected to become sovereign. As EU-sovereign speech and image providers reach the quality bar, these features move under the sovereign floor like everything else and the separate consent stops being necessary. The exception list is meant to shrink.

Everything else, without asking

Independent of any setting: research, retrieval, embeddings, transcription, and storage run on sovereign or local infrastructure. Not as a fallback, not as a preference — as the only path that exists.

How the floor is enforced

A floor is not a preference the system tries to honour. It is a gate in the router — which is what makes the guarantee above something other than a promise.

Every request carries its floor. When the router assembles the list of backends that could serve it, each candidate is checked against that floor, and a backend that does not meet it is not eligible — there is no “closest available” fallback that quietly crosses the line.

Three properties are worth stating explicitly:

It fails closed. If the router cannot establish that a backend meets your floor, the backend is not eligible. An unknown answer is treated as a no.

Floors only ever rise. Several things can demand a higher floor for a given request — your account setting, a per-request escalation, an automatic raise when redaction sees something sensitive. The effective floor is the most restrictive of them. Nothing can lower a floor that something else asked for.

Sovereignty is derived, not declared. A backend qualifies because of what it is — where it runs and who operates it — not because of a label attached to it in configuration.

Classification and redaction

Inside whatever boundary your floor sets, a second system looks at the content itself.

What the classifier finds

Every piece of content flowing through LumaVista — your inputs, search results, uploaded documents, model responses — is scanned for:

Personal data. Credit card numbers validated with Luhn checksums rather than matched by shape, so a random digit string is not mistaken for one. National identity numbers for EU member states, each with its own country-specific validation — the Dutch BSN’s 11-check, the Spanish DNI’s letter suffix, IBANs against ISO 7064 mod-97. Email addresses, phone numbers, passport numbers, dates of birth, health-related data.

Secrets. API keys in the formats the major providers use, JWTs, private key headers, database connection strings, and generic credential patterns.

Threats. Prompt injection, both the direct kind (“ignore previous instructions”) and the indirect kind — zero-width character smuggling, instructions hidden in HTML comments, base64-wrapped payloads. Also content-integrity attacks: entity-expansion bombs, pathologically nested JSON, binary disguised as text. These are blocked at the boundary rather than flagged, because they have no legitimate reason to be there.

Every match carries a confidence score and the exact span it matched, so a decision can be traced back to the specific characters that caused it.

A note on why this matters more than it sounds: documents you upload and pages the crawler fetches are not written by you. Content coming back from the open web is adversary-controlled by definition, and the classifier is what stands between it and the model.

Redaction strictness

You control how aggressively detected material is removed before anything is sent, in the same settings block:

Setting	Behaviour
Off	No redaction. Sensitive values are sent as-is. Use only on trusted networks.
Standard	Redacts credentials and strong personal identifiers. The recommended setting.
Strict	Redacts everything detected, including financial and contact details.

Redacted spans are replaced with typed placeholders. The original stays in your encrypted store; the provider sees the placeholder; the response is reassembled on our side. Where redaction sees something sensitive enough, it can also raise the floor for that request rather than merely masking it.

Organisation policy

Where LumaVista is deployed for an organisation, some of this is set centrally rather than per person.

An organisation can set a default trust floor and a default redaction preset, which apply to everyone who has not chosen otherwise. It can also define custom classification patterns — internal project codes, proprietary terminology, industry-specific identifiers — with the clearance level they should attract. Custom patterns are checked for catastrophic backtracking before they are accepted, because a regex that hangs is a denial of service against your own pipeline.

An organisation default is a default: your personal setting overrides it, and the settings page tells you what the organisation chose and that you are overriding it. Where a policy is genuinely mandatory rather than advisory, it shows as locked.

Outbound protections

Every outbound request LumaVista makes — to model providers, search engines, or the crawler — goes through a single egress path, which is where the network-level protections live.

Server-side request forgery is blocked at the boundary. Outbound URLs are validated, DNS is pre-resolved to defeat rebinding, private address ranges are refused — RFC 1918, loopback, link-local, and cloud metadata endpoints in particular — and redirect chains are re-validated rather than followed blindly. Internal services are reachable only by explicit allowlist.

Everything is attributable. Each outbound request is logged with its destination, timing, and which project and user it belonged to.

Availability

The trust-floor selector and the per-feature “where your data goes” map are in beta and off by default. If you do not see them under Settings → Privacy & data, they are not enabled for your account — ask and we will turn them on. Redaction strictness is generally available.

Your statutory controls — data export, import, and your consent record — are on the same page and are never gated.

How this connects

How Your Data Is Protected — encryption and isolation: your data at rest.
Setting Up Your Encryption — the keys, the devices, and recovery.
Unattended Actions and Approvals — the separate gate governing whether an automation may contact anyone outside your account.

For a high-level overview of LumaVista’s security commitments, visit the Security page. For deeper technical detail, see the Security Architecture whitepaper.