Das Problem
GxP-Prozesse überschreiten regelmäßig Systemgrenzen. Das Problem entsteht nicht beim Übergang — es entsteht in der Art, wie Systeme und Integration üblicherweise eingeführt werden.
01
Standardsoftware wird üblicherweise von der Funktion her eingeführt: Aus den verfügbaren Transaktionen wird ein Systemprozess abgeleitet. Der durchgängige Geschäftsprozess über Systemgrenzen tritt dabei in den Hintergrund — er ist nirgends ausführbar modelliert und damit nicht auditierbar.
02
Klassische Integrationsmiddleware übernimmt schleichend Routing- und Entscheidungslogik. Sie wird zum zweiten, nicht modellierten Agenten im Prozess — einer, dessen Entscheidungen weder im BPMN-Modell sichtbar noch im Audit-Trail nachvollziehbar sind. Genau das ist im regulierten Umfeld nicht akzeptierbar.
03
KI-Werkzeuge werden auf bestehende Systemlandschaften aufgesetzt — als Schicht, die Ergebnisse produziert, ohne dass der Prozessrahmen davor und danach determiniert ist. Das Ergebnis ist ein nicht-deterministischer Schritt ohne klare Eingabemenge, ohne erzwungene menschliche Freigabe, ohne auditierbaren Lebenszyklus.
Regulatorische Konsequenz
Annex 11 verlangt, dass jede qualitätsrelevante Entscheidung nachvollziehbar ist — wer hat was auf welcher Grundlage entschieden. Der Annex-22-Entwurf zieht für KI-Systeme eine Grenze: Generative KI und Large Language Models sollen in kritischen GMP-Anwendungen nicht eingesetzt werden; der Entwurf nimmt sie aus seinem Anwendungsbereich aus. Nicht-deterministische Schritte halten wir deshalb aus qualitätsbestimmenden Entscheidungen heraus — oder wir gestalten ihren Rahmen so, dass die Entscheidungsverantwortung nachweislich beim Menschen liegt.
Das klassische Middleware-Modell erfüllt keine dieser Anforderungen systematisch: Es produziert Übergaben ohne Entscheidungsmodell, Integration ohne Lebenszyklus, und KI-Ergebnisse ohne deterministischen Rahmen. Das Problem ist nicht der Einsatz von Middleware oder KI — es ist die fehlende Autorität einer einzigen, auditierbaren Instanz über den Gesamtprozess.
Wenn Middleware routet und die Routing-Logik nicht im Prozessmodell steht, ist die Entscheidung nicht auditierbar — auch wenn das Ergebnis korrekt ist.
Ein BPMN-Prozessmodell ohne ausführbare Engine ist eine Dokumentation, kein Steuerungsinstrument. Was ausgeführt wird, folgt dann dem Systemfluss — nicht dem Modell.
KI-Schritte in einem nicht-modellierten Ablauf erzeugen Ergebnisse ohne nachvollziehbare Entscheidungsbasis. Die Lücke entsteht im Prozessdesign — lange bevor ein Audit sie findet.
Der Audit-Trail beginnt nicht beim Systemergebnis. Er muss den gesamten Lebenszyklus abdecken: welche Eingabe, welche Verarbeitung, welche menschliche Freigabe, welches Ergebnis.
Das Grundprinzip
Die Lösung für das Middleware-Problem ist keine neue Middleware. Es ist eine Architektur, in der jede Schicht eine klar definierte Autorität hat — und in der die Orchestrierungsschicht die Entscheidungshoheit über den Gesamtprozess nicht abgibt.
Schicht 1 · Orchestrierung
Die BPMN-Engine führt den gesamten E2E-Ablauf als ausführbares Modell. Sie hält den Lebenszyklus, kontrolliert die Freigabe-Gates und ist die führende Audit-Klammer — sichtbar, modelliert, prüfbar.
Camunda 8
Schicht 2 · Integration
Ruft Zielsysteme auf und liefert Ergebnisse zurück — ohne eigene Entscheidungslogik. Verzweigungen und Bedingungen gehören in die Orchestrierungsschicht, nicht hier. Das ist eine Baupflicht, kein Detail.
n8n
Schicht 3 · KI
KI-Funktionen sitzen an klar abgegrenzten Schritten. Davor: eine deterministische Wissensbasis legt die Eingabemenge fest. Danach: ein erzwungenes menschliches Freigabe-Gate. Das Modell entscheidet nichts, was den Prozess unkontrolliert weiterträgt.
LLM + HITL-Gate
„Die Sicherheit der KI entsteht aus dem Rahmen — nicht als Aufsatz auf ihn."
Das ist der Beweiswert der Architektur: Das Risiko des nicht-deterministischen Schritts wird durch das Design eingegrenzt, bevor gebaut wird — nicht nachträglich validiert.
Anwendungsbeispiel
Change Management berührt typischerweise ERP, MES und eQMS gleichzeitig — mit unterschiedlichen Freigabestufen, Zuständigkeiten und Dokumentationsanforderungen. Ohne ausführbares Prozessmodell wird die Koordination zur Quelle von Compliance-Lücken.
Das Beispiel ist als Normal Change (vollständiger Genehmigungspfad) dargestellt. Unterschiedliche Change-Typen unterscheiden sich ausschließlich im Prozessablauf — nicht in der Systemarchitektur. Dass unterschiedliche Governance allein durch das Prozessmodell abbildbar ist, ohne neuen Code, ist ein eigenständiger Beleg der Architekturthese.
Warum Significon
Wir kommen aus dem GxP-Umfeld — Validation, Qualifizierung, regulatorische Anforderungen sind kein Aufschlag auf das Projekt, sondern Ausgangspunkt. Den Showcase auf dieser Seite bauen wir selbst und intern: Camunda, n8n, Systemintegration. Er ist im Bau und nicht fertig; was hier steht, ist am Bauen entstanden und nicht an einer Folie.
Einen PoC führen wir nach denselben Phasen wie ein reguläres Vorhaben: Scoping, Design, Build, Deploy. Das ist konsequent zur Grundthese — Struktur trägt Konformität. Der PoC lebt das Prinzip vor, das er belegt. Er ist ein abgegrenzter erster Schritt an einem echten Prozess; was danach kommt, entscheidet sein Ergebnis und nicht dieses Angebot.
Die Systemkomponenten unterhalb der Orchestrierungsschicht sind austauschbar — ERP, MES, LLM-Modell. Das Architekturelement, das nicht ausgetauscht werden kann, ist die Disziplin: Die Entscheidungshoheit bleibt in der Orchestrierungsschicht. Das gilt für jede konkrete Systemlandschaft.
Einordnung
Wie wir arbeiten — die vier Arbeitsprinzipien →
Woran dieser Showcase hängt — und wo für ein Feld heute keine Methode niedergeschrieben ist
Verwandter Beleg
KI-Validierung & EU GMP Annex 22 — regulatorischer Rahmen →
Warum der deterministische Rahmen die regulatorische Grundlage für KI-Einsatz ist
Ist prozesszentrische Orchestrierung für Ihre Systemlandschaft der richtige Ansatz?
Wir klären das im ersten Gespräch — ohne Pitch.