Änderungsmanagement für Produktakten automatisieren

Das echte Ausmaß des Problems

Das Änderungsmanagement ist eine häufige Quelle für Befunde bei Notified-Body-Audits in der Medizintechnik. Nicht weil Hersteller die Anforderungen nicht kennen, sondern weil die Umsetzung aufwendig und fehleranfällig ist.

Ein Medizinprodukte-KMU mit einem oder zwei Klasse-IIa/IIb-Geräten bearbeitet nach unserer Annahme 20–50 Change Events im Jahr. Dazu zählen Lieferantenwechsel, Materialsubstitutionen, Software-Updates, Designoptimierungen und Prozessänderungen in der Fertigung. Für jede dieser Änderungen gilt: Sie muss bewertet und dokumentiert werden. Was danach folgt, hängt am Zertifikat. Bei Produkten mit MDR-Zertifikat informiert der Hersteller die Benannte Stelle über geplante wesentliche Änderungen, und Änderungen, die Sicherheit, Leistung oder Anwendungsbedingungen beeinträchtigen könnten, braucht es deren Genehmigung vorab (MDR Anhang IX Abschnitte 2.4 und 4.10). Bei Altprodukten, die mit MDD-Zertifikat unter Art. 120 MDR weiter in Verkehr gebracht werden, entscheidet MDCG 2020-3, ob die Änderung signifikant ist. Ist sie es, endet die Übergangsregel für dieses Produkt.

Der Aufwand pro Change Assessment liegt nach unserer Annahme bei einem halben bis drei Arbeitstagen, abhängig von der Komplexität des Geräts und der Vollständigkeit des Technical Files. Bei 35 Change Events im Jahr sind das 17 bis 105 Arbeitstage, also rund 3 bis 21 Wochen, ohne die eigentliche Implementierung und Dokumentationspflege zu rechnen.

Das strukturelle Problem ist die Fragmentierung. Das Technical File liegt in einem eQMS oder auf einem Netzlaufwerk. Die FMEA ist ein Excel-Dokument. Die Verifikationsprotokolle liegen in einem anderen Ordner. Die betroffenen Dokumente manuell zu identifizieren und zu verlinken ist das, was den Großteil der Zeit kostet.

Ein weiteres Problem ist die Grauzone bei der Klassifikation. MDCG 2020-3 bietet Orientierung durch sechs Flowcharts, aber die Grenzen zwischen signifikant und nicht-signifikant sind bei komplexen Änderungen interpretationsbedürftig. Das Johner Institut stellt in seiner regulatorischen Praxisdokumentation (2024) fest, dass Praktiker dabei systematisch drei verschiedene Bewertungsebenen verwechseln: die allgemeine QMS-Dokumentationspflicht, die Meldepflicht gegenüber der Benannten Stelle, und die Frage der Zertifikatsgültigkeit unter dem Übergangszeitraum von MDR Artikel 120. Diese Verwechslung führt in der Praxis zu beiden Fehlern: unnötige Meldungen, die Ressourcen verbrauchen, und übersehene Meldepflichten, die Compliance-Risiken erzeugen.

Mit vs. ohne KI, ein ehrlicher Vergleich

Die Zeitangaben sind Annahmen dieser Seite, keine Messung. Der Anbieter qmsWrapper berichtet selbst über 80 Prozent weniger manuellen Traceability-Aufwand, unabhängig geprüft ist das nicht.

Einschätzung auf einen Blick

Zeitersparnis, mittel (3/5)
Ein funktionierendes KI-gestütztes Change-Assessment spart pro Änderungsereignis nach unserer Annahme etwa einen halben bis ganzen Arbeitstag für die Dokumenten-Impact-Analyse. Das ergibt bei 30–40 Changes pro Jahr 15 bis 40 Arbeitstage, also rund 3 bis 8 Wochen RA-Kapazität. Das ist substanziell, aber nicht der stärkste Zeiteinspar-Effekt in dieser Branche. Systeme wie die Technische Dokumentation nach MDR oder Post-Market Surveillance beschleunigen deutlich umfangreichere Dokumentenwerke. Der Wert des Änderungsmanagements liegt weniger in der reinen Zeiteinsparung als in der Konsistenz und Nachvollziehbarkeit.

