When a European wealth manager evaluates AI, the first question is rarely about the model. It is about the path: where does client data go, who can reach it, and what would we tell our regulator. This post describes how Luscent answers that question in architecture rather than in contract language, across three layers: where the system runs, how data is governed inside it, and who decides. The principle behind all three is the same. Sovereignty is architecture, not a setting, and none of it can be switched on afterwards.
Layer one: an EU-native architecture, not an EU region
There is a difference between hosting in an EU region of a global cloud and being EU-native, and for client communications the difference is the whole question. Storage residency without inference residency is a claim about the filing cabinet, not about who reads the files: an AI product can store data in Paris and still send every message to a model API operated from outside the EU.
Luscent's answer: all client data is stored and processed in the European Union, with the primary region at Scaleway PAR-2 in Paris and encrypted disaster recovery at Scaleway WAW-2 in Warsaw. Model inference runs on open-weight language models served on Scaleway's EU platform, 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. Exactly one sub-processor has access to client data (Scaleway); the full list is published in the Trust Center, including the one honest edge case: Tailscale, a US company, provides the encrypted mesh between Luscent's own machines and receives connection metadata only, because traffic runs peer to peer and never transits its servers. That is the level of specificity at which the residency conversation should be had, with any vendor.
Layer two: data governance by design
Four governance properties are built into the pipeline rather than promised beside it. Consent first: lawful basis is recorded before anything is read, and it cannot be recorded after the reading, because the pipeline runs in one order for every Signal. Redaction before inference: identifiers are removed before any model sees content, so what reaches the model carries the situation and not the identity. No training on client data: Luscent consumes models as served infrastructure and does not contribute client data to model training, its own or anyone's. And retention with an ending: client data is deleted or returned on termination under the data processing agreement, with the operational retention periods published.
On the regulatory map, each regime sits where it belongs. GDPR governs the processing: the firm is controller, Luscent is processor under Article 28, and the DPA template is 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. And DORA belongs in a different sentence than the other two: it is not a standard this architecture "meets" and not a product feature of Luscent or anyone else. DORA applies to Luscent as an ICT third-party service provider and describes how the company operates; what a client gets is support for its own Article 28 due diligence and register of information, documented in the Trust Center. A vendor that lists DORA among product capabilities is blurring its obligations with yours.
Layer three: the human-in-the-loop model
The decision model is the part of the architecture regulators and clients actually experience. Two rules define it. Compliance outcomes come from a deterministic rules engine, never from a model: a rule produces the same result on the same input every time, which is the property an auditor needs and a probabilistic system does not have. Language models read and summarise; they do not decide whether an obligation is met. And a person decides everything client-facing: every Signal is a recommendation carrying its evidence, the rule that gated it, and the model and version that read the sources; the relationship manager takes the decision, and the decision is recorded with the person who took it, immutably.
This is not a concession bolted on for comfort. It is what keeps the system on the right side of the EU AI Act's transparency regime, it is what makes the output usable as evidence, and it reflects a view about the work: judgement is not the bottleneck to be automated away. It is the part a regulator, and a client, is actually asking about.
Why this is an advantage and not a constraint
Every property above narrows what Luscent is allowed to build, and that narrowing is the moat. A firm that adopts an EU-native, human-in-the-loop system gets AI it can defend in a vendor questionnaire, in a board paper, and in front of the CSSF, and it gets evidence as a by-product of work that was going to happen anyway. The architecture decisions that look like caution compound into the one thing wealth management runs on: the ability to prove you did what you said. For the fuller reference treatment, including the due-diligence questions that separate EU-hosted from EU-native, see our guide to EU-native AI for wealth management.
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. Client data is processed and stored in the EU, on EU infrastructure. The current security posture, including what is not yet true, is published in full in the Trust Center. This post describes published architecture; it is not legal advice.
