traqx

IT-Infrastruktur · EU-GMP Annex 11 In Entwicklung

Einmal qualifiziert, je Instanz verifiziert.

IT-Infrastruktur ist GAMP-Kategorie 1 — qualifiziert, nicht validiert. Der Building-Block wird als Typ einmal qualifiziert; jede Instanz wird deterministisch gegen die Konfigurations-Baseline geprüft.

Relevant für EU-GMP Annex 11, GAMP 5 (Kategorie 1, Appendix M11) und die ISPE GAMP GPG „IT Infrastructure“.

  • Qualifiziert, nicht validiert — der Nachweis für Kategorie-1-Software ist der erfasste und verifizierte Versions- und Konfigurationsstand, keine Testkampagne je Maschine.
  • Eine Qualifizierung, viele Umsetzungen — der Building-Block wird einmal qualifiziert; jede Instanz wird gegen die Baseline abgeglichen, Abweichungen werden sichtbar.
  • Verwandt mit Equipment, bewusst getrennt — Equipment qualifizieren Sie je Asset nach Annex 15; die Plattform darunter als Typ nach Annex 11. Wert und Workflow sind in Vorbereitung — im Pilot bauen wir die Disziplin an Ihrem Standard auf.

Die ganze Plattform

Annex 11GAMP 5 Kat. 1GAMP 5 M11ISPE GAMP GPG

Plattform-QualifizierungAnnex 11 · GAMP 5 Kat. 1

IT-INFRASTRUKTUR-QUALIFIZIERUNG · getrennt von Annex 15 GAMP Kat. 1 · IT-GPG IN VORBEREITUNG QuellenpaketPolicy · Build-SOPProtokoll-TemplateKonfig-Baselinequellengebunden Standard-Building-Blockqualifiziert 1×OS-Baseline · VM-ImageKat. 1 · nicht validiert CMDB · CI-ListeBaseline-Rev · OS+Ver · SW+Ver Instanz 01MATCHInstanz 02MATCHInstanz 03ABWEICHUNG→ ITQ-Review verifiziert je Instanz · Konfig = Baseline MENSCHentscheidetITQ-VerifikationausstehendQA-Freigaberisikobas. · offen Qualified PlatformRecordnach QA-Freigabe Plattform-Inventar Qualifizierungsplan Building Blocks Betrieb & Review AUDIT-TRAIL wer · was · wann · Bewertung fällig · keine autonome Freigabe

CMDB & Config-Item-Liste als Register · geplant, in Vorbereitung

Warum IT-Infrastruktur im Audit auffällt

Die Plattform trägt jede Applikation. Belegt ist sie selten.

Annex 11 trennt es in einem Satz: Die Applikation wird validiert, die IT-Infrastruktur wird qualifiziert. In der Praxis liegt der Nachweis für die Plattform unter den GxP-Applikationen aber verstreut — Build-Sheets, Ticket-Historien, das Wissen einzelner Administratoren. Je mehr Server, Standorte und Cloud-Anteile, desto schwerer wird zu zeigen, dass jede Instanz dem qualifizierten Stand entspricht.

01

Falsches Verb, falscher Aufwand

IT-Infrastruktur wird behandelt wie eine Applikation — oder wie Equipment: jede Maschine einzeln durch volle Testkampagnen. GAMP 5 sieht für Kategorie 1 einen anderen Weg vor; der Mehraufwand bringt keinen zusätzlichen Nachweiswert.

02

Baseline ohne Register

Die Konfigurations-Baseline lebt als Build-Sheet, in Skripten oder im Kopf der erfahrensten Person. Ohne gepflegte Config-Item-Liste lässt sich im Audit nicht zeigen, welcher Stand eigentlich der qualifizierte ist.

03

Drift bleibt unbemerkt

Patches, Ad-hoc-Änderungen und manuelle Eingriffe verändern Instanzen schleichend. Ohne Abgleich gegen die Baseline fällt die Abweichung erst im Audit auf — oder gar nicht.

Wie traqx IT-Infrastruktur abbilden soll

Vom Inventar zum gehaltenen Zustand — ein Typ, viele Instanzen.

Das Grundprinzip bleibt wie überall bei traqx: Policy → SOP → Template. traqx soll Ihre Infrastruktur-Policies, Build-SOPs, Protokoll-Templates und die Konfigurations-Baseline nutzen, um Qualifizierungs-Records vorzustrukturieren, Quellenbezüge sichtbar zu machen und jede Entscheidung nachvollziehbar zu halten. Die folgenden Schritte beschreiben den geplanten Workflow — dieser Use Case ist in Vorbereitung und wird im Pilot an Ihrem realen Prozess aufgebaut.

