IEC 62304 AI-Doku-Generator für MedTech

TL;DR

• In mittelständischen MedTech-Häusern ist die IEC-62304-Dokumentation der Engpass: ein Klasse-B-Modul kostet 6–12 Wochen reine Doku-Zeit pro Release, die Engineering-Arbeit oft nur zwei bis vier.
• Drei KI-Patterns sind 2026 reif: SRS-Drafting aus Jira/Azure DevOps, Traceability-Matrix-Generation und Risk-Management-File-Aggregation. Reproduzierbar 40–60 % weniger Engineering-Zeit für die regulatorische Dokumentation.
• Architektur: RAG über bestehende Engineering-Artefakte, kein Fine-Tuning. Halluzinations-Rate in laufenden Pilots unter 0,8 % auf Norm-Aussagen.
• Klinische Validierung, Risk-Akzeptanz-Entscheidungen und Reviewer-Signaturen bleiben beim Menschen. KI-Output ohne Signatur ist regulatorisch wertlos.

Warum die Doku, nicht der Code der Engpass ist

In einem MedTech-Haus mit 200–500 Mitarbeitenden — Heidelberg, Tuttlingen oder Erlangen — gilt eine ungeschriebene Regel: Die Software-Entwicklung ist schnell, die Dokumentation langsam. Ein Klasse-B-Modul kostet ein erfahrenes Team 6–12 Wochen reine Doku-Zeit pro Release, ein Klasse-C-Modul (Lebenserhaltung, kritische Diagnose) das Doppelte. Die Engineering-Arbeit selbst ist häufig in zwei bis vier Wochen erledigt.

Diese Asymmetrie ist nicht das Verschulden der Regulatory-Affairs-Manager. Sie ist die direkte Folge der IEC 62304 in Verbindung mit EU-MDR Anhang II und — seit 2026 — EU AI Act Article 9, sofern eine ML-Komponente an Bord ist. In genau diese Lücke fährt seit 2025 ein neuer Tool-Layer: KI-gestützte Doku-Generatoren mit RAG über bestehende Engineering-Artefakte.

Was IEC 62304 verlangt — und wo der Aufwand sitzt

IEC 62304 strukturiert den Software-Lifecycle in acht Pflicht-Bereiche: Entwicklungsplan, Anforderungsanalyse, Software-Architektur, Detailspezifikation, Implementierung mit Verifikation, Integration und Integrations-Test, System-Test, Release. Dazu ISO 14971 für Risikomanagement.

In der Praxis konzentriert sich der Engpass auf drei Artefakte: SRS, SDD und die Traceability-Matrix.

Wo KI heute belastbar funktioniert

Drei Patterns sind 2026 reif für die Mittelstands-Praxis.

• SRS-Drafting aus Jira/Azure DevOps: Ein RAG-System liest User-Stories, Akzeptanzkriterien und ADRs und erzeugt einen normgerechten SRS-Entwurf nach IEC 62304 §5.2. Ersparnis: 45–55 % Engineering-Zeit auf diesem Arbeitspaket.
• Traceability-Matrix-Generation: Das System verknüpft Anforderungs-IDs, Architektur-Komponenten, Code-Module (aus Git mit Conventional Commits) und Test-Cases. 60–70 % schneller als manuelles Pflegen.
• Risk-Management-File-Aggregation Klasse B/C: Hazards aus FMEA-Sheets, Test-Reports und Post-Market-Surveillance-Daten werden nach ISO 14971 Anhang E konsolidiert. Der QM-Lead validiert.

Was nicht in die Maschine gehört

Klinische Verifikation und Validierung: Aussagen über Sicherheit und Wirksamkeit bleiben beim Clinical Affairs Manager. Sicherheits-relevante Risk-Entscheidungen — acceptable, ALARP, unacceptable — entscheidet das Risk-Management-Board. Signaturen, Approvals und Audit-Trail-Verantwortung bleiben menschlich: KI-Output ohne Reviewer-Signatur ist regulatorisch wertlos.

Architektur-Pattern: RAG, nicht Fine-Tuning

Die häufigste Frage in Erstgesprächen: Müssen wir ein eigenes Modell trainieren? Antwort 2026: klar nein. Sinnvoll ist ein RAG-Layer über bestehende Engineering-Artefakte.

1. Indexierung: SRS-/SDD-Vorlagen, ISO-14971-Templates, Audit-Reports, QM-Handbuch in eine Vector-DB (Postgres+pgvector oder Weaviate, EU-Hosted).
2. Retrieval: 8–15 relevante Doku-Snippets pro Generation.
3. Generation: Claude Sonnet 4 oder vergleichbar, mit Quellenzitat auf jedes Engineering-Artefakt.
4. Citation-Constraint: Das System lehnt Aussagen ohne Quellenbeleg ab.

Halluzinations-Rate in laufenden Pilot-Mandaten: unter 0,8 % auf Norm-Aussagen.

Was der EU AI Act zusätzlich verlangt

Sobald eine ML-Komponente im Produkt steckt, kommt seit 2026 EU AI Act Article 9 als zweite Pflicht-Ebene dazu. Drei Punkte erweitern die klassische IEC-62304-Akte, ohne sie zu ersetzen:

• Datenqualitäts-Nachweis (Art. 10): Herkunft, Repräsentativität und Bias-Prüfung der Trainingsdaten dokumentieren — ein Bereich, in dem klassische Software-Doku schweigt.
• Logging und Nachvollziehbarkeit (Art. 12): Aufzeichnung der Modell-Outputs über den Lebenszyklus, damit Entscheidungen im Audit rekonstruierbar bleiben.
• Menschliche Aufsicht (Art. 14): der dokumentierte Nachweis, dass ein qualifizierter Reviewer jede sicherheitsrelevante Ausgabe freigibt.

Der Vorteil: Ein gut strukturierter RAG-Layer adressiert Datenherkunft und Logging ohnehin als Architektur-Eigenschaft. Die Doku entsteht dann als Nebenprodukt der sauberen Pipeline, nicht als nachgelagerte Pflichtübung.

Die ersten 90 Tage

Drei Vorarbeiten entscheiden über den Erfolg: strukturierte Engineering-Artefakte (saubere Jira-Felder, ADRs als Pflicht), ein indexierbares QM-Handbuch (Markdown statt PDF-Sammlung) und klare Reviewer-Rollen. Typischer Pilot-Pfad: ein Klasse-B-Modul mit Notified-Body-Release in sechs Monaten — RAG-Layer aufsetzen, SRS-Draft generieren, Traceability-Matrix bauen.

Azena begleitet MedTech-Häuser bei genau diesem Pfad: von der RAG-Architektur über die Pilot-Wahl bis zur produktiven Übergabe an Regulatory Affairs und IT-Betrieb.

Stand Mai 2026.