Technische Dokumentation nach MDR erstellen

Das echte Ausmaß des Problems

Die technische Dokumentation nach MDR 2017/745 ist kein einfaches Dokument. Anhang II beschreibt die technische Dokumentation zum Produkt selbst, Anhang III die technische Dokumentation über die Überwachung nach dem Inverkehrbringen. Für komplexe Produkte können daraus Dutzende zusammenhängende Dokumente entstehen, die vollständig und konsistent zueinander sein müssen. (Eine frühere Fassung dieser Seite beschrieb Anhang III als Regelwerk für implantierbare Produkte. Das ist falsch, Anhang III ist die Post-Market-Surveillance-Dokumentation.)

Wie viele Arbeitsstunden die Ersterstellung kostet, hängt an Risikoklasse, Softwareanteil und vorhandenem Dokumentationsstand und lässt sich nicht seriös pauschalisieren. Eine frühere Fassung dieser Seite nannte hier eine Stundenspanne mit Verweis auf eigene Consulting-Projekte. Solche Projekte haben wir nicht, die Zahl ist raus. Die belastbare Größe ist eure eigene: Zieht die Stundenbuchungen des letzten abgeschlossenen Zulassungsprojekts heran. In einem Team mit zwei Regulatory-Affairs-Mitarbeitenden zeigt diese Zahl meist schon, ob ein einziges neues Produkt über Monate die gesamten Kapazitäten bindet.

Besonders kritisch sind dabei drei Schwachstellen:

• Vollständigkeitslücken: MDR Anhang II hat sechs Abschnitte, Produktbeschreibung und Spezifikation, vom Hersteller zu liefernde Informationen, Informationen zu Auslegung und Herstellung, grundlegende Sicherheits- und Leistungsanforderungen, Nutzen-Risiko-Analyse und Risikomanagement sowie Verifizierung und Validierung des Produkts. Jeder davon hat zahlreiche Unterpunkte. Selbst erfahrene Regulatory-Profis übersehen Anforderungen, die in der vorherigen MDD noch nicht so spezifisch waren, etwa die systematische Darstellung der klinischen Bewertungsmethodik oder der Post-Market-Surveillance-Planung.
• Inkonsistenz zwischen Dokumenten: Risikoanalyse und klinische Bewertung müssen inhaltlich aufeinander verweisen. Wenn eine Anforderung in der technischen Spezifikation anders formuliert ist als im Risikomanagementfile, erzeugt das Rückfragen.
• Veraltete Dokumentation bei Änderungen: Jede Produktänderung, selbst eine scheinbar kleine, muss bewertet und dokumentiert werden. In der Praxis entsteht ein Rückstau: Die Dokumentation spiegelt nicht mehr den aktuellen Produktstand wider.

Für Hersteller, die sowohl den europäischen (CE) als auch den amerikanischen (FDA 510(k) / De Novo) Markt bedienen wollen, kommt die Parallelarbeit zweier unterschiedlicher Anforderungssysteme hinzu.

Mit vs. ohne KI, ein ehrlicher Vergleich

Diese Tabelle enthält bewusst keine Prozentzahlen. Eine frühere Fassung stützte sie auf „Erfahrungswerte aus Implementierungsprojekten”, die es bei uns nicht gibt, und auf eine Notified-Body-Erhebung, deren Primärquelle wir nicht öffnen konnten. Beides ist raus. Der Hebel bleibt derselbe und er ist auch ohne Zahl erkennbar: Jede vermiedene Rückfragen-Runde spart nicht nur die Antwortfrist, sondern den gesamten Zeitverlust bis zur nächsten Prüfrunde.

Einschätzung auf einen Blick

Zeitersparnis, sehr hoch (5/5) Die Erstellung technischer Dokumentation ist in der Medizintechnik der zeitintensivste Engpass überhaupt. KI kann Textvorschläge aus Produktspezifikationen generieren, eine bestehende Dokumentation gegen die Abschnitte der MDR-Anhänge durchgehen und Querverweise zwischen Dokumenten sichtbar machen. Eine belastbare Zahl für die Ersparnis gibt es nicht, und wir erfinden hier keine. Was für die Bewertung spricht: Die Arbeit, die wegfällt, ist mechanisches Abgleichen, nicht fachliche Beurteilung. Genau das ist die Sorte Arbeit, bei der der Effekt am größten und am schnellsten sichtbar ist.

