Six AI adoption challenges Swiss companies hit
Most enterprise AI pilots never reach production. The six blockers Swiss and DACH mid-market companies run into, and what actually resolves each one.
The gap between AI pilots and AI in production is the defining problem of the current cycle. Not model quality — that has rarely been the constraint. The constraint is everything around the model.
What follows is drawn from work with mid-market companies in Switzerland and the wider DACH region. The pattern repeats with unusual consistency.
Challenge 01 · Strategy
The initiative has no owner and no decision attached
Most stalled AI programmes share a shape: a capability was pursued rather than a decision. “We should be using AI” becomes a proof of concept, the proof of concept works, and then nobody can say what it changes.
A useful AI initiative names a decision that is currently made badly, slowly, or inconsistently — and proposes to make it better, faster, or more consistent. If you cannot name the decision, you do not have a use case yet.
The fix. Before any model work, write one sentence: “Today, X is decided by Y in Z time, and it goes wrong when W.” If that sentence is hard to write, the problem is not ready.
Challenge 02 · Data foundations
The data is not as ready as the slide says
This is the most common blocker, and the least visible before you start. Data exists, but it is not labelled, not consistent across systems, not reliably timestamped, or not accessible without someone running an export by hand.
The symptom is a pilot that works beautifully on a curated extract and falls apart on the live feed.
The fix. Check three things before committing: can the system access the data automatically, is it consistent enough for the question being asked, and does it cover enough history. Weeks of data work now is cheaper than a pilot that dies at integration.
Challenge 03 · Infrastructure
Legacy systems have no way to answer
The model is not the integration problem. The system of record is. An ERP that exposes no API, a scheduling system that only produces overnight batch exports, a document store with no structure — none of it stops a pilot, and all of it stops production.
The fix. Map the integration path before the model. If the only route to the data is a nightly batch, you cannot build anything real-time, and knowing that in week one changes what you build.
Challenge 04 · Talent
Hiring is not a plan on a Swiss timeline
The Swiss market for senior ML and data engineering is tight and expensive. A role opened today is realistically filled in six to nine months, if it is filled. Meanwhile the roadmap waits.
Hiring is a legitimate long-term answer. It is not a plan for something that has to move this year.
The fix. Separate what genuinely needs in-house depth — domain knowledge, architecture ownership, governance — from what does not. The first should be hired for. The second can be brought in, which is what our dedicated engineering teams work is usually solving.
Challenge 05 · Governance and compliance
Compliance arrives after the build, not before
In DACH this is not optional and it is not a formality. Under the EU AI Act, systems influencing employment, credit, or essential services carry documentation, logging and human-oversight obligations. Swiss data protection under revDSG carries its own requirements around personal data, and GDPR applies wherever EU data is involved.
The expensive failure is discovering this after the system is built, when governance has to be retrofitted into an architecture that never anticipated it.
The fix. Ask three questions at design time, not at launch: what personal data does this touch, what decision does it influence, and where is it processed. The answers shape architecture. Retrofitting them does not work cleanly.
Challenge 06 · The pilot-to-production gap
Nothing was built to run
A pilot is judged on whether it works. A production system is judged on whether it keeps working — when the data drifts, when the vendor changes the model, when the person who built it leaves.
That gap is monitoring, versioning, rollback, cost control and a named owner. None of it is interesting, all of it is the difference.
The fix. Decide the production bar before the pilot starts, and make the pilot demonstrate it: how will we know this is degrading, who is called, and what does rollback look like. Our MLOps and AI infrastructure work exists because this is where most initiatives stop.
A more realistic path
The companies that get through share an approach rather than a technology:
- One process, narrow. Not a platform, not a strategy — one decision, deliberately small.
- Real data from day one. Synthetic data hides exactly the problems you need to find.
- The production question asked first. Monitoring and ownership designed in, not added.
- Compliance at design time. Cheaper by an order of magnitude than after.
- A fixed end point. An initiative that can run indefinitely usually does.
None of this is exotic. It is ordinary engineering discipline applied to a category of system that often gets exempted from it — and the exemption is the problem.
If a pilot is stuck somewhere in this list, the useful conversation is usually about which of the six it is, not about the model. Our AI strategy work starts there, and a first conversation is non-binding.