Regulatory Update 12.07.2026 · 16:24 Uhr 8 Min Lesezeit von Daniel Herrmann

Annex 22 und KI-Validierung: Was der GMP-Entwurf für Ihre Systeme verlangt

Was der Annex-22-Entwurf für KI-Validierung bedeutet: Scope, Testdaten, Akzeptanzkriterien, Explainability und Monitoring.

Der Entwurf zu EU GMP Annex 22 beschreibt zusätzliche Erwartungen für statische, deterministische KI/ML-Modelle in kritischen GMP-Anwendungen. Im Zentrum stehen präziser Intended Use, repräsentative und unabhängige Testdaten, vorab definierte Leistungskennzahlen, Explainability, Change Control und laufendes Monitoring. Annex 22 ist derzeit ein Konsultationsentwurf und noch kein final in Kraft gesetzter GMP-Anhang.

Zuerst den Status richtig einordnen

Die Europäische Kommission eröffnete am 7. Juli 2025 eine gemeinsame Konsultation zur Überarbeitung von EU GMP Kapitel 4 und Annex 11 sowie zum neuen Annex 22 „Artificial Intelligence“. Die Konsultation endete am 7. Oktober 2025. Auf der offiziellen EudraLex-Seite ist weiterhin Annex 11 in der Revision von Januar 2011 als gültiger Anhang aufgeführt; ein finaler Annex 22 ist dort mit Stand 12. Juli 2026 nicht veröffentlicht.

Für Unternehmen folgen daraus zwei Regeln. Erstens darf der Entwurf nicht als bereits geltendes Recht dargestellt werden. Zweitens ist es wirtschaftlich unklug, ein kritisches KI-System zu bauen, dessen Daten-, Test- und Betriebsmodell die erkennbare regulatorische Richtung ignoriert.

Der Entwurf ist deshalb ein Planungs- und Gap-Assessment-Input. Die verbindliche Grundlage bleibt das jeweils anwendbare Regelwerk, insbesondere bestehende GMP-Anforderungen, Annex 11 und das pharmazeutische Qualitätssystem.

In der Umsetzung verbindet DHC die CSV-Beratung mit der GxP-Systemvalidierung, damit KI-spezifische Modell- und Datennachweise in einen kontrollierten Systemlebenszyklus eingebettet werden.

Welche KI-Systeme der Entwurf abdeckt

Annex 22 setzt mehrere Filter gleichzeitig. Der Entwurf adressiert Computersysteme in der Herstellung von Arzneimitteln und Wirkstoffen, wenn ein KI-Modell in einer kritischen Anwendung direkten Einfluss auf Patientensicherheit, Produktqualität oder Datenintegrität hat – beispielsweise für Vorhersage oder Klassifikation.

Erfasst werden nach dem Entwurf Modelle, die ihre Funktion durch Training mit Daten erhalten haben und:

statisch sind, sich während des Betriebs also nicht kontinuierlich selbst anpassen;
deterministisch arbeiten, bei identischen Eingaben also identische Ausgaben liefern;
in eine GMP-relevante Computeranwendung eingebettet sind;
einen klar beschriebenen Intended Use besitzen.

Der Entwurf deckt dynamisch weiterlernende und probabilistische Modelle nicht ab und sagt, dass solche Modelle nicht in kritischen GMP-Anwendungen eingesetzt werden sollten. Generative AI und Large Language Models fallen nach derselben Logik nicht in den Scope und sollten laut Entwurf ebenfalls nicht in kritischen GMP-Anwendungen eingesetzt werden.

Für nicht kritische GMP-Anwendungen lässt der Text eine andere Einordnung erkennen: Qualifiziertes Personal soll die Eignung der Ausgaben für den Intended Use sicherstellen. Dieses Human-in-the-loop-Prinzip macht aus einem unkontrollierten LLM aber noch kein validiertes kritisches System.

Der Scope-Check vor jedem Validierungsprojekt

Bevor ein Team Testfälle schreibt, sollte es sechs Fragen beantworten:

1. Unterstützt das System tatsächlich Herstellung von Arzneimitteln oder Wirkstoffen?

2. Ist die konkrete KI-Funktion kritisch für Patientensicherheit, Produktqualität oder Datenintegrität?

3. Wird die Funktion durch ein trainiertes Modell erbracht oder durch explizit programmierte Logik?

4. Bleibt das freigegebene Modell im Betrieb statisch?

5. Ist der Output bei identischer Eingabe reproduzierbar?

6. Unterstützt die KI einen Menschen oder automatisiert sie eine Entscheidung?

Diese Fragen trennen drei verschiedene Arbeitsstränge: ein Annex-22-orientiertes kritisches KI/ML-System, eine nicht kritische Anwendung mit menschlicher Prüfung oder ein System außerhalb des beschriebenen Annex-22-Scopes. Alle drei können kontrollbedürftig sein, aber nicht mit derselben Begründung.

Arbeitspaket 1: Intended Use und Input Sample Space