Kosteneinsparung, hoch (4/5) Direkte Einsparungen entstehen über drei Wege: weniger externe Regulatory-Consulting-Stunden, kürzere Time-to-Market, und vermiedene Notified-Body-Mehrkosten durch Nacheinreichungen. Die Einrichtungskosten hängen fast vollständig daran, ob ihr ein eQMS einführt oder mit einem Prompt und eurem bestehenden QMS startet. Zwischen diesen beiden Wegen liegt eine Größenordnung, und die Toolpreise der spezialisierten Anbieter sind nicht öffentlich, dazu unten mehr.

Schnelle Umsetzung, niedrig (2/5) Das ist der ehrliche Preis dieses Anwendungsfalls: Jede KI-Unterstützung im Regulatory-Bereich muss im QMS beschrieben und die eingesetzte Software validiert werden. Das folgt aus der QMS-Pflicht in Artikel 10 Absatz 9 MDR und der Ausgestaltung nach ISO 13485, nicht aus einem Anhang mit einer Abschnittsnummer. Zwischen 16 und 24 Wochen von der Entscheidung bis zum produktiven Einsatz sind realistisch. Wer das unterschätzt, kauft sich in der Praxis nur ein neues Projektmanagementproblem.

ROI-Sicherheit, hoch (4/5) Der Nutzen ist direkt messbar: Wie viele Rückfragen kamen beim letzten Einreichungsversuch? Wie viele Stunden wurden für Lückenanalysen aufgewendet? Wie lange dauerte die letzte Notified-Body-Runde? Das sind Zahlen, die ein Regulatory-Affairs-Team kennt, und gegen die man nach 6 Monaten KI-Einsatz sauber vergleichen kann. Nicht auf Platz 5, weil das Qualitätsniveau des KI-Outputs stark von der Güte der Eingangsdokumente abhängt.

Skalierbarkeit, hoch (4/5) Einmal eingerichtet, lässt sich der KI-Assistent auf jedes neue Produkt im Portfolio anwenden, ohne proportional steigenden Aufwand. Für Hersteller mit 5 oder mehr Produkten ist der Skalierungshebel erheblich. Nicht auf 5, weil bei sehr unterschiedlichen Produktkategorien (z. B. Klasse I und Klasse III im gleichen Portfolio) die Konfiguration für jede Klasse separat validiert werden muss.

Richtwerte, stark abhängig von Unternehmensgröße, Produktkomplexität und bestehendem Dokumentationsstand.

Was das System konkret macht

KI übernimmt bei der technischen Dokumentation nach MDR drei klar abgrenzbare Aufgaben:

1. Strukturprüfung und Lückenanalyse Ein KI-Assistent kann, prompt-gesteuert mit den Anforderungen aus MDR Anhang II konfiguriert, eine bestehende technische Dokumentation systematisch gegen die Checkliste der Anforderungen durchgehen. Das Ergebnis: eine Liste fehlender oder unvollständiger Abschnitte. Die Priorisierung nach regulatorischer Kritikalität bleibt beim Menschen, ein Modell kennt eure Risikoklasse und eure Auditgeschichte nicht. Was sich verschiebt, ist der Vorlauf: Der erste Durchgang durch den Bestand dauert Stunden statt Tage, und die teure Fachzeit setzt später und gezielter ein.

2. Textgenerierung aus Produktdaten Viele Abschnitte der technischen Dokumentation (Gerätebeschreibung, Zweckbestimmung, Betriebsbedingungen) sind strukturiert aus vorhandenen Produktdaten ableitbar. KI kann aus Pflichtenheften, technischen Spezifikationen oder Labordaten strukturierten Fließtext generieren, der als Entwurf dient und von der Fachperson überarbeitet wird, statt bei Null anzufangen.

3. Konsistenzprüfung zwischen Dokumenten Wenn in der Risikoanalyse ein bestimmtes Anwendungsszenario beschrieben wird, sollte es auch in der klinischen Bewertung auftauchen. KI kann solche Querverweise prüfen und Inkonsistenzen markieren, noch bevor der Notified Body sie findet.

