KI-Software für Kliniken: C5-Testat mit Modellanbieter und Inferenz planen

Diese Seite richtet sich an Anbieter von KI-Software für Krankenhäuser und andere Einrichtungen im Gesundheitswesen, die ein C5-Testat planen. Sie behandelt die Punkte, die es nur bei KI gibt: Modellanbieter, Inferenz, Datenwege und Freigabe von Modelländerungen. Ob und wie § 393 SGB V greift, einschließlich Verarbeitungsort und Niederlassung im Inland, steht auf der Seite § 393 SGB V. Wie man den Prüfungsgegenstand allgemein zuschneidet, beschreibt C5-Scope. Für die Prüfung des KI-Systems selbst, über die Infrastruktur hinaus, entwirft das BSI mit A5 einen eigenen Prüfrahmen. KI-SaaS außerhalb des Gesundheitswesens behandelt die Seite C5 für KI-SaaS; für Hersteller von Praxissoftware ohne KI-Schwerpunkt siehe C5 für Praxissoftware-Anbieter.

Das Beispiel: eine KI-Dokumentationsassistenz für Kliniken

Fiktives Beispiel. Ein Anbieter entwickelt eine Software, die aus diktierten Notizen und Daten aus dem Krankenhausinformationssystem Entwürfe für Arztbriefe erstellt. Ärztinnen und Ärzte prüfen und korrigieren jeden Entwurf, bevor er ins Krankenhausinformationssystem zurückgeht. Die Architektur:

• Anwendung mit Web-Oberfläche, Schnittstelle zum Krankenhausinformationssystem, Vorverarbeitung und Prompt-Aufbau, betrieben vom Anbieter auf einer Hyperscaler-Plattform in einer Region in Deutschland.
• Inferenz in zwei denkbaren Varianten: (A) Aufruf des Sprachmodells eines externen Modellanbieters über eine API oder (B) ein Modell mit offenen Gewichten, das der Anbieter selbst auf gemieteten GPU-Instanzen betreibt.
• Datenhaltung für Eingaben, Entwürfe, Protokolle der Modellaufrufe und eine Vektordatenbank mit Vorlagen je Klinik.
• Betrieb und Support durch ein eigenes Team; Überwachung über einen Logging-Dienst eines Dritten.

Dieselbe Software kann in beiden Varianten gleich aussehen. Für das Testat sind es zwei verschiedene Prüfungsgegenstände.

Ist der Modellanbieter ein Subdienstleister?

In Variante A in aller Regel ja. Der Katalog behandelt einen Dienstleister als Subdienstleister im Sinne des Berichts (Subservice-Organisation), wenn zwei Merkmale zusammen vorliegen: Seine Leistung ist für das Verständnis der Kunden relevant, und Kontrollen, die der Anbieter bei ihm voraussetzt (im Katalog: korrespondierende Kontrollen der Subservice-Organisation, Complementary Subservice Organisation Controls, CSOC), sind zusammen mit den eigenen Kontrollen des Anbieters erforderlich, um die Kriterien zu erfüllen. Deckt der Anbieter die Kontrollen des Dienstleisters schon durch eigene Überwachungskontrollen ausreichend ab, ist er kein Subdienstleister in diesem Sinn. Ein Sprachmodell, das jeden Arztbrief-Entwurf erzeugt und dabei Patientendaten erhält, erfüllt nach unserer Einordnung beide Merkmale.

Der Anbieter wählt dann zwischen zwei Methoden und nennt sie in der Systembeschreibung:

Carve-out entbindet nicht von der Verantwortung: Der Katalog sagt ausdrücklich, dass der Anbieter verantwortlich bleibt. In der Systembeschreibung stehen zum Modellanbieter Firmenname, Ort der Verarbeitung und Speicherung (Länderebene genügt), eine Einschätzung von Komplexität und Abhängigkeit und ob C5-Berichte verfügbar sind.

In Variante B betreibt der Anbieter das Modell selbst. Dann gehören Modellbetrieb, Modellaktualisierung und GPU-Konfiguration in den eigenen Prüfungsgegenstand, die GPU-Plattform ist der Subdienstleister.

Scope-Entscheidungen, die es nur bei KI gibt

Vier Entscheidungen sollten vor der Prüfung feststehen, weil sie Systembeschreibung, Kontrollen und Nachweise verändern:

