Local AI for Medical Practices: §203 StGB, GDPR Art. 9 and RAG

AI in the practice without risking confidentiality? We build local, §203-compliant AI on your hardware - see AI for medical practices and AI for confidentiality professionals, or book an initial consultation.

Writing doctor's letters, summarising findings, coding, searching guidelines - AI can save a lot of time in the practice. The problem is not the AI but where the data flows. Anyone entering patient data into ChatGPT or Copilot transmits it to third-party servers. For health data, that is regularly a breach of medical confidentiality - criminally sanctioned via §203 StGB.

The good news: there is a clear, legal path. It runs through local AI that never leaves the practice. This article frames the legal situation, shows the permitted operating models, and explains how we build a RAG pipeline on your practice knowledge.

Table of contents

• The legal situation in 2026: §203 StGB and GDPR Art. 9
• Why cloud AI becomes a risk for practices
• Operating models for practice AI
• The RAG pipeline: components step by step
• Connecting multiple knowledge sources securely
• How we work at WZ-IT
• Further guides

The legal situation in 2026: §203 StGB and GDPR Art. 9

Medical confidentiality is criminally sanctioned via §203 StGB and anchored in §9 of the (model) professional code for physicians. Health data is among the specially protected categories under Art. 9 GDPR - with the strictest standard data-protection law knows.

For AI with patient data, four regulations therefore apply at once: §203 StGB, GDPR Art. 9, the EU AI Act and - for diagnostic systems - the Medical Device Regulation (MDR, Rule 11). Entering clear patient data into the standard version of ChatGPT, Gemini, Claude or Copilot is regularly a breach of §203 StGB and the GDPR - regardless of whether the input is deleted afterwards.

Unlike lawyers or tax advisors, physicians have no dedicated service-provider norm like §43e BRAO. Here §203 (3) s. 2 StGB applies directly: a person participating in the professional activity (such as the IT service provider) may only have secrets revealed to the extent necessary - and is itself included in liability under §203 (4) StGB. We therefore bind ourselves to confidentiality in text form (§126b BGB) and are warned about the criminal consequences.

From 2 August 2026, transparency obligations of the EU AI Act for deployers also apply (as of June 2026, European Commission). This article is general information and not legal advice.

Why cloud AI becomes a risk for practices

Cloud AI with patient data is structurally problematic:

1. The subprocessor chain. An AI provider itself uses subprocessors (Azure, AWS, and others). Everyone who could see health data would have to be bound - not practically feasible with a long, opaque chain.
2. The CLOUD Act. US providers are subject to the US CLOUD Act. An EU region does not protect against this as long as a US parent company stands behind it.
3. Art. 9 GDPR. For health data, legally sound consent to cloud-AI processing can hardly be obtained in daily practice.

The DPA does not solve this: it governs data protection under Art. 28 GDPR, not the criminally sanctioned confidentiality. Both layers must be satisfied.

With local AI in the practice network most of this chain disappears: the data does not leave the practice. Because we retain remote-maintenance and admin access, we remain a participating person - which is why we supply the §203 contract package for the build and maintenance phase.

Operating models for practice AI

We implement three models - with a clear link to our services:

• On-premise appliance (AI Cube). A turnkey, quiet AI box in the practice network - no server room needed. Open WebUI, Ollama/vLLM and local models are pre-installed; ideal for single practices and small MVZ.
• Dedicated GPU server or LLM hosting. For larger MVZ with more users. Operated on your own hardware, with an OpenAI-compatible API for integration into the PMS.
• Managed fallback. If you do not (yet) want to operate your own hardware, you can have AI run in our EU infrastructure - with a short, controllable provider chain instead of a US hyperscaler.

In all models only open-source building blocks are used (no vendor lock-in), and the §203 contract package is standard. More on the cross-industry framework under AI for confidentiality professionals.

The RAG pipeline: components step by step

The real value comes not from a bare language model but from Retrieval-Augmented Generation (RAG): the AI answers questions from your own documents and guidelines instead of from generic training knowledge - with source references. This is how we build the pipeline (more under Custom RAG):

1. Ingestion. Documents are read in from the source systems (guideline PDFs, findings, structured inputs) and normalised.
2. Chunking. Content is split into meaningful sections, oriented around structure and context.
3. Embeddings + vector database. Each section is translated into a vector and stored in a vector database (Qdrant) - with access metadata.
4. Retrieval and re-ranking. For a query, the most relevant sections are retrieved and sorted by re-ranking.
5. Generation. A local model (Ollama or vLLM) formulates the answer - based solely on the retrieved passages, with source references.
6. Observability and quality. With Langfuse we measure quality, latency and cost and make answers traceable.

We run exactly this stack ourselves: our AI offer finder on wz-it.com is a production RAG system on Qdrant, LiteLLM/Mistral and Langfuse.

Connecting multiple knowledge sources securely

We connect multiple knowledge sources into the same RAG pipeline - with enforced access rights:

• Practice documentation and PMS. Connection to your practice management system for research in the practice context.
• Guidelines and medical literature. Where permitted by licence, as a RAG source.
• Your own templates. Doctor's-letter and findings templates for consistent drafts.
• Internal knowledge base. Practice know-how, SOPs and workflows searchable from one place.

The decisive factor is access control: through rights and payload filters in the vector database, every query only sees the sources it is allowed to see - a requirement generic cloud tools do not meet.

How we work at WZ-IT

We deliver practice AI as a lifecycle, not as a device purchase:

1. Advise and design. Workshop, sizing, data classification and the §203 contract framework - before any hardware arrives.
2. Build and integrate. On-premise setup in the practice network, RAG on your documents with access control, PMS integration, confidentiality obligation plus DPA.
3. Operate and maintain (optional). Updates, monitoring, model upgrades and RAG curation as a contract - or you operate it yourself after handover and training.

The operational contract texts are drafted by qualified professionals; this article does not replace case-specific legal advice.

Further guides

• AI for medical practices - the solution page with use cases and hardware options.
• AI for confidentiality professionals - the cross-industry §203 framework (also for hospitals and psychotherapists).
• Custom RAG - how we build RAG pipelines end to end.
• AI hub - local AI infrastructure, LLM hosting and RAG at a glance.

Ready for AI that protects your patients? We build it locally, §203-compliant, and operate it on request. Book your initial consultation now.

Sources

• §203 StGB (violation of private secrets)
• Art. 9 GDPR (processing of special categories of personal data)
• (Model) professional code for physicians - German Medical Association
• European Commission: Regulatory framework on AI (EU AI Act)