Kosteneinsparung, niedrig (2/5)
Die Einrichtungskosten eines integrierten KI-Änderungsmanagements liegen nach unserer Annahme bei 20.000–50.000 Euro (Implementierung, Konfiguration, Validierung). Die laufenden Kosten für ein dediziertes eQMS mit KI-Funktionalität beginnen laut unserer Toolseite bei rund 500 US-Dollar im Monat für 10 Nutzer ( qmsWrapper ). Die gesparte Zeit ist Arbeitszeit, kein Geld, solange niemand eingestellt oder entlassen wird. Der finanzielle Nutzen ist nur messbar, wenn Befunde aus Audits verhindert werden, und das ist schwer in Euro auszudrücken, bevor der erste Befund eintritt. Wer den Business Case auf Basis von vermiedenen Non-Conformities baut, muss intern eine realistische Einschätzung haben, wie oft solche Fehler heute passieren.

Schnelle Umsetzung, mittel (3/5)
Zehn bis sechzehn Wochen bis zur produktiven Nutzung im QMS ist realistisch. Die Hürde ist nicht die Software, sondern die Vorbereitung: Das Technical File muss maschinenlesbar strukturiert sein, Change-Control-Prozeduren müssen SOP-Basis haben, und der Workflow im Tool muss auf die bestehenden Abläufe zugeschnitten werden. Schneller als MDR-Dossiers für den Notified Body, aber deutlich langsamer als reine Text-KI-Anwendungen wie Schulungsunterlagen.

ROI-Sicherheit, mittel (3/5)
Compliance-Risiken im regulierten Medizintechnik-Umfeld sind nicht abstrakt: Eine nicht gemeldete genehmigungspflichtige Änderung kann zur Aussetzung des Zertifikats führen, bei einem Altprodukt beendet eine unerkannt signifikante Änderung die Übergangsregel. Ein übersehener Dokumenten-Impact kann in einem Audit als systematisches QMS-Versagen bewertet werden. Der Nutzen ist weniger “wir sparen Zeit” als “wir reduzieren das Risiko eines gravierenden Compliance-Vorfalls”. Messbar ist davon aber nur die Zeit je Assessment. Ob ein Befund ausbleibt, weil das System ihn verhindert hat, lässt sich bei ein, zwei Audits im Jahr nicht zeigen. Deshalb 3, nicht 5.

Skalierbarkeit, hoch (4/5)
Mit wachsendem Produktportfolio skaliert der Nutzen erheblich: Mehr Geräte, mehr Varianten, mehr Änderungen pro Jahr, aber nicht proportional mehr RA-Kapazität. Das KI-System übernimmt die Basis-Dokumenten-Recherche für jede neue Änderung, unabhängig davon, wie viele Geräte im Portfolio sind. Einzige Einschränkung: Das Technical File jedes Produkts muss sauber im System gepflegt sein. Ein Stern Abzug gegenüber dem Maximum, weil die Qualität der KI-Analyse direkt von der Qualität der Datenpflege abhängt.

Richtwerte, stark abhängig von Geräteklasse, Anzahl der jährlichen Change Events und Reife des bestehenden QMS.

Was das System konkret macht

Das Prinzip eines KI-gestützten Änderungsmanagements lässt sich in drei Schritte zerlegen:

1. Änderungsereignis strukturiert erfassen. Statt einer formfreien E-Mail oder einem Word-Dokument wird die Änderung über ein strukturiertes Formular eingegeben: Was ändert sich? Welches Bauteil, welches Material, welcher Prozess? Welche Begründung liegt vor? Das Formular stellt sicher, dass die für die Bewertung nötigen Informationen vollständig vorhanden sind, bevor irgendjemand mit der Analyse beginnt.

2. KI analysiert den Änderungsumfang gegen das Technical File. Das ist der Kern des Automatisierungseffekts. Das System, etwa der Wrapper-Mapper in qmsWrapper , durchsucht das verknüpfte Technical File semantisch und identifiziert: Welche Anforderungen aus dem Design-Dossier sind von dieser Änderung betroffen? Welche FMEA-Einträge beziehen sich auf das geänderte Element? Welche Verifikations- und Validierungsnachweise müssen überprüft werden? Welche Normenkapitel und MDR-Anhänge sind relevant?

Das Ergebnis ist eine strukturierte Impact-Liste mit konkreten Verweisen, nicht ein allgemeines “prüft Abschnitt 5 der technischen Dokumentation”, sondern “Anforderung R-047 (Druckbeständigkeit) ist betroffen, Verifikationsprotokoll VP-12 muss geprüft werden, FMEA-Eintrag F-033 erfordert Update.”

3. RA-Expert trifft die regulatorische Entscheidung, mit vollständiger Informationsbasis. Die KI klassifiziert nicht abschließend, ob eine Änderung genehmigungspflichtig oder, bei Altprodukten, signifikant im Sinne von MDCG 2020-3 ist. Das wäre regulatorisch falsch und gefährlich. Was das System tut: Es stellt sicher, dass der zuständige RA-Manager alle relevanten Informationen auf einen Blick hat, und erzeugt einen begründeten Change-Assessment-Bericht, der als Basis für die fachliche Entscheidung dient. Die Unterschrift und die regulatorische Verantwortung bleiben beim Menschen.

