GxP-konform und trotzdem nutzbar: Warum Compliance kein Datenproblem ist
Florian Seidl
Florian Seidl, cts Group
BU Manager Industrieinformatik · · 8 Min. Lesezeit

GxP-konform und trotzdem nutzbar: Warum Compliance kein Datenproblem ist

In der regulierten Produktion ist der erste Reflex, Daten wegzusperren. Doch das Ziel ist nicht weniger Datenfluss — es ist nachvollziehbarer Datenfluss. Wie Daten die validierte Anlage verlassen, ohne sie anzufassen, und warum das eine Frage der Architektur ist.

Ein Beispiel, das in fast jedem Werk vorkommt: Ein Prozessingenieur will die letzten 90 Tage eines kritischen Temperatur- und Druck-Tags einer validierten Verpackungslinie auswerten, um wiederkehrende Mikrostopps zu verstehen. Die Reaktion von Qualitätssicherung und Validierung ist berechtigt vorsichtig — Finger weg vom validierten System, jede Änderung zieht eine Re-Qualifizierung nach sich. Also werden die Werte einmal manuell nach Excel exportiert. Und die Analyse stirbt im Formatieren.

Die Daten waren da. Das Hindernis war die Annahme, dass man das validierte System anfassen muss, um an sie heranzukommen.

Denn Daten wegzusperren ist nicht dasselbe, wie Daten zu schützen. Der Verschluss löst kein Compliance-Problem — er verlagert es nur in manuelle Auswertungen, Medienbrüche und Berichte, die niemand nachvollziehen kann. Ausgerechnet die Datenintegrität, die geschützt werden soll, leidet unter dem manuellen Umweg am meisten.

Kennen Sie diesen Moment aus dem eigenen Werk? Dann lohnt sich die Frage, ob die Vorsicht wirklich dem validierten System gilt — oder einer Annahme darüber, wie man an seine Daten kommt.

Was die Regulatorik wirklich verlangt

GxP (Good x Practice — der Sammelbegriff für gute Praxis in Herstellung, Labor und Klinik) und 21 CFR Part 11 (die FDA-Regel für elektronische Aufzeichnungen und Signaturen) verlangen keine Datenstille. Sie verlangen nachvollziehbare, zuordenbare und rückverfolgbare Aufzeichnungen.

Die Kernfrage von 21 CFR Part 11 ist die Vertrauenswürdigkeit elektronischer Aufzeichnungen: Wer hat wann was geändert, und lässt sich das lückenlos belegen? Compliance ist damit eine Frage von Herkunft und Verantwortung — nicht von Isolation.

Der eigentliche Denkfehler ist, „compliant" gegen „nutzbar" auszuspielen. Die Regulatorik verlangt Nachvollziehbarkeit, nicht Stillstand. Sobald Herkunft, Audit-Trail und Verantwortung in der Datenschicht selbst verankert sind, verschwindet der vermeintliche Zielkonflikt.

Wie Daten die validierte Anlage verlassen, ohne sie anzufassen

Der Schlüssel liegt in einer Schicht, die neben OT (Operational Technology, die Technik der Produktion) und IT (Information Technology) sitzt — nicht in ihnen. Tools wie AspenTech inmation sind so eine Konnektivitätsschicht. Sie bildet ein Fundament zwischen IT und OT, ist aber kein Prozessleitsystem, kein SCADA (Supervisory Control and Data Acquisition) und kein MES (Manufacturing Execution System) — und ersetzt keines davon. Welches Werkzeug am Ende zum Einsatz kommt, hängt vom Bestand ab; entscheidend ist das Prinzip, nicht das Produkt.

Das Prinzip heißt read-only und out-of-band. Die Schicht abonniert Daten, statt in die Steuerung einzugreifen: Sie liest Tag-Werte, zapft den Historian an, hört auf Nachrichten — aber sie sendet keine Steuerbefehle zurück an SPS oder Leitsystem. Die validierte Logik und ihre Konfiguration bleiben Byte für Byte unverändert. Damit wird kein Auslöser für eine Re-Validierung erzeugt.

Angebunden wird über die etablierten industriellen Schnittstellen — OPC UA und OPC DA, wo vorhanden, dazu Historian-Schnittstellen und Message-Broker. Fehlt einer Quelle eine native Standardschnittstelle, liest ein eigener Treiber sie aus, ohne die Quelle zu verändern. Und wo Rohwerte schon an der Kante normalisiert oder angereichert werden sollen, übernimmt das ein leichtgewichtiges Skript direkt auf der Komponente (etwa in Lua) — statt zusätzlicher Middleware obendrauf.

1
Qualifizierter Einmal-Eingriff. Eine Komponente wird einmalig auf einer virtuellen Maschine (VM) aufgesetzt — in CSV-Logik (Computerized System Validation) ein dokumentierter IQ/OQ-Schritt (Installation und Operational Qualification), danach abgeschlossen.
2
Read-only-Erfassung. Prozess- und Historiendaten werden über Standardschnittstellen (OPC UA, Historian-API) oder einen eigenen Treiber gelesen — nie zurückgeschrieben. Die Quelle bleibt unberührt.
3
Zentrale Verwaltung, out-of-band. Die laufende Verwaltung passiert zentral, außerhalb der validierten Umgebung — kein wiederkehrender Fernzugriff (RDP) in die Anlage. Genau das, was Auditoren ungern sehen, entfällt.

Datenintegrität ist Engineering, nicht Papier

