Home / Journal / Compliance, hosting and impact

Hosting an AI project in France: OVH, Scaleway or a hyperscaler

By NabilDevOps and Security lead
Compliance, hosting and impact Published 8 min read

Hosting an AI project in France is not just about picking a country on a map. The real questions concern the data that reaches the model, the law that governs your provider, and whether you can leave one day. That is what lets you choose based on the project's actual sensitivity, not on principle.

Hosting an AI project in France: OVH, Scaleway or a hyperscaler, Kabaun Studio journal article

What data actually reaches the model

Before picking a hosting setup, ask a simple question: what really gets sent into the AI model? An agent that summarises internal emails does not handle the same information as one reading patient files or industrial production data. List the fields that travel to the model, not just the data sitting in your database. A poorly designed prompt can carry a name, an address or a contract number without anyone noticing.

This diagnostic step always comes before the technical choice. Until you know what is circulating, discussing hosting is like picking a lock before knowing what is behind the door.

How to build that list of fields being sent

The most reliable method is to take the exact prompt sent to the model, as it actually goes out, and highlight every variable field it contains: identity, contact details, a case reference, the content of an attached document. Many teams discover at this point that context meant to help the model, such as a full conversation history or the content of an attachment, carries more personal information than the visible form the user filled in. Once built, this list becomes the basis for every following question on storage, processing and applicable law.

Where it is stored, where it is processed

Storage and processing do not always happen in the same place. A database can sit in a European region while the call to the language model runs through a data centre located elsewhere. Ask every provider, hosting company and model vendor alike, where the servers that store your data physically are, and where the ones running inference sit. Both answers matter equally.

The precise questions to ask a provider

A sales conversation rarely stays precise unless the question is asked in a closed form. It is better to ask directly which country the storage servers are in, which country the servers running the model are in, whether either location can change without notice depending on service load, and whether a subcontractor steps in anywhere in the chain, in which case their own location matters too. A vague answer or one pushed to "later" on any of these four questions deserves to be pressed before signing.

Which law applies to your provider

The location of a server does not tell the whole story: the law that governs the company operating it matters too. A company subject to US law, even with data centres in Europe, remains within reach of the CLOUD Act, the US federal law that lets American courts request access to data held by a provider under its jurisdiction, wherever in the world that data is stored. It is a legal fact to weigh into the choice, whichever provider you use, in the same way that the GDPR governs transfers of personal data outside the European Union through adequacy decisions or standard contractual clauses, under its chapter V.

Why this distinction changes the project in practice

This distinction between server location and the law applying to the provider is not a theoretical point reserved for lawyers. For a project handling patient files, HR data or industrial plans, it determines whether a foreign authority can legally request access to the data, regardless of its physical location. For a public chatbot answering generic questions, the same question carries much less weight. This is exactly why the initial diagnostic needs to qualify data sensitivity before choosing a hosting provider, rather than the other way round.

Does the provider train its models on your exchanges

Ask the question directly and check the answer in the contract, not just on the marketing page: do your prompts and documents get used to retrain the provider's model? Some contracts rule this out explicitly for professional use, others stay vague or reserve that right by default. At Kabaun Studio, this clause is a non-negotiable condition before any deployment: no model training on client exchanges, whatever provider is chosen.

Where to look for that clause in a contract

A provider's marketing page almost always shows a reassuring statement about confidentiality. The contractual text that actually matters sits elsewhere, often in the API terms of use or in a technical appendix separate from the same provider's consumer offering. It is not unusual for one provider to apply different rules depending on whether you use its consumer product or its metered professional offering. Checking which of the two you actually signed up for is one of the checks not to skip.

Reversibility: can you actually leave

One last test before signing: if you switch providers in two years, how long does it take to get your data back in a usable format, and how much code needs rewriting because the model call was hard-wired to a proprietary API? An architecture that routes through an abstraction layer between your application and the model keeps that door open. It is one of the principles we apply systematically: see our approach to responsible AI.

What this abstraction layer changes in practice

In practice, this abstraction layer means the rest of the application never depends on the quirks of a single model API. The code that prepares the question, the code that processes the answer, and the code that displays it to the user all stay the same whatever model is called behind the scenes. The day a project changes provider, for reasons of cost, compliance or performance, only that connection point needs rewriting, not the whole application. That is what turns a change of provider from a months long project into a change of a few days.