Technisch nutzen diese Systeme eine Kombination aus Generativer KI (für die Interpretation der Änderungsbeschreibung und die Strukturierung der Begründung) und regelbasierter Logik (für die Traceability-Matrix zwischen Anforderungen, Risiken und Verifikationsnachweisen).

Die drei Bewertungsebenen: Was die KI helfen kann, und was nicht

Bevor du Tools und Zeitpläne betrachtest, lohnt sich ein Blick auf das strukturelle Problem, das das Johner Institut als häufigste Fehlerquelle im RA-Alltag beschreibt: Die Verwechslung von drei Bewertungsebenen, die für jede Änderung parallel gelten.

Ebene 1, QMS-Dokumentationspflicht (ISO 13485 §7.3): Jede geplante Änderung, egal wie klein, muss im Qualitätsmanagementsystem dokumentiert und bewertet werden. Das gilt auch für einen Lieferantenwechsel innerhalb gleicher Spezifikationen oder eine Tippfehlerkorrektur im IFU.

Ebene 2, Meldepflicht gegenüber der Benannten Stelle: Welche Änderungen müssen der Benannten Stelle aktiv gemeldet werden? Für MDR-zertifizierte Produkte steht das in Anhang IX: geplante wesentliche Änderungen am QMS oder an der Produktpalette sind mitzuteilen (Abschnitt 2.4), Änderungen am genehmigten Produkt, die Sicherheit, Leistung oder Anwendungsbedingungen beeinträchtigen könnten, braucht es die Genehmigung vorab (Abschnitt 4.10). Die Details regelt zusätzlich der Vertrag mit der Benannten Stelle.

Ebene 3, Signifikanzprüfung nach MDCG 2020-3 (nur relevant für Altprodukte nach Art. 120 MDR): Hier geht es um eine spezifischere Frage: Ändert sich Design oder Zweckbestimmung signifikant, darf das Produkt nicht mehr unter dem MDD-Zertifikat in Verkehr gebracht werden (Art. 120 Abs. 3c Buchst. b), und es braucht die MDR-Konformitätsbewertung. Für Produkte mit MDR-Zertifikat spielt MDCG 2020-3 keine Rolle.

KI-gestützte Systeme können Ebene 1 erheblich entlasten, die Dokumentation, Strukturierung und Impact-Analyse. Bei Ebene 2 und 3 können sie die Informationsbasis verbessern, aber die fachliche Entscheidung nicht ersetzen. Wer ein KI-System kauft und erwartet, dass es automatisch meldet, was der Benannten Stelle zugeht, kauft die falsche Erwartung.

Change-Kategorie-Matrix: Was bei Altprodukten als signifikant gilt

Für die praktische Arbeit ist eine klare Übersicht unverzichtbar. Die folgende Matrix fasst Beispiele aus MDCG 2020-3 Rev. 1 (September 2023) zusammen, der Leitlinie der Koordinierungsgruppe für Altprodukte unter Art. 120 MDR. Rechtlich bindend ist sie nicht, Benannte Stellen und Behörden richten sich aber danach. Für MDR-zertifizierte Produkte gilt sie nicht, dort entscheidet Anhang IX.

Wichtig: Diese Matrix ist eine Orientierungshilfe, kein Ersatz für die MDCG-2020-3-Flowcharts (Charts A–E). Grenzfälle, besonders im Bereich Software und Materialien mit Körperkontakt, müssen individuell mit dem Technical-File-Kontext und im Zweifel mit der Benannten Stelle abgestimmt werden. Schriftliche Bestätigungen der Benannten Stelle für Grenzfälle sind empfehlenswert.

Konkrete Werkzeuge, was wann passt

Der Markt für KI-gestütztes Änderungsmanagement in der Medizintechnik ist noch jung. Die meisten eQMS-Plattformen haben diese Funktion erst in den letzten Jahren eingeführt. Hier sind die relevanten Optionen mit ehrlicher Einordnung:

qmsWrapper , wenn der KI-Änderungsworkflow im Mittelpunkt steht
Ein spezialisiertes eQMS, das einen KI-Change-Impact-Analyzer (Wrapper-Mapper) als Kernfunktion positioniert. Das System analysiert Änderungen semantisch gegen das Technical File und generiert strukturierte Task-Listen für betroffene Dokumente. Einstiegspreis laut Toolseite: ab ca. 500 USD/Monat für 10 Nutzer (alle Module inkl.), größere Teams 1.500–4.000 USD/Monat. Kein deutsches Interface, EU-Hosting. Empfehlenswert für KMU, die ihre Traceability und ihr Change Management gleichzeitig modernisieren wollen. Noch jung, keine unabhängigen Langzeiterfahrungen verfügbar.

