MDR trifft EU AI Act: Das Trilemma für KI-Software

KI-Software im medizinischen Kontext wird gern als reines Zulassungsthema behandelt: erst die MDR (Verordnung (EU) 2017/745) erfüllen, dann sehen, ob der EU AI Act (Verordnung (EU) 2024/1689) noch etwas obendrauf verlangt. Genau diese Reihenfolge führt in die Irre. Die beiden Verordnungen greifen nicht nacheinander, sondern auf demselben Produkt gleichzeitig. Wer sie als getrennte Projekte mit eigenen Teams und eigenen Aktensätzen aufsetzt, baut die teuerste Variante: zwei Dokumentationswelten, die voneinander abweichen, sich gegenseitig widersprechen und im Audit beide auffallen.

Warum aus zwei Verordnungen ein Trilemma wird

Das Problem hat drei Pole. Die MDR fragt, ob Ihre Software ein Medizinprodukt ist und in welche Risikoklasse sie fällt. Der AI Act fragt, wie das KI-System gebaut, trainiert und überwacht wird. Und beide verlangen am Ende einen Nachweis auf demselben Artefakt, der Software, die beim Patienten ankommt.

Der Hebel liegt in Art. 6 Abs. 1 EU AI Act: Eine KI gilt als Hochrisiko-KI, wenn sie Sicherheitskomponente eines Produkts ist oder selbst ein Produkt darstellt, das nach Harmonisierungsrecht wie der MDR oder der IVDR (Verordnung (EU) 2017/746) einer Konformitätsbewertung durch eine Benannte Stelle unterliegt. Damit ist die MDR- bzw. IVDR-Klassifizierung der Trigger für die AI-Act-Einstufung. Software, die als Medizinprodukt einer Benannten Stelle vorgelegt werden muss, fällt in aller Regel automatisch in die strengste Stufe des AI Act. Die regulatorische Einstufung nach Produktrecht entscheidet also nicht nur über die MDR-Pflichten, sondern öffnet zugleich die Tür zu einem zweiten Pflichtenkatalog.

Was der AI Act über die MDR hinaus verlangt

Steht die Einstufung als Hochrisiko-KI fest, greifen die Anforderungen aus Art. 8 bis 15 EU AI Act. Viele davon haben ein MDR-Pendant, sind aber nicht identisch:

• Risikomanagement (Art. 9): Ein kontinuierliches Risikomanagementsystem, das sich mit dem MDR-Risikomanagement nach ISO 14971:2019 überschneidet, aber KI-spezifische Risiken wie Modelldrift und Fehlverhalten bei untypischen Eingaben ausdrücklich adressieren muss.
• Daten-Governance (Art. 10): Hier wird es für viele Hersteller eng. Der AI Act verlangt belegte Repräsentativität der Trainings-, Validierungs- und Testdaten sowie einen Bias-Review. Das geht über das übliche Niveau der ML-Entwicklung hinaus und hat in der klassischen MDR-Technischen Dokumentation kein direktes Gegenstück.
• Technische Dokumentation (Art. 11 + Anhang IV): Ein eigener Dokumentationskatalog, der sich mit der MDR-Technischen Dokumentation überlappt, aber zusätzliche Inhalte zu Systembeschreibung, Trainingsdaten und Leistungsmetriken fordert.
• Menschliche Aufsicht (Art. 14): Sie muss als Designprinzip implementiert und nachgewiesen sein. Dass ein Anwender theoretisch eingreifen könnte, genügt ohne dokumentierten Mechanismus nicht.
• Genauigkeit, Robustheit, Cybersicherheit (Art. 15): Eng verwandt mit den MDR-Anforderungen und der Software-Sicht aus IEC 62304, aber mit eigenem Fokus auf die statistische Leistungsfähigkeit des Modells.

