The dependency you're really choosing when you "adopt AI"
"Adopt AI" sounds like one decision. For a European company that has to keep data strictly under control, it's really a bet across inference, data, weights, jurisdiction, hardware cost — and time. Why there's no easy choice between American, Chinese, and European models.
Everyone in the world is talking about "adopting AI." Almost nobody is talking about what you're actually committing to underneath it.
Because "adopt AI" sounds like one decision. For a European company with a strong requirement to keep data strictly under control, it's really a bet across several axes at once — and they don't all point in the same direction.
When you commit to a model, you're deciding:
- Where inference runs: your own GPUs, a private EU cloud, or someone else's API
- Who can see the data: only you, or a provider, and under what contract
- Where the weights come from: American, Chinese, European; open-weight or closed
- Whose jurisdiction the provider sits under, and what that means the day the rules change
Most AI-strategy conversations focus on capability and price. Some discuss whether inference should run internally or through an API. Very few discuss the full dependency stack. And that matters, because the best model on a benchmark is not necessarily the best model for the organisation.
If you want frontier capability, the strongest options are still American closed models like GPT or Claude. They're excellent — but you're consuming them through someone else's infrastructure, under someone else's commercial and legal perimeter.
If you want self-hosted efficiency, Chinese open-weight models like Qwen are among the most attractive. Qwen3.6-35B-A3B is a sparse mixture-of-experts model: 35B total parameters but only ~3B active per token. That keeps it fast and cheap to run. The catch isn't capability, it's governance: standardising on Chinese weights raises training-data and jurisdiction questions that some boards won't approve, even when the weights run entirely inside your walls.
If you want a serious European option, Mistral is the obvious option, but the trade-off is different. Mistral Small 4 is also mixture-of-experts (119B total, ~6B active), and the full 119B has to fit in memory too. It's a heavier model to host, but its case isn't unit economics; it's a European provider, an enterprise posture, a self-hostable path, and a clearer story about where your AI dependency sits.
So the decision isn't simply "which model is best?" It's closer to: "which compromise are we willing to institutionalise?"
- A Qwen-style model may be the rational default for high-volume self-hosted workloads: efficient, capable, cost-effective on internal GPUs.
- A Mistral model may be the rational choice where governance, jurisdiction, supportability and European strategic control matter enough to justify the extra hardware.
- A frontier API may still be the rational escalation layer for the hardest tasks, where the quality gap matters more than locality or unit economics.
And here's the axis nobody puts on the slide: time
When you invest in a model, you're not buying this quarter's benchmark winner. You're choosing a dependency you may have to live with for two to five years — the same way you do with any serious software platform.
Today, the strongest frontier capability is largely American. The most efficient self-hostable open-weight models are often Chinese. The serious European option, Mistral, is more expensive to run and not quite frontier-level. All three of those statements have a short shelf life — and that's exactly the point.
You're not choosing a model. You're choosing a dependency while the ground keeps moving.
So the honest question is not "which model is best right now?" It's: across inference, data, weights, jurisdiction, hardware cost, and time — which dependencies can our organisation still live with in three years?
And perhaps more importantly: is anyone actually deciding that on purpose, or is it being chosen by default?