Sovereign AI: why French midsize companies can no longer wait

An HR director pastes an excerpt of payroll data into a consumer chatbot to draft a summary note. A financial controller uploads confidential budget figures into a tool nobody has checked for hosting location, let alone whether it feeds the model’s training data. These aren’t disaster scenarios — they happen every week inside midsize companies that have never asked whether their AI tools are sovereign. This is no longer a subject reserved for large corporations with a full-time data protection officer. Here’s what sovereignty actually means in practice, and why putting it off has already become a risk decision in itself.

What “sovereignty” doesn’t mean

The word became a marketing argument before it became a technical criterion, and that confusion is expensive. Sovereignty doesn’t mean “built by a French vendor” — a tool developed in France can easily host your data with a US cloud provider subject to the Cloud Act, raising the exact same jurisdiction questions as a foreign vendor. Nor does it mean “no American AI” — a model developed in the US, deployed on your own infrastructure, with no data flowing back to its developer, raises far fewer problems than a French-branded tool hosted elsewhere.

The real question isn’t who wrote the model. It’s who has access to your data, where it’s stored, under which jurisdiction, and what happens to it once processing is complete. These are contractual and architectural questions, not questions of nationality.

This marketing-driven confusion has a perverse effect: it pushes some midsize companies to pick a vendor for its flag rather than its guarantees, and to stop there. A quick read of the terms of service is often enough to reveal that a tool marketed as sovereign actually subcontracts hosting to a provider under foreign jurisdiction — which doesn’t make the tool unusable, but does make the marketing claim misleading if nobody checked before signing.

The real risk isn’t a data leak — it’s dependency

Sovereign AI tends to be framed as protection against hacking or industrial espionage. The most concrete risk for a midsize company lies elsewhere: operational dependency on a single vendor whose terms, pricing or underlying models can change overnight, with no real negotiating leverage for a company of that size. A midsize company that has built its HR or finance processes around one proprietary tool, with no migration path, ends up hostage to a commercial decision made thousands of miles away.

Sovereignty, in that sense, is first and foremost a question of reversibility: being able to switch model or vendor without rebuilding the whole setup. A deployment designed to work with any model, rather than locked to a single provider, turns a dependency risk into a simple technical parameter.

That dependency doesn’t show up immediately. It builds gradually, as business processes organize themselves around one specific tool’s quirks — an output format, a particular integration, a team habit. Two years later, migrating to another vendor, even a cheaper or better-performing one, looks like a project nobody wants to open. That inertia, more than the cost of the original contract, is the real price of dependency.

What the AI Act actually changes, and on what timeline

The European regulatory framework is accelerating this timeline. The AI Act imposes documentation obligations on high-risk uses starting August 2026 — December 2027 for entities covered by the Omnibus mechanism. Concretely, this means a midsize company using AI for decisions touching recruitment, performance evaluation, or HR management will need to be able to show how the system works, what data it was validated on, and what human oversight governs its recommendations.

An organization that discovers this obligation at audit time starts months behind. An organization that has built its AI governance on traceable foundations — localized data, clear processing contracts, a log of AI-assisted decisions — answers the request in a few weeks, with evidence already on hand.

This regulatory timeline isn’t only a large-corporation concern. A midsize company using AI to screen applications, evaluate performance, or steer internal mobility decisions falls squarely within the scope of high-risk uses under the AI Act. The text draws no distinction by company size on this point: the documentation obligation attaches to the use, not to the headcount of the company deploying it.

The four pillars of defensible AI governance

Serious AI governance for a midsize company rests on four concrete elements, not a charter of principles:

• Data location and hosting — knowing precisely where sensitive data is processed, and being able to demand it contractually rather than inferring it from a vendor’s terms of service.
• Model neutrality — an architecture that works with several models keeps an initial technical choice from turning into an irreversible strategic dependency.
• Usage traceability — a record of who used which tool, on what data, for what decision, available on demand for a data protection audit or a works-council consultation.
• No reuse of data to train third-party models — an explicit contractual guarantee, not an implicit assumption resting on the vendor’s good faith.

Sovereign AI isn’t a philosophical option reserved for large corporations; it’s a contractual clause any midsize company can negotiate today, provided it knows which one to ask for.

Why large corporations have a head start — and why it isn’t permanent

Large corporations have full-time data protection officers, dedicated legal teams, and compliance budgets most midsize companies don’t have. They started documenting their AI uses as soon as the AI Act discussions began, while a midsize company often discovers the subject during a vendor audit or a question raised at a works-council meeting.

That gap isn’t insurmountable, but it calls for a different method than the one large corporations use: not a ten-person compliance department, but simple architectural choices made from the outset — on-premise deployment rather than a default third-party API for sensitive data, processing contracts systematically reviewed before signature, and even a rough inventory of the AI tools actually in use across the organization. Most midsize companies, today, have no consolidated view of that inventory at all.

That’s where the real gap plays out: not in the sophistication of the tools deployed, but in the rigor of the contractual framework around them. A midsize company that systematically negotiates a no-data-reuse clause and an on-premise hosting option for its sensitive uses ends up, in practice, with governance as solid as a large corporation’s — without the dedicated budget or headcount the latter throws at the problem.

Governance built in three steps, not one grand program

Faced with the apparent scale of the subject, the temptation is to postpone it while waiting for a “full AI compliance program.” The opposite approach works better:

1. Map what’s actually in use — inventory the AI tools genuinely used across the organization, including those teams adopted on their own without formal validation, and flag which ones process sensitive data.
2. Set one simple deployment rule — for any HR, financial or strategic data, require processing on controlled infrastructure or a contract guaranteeing no data reuse, with no tacit exceptions.
3. Document as you go — log uses as they’re deployed, rather than attempting a retroactive reconstruction the moment an audit or a works-council consultation demands it.

This sequence requires neither a disproportionate budget nor immediate hiring. It requires one decision: treating AI governance as a leadership-level subject, not a deferred IT project.

Midsize companies that wait for a fully settled regulatory framework before acting will find themselves, at audit time, needing to close a two-year gap in a few months. Those asking the right contractual questions today will only need to pull out a file that’s already ready.