GAMP 5 2nd Edition: Was CSV jetzt braucht

Warum eine zweite Ausgabe — und was sie nicht ist

Die erste GAMP-5-Ausgabe stammt aus 2008. Seither hat sich die Art, wie regulierte Unternehmen Software beschaffen und betreiben, grundlegend verschoben: weg von hausintern entwickelten, einmalig validierten Systemen, hin zu konfigurierbaren Standardprodukten, kontinuierlich gelieferten Cloud-Diensten und Plattformen, die sich monatlich ändern. Die Second Edition (2022) ist die Antwort des ISPE auf diese Realität — und auf parallele Bewegungen bei den Behörden, insbesondere die FDA-Initiative Computer Software Assurance (CSA).

Wichtig für die Einordnung: Die zweite Ausgabe ist keine Kehrtwende. Der risikobasierte, Lifecycle-orientierte Kern bleibt unverändert — die fünf Software-Kategorien, das Lieferanten-Leverage-Prinzip, die Forderung nach Datenintegrität. Was sich ändert, ist die Betonung. GAMP 5 wollte schon immer verhältnismäßige, risikobasierte Validierung. In der Praxis hat die Branche daraus oft Dokumenten-Rituale gemacht: identische Testskripte für unkritische Funktionen, Screenshots als Selbstzweck, Reviews, die Vollständigkeit prüfen statt Risiko. Die Second Edition korrigiert diese Fehlinterpretation explizit.

Critical Thinking: das tragende Prinzip

Der sichtbarste Zugewinn der zweiten Ausgabe ist die Aufwertung von Critical Thinking zum durchgängigen Prinzip. Gemeint ist keine Worthülse, sondern eine konkrete Erwartung: Jede Validierungsaktivität soll aus einer bewussten, begründeten Risikoentscheidung folgen — nicht aus einer Checkliste, die für jedes System gleich abgearbeitet wird.

Praktisch heißt das: Ihr Team fragt vor jedem Testfall, warum er existiert. Welches Patientenrisiko, welche Datenintegritäts- oder Produktqualitätsgefahr deckt er ab? Was passiert im schlimmsten Fall, wenn diese Funktion versagt? Für Funktionen mit hohem Risiko bedeutet das mehr Tiefe als zuvor. Für unkritische, von einem etablierten Lieferanten bereits getestete Standardfunktionen bedeutet es: weniger redundante Eigenprüfung, mehr Stützung auf den Lieferantennachweis.

Der Preis dieser Freiheit ist Verantwortung. Wo eine Checkliste keine Begründung verlangte, verlangt Critical Thinking eine nachvollziehbare Rationale — und die muss im Audit Bestand haben. Genau hier verschiebt sich die Belastung: weg vom Umfang der Dokumentation, hin zur Qualität der dokumentierten Entscheidung.

Critical Thinking verschiebt die Last vom Umfang der Dokumentation zur Qualität der dokumentierten Entscheidung.

Agile und iterative Lifecycles werden anerkannt

Lange galt im GxP-Umfeld die stille Annahme, Validierung verlange ein sequenzielles V-Modell: erst die komplette Spezifikation, dann der Build, dann die Tests, am Ende ein Validierungsbericht. Agile Teams, die in Sprints liefern, standen damit im scheinbaren Widerspruch zur Regulatorik.

Die Second Edition räumt mit diesem Missverständnis auf. Sie erkennt agile, iterative und inkrementelle Vorgehensweisen ausdrücklich an — vorausgesetzt, die Kontrollen bleiben erhalten. Entscheidend ist nicht die Reihenfolge der Phasen, sondern dass am Ende belegbar ist: Anforderungen sind rückverfolgbar, Risiken bewertet, Tests bestanden, Änderungen kontrolliert. Ob diese Belege über Sprints verteilt entstehen oder in einem großen Block, ist regulatorisch zweitrangig.

Für Ihre Praxis heißt das: Sie dürfen continuous delivery und automatisierte Test-Pipelines nutzen — solange deren Ergebnisse versioniert, nachvollziehbar und an Anforderungen geknüpft bleiben. Automatisierte Tests werden nicht zum Compliance-Risiko; sie werden, sauber konfiguriert und qualifiziert, zum Compliance-Vorteil, weil sie reproduzierbar und lückenlos protokolliert sind.

Software-Kategorien, Cloud und der Lieferanten-Hebel

Die fünf GAMP-Software-Kategorien bleiben das Rückgrat der Risikoeinstufung — von Infrastruktur (Kategorie 1) über nicht-konfigurierte und konfigurierte Standardprodukte (Kategorien 3 und 4) bis zu kundenspezifischer Anwendung (Kategorie 5). Was die zweite Ausgabe schärft, ist die Erwartung, wie Sie diese Einstufung nutzen, um Aufwand zu steuern: Je mehr ein etablierter Lieferant bereits nachweisbar getestet hat, desto stärker dürfen Sie sich auf diesen Nachweis stützen, statt ihn zu duplizieren.

Dieses Leveraging supplier activities ist im Cloud-Zeitalter kein Nebenschauplatz mehr, sondern zentral. Bei Software as a Service kontrollieren Sie die Infrastruktur nicht selbst, sehen den Code nicht und erleben Updates, die der Anbieter ausrollt. Die Second Edition adressiert diese Lage direkt: Der Schwerpunkt verschiebt sich von der Eigen-Qualifizierung hin zu robustem Lieferantenmanagement — Audit oder fundierte Assessment des Anbieters, klare Service-Level- und Qualitätsvereinbarungen, ein Verständnis davon, wie der Anbieter Änderungen kontrolliert und kommuniziert.

