Das KI-Digitalisierungs-Fax Effizienz-Booster oder Compliance-Risiko? Wie KI ins QMS darf

Anbieter zum Thema

M&M Software GmbH

KUMAVISION AG

ConSense GmbH

Metecon GmbH

Darf KI im QMS, im Regulatory Affairs oder im Einkauf überhaupt eingesetzt werden? Im zweiten Teil der Kolumne „Das KI-Digitalisierungs-Fax“ zeigt sich: Die Frage nach der Erlaubnis ist meist schon beantwortet – nur hat es niemand dokumentiert.

Es ist Dienstagnachmittag, CAPA-Review. Die Qualitätsmanagerin stellt eine Wirksamkeitsbewertung vor, die auffällig sauber formuliert ist. Struktur, Sprache, Argumentation – deutlich besser als das, was sonst im Umlauf ist. Jemand fragt nach: Woher kommt der Text? Kurze Pause. Dann: „Ich habe mir einen Entwurf generieren lassen und ihn überarbeitet.“

Im Raum entsteht genau das Schweigen, das man aus Audits kennt. Niemand weiß, ob das gerade ein Problem war. Der QMB weiß es nicht. Der Regulatory-Kollege weiß es nicht. Die Geschäftsführung erfährt es ohnehin erst später.

Was in diesem Moment sichtbar wird, ist nicht ein Regelverstoß. Es ist eine Lücke. Die Technologie ist bereits im Unternehmen – über Browser-Tabs, Office-Abonnements, private Konten, Übersetzungswerkzeuge. Sie wird oft benutzt, weil sie direkt hilft. Sie taucht nur in keinem Prozessdokument auf. Das ist der eigentliche Status quo in den meisten Medtech-Unternehmen: nicht verbotene KI, sondern unbeschriebene KI.

Die falsche Frage – und die Frage, die wirklich zählt

„Darf man das?“ ist die Frage, die in Workshops als Erstes kommt. Sie ist verständlich, aber sie führt in die Irre, weil sie zwei völlig verschiedene Dinge vermischt:

• Ist der Einsatz zulässig? Das ist eine Rechtsfrage.
• Ist der Einsatz beherrscht? Das ist eine QM-Frage.

Die Rechtsfrage ist in den allermeisten Fällen schnell beantwortet: Ja, der Einsatz ist zulässig. Ein KI-Werkzeug, mit dem Sie intern einen SOP-Entwurf schreiben, Reklamationstexte gruppieren oder eine Lieferantenbewertung vorstrukturieren, ist nach der KI-Verordnung im Regelfall kein Hochrisiko-KI-System. Es ist kein Sicherheitsbauteil eines Medizinprodukts, und es fällt nicht unter die eigenständigen Hochrisiko-Anwendungsfälle nach Anhang III. Der AI-Omnibus, seit dem 27. Juli 2026 in Kraft, hat die Hochrisiko-Einstufung zudem enger gefasst und die zugehörigen Pflichten deutlich nach hinten verschoben – für eigenständige Anhang-III-Systeme auf den 2. Dezember 2027, für KI, die in regulierte Produkte wie Medizinprodukte eingebettet ist, auf den 2. August 2028.

Genau diese Verschiebung wird gerade breit als Entwarnung gelesen. Ist sie nicht. Denn die Pflicht, die für interne KI im QMS tatsächlich greift, stand nie im AI Act. Sie steht in einer Norm, die Sie seit Jahren anwenden.

ISO 13485, Abschnitt 4.1.6 – die Vorschrift, die niemand erwartet hat

Die ISO 13485:2016 verlangt in Abschnitt 4.1.6, dass die Anwendung von Computersoftware, die im Qualitätsmanagementsystem verwendet wird, validiert wird – vor der ersten Nutzung und nach Änderungen, mit einem Aufwand, der dem Risiko angemessen ist. Es steht dort nichts von „außer bei KI“. Und es steht dort auch nichts von „nur bei gekauften Systemen“.

Damit ist die Sachlage klar: Sobald ein KI-Werkzeug regelmäßig und prozessgebunden in QM-relevanten Abläufen eingesetzt wird, ist es Software im QMS. In den USA gilt seit dem 2. Februar 2026 dieselbe Logik über die Quality Management System Regulation (QMSR), die die ISO 13485 in 21 CFR 820 einbezieht; die FDA hat ihre CSA-Leitlinie im Februar 2026 entsprechend aktualisiert.

Das ist die unbequeme Pointe für alle, die gerade auf die verschobenen AI-Act-Fristen schauen: Der Regelungsrahmen, der Ihre interne KI-Nutzung erfasst, ist längst in Kraft – und Sie haben ihn sogar schon zertifiziert.

CSA statt CSV: Warum das alte Validierungsdenken hier nicht funktioniert