Wichtig: KI ersetzt hier nicht das Fachwissen des Regulatory-Affairs-Teams. Sie produziert Entwürfe und Hinweise, die fachliche Verantwortung und die inhaltliche Überprüfung bleiben beim Menschen. Das ist keine Schwäche, sondern regulatorische Notwendigkeit: Nach Artikel 15 MDR muss jeder Hersteller über eine für die Einhaltung der Regulierungsvorschriften verantwortliche Person verfügen, und zwar unabhängig von der Risikoklasse. Kleinst- und Kleinunternehmen müssen diese Person nicht dauerhaft in der Organisation haben, sondern dauerhaft und ständig zur Verfügung. Wer also glaubt, die Klassifizierung entscheide darüber, ob jemand persönlich geradesteht, hat die Norm falsch gelesen.

Konkrete Werkzeuge, was wann passt

Greenlight Guru , ein etabliertes spezialisiertes eQMS für Medizinproduktehersteller. Bietet strukturierte Design Controls, Risikoregister nach ISO 14971 und Traceability bis auf Anforderungsebene. Starke Integration zwischen technischer Dokumentation und Post-Market-Modulen. Einschränkungen: ausschließlich englischsprachig, US-Hosting, mehrjährige Vertragsbindung, deren Laufzeit du vor Abschluss verhandeln solltest. Eine öffentliche Preisliste gibt es nicht. Die Marktdatenplattform Vendr weist für Greenlight-Guru-Verträge einen Median im mittleren fünfstelligen US-Dollar-Bereich pro Jahr aus, ohne Stichprobe oder Jahr zu nennen. Behandle das als Größenordnung für die Budgetfrage, nicht als Preis. Empfehlung für Hersteller, die auch den FDA-Markt bedienen.

meddevo eTD , Deutsche Alternative mit EU-Hosting und deutschsprachigem Support. Speziell auf MDR/IVDR-Anforderungen ausgerichtet, Dokumentenstruktur nach MDR Anhang II vorkonfiguriert. Für rein europäisch ausgerichtete Hersteller oft die bessere Wahl als US-basierte Plattformen. Preise auf Anfrage, individuelle Angebote nach Portfoliogröße.

Formwork von OpenRegulatory , vom Team hinter openregulatory.com entwickelt, einer der bekanntesten deutschen Ressourcen für MDR-Compliance. Die Community Edition ist kostenlos, aber eng begrenzt: fünf Nutzer, zehn Dokumente, zehn Records. Wer darüber hinaus arbeitet, ist bei Starter (99 Euro im Monat, fünf Nutzer, unbegrenzte Dokumente) oder QMS + Techdoc (499 Euro im Monat, unbegrenzte Nutzer). Monatlich kündbar. Geeignet für Startups und kleine Hersteller mit erstem Produkt, für komplexe Portfolios schnell zu schmal.

Claude AI oder ChatGPT mit regulatorischem Prompt, Für Teams ohne Budget für ein spezialisiertes Tool: Ein gut konfigurierter KI-Assistent kann eine bestehende technische Dokumentation gegen MDR-Anhang-Checklisten prüfen und Entwurfstexte generieren. Kein strukturiertes Traceability-System, aber als Einstieg und für Lückenanalysen sehr wirksam. Wichtig: Die Ausgaben müssen fachlich überprüft werden, und die verwendeten Dokumente dürfen keine nicht-öffentlichen Patientendaten enthalten.

Zusammenfassung: Wann welcher Ansatz

• Startup, erstes CE-Produkt, kleines Budget → Formwork (kostenlose Community Edition, danach 99 €/Monat)
• Europäischer Hersteller, Klasse IIa–III, deutschsprachiges Team → meddevo
• Dual-market (CE + FDA), mittleres bis großes Unternehmen → Greenlight Guru
• Schneller Einstieg, Lückenanalyse ohne Tool-Investition → Claude AI / ChatGPT mit Prompt

Rechtliche Besonderheiten

Das ist der Abschnitt, den viele KI-Einführungsberatungen weglassen, weil er den Enthusiasmus bremst. Deshalb steht er hier explizit.

