The EU’s Digital Omnibus agreement pushes high-risk AI obligations for medical devices from August 2027 to August 2028, and standalone Annex III systems from August 2026 to December 2027. For healthtech teams in Germany, Austria and Switzerland, that extra year is a planning gift, not an architectural reprieve.
Table of Contents
TL;DR – what changed and what didn’t
The provisional Digital Omnibus deal (May 2026) delays high-risk AI obligations under Article 6(1) for AI inside medical devices to 2 August 2028, and Annex III systems to 2 December 2027. The eight technical obligations from Articles 9 to 17 (risk management, data governance, technical documentation, automatic logging, transparency, human oversight, accuracy, QMS) are unchanged. Three of them — logging, human oversight, data governance — are architectural decisions that take 6 to 18 months to retrofit. Notified body queues in Germany are at 24 months end-to-end. Starting now is the conservative path, not the early one.
Most CTOs in DACH read the Omnibus headlines as „we have more time” and de-prioritised the AI Act. Many of them already shipped clinical AI in 2023 and 2024 on architectures designed for a regulatory landscape that no longer exists. The delay does not unship those products. It just lets the rebuild happen with one more quarter of buffer.
We have been navigating this stack with healthtech teams since before the AI Act was published in the Official Journal. The shape of the rebuild is the same in every project. The 2028 horizon does not change it.
What does „high-risk medical AI” mean under the EU AI Act?
Medical AI is classified as high-risk under the AI Act when it is software qualifying as a medical device under MDR and that device requires notified body conformity assessment – meaning Class IIa, IIb or III. This is the Article 6(1) pathway and it covers the majority of clinical AI applications. A separate pathway under Annex III point 5 catches AI used by public authorities to evaluate eligibility for healthcare benefits, as well as health and life insurance pricing AI and emergency triage systems.
Class I medical devices that do not require notified body involvement sit outside Article 6(1). The MDCG clarified in Guidance MDCG 2025-6 (June 2025) that AI Act high-risk classification does not change MDR risk class — they are independent regimes, evaluated in parallel by the same notified body for Class IIa+.
In practice, this means three things for a product team. Your AI feature inside a Class I app may sit outside Article 6(1), but still falls under Article 50 transparency obligations. Your AI feature inside a Class IIa+ SaMD is unambiguously high-risk. And your borderline-classification AI is the highest-risk product strategy, because regulators look first at exactly that line.
When does the EU AI Act actually apply to medical AI in 2026?
The original 2 August 2026 and 2 August 2027 deadlines are being moved by the Digital Omnibus agreement reached in May 2026. Formal adoption is expected before 2 August 2026. Three dates matter for healthtech roadmaps:
| Date | What goes live | Who is affected |
|---|---|---|
| 2 February 2025 | Prohibited AI practices, AI literacy obligations | All AI providers and deployers |
| 2 August 2025 | GPAI model obligations, governance, penalties | Foundation model providers, downstream operators |
| 2 December 2027 (delayed) | Annex III high-risk obligations (incl. healthcare eligibility, insurance pricing, emergency triage) | Public-sector health AI, health insurers, dispatch systems |
| 2 August 2028 (delayed) | Article 6(1) high-risk for AI in MDR/IVDR-regulated devices | SaMD AI vendors, Class IIa+ device manufacturers |
The European Parliament’s rationale for the delay is straightforward: the harmonised standards underpinning the technical requirements are not ready. CEN-CENELEC’s JTC 21 is still drafting them. Without those standards, conformity assessment becomes interpretation rather than measurement.
But the delay does not change the underlying obligations. Articles 9 to 17 remain the technical bar. Once the standards land in 2027, notified bodies will assess against them with the same rigour they apply to MDR.
How do the EU AI Act, MDR and EHDS reinforce each other and where do they collide?
A medical AI product in DACH operates under three regulations at once. They were written by separate teams with separate mental models, and the seams matter at the architecture level.
| Dimension | EU AI Act | MDR 2017/745 | EHDS (Reg. 2025/327) |
|---|---|---|---|
| Trigger | High-risk classification via Article 6 or Annex III | Software with medical purpose | Electronic health data, EHR systems, certain wellness apps |
| Conformity | Internal control or notified body — same body as MDR for Class IIa+ | Notified body for Class IIa, IIb, III | Conformity assessment for EHR systems from 2029 |
| Documentation | Article 11 + Annex IV technical file | MDR Annex II technical documentation | EEHRxF conformance evidence |
| Logging | Article 12 — automatic, lifecycle | Audit log per IEC 62304 | Interoperable export for secondary use |
| Human oversight | Article 14 — operationally enforceable | Required for clinical decision support | Patient access and override rights |
| Post-market | Article 72 monitoring + incident reporting | Articles 83-86 surveillance | Reporting to Health Data Access Body |
The friction we see most often: MDR’s clinical evaluation evidences clinical performance against intended use. The AI Act expects evidence of model accuracy, robustness and absence of discriminatory outcomes across protected groups. The same model, two evaluation frames. Teams that designed the evaluation framework to capture both ship one document. Teams that did not run the evaluation twice.
What does the 2028 deadline actually demand from a healthtech product team?
Eight technical obligations under Articles 9 to 17, three of which are architectural decisions that cannot be added later: automatic logging, human oversight, and data governance. The other five — risk management, technical documentation, transparency, accuracy/robustness, QMS — are operational layers built on top.
The numbers from recent industry surveys put scale on the work. Healthcare AI validation increases compliance cost by 20 to 40%. Documentation requirements extend development time by 15 to 25%. Per-model annual compliance cost lands around €29,277. Third-party conformity assessment runs €10,000 to €40,000 per system. A 2025 Pharmaceutical Technology survey found that only 60% of EU-based pharma companies plan to implement AI risk management by 2027, and 45% expected to overhaul QMS for AI. The other 40% and 55% are starting late.
The notified body bottleneck compounds this. Germany’s most in-demand notified bodies — BSI, TÜV SÜD, DEKRA — are running 6 to 12 month intake queues and 13 to 18 month review cycles. From first contact to certificate, budget 24 months. The pool of notified bodies under MDR is roughly 45, down from approximately 80 under MDD, absorbing significantly more work per assessment.
The math: if your Class IIa SaMD with AI needs to be certified before 2 August 2028, the realistic latest entry point to the notified body queue is Q3 2026. That is now.
Three product scenarios from our DACH work
The architectural decisions surface across very different product categories. Three scenarios from our healthcare practice illustrate what AI Act readiness looks like in code.
An AI-powered therapy documentation tool in the Mentalyc category is the textbook Article 14 case. Every session recording is sensitive data under GDPR Article 9. Every model output is a clinical artefact. The therapist’s decision to accept, edit or reject the AI-generated note is precisely the human oversight Article 14 requires. The architectural question is whether your database can reconstruct, for any given note, what the model proposed, what the therapist changed, and at what timestamp. We built that audit chain into Mentalyc’s data model from the first sprint. Retrofitting it would have meant migrating every historical note.
A clinical decision support system for hospitals, classified as MDR Class IIa, is high-risk under Article 6(1) from August 2028. The architectural challenge is uncertainty representation. Article 15 demands accuracy; Article 13 demands deployers understand the system’s limits. The API response cannot just return a recommendation. It has to return a calibrated confidence value, the features that drove it, and a flag for inputs outside the training distribution. Most CDSS systems built before 2024 return only the recommendation. The retrofit is significant.
A diabetes management mHealth app in the spirit of mySugr, with AI suggesting insulin dose adjustments, sits at the classification boundary. If the AI constitutes a medical device under MDR, and most dosing recommendations do, it is high-risk via Article 6(1). If classified as a wellness suggestion below the MDR threshold, it may sit outside high-risk. That line is exactly where regulator attention concentrates. We advise teams to design for high-risk compliance and make the classification argument from architectural strength, not the reverse.
Where most teams will get stuck
Three architectural decisions determine whether AI Act readiness is a manageable engineering programme or a multi-quarter rebuild.
Separating model output from human override in the data layer. Article 14 requires that humans intervene before AI outputs affect the user. In code, this means every AI-generated artefact needs three first-class states: original model output, human-modified version, final version of record. Most schemas store the final version and overwrite the rest. That works for product UX. It does not survive an Article 14 audit.
Immutable, query-able audit trail. Article 12 requires automatic logging throughout the AI system lifecycle. The audit threshold is not „do we log” but „can we answer a notified body question from the log”. If a regulator asks how the model behaved on a specific Tuesday last March, your log needs to answer in minutes, not weeks. Append-only object storage indexed by model version and inference timestamp works. Application logs in a SIEM optimised for security events do not.
Model card to technical documentation pipeline. Article 11 plus Annex IV specify the technical file: intended purpose, training data characteristics, performance metrics across representative populations, known limitations, human oversight provisions. Teams that maintain a model card per version, updated alongside every retraining, can generate the Annex IV file as an export. Teams that produce the technical file manually discover their next model retrain invalidates it.
What we would do if we were starting today
If we were building a new medical AI product for DACH in May 2026, we would treat the eight Articles 9 to 17 obligations as eight architectural choices made in sprint one, not as a compliance workstream parallel to development. We would model AI output, human modification and record of care as distinct data classes. We would log every inference into an immutable store keyed by model version. And we would write the model card in the same pull request as the model code.
The teams that will struggle in 2027 and 2028 are not the ones starting today. They are the ones reading the Omnibus headlines as permission to wait. Germany’s digital health market is projected at USD 38.33 billion in 2026, with SaMD growing at 20.9% CAGR through 2032. The competitive risk of delay is larger than the cost of building right.
Pressure-testing your medical AI architecture against the AI Act
If you are building clinical or wellness AI for the DACH market and want a second opinion on what the August 2028 deadline means for your specific architecture, we would be glad to compare notes. We have been working through these decisions with healthtech teams in Germany, Austria and Switzerland since before the AI Act was finalised, including with clients like Mentalyc, Selfapy and mySugr/Roche.
Book a 30-minute consultation → · See our healthcare and medtech practice → · Read our EHDS deep-dive →