Three families of answers, not a ranking

A European cloud provider, governed by the law of a member state, simplifies the question of applicable law and often meets the strictest compliance needs. It usually means accepting a narrower tool ecosystem than the largest global players offer.

A large American provider offering a European region generally guarantees storage and processing carried out within the European Union, backed by contractual commitments on transfers, and since 2023 by the European Commission's adequacy decision for flows toward the United States. It remains subject to the law of its home country for anything beyond strict European storage, which needs to be weighed against how sensitive your data really is.

An open model hosted on a local or dedicated architecture keeps the data within your own perimeter, or that of a hosting provider you select precisely, without depending on the usage contract of a closed model. For the most sensitive data, some public bodies turn to providers qualified SecNumCloud by ANSSI, a French framework combining technical requirements with immunity from extraterritorial law. This option asks for a team able to maintain the infrastructure in return, or a partner who takes that on for you.

What each family means day to day

These three families do not differ only in legal theory, they also change a technical team's daily routine. The European cloud provider simplifies conversations with a data protection officer or a legal team, but may require adapting some use cases to the tools available in its catalogue. The large American provider with a European region generally offers the widest catalogue of models and the fastest integration, at the cost of closer contractual attention to transfer clauses. The locally hosted open model carries the heaviest internal load, security updates, infrastructure supervision, handling scale, but removes any ambiguity about where the data sits.

Choosing by data sensitivity, not by principle

None of these three families is the right answer on its own. A chatbot answering frequently asked questions on a public website does not carry the same requirements as an agent reading HR files or industrial plans. The initial diagnostic exists precisely to qualify that sensitivity before recommending an architecture, so the project does not pay for a technical constraint it does not need, or skip one it actually requires.

Common mistakes when choosing AI hosting

The first mistake is choosing a hosting provider before qualifying the actual sensitivity of the data, relying on general reputation rather than an examination of the specific project. The second is stopping at the server location without checking the law applying to the company operating it, when the two questions are distinct and need separate answers. The third is not rereading the clause on model training, assuming a general privacy policy automatically covers professional exchanges. The fourth is neglecting reversibility, assuming a project will never need to change provider, until a price increase or a policy change makes that change necessary.

Our AI diagnostic qualifies these criteria before any hosting recommendation, and leads depending on the case into a full project through our application development methods or into an AI agent sized to the actual sensitivity of the data being handled. You can browse examples of hosting choices in our projects.

A checklist before signing with a hosting provider

Before signing a hosting contract for an AI project, a series of simple checks helps avoid most of the bad surprises described above. Have you listed precisely which fields travel in the prompt sent to the model, beyond just the data stored in your database? Do you know, for this specific provider, which country both the storage servers and the servers running the model sit in? Have you identified which law applies to the company operating those servers, regardless of their geographic location? Have you reread, in the contract rather than on the marketing page, the clause on training the model from your exchanges? And finally, does your technical architecture route through an abstraction layer that would let you switch providers without rewriting the whole application?

These five checks do not replace a full diagnostic, but they are often enough to rule out the least serious proposals before even entering deeper contract negotiations. A provider who answers each of these five questions clearly and in writing deserves consideration. A provider who dodges one of them, or who systematically points to general documentation instead of a precise answer about your case, deserves further questioning before any signature.

Sources

Frequently asked questions

Is my data automatically safe if my hosting provider is in France?

No. Hosting in France answers part of the question, applicable law and proximity, but you still need to check who processes the data when the model is called, and whether that processing happens elsewhere.

Does a US hyperscaler with a European region comply with the GDPR?

A European region and standard contractual clauses allow compliance with the GDPR for storage and processing carried out in the EU. The 2023 adequacy decision also governs transfers to the United States for companies adhering to the Data Privacy Framework. Guarantees vary by service, so the contract still needs checking.

Why does a locally hosted open model change the question?

Because the data never leaves the infrastructure you control, or that of a hosting provider you chose specifically. In exchange, someone has to maintain that infrastructure, in house or through a partner.

At what stage of the project should these questions be asked?

As early as the diagnostic, before any quote. The hosting choice should follow from how sensitive the data actually is, not the other way round.

Let's talk

A case like this at your end?

We always start with a diagnostic: what can be automated, what must not be, and what it really costs.

Book a diagnostic