Wer „Validierung“ hört, denkt reflexhaft an das klassische CSV-Paket: IQ, OQ, PQ, Testskripte, Screenshots, Unterschriftenlisten. Bei einem sprachbasierten KI-Assistenten läuft dieses Denken ins Leere, und zwar aus einem einfachen Grund: Das System ist nicht deterministisch. Zweimal derselbe Prompt kann zwei unterschiedliche Formulierungen erzeugen. Ein Testfall mit „erwartetes Ergebnis = exakter Textstring“ ist damit sinnlos.

Der Computer-Software-Assurance-Ansatz, den die FDA im September 2025 final veröffentlicht und Anfang 2026 an die QMSR angepasst hat, bietet hier den passenderen Denkrahmen. Er verschiebt die Frage von „Haben wir genug getestet?“ zu „Was passiert, wenn dieses Feature falsch arbeitet – und wer merkt es?“. Maßgeblich sind der Verwendungszweck und das Prozessrisiko; nur Funktionen mit hohem Prozessrisiko rechtfertigen skriptbasierte Tests, alles andere kommt mit schlankeren Methoden aus. Und ausdrücklich erwünscht ist, Lieferantenbewertungen und digitale Aufzeichnungen zu nutzen, statt Dokumentation neu zu produzieren.

Übertragen auf KI heißt das: Sie validieren nicht das Modell. Sie sichern den Prozess ab, in dem das Modell einen Beitrag leistet. Nachweisgegenstand ist nicht die Richtigkeit einer einzelnen Antwort, sondern die Wirksamkeit der Kontrolle, die eine falsche Antwort abfängt.

Human-in-the-Loop: Sicherheitsnetz oder Feigenblatt?

Genau hier liegt der Punkt, an dem in der Praxis am meisten schiefgeht. „Ein Mensch prüft das ja noch.“ ist die Standardantwort auf jede Nachfrage, aber in vielen Unternehmen ist sie nicht wirklich belastbar.

Ein „Human-in-the-Loop“ wirkt nur unter drei Bedingungen:

1. Die prüfende Person ist fachlich in der Lage, den Fehler zu erkennen. Wer eine KI-generierte Risikobewertung freigibt, muss die Risikobewertung selbst beherrschen. Sonst prüft er die Sprachqualität, nicht den Inhalt.
2. Sie hat die Zeit und den Auftrag, tatsächlich zu prüfen. Eine Freigabe, die im Prozess drei Sekunden dauert, ist keine Prüfung. Sie ist eine Signatur.
3. Sie ist nicht durch die Qualität der Darstellung geblendet. Flüssig formulierte, selbstsicher vorgetragene Fehler werden seltener entdeckt als holprig formulierte, das ist auch bei Menschen so. Dieser Effekt – in der Human-Factors-Literatur auf KI-bezogen als Automation Bias beschrieben – ist bei generativer KI besonders ausgeprägt, weil sprachliche Souveränität und inhaltliche Korrektheit hier vollständig entkoppelt sind.

Wer den „Human-in-the-Loop“ als regulatorisches Sicherheitsnetz anführt, muss ihn auch entsprechend als Kontrolle ausgestalten: mit definierten Prüfkriterien, mit benannter Rolle, mit dokumentiertem Ergebnis. Alles andere ist eine Behauptung, die im Audit genau eine Nachfrage überlebt.

Ein „Human-in-the-Loop“, der nicht befähigt, beauftragt und dokumentiert ist, ist keine Kontrolle – er ist eine Signatur.

Entscheidungsbaum: Muss diese KI validiert werden?

Fünf Fragen in dieser Reihenfolge ersetzen keine Verfahrensanweisung, aber sie klären in zehn Minuten, worüber wir eigentlich reden.

1. Fließt der Output in ein regulatorisches Artefakt oder in eine QM-relevante Entscheidung ein?
Nein → kein Validierungsthema. Recherche, Ideensammlung, interne Zusammenfassungen ohne Weiterverwendung bleiben ein freies Feld. 
Ja → weiter.

2. Wird das Werkzeug wiederholt und prozessgebunden eingesetzt?Einmalige, spontan erfolgte Nutzung durch eine Einzelperson ist etwas anderes als ein fest im Ablauf verankerter Schritt. Erst die Prozessbindung macht aus einem Werkzeug „Software im QMS“ im Sinne von Abschnitt 4.1.6 der ISO 13485:2016.

3. Was passiert, wenn der Output falsch ist – und wann fällt es auf?Diese Frage bestimmt das Prozessrisiko. Ein fehlerhafter SOP-Entwurf, der drei Review-Schleifen durchläuft, ist etwas anderes als eine fehlerhafte Vorbewertung, ob eine Reklamation meldepflichtig ist.

4. Gibt es eine wirksame, dokumentierte menschliche Kontrolle vor der Verwendung?Wenn ja, verschiebt sich der Nachweisaufwand von der Technik auf den Prozess. 
Wenn nein, ist das Feature faktisch autonom und der Aufwand steigt erheblich.

