Medical AI unter DSGVO und MDR: Der Architektur-Leitfaden 2026

Ab dem 2. August 2027 greift der EU AI Act voll für Hochrisiko-Systeme. Zusammen mit MDR und DSGVO entsteht damit das strengste regulatorische Umfeld für Medical AI weltweit. Drei Schichten, die alle gleichzeitig anwendbar sind, sich teilweise widersprechen und in der Praxis kaum jemand sauber zusammenbringt.

Wir bei NeuralMedic haben in den letzten 18 Monaten Architektur-Reviews für KI-Systeme in Kliniken, MedTech-Startups und diagnostischen Plattformen gemacht. Das Ergebnis ist ernüchternd: Vier von fünf Architekturen scheitern beim ersten Durchlauf an mindestens einer regulatorischen Anforderung. Meist nicht an spektakulären Verstößen — sondern an Standard-Cloud-Defaults, die niemand mehr hinterfragt. Dieser Leitfaden zeigt, welche Patterns durch ein Audit kommen, welche nicht, und was eine compliance-konforme Architektur in der Realität kostet.

1. Die drei Regulierungs-Schichten: DSGVO, MDR und EU AI Act

Wer Medical AI in Deutschland produktiv betreibt, hat es nicht mit einer Regulierung zu tun, sondern mit drei — die übereinander liegen und sich teilweise überschneiden.

DSGVO (Verordnung 2016/679) ist die Grundschicht. Sie greift, sobald personenbezogene Daten verarbeitet werden — und Patientendaten sind das per Definition. Relevant für ML-Architekturen sind vor allem Art. 5 (Grundsätze der Datenverarbeitung), Art. 9 (besondere Kategorien personenbezogener Daten, dazu gehören Gesundheitsdaten), Art. 25 (Privacy by Design and by Default), Art. 32 (technische und organisatorische Sicherheitsmaßnahmen) und Art. 35 (Datenschutz-Folgenabschätzung, kurz DSFA). Für Medical AI ist eine DSFA praktisch immer Pflicht.

MDR (Medical Device Regulation 2017/745) greift, sobald die Software als Medizinprodukt klassifiziert ist. Diagnostische KI-Systeme landen typischerweise in Klasse IIa oder IIb — abhängig vom Risiko der Fehldiagnose. Mit der MDR-Klassifizierung kommen Conformity Assessment durch eine Benannte Stelle, vollständige technische Dokumentation nach Annex II, Post-Market Surveillance und Vigilance-Reporting an die zuständige Behörde, in Deutschland das BfArM.

EU AI Act (Verordnung 2024/1689) ist die jüngste Schicht und ändert die Spielregeln deutlich. Medical AI fällt fast immer unter die Hochrisiko-Kategorie nach Anhang III bzw. — bei Medizinprodukten — direkt über Art. 6 in Verbindung mit Anhang I. Das bedeutet: Risk Management System nach Art. 9, Data Governance nach Art. 10, technische Dokumentation nach Art. 11, Logging-Pflichten nach Art. 12, Transparenz nach Art. 13, Human Oversight nach Art. 14 und Accuracy/Robustness/Cybersecurity nach Art. 15.

Die entscheidende Erkenntnis: Diese drei Schichten stacken. Eine MDR-Konformitätsbewertung ersetzt keine DSFA. Ein gutes DSGVO-Pseudonymisierungskonzept ersetzt kein AI-Act-Logging. Und keine der drei Regulierungen erlaubt, die anderen zu ignorieren.

2. Architektur-Patterns, die DSGVO-konform sind

Compliance-konforme Architektur folgt einer kleinen Zahl wiederkehrender Patterns. Wir bauen sie seit Jahren in genau dieser Form — sie haben durch Audits durch TÜV, BSI und Notified Bodies getragen.

Pseudonymisierungs-Layer am Eingang des ML-Stacks. Bevor irgendetwas in die Trainings- oder Inferenz-Pipeline geht, läuft ein dedizierter Pseudonymisierungs-Service. Der Service ersetzt direkte Identifikatoren (Name, Versicherungsnummer, Geburtsdatum) durch Pseudonyme. Das Mapping zwischen Pseudonym und realer Identität liegt in einem separaten System mit eigener IAM-Boundary — anderer AWS-Account, andere KMS-Keys, anderes Audit-Logging. Die ML-Engineers haben prinzipiell keinen Zugriff auf das Mapping. Das ist Art. 25 DSGVO in Architektur übersetzt.

