Sovereignty

Sovereign AI in Monaco: three layers, not a slogan

Place du Casino, Monte-Carlo, Principality of Monaco

Most of the executives we meet in Monaco believe they have settled the question of sovereignty by ticking a box: "our data is hosted in Europe". It is reassuring, and it is false. A server installed in Ireland but operated by a subsidiary subject to US law is not sovereign. Sovereignty is not a geography, it is an architecture. And the moment you look at it from that angle, it stops being a trade-off on performance and becomes a simple engineering decision.

This article defends a precise thesis, against the grain of the prevailing marketing discourse. First, "sovereign" breaks down into three cumulative layers, and at least one of them is almost always missing from consumer-grade deployments. Next, on the vast majority of the business tasks of a family office, a private bank or a law firm, so-called open-weight models have caught up with closed models. The conclusion: choosing sovereignty is no longer a trade-off between security and results, it is a design choice that you can uphold without sacrificing anything.

The real threat model is not the hacker, it is the contract

When an executive thinks "AI security", they picture an attacker forcing a door. The real risk is more mundane and more structural: it is written into the terms of use and into the law applicable to the supplier. Here is what you actually accept when you paste a confidential memorandum or a list of beneficial owners into a consumer-grade AI.

  • Extraterritorial laws. A supplier subject to the US CLOUD Act can be compelled to hand over data to an authority, including when it is physically stored in Europe. The location of the disk offers no protection if the entity that controls it falls under a third-country jurisdiction. This is the nuance that "hosted in Europe" entirely conceals.
  • Training on your data. Depending on the offer and the tier subscribed to, your inputs may feed the improvement of the models. An innocuous clause is enough to turn a divorce file, a holding-company structuring or a due diligence note into training material. What leaves your perimeter never comes back.
  • Opaque sub-processors. Behind an API lies a chain of sub-processors: hosting provider, compute provider, moderation, sometimes human annotation. You contract with one name; you expose your data to actors you will never name nor audit.
  • The absence of an access log. Can you produce the time-stamped list of everything that was sent to an external model last month, by whom, and on which files? In almost all consumer-grade usage, the answer is no. Without that log, you can neither demonstrate your compliance, nor conduct a post-incident investigation, nor respond calmly to the APDP.

None of these four points is a flaw. They are the normal properties of a service designed for the general public. The problem arises when you pour into it matter covered by Monégasque professional secrecy or by anti-money-laundering (AML/CFT) obligations.

The three layers of sovereignty

To be sovereign is to uphold three layers simultaneously. They are cumulative: one of them is missing, and the edifice collapses.

1. Localisation

Where is the data physically stored and processed, including during inference, that is to say at the moment the model reads your text to produce its answer? This is the layer everyone knows, and the only one most suppliers put forward. Necessary, but far from sufficient. A datacentre in Roubaix is not sovereign if the next two layers are missing.

2. Jurisdiction

Under which law does the entity that controls the infrastructure and the model fall? A European company, shielded from extraterritorial law in both ownership and operations, cannot be compelled to surrender your data to a third-country state. This is where the real difference between "hosted in Europe" and "sovereign" plays out. Localisation describes the place; jurisdiction describes who can give orders about that place.

3. Effective control

Do you concretely keep your hand on access, logging, retention periods, partitioning by client, and the ability to erase everything? Control is the most neglected layer because it is the most demanding: it presupposes an architecture designed for you, not a subscription taken out online. It is also the layer that turns compliance from a promise into proof.

"Hosted in Europe" answers one question out of three. Sovereignty begins when you can name the law that applies to your supplier and produce the log of everything it has seen of your files.

The deployment spectrum, and when to choose each option

Sovereignty is not a switch. It is a dial that you set file by file, according to the real sensitivity of the data. Imposing the maximum everywhere is wasteful; applying the minimum everywhere is a fault. Here is the spectrum, from the most protected to the most open.

  • Monégasque sovereign actors, and local execution. For the most sensitive matter (named wealth files, AML/CFT vigilance data, items covered by professional secrecy), the infrastructure stays on the territory, with actors such as Monaco Cloud, Monaco Telecom or Telis, or on models that run as close as possible. The data leaves neither the jurisdiction, nor your perimeter of trust.
  • European private cloud. For heavy workloads (large document volumes, indexing several years of archives), a dedicated instance with a European actor beyond the reach of extraterritorial law offers the power without giving up jurisdiction. The right compromise when the volume exceeds what strictly local hosting can absorb.
  • On-premise. For the absolutely critical, the model runs on your own servers, behind your firewall. Nothing leaves. It is the most demanding option to operate, reserved for cases where even a trusted private cloud is judged one step too far.
  • Closed-model APIs, via a filtering gateway. When the task allows it and the data has been neutralised, you can call a cutting-edge proprietary model, provided you interpose a gateway (see below). Acceptable for non-identifying tasks: rephrasing a public text, summarising a note stripped of names, producing a generic draft.

The right reflex is therefore not to choose one option for the whole house, but to classify your use cases by sensitivity and assign each to the right level. The same private bank will run its email triage locally and its draft of a public market note via the gateway.

