KI im GxP-Umfeld: Worauf müssen Sie achten?

KI im GxP-Umfeld: Worauf müssen Sie achten?

Unternehmen prüfen zunehmend den Einsatz von KI-Systemen in GxP-relevanten Prozessen. Die eigentliche Herausforderung liegt jedoch nicht in der Technologie, sondern in ihrer kontrollierten Einführung. Für Unternehmen aus Pharma, MedTech, Biotech oder anderen regulierten Industrien stellt sich deshalb zunehmend die Frage, unter welchen Rahmenbedingungen ein KI-Einsatz GxP-konform erfolgen kann.

Viele Unternehmen betrachten KI zunächst als weiteres Softwaresystem. In der Praxis zeigt sich jedoch schnell: Die regulatorischen Anforderungen an die CSV gemäß Annex 11 und den relevanten GMP-Regelwerken wie GAMP 5 bleiben bestehen. 

Der Rahmen zur risikobasierten Umsetzung der CSV-Anforderungen ist da. KI-Systeme erweitern diese Anforderungen jedoch um zusätzliche Fragestellungen, beispielsweise Trainingsdatenqualität, Modell-Drift und Automation Bias. 

Inhaltsverzeichnis 

1. Warum KI im GxP-Umfeld anders bewertet werden muss
2. Beispiel aus der Praxis: KI im Abweichungsmanagement
3. Die wichtigste Entscheidung vor Projektstart: Make oder Buy?
4. KI als SaaS-Lösung beschaffen: Welche Fragen müssen geklärt werden?

1. • Lieferantenqualifizierung bei KI-Systemen
   • Datenübermittlung und Datenschutz
   • Change Control bei Modell-Updates
   • Grenzen von Vendor Validation Packages

5. KI selbst entwickeln: Welche zusätzlichen Anforderungen entstehen?

1. • QMS und Organisationsstruktur
   • Trainingsdaten als GxP-relevante Records
   • Validierungsstrategie für interne Modelle
   • Betrieb, Monitoring und Modell-Drift

6. Warum Human-in-the-Loop allein keine ausreichende Kontrolle ist

1. • Automation Bias als GxP-Risiko
   • Messbarkeit von menschlicher Oversight

7. Risikoanalyse für KI-Systeme im GxP-Umfeld

1. • Risiko: Fehlklassifikation kritischer Abweichungen
   • Risiko: Fehlerhafte oder inkonsistente Trainingsdaten
   • Risiko: Änderungen außerhalb der eigenen Kontrolle

8. Welche Restrisiken immer bleiben
9. Checkliste: Was vor dem Start eines KI-Projekts geklärt sein sollte

Fazit: Was ist bei KI neu und was bleibt klassisches CSV-Handwerk?

Warum KI im GxP-Umfeld anders bewertet werden muss

Viele Organisationen verfügen bereits über etablierte Prozesse für die Einführung und Validierung computergestützter Systeme.

Tatsächlich bleiben zahlreiche Grundprinzipien erhalten:

1. • Definition des ‚Intended Use‘
   • Risiken analysieren
   • Lieferanten bewerten
   • Änderungen kontrollieren
   • Systemleistung nachweisen

Ein KI-System liefert nicht zwangsläufig bei derselben Eingabe immer dieselbe Antwort. Seine Leistungsfähigkeit hängt maßgeblich von Trainingsdaten ab. Modelle können sich über die Zeit verändern und Nutzer neigen dazu, erfolgreichen KI-Vorschlägen zunehmend zu vertrauen.

CSV- und CSA-Prinzipien bleiben anwendbar. Neu ist die Frage, wie Trainingsdaten, Modellverhalten und Modelländerungen in diese bestehenden Frameworks integriert werden.

Beispiel aus der Praxis: KI im Abweichungsmanagement

Angenommen, ein Hersteller steriler Arzneimittel bearbeitet jährlich mehrere hundert Abweichungen im Qualitätsmanagementsystem. Die QA-Abteilung arbeitet unter hoher Belastung, Bearbeitungszeiten steigen und wiederkehrende Ursachen werden nicht systematisch erkannt.

Das Unternehmen prüft den Einsatz eines KI-Systems zur Unterstützung des Abweichungsmanagements.

Das System soll:

1. • Abweichungen als Minor, Major oder Critical klassifizieren
   • ähnliche historische Fälle identifizieren
   • Root-Cause-Hypothesen vorschlagen
   • CAPA-Maßnahmen empfehlen
   • einen ersten Berichtsentwurf erstellen

Die finale Entscheidung verbleibt beim QA-Mitarbeitenden.

Die wichtigste Entscheidung vor Projektstart: Make oder Buy?