Trainings-Umgebung in EU-Region mit Customer-Managed Keys. Frankfurt (eu-central-1) oder Dublin (eu-west-1), abhängig vom Cloud-Provider. KMS-Keys sind Customer-Managed, nicht AWS-Managed. Das macht einen Unterschied bei Sub-Processor-Diskussionen mit dem Datenschutzbeauftragten. S3-Buckets haben Block Public Access aktiv, Versionierung aktiv, Default Encryption mit dem Customer-Managed Key.

Inferenz strikt getrennt von Training. Zwei separate VPCs, zwei separate IAM-Rollen, zwei separate Audit-Trails. Inferenz hat keinen Schreibzugriff auf Trainingsdaten, Training hat keinen Zugriff auf Produktions-Inferenz-Logs. Diese Trennung ist nicht nur sauber, sondern erleichtert die Argumentation beim Audit erheblich.

Audit-Log jeder Inferenz. Jede einzelne produktive Inferenz erzeugt einen Audit-Eintrag mit: Modell-SHA (welche exakte Modellversion war im Einsatz?), Input-Hash (welche Daten kamen rein, ohne sie selbst zu loggen), Output, Timestamp, Reviewer-ID (welcher Arzt hat das Ergebnis freigegeben oder überprüft?). Dieser Log geht in einen Append-Only-Bucket mit Object Lock — kein Schreibrecht für Anwendungen, nur ein dedizierter Compliance-Account.

Lineage explizit dokumentiert. Jeder Datenfluss zwischen Services wird explizit modelliert. Tools wie OpenLineage oder DataHub helfen, sind aber kein Selbstzweck — das Ziel ist, beim Audit eine Frage wie "wo gehen Patient-IDs von System A nach System B?" in Minuten beantworten zu können.

Wer diese Patterns von Anfang an einsetzt, hat einen weiteren Vorteil: Die MLOps-Reife des Teams steigt nebenbei. Wir haben das im MLOps-Leitfaden für den Mittelstand genauer beschrieben — Compliance-Engineering und MLOps-Engineering sind weniger weit auseinander, als die meisten denken.

3. Architektur-Patterns, die im Audit durchfallen (Anti-Patterns)

Genauso wichtig wie die guten Patterns sind die typischen Fehler. Wir sehen sie in vier von fünf Audits — meist nicht aus Nachlässigkeit, sondern weil Cloud-Defaults so aussehen.

Cloud-Defaults ohne Region-Hardening. CloudWatch Logs landen ohne explizite Konfiguration in der Default-Region des Accounts. Wenn der Account ursprünglich in us-east-1 angelegt wurde, laufen Patientendaten-Logs in die USA. Cross-Region-Replikation von S3-Buckets ist in Backup-Konfigurationen oft aktiv, ohne dass das Engineering-Team davon weiß. Ergebnis: Personenbezogene Daten verlassen die EU, niemand hat es dokumentiert, niemand hat eine Rechtsgrundlage.

Lambda/Serverless für Inferenz ohne Version-Pinning. Wenn die Lambda-Function einen ML-Layer mit "latest"-Tag lädt, kann sich das Modell zwischen zwei Aufrufen ändern, ohne dass die Anwendung es bemerkt. Für die MDR-Dokumentation ein massives Problem: Welche Modellversion hat die diagnostische Aussage erzeugt?

SageMaker-Endpoints mit Auto-Scaling über mehrere Modellversionen. Wenn ein Deployment-Update läuft und parallel ein Auto-Scaling-Event passiert, können kurzzeitig zwei Modellversionen auf demselben Endpoint Traffic bekommen. Ohne explizites Version-Logging in der Response ist nicht rekonstruierbar, welche Version welchen Output produziert hat — ein klarer MDR-Annex-I-Verstoß.

Personenbezug in Application-Logs. Mit Abstand der häufigste Fund. ORMs wie SQLAlchemy, Hibernate oder Prisma loggen bei DEBUG-Level standardmäßig vollständige SQL-Statements inklusive Parameter — also inklusive Patient-IDs, Diagnosen, Geburtsdaten. Diese Logs landen in zentralen Logging-Systemen, oft mit Retention von 90+ Tagen, oft cross-region repliziert, oft mit Zugriff für das gesamte Engineering-Team.