The filtering gateway, in concrete terms

It is the most misunderstood piece, and the most useful. A gateway (or proxy) is a compulsory point of passage that slots in between your staff and any external model. No call goes out directly. Everything transits through it, and it does three things before letting anything out.

  • It anonymises. Before sending, the gateway spots and replaces identifying elements: names, company names, account numbers, sensitive amounts. "Monsieur Dupont, beneficial owner of the Azur holding, €4.2m" goes out as "[PERSON_1], beneficial owner of [ENTITY_1], [AMOUNT_1]". The model works on a disembodied version; on the way back, the gateway reinserts the real values on the Monaco side. The external supplier has never seen a single real name.
  • It filters and blocks. Rules decide what is not allowed to leave. An item classified at the most sensitive level is refused to the external API and redirected to a local model. The decision does not rest on the vigilance of a rushed member of staff: it is applied by default, on every call.
  • It logs. Each request is time-stamped, attributed to a user, attached to a file, and retained. You obtain exactly the access log that consumer-grade usage lacks.

A well-tuned gateway therefore lets you use the best of a closed model without ever exposing named data. Let us be honest about its limit: anonymisation is not magic. On highly contextual texts, a detail can remain re-identifying, for example a single property transaction over the period that designates its purchaser without naming them. This is why the gateway is always paired with a rule that switches to local for anything that must not, under any circumstances, leave.

Why open-weight is enough for most business tasks

Then comes the natural objection: does staying sovereign not condemn you to a second-rate model? Two years ago, the answer was sometimes yes. Today, no. On the tasks that make up the bulk of real work, open-weight models, the ones you can run on an infrastructure you control, reach a production-grade quality.

Which ones? Summarisation (condensing a fifty-page contract, distilling an exchange of emails), structured extraction (turning a deed or an invoice into usable data: parties, dates, amounts, clauses), assisted drafting (a first draft of a notice convening a co-ownership meeting, a letter, an internal note), classification (sorting items, routing a request to the right file). These four families cover the greater part of the administrative hours that AI can absorb. As an order of magnitude, a 2024 McKinsey estimate places between 60 and 70% the share of administrative tasks potentially automatable, and around five hours a week per employee the time that can be freed up. Orders of magnitude, to be confirmed by an audit of your own processes, never promises.

Where a cutting-edge closed model keeps an edge is on long and complex reasoning: unprecedented legal arrangements, multi-parameter trade-offs, demanding mathematical reasoning. These cases are in the minority, and they are precisely the ones where you want an expert to keep their hand anyway. The gateway makes it possible to resort to them occasionally, on neutralised data. For the bulk of the volume, the sovereign approach costs nothing in quality.

Let us spell out the mechanism that makes all this reliable. You do not use a "raw" model: you anchor it to your documents through a technique called RAG (the model goes and finds the relevant passages in your own archives before answering, which grounds its responses in your data rather than in its general memory, and markedly reduces the risk of it making things up). You give it tools when it has to act, with a human-in-the-loop on high-stakes decisions, and you partition strictly by client. It is this assembly, not the model alone, that makes the difference.

The Monégasque framework: law n°1.565, the APDP and anti-money-laundering

All of this does not float in a legal void. Since law n°1.565 of 3 December 2024, the Principality has had a modernised personal-data protection regime, aligned with the GDPR and the Council of Europe's Convention 108+. Any AI project handling personal data falls within this perimeter, and oversight rests with the APDP, the Personal Data Protection Authority, which succeeds the CCIN with broadened powers.

The point that many overlook: compliance is not proclaimed, it is proved. And the three layers of sovereignty and the filtering gateway produce precisely the evidence expected. Localisation and jurisdiction document where the data lives and who can lay claim to it. The access log materialises traceability. Partitioning and retention periods show mastery. For the professions subject to anti-money-laundering and counter-terrorist-financing requirements (AML/CFT), governed by law n°1.362 under the authority of SICCFIN (private banks, family offices, financial professions), this ability to retrace each processing operation is not a comfort: it is the extension of obligations that already exist. A well-designed sovereign AI is therefore not in tension with the Monégasque framework, it is its instrument. And for eligible entities, the Blue Fund of the Extended Monaco programme can co-finance up to 70% (excl. VAT) of a structuring AI project, with the cloud infrastructure remaining excluded from the basis.

Start with the audit, not with the technology

Everything above describes means. None should be chosen before posing the only question that matters: which tasks, on which data, with what level of sensitivity? It is the audit that answers, and it is the audit that then dictates the architecture, not the other way round. You map the processes, you classify each use case on the spectrum, you quantify the expected return, and only then do you deploy the right level in the right place. Choosing the technology before this work is done is to guarantee either over-investment or exposure.

The good news is that sovereignty has ceased to be a sacrifice. You can today uphold the professional secrecy of the Place, satisfy the APDP, and obtain production-grade quality, all within the same architecture. What remains is to know where, precisely, it will gain you the most. That is exactly what a first audit brings to light.

Take action

What if we audited your potential?

A 30-minute conversation to identify a first high-impact use case, or a quantified estimate in under a minute.

70%of time-consuming tasks automatable