Der entscheidende Punkt: Es sind nicht zwei völlig fremde Welten, sondern stark überlappende Anforderungen mit unterschiedlichem Akzent. Genau diese Überlappung ist die Chance, und zugleich die Falle, wenn man sie ignoriert.

Die typischen Stolperfallen an der Schnittstelle

In der Praxis scheitern diese Projekte selten an einer einzelnen Anforderung, sondern an der Organisation der Schnittstelle:

• Doppelte Aktenführung. AI Act und MDR werden als separate Vorhaben geführt, jedes mit eigenem Dokumentensatz. Das Ergebnis sind redundanter Pflegeaufwand und Versionsstände, die auseinanderlaufen. Ein Risiko, das in der MDR-Akte als „mitigiert" steht, taucht in der AI-Act-Akte unverändert offen auf, und beide Versionen liegen der Benannten Stelle vor.
• Klassifizierung ohne Dokumentation. Die Hochrisiko-Einstufung wird intern besprochen, aber nicht formal festgehalten. Art. 9 EU AI Act verlangt ein dokumentiertes Risikomanagementsystem; eine nur diskutierte Einstufung gilt im Audit als nicht erfüllt.
• Daten-Governance auf ML-Niveau. Trainingsdaten werden wie in einem gewöhnlichen ML-Projekt behandelt, ohne Quellennachweis, Bias-Review und Repräsentativitätsbeleg nach Art. 10. Damit bleibt eine zentrale Hochrisiko-Anforderung offen, obwohl das Modell selbst funktioniert.
• Fehlende Verzahnung im Post-Market. Das KI-Monitoring nach Art. 72 EU AI Act läuft getrennt von der MDR-Post-Market-Surveillance. Beobachtungen zu Modellperformanz und unerwünschten Ausgaben fließen dann nicht in dieselbe Bewertung wie die übrigen Felddaten.

Hinzu kommt der zeitliche Versatz. Für KI, die als Produkt oder Sicherheitskomponente unter MDR oder IVDR fällt (Hochrisiko-KI nach Anhang I), greift die längere Übergangsfrist des AI Act. Im Zuge der jüngsten Anpassungen am AI Act wurde diese Frist für die Anhang-I-Fälle nach hinten verschoben. Das ist kein klassischer Puffer: Teile des regulatorischen Rahmens, etwa harmonisierte Normen und Leitlinien, sind in dieser Phase noch nicht vollständig ausdefiniert. Wer auf endgültige Klarheit wartet, verliert die Zeit, die für die Integration in die laufende Entwicklung nötig wäre.

Was zu tun ist

Der Ausweg aus dem Trilemma ist kein dritter Aktenstapel, sondern ein integriertes Framework. Drei Schritte sind tragend:

1. Zuerst klassifizieren. Die MDR-/IVDR-Risikoklasse bestimmt über Art. 6 Abs. 1 die AI-Act-Einstufung. Beides muss dokumentiert vorliegen, bevor sich der Pflichtenumfang ableiten lässt.
2. Anforderungen mappen statt verdoppeln. Die Pflichten nach Art. 8 bis 15 werden auf die bestehende MDR-Technische Dokumentation, das QMS und den Software-Lebenszyklus nach IEC 62304 abgebildet. Jede Anforderung wird einmal belegt und konsistent gepflegt. Ein KI-Managementsystem nach ISO/IEC 42001:2023 kann dabei den organisatorischen Rahmen liefern.
3. Post-Market verzahnen. Das Monitoring nach Art. 72 wird in die MDR-/IVDR-Post-Market-Surveillance eingebettet, damit Modelldrift und Felddaten in einer Bewertung zusammenlaufen.

Entourage setzt genau an dieser Schnittstelle an: Klassifizierung nach Produktrecht und AI Act, ein Mapping der Anforderungen ohne doppelte Dokumentation und die Integration in das bestehende QMS. So bleibt aus zwei Verordnungen ein Nachweis pro Anforderung statt zwei voneinander abweichende Aktenwelten.