"The directives are in place, we're looking for alternatives to Copilot." I hear this from leaders of small and mid-sized companies, usually followed by: "We're staying on Office 365 for now, but we want a path of at least five years to get out."
They are right on both counts. Nobody switches off Microsoft 365 on a Monday morning, and nobody has to in order to take back control of their AI. You can move one layer at a time without breaking what works.
The first issue is confidentiality. One executive put it this way: "We can't guarantee our data won't be used."
Copilot runs in Microsoft's cloud, and Microsoft is an American company subject to US law, including the CLOUD Act, wherever its servers happen to be.
On 10 June 2025, before a French Senate inquiry committee, Microsoft France's director of public and legal affairs stated under oath that he could not guarantee French customers' data would never be handed to US authorities. When a supplier cannot promise that, its customers cannot promise it to theirs.
The second issue is cost. A per-user licence paid for the whole team, including people who never open it, adds up. And one question keeps coming back: do teams really use the AI they are paying for?
The objection I hear most fits in one sentence: getting out of Microsoft is impossible, or too risky. It's true if you picture a full switchover.
Email, files, user accounts and access rights all live in Microsoft 365. Replacing everything in one go is a risk few companies can absorb.
Ask a different question instead: which data goes today to an AI you don't control, and how do you route those uses through a path you do control? That gets settled use case by use case, without touching office tools. Email and files move last, or never if there's no point.
This is the order I follow. Each step pays off on its own, and you can stop at any of them without losing what you've invested.
Before picking a tool, I look at who uses AI, for which tasks, and which data goes into the prompts: contracts, HR files, customer data, health data. That classification drives everything else. This is often where you find a process problem rather than an AI problem, which I cover in the article on mapping processes before AI.
Instead of letting each team open its own account with a provider, every request goes through a single entry point, one API in front of several models. It logs exchanges, applies rules based on how sensitive the data is, and lets you switch models without changing your teams' tools. This is the piece that makes everything else reversible.
The gateway measures consumption per team and per use case. You set quotas, see what is actually used and pay for what you consume, rather than a per-seat licence for everyone. It's also the most honest answer when someone asks whether teams really use it: the gateway's figures show it.
For data that must not leave, open models run on servers in France, or directly on your premises. For the most sensitive cases, the server can run with no internet connection at all. Other uses can keep going to commercial models, behind the same gateway.
I favour open source components, open formats and a full data export at any time. The test is simple: if you want to bring everything back in-house tomorrow, you shouldn't have to buy back a single licence. If the answer depends on a vendor's goodwill, you've only swapped one dependency for another.
Nothing in this path forces you to switch off Microsoft 365. Your teams keep their email and documents.
What changes is the route data takes when it goes to an AI. The gateway becomes the place where you decide, and you can then move other pieces at your own pace, over the timeframe you chose.
That is what makes a five-year horizon realistic: at each step, the company depends a little less on a single supplier.
"Training is fine, now we have to do it for real, in projects." I agree: a sovereign AI nobody uses protects nothing and earns nothing.
So I always start with one or two concrete uses chosen with the teams who will rely on them (meeting minutes, sorting incoming requests, preparing a quote), and we measure actual use in the gateway before opening more.
I start from your uses and constraints, then put the pieces in place in this order.
A single entry point to the models, with logging, rules by data sensitivity and model switching without touching your teams' tools.
Consumption tracked per team and per use case, with quotas. You pay for what is actually used, and you can see who uses it.
Open models on servers in France, or installed on site, cut off from the internet when the case calls for it.
Open source components, open formats, full export at any time. You can bring everything back in-house without buying back a licence.
One or two concrete cases deployed with the teams who use them, measured, then extended, rather than one more proof of concept.
I build these pieces in my own companies: France Nuage, a cloud hosted in France on open source technology that offers an AI gateway, and Recapro, an AI meeting-minutes product that can be installed on the customer's premises and run offline.
France Nuage is not currently SecNumCloud-qualified or HDS-certified (the French health data hosting certification). For health data, I point you to an HDS-certified host and build the path around it.
Yes, and I make it a condition from the start. The components are open source, data can be exported at any time in open formats, and nothing forces you to buy back a licence to bring it all in-house. If you want to change provider or take everything back, you leave with your data, your configuration and the documentation.
Not in the architecture I put in place. Sensitive uses run on models hosted in France or on your premises, with nothing sent to a third party. The AI gateway applies rules by sensitivity level, so an HR file or health data doesn't go to a service you haven't approved.
The gateway measures actual use, per team and per use case. We start with one or two uses chosen with the teams involved, look at what gets used every week, and only open new ones once the first have found their place.
Yes, if the architecture allows for it. A locally installed model works without an internet connection, and results sync as soon as the device is back on the company network. I raise the field question during scoping, because it changes the choice of hardware and models.
Often yes, though not always cleanly. We use scheduled exports, read access to the database when the contract allows it, and as a last resort user-interface automation. I also recommend requiring an API and a reversibility clause at the next renewal of the vendor contract.
No, email and documents can stay on Microsoft 365 throughout the transition. What changes is the route data takes when it goes to an AI: it goes through a gateway you control. You then decide, piece by piece, what you move and how fast.
One scoping call is enough to map your uses, your sensitive data and the first useful step.
Microsoft, Microsoft 365, Office 365 and Copilot are trademarks of Microsoft Corporation. This page is not affiliated with or endorsed by Microsoft.
