Local AI for Hospitals: §203 StGB, HIS Integration and RAG

AI in the hospital without putting patient data into the cloud? We build local, §203-compliant AI in your data centre - see AI for hospitals and AI for confidentiality professionals, or book an initial consultation.

Discharge letters, tumour-board preparation, DRG coding - in a hospital all of this occurs at large volume and ties up clinical time. AI can provide massive relief here. The problem is not the AI but where the data flows. Patient data may not leave the hospital network - so cloud AI is not an option.

The good news: there is a clear, legal path. It runs through AI in your own data centre, air-gapped on request. This article frames the legal situation, shows the permitted operating models, and explains how we build a RAG pipeline on your hospital knowledge - scaled to hospital size.

Table of contents

• The legal situation in 2026: §203 StGB and GDPR Art. 9
• Why cloud AI becomes a risk for hospitals
• Operating models for hospital 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. In a hospital many professionals are subject to this duty; seizure protection even extends to the custody of the medical institution. Health data is specially protected under Art. 9 GDPR, plus the state hospital laws.

For engaging external AI providers, §203 (3) s. 2 StGB applies: a participating person may only have secrets revealed to the extent necessary - and is itself included in liability under §203 (4) StGB. Hospitals conclude contracts with providers under Art. 28 GDPR that also cover §203 (4): employees and participating persons are bound to confidentiality in text form.

In practice: health data does not belong in web-based standard AI. Providers like OpenAI or Anthropic offer neither §203 provisions nor C5 certification nor a German responsible entity. Where a cloud provider processes health data for AI, C5 Type 2 certification and a German location are required. Local AI avoids these hurdles because the data never leaves the building in the first place. 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 hospitals

Cloud AI with patient data is structurally problematic:

1. The subprocessor chain. An AI provider itself uses subprocessors (Azure, AWS, and others). In a hospital with many professionals, every entity would have to be bound individually - not practically feasible.
2. The CLOUD Act. US providers are subject to the US CLOUD Act. An EU region does not protect as long as a US parent company stands behind it.
3. C5 and responsibility. For health data in the cloud, C5 Type 2 evidence and a German responsible entity are required - regularly not provided by the large AI vendors.

With local AI in your own data centre most of these requirements disappear: the data stays in-house, air-gapped on request. Because we retain maintenance access, we remain a participating person - which is why we supply the §203 contract package for the build and maintenance phase.

Operating models for hospital AI

At hospital scale we rely primarily on your own hardware:

• Dedicated GPU server or LLM hosting. For the large volume of a hospital - many users, high throughput. Operated in your own data centre, air-gapped on request, with an OpenAI-compatible API for HIS integration.
• On-premise appliance (AI Cube). For individual departments or as a pilot - turnkey, local.
• Managed operation in German infrastructure. Where an own data centre is not an option, we operate the AI in a German data centre with a short, controllable provider chain.

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 internal guidelines and SOPs 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 (guidelines, SOPs, documentation) 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 and department 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 - important for audits.

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:

• HIS and case documentation. Connection to your hospital information system for research in the treatment context.
• Internal guidelines and SOPs. In-house standards as a RAG source for consistent drafts.
• Medical literature and guidelines. Where permitted by licence, as a supplement.
• Knowledge base. Hospital know-how 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 - by department and role. This matters especially in a hospital with many departments.

How we work at WZ-IT

We deliver hospital 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 enters the data centre.
2. Build and integrate. Setup in your own data centre (air-gapped on request), RAG with access control, HIS integration, confidentiality obligation plus DPA.
3. Operate and maintain (optional). Updates, monitoring, model upgrades and RAG curation as a contract - or your IT operates it after handover.

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

Further guides

• AI for hospitals - the solution page with use cases and hardware options.
• AI for confidentiality professionals - the cross-industry §203 framework (also for medical practices 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 in your own data centre, §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)
• BSI: Cloud Computing Compliance Criteria Catalogue (C5)
• European Commission: Regulatory framework on AI (EU AI Act)