Änderungsmanagement für Produktakten automatisieren

Das echte Ausmaß des Problems

Das Änderungsmanagement ist eine der häufigsten Ursachen 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 typisches Medizinprodukte-KMU mit einem oder zwei Klasse-IIa/IIb-Geräten bearbeitet pro Jahr 20–50 Change Events. Dazu zählen Lieferantenwechsel, Materialsubstitutionen, Software-Updates, Designoptimierungen und Prozessänderungen in der Fertigung. Für jede dieser Änderungen gilt: Sie muss bewertet werden, dokumentiert werden, und — falls signifikant im Sinne von MDCG 2020-3 — der Benannten Stelle gemeldet werden.

Der Aufwand pro Change Assessment liegt in der Praxis bei einem bis drei Arbeitstagen, abhängig von der Komplexität des Geräts und der Vollständigkeit des Technical Files. Das bedeutet: Ein RA-Manager mit 35 Change Events pro Jahr verbringt drei bis sechs Wochen pro Jahr ausschließlich mit der Beurteilung von Änderungen — 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

Quelle: Erfahrungswerte aus Implementierungsprojekten bei Medizintechnik-KMU; qmsWrapper (2024) berichtet über 80 Prozent Reduktion bei manuellem Traceability-Aufwand.

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5)
Ein funktionierendes KI-gestütztes Change-Assessment spart pro Änderungsereignis etwa einen halben bis ganzen Arbeitstag für die Dokumenten-Impact-Analyse. Das ergibt bei 30–40 Changes pro Jahr realistisch drei bis fünf Wochen eingesparte 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 bei 20.000–50.000 Euro (Implementierung, Konfiguration, Validierung). Die laufenden Kosten für ein dediziertes eQMS mit KI-Funktionalität beginnen bei ca. 500–800 Euro/Monat für kleine Teams. Der finanzielle Nutzen ist real, aber 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 — sehr hoch (5/5)
Das ist der stärkste Hebel dieses Use Cases. Compliance-Risiken im regulierten Medizintechnik-Umfeld sind nicht abstrakt: Ein fehlender Notified-Body-Report für eine signifikante Änderung kann zur Aussetzung des CE-Zertifikats führen. Ein übersehener Dokumenten-Impact kann in einer Inspektion als systematisches QMS-Versagen bewertet werden. Der Nutzen ist weniger “wir sparen Zeit” als “wir reduzieren das Risiko eines gravierenden Compliance-Vorfalls” — und dieser Nutzen tritt unabhängig von der Unternehmensgröße ein. Auf gleicher Höhe mit Post-Market Surveillance als der zweite klare Compliance-getriebene ROI-Hebel im Branch.

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 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 in der Praxis 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? Das ist vertraglich geregelt und geht über die bloße QMS-Dokumentation hinaus. Manche Änderungen müssen vor Umsetzung genehmigt werden, andere nur im nächsten Audit besprochen werden.

Ebene 3 — Signifikanzprüfung nach MDCG 2020-3 (nur relevant für Übergangsprodukte nach Art. 120 MDR): Hier geht es um eine spezifischere Frage — hat eine Änderung Einfluss auf Design oder Zweckbestimmung so, dass das MDD-Zertifikat seine Gültigkeit verliert und ein vollständiges MDR-Verfahren nötig wird?

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 unter MDR als signifikant gilt

Für die praktische Arbeit ist eine klare Übersicht unverzichtbar. Die folgende Matrix basiert auf MDCG 2020-3 Rev. 1 (September 2023) — dem verbindlichen EU-Guidance-Dokument für Änderungsbewertungen.

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 zwei Jahren (2023–2025) eingeführt. Hier sind die relevanten Optionen mit ehrlicher Einordnung:

qmsWrapper — wenn der KI-Änderungsworkflow im Mittelpunkt steht
Das einzige spezialisierte eQMS, das einen dedizierten 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: ab ca. 500 USD/Monat für 10 Nutzer (alle Module inkl.). Kein deutsches Interface. 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. KI-gestützte Impact-Analyse ist im Aufbau, der traditionelle workflow-basierte Ansatz ist jedoch bereits stark standardisiert. Typische Implementierungszeit: 3–6 Monate. Jahreskosten: ab ca. 25.000 €. 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 dedizierten KI-Analysefunktionen für Änderungsfolgen, aber schnelle Implementierung (4–8 Wochen) und EU-Hosting (Dänemark). Ab ca. 500 €/Monat. 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 ChatGPT (via API, EU-gehostet) 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.” In der Praxis 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 — nach GAMP5 oder einem ähnlichen Rahmen. 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. Erfahrungsgemäß braucht es zwei bis drei echte Änderungsereignisse durch das neue System, 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: EU-Region verfügbar; ISO 27001 zertifiziert. AVV erhältlich.
• SimplerQMS: EU-Hosting (Dänemark); baut auf Microsoft 365 auf — AVV über Microsoft Business Agreement.
• Claude / ChatGPT via API: Für EU-konforme Verarbeitung: Claude über AWS Bedrock (Frankfurt) oder ChatGPT ü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
• GAMP5-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 €, wobei der größte Posten fast immer die Datenstrukturierung ist, nicht das Tool selbst

Laufende Kosten (monatlich)

• qmsWrapper Starter (bis 10 Nutzer): ca. 500–800 USD/Monat
• Greenlight Guru: ca. 2.100–3.000 USD/Monat (Jahresrechnung)
• MasterControl: ca. 2.000–4.000 €/Monat je nach Nutzerzahl und Modulkonfiguration
• SimplerQMS: ca. 500–1.500 €/Monat

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: 8.400–10.800 € direkte Kosteneinsparung — nur bei der Bearbeitungszeit, nicht bei den Compliance-Risiken.

Aber die Hauptrechnung ist eine andere: Ein kritischer Befund einer Benannten Stelle, der aus einer übersehenen signifikanten Änderung resultiert, kann zur temporären Unterbrechung des CE-Zertifikats führen. Die Kosten dafür — Vertriebsstopp, Notifikation an Aufsichtsbehörden, Korrekturmaßnahmen, erneutes Audit — beginnen bei 50.000 € und können schnell in den sechsstelligen Bereich gehen. Der ROI des Change-Management-Systems wird in vielen Unternehmen nicht mit gesparter Arbeitszeit begründet, sondern mit diesem vermiedenen Worst-Case-Szenario.

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 reviewen.
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 KI-System, das strukturierte Change Assessments mit nachvollziehbarer Begründung und menschlicher Entscheidungssignatur erzeugt, entspricht den GMP/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 10–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 die MDCG-2020-3-Kernfragen ab und produziert einen begründeten Entwurf für die regulatorische Entscheidung:

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 und SimplerQMS: Preisangaben und Implementierungszeiten aus der ki-syndikat.de Tool-Datenbank, verifiziert April 2026.
• Zeitaufwand Change Assessment: Erfahrungswerte aus Medizintechnik-Beratungsprojekten; Bereich 0,5–3 Tage für Komplexitätsstufen übereinstimmend mit Praxisberichten bei devicemed.de und seleon.com.
• 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.