How Local AI Solves What LLM Providers Can't in Swiss Healthcare

Artificial intelligence has already become part of everyday healthcare. Physicians use it to draft reports, summarize findings, translate patient communication and search medical literature. Adoption is no longer the challenge. Integrating AI into Swiss healthcare without compromising privacy, governance and trust is.

This article explores why local AI is a better architectural fit for Swiss healthcare than cloud based LLMs, how projects like OpenMed put this idea into practice and what this means for the future of clinical AI.

Swiss Privacy Requirements

Under the revised Swiss Federal Act on Data Protection (revFADP), patient data is classified as sensitive personal data. Physicians are also bound by professional secrecy under Article 321 of the Swiss Criminal Code. These legal obligations are reflected in the FMH recommendations on generative AI, which explicitly recommend locally hosted or otherwise controlled language models whenever sensitive patient data is involved.

Commercial LLM platforms typically process on cloud infrastructure while under the revFADP, transferring sensitive personal data abroad is only permissible if the destination provides an adequate level of data protection. For many US based providers, this typically means certification under the Swiss-US Data Privacy Framework (DPF). Even then, using external AI services does not automatically permit processing patient data. Depending on the intended use, explicit patient consent may still be required.

Meeting these requirements does not automatically permit the use of patient data with external AI services. Depending on the intended use, explicit patient consent may still be required. That’s where local AI follows an entirely different architecture:

Bringing the Model to the Data

The principle itself is not new. Sensitive systems have long been designed around bringing computation to protected environments instead of exporting sensitive information to external platforms. AI simply becomes another workload following the same principle.

Local deployment, however, does not imply an isolated system. AI software may still establish outbound connections for telemetry, updates or other vendor specific functionality. Recent reports about Anthropic’s Claude Code, which surreptitiously transmitted user metadata as part of an anti abuse mechanism, illustrate why local AI should not be trusted blindly.

Firewall rules and network segmentation remain the responsibility of the organization’s IT security team. As AI systems become increasingly autonomous, they have already been observed circumventing safeguards and pursuing objectives contrary to user intent. Trust technical controls, not model behaviour.

The OpenMed Project

A relatively new and interesting example of this architectural approach is OpenMed. It is an open source, Apache 2 licensed platform for building AI powered healthcare applications that can be deployed within a healthcare provider’s own infrastructure. Instead of focusing on a single AI assistant, OpenMed provides the building blocks required to integrate language models into existing clinical systems.

Its architecture is built around a few key principles:

• Local first
  Models run inside the healthcare provider’s own infrastructure, keeping sensitive patient data within the existing trust boundary.

• Composable building blocks
  OpenMed provides reusable components for de-identification, document processing, retrieval, structured outputs and model orchestration that can be combined into larger clinical applications.

• Healthcare standards
  Native support for FHIR and HL7 enables integration with existing hospital information systems instead of creating another isolated AI tool.

• Model independence
  Applications are decoupled from the underlying language model, allowing organizations to switch models, combine multiple models or adopt future models without redesigning their applications.

• AI as infrastructure
  Language models become another infrastructure component that applications consume through stable interfaces rather than being tightly coupled to a specific vendor or deployment model.

This architecture enables practical use cases such as drafting discharge summaries, extracting structured information from clinical notes, de-identifying documents for research or integrating AI into existing FHIR workflows.

Local Operation Does Not Solve AI’s Fundamental Limitations

Local deployment changes where a model runs, not how it behaves. Hallucinations, bias, missing context and overconfidence remain inherent limitations of today’s LLMs.

Healthcare therefore requires what it has always required: Qualified professionals who make decisions, validate information and take responsibility for patient care. AI, when used responsibly, can support these processes, but it cannot replace them!

Conclusion

Healthcare demonstrates an important lesson that extends beyond medicine: Successful AI adoption is not primarily about choosing the most capable model, but about building an architecture that aligns with the environment in which it operates. Projects such as OpenMed are interesting because they approach AI from that perspective. They start with the architecture and then integrate the model into it.