Open-Source-KI im Gesundheitswesen — Chancen und AI-Act-Pflichten

Open-Source-KI kann im Gesundheitswesen sinnvoll sein, wenn Sie drei Bedingungen gleichzeitig erfüllen: klare Zweckbestimmung, saubere Datenarchitektur und belastbare Einordnung nach EU-VO 2024/1689. Für Krankenhäuser und MedTech-Unternehmen ist der kritische Punkt nicht die Offenheit des Modells, sondern ob daraus ein Hochrisiko-System nach Art. 6, Anhang I oder Anhang III wird.

Letzte Aktualisierung: 23. März 2026

Die operative Reihenfolge ist eindeutig: zuerst den medizinischen Use Case klassifizieren, dann die Rollen von Anbieter und Betreiber prüfen und erst danach das Modell auswählen. Für den Branchenkontext helfen die Übersicht zu AI Act im Gesundheitswesen, die Pflicht aus Artikel 4 und die Systemlogik aus AI Act Hochrisiko-KI nach Annex III.

Welche OS-Modelle eignen sich für Medizin?

Für medizinische Workflows eignen sich offene Modelle nur dann, wenn sie sprachlich stabil, lokal betreibbar und lizenzrechtlich belastbar sind. Im Klinikalltag sind deshalb kleine bis mittlere Modelle für Dokumentation, Klassifikation und Wissenssuche meist realistischer als sehr große Foundation-Modelle für freie Diagnostik.

Für klinische Kernentscheidungen ist kein offenes Standardmodell ohne zusätzliche Validierung geeignet. Wer Diagnose, Therapieempfehlung oder Priorisierung automatisiert beeinflusst, verlässt den Bereich nützlicher Assistenz und bewegt sich in Richtung Hochrisiko oder Medizinprodukt.

Praktisch sollten Sie Modelle nach Funktion statt nach Popularität auswählen:

1. Dokumentation: Arztbriefe, Entlasszusammenfassungen, Kodierhilfen und Protokolle.
2. Suche: RAG auf Leitlinien, SOPs, Qualitätsdokumenten und internen Wissensbeständen.
3. Klassifikation: Triage-Vorstrukturierung, Ticketing, Befundkategorien und Textlabeling.
4. Transkription: Sprache-zu-Text für Diktat und Gesprächsdokumentation.

Die belastbare Faustregel lautet: Je enger der Use Case und je leichter die menschliche Freigabe, desto eher ist Open Source im Krankenhaus sinnvoll. Für eine rechtliche Einordnung der Modelloffenheit selbst ist ergänzend der Beitrag zu Open-Source-KI und dem EU AI Act relevant.

HOCHRISIKO: Annex I + III im Gesundheitswesen

Im Gesundheitswesen ist Hochrisiko für medizinisch wirksame KI regelmäßig der Standardfall. Art. 6 unterscheidet dabei zwei Wege: produktregulierte KI über Anhang I und eigenständige Hochrisiko-Systeme über Anhang III.

Die häufigste Fehlannahme lautet, dass nur diagnostische Systeme kritisch sind. Tatsächlich können auch Open-Source-Lösungen für Notrufannahme, Dringlichkeitsreihenfolge, Patientensteuerung oder Zugang zu Gesundheitsleistungen unter Anhang III fallen, selbst wenn sie nicht als klassisches Medizinprodukt vermarktet werden.

Für Krankenhäuser ist deshalb eine kurze Einordnungsmatrix sinnvoll:

1. Beeinflusst das System Diagnose, Therapie oder Priorisierung? Wenn ja, ist Hochrisiko ernsthaft zu prüfen.
2. Ist die KI Teil eines Medizinprodukts oder einer Sicherheitskomponente? Wenn ja, führt der Weg regelmäßig über Anhang I.
3. Steuert die KI Zugang, Reihenfolge oder Notfallentscheidungen? Wenn ja, ist Anhang III naheliegend.
4. Erzeugt die KI nur Entwürfe mit vollständiger menschlicher Prüfung? Dann kann der Fall außerhalb des Hochrisiko-Regimes liegen, bleibt aber nicht pflichtenfrei.