Vor Projektstart muss entschieden werden, ob die Lösung eingekauft oder selbst entwickelt wird. Die Wahl zwischen einer externen Lösung und einer Eigenentwicklung beeinflusst unter anderem Lieferantenqualifizierung, Validierungsstrategie, Datenverantwortung und Betriebsmodell.

Beide Ansätze erfordern:

1. • Risikoanalysen
   • Validierung
   • Dokumentation
   • Governance-Strukturen
   • Betriebskonzepte

Verantwortlichkeiten für Entwicklung, Modellbetrieb, Updates und Leistungsüberwachung hingegen unterscheiden sich deutlich.

Während bei einer SaaS-Lösung große Teile der technischen Entwicklung außerhalb des Unternehmens stattfinden, müssen diese Aufgaben bei einer Eigenentwicklung intern übernommen werden.

Deshalb sollte die Make-or-Buy-Entscheidung möglichst früh und bewusst getroffen werden.

KI als SaaS-Lösung beschaffen: Welche Fragen müssen geklärt werden?

Lieferantenqualifizierung bei KI-Systemen

Der Softwareanbieter betreibt möglicherweise kein eigenes Modell, sondern nutzt die Dienste eines Hyperscalers oder eines Foundation-Model-Anbieters.

In der Praxis ist häufig nicht das KI-System selbst das größte Problem, sondern die begrenzte Transparenz der zugrundeliegenden Lieferkette und Infrastruktur. Welchen Teil dieser Lieferkette können Sie bewerten und auditieren?

1. • Woher stammen die Trainingsdaten und darf oder möchte der Anbieter diese Information überhaupt offenlegen?
   • Wie wird Modellqualität überwacht?
   • Wie werden Modelländerungen dokumentiert?
   • Wie wird nicht-deterministisches Verhalten getestet?
   • Wie werden Modellfehler untersucht und behandelt?

Bestehende Lieferantenqualifizierungsprozesse decken diese Fragestellungen häufig nicht ab. Insbesondere bei Foundation Models ist die vollständige Nachvollziehbarkeit der Trainingsdaten häufig nicht gegeben. Die entscheidende Frage ist daher häufig nicht, ob vollständige Transparenz erreicht werden kann, sondern ob die verbleibende Intransparenz für das Unternehmen und den konkreten Anwendungsfall akzeptabel ist.

Datenübermittlung und Datenschutz

Generative KI verarbeitet häufig Inhalte außerhalb der eigenen Systemlandschaft.

Vor Vertragsabschluss sollte deshalb geklärt werden:

1. • Werden Kundendaten zum Weitertraining verwendet?
   • Welche Unterauftragnehmer sind beteiligt?
   • Wo werden Prompts verarbeitet?
   • Wo werden Daten gespeichert?
   • Welche technischen und organisatorischen Schutzmaßnahmen bestehen?

Dabei reicht es nicht aus, ausschließlich auf Marketingaussagen oder Hosting-Standorte des Anbieters zu schauen. Maßgeblich ist, welche Systeme Zugriff auf die Daten erhalten und wie diese verarbeitet werden.

Change Control bei Modell-Updates

Viele SaaS-Anbieter aktualisieren ihre Plattform und die zugrunde liegenden Modelle regelmäßig. Gleichzeitig fordert das Qualitätsmanagement die Bewertung von Änderungen vor ihrer Nutzung im produktiven Umfeld.

Mögliche Maßnahmen sind:

1. • vertragliche Informationspflichten
   • dedizierte Testumgebungen
   • definierte Testfenster
   • eigene Regressionstest-Sets
   • risikobasierte Revalidierung

Dennoch ist insbesondere bei vorgeschalteten Foundation Models ein gewisser Kontrollverlust unvermeidbar.

Grenzen von Vendor Validation Packages

Viele Anbieter stellen umfangreiche Dokumentationspakete bereit. Sie ersetzen jedoch keine eigene Validierung.

Das Unternehmen selbst muss weiterhin nachweisen, dass:

1. • der Intended Use erfüllt wird,
   • die Lösung für den eigenen Prozess und Anwendungsfall (Context of Use) geeignet ist,
   • die Leistung mit den eigenen Daten ausreichend ist,
   • definierte Akzeptanzkriterien eingehalten werden.

Für den Hersteller steriler Arzneimittel aus dem Beispiel bedeutet dies beispielsweise die Prüfung des Systems anhand historischer Abweichungsfälle aus dem eigenen Qualitätsprozess.

KI selbst entwickeln: Welche zusätzlichen Anforderungen entstehen?

QMS und Organisationsstruktur