5. Ist die Nutzung rekonstruierbar?Wissen Sie im Zweifel noch, welches Werkzeug in welcher Version, mit welcher Eingabe, zu welchem Zeitpunkt beteiligt war? Wenn nicht, haben Sie kein Validierungsproblem, sondern ein Rückverfolgbarkeitsproblem – und das ist das teurere.

Governance-Minimum für KMU: fünf Festlegungen, eine Seite

Ein kleines oder mittelständisches Medizintechnikunternehmen braucht in der Regel kein KI-Managementsystem nach ISO/IEC 42001, um handlungsfähig zu werden. Es braucht fünf wichtige, dokumentierte Entscheidungen:

1. Inventar. Welche KI-Werkzeuge werden im Unternehmen genutzt, von wem, wofür? Diese Liste zu erstellen, dauert einen Vormittag und ist regelmäßig die größte Überraschung des Quartals.
2. Drei Freigabestufen. Frei nutzbar / nutzbar mit dokumentierter Prüfung / nicht zulässig. Mehr Differenzierung braucht niemand am Anfang, weniger ist zu wenig.
3. Datenregel. Was darf in welches Werkzeug eingegeben werden? Konstruktionsdaten, Reklamationstexte mit Patientenbezug, Auditberichte, Vertragsinhalte? Da entstehen die Risiken, die kein QM-Auditor, sondern der Datenschutzbeauftragte, der Kunde oder der Marktbegleiter im Internet findet.
4. Kennzeichnungsregel. Wie wird im Dokument sichtbar, dass KI beteiligt war und wer inhaltlich geprüft hat? Ein Feld im Dokumentenkopf genügt.
5. Eine verantwortliche Person. Nicht ein Gremium. Eine Person mit Namen, die die Liste pflegt und die Stufen vergibt. Es muss nicht gleich ein CAIO (Chief Artificial Intelligence Officer) sein.

Diese fünf Punkte passen auf eine Seite und sind in bestehende QM-Prozesse integrierbar. Das Rollenmodell dahinter – AI Owner, Risk Owner, Data Owner – behandeln wir in der fünften Ausgabe dieser Kolumne.

Drei risikoarme Einstiegsfelder – und drei, die es nicht sind

Gut geeignet:

• Clustering von Reklamationen und Complaints als Vorstrukturierung für die Trendanalyse. Die KI schlägt Gruppen vor, der Mensch entscheidet über die Trendbewertung.
• Erstentwürfe für Verfahrensanweisungen und Schulungsunterlagen. Das Ergebnis durchläuft ohnehin ein etabliertes Review.
• Vorsortierung von Literatur- und Regulatory-Monitoring-Treffern. Relevanz-Vorschlag statt Relevanz-Entscheidung, mit dokumentierter Nachprüfung der Ausschlüsse.

Nicht geeignet – auch wenn es verlockend aussieht:

• Die Entscheidung über die Meldepflicht eines Vorkommnisses. Hier hängt eine gesetzliche Frist an einer Bewertung. Vorbereitung ja, Entscheidung nein.
• Übersetzungen von Gebrauchsanweisungen und Kennzeichnung ohne fachliche Freigabe. Diese Texte sind regulatorischer Inhalt, nicht (nur) Kommunikation.
• Die abschließende Klassifizierung oder Abgrenzungsentscheidung. Wer die Zweckbestimmung von einem Sprachmodell formulieren lässt, verlagert die folgenreichste Entscheidung des gesamten Lebenszyklus in eine Blackbox.

Die ehrliche Antwort auf die Ausgangsfrage lautet: Ja, KI darf im QMS, im Regulatory Affairs und im Einkauf eingesetzt werden. Sie wird es längst. Was fehlt, ist nicht die Erlaubnis, sondern der beschriebene Rahmen – und der Nachweis, dass sich jemand um die Ergebnisse kümmert (und diese verantwortet).

Wer daraus ableitet, man müsse KI erst einmal verbieten, bis die Governance steht, wird beides verlieren: die Produktivität und die Kontrolle. Denn ein Verbot, das niemand durchsetzen kann, erzeugt exakt das, was heute schon existiert: Nutzung ohne Überblick und Steuerung.

Und es gilt weiterhin, was wir in der ersten Ausgabe dieser Kolumne festgehalten haben: Ein KI-Assistent in einer Prozesslandschaft voller Medienbrüche beschleunigt nicht die Arbeit, sondern meistens nur die Fehler. Die Reihenfolge bleibt also dieselbe: erst Struktur, dann Daten, dann KI. Nur die Ausrede, man müsse auf regulatorische Klarheit warten, ist mit dem Blick in Abschnitt 4.1.6 der ISO 13485:2016 endgültig unbrauchbar.

Das KI-Digitalisierungs-Fax

Warum wir 2026 noch faxen – nur eben digital