In a previous article, we described a shift: AI is moving from a tool you query to a component that routes, at the heart of processes. This shift has a consequence that is poorly gauged. The component that sorts emails sees every email; the one that scores files sees every file; the one that checks test results sees every result. The question of the private LLM — a model you run yourself, on infrastructure you control — long reserved for the most exposed organisations, then becomes an architectural question for many others.
From assistant to component: what changes for your data
With a conversational assistant, the user chooses what to paste into the window. That choice is imperfect, often made in a hurry, but it exists: every submission is a deliberate act, and a usage policy can govern it.
In a workflow, that act disappears. The process sends, automatically, everything that passes through it. Nobody decides any more, message by message, what goes to the model’s provider. The decision was taken once, when the step was plugged in, and then applies to the whole flow, continuously.
Volume changes in nature too. An assistant receives a few requests per person. A decision step receives everything the business handles: every customer request, every attachment, every result. And every call may leave a trace at the provider, in the form of logs kept for debugging, billing or security, depending on its terms. What was an occasional exposure becomes a structural one.
Jev, the decision model unveiled by TypeSafe AI in September 2026, illustrates this shift well, with no fault to find in it. It is designed to be called thousands of times, at every step of a program, and is used through the vendor’s service. TypeSafe states that this service currently runs from the West Coast of the United States. The model returns probabilities without a rationale, which makes a decision hard to explain after the fact, as DataCamp notes.
It is a textbook case, not a target. The same reasoning applies to any artificial intelligence API, whatever its vendor’s country. What changes, in essence, is the scale of exposure: an assistant sees extracts, a decision component sees the entire business flow.
A private LLM, the CLOUD Act and the GDPR: what the framework really says
Two texts intersect as soon as European data goes to an AI provider.
The CLOUD Act, a US law passed in March 2018, allows US authorities to require a provider subject to their law to disclose data in its possession, custody or control, whether stored in the United States or elsewhere. The test is not where the server is, but the operator’s jurisdiction. A data centre located in Europe, run by a company under US law, therefore does not put the data beyond the reach of such requests.
The GDPR, for its part, qualifies the provider. When a model processes personal data on a business’s behalf, its provider is in principle a processor within the meaning of Article 28: a contract governing the processing is required, along with sufficient guarantees and prior authorisation for any sub-processor. We detail these clauses in our article on Article 28 of the GDPR.
If the data leaves the European Union, the rules of Chapter V on transfers apply as well. For the United States, the current framework rests on an adequacy decision of 10 July 2023, upheld by the EU General Court on 3 September 2025; the previous arrangement had been struck down by the Court of Justice in 2020.
The “AI and GDPR” issue therefore does not come down to whether a tool is compliant. It arises flow by flow: what data passes, on what basis, to whom, and under what law. The European regulation on artificial intelligence, Regulation (EU) 2024/1689, adds its own obligations depending on the use; it replaces none of these questions.
For a decision step, these principles translate into very concrete questions, to put to the provider before signing. Is the data sent retained, and for how long? Is it used to train or improve the model? Which sub-processors are involved, and in which countries? The answers should appear in the contract and its annexes; when they do not, that is already an answer.
Private LLM: what running your own model covers
A private LLM means running the model on infrastructure you control: your own machines, on your premises, or those of a trusted host operating them on your behalf. The data sent to the model, and the decisions it returns, then pass through no third party you have not chosen.
“Local” therefore does not necessarily mean “within your own walls”. A small business does not always have the space, the skills or the wish to run a compute machine. Entrusting that operation to a provider is still local AI in the sense that matters, on three conditions: that the provider falls under European law, that it does not itself rely on a sub-processor subject to an extraterritorial law, and that the model it runs is identified and frozen.
Two kinds of sovereignty hide behind the word, and they are often confused. Infrastructure sovereignty says where the computation runs, and under what law its operator stands. Model sovereignty says who designed it, what is known about it, and whether it can be inspected. A closed model hosted in France remains a black box; an open model run by a provider subject to the CLOUD Act remains exposed. Both conditions are necessary.
That is why a local LLM almost always rests on a so-called open-weight model, whose parameters are published. This kind of model makes it possible to freeze a precise version, run it identically for months, and replay a past decision with the same version to understand what produced it. Models of this kind exist from European vendors: France’s Mistral AI publishes several under an open licence.
What a private LLM does not settle
A private LLM is not a universal solution, and presenting it as one would do it a disservice.
Performance. On some complex tasks, such as long reasoning or highly specialised writing, the largest closed models keep the edge. A local model that is good enough is not an equivalent model.
Operations. A model running in-house needs what any system needs: updates, backups, physical and logical security, managed access, and someone accountable. Without operations, the local machine becomes one more risk.
Choosing the flows. Not everything warrants local processing. A flow of public or low-sensitivity data can perfectly well go through a well-governed online service. The effort goes to the flows where the data must not leave.
This is where the distinction between reflex and writing becomes useful. Reflex decisions (sorting, routing, scoring, checking) are often the ones a smaller model, run locally, handles well: the answer is closed, the context short, and the largest model on the market is not needed to choose between four categories. The most sensitive flows are thus often the ones best suited to local processing.
Three questions to ask before plugging AI into your processes
These questions are asked step by step, not tool by tool. The same provider may suit one step and not another, depending on what passes through it.
- What data passes through this step, and how sensitive is it?
- Under which jurisdiction is the provider, and where does the computation run?
- Can the model version be frozen, and a decision explained after the fact?
If the answer to the third question is no, the decision cannot be audited. For an organisation subject to scrutiny, whether regulatory or scientific, that may be enough to rule the tool out, whatever its performance.
The first question is often the most revealing. In asking it, many businesses discover that a step thought harmless sees health data, bank details or information covered by trade secrecy go by, simply because they appear in attachments.
Our approach
Maeliom has chosen dedicated infrastructure, operated in France, with a European open-weight model. The sovereignty argument thus covers the whole chain: the hardware, its operator and the model. No third party sits on the data’s route.
We do not claim this model rivals the largest closed models. It does not need to in order to sort, route, score or check. For some demanding writing tasks the gap exists, and it is a trade-off we set out to each organisation rather than keep quiet about.
This offer is open in early access to a small circle of organisations handling sensitive data: research, health, legal, compliance. It is presented, with its three formulas including the Safe Room, on our sovereign AI page.
The question is no longer whether AI will make decisions in your processes. It already does, or soon will, because that is where the gains are. The question is under what conditions: who sees these decisions go by, under what law, with which model, and with what ability to explain them. These conditions are set when the step is plugged in, rarely afterwards.
It remains to be seen how this applies in a modest-sized organisation. That is the subject of a regulatory monitoring case, broken down step by step.
Common questions
What is sovereign AI?
Sovereign AI is an artificial intelligence system whose entire chain is under control: the infrastructure the model runs on, the law its operator is subject to, and the model itself, preferably open-weight so that it can be inspected and frozen. Hosting in Europe is only one condition of it.
What is a local LLM?
A local LLM is a large language model run on infrastructure you control, on your premises or at a trusted host, rather than called at an online provider. The data sent to the model passes through no third party you have not chosen. It usually rests on an open-weight model.
Does the CLOUD Act apply to data hosted in Europe?
Yes, if the provider falls under US law. The CLOUD Act covers data that a provider subject to that law has in its possession, custody or control, wherever it is stored. The deciding factor is the operator’s jurisdiction, not the server’s location.
Is local AI GDPR-compliant by default?
No. It makes compliance easier by removing some transfers and some processors, but it does not guarantee it. A legal basis, information for the people concerned, a retention period, security measures and, where required, an impact assessment are still needed. Local processing reduces exposure; it waives no obligation.
Sources: US Department of Justice, CLOUD Act; 18 U.S.C. § 2713; GDPR, Article 28 and Chapter V (CNIL); adequacy decision (EU) 2023/1795; EU General Court, T-553/23, 3 September 2025; Regulation (EU) 2024/1689; TypeSafe AI (15 September 2026); DataCamp; Mistral AI, model list.