Annex 22 Praxisleitfaden: QA, Process SME, IT-Validation

Annex-22-Readiness bedeutet hier: Ein Pharma-Unternehmen bereitet KI/ML-Modelle in GMP-Prozessen so vor, dass intended use, Akzeptanzkriterien, Testdaten, Testdurchführung, Explainability, Confidence und Betriebskontrolle nachvollziehbar dokumentiert sind. Der Beitrag bezieht sich auf den EU-Kommissions-Konsultationsentwurf vom 7. Juli 2025. Die finale Fassung kann Begriffe, Detailtiefe und Übergangslogik noch verändern.

Der Entwurf gilt für computergestützte Systeme in der Herstellung von Arzneimitteln und Wirkstoffen, wenn KI/ML-Modelle in kritischen Anwendungen mit direkter Wirkung auf Patientensicherheit, Produktqualität oder Datenintegrität eingesetzt werden. Er ergänzt Annex 11. Er ersetzt weder Annex 11 noch allgemeine GMP-Anforderungen an Validierung, Datenintegrität, Zugriffsschutz, Audit Trails, Lieferantensteuerung und Change Control.

Scope zuerst

Die erste Aufgabe ist keine Rollenmatrix, sondern Scope-Klärung. Annex 22 adressiert Modelle, die ihre Funktion durch Training mit Daten erhalten haben. Der Entwurf betrifft statische Modelle, die im Betrieb nicht automatisch weiterlernen, und deterministische Outputs, bei denen identische Eingaben identische Ausgaben erzeugen.

Dynamische Modelle, die während der Nutzung weiterlernen, sind nicht abgedeckt und sollen in kritischen GMP-Anwendungen nicht eingesetzt werden. Modelle mit probabilistischem Output sind ebenfalls nicht abgedeckt, wenn identische Eingaben zu unterschiedlichen Ausgaben führen können. Generative KI und Large Language Models fallen nicht in den kritischen Annex-22-Scope und sollen in kritischen GMP-Anwendungen nicht genutzt werden.

Für nicht-kritische GMP-Anwendungen erlaubt der Entwurf mehr Spielraum, setzt aber menschliche Verantwortung voraus. Wenn ein LLM beispielsweise einen Entwurf für ein nicht freigaberelevantes Dokument erzeugt, muss eine qualifizierte Person den Output auf Eignung für den intended use prüfen. Human-in-the-loop ist damit eine echte Prozesskontrolle, keine nachträgliche Formalie. Für die interne Priorisierung der Use Cases vor dieser Scope-Prüfung bietet sich das Drei-Zonen-Modell als Heuristik an.

Rollen im Überblick

Der Annex-22-Entwurf nennt keine starre Unternehmensorganisation. Er verlangt aber enge Zusammenarbeit zwischen Process Subject Matter Experts, QA, Data Scientists, IT, Beratern und weiteren relevanten Parteien bei Algorithmusauswahl, Training, Validierung, Test und Betrieb. Alle Beteiligten brauchen definierte Verantwortlichkeiten, angemessene Qualifikation und passende Zugriffsrechte.

Die Matrix ist kein Ersatz für ein RACI im QMS. Sie zeigt aber, dass Regulatory Affairs nicht automatisch die Hauptrolle trägt. In reinen Herstellungsprozessen liegen operative Annex-22-Aufgaben näher bei Process SME, QA, IT-Validation, IT und Data Science. Regulatory Affairs wird wichtig, wenn Modellnutzung Zulassungsunterlagen, Variations, Drug-Device-Kombinationen, externe Behördenkommunikation oder AI-Act-Mapping berührt.

Ein Beispiel macht die Verteilung greifbarer: Eine visuelle Defekterkennung an einer Verpackungslinie soll Blister mit beschädigter Folie automatisch ausschleusen. Der Process SME beschreibt Defektklassen, Grenzfälle, Beleuchtung, Kameraposition, Liniengeschwindigkeit und seltene Varianten im Sample Space. Data Science übersetzt diese Beschreibung in Modellarchitektur, Metriken, Explainability-Ansatz und Confidence-Schwellen. IT-Validation baut Testplan, Testdatenreferenz, Skriptlogik und Abweichungsbehandlung. QA prüft Unabhängigkeit der Testdaten, Genehmigung der Akzeptanzkriterien, Change Control und Betriebskontrollen. Supplier Oversight stellt sicher, dass der Kameralieferant Modellversionen, Trainings-/Validierungs-/Testlogik und Release-Änderungen belegbar macht.

