"Hosted in the EU" and "EU-native" are two different claims. Only one of them survives due diligence.
Most AI vendors answer the data-residency question with a region name: the deployment runs in Frankfurt, or Paris, or Amsterdam. That is EU hosting, and for a wealth manager whose constraint is "client data cannot leave the EU or be exposed to a non-EU provider", it is not the claim that matters. EU-native means the whole path is European: where the data is stored, where model inference runs, which model APIs sit in the path, who controls the infrastructure company, and where every sub-processor stands. A firm that checks only the region name finds the difference later, in a questionnaire it has to answer for its own regulator.
What is the difference between EU hosting and EU-native AI?
EU hosting places workloads in a European region of an infrastructure provider that may itself be controlled from outside the EU. EU-native (sometimes called sovereign) means the data, the processing, the model inference and the controlling entities are all inside EU jurisdiction, so no extraterritorial claim on the provider can reach the data. The practical test is not the data centre's address; it is the answer to "who can be compelled, under whose law, to hand over what".
EU region of a global cloud | EU-native stack | |
|---|---|---|
Data at rest | In the EU | In the EU |
Model inference | Often routed to a US model API | On EU infrastructure, open-weight models |
Infrastructure control | Non-EU parent company | EU-controlled provider |
Extraterritorial exposure | Possible via the provider's home jurisdiction | Structurally limited |
What the vendor can honestly claim | "Your data is stored in the EU" | "No non-EU provider sits in the path of your data" |
Why does this matter more for AI than for ordinary SaaS?
Because AI moves the data. In a conventional application, client data sits in a database in one place. In an AI product, the sensitive content is sent somewhere to be processed by a model, and that somewhere is the whole question. A vendor can store client communications in Paris and still send every one of them to a model API operated from the United States. Storage residency without inference residency is a claim about the filing cabinet, not about who reads the files. For wealth management, where the content is client communications, the reading is the sensitive act.
The clean architecture is the one where inference happens on the same European infrastructure that holds the data. In Luscent's case: open-weight language models served on Scaleway's EU platform in Paris, no OpenAI, Anthropic, Google or other non-EU model API in the path of client data, and identifiers removed before inference so what reaches the model carries the situation and not the identity. Client data is never used to train or fine-tune models, Luscent's own or anyone else's.
The due-diligence questions that separate the two
A procurement or compliance team can resolve the whole topic with a short list, asked in writing:
Where are inference servers located, and which company operates them?
Do any model APIs sit in the path of client data, and who operates those?
Where are embeddings, logs, telemetry and backups stored?
Who controls the infrastructure provider, and under which jurisdiction's law?
Which sub-processors exist, in which jurisdictions, and what does each receive?
Is client data ever used for model training, by the vendor or a third party?
What is deleted or returned on termination, and on what timeline?
A vendor with a real answer publishes most of this before being asked. Luscent's Trust Center states it in one table: all client data in the EU, primary region Scaleway PAR-2 in Paris, disaster recovery in Warsaw, one sub-processor with access to client data, AES-256 at rest, TLS 1.3 in transit, client notification within 24 hours of a confirmed incident. It also states plainly what is not yet true: Luscent holds no security certification today, with ISO/IEC 27001 controls aligned and certification planned. A sovereignty story that hides its gaps is marketing; one that lists them is evidence.
One honest edge case belongs in the open: Luscent uses one United States sub-processor, Tailscale, for the encrypted mesh between Luscent's own machines. It receives connection metadata only; traffic runs peer to peer over WireGuard and does not transit Tailscale's servers. That is the level of specificity the residency conversation should be had at, for any vendor.
Where the regulations actually sit
Three regimes shape the question, and they sit in different places. GDPR governs the data processing itself: Luscent acts as processor under Article 28, on the firm's documented instructions, with a data processing agreement available before any commercial commitment. The EU AI Act governs the AI system: Luscent is a provider under Regulation (EU) 2024/1689, with the Article 50 transparency obligations applicable since 2 August 2026 and a documented position available on request. DORA is different in kind: it applies to Luscent as an ICT third-party service provider and describes how the company operates, including support for a client's Article 28 register of information. DORA is not a feature of the product, and a vendor who lists it among product capabilities is blurring the supplier's obligations with the firm's.
How Luscent fits this picture
Luscent is the system of intelligence for wealth management: an EU-native AI platform for private banks, family offices, external asset managers, and independent advisors. It reads client communications (emails, call notes, meeting summaries) to surface relationship insights and generate compliance evidence automatically. Client data is processed and stored in the EU, on EU infrastructure.
Sovereignty here is architecture, not a setting: it cannot be switched on afterwards, which is why the question belongs at the start of an evaluation rather than the end.
This page describes Luscent's architecture and published posture; it is not legal advice, and each firm's residency requirements are its own to define.
Frequently asked questions
What does EU-native AI mean? That storage, processing, model inference and the controlling infrastructure entities are all inside EU jurisdiction, with no non-EU model API or controlling parent in the path of the data. It is a stronger claim than EU hosting, which only places workloads in a European region.
Is an EU region of a US cloud provider enough for wealth management client data? That depends on the firm's own policy and its regulator's expectations, and it is precisely the question to resolve in writing before selecting a vendor. The distinction to test is whether the provider's home jurisdiction can reach the data regardless of where it is stored, and whether inference leaves the region even when storage does not.
Which AI models does Luscent use, and where do they run? Open-weight language models, served on Scaleway's EU inference platform in Paris, on the same European infrastructure that holds the data. No OpenAI, Anthropic, Google or other non-EU model API sits in the path of client data.
Does Luscent train models on client data? No. Luscent consumes models as served infrastructure and does not contribute client data to model training, its own or a third party's.
Is DORA a feature of the Luscent product? No, and it is not a feature of any product. DORA applies to Luscent as an ICT third-party service provider and describes how the company operates; Luscent supports its clients' DORA Article 28 due-diligence and register obligations with an information pack on request.
Does Luscent hold a security certification? Not today, and it says so: ISO/IEC 27001 controls are aligned with certification planned post-Series A, and SOC 2 Type I and II reports are planned for 2027 and 2028. The compensating posture is published in full in the Trust Center.
Sources: Luscent Trust Center (last reviewed 17 August 2026); Regulation (EU) 2016/679 (GDPR), Article 28; Regulation (EU) 2024/1689 (EU AI Act), Article 50; Regulation (EU) 2022/2554 (DORA), Article 28. Last updated: 24 August 2026.