DPA-Sub-Processor-Listen nicht durchgeprüft. Das DPA mit AWS, GCP oder Azure ist unterschrieben — aber die Sub-Processor-Liste enthält 60 bis 80 Drittunternehmen, die regelmäßig wechseln. Wer hat zuletzt geprüft, ob ein neuer Sub-Processor in einem Drittland sitzt? Bei den meisten Mandanten: niemand.

4. Pseudonymisierung in ML-Pipelines: was Art. 25 DSGVO wirklich verlangt

Art. 25 DSGVO ist einer der am häufigsten missverstandenen Artikel. Der Text spricht von "geeigneten technischen und organisatorischen Maßnahmen" — kein konkretes Schema, kein Algorithmus, keine Whitelist. Das macht ihn flexibel, aber auch interpretationsbedürftig.

Was sich in der Praxis durchgesetzt hat: Pseudonymisierung ist nicht Anonymisierung. Pseudonymisierte Daten bleiben personenbezogen im Sinne der DSGVO, weil mit dem Schlüssel die Re-Identifikation möglich ist. Das hat eine direkte architektonische Konsequenz: Auch pseudonymisierte Trainingsdaten unterliegen der vollen DSGVO. Wer glaubt, durch Pseudonymisierung aus der Regulierung herauszukommen, irrt.

Was Pseudonymisierung dagegen leistet: Sie reduziert das Risiko erheblich und ist eine konkrete Maßnahme nach Art. 25 und Art. 32. Praktisch heißt das:

• Trennung der Schlüssel. Das Mapping zwischen Pseudonym und realer Patient-ID liegt in einem System mit separater IAM-Berechtigung. ML-Trainingsumgebungen sehen nur Pseudonyme, niemals reale Identifikatoren.
• Strukturelle Re-Identifikationsschutz. k-Anonymität als Mindeststandard für Trainingsdatensätze: jeder Datenpunkt muss zu einer Gruppe von mindestens k Personen mit identischen Quasi-Identifikatoren (Alter, PLZ, Geschlecht) gehören. k=5 ist ein in der Praxis tragbarer Wert, k=10 ist konservativer.
• Differential Privacy kommt langsam aus der Forschung in die Produktion. Wir setzen es bei besonders sensitiven Feldern (genetische Daten, psychiatrische Diagnosen) ein, noch nicht flächendeckend.

Eine ehrliche Anmerkung: Vollständige Anonymisierung ist bei medizinischen Bilddaten praktisch unmöglich. Ein MRT-Scan ist biometrisch eindeutig. Wer behauptet, MRT-Trainingsdaten "anonymisiert" zu haben, verkennt die Re-Identifikationsforschung der letzten zehn Jahre. Die ehrliche Antwort ist: Pseudonymisierung mit klarer Rechtsgrundlage nach Art. 9 Abs. 2 DSGVO — typischerweise Einwilligung des Patienten oder Forschungsprivileg nach lit. j.

5. Audit-Trail-Anforderungen für Inferenz unter MDR

MDR Annex I (allgemeine Sicherheits- und Leistungsanforderungen) und Annex II (technische Dokumentation) sind die zentralen Referenzen für KI-basierte Medizinprodukte. Aus beiden ergeben sich konkrete Anforderungen an Audit-Trails, die jede medizinische KI MDR-konform erfüllen muss.

Vollständige Modellprovenienz. Für jede produktive Modellversion muss dokumentiert sein: Herkunft der Trainingsdaten (welche Quellen, welche Zeiträume, welche Rechtsgrundlage), Validierungsmethodik (Trainings-/Validierungs-/Test-Split, Cross-Validation-Strategie), Performance-Metriken auf einem unabhängigen Test-Set (Sensitivität, Spezifität, AUC, Calibration), Confounder-Analyse (welche Korrelationen wurden bewusst akzeptiert, welche ausgeschlossen). Diese Dokumentation ist kein einmaliges Artefakt — sie muss pro Modellversion erneuert werden.

Inferenz-Logging. Jede produktive Inferenz, die zu einer klinischen Entscheidung beiträgt, braucht einen Log-Eintrag mit folgenden Feldern: Modellversion als Git-SHA oder ähnliche kryptographische Referenz, Input-Hash (kein roher Input), strukturierter Output mit Confidence-Score, Timestamp in UTC, Identifikation des Reviewers, der den Output freigegeben hat. Pseudonyme Patient-ID — keine reale ID — als Foreign Key zum klinischen System.