Greenlight Guru , wenn Design Controls und Change Management eng verknüpft sein müssen
Greenlight Guru bietet als reifes, auf Medizintechnik spezialisiertes eQMS eine starke Traceability zwischen Anforderungen, Risiken und Verifikationsnachweisen, Basis für gute Change-Impact-Analysen. Die KI-Funktionen für Änderungsmanagement sind weniger explizit als bei qmsWrapper , aber das Datenmodell ist reifer. Jahreskosten: ca. 25.000–35.000 USD. Empfehlenswert für Unternehmen mit FDA- und CE-Markt gleichzeitig oder für MedTech-Startups, die von Anfang an ein vollständiges eQMS aufbauen. Kein deutsches Interface, US-Hosting (für reine EU-Hersteller datenschutztechnisch prüfen).

MasterControl , wenn Change Control Teil eines breiteren GxP-QMS ist
MasterControl bietet ein ausgereiftes Change-Control-Modul als Teil seines vollständigen eQMS, dazu mit MasterControl AI eine KI-Schicht. Typische Implementierungszeit: 3–6 Monate. Laut unserer Toolseite grob 25.000 bis 200.000 USD im Jahr, Hosting primär in den USA. Empfehlenswert für Unternehmen mit mehreren Produktlinien und komplexeren Prozesslandschaften.

SimplerQMS , wenn Microsoft 365 schon im Einsatz ist
Baut auf SharePoint und Teams auf. Change-Management-Workflows sind vorkonfiguriert und GxP-konform. Keine eigenen KI-Analysefunktionen für Änderungsfolgen, KI kommt über Microsoft Copilot. Schnelle Implementierung (laut Toolseite 5–6 Wochen) und EU-Hosting. Laut Toolseite ab rund 17.500 USD im Jahr für bis zu 15 Nutzer. Sinnvoll, wenn das primäre Ziel eine strukturierte Change-Control-Dokumentation ist, nicht eine tiefe KI-Impact-Analyse.

KI auf bestehendes eQMS aufsetzen, Wer bereits Greenlight Guru, MasterControl oder Veeva Vault im Einsatz hat, kann dedizierte KI-Schichten darüber legen: Claude oder die OpenAI-Modelle hinter ChatGPT (über die API, für EU-Hosting über AWS Bedrock oder Azure OpenAI in einer EU-Region) können Change-Descriptions interpretieren, MDCG-2020-3-Checklisten abarbeiten und begründete Entwürfe für Change-Assessments generieren, wenn die Anbindung an das Technical File vorhanden ist. Dieser Ansatz ist flexibler, aber technisch aufwendiger und erfordert Entwicklerunterstützung.

Zusammenfassung: Wann welcher Ansatz

• KI-Änderungsanalyse als Kernfunktion, begrenztes Budget → qmsWrapper
• Vollständiges eQMS für MDR + FDA, Design Controls im Fokus → Greenlight Guru
• Größeres Unternehmen, breites GxP-QMS → MasterControl
• M365-Ökosystem, schneller Einstieg, kein KI-Deep-Dive → SimplerQMS
• Bestehendes Enterprise-eQMS vorhanden, KI-Schicht aufsetzen → Claude oder ChatGPT via API

QMS-Integration: Die eigentliche Arbeit

Der häufigste Denkfehler bei der Planung: “Wir kaufen das Tool, migrieren die Daten, und es funktioniert.” Tatsächlich ist die Tool-Integration die kleinste Hürde. Die eigentliche Arbeit liegt davor und danach.

Vor der Integration: Technical File als Datenstruktur
Ein KI-System kann nur dann sinnvolle Change-Impact-Analysen produzieren, wenn das Technical File als durchsuchbare, strukturierte Datenbank vorliegt, mit expliziten Verknüpfungen zwischen Anforderungen (Design Inputs), Risikoeinträgen (FMEA), Verifikationsnachweisen und Normenkapiteln. Wenn dein Technical File heute aus 40 Word-Dokumenten in 12 Ordnern besteht, ist der erste Schritt nicht das KI-Tool, sondern die Strukturierung dieser Daten. Je nach Zustand des Technical Files bedeutet das vier bis zwölf Wochen Vorarbeit.

