EU AI Act Enforcement-Deadline — 2. August 2026 Jetzt prüfen →
Live-Beispiel · Art. 13 EU AI Act

Instructions-for-Use-Generator: Medizinisches Diagnose-KI-System (Annex I MDR-Software)

KI-System zur Bildanalyse + Diagnose-Unterstützung als Medizinprodukt nach MDR. Annex I (Produktsicherheit) — vollständig generiertes Beispiel-Dokument.

HochrisikoAnnex I (Sicherheits­komponente Medizinprodukt)MDR / IVDR Medical Device1043 Wörter · 86 Platzhalter

Free-Tier ohne Kreditkarte · Engine läuft live · 5 Minuten zum eigenen Dokument

Beispiel-Dokument: Dieses Dokument wurde live generiert auf Basis fiktiver Eingaben für „MedAI-Diagnostic". Es ersetzt keine Rechtsberatung. Platzhalter mit 〔...〕 markieren Stellen, die im echten Dokument vom Compliance-Officer ergänzt werden müssen.

Instructions for Use — MedAI-Diagnostic

Live-generated · Engine v4.15

Instructions for Use — MedAI-Diagnostic

FeldWert
Provider[Beispiel-Unternehmen GmbH]
KI-SystemMedAI-Diagnostic
Version dieser Instructions〔z.B. v1.0〕
Datum2026-05-13
ZielgruppeDeployer / einsetzende Stelle
SpracheDeutsch (de-CH/DE/AT)
> Rechtsgrundlage: Art. 13 EU AI Act. Diese Instructions müssen jedem Deployer vor Inbetriebnahme bereitgestellt werden. Bei Hochrisiko-Systemen (high_risk) ist die Bereitstellung zwingend.

---

1. Provider-Identifikation (Art. 13(3)(a))

FeldWert
Unternehmen[Beispiel-Unternehmen GmbH]
Adresse〔Strasse, Postleitzahl, Stadt, Land〕
Authorized Representative (falls non-EU Provider)〔Name + EU-Adresse〕
Kontakt — allgemeine Anfragen〔E-Mail〕
Kontakt — Sicherheits-Vorfälle (24/7)〔E-Mail / Hotline〕
Website / Documentation-Portal〔URL〕
Versions-Updates / Changelog〔URL〕

---

2. System-Eigenschaften und Leistungsfähigkeit (Art. 13(3)(b))

2.1 Beabsichtigte Zweckbestimmung

Das System MedAI-Diagnostic ist dafür bestimmt, 〔Anwendungsbereich konkret beschreiben〕 zu unterstützen.

Konkreter Einsatzbereich: 〔Hier konkret beschreiben, wofür das System designt wurde. Wichtig: Abweichungen von dieser Zweckbestimmung können Substantial-Modification (Art. 25) auslösen und den Deployer zum Provider machen.〕

2.2 Eigenschaften und Funktionen

  • Eingabe-Typen: 〔z.B. Text / Bild / Strukturierte Daten / Audio〕
  • Ausgabe-Format: 〔z.B. Klassifikations-Score / Empfehlung / Generierter Text〕
  • Konfidenz-Indikatoren: 〔Ja/Nein — wenn ja, in welcher Skala〕
  • Modus: unterstützend (assisted) — KI-Empfehlung, Mensch entscheidet final

2.3 Genauigkeit und Performance

MetrikWert (Test-Set)Erwartete Produktions-Performance
〔Hauptmetrik, z.B. Accuracy〕〔Wert〕〔Wert〕
〔Sekundäre Metrik, z.B. F1〕〔...〕〔...〕
Inferenz-Latenz P50〔ms〕〔ms〕
Inferenz-Latenz P95〔ms〕〔ms〕

2.4 Bekannte Leistungs-Limitationen

〔Konkrete Limitationen: z.B. niedrigere Genauigkeit bei seltenen Klassen / spezifischen Demographien / bestimmten Sprachen / Edge-Cases.〕

---

3. Risiken und Vorsichts-Massnahmen (Art. 13(3)(c))