Append-Only-Storage. Diese Logs gehören in einen Bucket mit Object Lock im Compliance-Modus. Append-only bedeutet: Schreiben ja, Löschen oder Überschreiben nein — selbst durch Root-Accounts nicht. Das ist eine harte Anforderung, weil die MDR Manipulationsschutz verlangt und im Streitfall (Vigilance-Fall, Schadenersatz) die Beweiskraft der Logs entscheidend ist.

Post-Market Surveillance. Annex III MDR verlangt ein PMS-System. Für KI heißt das: kontinuierliches Performance-Monitoring in Produktion, automatische Drift-Detection mit Alerts, jährlicher PMS-Report an die Benannte Stelle, sofortige Vigilance-Meldung an das BfArM bei schwerwiegenden Vorkommnissen. Architektonisch braucht das ein separates Monitoring-System, das die Inferenz-Logs in Echtzeit auswertet, ohne selbst Teil der Inferenz-Pipeline zu sein.

Aufbewahrungsfristen sind ein Punkt, bei dem oft unterschätzt wird. MDR Art. 10 Abs. 8 verlangt mindestens 10 Jahre Aufbewahrung der technischen Dokumentation nach dem letzten in Verkehr gebrachten Gerät, bei implantierbaren Produkten 15 Jahre. Für Audit-Logs eines diagnostischen KI-Systems heißt das praktisch: 10+ Jahre Storage einplanen, mit kalkulierbaren S3-Glacier- oder Azure-Archive-Kosten.

6. EU AI Act: was sich ab 2027 für Medical AI ändert

Der EU AI Act ist am 1. August 2024 in Kraft getreten, wird aber gestaffelt anwendbar. Für Medical-AI-Architekten sind drei Daten relevant.

2. Februar 2025: Verbotene Praktiken nach Art. 5 sind anwendbar. Für Medical AI selten direkt relevant, aber Social-Scoring-Use-Cases in Krankenversicherungen wären hier kritisch.

2. August 2025: Pflichten für General-Purpose-AI-Modelle (Art. 51 ff.) greifen. Wer eigene Foundation-Models trainiert oder GPT-4-, Claude- oder Llama-basierte Systeme einsetzt, muss prüfen, ob Provider- oder Deployer-Pflichten greifen.

2. August 2027: Hochrisiko-Systeme nach Anhang III und nach Art. 6 (Medizinprodukte) sind voll reguliert. Das ist das harte Datum für Medical AI.

Was ändert sich konkret? Erstens: Ein Risk Management System nach Art. 9 wird verpflichtend — strukturell ähnlich zum MDR-Risikomanagement nach ISO 14971, aber spezifisch für KI-Risiken (Bias, Robustness, Drift). Zweitens: Data Governance nach Art. 10 verlangt explizite Dokumentation der Trainingsdatenherkunft, Bias-Analyse, Repräsentativitätsprüfung. Drittens: Logging-Pflichten nach Art. 12 — automatisches Logging der Inferenz-Events über die gesamte Lebensdauer des Systems. Viertens: Human Oversight nach Art. 14 — strukturelle Möglichkeit für einen Menschen, die KI-Entscheidung zu überstimmen oder die KI abzuschalten. Fünftens: Conformity Assessment durch eine Benannte Stelle. Bei Medical AI läuft das praktisch zusammen mit dem MDR-Assessment.

Bußgelder sind beachtlich: bis zu 35 Mio. EUR oder 7% des weltweiten Jahresumsatzes bei Verstößen gegen die Verbote, bis zu 15 Mio. EUR oder 3% bei Verstößen gegen Hochrisiko-Pflichten. Das ist kein DSGVO-Niveau, sondern noch eine Schippe drauf.

Die gute Nachricht für Teams, die MDR und DSGVO bereits sauber umgesetzt haben: Der Sprung zum EU AI Act ist überschaubar. Die meisten strukturellen Anforderungen sind Erweiterungen dessen, was schon da ist — kein paralleles zweites System.

7. Die 6 häufigsten Compliance-Lücken in unseren Audits

Aus den letzten 18 Monaten Audit-Praxis bei NeuralMedic — diese sechs Befunde haben wir in der einen oder anderen Form fast überall gesehen.

1. Pseudonymisierungsschlüssel im selben IAM-Bereich wie die pseudonymisierten Daten. Das Mapping liegt im selben AWS-Account, derselben Subscription, demselben GCP-Project wie die ML-Pipeline. Damit ist die Pseudonymisierung formal vorhanden, materiell aber wirkungslos — jeder mit ausreichenden Rechten kann re-identifizieren. Fix: separater Account/Project mit eigenem KMS-Schlüssel und striktem Need-to-Know-Zugriff.