Change-Control-SOP als Voraussetzung
Das KI-System folgt einem Workflow, und dieser Workflow muss in einer validierten SOP beschrieben sein, bevor das Tool im regulierten Umfeld eingesetzt werden kann. Wer noch keine dokumentierte Change-Control-Prozedur hat, muss diese zuerst schreiben und durch das QMS genehmigen lassen. Das ist keine Formalität: Bei einer Notified-Body-Inspektion wird der Workflow des KI-Systems am Maßstab der SOP gemessen.

Validierung des eQMS
Jedes eQMS im regulierten Medizintechnik-Umfeld muss validiert werden, die Pflicht dazu steht in ISO 13485 (Validierung von Software im QMS), als Rahmen dienen ISO/TR 80002-2 oder GAMP 5. Moderne Plattformen liefern vorvalidierte IQ/OQ-Dokumentationen mit, aber die Installation Qualification und Operational Qualification müssen für dein spezifisches Setup durchgeführt werden. Plane vier bis acht Wochen ein.

Schulung und Akzeptanz
Der Wechsel von einer Excel- oder Word-basierten Change-Control zur Arbeit mit einem eQMS ist für viele Mitarbeitende eine erhebliche Verhaltensänderung. Rechne damit, dass es einige echte Änderungsereignisse durch das neue System braucht, bevor das Team es als hilfreich und nicht als zusätzliche Bürokratie wahrnimmt.

Datenschutz und Datenhaltung

Das Technical File enthält technische Zeichnungen, Software-Quellcode-Referenzen, Lieferanteninformationen und in manchen Fällen klinische Daten, alles potenziell schützenswert, nicht nur im Sinne der DSGVO, sondern auch hinsichtlich Geschäftsgeheimnissen und regulatorischer Vertraulichkeit.

Grundregel: Technische Dokumentation für CE-markierte Medizinprodukte sollte nicht in US-gehostete KI-Dienste fließen, ohne vertragliche Absicherung und, je nach Inhalt, Datenschutz-Folgenabschätzung.

Die Datensituation je Tool:

• qmsWrapper : EU-Hosting verfügbar. AVV nach Art. 28 DSGVO erhältlich. Für EU-Hersteller als Standardkonfiguration empfehlenswert.
• Greenlight Guru : US-Hosting (primär). Für reine EU-Hersteller ohne FDA-Markt datenschutztechnisch zu prüfen; Frage an die Benannte Stelle, ob US-gehostete Technical-File-Inhalte akzeptabel sind.
• MasterControl : laut unserer Toolseite primär US-Rechenzentren, keine native EU-Region für Standardkunden. AVV erhältlich, Datentransfer in die USA prüfen.
• SimplerQMS : EU-Hosting; baut auf Microsoft 365 auf.
• Claude / OpenAI-Modelle via API: Für Verarbeitung in der EU: Claude über AWS Bedrock (Frankfurt) oder OpenAI-Modelle über Azure OpenAI (EU-Region). Beide bieten AVV. Kein Training auf Kundendaten in den Business/Enterprise-Varianten.

Wenn das Technical File besonders schutzbedürftige Inhalte enthält (patentierte Verfahren, klinische Daten von Patienten aus klinischen Studien), empfiehlt sich ein vollständig on-premises gehosteter Ansatz, oder zumindest die Trennung: strukturierte Metadaten in der Cloud, schützenswerte Volltexte auf eigenen Servern.

Für jeden externen KI-Dienst, der Technical-File-Inhalte verarbeitet, gilt: AVV abschließen, Datenschutz-Folgenabschätzung prüfen (besonders wenn klinische Daten enthalten), und das Ergebnis im QMS-Dokument zum Tool-Einsatz dokumentieren.

Was es kostet, realistisch gerechnet

Einmalige Einrichtungskosten (all-in)

• Tool-Implementierung + Konfiguration: 5.000–20.000 €
• Technical-File-Strukturierung (wenn noch nicht strukturiert vorhanden): 10.000–30.000 € (extern) oder 4–12 Wochen interner Aufwand
• Validierung des eQMS: 3.000–10.000 € (bei vorvalidierten Plattformen am unteren Rand)
• Change-Control-SOP entwickeln/aktualisieren: 1.000–3.000 € (wenn extern begleitet)
• Gesamt: 20.000–50.000 € (Annahmen dieser Seite), wobei der größte Posten fast immer die Datenstrukturierung ist, nicht das Tool selbst

Laufende Kosten

• qmsWrapper Starter (bis 10 Nutzer): laut Toolseite ab ca. 500 USD/Monat
• Greenlight Guru : laut Toolseite ca. 25.000–35.000 USD im Jahr
• MasterControl : laut Toolseite grob 25.000–200.000 USD im Jahr je nach Nutzerzahl und Modulen
• SimplerQMS : laut Toolseite ab rund 17.500 USD im Jahr