Schritt 01 Plattform-Inventar & Baseline erfassen Building-Blocks, Instanzen und ihre Config Items werden als Register geführt — Name, Modell, OS- und Software-Versionen, Owner. Die Konfigurations-Baseline wird versioniert erfasst, statt in Build-Sheets zu versanden. Geplant · in Vorbereitung — Workflow wird im Pilot aufgebaut
Schritt 02 Qualifizierungsplan & Protokolle strukturieren traqx soll Plattform-Qualifizierungsplan und Protokolle aus Ihren Policies, Build-SOPs und Templates vorstrukturieren — als Vorschlag, der quellgebunden danebensteht, bis Sie ihn annehmen, ändern oder ablehnen. Die Methode bleibt Ihre; Struktur und Beleg kommen von traqx. Geplant · in Vorbereitung — Vorschlag, kein automatischer Schreibvorgang
Schritt 03 Building-Block einmal qualifizieren Der Plattform-Typ — etwa eine OS-Baseline oder ein Standard-VM-Image — wird einmal qualifiziert: qualifiziert, nicht validiert (GAMP-Kategorie 1). Die ITQ-Verifikation prüft technisch; die QA-Freigabe bleibt strategisch und risikobasiert. Beides menschlich — traqx qualifiziert nicht. Geplant · in Vorbereitung — Freigabe bleibt bei ITQ und QA
Schritt 04 Instanzen gegen die Baseline verifizieren Jede neue Instanz wird deterministisch gegen die qualifizierte Baseline abgeglichen — Versions- und Konfigurations-Match statt erneuter Qualifizierung jeder Maschine. Eine Abweichung wird als Review-Fall sichtbar gemacht, nicht still akzeptiert. Geplant · in Vorbereitung — Abgleich deterministisch, Review bei Abweichung
durchgehend Zustand halten · Audit-Trail Qualifizierung ist kein Einmal-Event: Änderungen, Backup-/Restore-Nachweise und die periodische Bewertung bleiben mit dem Record verbunden. Der Audit-Trail schreibt mit: wer, was, wann, auf welcher Grundlage — als fortlaufend geschützte Historie. Geplant · in Vorbereitung — Audit-Trail nach demselben Prinzip wie in Live-Spokes

Warum das im Audit bestehen soll

Die KI strukturiert. Qualifiziert wird von Menschen.

Auch hier gilt das traqx-Grundprinzip: Kein KI-Output wird still in einen kontrollierten Datensatz geschrieben — und traqx qualifiziert oder zertifiziert keine Plattform. traqx soll die Evidenz erzeugen, prüfen und überwachen; die Qualifizierungsentscheidung bleibt bei ITQ und QA. Der Infrastruktur-Workflow soll auf der bestehenden traqx-Architektur aufsetzen und ist in Vorbereitung.

Generate Vorschlag bleibt Vorschlag Plan- und Protokoll-Entwürfe sollen als ausstehende Vorschläge am Datensatz leben. Der gespeicherte Inhalt bleibt unverändert, bis ein Mensch handelt — keine Plattform qualifiziert sich selbst.
Verify Zweistufige menschliche Freigabe Die ITQ-Verifikation (SME, technische Prüfung) ist der Regelweg; die QA-Freigabe bleibt strategisch und risikobasiert — nicht jedes Dokument, aber jede signifikante Entscheidung. Beide Stufen sind attributierte, auditierte Entscheidungen; eine autonome Freigabe gibt es nicht.
Monitor Quellengebunden statt frei erfunden Vorschläge sollen sich aus Ihren Infrastruktur-Policies, Build-SOPs und freigegebenen Templates speisen. Jede Citation wird deterministisch gegen diesen Pool geprüft; eine erfundene Quelle wird als Warnung sichtbar gemacht, nicht als Wahrheit ausgegeben.

Per Konstruktion

Was eine Building-Block-Qualifizierung strukturell absichern soll.

n

qualifiziert als Typ, verifiziert je Instanz

Der Building-Block soll einmal qualifiziert und jede Instanz gegen die Baseline abgeglichen werden. Die Audit-Frage „warum reicht der Abgleich statt erneuter Qualifizierung?“ wird am Datensatz beantwortbar — Kategorie 1: qualifiziert, nicht validiert.

Abweichung

wird sichtbar

