KI und GxP: Wie AI-gestützte Entwicklung kontrollierbar bleibt

„Dürfen wir im GxP-Umfeld KI einsetzen?“ ist so gestellt nicht beantwortbar – etwa so wie „Dürfen wir Software einsetzen?“. Entscheidend ist, wo das Modell wirkt: beim Bauen des Systems oder im laufenden System. Die beiden Fälle haben fast nichts gemeinsam.

1. Zwei Fälle, zwei Antworten

Die Vermischung dieser beiden Fälle ist der Grund, warum Diskussionen über „KI und GxP“ oft in Grundsatzdebatten enden. Getrennt betrachtet sind beide Fälle handhabbar – der erste sogar mit überschaubarem Aufwand.

2. Fall 1: KI als Entwicklungswerkzeug

Ein Coding Agent erzeugt Code oder Konfiguration; ausgeliefert und validiert wird das Ergebnis. Aus regulatorischer Sicht ist das zunächst unspektakulär: Regelwerke fordern beherrschte Prozesse, definierte Verantwortung und belastbare Nachweise – nicht eine bestimmte Art, Code zu erzeugen.

Der Vergleich hilft: Ein Compiler, ein Code-Generator oder eine Bibliothek werden auch nicht einzeln validiert. Bewertet wird, was sie erzeugen, und ob der Prozess drumherum geeignet ist, Fehler zu entdecken.

3. Was dafür zu regeln ist

Vier Punkte genügen in den meisten Organisationen und lassen sich als Ergänzung bestehender SOPs formulieren:

1. Zugelassene Werkzeuge und Betriebsmodell. Welche Dienste dürfen genutzt werden, in welcher Betriebsform?
2. Datenflüsse. Welche Inhalte dürfen hinein? GxP-relevante Daten, Patientendaten und Produktionsdaten sind hier die kritische Kategorie – in der Entwicklung werden sie ohnehin selten benötigt.
3. Prüfpflichten. Identisch zu handgeschriebenem Code, ergänzt um die Punkte, die bei generiertem Code häufiger auffallen: Berechtigungslogik, Fehlerpfade, neue Abhängigkeiten.
4. Dokumentation. Dass KI eingesetzt wurde, wer geprüft hat und woran geprüft wurde.

Eine ausführlichere Vorlage dafür beschreibt der Deep Dive AI Coding Governance.

4. Prüfpflichten und Nachweise

Die Prüfmittel bleiben dieselben – Review, Test, Traceability, Change Control. Was sich lohnt, ist eine leichte Verschiebung der Aufmerksamkeit:

• Testfälle aus der Anforderung ableiten, nicht aus dem generierten Code. Sonst bestätigt der Test das Verhalten statt die Anforderung.
• Berechtigungs- und Fehlerpfade explizit prüfen; sie sind die häufigste Lücke.
• Neue Abhängigkeiten gegen eine kuratierte Quelle prüfen.
• Umfang der Änderungssätze begrenzen, damit Review real stattfinden kann.
• Kennzeichnung wesentlichen KI-Einsatzes am Änderungssatz, um die Prüftiefe später bewerten zu können.

5. Fall 2: KI als Funktion im System

Sobald ein Modell zur Laufzeit Ergebnisse liefert, auf denen GxP-relevante Entscheidungen beruhen, entsteht eine grundsätzlich andere Fragestellung. Zu klären sind unter anderem:

• Intended Use des Modells – wofür genau wird es eingesetzt, und was ist ausdrücklich ausgeschlossen?
• Datenherkunft und Repräsentativität der Trainings- oder Referenzdaten,
• Modellversionierung – welche Version lief wann, und wie wird ein Wechsel bewertet?
• Leistungsgrenzen und Verhalten außerhalb des vorgesehenen Eingaberaums,
• menschliche Kontrolle – wer prüft Ergebnisse, und wie ist das dokumentiert?
• laufende Überwachung im Betrieb, nicht nur eine Prüfung bei Einführung.

Hinzu kommen mögliche Pflichten aus der KI-Verordnung, deren Anwendbarkeit vom konkreten Anwendungsfall abhängt und im Einzelfall zu prüfen ist. Dieser Fall gehört gesondert bewertet und ist nicht Gegenstand dieses Artikels.

6. Determinismus und Modellversionen

Häufiges Missverständnis: „KI ist nicht deterministisch, also nicht validierbar.“ Das gilt für Fall 2 als ernstzunehmende Herausforderung – für Fall 1 gar nicht. Im Werkzeugfall muss nicht der Generierungsvorgang reproduzierbar sein, sondern das Artefakt. Aus demselben Quellstand entsteht derselbe Build, unabhängig davon, wie der Quelltext entstanden ist.

Praktisch heißt das: Reproduzierbare Builds, festgeschriebene Abhängigkeiten und versionierte Konfiguration sind auch im KI-Zeitalter die Grundlage – und sie sind ohnehin gute Praxis.

7. Grauzonen und offene Fragen

• KI in der Testerstellung. Zulässig, aber: Wenn Test und Implementierung aus demselben Kontext stammen, sinkt die Aussagekraft. Für risikoreiche Funktionen sollten Testfälle unabhängig entstehen.
• KI in der Dokumentation. Unkritisch bei Entwürfen, kritisch bei Nachweisdokumenten – dort trägt eine Person die Verantwortung für den Inhalt.
• KI in der Datenauswertung. Sobald Ergebnisse in GxP-Entscheidungen einfließen, ist man in Fall 2, auch wenn das Werkzeug „nur“ unterstützt.
• Assistenzfunktionen in Fremdsystemen. Werkzeuge aktivieren KI-Funktionen teils ohne Zutun; das gehört in die Lieferantenbewertung und in die periodische Überprüfung.

Typische Fehler

• Beide Fälle in einer Richtlinie vermengen – das Ergebnis ist entweder zu streng oder zu lasch.
• Pauschales Verbot, das die Nutzung nur aus der Dokumentation entfernt.
• Sonderprozess für KI-Code, der die regulären Prüfungen ersetzt statt sie zu nutzen.
• Produktionsdaten als Testdaten in externe Werkzeuge geben.
• Anbieteraussagen zur Compliance übernehmen, ohne sie auf den eigenen Verwendungszweck zu beziehen.

Checkliste: KI im GxP-Umfeld

Fazit

KI im GxP-Umfeld ist kein Sonderfall, solange sie ein Entwicklungswerkzeug bleibt. Dann genügen eine knappe Ergänzung der bestehenden Regeln und eine leichte Verschiebung des Prüffokus. Der Aufwand liegt bei wenigen Seiten Regelung, nicht bei einem neuen Qualitätssystem.

Anspruchsvoll wird es erst, wenn ein Modell im laufenden System Entscheidungen beeinflusst. Diese Grenze sauber zu ziehen – und sie schriftlich zu haben – ist die wichtigste einzelne Maßnahme.