Was du dagegenrechnen kannst

Ein RA-Manager mit einem Bruttojahresgehalt von 70.000–90.000 € (üblich für erfahrene Regulatory-Affairs-Spezialisten in der Medizintechnik) kostet pro Arbeitstag ca. 280–360 €. Bei 30 Change Events pro Jahr und einer Einsparung von einem Tag pro Event: 30 mal 280 bis 360 € = 8.400–10.800 € Wert der gesparten Zeit im Jahr. Geld wird das nur, wenn die Kapazität sonst extern eingekauft oder neu eingestellt würde.

Dagegen steht beim günstigsten Werkzeug der Liste eine Lizenz von 12 mal 500 USD = 6.000 USD im Jahr, dazu 20.000–50.000 € Einrichtung. Über die Zeit allein amortisiert sich das nach vielen Jahren oder nie. Wer schon ein eQMS hat und nur die KI-Schicht ergänzt, rechnet deutlich günstiger.

Die andere Rechnung: Eine übersehene genehmigungspflichtige Änderung kann zur Aussetzung des Zertifikats führen, mit Vertriebsstopp, Korrekturmaßnahmen und erneutem Audit. Was das kostet, hängt am Umsatz des betroffenen Produkts und lässt sich seriös nicht pauschal beziffern. Wie oft solche Fehler heute passieren, weißt nur du. Wer das System mit diesem Risiko begründet, sollte es als Versicherung budgetieren, nicht als Einsparung.

Wie du den Nutzen tatsächlich misst:
Führe für sechs Monate parallel eine manuelle Impact-Analyse und die KI-unterstützte Analyse durch. Messe die Zeit je Event und die Vollständigkeit der identifizierten Dokument-Referenzen. Das gibt dir den ehrlichsten Benchmark für deinen spezifischen Technical-File-Umfang.

Vier typische Einstiegsfehler

1. Das Tool kaufen, bevor das Technical File strukturiert ist.
Dieses Muster führt garantiert zur Enttäuschung. Ein Change-Impact-Analyzer kann nur so gut sein wie die Verknüpfungen im Technical File. Wenn dein Technical File aus 40 unstrukturierten Word-Dokumenten besteht, gibt das System eine Liste von Fragmenten zurück, nicht eine nützliche Impact-Analyse. Lösung: Erst das Technical File in eine Traceability-Matrix überführen, dann das Tool aktivieren. Der Zeitaufwand für diesen Schritt ist der häufig unterschätzte Anteil des Projekts.

2. Die KI-Klassifikation als finale Entscheidung behandeln.
Das ist der gefährlichste Fehler, weil er aus gutem Willen entsteht: Das System sagt “nicht-signifikant”, und der RA-Manager entlastet sich. In einem Audit fragt der Prüfer nach der menschlichen Entscheidungsspur. Wer nur den KI-Output dokumentiert, hat keine. Lösung: Jede Change-Assessment-Entscheidung muss von einem qualifizierten RA-Mitarbeitenden geprüft, eventuell angepasst und unter Angabe der eigenen Qualifikation und Begründung unterzeichnet werden. Das KI-System produziert den Entwurf, der Mensch verantwortet die Entscheidung.

3. Alte Change-Events aus der Vergangenheit nicht prüfen.
Viele Unternehmen nutzen die Einführung eines KI-Systems, um ausschließlich neue Änderungen zu bearbeiten, und lassen ungeklärte historische Changes in einem Schwebezustand. Das ist regulatorisch problematisch, besonders wenn die Benannte Stelle im nächsten Audit fragt, wie Änderungen der letzten drei Jahre bewertet wurden. Lösung: Vor dem Go-Live eine geordnete Rückschau der letzten 24 Monate durchführen und alle offenen Change-Events schließen.

4. Das System wird eingeführt, aber der Workflow nicht gelebt.
Das ist die leise Version des Scheiterns. Das Tool ist da, aber im Alltag landen neue Änderungen weiterhin als E-Mail im Postfach des RA-Managers. Lösung: Den Eingang einer Änderung verbindlich über das System kanalisieren, kein Papier mehr, kein E-Mail-Anhang. Das erfordert eine klare interne Kommunikation und im Idealfall eine kurze Schulungssession für alle, die Änderungen initiieren können (Entwicklung, Einkauf, Produktion).

Was mit der Einführung wirklich passiert, und was nicht

Die häufigste Überraschung: Der meiste Aufwand der Einführung fällt nicht auf das KI-System, sondern auf die Nebenaufgaben, die vorher nicht sauber erledigt worden sind.