Drift gegenüber der qualifizierten Baseline soll als Review-Fall erscheinen, nicht still verschwinden. Review-by-Exception lenkt die Aufmerksamkeit auf die Ausnahme — die Konformität trägt ihren Nachweis bereits.

0

stille KI-Schreibvorgänge

Kein Vorschlag soll ohne menschliche Freigabe in den Datensatz gelangen. Per Konstruktion — nicht per Disziplin. Dieses Prinzip gilt plattformweit; der Infrastruktur-Workflow darauf ist in Vorbereitung.

Status: in Vorbereitung. Dieser Use Case ist noch nicht verfügbar — Wert und Workflow sind geplant, nicht eine Live-Funktion. Die hier gezeigten strukturellen Eigenschaften beschreiben die geplante Disziplin auf der bestehenden traqx-Architektur; traqx qualifiziert keine Plattform und gibt keine Garantie für ein Audit-Ergebnis — aber eine bessere Vorbereitung. Belastbare Zeit- oder Kosteneffekte veröffentlichen wir erst mit echten Pilot- oder Case-Study-Daten.

Fragen aus der Praxis

Häufige Fragen zur IT-Infrastruktur-Qualifizierung

Muss IT-Infrastruktur validiert oder qualifiziert werden?

Qualifiziert: EU-GMP Annex 11 verlangt, dass IT-Infrastruktur qualifiziert wird — validiert werden die Applikationen, die darauf laufen. Der Unterschied bestimmt Prüftiefe und Dokumentation: Die Infrastruktur muss nachweislich kontrolliert betrieben werden, nicht jeden Anwendungsfall belegen.

Was zählt zur GxP-relevanten IT-Infrastruktur?

Server, Netzwerkkomponenten, Virtualisierung, Betriebssysteme, Datenbanken und Cloud-Basisdienste — die Plattform, auf der GxP-Applikationen laufen. GxP-relevant ist, was die Integrität, Verfügbarkeit oder Nachvollziehbarkeit regulierter Daten beeinflussen kann.

Wie qualifiziert man Cloud-Infrastruktur?

Über eine belastbare Lieferantenbewertung (etwa anhand von Zertifizierungen und Auditrechten), definierte Konfigurations-Baselines, die dokumentierte Verifizierung der eigenen Instanzen gegen diese Baselines und konsequentes Change Control. Die Verantwortung bleibt beim regulierten Unternehmen — auch in der Cloud.

Wie oft muss IT-Infrastruktur requalifiziert werden?

Änderungsgetrieben und risikobasiert: Jede relevante Änderung läuft über Change Control und wird gegen die Baseline verifiziert; periodische Reviews bestätigen den qualifizierten Zustand. Einmal sauber als Baustein qualifiziert, lässt sich jede Instanz gegen dieselbe Baseline belegen.

Weitere Disziplinen

Eine Plattform, viele Use Cases.

Gleiche Trust-Architektur — Quellen zuerst, KI als Vorschlag, Mensch entscheidet, Audit-Trail bleibt — über jede GxP-Disziplin.

Sicherheit & Standards · gebaut für nachvollziehbare Nachweise

Made in Germany DSGVO-konform · EU-gehostet Kein Modell-Training auf Ihren Daten
Gebaut fürGAMP 5EU-GMP Annex 1121 CFR Part 11ALCOA+
MitgliedschaftenISPEPDAGQMA

Gebaut von Compliance- & GxP-Experten · 15+ Jahre Domänen-Erfahrung

Pilot-Programm · IT-Infrastruktur in Vorbereitung · gemeinsamer Aufbau

Gestalten Sie die Plattform-Qualifizierung mit.

IT-Infrastruktur-Qualifizierung ist in Vorbereitung — und genau deshalb ist jetzt der richtige Moment. Bringen Sie einen realen Building-Block in den Pilot — etwa eine OS-Baseline oder ein Standard-VM-Image — und bauen Sie die Disziplin mit uns an Ihrem Standard auf, statt eine fertige Schablone übergestülpt zu bekommen.

Kein Sales-Pitch — ein kurzes Gespräch zu Ihrem konkreten Infrastruktur-Scope. IT-Infrastruktur-Qualifizierung bleibt als Roadmap-Use-Case klar markiert; wir prüfen gemeinsam, ob ein Aufbau-Pilot sinnvoll ist. Die Bewertung gehört Ihnen, auch wenn Sie danach Nein sagen; Quellenraum auf Wunsch nachweisbar löschbar.

Roadmap-Piloten nur, wenn wir den Scope mit voller Aufmerksamkeit begleiten können · Discovery in Reihenfolge des Eingangs