Healthcare organisations get more AI proposals than almost any other sector, and approve fewer of them. The reason is usually correct caution applied at the wrong point: the legal question is asked about the model, when it should have been asked about the data.
Under Swiss law health data is sensitive personal data, which raises the bar for every processing decision — consent, purpose, transfer, retention. That bar does not prohibit AI. It does determine which projects are straightforward and which need a year of preparation, and the difference between the two is not how clever the model is.
What does Swiss law actually require?
The revised Federal Act on Data Protection treats data on health as sensitive personal data, which means processing generally requires a clear legal basis, an explicit purpose, and proportionality between what is collected and why. Sensitive data also raises the threshold at which a data protection impact assessment becomes necessary, and tightens the conditions for disclosure to third parties — including processors abroad.
That last clause is where cloud AI services meet the law. Sending identifiable patient data to a service that processes it outside Switzerland is not automatically forbidden, but it is a decision with conditions attached, and the conditions have to be documented before the fact rather than reconstructed afterwards. Guidance is published by the Federal Data Protection and Information Commissioner.
There is a second regime that catches people by surprise. Software that is intended to diagnose, prevent, monitor or treat can be a medical device, with the conformity obligations that follow — a scheduling tool is not, a triage recommendation may well be. Swissmedic is the authority for that question, and it is worth asking early, because the answer changes the project rather than the paperwork.
Which projects clear the bar
The projects that move are the ones that either avoid identifiable patient data entirely, or keep it inside infrastructure the organisation already controls.
| Project | Data involved | Usual verdict |
|---|---|---|
| Roster and capacity planning | Staff and operational data | Straightforward |
| Supply and consumable forecasting | Purchasing history | Straightforward |
| Document and correspondence drafting | Administrative text, no patient identifiers | Straightforward with controls |
| Coding and billing support | Pseudonymised episode data | Feasible, needs assessment |
| Imaging or triage decision support | Identifiable clinical data | Slow: device rules may apply |
| Anything sending patient records to an external model | Identifiable clinical data | Stop and get advice first |
The pattern is consistent: administrative and operational work carries most of the near-term value and almost none of the legal weight. Clinical decision support carries the reverse. Organisations that start at the bottom of this table spend a year in review and deliver nothing; organisations that start at the top fund the harder work with results.
Why do pilots stall even when they are permitted?
Because the pilot was scoped as a demonstration rather than as a change to how work is done. This is not specific to healthcare — it is the failure described in AI adoption in Swiss companies: getting past the pilot — but healthcare amplifies it, because clinical and administrative staff have no spare capacity to absorb a parallel process that runs alongside the real one.
A pilot that adds a step will be abandoned regardless of its accuracy. A pilot that removes a step survives even when it is imperfect. The question to ask of any proposal is which of the two it is, and the answer is usually visible in whether anyone has been asked to stop doing something.
The second stall is ownership. A model that drafts correspondence needs someone accountable for what it drafts, a review path when it is wrong, and a record of both. Without that, the first bad output ends the programme — correctly.
A realistic first year
Start with one administrative process that is measurably slow, where the data never leaves your control, and where a named person can say whether the output was good. Run it in parallel, keep the record, and decide at the end of a quarter with evidence rather than enthusiasm.
In parallel — not afterwards — document the data protection position for the class of projects you actually intend to pursue, not just the one in front of you. The assessment is reusable; doing it once per project is what makes each project feel prohibitively slow. The same sequencing logic applies to security work generally, as in our cybersecurity priorities for Swiss SMEs.
Our AI and machine learning practice works with healthcare organisations on exactly this ordering: the data position first, one operational process second, clinical questions only once both are settled. It is slower to start and considerably faster to finish.
Related reading
- The revised FADP: what Swiss companies actually have to do
- AI adoption in Swiss companies: getting past the pilot
- AI and machine learning consulting
Working on this right now?
Tell us where you are in two questions. A consulting partner reviews every enquiry within 2 business days.