Das Werkzeug gehört ins QMS, und die Norm dafür heißt nicht Anhang II Abschnitt 9. Eine frühere Fassung dieser Seite nannte genau das als Rechtsgrundlage. Es gibt diesen Abschnitt nicht, Anhang II hat sechs Abschnitte. Der richtige Anker ist Artikel 10 Absatz 9 MDR: Hersteller müssen ein Qualitätsmanagementsystem „einrichten, dokumentieren, anwenden, aufrechterhalten, ständig aktualisieren und kontinuierlich verbessern”, das ausdrücklich auch die Prozesse und Verfahren der Organisation umfasst. Die konkrete Anforderung, Software zu validieren, die im QMS selbst eingesetzt wird, steht in der harmonisierten Norm ISO 13485:2016, nach der das QMS aufgebaut wird, nicht im Verordnungstext.

In der Praxis ändert das nichts am Ergebnis, nur an der Begründung, die im Audit trägt: Bevor du Claude AI oder ein anderes LLM produktiv in die Dokumentationserstellung integrierst, braucht dein QMS eine SOP, die beschreibt, wofür das Tool eingesetzt wird, welche Ausgaben manuell geprüft werden müssen, und wer die fachliche Verantwortung trägt. Das ist kein Showstopper, aber ein notwendiger Schritt, den du einplanen musst.

Und die Abgrenzung, die im Medizintechnikumfeld regelmäßig durcheinandergeht: Ein Werkzeug, mit dem ihr eure eigene Dokumentation schreibt, ist kein Medizinprodukt. Ein Medizinprodukt setzt nach Artikel 2 Nummer 1 MDR eine medizinische Zweckbestimmung voraus, Diagnose, Verhütung, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung. Sobald KI dagegen in euer Produkt wandert, greift Regel 11 in Anhang VIII Abschnitt 6.3: „Software, die dazu bestimmt ist, Informationen zu liefern, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden”, gehört zur Klasse IIa, bei Entscheidungen mit der Folge einer schwerwiegenden Verschlechterung des Gesundheitszustands oder eines chirurgischen Eingriffs zur Klasse IIb, bei Tod oder irreversibler Verschlechterung zur Klasse III. Sämtliche andere Software ist Klasse I. Das ist der Grund, warum die harmlos klingende Frage „können wir den Assistenten nicht auch dem Anwender geben” ein anderes Projekt ist als das hier beschriebene.

Halluzinationsgefahr bei regulatorischen Anforderungen: Ein allgemeines LLM kann MDR-Anforderungen falsch zitieren oder erfinden. Das ist gefährlich, weil die Ausgaben gut klingen, und niemand, der kein Regulatory-Experte ist, den Fehler erkennt. Die Lösung: Normtexte nie durch KI zitieren lassen. KI generiert Entwurfstexte, Menschen prüfen gegen die Primärquelle.

Datenschutz und Datenhaltung

Technische Dokumentation enthält in der Regel keine personenbezogenen Patientendaten, sie beschreibt das Produkt, nicht einzelne Patienten. Das vereinfacht die DSGVO-Bewertung erheblich.

Relevant ist aber: Produktspezifikationen, Fertigungsgeheimnisse und Designdaten sind vertraulich. Wenn du diese Daten in ein cloud-basiertes KI-Tool hochlädst, gibst du Geschäftsgeheimnisse weiter. Die Risikoabwägung hier ist keine Datenschutz-, sondern eine IP-Frage. Empfehlungen:

• Für US-gehostete Tools (Claude API, ChatGPT Enterprise, Greenlight Guru): prüfe die Datenverarbeitungsverträge auf IP-Klauseln und stelle sicher, dass Trainingsdatennutzung ausgeschlossen ist
• Für EU-gehostete Lösungen (meddevo, Formwork): einfachere Ausgangslage, aber AVV nach Art. 28 DSGVO trotzdem abschließen
• Für hochsensible Produktdaten (Klasse III, implantierbare Geräte): On-Premise-Deployment oder EU-konforme Privat-Cloud erwägen

Alle drei genannten Anbieter bieten AVV-Prozesse, aber du musst sie aktiv anfordern.

Was es kostet, realistisch gerechnet

Einmalige Einrichtungskosten