Nachweise im Dossier

Für die Audit-Vorbereitung reicht eine Rollenbeschreibung allein nicht. Entscheidend ist, ob pro Dossierbaustein ein Owner, eine Review-Rolle und ein prüfbarer Nachweis existieren. Eine kompakte Arbeitsmatrix kann so aussehen:

Aufgaben des Process SME

Der Process SME trägt im Entwurf eine auffällige Verantwortung. Er muss die Zweckbestimmung des Modells fachlich absichern. Intended use umfasst nicht nur einen Satz wie "Klassifikation von Defekten", sondern eine detaillierte Beschreibung des Prozesses, der Modellaufgabe, der Eingabedaten, der üblichen und seltenen Varianten, der Grenzen des Sample Space und möglicher fehlerhafter oder verzerrter Eingaben.

Auch Akzeptanzkriterien hängen am Prozesswissen. Bei einem Klassifikationsmodell können Sensitivity, Specificity, Accuracy, Precision, F1 Score oder Confusion Matrix relevant sein. Der Process SME muss die passende Metrik für den Prozess begründen. Bei einer visuellen Defekterkennung kann eine geringe False-Negative-Rate wichtiger sein als eine hohe Gesamtgenauigkeit.

Der Entwurf setzt für diese Kriterien eine Untergrenze: Sie sollen mindestens so hoch liegen wie die Leistung des Prozesses, den das Modell ersetzt. Diese Anforderung ist knapp formuliert und hat eine weitreichende Voraussetzung, denn sie verlangt, dass die Leistung des abzulösenden Prozesses bekannt ist. Für eine manuelle Sichtprüfung liegt eine solche Messung selten vor. Wer ein Modell gegen einen ungemessenen Prozess abnehmen will, hat keinen Vergleichsmaßstab, und der Nachweis, dass sich das Risiko nicht erhöht hat, wird zur Behauptung.

Praktisch heißt das: Die Messung des Ausgangsprozesses gehört an den Anfang des Vorhabens, nicht in die Testphase. Sie braucht dieselbe Sorgfalt wie der Modelltest, also definierte Metriken, ausreichende Fallzahl und eine belastbare Referenz für die richtige Antwort. Der Aufwand fällt vor der Modellauswahl an und wird in Projektplänen oft übersehen.

Bei Human-in-the-loop-Anwendungen beschreibt der Process SME außerdem die Verantwortung des Operators. Wenn der Testaufwand wegen menschlicher Review-Barriere reduziert wird, muss der Mensch als Prozessbestandteil kontrolliert werden. Training und konsistente Leistung des Operators werden dann ähnlich betrachtet wie bei anderen manuellen GMP-Prozessen.

Aufgaben der QA

QA verankert Annex 22 im Qualitätssystem. Dazu gehört zuerst eine SOP-Logik, die KI/ML-Modelle nicht nur als Software-Funktion behandelt, sondern intended use, Datenbasis, Testdaten-Unabhängigkeit, Explainability, Confidence und Betriebskontrolle als eigene Prüfpunkte aufnimmt.

QA verantwortet außerdem die Governance der Testdaten-Unabhängigkeit. Der Entwurf verlangt technische oder prozedurale Kontrollen, damit Testdaten nicht in Entwicklung, Training oder Validierung einfließen. Zugriff auf Testdaten muss kontrolliert und durch Audit Trail nachvollziehbar sein. Es darf keine unkontrollierten Kopien außerhalb des definierten Repositories geben.

Im Betrieb liegt QA nahe an Change Control und Periodic Evaluation. Modell, System und der automatisierte oder unterstützte Prozess müssen vor Deployment unter Change Control stehen. Änderungen am Modell, am System, am Prozess oder an physischen Objekten, die als Input dienen, müssen bewertet werden. Ein Verzicht auf Retest braucht Begründung.

QA führt außerdem die Audit-Vorbereitung. Prüffragen werden sich an den Entwurfsbegriffen orientieren: intended use, Akzeptanzkriterien, Testdaten, Testplan, Abweichungen, Explainability, Confidence, Configuration Control, Performance-Monitoring und Human Review. Ein allgemeines "KI ist validiert" reicht für diese Struktur nicht.

