CSV endet nicht bei der Qualifizierung: Periodic Review und Change Control als häufige Findings

Ein System gilt im Audit nicht deshalb als validiert, weil zum Go-live ein unterschriebener Validierungsreport vorliegt. Es gilt als validiert, solange der dokumentierte Zustand mit dem tatsächlichen Zustand übereinstimmt. Diese Unterscheidung ist der Kern der meisten Annex-11-Findings: Die Erstqualifizierung ist sauber, aber zwischen Go-live und der nächsten Inspektion liegen zwei Jahre Betrieb, in denen niemand den Validierungsstatus gepflegt hat.

Der Irrtum: validiert ist ein Datum, nicht ein Zustand

Computer System Validation (CSV) wird in vielen Organisationen als Projekt geführt. Es gibt einen Validierungsplan, eine Risikoanalyse, die Qualifizierungsläufe IQ, OQ und PQ und am Ende einen Report mit Freigabe. Damit ist die Einführung abgeschlossen, das Projekt-Team löst sich auf, und das System geht in den Betrieb über.

Der EU-GMP-Leitfaden Annex 11 (Computerised Systems) behandelt den validierten Zustand aber als Lebenszyklus, nicht als Stichtag. Zwei Abschnitte machen das explizit:

• Abschnitt 11 (Periodic evaluation) verlangt, dass computergestützte Systeme periodisch bewertet werden, um zu bestätigen, dass sie weiterhin im validierten Zustand sind und Annex 11 erfüllen.
• Abschnitt 10 (Change and Configuration Management) verlangt, dass jede Änderung an einem validierten System über ein definiertes Verfahren mit Bewertung der Auswirkung gesteuert wird.

Wer CSV als einmaligen Projektabschluss versteht, erfüllt beide Anforderungen am Tag der Freigabe und verliert sie danach schrittweise. Genau dieser Verlust wird im Audit sichtbar.

Periodic Review: die häufigste Lücke nach der Erstqualifizierung

Die periodische Bewertung ist die Routine, die den validierten Zustand über die Lebensdauer eines Systems belegt. Sie gleicht ab, was sich seit der letzten Bewertung verändert hat: Änderungen, Abweichungen, offene CAPA, Audit-Trail-Auswertungen, Vorfälle, Benutzer- und Berechtigungsänderungen. Die Frequenz ist nicht fix vorgegeben, sondern risikobasiert festzulegen, häufig jährlich oder im Zweijahresrhythmus, gestaffelt nach GxP-Kritikalität.

In der Praxis fällt dieser Review nach der Erstqualifizierung häufig aus. Typische Muster:

• Es existiert kein Verfahren mit Trigger und Verantwortlichkeit, sodass niemand den Review terminlich anstößt.
• Der Review wird durchgeführt, aber als reine Formalbestätigung ohne tatsächlichen Soll-Ist-Abgleich der Systemhistorie.
• Die Bewertung deckt nur einen Teil der GxP-relevanten Systeme ab, weil der Systemkatalog unvollständig ist.

Das Ergebnis ist ein System, das nominell validiert ist, dessen Validierungsstatus aber nicht mehr belegbar ist. Bei der Inspektion findet der Auditor die Diskrepanz zwischen Dokumentation und Realität zur selben Zeit wie das Unternehmen, nur mit dem Unterschied, dass er sie als Finding protokolliert.

Change Control: die lückenhafte Historie als Major Finding

Noch unmittelbarer kritisch ist die Change-Control-Historie. Abschnitt 10 verlangt, dass Änderungen an validierten Systemen kontrolliert ablaufen, einschließlich einer Bewertung, welcher Umfang an Requalifizierung erforderlich ist. Der häufigste Fehler ist nicht das bewusste Umgehen dieses Prozesses, sondern die Einstufung technischer Routine als nicht regulierungsrelevant.

Ein Software-Patch, ein Betriebssystem-Upgrade, eine Konfigurationsänderung oder ein Update durch den Hersteller werden als administrativer IT-Vorgang behandelt und am Change Control vorbei eingespielt. Es fehlt das Impact Assessment, das die Frage beantwortet: Berührt diese Änderung GxP-relevante Funktionen, und welcher Teil des Systems muss erneut qualifiziert werden? Über Monate entsteht so eine Historie, in der der dokumentierte und der reale Systemstand auseinanderlaufen.