• Auswahl und Konfiguration des Tools: 4–8 Wochen interner Aufwand
• Validierung der KI-Unterstützung im QMS (erforderlich nach ISO 13485, siehe Rechtliche Besonderheiten): interne Regulatory- und QM-Zeit, deren Umfang am Validierungsplan hängt. Schreib den Plan zuerst und schätze dann, nicht umgekehrt
• Bei eQMS-Tools (Greenlight Guru, meddevo): Onboarding und Datenmigration werden separat angeboten und separat bepreist. Lass dir diesen Posten im Angebot ausweisen, er taucht in Vendor-Präsentationen selten neben dem Lizenzpreis auf
• Bei LLM-basiertem Ansatz (Claude AI / ChatGPT): primär interne Personalzeit, externe Kosten minimal

Laufende Kosten (monatlich)

• Greenlight Guru: kein öffentlicher Listenpreis, Jahresvertrag nach Angebot
• meddevo: kein öffentlicher Listenpreis, Angebot nach Portfoliogröße. Eine frühere Fassung dieser Seite nannte hier eine Monatsspanne als „Schätzung”, die auf nichts beruhte
• Formwork: Community Edition kostenlos (5 Nutzer, 10 Dokumente), Starter 99 Euro, QMS + Techdoc 499 Euro
• LLM-Nutzung: im zweistelligen Eurobereich pro Monat, solange ihr Text prüft und nicht ganze Dokumentenbestände durch die API schiebt

Was du dagegenrechnen kannst Den Stundensatz eures Regulatory-Dienstleisters kennt ihr aus der letzten Rechnung, und den Umfang der letzten Lückenanalyse ebenfalls. Multipliziert das, dann habt ihr die Vergleichsgröße, die für euch gilt. Dazu kommt der Posten, der in keiner Rechnung steht: Jede Notified-Body-Rückfragen-Runde kostet nicht nur die Antwortfrist, sondern die Wartezeit bis zur nächsten Prüfrunde. Setzt dafür euren eigenen Deckungsbeitrag pro Monat ein, das ist die Zahl, die im Management ankommt.

Wie du den Nutzen tatsächlich misst Führe Buch über Rückfragen je Einreichung, aufgewandte Regulatory-Stunden je Produkt und die Zahl externer Consulting-Einsätze. Vergleiche nach 12 Monaten. Wenn das System funktioniert, sinken alle drei Kennzahlen, und du hast den ROI schwarz auf weiß.

Typische Einstiegsfehler

1. Das KI-Tool als Autorität behandeln, nicht als Entwurfshelfer. Der gefährlichste Fehler: Regulatory-Mitarbeitende, die unter Zeitdruck stehen, akzeptieren KI-generierte Texte ohne gründliche Überprüfung. Ein LLM kann zu MDR-Anforderungen plausibel klingende, aber inhaltlich falsche Aussagen produzieren, samt Abschnittsnummern, die es nicht gibt. Die Faustregel: Alles, was normativ zitiert wird, wird gegen den Primärtext auf EUR-Lex geprüft. Ohne Ausnahme.

2. Das Tool ohne QMS-Integration einführen. KI-Unterstützung, die außerhalb des Qualitätsmanagementsystems läuft, schafft Schatten-Prozesse, die bei einem Audit sofort auffallen. Jede KI-gestützte Aktivität im Dokumentationsprozess braucht eine SOP: Was tut das Tool? Was prüft der Mensch nach? Wer zeichnet ab? Das vor dem Start klären, nicht danach.

3. Mit allen Produkten gleichzeitig starten. Der Reflex ist verständlich: Wenn das Tool gut ist, wollen alle davon profitieren. Eine simultane Einführung auf zehn Produkte führt aber dazu, dass Qualitätsmängel im System erst spät auffallen, und dann in zehn Dokumentationen gleichzeitig behoben werden müssen. Starte mit einem Produkt, validiere das Ergebnis, dann skaliere.

4. Die Validierung als lästige Pflicht behandeln. Regulatory-Teams, die die QMS-Anforderungen an die Validierung der eingesetzten Tools als Bürokratie sehen, riskieren ein Audit-Problem. Die Validierung der KI-Unterstützung ist kein extra Aufwand, sie ist der Nachweis, dass du deinen Erstellungsprozess unter Kontrolle hast. Wer diese Dokumentation von Anfang an sauber aufbaut, hat beim nächsten Audit ein starkes Argument: Das Tool ist kein Risiko, es ist ein kontrollierter Prozess.

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