Seit dem 2. Februar 2025 gilt zudem Artikel 4 zur KI-Kompetenz unabhängig davon, ob ein System offen oder proprietär ist. Open Source reduziert im Krankenhaus also weder die Pflicht zur Schulung noch die Pflicht zur sauberen Klassifizierung.

MDR + AI Act = doppelte Regulierung

Medizinische KI muss häufig gleichzeitig die MDR, Verordnung (EU) 2017/745 und den AI Act erfüllen. Für MedTech-Unternehmen und Krankenhäuser ist genau diese Doppelregulierung der Kerngrund, warum ein technisch gutes Open-Source-Modell allein kein marktreifes oder einsatzreifes System ist.

Die kritische Schnittstelle ist die Zweckverschiebung. Wenn ein Krankenhaus ein offenes Basismodell mit eigenen Prompts, RAG und UI so umbaut, dass daraus faktisch klinische Entscheidungsunterstützung mit medizinischem Zweck wird, entsteht nicht nur ein IT-Projekt, sondern potenziell ein reguliertes System.

Für Software ist diese Schnittstelle besonders scharf. Nach MDR Anhang VIII Regel 11 wird Software, die Entscheidungen für diagnostische oder therapeutische Zwecke bereitstellt, regelmäßig mindestens der Klasse IIa zugeordnet; im AI Act zieht dieselbe Zweckrichtung den Pfad über Art. 6 Abs. 1 und die Konformitätslogik aus Art. 43 nach sich.

Vor einer produktiven Einführung sollten Sie mindestens diese Punkte dokumentieren:

1. Medizinischer Zweck: Welche Entscheidung oder Handlung wird beeinflusst?
2. Rollen: Wer ist Anbieter, wer Betreiber, wer Integrator?
3. Validierung: Mit welchen klinischen Daten und Qualitätsmaßen wurde getestet?
4. Grenzen: Wann darf das System nicht genutzt werden?
5. Fallback: Wie wird auf rein menschliche Bearbeitung umgeschaltet?

Die Doppelregulierung bedeutet nicht, dass Open Source untauglich ist. Sie bedeutet nur, dass Krankenhäuser und Hersteller ein gemeinsames Qualitäts-, Sicherheits- und Rechtsmodell brauchen, bevor das System an Patienten, Ärztinnen und Ärzte oder Pflegekräfte heranrückt.

Self-Hosting für Patientendaten

Self-Hosting ist für Patientendaten oft die sauberste Architektur, aber keine automatische Freigabe. Der Vorteil liegt in Datenlokation, Protokollierung und Zugriffskontrolle, nicht in einer Befreiung von DSGVO, Berufsgeheimnis oder AI-Act-Pflichten.

Für Gesundheitsdaten ist der technische Mindeststandard höher als in normalen Wissensprozessen. Sie brauchen Netzsegmentierung, Verschlüsselung ruhender und übertragener Daten, rollenbasierte Rechte, detaillierte Logs und ein belastbares Lösch- und Berechtigungskonzept.

Für die Praxis sollten Sie vier Speicherorte getrennt bewerten: Prompt, Modell-Cache, Vektordatenbank und System-Logs. Wenn nur einer dieser Pfade unkontrolliert in ein Drittland oder in ein unsauberes Backup läuft, ist der Datenschutzvorteil des Self-Hostings faktisch verloren.

Eine knappe Prüfliste für Krankenhaus-IT genügt oft, um die Architekturentscheidung zu strukturieren:

1. Bleiben Prompts, Embeddings, Logs und Backups vollständig im EWR?
2. Ist der Zugriff auf Patientendaten nach Rollen und Zweck getrennt?
3. Gibt es ein dokumentiertes Lösch- und Retention-Konzept?
4. Wer prüft Modell-Updates, Sicherheitspatches und Prompt-Injection-Risiken?
5. Sind RAG-Datenquellen medizinisch freigegeben und versioniert?

Self-Hosting lohnt sich besonders für Befundzusammenfassungen, interne Wissensassistenten und Dokumentationsunterstützung mit sensiblen Daten. Wer dagegen ein externes Modell nutzt, sollte den Betriebsweg mindestens so streng prüfen wie den medizinischen Use Case selbst.

Mistral 7B + Fine-Tuning für klinische NLP

