GxP-Softwareentwicklung: Anforderungen, Validierung und Nachvollziehbarkeit

Wer zum ersten Mal Software für ein GxP-Umfeld baut, unterschätzt meistens nicht die technische Komplexität, sondern die Beweislast. Die eigentliche Frage lautet nicht „funktioniert es?“, sondern: „Können Sie belegen, dass es für den vorgesehenen Zweck geeignet ist – und dass es das über die Zeit bleibt?“ Dieser Unterschied prägt jeden Schritt des Entwicklungsprozesses.

1. Was GxP umfasst – und was daraus für Software folgt

GxP ist ein Sammelbegriff für „Good x Practice“-Regelwerke: Good Manufacturing Practice (GMP), Good Clinical Practice (GCP), Good Laboratory Practice (GLP), Good Distribution Practice (GDP) und weitere. Sie stammen aus unterschiedlichen Rechtsräumen, teilen aber eine gemeinsame Logik: Prozesse, die Produktqualität oder Patientensicherheit beeinflussen, müssen beherrscht, dokumentiert und überprüfbar sein.

Für computergestützte Systeme konkretisieren das vor allem zwei Dokumente: der Annex 11 des EU-GMP-Leitfadens (EudraLex Volume 4) und 21 CFR Part 11 der US-amerikanischen FDA. Beide verlangen im Kern dasselbe: dass ein System für seinen Zweck validiert ist, dass Daten zugeordnet, unverändert nachweisbar und über ihre Aufbewahrungsfrist verfügbar bleiben, und dass Zugriffe und Änderungen kontrolliert erfolgen.

Wichtig für die Einordnung: Diese Anforderungen richten sich an das System in seinem Einsatz, nicht an ein Werkzeug im Regal. Eine Entwicklungsplattform kann Voraussetzungen mitbringen; „GxP-konform“ wird immer erst die konkrete Anwendung bei einem konkreten Betreiber – und auch dann nur mit der zugehörigen Prozess- und Nachweislage.

2. Intended Use: die Grundlage jeder Bewertung

Der bestimmungsgemäße Gebrauch legt fest, wofür ein System eingesetzt wird, welche GxP-relevanten Daten es verarbeitet, welche Entscheidungen darauf beruhen und welche Prozessschritte es unterstützt. Alles Weitere – Risikoklasse, Validierungsumfang, Testtiefe, Aufbewahrungspflichten – leitet sich daraus ab.

Ein brauchbar formulierter Intended Use beantwortet mindestens:

• Welcher regulierte Prozess wird unterstützt, und in welchem Umfang?
• Welche Daten entstehen, werden verändert oder ausgewertet – und sind sie GxP-relevant?
• Welche Entscheidungen werden auf Basis dieser Daten getroffen?
• Was passiert, wenn das System falsche Ergebnisse liefert oder ausfällt?
• Welche Schnittstellen bestehen zu anderen validierten Systemen?

Unscharfe Formulierungen an dieser Stelle rächen sich später doppelt: Sie führen entweder zu übermäßigem Validierungsaufwand für unkritische Funktionen oder zu Lücken bei genau den Funktionen, auf die es ankommt.

3. Risikobasierter Ansatz: Aufwand dorthin, wo Risiko ist

Sowohl Annex 11 als auch die einschlägigen Branchenleitfäden – allen voran GAMP 5 – gehen von einem risikobasierten Vorgehen aus. Nicht jede Funktion wird gleich tief geprüft; entscheidend ist der Einfluss auf Produktqualität, Patientensicherheit und Datenintegrität.

Praktisch heißt das, Funktionen zu klassifizieren und daraus die Prüftiefe abzuleiten. Eine bewährte Grobstruktur:

Ebenfalls aus GAMP 5 stammt die Unterscheidung nach Softwarekategorien – von Infrastruktursoftware über konfigurierte Standardprodukte bis zu kundenspezifischer Software. Sie ist deshalb relevant, weil eine Plattformentscheidung den Validierungsaufwand direkt beeinflusst: Was als konfiguriertes Plattformverhalten abgebildet wird, muss anders nachgewiesen werden als individuell programmierte Logik.

4. Validierungsplanung: erst planen, dann prüfen

Die Validierungsplanung legt vor Beginn fest, was nachgewiesen werden soll, mit welchen Mitteln, durch wen und mit welchen Akzeptanzkriterien. Sie ist bewusst ein vorlaufendes Dokument – Nachweise, deren Kriterien erst nachträglich formuliert werden, sind schwach.

Typischer Umfang:

• Geltungsbereich und Abgrenzung: Was ist Teil der Validierung, was ausdrücklich nicht?
• Risikobewertung und daraus abgeleitete Prüftiefe.
• Anforderungen (User Requirements) als Bezugspunkt aller Nachweise.
• Qualifizierungsschritte – klassisch Installation, Funktion und Leistung im Einsatzkontext.
• Verantwortlichkeiten, Freigaben und Abweichungsbehandlung.
• Lieferantenbewertung, wenn Plattform- oder Fremdsoftware eingesetzt wird.
• Aufrechterhaltung des validierten Zustands: Change Control, periodische Überprüfung, Außerbetriebnahme.