Die Technik ist das Einfachste. Schwieriger ist der Mensch.

Erfahrene Regulatory-Mitarbeitende haben oft jahrelange persönliche Workflows entwickelt: Word-Vorlagen, Excel-Checklisten, ein mentales Modell der MDR-Anforderungen. Ein neues System fühlt sich zunächst wie mehr Arbeit an, nicht weniger. Dieser Widerstand ist verständlich und normal. Was hilft: Die erfahrenste Person im Team frühzeitig einbeziehen, ihr Feedback in die Konfiguration einfließen lassen. Wer das System mitgestaltet hat, verteidigt es bei der nächsten Auditsvorbereitung.

Neue Regulatory-Mitarbeitende sind oft sofort begeistert, weil das System ihnen Struktur gibt, die sie sonst mühsam aufbauen müssten. Diese Gruppe ist der natürliche Champion für die Einführung.

Das Management erwartet oft einen sofortigen Effekt. Die Realität: In den ersten drei Monaten steigt der Aufwand, weil alte Dokumentation migriert, das System konfiguriert und das Team eingearbeitet werden muss. Rechne nicht damit, dass sich das schon beim ersten Produkt auszahlt: Es trägt Migration, Konfiguration und Einarbeitung allein.

Was konkret hilft:

• Einen 90-Tage-Pilot mit einem einzigen Produkt und einem klaren Messziel festlegen
• Die Validierungsdokumentation von Anfang an als eigenes Dokument führen, nicht als Nacharbeit
• Wöchentliche kurze Retros im ersten Quartal, um Konfigurationsprobleme früh zu beheben

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

„KI kann keine Regulatory-Entscheidungen treffen.” Richtig. Und das soll sie nicht. Der Anwendungsfall ist nicht Entscheidungsautomatisierung, sondern strukturierte Entwurfs- und Prüfunterstützung. Der Regulatory-Experte entscheidet, KI hilft dabei, nichts zu vergessen und schneller erste Entwürfe zu haben.

„Wir können kein US-Tool verwenden, DSGVO.” Für US-gehostete Tools ist eine gründliche Prüfung der Datenverarbeitungsverträge notwendig, das stimmt. Aber es gibt EU-gehostete Alternativen (meddevo, Formwork), und für LLM-basierte Ansätze lässt sich der Datentransfer so konfigurieren, dass keine personenbezogenen oder geheimen Produktdaten übertragen werden.

„Wir werden das Tool eh wieder wechseln, wenn MDR sich ändert.” MDR-Updates werden inkrementell durch Guidance-Dokumente der MDCG konkretisiert, radikale Strukturänderungen der technischen Dokumentation sind nicht zu erwarten. Ein gut konfiguriertes System kann auf neue Guidance-Anforderungen angepasst werden. Der Aufwand für einen Tool-Wechsel ist deutlich höher als für eine Rekonfiguration.

Woran du merkst, dass das zu dir passt

• Dein Regulatory-Team verbringt mehr als 30 Prozent seiner Zeit mit Strukturprüfungen und Lückenanalysen, nicht mit inhaltlicher Beurteilung
• Ihr habt mehr als ein Produkt in der CE-Zertifizierungspipeline gleichzeitig, der Engpass bei der Dokumentation ist systematisch, nicht zufällig
• Die letzte Notified-Body-Einreichung hat Rückfragen generiert, bei denen im Nachhinein klar war: Das hätten wir selbst finden können
• Das Team wächst und ihr onboardet Regulatory-Nachwuchs, ein strukturiertes Tool reduziert die Abhängigkeit von einem einzigen erfahrenen Mitarbeitenden
• Ihr plant neue Produktkategorien oder Varianten des bestehenden Portfolios, je mehr Produkte, desto größer der Skalierungshebel

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

1. Einzelnes Produkt, das bereits CE-zertifiziert ist und keine Änderungen plant. Wenn die technische Dokumentation fertig ist und gepflegt wird, ist der Einführungsaufwand eines neuen Systems nicht gerechtfertigt.

2. Team ohne dedizierten Regulatory-Affairs-Experten. KI-Unterstützung ersetzt kein Regulatory-Fachwissen, sie macht vorhandenes Fachwissen effizienter. Ein Tool, das niemand fachlich überprüfen kann, erzeugt falsche Sicherheit.