Aufgaben von IT-Validation

IT-Validation übersetzt Annex 22 in ein prüfbares Dossier. Das beginnt mit der Verbindung zu Annex 11: Systembeschreibung, Datenflüsse, Schnittstellen, Lieferantensteuerung, Zugriffsschutz, Audit Trails, Change Control, Security und Business Continuity bleiben relevant. Annex 22 ergänzt diese Basis um KI-spezifische Evidenz.

Für den Testplan braucht IT-Validation mehr als klassische Funktionsprüfung. Der Plan muss intended use, vordefinierte Metriken, Akzeptanzkriterien, Referenz auf Testdaten, Testskript und Berechnungslogik für Metriken enthalten. Der Process SME muss in die Planentwicklung eingebunden sein.

Abweichungen in der Testausführung sind besonders sensibel. Nicht erreichte Akzeptanzkriterien, ausgelassene Testdaten oder Abweichungen vom Testplan müssen dokumentiert, untersucht und begründet werden. Testdokumentation, Testdatenbeschreibung, tatsächlich verwendete Testdaten, physische Testobjekte sowie Audit-Trail-Aufzeichnungen zum Testdatenzugriff müssen aufbewahrt werden.

IT-Validation strukturiert auch Betrieb und Monitoring. Performance-Metriken werden im Betrieb überwacht. Zusätzlich wird geprüft, ob neue Eingabedaten weiterhin im Sample Space und intended use liegen. Für Drift in Inputdaten müssen Metriken definiert werden. Damit wird Monitoring zu einem Element des validierten Zustands.

Aufgaben von Data Science und IT

Data Science liefert Modellverständnis, Metriklogik und Explainability. Der Entwurf nennt Feature Attribution und Beispiele wie SHAP, LIME oder Heatmaps. Diese Verfahren sind kein Selbstzweck. Sie sollen prüfen helfen, ob ein Modell Entscheidungen auf relevante und angemessene Merkmale stützt.

Bei Confidence Scores geht es um Schwellenlogik. Modelle, die Vorhersagen oder Klassifikationen erzeugen, sollen dort, wo anwendbar, einen Confidence Score loggen. Niedrige Confidence kann dazu führen, dass das Modell "undecided" ausgibt statt eine unzuverlässige Klassifikation zu erzeugen. Die Schwelle muss fachlich und statistisch begründet werden.

IT stellt Zugriffsschutz, Audit Trails, Repository-Kontrolle, Configuration Control und technische Unveränderbarkeit sicher. Das betrifft nicht nur das Produktionssystem, sondern auch Testdaten-Repositories, Modellartefakte, Scripts, Feature-Definitionen, Trainings-/Validierungs-/Testdatensplits und Deployment-Pakete.

Supplier Oversight

Der Entwurf stellt klar, dass Dokumentation auch dann verfügbar und durch den regulierten Nutzer reviewt werden muss, wenn Modelltraining, Validierung oder Test durch Supplier oder Service Provider erfolgen. Anbieterunterlagen können also nicht nur abgelegt werden. Sie müssen fachlich gegen intended use, Datenbasis, Akzeptanzkriterien, Teststrategie und Betriebskontrollen geprüft werden.

Für SaaS- und OEM-KI-Funktionen ist das entscheidend. Der regulierte Nutzer braucht genügend Informationen über Modellart, Trainings-/Validierungs-/Testlogik, Modellversion, Änderungskontrolle, Datenverarbeitung, Supportzugriffe, Release-Kommunikation, Performance-Monitoring und Exportfähigkeit. Wo der Anbieter diese Evidenz nicht liefern kann, entsteht eine Dossierlücke.

Vertraglich gehören mindestens fünf Punkte in die Prüfung: Erstens braucht der regulierte Nutzer Zugriff auf validierungsrelevante Modell- und Testdokumentation, auch wenn Details zum proprietären Modell geschützt bleiben. Zweitens muss der Anbieter Modellversionshistorie, Release Notes und Änderungskategorien rechtzeitig liefern. Drittens sind Support- und Fernzugriffe mit Rollen, Protokollierung und Datenzugriff zu regeln. Viertens braucht das QMS Audit-Rechte oder gleichwertige Lieferantennachweise. Fünftens muss eine Exit-Fähigkeit bestehen, damit Daten, Konfigurationen und relevante Nachweise bei Anbieterwechsel oder Abschaltung verfügbar bleiben.

