Compliance-by-Design bei KI-Medizinprodukten

Compliance-by-Design bei KI-Medizinprodukten bedeutet, regulatorische Anforderungen während der Entwicklung frühzeitig zu berücksichtigen und zu dokumentieren. Der Unterschied ist praktisch relevant, denn ein Teil der nach MDR, IVDR und AI Act erforderlichen Nachweise basiert auf Entscheidungen, die im Entwicklungsverlauf getroffen werden. Werden diese Entscheidungen nicht getroffen oder nicht dokumentiert, lassen sie sich später nicht oder nur schwer rekonstruieren. Betroffen sind unter anderem die Herkunft und Aufteilung der Trainingsdaten, die vorab festgelegten Akzeptanzkriterien und der Änderungsrahmen des Modells.

Die Verschiebung der Hochrisikoanforderungen des AI Act auf den 2. August 2028 ändert daran wenig. Die Anforderungen aus MDR und IVDR gelten unverändert, und Produkte, die heute entwickelt werden, treffen absehbar auf den vollständigen, neuen Anforderungsrahmen. Dieser Beitrag beschreibt wesentliche, daraus resultierende Entscheidungen im Entwicklungsprozess eines KI-Medizinprodukts und ihre regulatorischen Folgen.

Compliance-by-Design im Sinne von MDR, IVDR und AI Act

Compliance-by-Design ist weder in MDR, IVDR oder AI Act noch in den einschlägigen MDCG-Dokumenten als Rechtsbegriff definiert. Der Begriff bezeichnet eine Entwicklungsvorgehensweise, bei der regulatorische Anforderungen bereits bei Zweckbestimmung, Systemauslegung, Datenauswahl und Validierung berücksichtigt und die maßgeblichen Entscheidungen nachvollziehbar dokumentiert werden.

Diese Vorgehensweise lässt sich zunächst aus MDR und IVDR ableiten. Art. 10 Abs. 2 verpflichtet den Hersteller, ein Risikomanagementsystem einzurichten und aufrechtzuerhalten. Anhang I Abschnitt 3 konkretisiert dieses als kontinuierlichen, iterativen Prozess über den gesamten Produktlebenszyklus. Nach Abschnitt 4 sind Risiken vorrangig durch sichere Auslegung und Herstellung, danach durch Schutzmaßnahmen und erst nachrangig durch Sicherheitsinformationen zu beherrschen. Die Risikobeherrschung muss damit bereits in der Entwicklung und konstruktiven Auslegung ansetzen.

Der AI Act folgt demselben Grundgedanken. Art. 9 verlangt ein Risikomanagement über den gesamten Lebenszyklus. Die Anforderungen an Daten-Governance, Protokollierung, menschliche Aufsicht, Genauigkeit, Robustheit und Cybersicherheit nach Art. 10, 12, 14 und 15 müssen in Datenbasis, Architektur und Benutzerschnittstelle einfließen. Sie lassen sich nicht allein nach Entwicklungsabschluss durch Dokumentation erfüllen. Art. 8 Abs. 2 erlaubt, die dafür erforderlichen Prozesse in die bestehenden Prozesse nach MDR oder IVDR zu integrieren.

Die Guidance AIB 2025-1 / MDCG 2025-6 bestätigt die gleichzeitige und komplementäre Anwendung der Rechtsrahmen. Ein KI-basiertes Medizinprodukt ist nach Art. 6 Abs. 1 AI Act ein Hochrisiko-KI-System, wenn das KI-System selbst Produkt oder Sicherheitsbauteil ist und die Konformitätsbewertung nach MDR oder IVDR die Beteiligung einer Benannten Stelle erfordert. Die MDR- beziehungsweise IVDR-Risikoklasse wird dadurch nicht verändert.

Compliance-by-Design fasst diese Vorgaben als Entwicklungsvorgehensweise zusammen, d.h. regulatorisch relevante Entscheidungen werden zu dem Zeitpunkt getroffen, zu dem sie noch wirksam in Datenbasis, Architektur, Benutzerschnittstelle, Risikokontrollen und Prüfkonzept einfließen können. Sie werden begründet, versioniert und so dokumentiert, dass die spätere Konformitätsbewertung auf nachvollziehbaren Entwicklungsnachweisen beruht.