2. Modell-Inferenz ohne Version-Logging. Die Inferenz-Response enthält das Ergebnis, aber nicht die Modellversion, die es produziert hat. Bei einem Vigilance-Fall ist nicht rekonstruierbar, welches Modell verantwortlich war. Fix: Modell-SHA als Pflichtfeld in jeder Inferenz-Response und jedem Audit-Log.

3. Trainingsdaten ohne dokumentierte Rechtsgrundlage nach Art. 9 DSGVO. Patient-Daten wurden für Behandlungszwecke erhoben und werden für ML-Training verwendet — ohne dass die Zweckänderung sauber dokumentiert ist und ohne dass Art. 9 Abs. 2 lit. a (Einwilligung), lit. h (Versorgung) oder lit. j (Forschung) explizit referenziert ist. Fix: Rechtsgrundlagen-Register als Pflichtartefakt für jeden Trainingsdatensatz.

4. Cross-Region-Datenfluss in Backup-Pipelines. S3-Bucket in eu-central-1 hat Cross-Region-Replication nach us-east-1 aktiv. Niemand erinnert sich, warum. Die Replikation läuft seit Jahren, hat keine vertragliche Grundlage, keine Standardvertragsklauseln, keine Erwähnung im DPA. Fix: Audit aller Cross-Region-Konfigurationen, sofortiges Abschalten oder vertragliche Grundlage schaffen.

5. Personenbezug in Application-Logs. Häufigster Fund, in nahezu jedem Audit. Standard-ORM-Logs, Default-Trace-Konfigurationen, Crashreports mit Stack-Traces, die Request-Payloads enthalten — überall landen Patientendaten in Logging-Systemen, die nicht für sensitive Daten ausgelegt sind. Fix: Log-Sanitization als Pflicht im Application-Framework, statisches Code-Scanning auf sensitive Felder, Pre-Production-Audit der Log-Outputs.

6. DPA mit Cloud-Provider unvollständig. Das Hauptdokument ist unterschrieben, aber die referenzierte Sub-Processor-Liste wurde seit Vertragsabschluss nie wieder gelesen. Neue Sub-Processoren wurden über die übliche 30-Tage-Notification akzeptiert, ohne dass jemand sie geprüft hat. Fix: Quartalsweiser Sub-Processor-Review als Pflichttermin im Compliance-Kalender.

Die vollständige Checkliste: Wir gehen vor jedem Healthcare-Go-Live 47 Compliance-Kontrollpunkte durch. Die komplette Liste — DSGVO, MDR, ISO 27001, SOC 2 — gibt es als kostenlosen PDF-Download: → Medical AI Compliance Checkliste herunterladen

8. Was eine compliance-konforme Architektur kostet — ehrlich

Ehrliche Zahl aus der Praxis: Eine DSGVO- und MDR-konforme Architektur kostet im initialen Bau ungefähr 20-30% mehr als ein nicht-compliantes Setup. Das sind reale Personentage für Pseudonymisierungs-Service, separate IAM-Boundaries, Audit-Log-Infrastruktur, Lineage-Tooling und Dokumentationsartefakte.

Konkret bei einer typischen Medical-AI-Plattform: ca. 4 zusätzliche Architekt:innen-Wochen in der Design-Phase, ca. 6 zusätzliche Engineering-Wochen in der Implementierung, ca. 2 zusätzliche Wochen für Compliance-Dokumentation. Bei einem Projekt von 6 Monaten Engineering-Zeit sind das die genannten 20-30%.

Was diese 20-30% spart: Nahezu alle Folgekosten. Ein neuer Standort kostet praktisch nichts mehr. Ein neuer Kunde mit denselben Anforderungen ist in Wochen statt Monaten onboardable. Ein TÜV- oder Notified-Body-Assessment läuft glatt durch, weil die Dokumentation als Nebenprodukt der Architektur entsteht, nicht als Krampfaktion drei Wochen vor dem Termin.

Vergleichswert aus zwei realen Mandaten: Team A hat von Anfang an compliance-konform gebaut, 4 Wochen extra Architektur-Aufwand investiert und ist nach 6 Monaten live gegangen. Team B hat "schnell live gehen" priorisiert, ist nach 4 Monaten gestartet und musste 9 Monate später 6 Monate Rework machen, als der erste Großkunde einen Compliance-Audit verlangt hat. Die "schnelle" Variante hat netto deutlich länger gedauert.