Nachvollziehbarkeit ist keine nachträgliche Funktion, sondern eine Eigenschaft der Erfassung selbst. Die anerkannten Datenintegritätsprinzipien der Aufsichtsbehörden — ALCOA (attributable, legible, contemporaneous, original, accurate) — lassen sich direkt auf konkrete Mechanismen der Datenschicht abbilden, statt sie später über Systemgrenzen hinweg zusammenzusuchen.

ALCOA-Prinzip Technischer Mechanismus
Attributable
zuordenbar
Jeder Wert trägt seine Quell-Tag-Kennung; jede Konfigurationsänderung wird mit Nutzer und Zeit protokolliert.
Legible
lesbar & dauerhaft
Prüffähiges, maschinen- und menschenlesbares Logging aller System- und Konfigurationsänderungen.
Contemporaneous
zeitgleich
Der Zeitstempel entsteht bei der Erfassung an der Quelle — nicht erst beim Import ins Zielsystem.
Original
Rohwert erhalten
Store-and-Forward puffert bei Netzunterbrechung; der Rohwert der Quelle bleibt erhalten — keine Lücken, keine nachträgliche Interpolation.
Accurate
korrekt & konsistent
Eine verlässliche Quelle (Single Source of Truth) für historische und einlaufende Tag-Daten — keine widersprüchlichen Kopien.

Der Audit-Trail läuft quer über all das: Er erfasst jede System- und Konfigurationsänderung nachvollziehbar und unveränderbar — Accountability by design, nicht als aufgesetztes Protokoll. [FACHLICHE PRÜFUNG: ALCOA-Zuordnung und Store-and-Forward-Formulierung von Florian Seidl bestätigen lassen — technische Einordnung der Redaktion, nicht wörtlich aus dem Interview.]

Kontext macht aus einem Wert eine prüfbare Aufzeichnung

Datenintegrität endet nicht bei der sauberen Erfassung. Ein Rohwert wie TT_1042 = 21,4 ist für sich genommen wertlos — und im Audit nicht verteidigbar. Erst die Bindung an Equipment, Batch, Prozessschritt und Standort macht daraus eine Aussage: dieser Wert, von diesem Asset, in diesem Batch, an diesem Prozessschritt.

Hier hilft ein sauberes Datenmodell nach ISA-95 (der Standard ANSI/ISA-95 bzw. IEC 62264 zur Strukturierung von Fertigungsdaten über die Ebenen Unternehmen, Standort, Bereich, Linie und Equipment). Die Konnektivitätsschicht ordnet die Rohdaten in diese Hierarchie ein — aus einer Zahl wird ein Datensatz mit Herkunft. Damit fallen „nutzbar" und „prüfbar" zusammen, statt sich zu widersprechen.

Lokale Compliance, zentrale Daten — die Architektur

Der eigentliche Unterschied ist architektonisch. Es ist kein globaler Rollout, bei dem an jedem Standort dieselbe Software installiert wird und isoliert läuft.

Stattdessen betreibt jeder Standort seine eigene, autonome Instanz der Datenschicht: technisch selbstständig, unabhängig betreibbar. Alle Instanzen verbinden sich zu einer zentralen, globalen Ebene. Ein System, unternehmensweit — statt vieler isolierter Einzelinstallationen.

⚠ Der klassische Weg

Üblich sind ein separater Historian und ein separates MES pro Standort — jede Insel für sich, jede Compliance-Diskussion von vorn. Die Daten bleiben lokal gefangen, oder man dupliziert Infrastruktur, um sie zusammenzuführen.

Im beschriebenen Modell bleibt die Compliance lokal intakt, während die Daten trotzdem zentral fließen. Regulatorik und Standort-Autonomie bleiben, wo sie hingehören — und die unternehmensweite Sicht entsteht darüber, nicht dagegen.

Deshalb ist Compliance ein Kontextproblem, kein Datenproblem

Die Daten waren nie das Hindernis. Das Hindernis war eine Architektur, die zur Wahl zwang: compliant oder nutzbar. Sobald Herkunft, Audit-Trail und Verantwortung Teil der Konnektivitätsschicht sind, entfällt diese Wahl. Compliance wird zur Eigenschaft der Architektur — nicht zum Grund, Daten einzusperren.

Ob das in Ihrem regulatorischen Umfeld genauso trägt, hängt von Ihren Systemen und Ihrer Validierungsstrategie ab — eine pauschale Antwort gibt es hier nicht. Genau solche Fälle schauen wir auf der Pharma MES Europe lieber konkret an, als sie im Blog zu verallgemeinern.

Aus der Praxis: In 18 Jahren OT-Integration ist mir der Re-Validierungs-Einwand hundertfach begegnet — und er ist berechtigt. Genau deshalb zählen „lesen statt schreiben" und der einmalige, dokumentierte Eingriff: Das validierte System bleibt, wie es ist — die Datenschicht liegt daneben, nicht darin.

Weiterlesen · Teil 3 der Serie

Warum MES-Projekte scheitern — und es meistens nichts mit dem MES zu tun hat

Wenn die Technik nicht das Problem ist: woran Datenprojekte in der Pharma wirklich scheitern — aus Sicht der Projektleitung.

Zum Beitrag →

Wir sprechen darüber auf der Pharma MES Europe 2026

cts Group und Xenium AG zeigen in Berlin, wie GxP-Daten nutzbar werden, ohne die Validierung zu gefährden — von der Architektur bis zur laufenden Anlage.

Termin am Stand vereinbaren