Was typischerweise zuerst passiert: Das Projekt deckt auf, dass der Technical-File-Inhalt über drei verschiedene Ablagesysteme verteilt ist und nicht immer die aktuelle Version zeigt. Das eQMS kann nicht gegen veraltete Dokumente analysieren. Also beginnt zuerst eine aufräumende Dokumentenmigration, die niemand geplant hat und die doppelt so lange dauert wie gedacht.

Was nach sechs Wochen passiert: Das Team, das das System bedient, schätzt die strukturierten Checklisten für die Impact-Analyse. Was anfangs als Bürokratie empfunden wurde, ist nach dem zweiten oder dritten Durchlauf der Change-Workflow, den niemand mehr missen will, weil er sicherstellt, dass beim nächsten Audit alles lückenlos dokumentiert ist.

Was nach 12 Monaten passiert: Die Skalierungseffekte werden sichtbar. Wenn das Portfolio wächst (neues Gerät, neue Variante), kostet das Einpflegen in das System deutlich weniger Aufwand als die erste Einführung, weil die Struktur schon steht und das Team den Workflow kennt. Das ist der eigentliche Langzeit-ROI.

Was nicht passiert: Das System ersetzt keinen RA-Manager. Wer erwartet, dass mit dem Tool kein Regulatory-Affairs-Wissen mehr gebraucht wird, wird enttäuscht. Die KI entlastet die Recherche und Dokumentation, aber die fachliche Einordnung einer Änderung in den regulatorischen Kontext (MDCG 2020-3, Vertragsklauseln mit der Benannten Stelle, länderspezifische Besonderheiten) bleibt eine Aufgabe für Menschen mit entsprechender Ausbildung.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

„Wir haben nur 15–20 Changes pro Jahr, das lohnt sich nicht.”
Das ist der häufigste und manchmal berechtigte Einwand. Die Antwort hängt von der Komplexität deines Technical Files ab, nicht nur von der Anzahl der Changes. Ein Klasse-IIb-Gerät mit einer umfangreichen Risikoanalyse und vielen Verifikationsnachweisen macht auch bei 15 Changes eine tiefe Impact-Analyse pro Event nötig. Ein einfaches Klasse-I-Gerät mit schlankem Technical File braucht das nicht. Ehrliche Selbsteinschätzung: Wie lange dauert bei dir heute eine Impact-Analyse für eine mittelkomplexe Änderung?

„Unsere Benannte Stelle akzeptiert das nicht.”
In der Regulatorik gibt es selten ein “akzeptieren” oder “nicht akzeptieren” für das Tool selbst, was zählt, ist der Prozess und die Dokumentation. Ein validiertes KI-System, das strukturierte Change Assessments mit nachvollziehbarer Begründung und menschlicher Entscheidungssignatur erzeugt, entspricht den QMS-Anforderungen. Was die Benannte Stelle nie akzeptieren wird: eine Entscheidung, die ausschließlich auf KI-Output basiert, ohne menschliche Überprüfung. Das ist auch nicht das Ziel.

„Wir sind gerade mitten in der MDR-Transition, jetzt noch ein Tool einführen?”
Das ist ein valider Einwand zum Timing. Die Einführung eines neuen eQMS-Tools sollte nicht mit dem Druck einer laufenden MDR-Rezertifizierung zusammenfallen, das erhöht die Fehlerrate bei beiden Projekten. Vernünftiger Zeitpunkt: nach dem ersten erfolgreichen MDR-Audit, wenn das Technical File aktuell und strukturiert ist. Dann hat das Projekt die beste Grundlage.

Woran du merkst, dass das zu dir passt

• Du hast 20 oder mehr Change Events pro Jahr, Lieferantenwechsel, Materialsubstitutionen, Software-Updates, Designanpassungen
• Dein Technical File ist komplex genug, dass eine Impact-Analyse nicht intuitiv offensichtlich ist, mehrere miteinander verknüpfte Anforderungen, FMEA-Einträge, Verifikationsprotokolle
• Du hast einen dedizierten RA-Manager oder eine RA-Funktion im Haus, das System entlastet qualifizierte Fachleute, ersetzt sie nicht
• Du nutzt bereits ein eQMS oder planst dessen Einführung, dann ist das Change-Management-Modul ein natürlicher Teil
• Du wurdest schon einmal in einem Audit auf unvollständige Change-Assessment-Dokumentation angesprochen, das ist der stärkste Prädiktor dafür, dass ein strukturierterer Ansatz Wert bringt

Wann es sich (noch) nicht lohnt, drei harte Ausschlusskriterien:

1. Weniger als 15 Change Events pro Jahr. Unterhalb dieser Schwelle ist der ROI der System-Einrichtung und -Wartung in den meisten Fällen negativ. Eine gut strukturierte MDCG-2020-3-Checkliste als Excel-Datei oder Word-Template reicht dann völlig. Die Energie fließt besser in die Dokumentenstruktur als in ein Tool.

