Swiss companies are past the question of whether to use AI. In a 2025 survey of Swiss SMEs, the share deliberately using AI rose from 22% to 34% in a year, and 57% of those using it reported working more efficiently. The harder question is what happens after the pilot, and who you trust to get you there.
That is where the market gets confusing. "AI consultant" describes a strategy workshop, a machine learning specialist, a systems integrator and a full engineering team equally well. The label tells you almost nothing about whether the person across the table can put a system into production and keep it running.
Read those last two figures together. Nearly everyone is using AI; barely half have it working inside a business area. The distance between those numbers is the work, and it is engineering work more than it is strategy work.
Why the gap exists
A proof of concept can look impressive within days. Production is a different problem. As soon as an AI application reads internal data, talks to your CRM or ERP, or takes an action on someone's behalf, ordinary engineering questions arrive all at once. Who is allowed to see what? What happens when it fails? Where are outputs logged? Which data leaves the company? How do you test a new model version, and how do you roll one back?
The blockers Swiss companies report are consistent with that. EY's 2026 survey put data quality and data silos first, ahead of security and privacy concerns, with a shortage of skilled people close behind. None of those are model problems.
The regulated sectors are further along, and hit the same wall
FINMA surveyed around 400 supervised institutions in 2025. About half were already using AI or building their first applications, and another 25% planned to within three years. The risks they ranked highest were data quality, data protection and explainability.
Nine questions worth asking
Compare capabilities rather than labels. These are the questions that reliably tell the two kinds of supplier apart.
Do they start with the business case?
A first conversation should be about processes, costs, bottlenecks and users. If a specific model or platform gets recommended before anyone understands your data, the analysis has been skipped.
Do they understand your data before your model?
Ask how sources get connected, how permissions carry through, how data quality is checked and how access is logged. A capable model on unreliable data produces confident nonsense.
Can they build what they propose?
Ask who writes the pipelines, APIs, interfaces and deployment after the workshop ends. A slide deck is not an implementation, and the handover between the two is where projects die.
Can they integrate with what you already run?
AI that sits beside your systems rarely changes a process. Value appears when it can reach documents, APIs, CRM, ERP and support tooling under controlled permissions.
Can they explain where your data goes?
"The cloud is secure" is not an answer. You want the processing location, the subprocessors, what gets stored or logged, how access rights work, and which controls are technical rather than contractual.
How is success measured?
Agree the metric before the work starts: handling time, automation rate, answer quality, error rate, cost per case, or a business KPI. Then agree what result would justify stopping.
How do they evaluate model quality?
AI systems cannot be signed off against a fixed input and output the way ordinary software can. Ask for the evaluation set, the failure taxonomy and how regressions get caught before users see them.
What happens after launch?
Models, data sources and interfaces all change. Ask about monitoring, model versioning, rollback, incident handling, documentation and who is accountable at three in the morning.
What would they not solve with AI?
The most revealing question of the nine. A partner who cannot name a case where AI is the wrong tool is selling a product rather than advising you.
Data protection is an architecture question, not a launch checklist
For Swiss companies this shapes the build rather than following it. The Federal Data Protection and Information Commissioner has been explicit that the existing Swiss Data Protection Act already applies to AI-supported processing of personal data. It requires transparency about purpose, how the system works and where the data comes from, and high-risk processing can require a data protection impact assessment.
As of August 2026 Switzerland has no general AI act. The federal administration is preparing a consultation draft, expected by the end of 2026, covering transparency, data protection, non-discrimination and supervision. Companies doing business in the EU have a second layer to check: the EU AI Act can reach suppliers outside the Union, and its transparency obligations under Article 50 have applied since 2 August 2026, with longer transition periods for parts of the high-risk regime.
The practical consequence is that the decisive questions land early. Which data does the system genuinely need? Where is it stored? Which third parties receive it? Which users may see which records? What may an agent do on its own, and what still needs a human to approve it? Those are architecture decisions, and retrofitting them costs far more than designing for them.
Reading the three kinds of supplier
Strategy only
Useful for framing and prioritisation. The risk is a roadmap nobody can execute.
- Workshops, use case maps, business cases
- Ask who builds it, and get a name
- Works when you have a strong internal engineering team
Models only
Deep model expertise, thin on the surrounding system. Often the most interesting part of the problem, rarely the hardest.
- Data science, fine-tuning, evaluation
- Ask about identity, permissions and deployment
- Works when integration is already solved
End to end
Strategy, engineering and operations under one accountable owner. The handovers disappear because there are none.
- Use case selection through to running the system
- Software, cloud and DevOps alongside model work
- Ask for a case where they recommended stopping
How we approach it at Alpine Edge
Our own position sits deliberately at the intersection of AI, software engineering, cloud infrastructure and DevOps, because that is the boundary most AI projects have to cross straight after the prototype. The assistant suddenly needs authentication. Company data needs connecting. Internal APIs need to be reachable under control. Deployments need automating. At that point an AI experiment has become a software and infrastructure project.
- 01Audit
Understand before proposing
- Use cases scored on value, feasibility and data availability
- Data sensitivity, storage locations and who may access what
- Existing infrastructure, identity and integration points
- Compliance requirements, including FADP obligations
- 02Build
Into your environment, not beside it
- Self-hosted or private LLMs where data cannot leave
- Retrieval over your own documents, with permissions preserved
- MCP servers and agents wired to real systems
- PII detection and redaction, encryption, role-based access, audit logging
- 03Run
The part that decides whether it lasts
- Monitoring, logging and cost tracking
- Model versioning and rollback
- Iteration against the metric agreed at the start
- Knowledge transfer, so the capability stays with your team
A self-hosted model on its own solves nothing. It becomes useful once it has data access, retrieval, software integration, access control, monitoring and a workflow someone actually follows.
Access to AI is no longer an advantage. Almost everyone has it. The advantage is integrating it into your processes, data and software better than your competitors do.