Die Frage ist nicht, ob Compliance-Architektur teuer ist. Die Frage ist, ob ihr lieber 30% am Anfang oder 200% in der Mitte zahlt.

9. FAQ

Ist meine KI ein Medizinprodukt nach MDR? Wenn die Software einen medizinischen Zweck nach Art. 2 MDR verfolgt — Diagnose, Vorbeugung, Überwachung, Behandlung, Linderung — und dies durch einen Hersteller bestimmungsgemäß so deklariert ist, dann ja. Reine Workflow-Tools, Dokumentationssysteme oder Verwaltungssoftware sind in der Regel keine Medizinprodukte. Bei Grenzfällen hilft die MDCG 2019-11-Leitlinie. Klassifizierungs-Risiko: Wer "wir sind eigentlich kein Medizinprodukt" annimmt, ohne dies sauber zu dokumentieren, hat im Zweifelsfall ein nicht-konformes Medizinprodukt im Markt.

Was ist der Unterschied zwischen Pseudonymisierung und Anonymisierung? Pseudonymisierung ersetzt Identifikatoren durch Pseudonyme, wobei ein Mapping für die Re-Identifikation existiert. Pseudonymisierte Daten bleiben personenbezogen und unterliegen voll der DSGVO. Anonymisierung entfernt jede Re-Identifikationsmöglichkeit — auch mit Zusatzwissen. Echte Anonymisierung ist bei medizinischen Daten mit biometrischen Anteilen (Bildgebung, Genetik) praktisch nicht erreichbar. Für ML-Trainingsdaten ist Pseudonymisierung mit k-Anonymität die realistische Praxis.

Brauche ich eine DSFA für Medical AI? In nahezu allen Fällen ja. Art. 35 Abs. 3 DSGVO listet DSFA-Pflicht unter anderem bei umfangreicher Verarbeitung besonderer Kategorien personenbezogener Daten (Art. 9) — Gesundheitsdaten fallen darunter. Ergänzend hat die DSK eine sogenannte Muss-Liste veröffentlicht; KI-basierte Verarbeitung von Patientendaten steht praktisch immer drauf. Die DSFA ist kein einmaliges Dokument, sondern muss bei wesentlichen Architektur-Änderungen aktualisiert werden.

Wo sollte meine ML-Trainings-Umgebung gehostet sein? EU-Region, immer. Frankfurt (eu-central-1, europe-west3) oder Dublin (eu-west-1) sind die etablierten Standorte. Für besonders sensitive Setups gibt es zusätzlich souveräne Clouds (z.B. Open Telekom Cloud, Stackit, Ionos). Entscheidend ist nicht nur die Region der Trainings-Compute, sondern auch der Logs, Backups, Telemetrie und aller Sub-Processoren. Cross-Region-Replikation ist ein häufiger blinder Fleck.

Was passiert, wenn ich gegen den EU AI Act verstoße? Bußgelder bis zu 35 Mio. EUR oder 7% des weltweiten Jahresumsatzes bei Verstößen gegen Verbote (Art. 5), bis zu 15 Mio. EUR oder 3% bei Verstößen gegen Hochrisiko-Pflichten (Art. 6 ff.). Praktisch wichtiger: Eine Benannte Stelle, die ein nicht-konformes System bewertet, wird kein Zertifikat ausstellen — das System ist dann nicht marktfähig.

Wie lange muss ich Inferenz-Audit-Logs aufbewahren? Mindestens so lange wie die zugehörige technische Dokumentation des Medizinprodukts. MDR Art. 10 Abs. 8: 10 Jahre nach dem letzten in Verkehr gebrachten Gerät, bei implantierbaren Produkten 15 Jahre. Praktisch heißt das: Plant Storage auf einer Zeitskala von 10+ Jahren ein — mit Konsequenzen für Key-Rotation, Format-Stabilität und Backup-Strategie.

---

Nächster Schritt: Wenn ihr in der Compliance-Architektur Klarheit braucht, machen wir kostenlose 30-Min Architektur-Reviews. Kein Sales-Deck, kein Vertragsdruck. → Termin buchen

---

Jonas Heinzmann ist Gründer und Geschäftsführer der NeuralMedic GmbH in Ingolstadt. Das Unternehmen entwickelt produktionsreife Daten- und KI-Plattformen für den deutschen Mittelstand — mit besonderer Erfahrung in regulierten Industrien wie Healthcare. → Profil ansehen