2. Keine dokumentierte Change-Control-SOP vorhanden. Wenn der Change-Control-Prozess noch nicht definiert und schriftlich festgelegt ist, kann kein Tool diesen Prozess abbilden, es würde einen undefinierten Prozess digitalisieren. Das Ergebnis wäre weder valide noch nützlich. Zuerst die SOP schreiben und genehmigen lassen, dann das Tool aktivieren.

3. Technical File liegt ausschließlich in Papierform oder in unstrukturierten E-Mail-Anhängen. Eine KI-Impact-Analyse setzt eine digitale, durchsuchbare und strukturierte Dokumentenbasis voraus. Ohne diese Grundlage erzeugt das System keine Mehrwerte, und die Kosten für die nachträgliche Digitalisierung übersteigen in der Regel das Projektbudget für das Tool selbst. Zuerst digitalisieren, dann automatisieren.

Das kannst du heute noch tun

Bevor du Tools evaluierst: Mach eine Bestandsaufnahme deiner letzten fünf Change Events. Notiere für jeden: Wie lange hat die Impact-Analyse gedauert? Welche Dokumente wurden dabei geprüft? War die Entscheidung (signifikant / nicht-signifikant / meldepflichtig) eindeutig oder eine Einschätzungsfrage? Das gibt dir den ehrlichsten Blick auf deinen tatsächlichen Handlungsbedarf, bevor du einen Cent für Software ausgibst.

Für die nächste Änderungsbewertung kannst du diesen Prompt direkt nutzen, er arbeitet je nach Zertifikat die Fragen aus MDR Anhang IX oder aus MDCG 2020-3 ab und produziert einen begründeten Entwurf für die regulatorische Entscheidung. Technical-File-Inhalte sind Geschäftsgeheimnisse, nutze einen Business- oder Team-Tarif, nicht dein privates Abo:

Quellen & Methodik

• MDCG 2020-3 Rev. 1, September 2023: „Guidance on significant changes regarding the transitional provision under Article 120 of the MDR with regard to devices covered by certificates issued according to MDD or AIMDD.” European Commission, Health and Food Safety Directorate-General. Direktlink: health.ec.europa.eu. Maßgebliches Dokument für die Signifikanz-Klassifikation, Basis der Change-Kategorie-Matrix in diesem Text.
• Johner Institut, „Design Change/Designänderung: Anforderungen und MDCG 2020-3”: Praxisdokumentation zu den drei Bewertungsebenen und häufigen Fehlern in der Umsetzung. johner-institut.de/blog/regulatory-affairs/design-change/. Stand: 2024.
• qmsWrapper v10.2 Feature-Dokumentation: KI-Change-Impact-Analyse (Wrapper-Mapper), Preisangaben Starter-Plan ($500/Monat, 10 Nutzer, alle Module inkl.). qmswrapper.com und G2-Preisseite, Stand Mai 2026.
• Greenlight Guru: Jahrespreise ($25.000–35.000 USD, Mindestvertrag 2–3 Jahre). Verifiziert in der ki-syndikat.de Tool-Datenbank, Stand April 2026.
• MasterControl, SimplerQMS, qmsWrapper: Preis-, Hosting- und Implementierungsangaben aus unseren Toolseiten.
• MDR Anhang IX Abschnitte 2.4 und 4.10, Art. 120 Abs. 3c und 3e: Verordnung (EU) 2017/745, konsolidierte Fassung vom 19.07.2026 (eur-lex.europa.eu, abgerufen am 19.09.2026): Mitteilung und Genehmigung von Änderungen bei MDR-Zertifikaten, Bedingungen und Überwachung bei Altprodukten.
• Zeitaufwand Change Assessment: Annahme dieser Seite, keine Messung; Bereich 0,5–3 Tage je nach Komplexität.
• qmsWrapper Traceability-Reduktion (>80%): Eigenangabe qmsWrapper, keine unabhängige Verifikation verfügbar. Als Vendor-Angabe entsprechend einzuordnen.
• Gehälter RA-Manager: Orientierungswert 70.000–90.000 € Bruttojahresgehalt basierend auf Stepstone/LinkedIn-Gehaltsauswertungen für Regulatory Affairs Manager Medizintechnik, Deutschland, Stand 2024/2025.

Du willst einschätzen, ob dein Technical File die Voraussetzungen für KI-gestütztes Änderungsmanagement erfüllt, oder welcher Vorbereitungsaufwand realistisch ist? Melde dich für ein kurzes Gespräch.