Konkret sollten Sie prüfen: Wie informiert der Anbieter über Releases? Welche Change-Control hält er vor? Welche Belege (Zertifikate, Testevidenz, Pentests) stellt er bereit? Die Verantwortung für die regulatorische Konformität bleibt bei Ihnen — auch wenn die technische Ausführung beim Anbieter liegt. Der EU-Annex 11 formuliert dieselbe Erwartung an die Steuerung von Dienstleistern und Zulieferern.

Der neue Blick auf KI und maschinelles Lernen

Mit der zweiten Ausgabe und ihren begleitenden Materialien rückt erstmals künstliche Intelligenz und maschinelles Lernen in den GAMP-Rahmen. Der Grund ist offensichtlich: KI-Komponenten verhalten sich anders als klassische, deterministische Software. Sie sind datengetrieben, können probabilistisch antworten, und ihr Verhalten kann sich verändern, wenn sich Trainingsdaten oder Modell ändern. Ein einmaliger Validierungslauf am Stichtag bildet das nicht ab.

Die Leitlinien betonen deshalb Aspekte, die im klassischen V-Modell keine Hauptrolle spielten: Datenqualität und Datenherkunft, Nachvollziehbarkeit der Modellentscheidung, Umgang mit Modell-Drift, und vor allem ein risikobasiertes, fortlaufendes Monitoring statt eines einzelnen Validierungsereignisses. Je höher das Risiko der Anwendung — etwa wenn ein Modell unmittelbar in eine Qualitätsentscheidung einfließt — desto strenger die Anforderungen an Erklärbarkeit und menschliche Aufsicht.

Diese Erwartung deckt sich mit der breiteren regulatorischen Linie. Die EMA hat ein Reflection Paper zum Einsatz von KI über den Arzneimittel-Lebenszyklus vorgelegt; die FDA hat einen risikobasierten Entwurf für KI im Arzneimittel-Lebenszyklus publiziert. Der gemeinsame Nenner: KI darf unterstützen, aber die Verantwortung für die GxP-Entscheidung bleibt beim Menschen — und sie muss nachvollziehbar dokumentiert sein.

Was Ihr Team konkret anpassen sollte — und was bleibt

Aus der Theorie wird Arbeit. Die folgenden Verschiebungen sind die, die in der Praxis am stärksten durchschlagen:

• Validierungsstrategie statt Validierungs-Volumen: Verankern Sie eine dokumentierte, risikobasierte Begründung pro System und pro kritischer Funktion. Weniger generische Testskripte, mehr gezielte Tiefe dort, wo Patient, Produkt oder Daten gefährdet sind.
• Lieferantenbewertung professionalisieren: Bei Cloud und SaaS wird das Anbieter-Assessment zum Kern Ihrer Evidenzkette. Vertraglich verankerte Change-Kommunikation, Audit-Rechte und Qualitätsvereinbarungen gehören in den Standardprozess.
• Agile Evidenz zulassen: Passen Sie SOPs so an, dass iterativ entstandene, versionierte Belege ausdrücklich anerkannt werden — inklusive automatisierter, qualifizierter Test-Pipelines.
• KI/ML gesondert behandeln: Für lernende oder generative Komponenten brauchen Sie Datenqualitäts-Kontrollen, Monitoring auf Drift und einen klar definierten Punkt menschlicher Freigabe — kein einmaliges Abnahme-Ereignis.

Und was bleibt bewusst gleich? Das Wesentliche: Die Validierungspflicht selbst verschwindet nicht. Datenintegrität (ALCOA+), Rückverfolgbarkeit von Anforderung zu Test, kontrollierte Änderungen, ein vollständiger und manipulationssicherer Audit-Trail und die letztliche QA-Verantwortung — all das ist nicht verhandelbar und war nie zur Disposition gestellt. Die Second Edition will, dass Sie klüger validieren, nicht weniger sicher.

Wie eine Trust-Architektur dazu passt

Wenn Critical Thinking und KI-Unterstützung zusammenkommen, entsteht eine berechtigte Sorge in jeder Qualitätsabteilung: Verlieren wir die Kontrolle über die Begründung, sobald ein Modell mitschreibt? Genau an dieser Stelle entscheidet die Architektur — nicht die Marketing-Sprache.

traqx ist bewusst so gebaut, dass die Prinzipien dieser Regulatorik nicht untergraben, sondern gestützt werden. Quellen zuerst: KI-Ausgaben werden an nachprüfbare, interne Quellen gebunden statt frei generiert. KI als Vorschlag: Das System liefert einen Entwurf, keine Entscheidung. Der Mensch entscheidet: Die menschliche Freigabe bleibt verpflichtend — die QA-Verantwortung wandert nicht in die Maschine. Der Audit-Trail bleibt: Wer was wann auf welcher Quelle entschieden hat, ist nachvollziehbar protokolliert.

Das ist keine Behauptung, GAMP-5-konform zu sein — Konformität stellt immer Ihr validiertes Verfahren in Ihrem Kontext her, nicht ein Werkzeug. Es ist die Aussage, dass eine Architektur, die Quellenbindung, menschliche Freigabe und einen lückenlosen Audit-Trail als Fundament behandelt, mit dem, was die Second Edition fordert, gut zusammenpasst — statt dagegen zu arbeiten.