3.1 Engine-detected Risiken

  • ANNEXIDEADLINE2027: annex i deadline 2027
  • DEADLINEANNEXI2027: deadline annex i 2027

3.2 Vorhersehbare Risiken

RisikoWahrscheinlichkeitAuswirkungMitigation durch Deployer
〔z.B. Bias gegen unterrepräsentierte Gruppen〕〔Niedrig/Mittel/Hoch〕〔...〕〔z.B. Stichproben-Audit〕
〔z.B. Concept-Drift bei Daten-Verschiebung〕〔...〕〔...〕〔z.B. Re-Training alle 6 Monate〕
〔z.B. Adversarial-Inputs〕〔...〕〔...〕〔z.B. Input-Validation + Rate-Limiting〕

3.3 Wann das System NICHT verwendet werden sollte

  • 〔Spezifische Edge-Cases, in denen das System nicht designt ist〕
  • 〔Use-Cases ausserhalb der Zweckbestimmung — würden Substantial-Modification auslösen〕
  • 〔Demographische Gruppen, für die das System nicht ausreichend getestet wurde〕

---

4. Hardware- und Software-Anforderungen (Art. 13(3)(d))

4.1 Hardware

KomponenteMinimumEmpfohlen
CPU〔...〕〔...〕
RAM〔...〕〔...〕
GPU〔falls erforderlich〕〔...〕
Storage〔...〕〔...〕
Netzwerk〔Bandbreite + Latenz-Anforderung〕〔...〕

4.2 Software

KomponenteAnforderung
OS〔Linux / Windows / macOS〕
Runtime〔z.B. Python 3.11+, Node.js 20+, Docker〕
Browser (falls Web-UI)〔Chrome 100+, Firefox 100+, Safari 16+〕
Datenbank〔falls Self-Hosted〕

4.3 Cloud-Modus

〔Falls SaaS: welche Datenresidency, welche Cloud-Provider, welche Datenflüsse? Wichtig für Schweizer Deployer mit Datenresidency-Anforderungen.〕

---

5. Output-Interpretation (Art. 13(3)(e))

5.1 Wie ist der Output zu lesen?

〔Konkrete Anleitung: was bedeutet ein Confidence-Score von 0.85? Welche Schwellen-Werte sollten Deployer als Entscheidungs-Hilfe nehmen?〕

5.2 Empfohlene Entscheidungs-Logik

Wenn Confidence ≥ 〔Threshold A〕〔Aktion 1〕
Wenn Confidence ∈ [〔B〕, 〔A〕)   → 〔Eskalation an Mensch〕
Wenn Confidence < 〔Threshold B〕〔Ablehnung / Manuelle Bearbeitung〕

5.3 Erklärungs-Mechanismen (Art. 13(3)(f))

〔Bietet das System Erklärungen (z.B. SHAP, LIME, Attention-Maps)? Wie werden diese im UI dargestellt?〕

---

6. Menschliche Aufsicht (Art. 13(3)(g) + Art. 14)

6.1 Aufsichts-Rolle des Deployers

Der Deployer muss sicherstellen, dass die finale Entscheidung von einer qualifizierten natürlichen Person getroffen wird, die die KI-Empfehlung kritisch bewertet.

6.2 Was der Aufsichts-Verantwortliche können muss

  • Verstehen: Output-Interpretation, Konfidenz-Werte, Limitationen
  • Erkennen: Anomalien, Drift-Signale, Bias-Indikatoren
  • Eingreifen: Override-Mechanismus benutzen, System pausieren
  • Dokumentieren: Override-Begründung, Eskalations-Trail

6.3 Empfohlene Schulungs-Inhalte für Aufsichts-Verantwortliche

1. 〔Modul 1: System-Funktion und Limitationen (1h)〕 2. 〔Modul 2: Output-Interpretation und Konfidenz-Werte (1h)〕 3. 〔Modul 3: Override-Mechanismus und Eskalation (30 min)〕 4. 〔Modul 4: Bias-Recognition und Red-Flags (1h)〕 5. 〔Modul 5: Notfall-Verfahren (30 min)〕