Der letzte Punkt ist der am häufigsten unterschätzte. Validierung ist kein Projektabschluss, sondern ein Zustand, der gepflegt werden muss – über Updates, Personalwechsel und Infrastrukturänderungen hinweg.

5. Requirements: ohne Kennung keine Nachweiskette

Anforderungen sind im GxP-Kontext keine Projektartefakte, sondern der Anker der gesamten Nachweisführung. Jeder Test, jede Abweichung, jede Änderung bezieht sich am Ende auf eine Anforderung.

• Eindeutig identifiziert und stabil versioniert.
• Prüfbar formuliert: eine Anforderung, die sich nicht testen lässt, lässt sich auch nicht validieren.
• Nach GxP-Relevanz gekennzeichnet – nicht jede Anforderung ist regulatorisch relevant, und diese Unterscheidung spart erheblichen Aufwand.
• Verknüpft mit Design, Implementierung, Test und Freigabe – die Traceability-Matrix ist nichts anderes als die sichtbar gemachte Summe dieser Verknüpfungen.

Wenn diese Struktur im Werkzeug erzwungen wird statt in einer Tabelle gepflegt zu werden, entfällt der größte Teil der klassischen Dokumentationsarbeit. Nicht, weil weniger nachgewiesen wird, sondern weil der Nachweis beim Arbeiten entsteht.

6. Testing: Nachweis statt Stichprobe

Tests im GxP-Kontext haben eine formale Zusatzanforderung: Ergebnisse müssen zuordenbar, nachvollziehbar und aufbewahrbar sein. Ein Testlauf, dessen Protokoll nach 30 Tagen aus der CI-Oberfläche verschwindet, ist als Nachweis unbrauchbar.

Bewährte Praxis:

1. Testfall referenziert Anforderung. Ohne diese Verknüpfung gibt es keine Abdeckungsaussage.
2. Erwartetes Ergebnis vor der Ausführung festhalten – nachträglich formulierte Erwartungen sind keine Prüfung.
3. Negative Tests für risikoreiche Funktionen: Was passiert bei fehlenden Rechten, ungültigen Werten, Abbrüchen?
4. Nachweise versioniert ablegen, verknüpft mit dem exakten Softwarestand (Version, Prüfsumme, Build).
5. Abweichungen dokumentieren und bewerten, statt Testfälle stillschweigend anzupassen.

Automatisierte Tests sind dabei ausdrücklich willkommen – sie sind reproduzierbar, protokollierbar und laufen bei jeder Änderung erneut. Ihre regulatorische Belastbarkeit hängt allerdings daran, dass die Testumgebung, die Testdaten und die Auswertung selbst kontrolliert sind.

7. Audit Trails: technisch einfach, organisatorisch anspruchsvoll

Ein Audit Trail zeichnet auf, wer wann welchen GxP-relevanten Datensatz wie verändert hat – und, wo gefordert, aus welchem Grund. Die technischen Anforderungen sind überschaubar; anspruchsvoll ist die Nutzung.

• Automatisch und nicht abschaltbar für GxP-relevante Daten. Ein Protokoll, das im Betrieb deaktiviert werden kann, verliert seine Beweiskraft.
• Vollständig: alter Wert, neuer Wert, Zeitstempel, handelnde Person, betroffener Datensatz.
• Vor Veränderung geschützt, mit klarer Trennung von Anwendungs- und Administrationsrechten.
• Auswertbar: Ein Audit Trail, den man nur als Rohdaten exportieren kann, wird faktisch nicht geprüft.
• Regelmäßig überprüft (Audit Trail Review) – genau hier liegt die organisatorische Last, die keine Software abnimmt.

Wenn Historisierung Teil der Plattform ist statt in jedem Projekt neu implementiert zu werden, sinkt nicht nur der Entwicklungsaufwand, sondern auch das Risiko unvollständiger Aufzeichnungen. Wie CodamAI Historie und Nachvollziehbarkeit technisch abbildet, steht auf der Feature-Seite.

8. Elektronische Aufzeichnungen und Signaturen

Wo elektronische Aufzeichnungen Papier ersetzen, gelten zusätzliche Anforderungen. Als gemeinsamer Nenner hat sich das Prinzip der Datenintegrität etabliert, häufig als ALCOA+ zusammengefasst: Daten sollen zuordenbar, lesbar, zeitnah, original und korrekt sein – ergänzt um vollständig, konsistent, dauerhaft und verfügbar.

Für die Umsetzung heißt das konkret:

