Navigation überspringen

SAP investiert in n8n — was das für regulierte Prozesse in der Pharmabranche bedeutet

Seit Juli 2025 steht Annex 22 im Raum — das erste dedizierte GMP-Regelwerk für künstliche Intelligenz in der Pharmaproduktion. Die Frage, die sich seitdem in Gesprächen mit IT-Leitern, Qualitätsverantwortlichen und Fachbereichsleitungen gleichermaßen stellt: Was bedeutet das konkret für bestehende Systeme und laufende KI-Piloten?

Seit Juli 2025 steht Annex 22 im Raum — das erste dedizierte GMP-Regelwerk für künstliche Intelligenz in der Pharmaproduktion. Die Frage, die sich seitdem in Gesprächen mit IT-Leitern, Qualitätsverantwortlichen und Fachbereichsleitungen gleichermaßen stellt: Was bedeutet das konkret für bestehende Systeme und laufende KI-Piloten? 

Die nüchterne Bestandsaufnahme: Die regulatorischen Anforderungen sind klar formuliert. Was fehlt, ist in vielen Unternehmen die Systemarchitektur, die deren Umsetzung ermöglicht. 

Am 12. Mai hat SAP auf der Sapphire-Konferenz in Orlando eine strategische Beteiligung an n8n bekanntgegeben — einem Berliner Unternehmen, dessen Workflow-Plattform ab Q3 2026 nativ in SAP’s Joule Studio eingebettet wird. Für die Finanzpresse war das eine Bewertungsnachricht (5,2 Mrd. USD, Verdopplung in sieben Monaten). Für die pharmazeutische Industrie hat die Meldung eine andere Tragweite: Sie markiert eine Architekturentscheidung, die direkt beeinflusst, wie Annex 22 in der Praxis umgesetzt werden kann. 

Der Zusammenhang erschließt sich über die regulatorischen Anforderungen selbst. 

Was Annex 22 von der Industrie verlangt 

Die EMA hat mit Annex 22 zum EU-GMP-Leitfaden erstmals ein regulatorisches Rahmenwerk geschaffen, das sich ausschließlich mit KI und Machine Learning in der Arzneimittelherstellung befasst. Die zentrale Weichenstellung: Der Annex unterscheidet strikt zwischen kritischen und nicht-kritischen GMP-Anwendungen — und zieht daraus unterschiedliche Konsequenzen. 

  1. Modelltyp-Beschränkung: In kritischen GMP-Anwendungen (mit direktem Einfluss auf Patientensicherheit, Produktqualität oder Datenintegrität) sind ausschließlich statische, deterministische Modelle zulässig. Probabilistische Modelle, dynamisch lernende Systeme, Generative AI und LLMs sind dort ausdrücklich ausgeschlossen — nicht eingeschränkt, sondern verboten. 
  2. Intended Use: Jedes KI-System erfordert eine dokumentierte Zweckbestimmung — Funktionsumfang, genutzte Daten, Einsatzbedingungen. Die Genehmigung erfolgt vor dem produktiven Einsatz, nicht rückwirkend. 
  3. Validierung über den Lebenszyklus: Keine einmalige IQ/OQ/PQ, sondern kontinuierliches Performance-Monitoring. Ändern sich Daten oder Modellparameter, muss die Validierung nachgeführt werden. 
  4. Human-in-the-Loop: Der Annex statuiert keine pauschale HITL-Pflicht für alle GxP-kritischen Prozesse. Ausreichend getestete, deterministische Modelle dürfen in kritischen Anwendungen autonom arbeiten. Eine explizite HITL-Pflicht gilt hingegen für den Einsatz von Generativer KI und LLMs in nicht-kritischen Anwendungen: Dort muss qualifiziertes Personal jede Ausgabe auf Eignung prüfen. 
  5. Explainability und Traceability: Modelle, die qualitätsrelevante Entscheidungen beeinflussen, müssen nachvollziehbar sein. Vollständige Rückverfolgbarkeit über Eingabedaten, Modellversion, Ergebnis und Freigabe ist durchgängig sicherzustellen. 

