How does a Swiss company choose the right AI model and vendor?

Choosing a model is a business decision, not a tech detail

The question “which AI model should I pick?” is often treated as a leaderboard comparison: the model with the highest benchmark wins. For Swiss SMEs that is misleading. A model that shines in synthetic tests can fail on the real use case, breach data protection, or cost a multiple in production. Model choice touches law, cost, IT architecture and risk at the same time.

A robust decision therefore starts not with the model but with the use case: what should the AI actually do, on which data, for whom, and at what error tolerance? Only then can criteria be weighted and vendors compared. This guide describes a repeatable framework rather than a fleeting model recommendation that is outdated within months.

The five core criteria at a glance

• Capability: does the model reliably solve the actual task – language, domain, context length, tool use, vision, and multilingual German/French/Italian/English coverage?
• Data location & sovereignty: where is data processed and stored, who has access, is training done on your inputs, and is Swiss or EU hosting available?
• Cost model & TCO: token pricing, volume discounts, fixed costs for self-hosting, and hidden costs for integration, monitoring and maintenance.
• Integration & operations: API stability, SDKs, latency, availability/SLA, model versioning and ecosystem maturity.
• Compliance & governance: revised FADP, the EU AI Act (extraterritorial), sector rules (e.g. FINMA requirements), a data-processing agreement, auditability and exit capability.

Capability: does the model fit the task?

Public benchmarks measure general ability, not your use case. Capability only becomes meaningful through your own small evaluation suite: 30 to 100 representative examples from your daily work with expected outputs. This lets you compare candidates under identical conditions and expose weaknesses leaderboards hide – for instance with Swiss terminology, dialect proximity or industry vocabulary.

Also check the frame conditions: required context length (long contracts or dossiers?), multimodality (image, PDF, audio), tool calls for automation, latency needs, and multilingual coverage across all four national languages. Often a mid-sized, cheaper model with clean retrieval (RAG) and good prompts beats the most expensive flagship.

Data location and sovereignty: the Swiss crux

For Swiss companies the data question often outweighs raw performance. Four points are central: where is data processed and stored? Are your inputs used to train the model (usually opt-out on business tiers)? Who can legally access it? And is there a data-processing agreement under the revised FADP? For personal data or trade secrets these answers are a precondition, not a nice-to-have.

The revised FADP does not strictly require hosting in Switzerland, but it does require adequate protection and transparency for cross-border transfers. Many large vendors now offer compute regions in the EU or Switzerland; for highly sensitive data (health, finance, public sector) EU/CH hosting or a self-run open-weight model can be the cleanest option. Swiss and European sovereignty options such as the open Apertus model from ETH Zurich and EPFL widen the field beyond US providers.

Cost model and total cost of ownership

The visible token price is only part of the bill. Compare real operating cost (TCO) over a realistic volume: input/output tokens, context size, retries from clarifications, caching discounts and batch options. A cheap headline price can end up dearer through long prompts or many iterations than a seemingly pricier model that solves the task on the first try. Actual prices change often – always consult the provider's current pricing.

With self-hosting the logic reverses: instead of variable token prices you carry fixed costs for GPU infrastructure, operations and expertise. It pays off at high, steady volume or when data sovereignty is decisive. Include the soft costs too: integration, prompt and evaluation effort, monitoring, model updates and staff training.

Integration, operations, compliance and exit

A model is only as useful as its embedding. Check API stability and backward compatibility, available SDKs, latency and throughput, documented availability (SLA), and ecosystem maturity (libraries, community, support). The versioning policy matters too: when old model versions are retired you must re-evaluate – plan this maintenance cycle in from the start.

On compliance you need a data-processing agreement under the revised FADP, transparency about sub-processors and cross-border transfers, and a classification under the EU AI Act. The EU AI Act is extraterritorial: it can reach Swiss providers whose systems are used in the EU or whose outputs are used there. In regulated sectors, FINMA requirements or professional secrecy add further duties. Finally, avoid vendor lock-in: prefer open standards, portable prompts and an architecture that keeps switching providers feasible.

The scorecard: weight and decide

Translate the five criteria into a simple scorecard. Weight each criterion by its importance to your use case (summing to 100%), rate each candidate on a 1-to-5 scale and multiply. This makes the decision transparent, defensible and auditable – and repeatable at every model update.

• Example weighting (adapt it!): compliance 25%, data location 25%, capability 20%, cost/TCO 15%, integration 15% – for heavily regulated data.
• Pilot before scaling: test the top two candidates in a bounded pilot with real data before committing.
• Do not lock in for good: keep the architecture swappable; the model landscape shifts in months, not years.