Eine Eigenentwicklung schafft Kontrolle, erzeugt aber zusätzliche Verantwortung:

1. • Wer qualifiziert interne Entwickler?
   • Wer verantwortet Modellversionen?
   • Wer erstellt KI-spezifische SOPs?
   • Wie wird Know-how langfristig gesichert?
   • Wer übernimmt den Betrieb nach Projektende?

Oft zeigt sich, dass vorhandene Entwicklungsprozesse Themen wie Finetuning, Trainingsdatenmanagement oder Retraining noch nicht abdecken. Das Qualitätsmanagementsystem muss daher häufig erweitert werden, bevor die eigentliche Entwicklung beginnt.

Trainingsdaten als GxP-relevante Records

Angenommen, der Arzneimittelhersteller aus dem Beispiel verwendet 4.000 historische Abweichungen aus zehn Jahren als Trainingsgrundlage.

Wichtige Fragen sind:

1. • Sind die Daten vollständig und korrekt?
   • Sind Klassifizierungen konsistent erfolgt?
   • Wurden dieselben Regeln angewendet?
   • Enthalten die Daten bekannte Fehlbewertungen?

Das Modell übernimmt nicht nur Wissen aus den Daten, es übernimmt auch deren Schwächen. Ein KI-System kann daher bestehende Fehlentwicklungen reproduzieren oder sogar verstärken. Trainingsdaten können daher abhängig vom Intended Use und der gewählten Validierungsstrategie Teil der regulatorisch relevanten Nachweisführung werden.

Validierungsstrategie für interne Modelle

Bei einer Eigenentwicklung entfällt die Möglichkeit, auf Lieferantennachweise zurückzugreifen. Die Validierungsstrategie muss vollständig selbst aufgebaut werden.

Typische Bestandteile sind:

1. • klar definierter Intended Use / Context of Use
   • unabhängige Testdatensätze
   • dokumentierte Ground Truth
   • statistische Akzeptanzkriterien
   • nachvollziehbare Testmethodik

Die Definition einer belastbaren Ground Truth ist eine zentrale Voraussetzung für die Modellvalidierung. Wenn mehrere Fachexperten denselben Fall unterschiedlich bewerten, entsteht eine grundlegende Frage: Wie lässt sich das Modell validieren, wenn der zugrunde liegende Fachprozess selbst nicht reproduzierbar ist? In solchen Fällen müssen Prozesse zur Expertenkalibrierung, Konsensbildung oder Mehrfachbewertung definiert werden.

Betrieb, Monitoring und Modell-Drift

Auch nach dem Go-live endet die Verantwortung nicht. Es muss geklärt werden:

1. • Wer überwacht die Modellgüte?
   • Wie wird Performance gemessen?
   • Wie werden Änderungen der Modellleistung erkannt, unabhängig davon, ob diese durch Drift, geänderte Daten oder Anbieter-Updates verursacht werden?
   • Wer entscheidet über Retraining?
   • Welche Schwellenwerte lösen Maßnahmen aus?

Wie jedes System benötigen auch KI-Modelle ein geregeltes und klar strukturiertes Monitoring während des Betriebs.

Warum Human-in-the-Loop nicht automatisch eine ausreichende Kontrolle ist

Automation Bias als GxP-Risiko

Häufig wird angenommen, dass Human-in-the-Loop allein eine ausreichende Risikokontrolle darstellt: Die KI macht Vorschläge, der Mensch entscheidet.

Wenn ein System über einen längeren Zeitraum überwiegend richtige Vorschläge liefert, sinkt erfahrungsgemäß die Aufmerksamkeit der Nutzer. Der Mensch wird schrittweise vom kritischen Prüfer zum Durchwinker. Dieses Phänomen wird als Automation Bias bezeichnet. Damit entsteht ein eigenes GxP-Risiko, das unabhängig von der technischen Modellqualität bewertet werden muss.

Messbarkeit von menschlicher Oversight

Eine Kontrolle ist nur wirksam, wenn ihre Wirksamkeit nachgewiesen werden kann.

Sinnvolle Überwachungsmechanismen können sein:

1. • Override-Rate
   • Blindstichproben ohne KI-Vorschlag
   • Vier-Augen-Prinzip bei kritischen Entscheidungen
   • Kalibrierungsreviews
   • risikobasierte Prüftiefen

Sinkt beispielsweise die Override-Rate langfristig gegen null, sollte dies nicht automatisch als Erfolg interpretiert werden. Sie kann ebenso auf eine unzureichende kritische Prüfung der KI-Ergebnisse hinweisen.

Risikoanalyse für KI-Systeme im GxP-Umfeld