• eindeutige, personenbezogene Benutzerkonten – keine geteilten Zugänge,
• rollenbasierte Berechtigungen mit dokumentierter Vergabe,
• Schutz gegen unbemerkte Veränderung, inklusive Sicherung und Wiederherstellbarkeit,
• Lesbarkeit über die gesamte Aufbewahrungsfrist – auch nach Systemwechsel,
• bei elektronischen Signaturen: eindeutige Zuordnung zur Person, sichtbarer Bezug zum signierten Datensatz und die Bedeutung der Signatur.

Der zuletzt genannte Punkt wird häufig als reine Technikfrage behandelt. Er ist zuerst eine Prozessfrage: Wer darf was mit welcher Bedeutung signieren, und wie wird das geschult und überwacht?

9. Change Control: den validierten Zustand halten

Nach der Freigabe wird jede Änderung zum bewertungspflichtigen Ereignis. Die zentrale Frage lautet nicht „ist die Änderung klein?“, sondern „berührt sie GxP-relevante Funktionen?“.

Ein tragfähiger Ablauf umfasst:

• Änderungsantrag mit fachlicher Begründung und betroffenen Anforderungen,
• Risikobewertung inklusive Auswirkung auf den validierten Zustand,
• Festlegung der erforderlichen Nachweise (Tests, Dokumente, ggf. Requalifizierung),
• Freigabe durch definierte Rollen vor Wirksamwerden,
• Nachführung der Dokumentation und der Traceability.

Wird die Bewertung an die Risikoklasse gekoppelt, bleibt der Prozess auch bei hoher Änderungsfrequenz handhabbar. Genau das ist die Voraussetzung dafür, moderne Entwicklungsgeschwindigkeit überhaupt in einem GxP-Umfeld nutzen zu können.

10. Rollen und Verantwortung

GxP-Regelwerke adressieren Verantwortung ausdrücklich. Für Softwareprojekte ergeben sich in der Praxis vier Rollenbündel, die klar zugeordnet sein müssen:

• Prozessverantwortliche (Process Owner) – definieren Verwendungszweck und fachliche Anforderungen.
• Systemverantwortliche (System Owner) – verantworten Betrieb, Konfiguration und Systemlebenszyklus.
• Qualitätseinheit (QA) – prüft und gibt frei, unabhängig von der Entwicklung.
• Lieferant / Entwicklung – liefert nachweisfähig, unterliegt einer Lieferantenbewertung, trägt aber nicht die regulatorische Verantwortung des Betreibers.

Diese Trennung ist keine Formalie. Sie entscheidet darüber, ob eine Freigabeentscheidung im Audit trägt.

11. KI-Nutzung als zusätzlicher kontrollierter Faktor

Der Einsatz von KI in der Entwicklung ist im GxP-Kontext kein Ausschlusskriterium – aber ein Faktor, der wie jeder andere kontrolliert werden muss. Zu unterscheiden sind dabei zwei völlig verschiedene Fälle:

1. KI als Entwicklungswerkzeug. Das Modell erzeugt Code oder Konfiguration, ausgeliefert wird deterministische Software. Die Validierung richtet sich unverändert auf das Ergebnis. Zusätzlich zu regeln sind Datenflüsse, Prüfpflichten und Dokumentation des Werkzeugeinsatzes.
2. KI als Funktion im validierten System. Wenn ein Modell zur Laufzeit GxP-relevante Entscheidungen beeinflusst, entsteht eine eigene, deutlich anspruchsvollere Fragestellung – inklusive Reproduzierbarkeit, Modellversionierung, Datenherkunft und laufender Überwachung. Dieser Fall gehört gesondert bewertet und ist nicht Gegenstand dieses Artikels.

Für den ersten Fall genügt in der Regel eine überschaubare Ergänzung des bestehenden Regelwerks: Welche Werkzeuge sind zugelassen, welche Daten dürfen hinein, welche Prüfungen sind verpflichtend, und wie wird der Einsatz dokumentiert. Die Prüfmittel selbst – Review, Test, Traceability, Change Control – bleiben dieselben. Wie eine solche Regelung aussieht, beschreibt der Deep Dive AI Coding Governance.

Wie sich das in einen durchgängigen Entwicklungsprozess einfügt, beschreibt der Artikel zu regulierter Softwareentwicklung mit KI.

Checkliste: GxP-Softwareprojekt

Fazit

GxP-Anforderungen sind kein Hindernis für moderne Softwareentwicklung. Sie sind eine Anforderung an die Beweislage – und Beweise lassen sich automatisieren. Anforderungen mit Kennung, Modelle statt impliziter Konventionen, Tests mit Anforderungsbezug, Historie als Plattformeigenschaft, reproduzierbare Builds und risikobasierte Änderungsbewertung: Das ist der überwiegende Teil dessen, was in Audits tatsächlich gefragt wird.

Was bleibt, ist die organisatorische Verantwortung – Verwendungszweck, Risikobewertung, Freigabe, Schulung, Überwachung. Sie lässt sich nicht an ein Produkt delegieren, und keine Plattform sollte etwas anderes behaupten.