Das Konsultationsverfahren lief bis Oktober 2025. Die finale Veröffentlichung wird für 2026 erwartet. Die praktische Konsequenz ist bereits jetzt eindeutig: Unternehmen müssen ihre KI-Anwendungen klassifizieren — kritisch oder nicht-kritisch — und sicherstellen, dass in kritischen Prozessen ausschließlich statische, deterministische Modelle zum Einsatz kommen. 

Warum die SAP-Beteiligung an n8n regulatorisch relevant ist 

n8n ist eine Workflow-Plattform, die deterministische Automation mit agentischen KI-Fähigkeiten verbindet. Jan Oberhauser, Gründer und CEO, hat den Ansatz anlässlich der Bekanntgabe wie folgt beschrieben: „Manche Arbeit ist deterministisch — ein richtiger Ausgang, alles andere ist ein Fehler. Compliance-Checks, Abrechnungen, Datenupdates. Der Rest ist nicht-deterministisch: Ergebnisse, die durch Urteilsvermögen und Kontext geprägt sind.“ 

Aus regulatorischer Perspektive ist diese Unterscheidung keine Marketing-Formulierung. Sie spiegelt exakt die Grenze wider, die Annex 22 zieht — und die sich in der Praxis über drei Anwendungsfälle illustrieren lässt: 

  • Chargenfreigabe — eine kritische GMP-Anwendung mit direktem Einfluss auf Produktqualität und Patientensicherheit. Hier sind nach Annex 22 ausschließlich statische, deterministische Modelle zulässig. KI-Agenten, LLMs und probabilistische Systeme sind kategorisch ausgeschlossen — nicht unter Auflagen erlaubt, sondern verboten. Das System transportiert Daten deterministisch, ein validierter Prozess steuert, eine autorisierte Person signiert. 
  • Abweichungsanalyse — die Klassifizierung entscheidet. Wird die Root-Cause-Analyse als nicht-kritische Anwendung eingestuft, dürfen LLM-gestützte Werkzeuge einen Berichtsentwurf erstellen — unter striktem HITL: Qualifiziertes Personal prüft und dokumentiert jede Ausgabe. Die Bewertung, Korrektur und finale Verantwortung verbleibt beim Qualitätsverantwortlichen, dokumentiert durch elektronische Signatur. 
  • Validierungsdokumentation — ebenfalls eine nicht-kritische Anwendung, sofern der Entwurf keinen direkten Einfluss auf Freigabeentscheidungen hat. Ein maschinell erstellter Entwurf für eine Funktionale Spezifikation ist unter HITL vertretbar. Eine automatisch freigegebene FS ist es nicht. Entscheidend ist die korrekte Klassifizierung durch das Unternehmen. 

Dass SAP n8n — eine Plattform, deren Kern deterministische Workflow-Automation ist — in seinen KI-Stack integriert, hat über die Technologie hinaus eine strategische Aussage: In kritischen GMP-Prozessen braucht es deterministische Zuverlässigkeit, nicht agentische Flexibilität. Für nicht-kritische Anwendungen wiederum ermöglicht die Kombination mit Joule den kontrollierten Einsatz von LLM-gestützter Assistenz — unter den HITL-Bedingungen, die Annex 22 dafür vorsieht. Die Architektur trennt beide Welten sauber. 

Drei Fragen, die IT, QA und Fachbereich gemeinsam beantworten sollten 

Die konkreten Antworten fallen je nach Systemlandschaft und Reifegrad unterschiedlich aus. Die Fragen selbst gelten branchenübergreifend. 

Erstens: Wo endet der validierte Prozess — und wo beginnt die technische Integration? 

Die kostspieligsten Validierungsprobleme in der Praxis entstehen nicht durch ungeeignete Technologie. Sie entstehen durch fehlende Architektur-Grenzen. Wenn ein LIMS-Update dazu führt, dass der gesamte Chargenfreigabe-Prozess re-validiert werden muss, liegt die Ursache nicht im LIMS. Sie liegt in einer Architektur, die Fachlogik und technische Integration nicht sauber trennt. 