3. Keine QM-Infrastruktur vorhanden. Wenn das Unternehmen noch kein ISO-13485-konformes Qualitätsmanagementsystem hat, ist die Einführung eines KI-Tools der falsche erste Schritt. Erst das QMS etablieren, dann digitalisieren.

Das kannst du heute noch tun

Öffne Claude AI oder ChatGPT und lade die erste Seite einer bestehenden technischen Dokumentation hoch. Verwende diesen Prompt, der die Anforderungen von MDR Anhang II als Prüfrahmen nutzt:

Quellen & Methodik

• MDR Anhang II, technische Dokumentation: sechs Abschnitte, 1 Produktbeschreibung und Spezifikation (1.1, 1.2), 2 Vom Hersteller zu liefernde Informationen, 3 Informationen zu Auslegung und Herstellung, 4 Grundlegende Sicherheits- und Leistungsanforderungen, 5 Nutzen-Risiko-Analyse und Risikomanagement, 6 Verifizierung und Validierung des Produkts (eur-lex.europa.eu, konsolidierte Fassung, abgerufen am 18.09.2026).
• MDR Anhang III: „Technische Dokumentation über die Überwachung nach dem Inverkehrbringen”, zu erstellen gemäß den Artikeln 83 bis 86. Nicht, wie eine frühere Fassung dieser Seite behauptete, das Regelwerk für implantierbare Produkte (ebenda).
• MDR Anhang I Abschnitt 17: Anforderungen an programmierbare Elektroniksysteme und Produkte in Form einer Software, insbesondere 17.2, Entwicklung nach dem Stand der Technik unter Berücksichtigung von Software-Lebenszyklus, Risikomanagement, Verifizierung und Validierung (ebenda).
• MDR Anhang VIII Abschnitt 6.3, Regel 11: Software, die Informationen für diagnostische oder therapeutische Entscheidungen liefert, ist Klasse IIa, IIb oder III je nach Folgenschwere; sämtliche andere Software ist Klasse I (ebenda).
• Art. 10 Abs. 9 MDR: Pflicht zur Einrichtung, Dokumentation und Aufrechterhaltung eines Qualitätsmanagementsystems (ebenda).
• Art. 15 MDR: für die Einhaltung der Regulierungsvorschriften verantwortliche Person, mit der Sonderregel für Kleinst- und Kleinunternehmen in Absatz 2 (ebenda).
• Art. 2 Nr. 1 MDR: Definition des Medizinprodukts über die medizinische Zweckbestimmung (ebenda).
• Toolpreise: Stand unserer Toolseiten, siehe Greenlight Guru , meddevo und Formwork . Greenlight Guru und meddevo nennen keine öffentlichen Listenpreise.
• Vendr, Greenlight Guru: Marktdaten zu Vertragswerten, Median im mittleren fünfstelligen US-Dollar-Bereich pro Jahr, ohne Angabe zu Stichprobe und Erhebungsjahr (vendr.com/marketplace/greenlight-guru, abgerufen am 03.10.2026).
• Art. 28 DSGVO (AVV): Datenschutz-Grundverordnung in der aktuell gültigen Fassung (gesetze-im-internet.de/dsgvo/, abgerufen am 18.09.2026).
• Nicht belegbar und deshalb nicht mehr auf dieser Seite: die Angabe, 71 Prozent der Notified Bodies berichteten über mehr als 13 Monate Zertifizierungsdauer, die Angabe, 75 Prozent der Ablehnungen beruhten auf unvollständigen Unterlagen, und eine Stundenspanne für die Ersterstellung der technischen Dokumentation. Die ersten beiden ließen sich nur über Beratungs-Blogs belegen, deren gemeinsame Primärquelle wir nicht öffnen konnten, die dritte stützte sich auf Projekterfahrung, die es hier nicht gibt.
• Keine Rechtsberatung. Dieser Text ordnet Normen ein, er ersetzt keine Prüfung des Einzelfalls, keine Auskunft eurer Benannten Stelle und keine eigene Prüfung gegen den Primärtext.

Du willst wissen, welcher Tool-Ansatz für euren spezifischen Produkttyp und eure Teamgröße sinnvoll ist? Meld dich, das besprechen wir konkret in einem kurzen Gespräch.