Mistral 7B ist für klinische NLP nur als Basismodell interessant, nicht als sofort einsatzfähige Medizin-KI. Die Stärke liegt in schlanker Inferenz, guten Kosten pro Anfrage und der Möglichkeit, auf enge Aufgaben wie Entitätenextraktion, Arztbrief-Zusammenfassung oder Kodierhinweise feinzujustieren.

Für Krankenhäuser und MedTech-Teams sind vor allem drei Einsatzfelder realistisch:

1. Arztbrief-Zusammenfassung mit verpflichtender ärztlicher Endfreigabe.
2. Klinische Entitätenextraktion aus Befunden, Laborwerten und Freitext.
3. Terminologie- und Kodierunterstützung für strukturierte Dokumentation.

Das eigentliche Risiko liegt nicht im Modellnamen, sondern in der Zweckausweitung. Wenn ein feinjustiertes Modell nur Texte vorbereitet, bleibt die Betreiberperspektive meist im Vordergrund; wenn es klinische Entscheidungen strukturiert vorgibt oder priorisiert, steigt die regulatorische Last sofort.

Für ein belastbares klinisches NLP-Projekt sollten Sie deshalb klein anfangen:

1. Nur dokumentationsnahe Aufgaben wählen.
2. Keine autonome Diagnose- oder Therapieempfehlung erlauben.
3. Goldstandard-Datensätze mit medizinischer Annotation verwenden.
4. Fehlerklassen getrennt messen, etwa Auslassungen, Halluzinationen und falsche Priorisierung.
5. Jede Ausgabe durch Fachpersonal freigeben.

Technisch ist Mistral 7B attraktiv, weil es lokal auf planbarer Hardware läuft. Regulatorisch bleibt aber entscheidend, dass Sie aus klinischem NLP keine verdeckte Entscheidungsmaschine machen.

Checkliste: Open-Source-KI im Krankenhaus

Die schnellste belastbare Umsetzung beginnt nicht mit einem Modellvergleich, sondern mit einer Klinik-Checkliste. Wenn diese sechs Punkte nicht dokumentiert sind, ist der Rollout einer Open-Source-KI im Gesundheitswesen zu früh.

1. Use Case schriftlich definieren. Benennen Sie Zweck, Nutzergruppe, Datenarten und medizinische Wirkung.
2. Hochrisiko prüfen. Ordnen Sie den Fall gegen Art. 6, Anhang I und Anhang III ein.
3. Rollen klären. Dokumentieren Sie Anbieter, Betreiber, Integrator und IT-Verantwortung.
4. Datenarchitektur festlegen. Entscheiden Sie API, Private Cloud oder Self-Hosting mit Blick auf Patientendaten.
5. Validierung aufsetzen. Testen Sie mit medizinisch relevanten Qualitätsmaßen und dokumentierten Ausschlussgrenzen.
6. Schulung nach Art. 4 organisieren. Schulen Sie Ärztinnen und Ärzte, Pflege, Datenschutz, Qualitätsmanagement und IT rollenspezifisch.

Eine ergänzende Entscheidungstabelle hilft im Lenkungskreis:

Wer diese Logik intern verankern will, sollte die Fachbereiche nicht mit Einzelmemos steuern. Ein gemeinsamer Wissensstand über Artikel 4, Hochrisiko-Fälle und die Seite AI Act im Gesundheitswesen ist die Voraussetzung dafür, dass IT, Datenschutz, Qualitätsmanagement und medizinische Leitung dieselbe Sprache sprechen.

Für genau diesen Mindeststandard ist unsere EU AI Act Schulung gedacht. Sie verbindet Art. 4, Rollenlogik, Hochrisiko-Einordnung und dokumentierbaren Abschluss mit Zertifikat in einem Format, das sich für Klinikteams und MedTech-Projekte direkt nutzen lässt.

Quellen

• Art. 4 EU AI Act
• Art. 6 EU AI Act
• Art. 11 EU AI Act
• Art. 25 EU AI Act
• Art. 43 EU AI Act
• Anhang I EU AI Act
• Anhang III EU AI Act
• Verordnung (EU) 2017/745 über Medizinprodukte (MDR)