1. Externe API oder eigenes Modell. Variante A verlagert Kontrollen zum Modellanbieter und verlangt dessen Überwachung, Variante B holt sie in den eigenen Scope. Wer zwischen beiden wechseln will, sollte das vor Beginn eines Typ-2-Zeitraums tun.
2. Protokolle der Modellaufrufe als Kundendaten. Prompts und Ausgaben enthalten Patientendaten. Nach unserer Einordnung gehören sie mit Aufbewahrungsfrist, Region und Zugriffsrechten in den Prüfungsgegenstand. PSS-12.01B verlangt, dass Kundendaten und Backups nur in der vereinbarten Region verarbeitet und gespeichert werden; das gilt dann auch für diese Protokolle und für den Logging-Dienst.
3. Training und Feinabstimmung. Fließen Kundendaten in ein Modell, braucht es eine dokumentierte Entscheidung, ob, mit welcher Rechtsgrundlage und mit welcher Trennung je Kunde. Wer das ausschließt, sollte es vertraglich und technisch belegen, etwa durch die Konfiguration beim Modellanbieter.
4. Trennung je Klinik. Eine gemeinsame Vektordatenbank für mehrere Kunden ist ein Fall für OPS-30 und OPS-31 (Trennung von Datenbeständen): Trennung entlang eines dokumentierten Schichtenmodells und eine Risikobewertung, die mindestens jährlich überprüft wird.

Freigabe: Modelländerungen wie Softwareänderungen behandeln

Ein neues Modell oder eine neue Modellversion verändert das Verhalten der Software, auch wenn kein Code geändert wurde. Wir empfehlen, Modelländerungen durch denselben Freigabeprozess zu führen wie Softwareänderungen, mit Test gegen eine feste Prüfmenge, Freigabe durch eine benannte Rolle und Protokoll. Drei Kriterien aus C5:2026 sind dabei hilfreich:

• DEV-13 verlangt eine gepflegte Liste der Softwarekomponenten für jede entwickelte oder integrierte Komponente; der Katalog nennt eine SBOM als Weg. Ein Modell mit Version und Herkunft gehört nach unserer Einordnung in diese Liste.
• DEV-14 verlangt, Software Dritter nur aus vertrauenswürdigen Quellen zu beziehen und die Authentizität nach Möglichkeit zu prüfen. Für Modellgewichte in Variante B heißt das: definierte Bezugsquelle und Prüfsumme oder Signatur.
• SSO-07 verlangt Transparenz über Dienstleister: Datenflüsse dokumentieren und Kunden informieren, welche Dienstleister ihrerseits Unterauftragnehmer einsetzen. Bei Modellanbietern, die selbst Rechenzentren Dritter nutzen, ist das schnell mehrstufig.

Bei einem Typ-2-Bericht muss die Systembeschreibung wesentliche Änderungen am internen Kontrollsystem im Prüfungszeitraum angeben. Ob ein Modellwechsel wesentlich ist, beurteilen Anbieter und Prüfer. Einen Wechsel des Modellanbieters, also eines Subdienstleisters, sollte man nach unserer Einschätzung als wesentlich behandeln. Planen Sie solche Wechsel deshalb nicht unbemerkt mitten in den Zeitraum.

Was die Klinik selbst beitragen muss

Ein Teil der Sicherheit liegt beim Kunden. Die Systembeschreibung nennt die korrespondierenden Kundenkontrollen (Complementary User Entity Controls, CUEC), die der Anbieter bei der Ausgestaltung seiner Kontrollen voraussetzt (Abschnitt 3.4.5.1 Nr. 7), und der Prüfer weist im Bericht darauf hin, dass die Kriterien nur bei wirksamen Kundenkontrollen erfüllt sind. Bei KI-Software sind das typische Kandidaten:

• Ärztinnen und Ärzte prüfen jeden Entwurf vor der Übernahme ins Krankenhausinformationssystem,
• die Klinik verwaltet Benutzerkonten und Rollen und entzieht Zugänge beim Austritt,
• die Klinik übermittelt nur die Daten, die für den Zweck nötig sind.

Formulieren Sie diese Kontrollen so, dass die Klinik sie umsetzen und belegen kann. Für Kunden im Anwendungsbereich von § 393 SGB V ist das keine Formsache: Das Gesetz verlangt, dass die im Prüfbericht enthaltenen korrespondierenden Kriterien für Kunden umgesetzt sind. Der Katalog nennt solche Kriterien für Kunden bei ausgewählten C5-Kriterien als Hilfe, um die CUEC zu bestimmen; wie sich der Gesetzesbegriff zu den CUEC verhält, ordnet die Seite § 393 SGB V ein.

Nachweise, die der Prüfer sehen will

Und AIC4?

Der AIC4 ist ein freiwilliger Kriterienkatalog des BSI für KI-Cloud-Dienste, als Erweiterung des C5 konzipiert und mit dem C5 als Voraussetzung; er liegt nur auf Englisch vor und stammt von 2021. § 393 SGB V verlangt ein C5-Testat für die Basiskriterien oder einen Nachweis nach der C5-Gleichwertigkeitsverordnung, keinen AIC4-Bericht. Den Entwurf des BSI für die Prüfung von KI-Systemen beschreibt die Seite BSI A5.

Was gesondert zu klären ist

Ein C5-Testat beantwortet Fragen der Informationssicherheit. Ob die Software ein Medizinprodukt ist, ob sie unter die europäische KI-Verordnung fällt und welche datenschutzrechtlichen Anforderungen gelten, beantwortet es nicht. Auch das BSI beschreibt C5 nicht als Datenschutzstandard. Diese Fragen sind gesondert und im Einzelfall rechtlich zu prüfen.