Der Entwurf verlangt eine detaillierte Beschreibung der Aufgabe und des Prozesses, in den das Modell eingebettet ist. Dazu gehört eine umfassende Charakterisierung der Eingabedaten einschließlich häufiger und seltener Variationen, Grenzen sowie möglicher fehlerhafter oder verzerrter Inputs.

Ein Satz wie „Das Modell erkennt Defekte“ ist zu grob. Ein belastbarer Intended Use beschreibt zum Beispiel:

Produkt, Material, Linie, Kamera- oder Sensorkonfiguration;
relevante Defektklassen und Entscheidungsausgänge;
zulässige Betriebs- und Umgebungsbedingungen;
bekannte Ausschlüsse und Eskalationsfälle;
Verantwortlichkeit des menschlichen Operators;
nachgelagerte Entscheidung und mögliche Auswirkung eines Fehlers.

Ein Process SME soll nach dem Entwurf die Angemessenheit dieser Beschreibung verantworten. Sie wird vor Beginn der Akzeptanztests dokumentiert und genehmigt.

Arbeitspaket 2: Metriken und Akzeptanzkriterien

Die Leistung eines KI-Modells lässt sich nicht sinnvoll mit einem allgemeinen „Test bestanden“ bewerten. Annex 22 nennt als mögliche Kennzahlen für Klassifikationsmodelle unter anderem Confusion Matrix, Sensitivität, Spezifität, Accuracy, Precision und F1 Score.

Die passende Auswahl hängt vom Intended Use ab. Bei einer Defekterkennung kann ein falsch akzeptiertes Produkt eine andere Bedeutung haben als eine unnötige Ausschleusung. Deshalb müssen Kriterien für relevante Untergruppen getrennt betrachtet werden.

Wichtig ist die Reihenfolge: Metriken und Akzeptanzkriterien werden vor der Testausführung festgelegt. Der Entwurf fordert außerdem, dass die Akzeptanzkriterien mindestens so hoch sind wie die Leistung des ersetzten Prozesses. Wer die Baseline des manuellen oder bisherigen technischen Prozesses nicht kennt, kann diese Anforderung nicht nachvollziehbar bewerten.

Arbeitspaket 3: Repräsentative Testdaten

Nach dem Entwurf müssen Testdaten den vollständigen vorgesehenen Eingaberaum abbilden – einschließlich relevanter Untergruppen, Grenzen, Komplexität sowie häufiger und seltener Varianten. Die Auswahl und ihre Begründung werden dokumentiert. Der Datensatz muss nach dem Entwurf groß genug sein, um die gewählten Metriken mit angemessener statistischer Sicherheit zu berechnen.

Auch die Labels sind Teil des Nachweises. Der Entwurf verlangt einen Prozess mit sehr hoher Korrektheit, beispielsweise durch unabhängige Experten, validierte Geräte oder Labortests. Datenbereinigung, Ausschlüsse und Vorverarbeitung werden vorab spezifiziert beziehungsweise vollständig begründet.

Für die KI-Systemvalidierung im GxP-Umfeld bedeutet das: Datenqualität ist kein vorgelagertes Data-Science-Thema. Sie ist Bestandteil des Validierungsobjekts.

Arbeitspaket 4: Unabhängigkeit der Testdaten

Ein Modell darf nicht mit den Daten geprüft werden, die seine Entwicklung bereits beeinflusst haben. Der Entwurf beschreibt technische und verfahrensmäßige Kontrollen, die Testdaten von Entwicklung, Training und Validierung trennen.

Wenn ein Testdatensatz vor Trainingsbeginn aus einem Gesamtbestand abgespalten wird, sollen Entwickler keinen Zugriff darauf haben. Zugriffskontrolle und Audit Trail schützen das Repository; externe Kopien sollen vermieden werden. Zusätzlich wird dokumentiert, welche Daten wann und wie oft für Tests verwendet wurden.

Diese Anforderung verhindert nicht nur versehentliches Data Leakage. Sie macht die Generalisierungsleistung des Modells prüfbar.

Arbeitspaket 5: Testplan, Ausführung und Abweichungen

Nach dem Entwurf wird vor Testbeginn ein genehmigter Plan benötigt. Er verbindet Intended Use, Metriken, Akzeptanzkriterien, Testdatenreferenz, Testschritte und Berechnungsmethode. Ein Process SME wirkt an der Planung mit.

Abweichungen vom Plan, verfehlte Kriterien oder nicht verwendete Testdaten werden dokumentiert, untersucht und begründet. Zur Testdokumentation gehören nach dem Entwurf auch Intended Use, Datencharakterisierung, tatsächliche Testdaten sowie Nachweise zu Zugriffskontrolle und Audit Trail.

Das ist klassische Validierungsdisziplin mit zusätzlichen modell- und datenbezogenen Nachweisen. Ein Data-Science-Notebook allein deckt diesen kontrollierten Entscheidungspfad normalerweise nicht vollständig ab.

Arbeitspaket 6: Explainability und Confidence

Für kritische Modelle soll das System während der Tests Merkmale erfassen, die zu einer Klassifikation oder Entscheidung beigetragen haben. Als Beispiele nennt der Entwurf Feature-Attribution-Verfahren wie SHAP oder LIME sowie Heatmaps. Die relevanten Merkmale werden bei der Genehmigung der Testergebnisse daraufhin geprüft, ob das Modell auf sachgerechten Faktoren entscheidet.