Im Inspektionskontext ist diese Lücke schwer zu reparieren, weil sie sich nicht nachträglich erzeugen lässt: Eine Change-Control-Historie, die im Betrieb nicht geführt wurde, kann nicht rückwirkend belegt werden. Sie gehört deshalb regelmäßig zu den Major Findings bei validierten Systemen. Wo zusätzlich der Audit Trail nach Abschnitt 9 nicht aktiviert oder nie ausgewertet wird, verbindet sich der Change-Control-Befund mit einem Datenintegritätsbefund.

Risikobasiert statt mit der Gießkanne: GAMP 5

Mehr Validierungsaufwand ist nicht automatisch mehr Compliance. GAMP 5 (ISPE, A Risk-Based Approach to Compliant GxP Computerized Systems, 2. Ausgabe 2022) staffelt den Aufwand nach Systemkategorie: von Standardsoftware über konfigurierte Produkte wie LIMS oder ERP bis zur Eigenentwicklung. Eine falsche Kategorisierung kostet in beide Richtungen.

• Übervalidierung bindet Ressourcen auf unkritischen Standardsystemen, die an kritischer Stelle fehlen.
• Untervalidierung lässt ein GxP-kritisches System mit zu geringem Testumfang in den Betrieb: ein regulatorisches Risiko.

Diese Logik gilt nicht nur bei der Einführung, sondern bestimmt auch, wie intensiv Periodic Review und Requalifizierung pro System ausfallen. Eine belastbare Risikoklassifizierung ist damit die Voraussetzung dafür, dass der laufende CSV-Betrieb verhältnismäßig bleibt.

Annex 22: KI-Systeme brauchen einen erweiterten Rahmen

Für KI- und ML-gestützte Systeme in GxP-Prozessen (etwa in der Qualitätskontrolle, in Laborsystemen oder in der Produktionssteuerung) reicht der klassische CSV-Rahmen absehbar nicht aus. Der EU GMP Annex 22 (Entwurf, Konsultation 2025) adressiert eine zusätzliche Ebene über Annex 11, unter anderem die laufende Überwachung von Modellen und ein KI-spezifisches Change Control für Modell-Updates.

Wichtig für die Einordnung: Der Annex ist noch nicht final. Wer KI in GxP-Prozessen einsetzt, sollte den bestehenden CSV-Rahmen aber frühzeitig auf diese Anforderungen ausrichten, statt sie nach Inkrafttreten nachzuarbeiten. Ein KI-System verändert sein Verhalten anders als deterministische Software: Ein Modell, das bei der Einführung valide war, kann durch veränderte Eingangsdaten von seinem qualifizierten Zustand abweichen. Damit wird die laufende Bewertung, die Annex 11 ohnehin verlangt, für KI-Systeme zur eigentlichen Kernaufgabe und nicht zur Pflichtübung am Stichtag.

Der validierte Zustand wird im Betrieb gehalten oder gar nicht. Konkret bedeutet das drei Routinen, die nach der Erstqualifizierung greifen müssen:

• Periodic-Review-Verfahren mit definiertem Trigger, Verantwortlichkeit und Kriterien, die den Soll-Ist-Abgleich der Systemhistorie erzwingen, nicht nur eine Bestätigung.
• Change Control mit Impact-Assessment-Logik, die jede Änderung einschließlich Patches und Updates erfasst und den Requalifizierungsumfang begründet ableitet.
• Audit-Trail-Review als feste Routine, sodass die Auswertung nicht erst zur Inspektion stattfindet.

Entourage begleitet diese Schritte gemeinsam mit der QA: von der Gap-Analyse des Systemkatalogs und der GAMP-5-Kategorisierung über die Qualifizierungsdokumentation für kritische Systeme bis zum laufenden CSV-Betrieb mit Periodic Review und Change Control. Für KI in GxP-Prozessen erweitern wir den bestehenden Annex-11-Rahmen um die Anforderungen, die der Annex-22-Entwurf in Aussicht stellt, ausgelegt auf den finalen Annex.