Lokale KI für Kliniken: §203 StGB, KIS-Integration und der RAG-Weg

KI in der Klinik, ohne Patientendaten in die Cloud zu geben? Wir bauen lokale, §203-konforme KI in Ihrem Rechenzentrum - siehe KI für Kliniken und KI für Berufsgeheimnisträger, oder direkt ein Erstgespräch vereinbaren.

Entlassbriefe, Tumorboard-Vorbereitung, DRG-Kodierung - im Krankenhaus fällt all das im großen Volumen an und bindet ärztliche Zeit. KI kann hier massiv entlasten. Das Problem ist nicht die KI, sondern wohin die Daten dabei fließen. Patientendaten dürfen das Klinik-Netz nicht verlassen - Cloud-KI ist damit keine Option.

Die gute Nachricht: Es gibt einen klaren, legalen Weg. Er führt über KI im eigenen Rechenzentrum, auf Wunsch air-gapped. Dieser Beitrag ordnet die Rechtslage ein, zeigt die erlaubten Betriebsmodelle und erklärt, wie wir eine RAG-Pipeline auf Ihr Klinikwissen bauen - skaliert auf Klinikgröße.

Inhaltsverzeichnis

• Rechtslage 2026: §203 StGB und Art. 9 DSGVO
• Warum Cloud-KI für Kliniken zum Risiko wird
• Betriebsmodelle für Klinik-KI
• Die RAG-Pipeline: Komponenten Schritt für Schritt
• Mehrere Wissensquellen sicher anbinden
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Rechtslage 2026: §203 StGB und Art. 9 DSGVO

Die ärztliche Schweigepflicht ist über §203 StGB strafbewehrt. In der Klinik unterliegen viele Berufsträger dieser Pflicht; der Beschlagnahmeschutz erstreckt sich sogar auf den Gewahrsam der Krankenanstalt. Gesundheitsdaten sind nach Art. 9 DSGVO besonders geschützt, hinzu kommen die Landeskrankenhausgesetze.

Für die Einbindung externer KI-Dienstleister gilt §203 Abs. 3 S. 2 StGB: Eine mitwirkende Person darf Geheimnisse nur soweit erforderlich offenbart bekommen - und ist nach §203 Abs. 4 StGB selbst in die Strafbarkeit einbezogen. Kliniken schließen mit Dienstleistern Verträge nach Art. 28 DSGVO, die zugleich §203 Abs. 4 abdecken: Beschäftigte und mitwirkende Personen werden in Textform zur Verschwiegenheit verpflichtet.

In der Praxis gilt: Gesundheitsdaten gehören nicht in webbasierte Standard-KI. Anbieter wie OpenAI oder Anthropic bieten weder §203-Regelungen noch eine C5-Zertifizierung oder eine deutsche verantwortliche Stelle. Wo ein Cloud-Dienstleister Gesundheitsdaten für KI verarbeitet, werden eine C5-Type-2-Zertifizierung und ein deutscher Standort verlangt. Lokale KI umgeht diese Hürden, weil die Daten das Haus gar nicht erst verlassen. Ab dem 2. August 2026 greifen zudem Transparenzpflichten des EU AI Act für Betreiber (Stand Juni 2026, EU-Kommission). Dieser Beitrag ist allgemeine Information und keine Rechtsberatung.

Warum Cloud-KI für Kliniken zum Risiko wird

Cloud-KI mit Patientendaten ist strukturell problematisch:

1. Die Unterauftragnehmer-Kette. Ein KI-Anbieter nutzt selbst Unterauftragnehmer (Azure, AWS, weitere). In der Klinik mit vielen Berufsträgern wäre jede Stelle einzeln zu verpflichten - praktisch nicht leistbar.
2. Der CLOUD Act. US-Anbieter unterliegen dem US CLOUD Act. Eine EU-Region schützt nicht, solange ein US-Mutterkonzern dahintersteht.
3. C5 und Verantwortlichkeit. Für Gesundheitsdaten in der Cloud werden C5-Type-2-Nachweise und ein deutscher Verantwortlicher verlangt - bei den großen KI-Anbietern regelmäßig nicht gegeben.

Bei lokaler KI im eigenen Rechenzentrum entfällt der größte Teil dieser Anforderungen: Die Daten bleiben im Haus, auf Wunsch air-gapped. Durch unseren Wartungszugriff bleiben wir mitwirkende Person - deshalb liefern wir das §203-Vertragspaket für die Aufbau- und Wartungsphase mit.

Betriebsmodelle für Klinik-KI

Im Klinik-Maßstab setzen wir vor allem auf eigene Hardware:

• Dedizierter GPU-Server bzw. LLM-Hosting. Für das große Volumen einer Klinik - viele Nutzer, hoher Durchsatz. Betrieb im eigenen Rechenzentrum, auf Wunsch air-gapped, OpenAI-kompatible API für die KIS-Integration.
• On-Premise-Appliance (AI Cube). Für einzelne Fachabteilungen oder als Pilot - schlüsselfertig, lokal.
• Managed-Betrieb in deutscher Infrastruktur. Wo eigenes RZ nicht in Frage kommt, betreiben wir die KI in einem deutschen Rechenzentrum mit kurzer, kontrollierbarer Dienstleisterkette.

