Warum KI/ML eine andere Validierung verlangt — innerhalb von GAMP 5
Klassische Software ist berechenbar: gleicher Input, gleicher Output — was einmal validiert ist, verhält sich morgen genauso. Ein KI-Modell gibt diese Garantie nicht. Es lernt aus Daten, antwortet probabilistisch, und sein Verhalten kann sich verschieben, sobald sich die Daten darunter ändern. Die Reproduzierbarkeit, auf die sich klassische Validierung stützt, ist bei Modellen nicht selbstverständlich — sie muss aktiv abgesichert werden.
Der Rahmen bleibt trotzdem GAMP 5: risikobasiert, Lifecycle-orientiert, Critical Thinking. Wie man ein KI/ML-System darin konkret validiert, ist der angewandte Pfad dieses Beitrags. (Was sich in der Second Edition allgemein geändert hat — Critical Thinking, agile Lifecycles, Cloud — steht im GAMP-5-Überblick.)
Seit Juli 2025 steht dafür zusätzlich der eigenständige ISPE GAMP Guide: Artificial Intelligence zur Verfügung. ISPE beschreibt ihn als Stand-alone-Guide, der parallel zu GAMP 5 Second Edition eingesetzt wird. Er ersetzt den bekannten Lifecycle nicht. Die folgenden Schritte wenden den CSV-Lifecycle auf KI an und ergänzen ihn um modell- und datenspezifische Aktivitäten.
Schritt 1: Intended Use präzise fassen und Risiko einstufen
Wie bei jeder CSV beginnt alles beim Intended Use — aber bei KI mit mehr Schärfe: Welche Aufgabe übernimmt das Modell, mit welchen Eingabedaten, mit welchen Grenzen, und welche Entscheidung hängt am Output?
Daraus folgt die Risiko-Einstufung. Je direkter ein Modell-Output eine GxP-Entscheidung trägt (Freigabe, Spezifikation, Bewertung), desto strenger die Anforderungen an Test, Erklärbarkeit und Aufsicht. Ein unterstützendes Modell (Strukturierung, Recherche-Hilfe) trägt weniger Risiko als eines, das in eine Qualitätsentscheidung einfließt. Diese Einstufung — bewusst und begründet, nicht schematisch — ist die Critical-Thinking-Grundlage, auf der alle weiteren Schritte ihren Aufwand bemessen.
Welche Nachweise braucht die Validierung eines KI-/ML-Systems?
Ein belastbares Nachweispaket verbindet den freigegebenen Systemstand mit der Frage, ob das Modell für seinen Intended Use geeignet bleibt. Die Tiefe wird risikobasiert skaliert; die folgende Matrix ist ein Prüfrahmen, keine universelle Pflichtliste.
| Nachweis | Dokumentierter Kern | Prüffrage |
|---|---|---|
| Intended Use & Scope | Aufgabe, Nutzer, Systemgrenze, Output und Entscheidungswirkung | Ist klar, wofür das Modell eingesetzt wird — und wofür nicht? |
| Risikobewertung | Einfluss auf Patientensicherheit, Produktqualität und Datenintegrität | Leiten sich Kontrollen und Testtiefe aus dem Risiko ab? |
| Daten | Herkunft, Eignung, Lineage und unabhängige Testdaten | Ist die Leistungsprüfung frei von Trainings- und Tuning-Einflüssen? |
| Leistung | Metriken, Akzeptanzgrenzen, Tests und Abweichungen | Ist vorab definiert, was Bestehen, Stop oder Eskalation bedeutet? |
| Systemstand | Modell-, Software- und Konfigurationsversion samt Provenienz | Lässt sich der freigegebene Zustand eindeutig reproduzieren? |
| Human Oversight | Rolle, Prüftiefe, Entscheidung und Begründung | Bleibt die fachliche Entscheidung einer benannten Fachrolle zugeordnet? |
| Betrieb & Change | Monitoring, Drift, Change Trigger, Abweichungs- und Eskalationsweg | Wird eine relevante Veränderung erkannt und kontrolliert bewertet? |
| Lieferant | Verantwortungen, Änderungsinformationen und verfügbare Evidenz | Kann das Unternehmen seine Bewertung trotz externer Komponenten tragen? |
Schritt 2: Datenqualität und unabhängige Testdaten
Der größte Unterschied zur klassischen CSV liegt in den Daten. Trainings-, Validierungs- und Testdaten müssen kontrolliert, repräsentativ und nachvollziehbar verwaltet sein — Qualität und Herkunft sind selbst validierungsrelevant.
Im Zentrum stehen unabhängige Testdaten mit drei Regeln:
- Strikter Daten-Split: Der Datenpool wird nachweisbar in getrennte Sätze für Training, Validierung (Tuning während der Entwicklung) und Test aufgeteilt.
- Vollständiger Ausschluss: Der finale Testdatensatz muss eine unvoreingenommene, unabhängige Prüfung sein — er darf zu keinem Zeitpunkt im Training oder im Hyperparameter-Tuning verwendet worden sein.
- Kein Data Leakage: Ein Testdatensatz wird für spätere Modell-Iterationen nicht wiederverwendet — sonst entsteht Verzerrung (data leakage). Ein Abweichen verlangt eine starke, risikobasierte Begründung.
Übersetzt: Die Leistungsbewertung ist nur dann ein Nachweis, wenn das Modell auf Daten geprüft wurde, die es nie gesehen hat.
Bei klassischer Software testet man das Programm. Bei KI testet man auch die Daten — und ihre saubere Trennung.
Schritt 3: Modell-Lebenszyklus statt Stichtags-Validierung
Klassische CSV denkt oft in einem Ereignis: validiert, freigegeben, fertig. Bei Modellen trägt das nicht. GAMP 5 erkennt agile und iterative Entwicklung ausdrücklich an — sofern die Kontrollen erhalten bleiben (Rückverfolgbarkeit Anforderung→Test, bewertete Risiken, kontrollierte Änderungen).
Für kritische Anwendungen heißt das in der Praxis: Das Modell wird trainiert, eingefroren, getestet und in einem definierten, nachweisbaren Zustand betrieben. Jedes Re-Training oder Modell-Update ist eine Änderung mit Change Control und Bewertung des Änderungsrisikos — kein stilles Weiterlernen im Betrieb. So bleibt der validierte Zustand jederzeit belegbar.
Schritt 4: Monitoring, Drift und menschliche Aufsicht
Weil sich reale Bedingungen ändern, verlangt die Betriebsphase eine kontinuierliche Überwachung der Modellmetriken — Stichwort Drift: Wenn die Eingangsdaten von der Trainingsverteilung abweichen, kann die Leistung leise sinken. Definierte Metriken, Schwellen und ein Eskalationspfad gehören deshalb in den Betriebsplan, nicht in eine Nachdokumentation.
Zentral bleibt die menschliche Aufsicht. Bei jedem GxP-relevanten Modell-Output bleibt die fachliche Prüfung und namentliche Freigabe Pflicht — die KI bereitet vor, der Mensch entscheidet. Quellenbindung, markiertes Unbelegtes und nachvollziehbare menschliche Prüfung sind auch das, worauf die Kontroll-Architektur von traqx aufsetzt — Ground, Generate, Verify, Human Review, kein Konformitätsversprechen.
Guardrails statt Vertrauen
Belastbar wird KI-Arbeit durch technische Guardrails: Quellenbindung des Outputs und automatisierte Inhaltsprüfungen, die Unbelegtes markieren — kombiniert mit einer dokumentierten menschlichen Freigabe.
Schritt 5: Modell- und Daten-Provenienz absichern
Ein Punkt, der klassische CSV nicht kennt, aber für KI zentral ist: die Provenienz — die nachvollziehbare Herkunft von Daten und Modell.
- Daten-Provenienz: Lückenlose Erfassung der Datenherkunft (data lineage), der Rechtevereinbarungen sowie der Curation- und Anonymisierungsschritte.
- Modell-Inventar & Traceability: Ein Modell-Inventar verknüpft die Version des Modell-Artefakts mit den exakten Trainingsparametern, dem genutzten Trainingscode und den zugrundeliegenden Trainingsdaten.
- Erweiterte Lieferantenbewertung: Liefert ein externer Anbieter das Modell, muss er GxP-Verständnis zeigen und auf KI-spezifische Qualitätsfähigkeiten geprüft werden — Modell-Integritätsschutz, Bias-Mitigation und Absicherung gegen Angriffe wie Data Poisoning.
Provenienz ist die KI-Übersetzung eines alten GxP-Prinzips — dieselbe Beweisdisziplin, die auch hinter ALCOA+ und Datenintegrität steht: Behaupte nichts, was du nicht zurückverfolgen kannst.
Die ehrlichen Grenzen
Drei Klarstellungen:
- GAMP 5 ist ein Leitfaden, kein Gesetz. Die bindenden Anforderungen sind GMP, EU-Annex 11 und 21 CFR Part 11 — GAMP 5 ist ein etablierter Branchenleitfaden, um ihre Erfüllung risikobasiert zu begründen.
- Generative KI ist ein Sonderfall. Für kritische Anwendungen erwarten Regulatoren beherrschbares, nachweisbares Modellverhalten; generative/probabilistische Systeme brauchen dort besondere Vorsicht und menschliche Prüfung (mehr dazu im Annex-22-Überblick und in Annex 22 vs. Annex 11).
- Dies ist Orientierung, keine Beratung. Maßgeblich sind die Originaldokumente und Ihre im Kontext validierte, mit Ihrer QA abgestimmte Bewertung.
Keine Konformitätszusage
Kein Werkzeug und kein Modell ist von sich aus GAMP-5-konform. Konformität stellt immer Ihr validiertes Verfahren in Ihrem Kontext her. GAMP 5 ist ein Leitfaden; bindend bleiben GMP, EU-Annex 11 und 21 CFR Part 11.
Häufige Fragen
Fällt KI/ML-Software unter GAMP 5?
Ja. KI/ML-Systeme werden im selben risikobasierten GAMP-5-Lifecycle validiert wie klassische Software — nur mit zusätzlichen Aktivitäten, die ein einmaliger Validierungslauf nicht abdeckt: unabhängige Testdaten, Drift-Monitoring, Modell-Provenienz und durchgängige menschliche Aufsicht. GAMP 5 Second Edition bleibt das Lifecycle-Fundament; der eigenständige GAMP AI Guide konkretisiert die KI-spezifischen Aktivitäten.
Wie validiert man ein KI-Modell nach GAMP 5?
In fünf Schritten: Intended Use präzise fassen und Risiko einstufen; Datenqualität sichern mit striktem Train/Validation/Test-Split und unabhängigen Testdaten; einen Modell-Lebenszyklus statt Stichtags-Test führen; im Betrieb auf Drift überwachen mit dokumentierter menschlicher Freigabe; Modell- und Daten-Provenienz absichern (Modell-Inventar, Data Lineage, Lieferantenbewertung).
Welche Nachweise braucht die Validierung eines KI-/ML-Systems?
Das risikobasierte Nachweispaket verbindet Intended Use und Scope, Risikobewertung, Datenherkunft und unabhängige Testdaten, Leistungsmetriken und Akzeptanzkriterien, Modell- und Konfigurationsstand, Human Oversight, Monitoring und Change Control, Abweichungs- und Eskalationsweg sowie Lieferantenbewertung. Die Tiefe hängt vom konkreten Einsatz und Risiko ab.
Wie verhalten sich GAMP 5 Second Edition und der GAMP AI Guide zueinander?
Der ISPE GAMP Guide: Artificial Intelligence ist seit Juli 2025 ein eigenständiger Leitfaden für KI-gestützte computergestützte Systeme. Laut ISPE wird er parallel zu GAMP 5 Second Edition eingesetzt: GAMP 5 bleibt das risikobasierte Lifecycle-Fundament, der AI Guide konkretisiert KI-spezifische Aktivitäten und Verantwortungen.
Muss ein KI-Modell nach jedem Re-Training neu bewertet werden?
Für kritische Anwendungen ja. Das Modell wird trainiert, eingefroren, getestet und in einem definierten Zustand betrieben. Jedes Re-Training oder Modell-Update ist eine Änderung mit Change Control und Bewertung des Änderungsrisikos — kein stilles Weiterlernen im Betrieb.
Was ist bei der KI-Validierung anders als bei klassischer Software?
Klassische Software ist reproduzierbar: gleicher Input, gleicher Output. Ein KI-Modell antwortet probabilistisch und kann sich verschieben, sobald sich die Daten darunter ändern. Deshalb kommen drei Dinge hinzu, die klassische CSV nicht kennt: die Daten selbst werden validierungsrelevant, der Betrieb braucht Drift-Monitoring, und die Herkunft von Daten und Modell (Provenienz) muss nachvollziehbar sein.