Nachweise, die sich nachträglich nicht mehr erbringen lassen

Viele Dokumentationslücken lassen sich nachträglich schließen. Bei KI-Medizinprodukten gilt dies jedoch nicht für Nachweise, die auf Entscheidungen und Daten aus dem Entwicklungsprozess beruhen. Die folgenden vier Beispiele zeigen diese Grenze.

Datenherkunft und Annotationshistorie:
Art. 10 AI Act verlangt geeignete Daten-Governance- und Datenmanagementverfahren. Die technische Dokumentation nach Anhang IV muss die Datensätze und ihre Herkunft beschreiben. Wurde die Herkunft einzelner Datenbestände nicht erfasst, ist sie später oft nicht mehr zu belegen. Gleiches gilt für die Annotationskriterien und Qualifikation der Annotierenden.

Trennung von Trainings- und Testdaten:
Wurden Daten desselben Patienten oder derselben Aufnahmeserie sowohl im Training als auch im Test verwendet, ist die ermittelte Leistung des Produkts nicht belastbar. Eine entsprechende Dokumentation löst dieses Problem nicht, so dass ggf. ein erneutes Training und eine erneute Bewertung erforderlich sind.

Vorab festgelegte Akzeptanzkriterien:
Werden Metriken und Schwellenwerte erst nach Vorliegen der Ergebnisse ausgewählt, kann der Verdacht einer nachträglichen Auswahl günstiger Kennzahlen entstehen. Benannte Stellen fragen den Zeitpunkt der Festlegung ab und verlangen den datierten Prüfplan als Nachweis.

Vorab festgelegter Änderungsrahmen des Modells:
Nach Art. 43 Abs. 4 AI Act gelten Änderungen an einem weiterlernenden Hochrisiko-KI-System, die der Anbieter bereits zum Zeitpunkt der ursprünglichen Konformitätsbewertung festgelegt und in der technischen Dokumentation beschrieben hat, nicht als wesentliche Änderung. Die erforderliche Vorabfestlegung kann nach einer Modelländerung nicht rückwirkend nachgeholt werden.

Wichtige Entscheidungen im Entwicklungsprozess

Die folgende Übersicht ordnet typische Entwicklungsentscheidungen ihrer regulatorischen Wirkung zu.

Entscheidung im Entwicklungsprozess	Regulatorische Wirkung
Zweckbestimmung, einschließlich Zielpopulation und Anwendungskontext	Bestimmt Klassifizierung nach Anhang VIII MDR bzw. IVDR, Umfang der klinischen bzw. Leistungsbewertung und damit maßgeblich auch, ob nach Art. 6 Abs. 1 AI Act ein Hochrisiko-KI-System vorliegt.
Auswahl, Aufteilung und Versionierung der Datensätze	Bestimmt die Belastbarkeit der Leistungsaussagen und die Erfüllbarkeit von Art. 10 AI Act. Fehler können eine neue Datenaufteilung, erneute Bewertung oder erneutes Training erfordern.
Festlegung der Leistungsziele und Akzeptanzkriterien	Bestimmt, anhand welcher Kriterien technische, klinische bzw. analytische Leistung nachgewiesen wird. Eine spätere Festlegung beeinträchtigt die Belastbarkeit des Nachweises.
Einbindung eines Drittmodells oder einer externen Modell-API	Lässt die Verantwortung des Herstellers für das Medizinprodukt unberührt. Erfordert Lieferantenlenkung, vertragliche Regelungen zu Leistung, Änderungen, Verfügbarkeit und Abkündigung sowie ggf. eine SOUP-Einordnung nach IEC 62304.
Ausgestaltung der Mensch-Maschine-Schnittstelle	Bestimmt die Wirksamkeit der menschlichen Aufsicht nach Art. 14 AI Act und ist Gegenstand der Gebrauchstauglichkeitsbewertung nach IEC 62366-1. Ergänzend müssen organisatorische Maßnahmen berücksichtigt werden.
Vorabfestlegung des Änderungsrahmens für Modellversionen	Bestimmt nach Art. 43 Abs. 4 AI Act, welche vorab festgelegten und dokumentierten Änderungen des Systems und seiner Leistung nicht als wesentliche Änderung gelten.
Planung der Überwachung nach dem Inverkehrbringen	Bestimmt Kennzahlen, Überwachungsintervalle und Schwellenwerte für Leistungsabweichungen, Untergruppenunterschiede sowie Daten- und Konzeptdrift. Setzt geeignete Protokollierungs- und Datenzugriffsmöglichkeiten voraus.
Architektur der Protokollierung	Bestimmt die Erfüllbarkeit von Art. 12 AI Act und die Verfügbarkeit relevanter Daten für das Post-Market Monitoring. Eine spätere Anpassung kann erhebliche Änderungen an der Softwarearchitektur erfordern.