In allen Modellen kommen ausschließlich Open-Source-Bausteine zum Einsatz (kein Vendor Lock-in), und das §203-Vertragspaket ist Standard. Mehr zum branchenübergreifenden Rahmen unter KI für Berufsgeheimnisträger.

Die RAG-Pipeline: Komponenten Schritt für Schritt

Der eigentliche Wert entsteht nicht durch ein nacktes Sprachmodell, sondern durch Retrieval-Augmented Generation (RAG): Die KI beantwortet Fragen aus Ihren internen Leitlinien und SOPs statt aus generischem Trainingswissen - mit Quellenbezug. So bauen wir die Pipeline (mehr unter Custom RAG):

1. Ingestion. Dokumente werden aus den Quellsystemen eingelesen (Leitlinien, SOPs, Dokumentation) und normalisiert.
2. Chunking. Die Inhalte werden in sinnvolle Abschnitte zerlegt, an Gliederung und Kontext orientiert.
3. Embeddings + Vektordatenbank. Jeder Abschnitt wird in einen Vektor übersetzt und in einer Vektordatenbank (Qdrant) gespeichert - mit Zugriffs- und Abteilungs-Metadaten.
4. Retrieval und Re-Ranking. Zu einer Anfrage werden die passendsten Abschnitte gesucht und per Re-Ranking sortiert.
5. Generierung. Ein lokales Modell (Ollama oder vLLM) formuliert die Antwort - ausschließlich auf Basis der gefundenen Stellen, mit Quellenangabe.
6. Observability und Qualität. Mit Langfuse messen wir Qualität, Latenz und Kosten und machen Antworten nachvollziehbar - wichtig für Audits.

Genau diesen Stack betreiben wir auch selbst: Unser KI-Angebotsfinder auf wz-it.com ist ein produktives RAG-System auf Qdrant, LiteLLM/Mistral und Langfuse.

Mehrere Wissensquellen sicher anbinden

Wir binden mehrere Wissensquellen in dieselbe RAG-Pipeline ein - mit durchgesetzten Zugriffsrechten:

• KIS und Falldokumentation. Anbindung an Ihr Klinikinformationssystem für die Recherche im Behandlungskontext.
• Interne Leitlinien und SOPs. Hauseigene Standards als RAG-Quelle für konsistente Entwürfe.
• Medizinische Literatur und Leitlinien. Soweit lizenzrechtlich zulässig, ergänzend.
• Wissensdatenbank. Klinik-Know-how und Abläufe zentral durchsuchbar.

Entscheidend ist die Zugriffskontrolle: Über Rechte und Payload-Filter in der Vektordatenbank sieht jede Anfrage nur die Quellen, die sie - je nach Abteilung und Rolle - sehen darf. Das ist im Klinik-Umfeld mit vielen Fachabteilungen besonders wichtig.

Unser Vorgehen bei WZ-IT

Wir liefern Klinik-KI als Lebenszyklus, nicht als Gerätekauf:

1. Beraten und konzipieren. Workshop, Sizing, Datenklassifizierung und der §203-Vertragsrahmen - bevor Hardware ins RZ kommt.
2. Aufbauen und integrieren. Aufbau im eigenen Rechenzentrum (auf Wunsch air-gapped), RAG mit Zugriffskontrolle, KIS-Integration, Geheimhaltungsverpflichtung plus AVV.
3. Betreiben und warten (optional). Updates, Monitoring, Modell-Upgrades und RAG-Pflege als Vertrag - oder Ihre IT betreibt nach Übergabe selbst.

Die operativen Vertragstexte werden fachkundig erstellt; dieser Beitrag ersetzt keine Rechtsberatung im Einzelfall.

Weiterführende Guides

• KI für Kliniken - die Lösungsseite mit Use-Cases und Hardware-Optionen.
• KI für Berufsgeheimnisträger - der branchenübergreifende §203-Rahmen (auch für Arztpraxen und Psychotherapeuten).
• Custom RAG - wie wir RAG-Pipelines end-to-end bauen.
• KI-Hub - lokale KI-Infrastruktur, LLM-Hosting und RAG im Überblick.

Bereit für KI, die Ihre Patienten schützt? Wir bauen sie im eigenen RZ, §203-konform und betreiben sie auf Wunsch. Jetzt Erstgespräch vereinbaren.

Quellen

• §203 StGB (Verletzung von Privatgeheimnissen)
• Art. 9 DSGVO (Verarbeitung besonderer Kategorien personenbezogener Daten)
• BSI: Kriterienkatalog Cloud Computing C5
• Europäische Kommission: Regulatory framework on AI (EU AI Act)