Regulatory Affairs und EU AI Act

Regulatory Affairs wird relevant, wenn KI-Komponenten in Zulassungsunterlagen, Variations, Drug-Device-Kombinationen oder Behördenkommunikation hineinwirken. Bei einer reinen GMP-Herstellungsanwendung ohne Zulassungsänderung liegt die operative Hauptarbeit nicht bei Regulatory Affairs.

Der EU AI Act muss getrennt gemappt werden. Art. 6 kann relevant werden, wenn ein AI-System als Sicherheitskomponente eines Produkts unter Annex-I-Harmonisierungsrecht gilt, etwa bei Medical Device oder IVD-Konstellationen. Annex III enthält eigene Hochrisiko-Felder, aber keine pauschale Einstufung für Pharma-Manufacturing. Pharma-Unternehmen dokumentieren daher AI-Act-Rolle, Systemkategorie und GMP-Scope nebeneinander.

Predetermined Change Control Plans aus dem FDA-Device-Kontext können als Vergleich für vorab beschriebene Änderungslogik dienen. Sie sind aber kein Annex-22-Pflichtartefakt. Für Annex 22 ist zunächst die konkrete Change-Control-Anforderung aus Abschnitt Operation maßgeblich: Änderung dokumentieren, bewerten, Retest-Entscheidung begründen.

Audit-Vorbereitung

Eine Inspektion mit Annex-22-Bezug wird voraussichtlich entlang der Entwurfsstruktur fragen. Der erste Block betrifft Scope und intended use: Anwendung, Prozess, Daten, kritische Wirkung, Modellart, statisch oder dynamisch, deterministischer oder probabilistischer Output, Human-in-the-loop oder Automatisierung.

Der zweite Block betrifft Testdaten und Testausführung. Inspektoren können nach Repräsentativität, Subgruppen, seltenen Varianten, Labelprüfung, Vorverarbeitung, Ausschlüssen, Testdaten-Unabhängigkeit, Zugriffsschutz, Audit Trail, Testplan, Abweichungen und Aufbewahrung der Testdokumentation fragen.

Der dritte Block betrifft Betrieb. Hier stehen Change Control, Configuration Control, unauthorisierte Änderungen, Performance-Monitoring, Input-Sample-Space-Monitoring, Drift-Metriken und Human-Review-Aufzeichnungen im Vordergrund.

90-Tage-Startpfad

Tag 1 bis 30: AI Use Case Inventory und Scope Screening. Alle KI/ML-Anwendungen und Piloten erfassen, wie es auch der integrierte Dossier-Workflow als erstes Artefakt vorsieht. Pro Anwendung werden Prozess, intended use, Datenklasse, kritische GMP-Wirkung, Modellart, Output-Verwendung, Anbieter und Verantwortlichkeit dokumentiert. Generative KI, LLMs, dynamische Modelle und probabilistische Outputs werden gesondert markiert. Ergebnis ist ein priorisiertes Inventory mit Scope-Entscheidung und offenen Klärpunkten.

Tag 31 bis 60: Intended Use Sheet und Test Data Independence Record. Für kritische Kandidaten werden intended use, Sample Space, Subgruppen, seltene Varianten, fehlerhafte Eingaben, Bias-Risiken und Akzeptanzmetriken beschrieben. Parallel entsteht die Testdatenstrategie mit Datensplit, Zugriffsschutz, Audit-Trail-Anforderung und Begründung für Ausschlüsse.

Tag 61 bis 90: Acceptance Criteria Protocol und Operation Monitoring Plan. Testplan, Testskript, Akzeptanzkriterien, Explainability-Ansatz, Confidence-Schwellen, Change-Control-Regel, Configuration Control, Performance-Monitoring, Drift-Metriken und Human-Review-Prozess werden als Dossierbausteine angelegt. Der Abschluss ist kein finales Validierungsdossier, sondern eine belastbare Struktur für die spätere finale Annex-22-Fassung.

Dieser Startpfad ersetzt keine finale Annex-22-Umsetzung. Er schafft aber fünf prüfbare Artefakte, mit denen die spätere finale Fassung gegen vorhandene Dossierbausteine gemappt werden kann.