Die Zweckbestimmung bildet die Grundlage für die nachfolgenden Entwicklungsentscheidungen. Die Protokollierung wird zwar zuletzt aufgeführt, sollte jedoch frühzeitig in die Entwicklung einbezogen werden.

Verankerung im Qualitätsmanagementsystem und in der technischen Dokumentation

Die Entwicklungsentscheidungen sollten definierten Dokumenten des Qualitätsmanagementsystems (QMS) und der technischen Dokumentation zugeordnet werden. Hierfür kommen insbesondere die folgenden Dokumente in Betracht:

Entwicklungsplan nach IEC 62304: Datenmanagement, Modellentwicklung, Verifikation und Validierung.
Datenmanagementplan: Herkunft, Auswahl, Annotation, Aufteilung und Versionierung der Daten.
Risikomanagementakte nach ISO 14971: Daten-, Modell-, Untergruppen- und Daten- bzw. Konzeptdriftrisiken sowie Automation Bias.
Lieferanten- und SOUP-Dokumentation: Drittmodelle, externe Dienste, Änderungen und Produktabkündigungen.
Gebrauchstauglichkeitsakte nach IEC 62366-1: Benutzerschnittstelle und menschliche Aufsicht.
Technische Dokumentation: KI-spezifische Inhalte nach Anhang IV AI Act einschl. Protokollierung und ggf. vorab festgelegtem Änderungsrahmen, integriert in die Dokumentation nach MDR bzw. IVDR.
Plan für die klinische Bewertung bzw. Leistungsbewertung: Klinische Aussagen, Leistungsziele und Akzeptanzkriterien sowie Nachweise zur klinischen Leistungsfähigkeit.
PMS-Plan: Überwachungsgrößen, Intervalle und Schwellenwerte einschließlich Daten- und Konzeptdrifterkennung.

Für die Ergänzung des QMS nach ISO 13485 kommen insbesondere EN 18286:2026 und ergänzend ISO/IEC 42001 in Betracht. EN 18286:2026 adressiert das QMS nach Art. 17 AI Act. ISO/IEC 42001 definiert ein organisationsweites Managementsystem für den verantwortungsvollen Einsatz von KI. Beide Normen sind nach derzeitigem Stand nicht harmonisiert.

Harmonisierte Normen zum AI Act: aktueller Stand

Der aktuelle Stand der AI Act bezogenen Normung ändert sich derzeit laufend. Zuständig ist das Gremium CEN-CENELEC JTC 21.

Im Juli 2026 wurde mit EN 18286:2026 „Artificial intelligence – Quality management system for EU AI Act regulatory purposes" die erste europäische Norm zur Umsetzung des AI Act veröffentlicht. Sie adressiert das QMS nach Art. 17 AI Act und ist nicht sektorspezifisch. Die Harmonisierung der EN 18286:2026 steht noch aus. Die QMS-Anforderungen der Norm ergänzen diejenigen nach MDR und IVDR.