6.4 KI-Literacy nach Art. 4

Alle Personen, die mit dem System interagieren, müssen ein Mindestmass an KI-Kompetenz haben. Empfehlung: jährliche Auffrischungs-Schulung.

---

7. Lebenszyklus und Wartung (Art. 13(3)(h))

7.1 Erwartete Nutzungsdauer

〔z.B. Modell wird alle 12 Monate neu trainiert; System wird bis 〔Datum〕 unterstützt.〕

7.2 Update-Politik

Update-TypFrequenzKommunikations-KanalDeployer-Aktion erforderlich?
Sicherheits-PatchBei Bedarf〔E-Mail / Portal〕〔Ja, innerhalb X Tage〕
Modell-Update (minor)Quartalsweise〔Changelog〕〔Nein / Optional〕
Modell-Update (major)Jährlich〔Mitteilung 30 Tage im Voraus〕〔Re-Validation empfohlen〕
Substantial ModificationAuf Provider-Entscheidung〔Mitteilung 90 Tage im Voraus〕〔Re-FRIA / Re-Assessment erforderlich〕

7.3 End-of-Life

〔Wann wird das System ausser Betrieb genommen? Wie werden Deployer informiert? Wie lange werden Logs aufbewahrt?〕

7.4 Datenpersistenz und Compliance

〔Welche Daten werden für wie lange aufbewahrt? Wie werden Lösch-Anfragen (Art. 17 DSGVO) bearbeitet?〕

---

8. Konformität und Versions-Historie

8.1 Compliance-Erklärung

Hiermit bestätigt [Beispiel-Unternehmen GmbH], dass das System MedAI-Diagnostic nach folgenden Standards entwickelt und dokumentiert wurde:

  • Art. 6(1) EU AI Act, Annex I EU AI Act

Konformitäts-Erklärung (Art. 47 EU AI Act): 〔Verweis auf separates Dokument oder URL〕

8.2 Versions-Historie

VersionDatumWesentliche Änderung
〔v1.0〕〔YYYY-MM-DD〕Initial release
〔v1.1〕〔...〕〔...〕

---

9. Kontakt für Sicherheits-Vorfälle

Bei Erkennen eines schwerwiegenden Vorfalls (Art. 73 EU AI Act):

1. Sofort melden an: 〔E-Mail / Hotline〕 2. Provider hat 15 Tage zur Meldung an die nationale Marktaufsichtsbehörde (BNetzA (zentrale Stelle für AI Act in Deutschland)) 3. Korrektur-Massnahmen werden gemeinsam abgestimmt

---

> Diese Instructions for Use wurden am 2026-05-13 mit ai-risk-check.com (Engine AI-ACT-2024-1689-v5.12.0) als Vorlage erstellt. Die finalen Instructions müssen vom Provider validiert und unterzeichnet werden. > > Audit-Trail-Hash: 〔Hash aus Audit-Package einfügen〕

Erzeuge dasselbe Dokument für DEIN System

5 Minuten Wizard · Engine klassifiziert nach 491 validierten EU-AI-Act-Cases · im Professional-Plan inklusive (€89/Mt.)

Rechtlicher Hinweis

Dieses Beispiel-Dokument wurde live generiert von der ai-risk-check Compliance-Engine v4.15 auf Basis fiktiver Wizard-Eingaben für „MedAI-Diagnostic". Es stellt keine Rechtsberatung dar und ist nicht für die direkte Verwendung in der eigenen Compliance-Praxis vorgesehen. Für die Erstellung Deines eigenen Compliance-Dokuments führe das vollständige Assessment durch — die Engine bezieht dann Deine spezifischen Country-, Industry- und Use-Case-Inputs ein und passt das generierte Dokument entsprechend an.

Instructions-for-Use-Generator Beispiel: Medizinisches Diagnose-KI-System (Annex I MDR-Software) | ai-risk-check | ai-risk-check.com