Wo anwendbar, soll zudem der Confidence Score je Vorhersage oder Klassifikation protokolliert werden. Geeignete Schwellen können einen „unentschieden“-Ausgang auslösen, statt eine potenziell unzuverlässige Entscheidung zu erzwingen.

Explainability ist hier kein allgemeines Versprechen, das Modell vollständig verständlich zu machen. Sie ist ein konkreter Test- und Review-Nachweis für die Faktoren, die den Output im vorgesehenen Prozess beeinflussen.

Arbeitspaket 7: Change Control, Konfiguration und Monitoring

Nach dem Entwurf kommen Modell, Computersystem und unterstützter Prozess vor dem produktiven Einsatz unter Change Control. Änderungen an Modell, System, Prozess oder physischen Eingaben werden daraufhin bewertet, ob ein Retest erforderlich ist. Eine Entscheidung gegen erneutes Testen muss begründet werden.

Der Entwurf verlangt außerdem Konfigurationskontrolle und Maßnahmen gegen unautorisierte Änderungen. Im Betrieb werden Modellleistung und Eingaberaum überwacht, um Performance-Veränderungen oder Drift der Eingangsdaten zu erkennen.

Das Betriebsmodell braucht daher definierte Trigger:

Performance fällt unter Warn- oder Akzeptanzschwelle;
Inputs verlassen den freigegebenen Sample Space;
Kamera, Sensor, Linie, Produkt oder Vorverarbeitung ändern sich;
Modell- oder Softwareversion wird aktualisiert;
Häufigkeit menschlicher Overrides oder „unentschieden“-Fälle steigt.

Ohne solche Trigger bleibt die Validierung eine Momentaufnahme.

Was Unternehmen jetzt sinnvoll vorbereiten können

Auch vor einer finalen Annex-22-Veröffentlichung sind reversible, regelwerksneutrale Schritte möglich:

1. KI-Anwendungen einschließlich eingebetteter Lieferantenfunktionen inventarisieren.

2. Intended Use, GMP-Bezug, Kritikalität und Modelltyp klassifizieren.

3. Für kritische Kandidaten Datenherkunft, Sample Space und Baseline-Prozess dokumentieren.

4. Verantwortlichkeiten zwischen Process SME, QA, IT, Data Science und Lieferant klären.

5. Testdatenunabhängigkeit, Metriken, Akzeptanzkriterien und Monitoring als Pilotnachweis aufbauen.

6. Delta zwischen bestehender GAMP-5-Compliance und den modellbezogenen Erwartungen dokumentieren.

Das Ergebnis ist kein pauschales „Annex-22-Zertifikat“. Es ist ein belastbarer Readiness-Stand, der bei einer finalen Fassung gezielt angepasst werden kann.

Auch KI-Anwendungen außerhalb des Annex-22-Entwurfsscope benötigen eine Einordnung gegen das jeweils anwendbare GxP-Regelwerk. Das DHC-Assessment klärt deshalb ebenso bei nicht kritischen generativen Anwendungen sowie in GCP-, GLP- oder GDP-Kontexten, welche Systemgrenze, menschliche Kontrolle, Daten- und Schnittstellennachweise, Tests und Monitoring für den konkreten Intended Use angemessen sind.

Häufige Fragen

Ist Annex 22 bereits verbindlich?

Nein. Mit Stand 12. Juli 2026 ist Annex 22 ein Konsultationsentwurf. Die Konsultation ist geschlossen, aber EudraLex Volume 4 führt noch keinen finalen Annex 22.

Dürfen LLMs laut Entwurf in GMP-Prozessen eingesetzt werden?

Der Entwurf sagt, dass Generative AI und LLMs nicht in kritischen GMP-Anwendungen eingesetzt werden sollten. Für nicht kritische Anwendungen sieht er qualifiziertes Personal vor, das die Eignung der Ausgaben für den Intended Use sicherstellt. Die konkrete Anwendung benötigt dennoch eine eigene GxP- und Risikobewertung.

Ersetzt Annex 22 eine CSV nach Annex 11 oder GAMP 5?

Nein. Der Entwurf ergänzt Annex 11 für Computersysteme mit eingebetteten KI-Modellen. Bestehende Lebenszyklus-, Qualitätsrisiko-, Datenintegritäts- und Computersystemkontrollen bleiben relevant und werden um modellspezifische Nachweise ergänzt.

Primärquellen

Autor

Daniel Herrmann Consulting unterstützt Pharma- und MedTech-Organisationen bei der Einordnung, Implementierung und Validierung von KI-Systemen im GxP-Umfeld – mit klarer Scope-Grenze zwischen geltendem Regelwerk und regulatorischem Entwurf.

Sie planen einen KI-Use-Case mit Einfluss auf Produktqualität, Datenintegrität oder Patientensicherheit?

Im KI-Validierungsassessment klären wir Scope, Nachweislücken und einen kontrollierten Pilotpfad.

KI-Validierungsassessment besprechen