Im nächsten Schritt müssen die mit dem KI-Einsatz verbundenen Risiken bewertet werden. Viele Risiken sind aus klassischen Computersystemen bekannt, treten bei KI-Systemen jedoch in veränderter Ausprägung oder mit zusätzlicher Komplexität auf.

Risiko: Fehlklassifikation kritischer Abweichungen

Im Abweichungsmanagement hätte eine falsche Einstufung direkte Auswirkungen auf Priorisierung, Eskalation und Bearbeitungszeiten. Für den Arzneimittelhersteller stellt sich daher die Frage, wie verhindert werden kann, dass kritische Fälle übersehen oder falsch kategorisiert werden.

Mögliche Kontrollen sind:

1. • Guardrails für kritische Signalwörter oder Ereignisse
   • risikobasierte Prüfprozesse
   • Vier-Augen-Prinzip bei kritischen Entscheidungen
   • definierte Akzeptanzkriterien innerhalb der Validierung

Risiko: Fehlerhafte oder inkonsistente Trainingsdaten

Besonders bei Eigenentwicklungen hängt die Qualität des Modells unmittelbar von der Qualität der Trainingsdaten ab.

Historische Abweichungen können fehlerhafte Klassifizierungen, unterschiedliche Bewertungsmaßstäbe oder etablierte Fehlpraktiken enthalten. Ohne entsprechende Qualitätsprüfung werden diese Muster Teil des Modells.

Wichtige Fragestellungen sind deshalb:

1. • Wie konsistent wurden historische Fälle bewertet?
   • Wer definiert die Ground Truth?
   • Welche Qualitätskriterien gelten für Trainingsdaten?

Risiko: Änderungen außerhalb der eigenen Kontrolle

Bei SaaS-Lösungen entstehen zusätzliche Risiken durch Änderungen beim Anbieter oder dessen Sub-Lieferanten.

Modell-Updates, neue Funktionen oder Änderungen der zugrundeliegenden Infrastruktur können Auswirkungen auf die Systemleistung haben, obwohl sie außerhalb des direkten Einflussbereichs des Betreibers stattfinden.

Typische Kontrollen umfassen:

1. • vertragliche Informationspflichten
   • eigene Regressionstests
   • Testumgebungen
   • dokumentierte Change-Bewertungen

Die Risikoanalyse dokumentiert und begründet, warum der geplante KI-Einsatz unter den definierten Rahmenbedingungen vertretbar ist.

Welche Restrisiken immer bleiben

Ein häufiger Fehler besteht darin, Restrisiken vollständig eliminieren zu wollen. Das ist weder realistisch noch regulatorisch gefordert. Entscheidend ist vielmehr die bewusste und dokumentierte Risikoentscheidung.

Typische Restrisiken sind:

Diese Restrisiken müssen bewertet, dokumentiert und von einer benannten verantwortlichen Person akzeptiert werden.

Checkliste: Was vor dem Start eines KI-Projekts geklärt sein sollte

1. • Intended Use / Context of Use definieren
   • Make- oder Buy-Strategie festlegen
   • Relevante Stakeholder einbinden (QA, CSV, IT, Legal, Datenschutz, Security)
   • Lieferantenstruktur verstehen
   • Datenflüsse analysieren
   • Trainingsdaten bewerten
   • Validierungsansatz festlegen
   • Change-Control-Konzept entwickeln
   • Oversight-Konzept definieren
   • Restrisiken dokumentieren und akzeptieren

Fazit: Was ist bei KI neu und was bleibt klassisches CSV-Handwerk?

CSV und CSA bleiben auch bei KI-Systemen die Grundlage für einen risikobasierten Validierungsansatz. Lieferantenbewertung, Intended Use, Risikoanalyse, Valdierungsdokumentation und Change Control bleiben unverändert zentrale Bestandteile jedes Validierungsprojekts im GxP-Umfeld.

Neue Anforderungen kommen hinzu:

1. • nicht-deterministisches Verhalten
   • Trainingsdaten als GxP-relevante Records
   • Modell-Drift über den Lebenszyklus
   • komplexe Lieferketten rund um Foundation Models
   • Automation Bias als Betriebsrisiko

Ob Make oder Buy: Validieren müssen Sie in beiden Fällen. Der Unterschied liegt im Aufwand, in den verfügbaren Nachweisen und in der Beherrschbarkeit der Risiken.

Wie können wir Ihnen helfen?

Es sind noch Fragen offen geblieben? Vereinbaren Sie jetzt einen kostenlosen und unverbindlichen Termin mit unseren Experten. Wir gehen individuell auf Ihre Bedürfnisse ein und führen Ihr nächstes Projekt gemeinsam zum Erfolg.