Die Lösung ist methodisch etabliert: Fachlogik (Entscheidungen, Freigaben, Eskalationen) gehört in eine orchestrierende Schicht mit eigenem Audit-Trail. Technische Datentransporte (Auslesen, Transformieren, Weiterleiten) gehören in eine gekapselte Integrations-Schicht. Ändert sich das eine, bleibt das andere stabil. 

Dass SAP n8n als genau diese Integrations-Schicht in seinen Stack aufnimmt, bestätigt dieses Architekturmuster auf Enterprise-Ebene. Die Grenzziehung innerhalb der eigenen Systemlandschaft bleibt jedoch eine Aufgabe, die jedes Unternehmen selbst leisten muss. 

Zweitens: Lassen sich für jeden KI-Einsatz in regulierten Prozessen die fünf Annex-22-Anforderungen belegen? 

Intended Use dokumentiert? Validierung über den Lebenszyklus geplant? HITL implementiert? Explainability gesichert? Traceability lückenlos? 

In der Beratungspraxis zeigt sich, dass die Mehrheit der Unternehmen drei von fünf Punkten belastbar beantworten kann. Die Lücken liegen regelmäßig bei der Lifecycle-Validierung (einmalig validiert, aber ohne Vorkehrung für Modell- oder Datenänderungen) und bei der Traceability über Systemgrenzen hinweg (der durchgängige Nachweis, welche Daten wann wohin geflossen sind, fehlt). 

Eine saubere Architektur-Trennung adressiert beide Lücken: Die orchestrierende Schicht sichert den Audit-Trail und damit die Traceability. Die Integrations-Schicht ist lokal qualifizierbar und re-testbar, ohne den Gesamt-Validierungsstatus zu gefährden. 

Drittens: Welche Vendor-Abhängigkeiten entstehen — und welche sind bewusst gewählt? 

SAP hält derzeit 1,3 % an n8n. n8n bleibt als Unternehmen unabhängig, das Fair-Code-Lizenzmodell besteht weiter, Self-Hosting ist möglich. Mercedes-Benz hat sich in der vergangenen Woche explizit wegen der digitalen Souveränität für n8n entschieden. 

Gleichwohl ist die Dynamik bekannt: Was heute eine Partnerschaft ist, kann sich mittelfristig zu einer Vollintegration entwickeln. Und Vollintegrationen bei SAP haben historisch eine wiederkehrende Konsequenz — steigende Kosten bei sinkendem Gestaltungsspielraum. 

Für regulierte Unternehmen hat das eine zusätzliche Dimension: Jede Vendor-Abhängigkeit in einem validierten Prozess erhöht den Change-Control-Aufwand bei Lizenzänderungen, Preisänderungen oder erzwungenen Upgrades. Wer diese Entscheidung heute bewusst trifft — n8n innerhalb des SAP-Stacks oder als eigenständige Komponente — vermeidet in der Zukunft kostspielige Nachrüstungen. 

 

Einordnung: Es geht nicht um SAP oder n8n 

Die gestrige Meldung lässt sich in einen größeren Kontext einordnen: Die Enterprise-Software-Industrie hat akzeptiert, dass KI in regulierten Prozessen nur dann funktioniert, wenn sie in eine Governance-Architektur eingebettet ist. 

Nicht „KI ersetzt den Prozess“. Nicht „KI entscheidet schneller“. Sondern: 

In kritischen Anwendungen gehören ausschließlich deterministische, validierte Modelle. 
In nicht-kritischen Anwendungen kann KI assistieren — unter menschlicher Aufsicht und dokumentierter Verantwortung. 

Das ist die Differenzierung, die Annex 22 einfordert. Und es ist die Differenzierung, die eine Systemarchitektur abbilden können muss — nicht als nachträgliche Governance-Schicht, sondern als strukturelle Grundlage. IT-Leitung, Qualitätssicherung und Fachbereiche sollten diese Grenzziehung als gemeinsame Aufgabe verstehen: Technologie im Dienst der Compliance, nicht als Ersatz dafür. 

Die Werkzeuge dafür werden gerade besser. Die Frage ist, ob die Architekturen bereit sind, sie angemessen einzusetzen.