Weitere Entwürfe befinden sich in der Erarbeitung, darunter prEN 18228 zum KI-Risikomanagement (Bezug zu Art. 9), prEN 18282 zu Cybersicherheitsanforderungen an KI-Systeme (Bezug zu Art. 15) und prEN 18229-1 zur Protokollierung (Bezug zu Art. 12). Die Veröffentlichungstermine sind nach derzeitigem Stand nicht gesichert. Kommt eine Norm nicht rechtzeitig zustande, kann die Kommission nach Art. 41 AI Act gemeinsame Spezifikationen erlassen. Die entsprechenden Normenentwürfe können bereits als Orientierung dienen, allerdings sind relevante Änderungen vor Veröffentlichung der jeweils finalen Fassung möglich. Zudem steht die Harmonisierung der Normen mit dem AI Act noch aus, so dass keine Konformitätsvermutung nach Art. 40 AI Act gilt.

Zeitliche Einordnung

Die Anforderungen des AI Act an Hochrisiko-KI-Systeme in Medizinprodukten bzw. IVD gelten ab dem 2. August 2028. Für laufende Entwicklungsvorhaben sollten sie jedoch bereits vor dem Design Freeze berücksichtigt werden, da sich Datenbasis, Modellarchitektur und Protokollierung danach häufig nur mit erheblichem Aufwand ändern lassen. Die nachweisrelevanten Entwicklungsentscheidungen sollten daher frühzeitig getroffen und ggf. mit der Benannten Stelle abgestimmt werden.

FAQ

Was gilt für ein Produkt, das vor dem 2. August 2028 in Verkehr gebracht wird?

Entscheidend ist Art. 111 Abs. 2 AI Act. Für Hochrisiko-KI-Systeme, die vor dem 2. August 2026 in Verkehr gebracht oder in Betrieb genommen wurden, greift der AI Act grundsätzlich nur bei späteren wesentlichen Änderungen der Konzeption. Für Produkte ab diesem Stichtag gelten die jeweils anwendbaren Fristen.

Wer ist Anbieter, wenn ein zugekauftes GPAI-Modell über eine API eingebunden wird?

Im Regelfall ist der Medizinproduktehersteller Anbieter des daraus entstehenden KI-Systems, wenn er dieses unter eigenem Namen in Verkehr bringt oder in Betrieb nimmt. Der GPAI-Modellanbieter hat eigene Pflichten.

Was passiert, wenn die Benannte Stelle nicht den erforderlichen Notifizierungsumfang abdeckt?

Die kombinierte Bewertung nach Art. 43 Abs. 3 AI Act setzt die entsprechenden Notifizierungen voraus. Ist das nicht der Fall, kann ein Wechsel der Benannten Stelle in Betracht gezogen werden.

Wann sollte die Benannte Stelle einbezogen werden?

Die Abstimmung sollte frühzeitig erfolgen, wenn Klassifizierung, KI-spezifische Nachweise oder geplante Modelländerungen Auswirkungen auf das Konformitätsbewertungsverfahren haben können.

Gibt es Erleichterungen für kleine Unternehmen und Startups?

Der AI Act sieht Unterstützungsmaßnahmen für kleine Unternehmen und Start-ups vor, u.a. einen erleichterten Zugang zu Reallaboren nach Art. 62. Die Anforderungen von MDR und IVDR bleiben allerdings unverändert.

Fazit

Compliance-by-Design bedeutet, regulatorisch relevante Entscheidungen frühzeitig zu treffen und nachvollziehbar zu dokumentieren, damit sie in die Produktentwicklung einfließen und als belastbare Nachweise für die Konformitätsbewertung dienen. Zweckbestimmung, Datenauswahl, Drittmodelle, Mensch-Maschine-Schnittstelle, Änderungsrahmen und Protokollierung bestimmen, welche Nachweise später möglich sind. Die zusätzliche Zeit bis zum 2. August 2028 und die noch fehlenden Normen ändern letztlich daran nur wenig, weil die Entscheidungen im laufenden Entwicklungsprojekt ohnehin getroffen werden müssen.

Wenn Sie prüfen möchten, an welchen Punkten Ihr Vorhaben steht und welche Entscheidungen wann und wie getroffen werden sollten, vereinbaren Sie gern ein unverbindliches Erstgespräch.

Compliance-by-Design bei KI-Medizinprodukten: wichtige Entscheidungen im Entwicklungsprozess

Haben Sie Fragen zu Ihrem Projekt oder Produkt?