The Digital Omnibus gave healthtech teams more time on paper. In practice, if you’re building AI into a medical device, the work was already overdue.

On June 29, 2026, the Council of the EU formally approved the Digital Omnibus package, pushing the compliance deadline for high-risk AI systems from August 2, 2026 to December 2027, or August 2028 for AI embedded in products regulated under MDR or IVDR. Within hours, Slack channels filled with product teams forwarding the news.

The reaction was relief. It probably should have been concern.

The extension doesn’t move the underlying problem. If you’re building software that qualifies as a medical device, or embedding AI into one, you’ve been operating under intersecting compliance obligations for years. The delay gives you more time before regulators check your documentation. It doesn’t give you more time to get the architecture right, because that ship already needed to sail.

What the Omnibus actually changed

The Digital Omnibus introduced a two-tier timeline. Standalone high-risk AI systems under Annex III of the AI Act must comply by December 2, 2027. AI systems embedded in regulated products, including SaMD under MDR and IVDR, get until August 2, 2028.

One part that didn’t move: Article 50 transparency obligations. Those apply from August 2, 2026, which at the time of writing is days away. If your product uses AI to interact with users, or generates content users might mistake for human-produced, transparency requirements are already active.

There’s also a grandfathering rule worth noting. AI systems already on the market before August 2, 2026 only need to meet the new obligations if they undergo significant design changes afterward. What counts as „significant” is still being interpreted by notified bodies, and if you’re planning substantial feature updates, you’d be unwise to count on grandfathering to protect you.

The real problem: you’re already under two frameworks

The European AI Act and MDR don’t replace each other. They stack.

Any AI-powered feature in a CE-marked medical device is subject to both regulatory frameworks simultaneously. MDR has been in effect since May 2021. It already requires clinical evaluation, post-market surveillance, software lifecycle documentation per IEC 62304, and risk management per ISO 14971. None of that goes away. The AI Act then adds its own layer: conformity assessments, data governance requirements, human oversight mechanisms, incident reporting to regulators, and registration in the EU database for high-risk AI systems.

Your technical documentation needs to satisfy both frameworks at once. MDR wants to know your software performs its intended clinical function safely. The AI Act wants to know your model’s training data was appropriate, your outputs are explainable to the degree possible, and a qualified human can override or shut down the system. These aren’t contradictory requirements, but they weren’t designed together, and reconciling them in a single documentation package takes real work.

We’ve seen teams discover this intersection late, typically when a notified body flags an issue during MDR conformity assessment and the team realizes they’ve built an AI feature that would also require AI Act compliance steps they haven’t started. At that point you’re looking at architectural changes under time pressure, which is the worst possible situation in healthcare software development.

What your development team needs to have in place

There’s no single checklist that covers every product, but after working on SaMD for clients across the DACH region, a few requirements come up consistently.

Data lineage comes first, and it’s deceptively easy to get wrong. The AI Act requires documentation of the datasets used to develop, train, and validate the AI system: sources, collection methodology, known biases and gaps. If your team built the model iteratively without documenting those decisions along the way, reconstructing that history is painful. Starting this documentation at the beginning of model development is orders of magnitude easier than doing it retroactively.

Closely tied to that is human oversight, and this is where most teams run into architectural problems. The AI Act requires that human oversight is possible throughout the system’s operation. For high-risk AI, this is not a UI checkbox at the end of development. If your system makes recommendations or decisions that affect patient care, the oversight mechanism needs to be embedded in the product logic, tested like any other feature, and included in the clinical evaluation.

Risk management is where the two frameworks need the most deliberate reconciliation. Your ISO 14971 risk file already covers software-related risks under MDR. You’ll need to extend it to cover AI-specific failure modes: model degradation over time, distribution shift when the patient population changes, edge cases the model hasn’t encountered. The frameworks map onto each other reasonably well once someone has done the alignment work, but that alignment doesn’t happen automatically.

Post-market surveillance now needs an AI monitoring component too. MDR’s PMS requirements need to account for performance drift. If your model was validated on a German patient population and your product expands to Austria, that’s a population shift worth tracking. This has real implications for how you instrument your product from day one, not something you can bolt on after launch.

Finally, when you update the AI component of your product, you need a defined process for determining whether that update constitutes a significant change under the Omnibus grandfathering rules. Building that into your change management process now is far easier than arguing about it with a notified body under pressure.

Where teams actually get into trouble

The compliance failures we see most often aren’t legal misunderstandings. They’re engineering decisions made before anyone thought hard about regulatory implications.

Model selection is one of the more common ones. Teams choose foundation models or third-party AI components for capability reasons without asking whether the provenance of those models satisfies the AI Act’s data governance requirements. If you’re using a model from a provider who can’t or won’t supply documentation of training data, that becomes your documentation gap, not theirs.

Logging is another. The AI Act requires records sufficient to support post-market monitoring and incident investigation. Teams that built AI features without structured logging of inputs, outputs, and confidence scores discover too late that they can’t reconstruct what the model did in a specific clinical case. By then, the fix is expensive.

The third problem is timeline miscalibration on clinical evaluation. MDR clinical evaluation for AI features takes longer than most teams expect, partly because evaluators need to understand what the model does and how it fails, and partly because post-market clinical follow-up needs a defined plan from day one. Starting the clinical evaluation after the product is built creates delays and, sometimes, requires design changes that nobody budgeted for.

We wrote more about how AI testing in healthcare applications intersects with compliance requirements if you want to go deeper on the testing side specifically.

The cost of delay

Germany’s healthcare AI market was valued at USD 3.34 billion in 2026 and is projected to reach USD 52.47 billion by 2035, growing at 35.8% annually, according to IMARC Group. That trajectory reflects real demand from healthcare providers and payers across the DACH region for AI-assisted diagnostics, documentation, and care coordination.

The companies that will capture that market are the ones whose products are compliant, trusted by clinicians, and approved by notified bodies while competitors are still arguing about documentation. The deadline extension doesn’t change that calculus. If anything, it gives compliant products a longer window to establish market position before the laggards catch up.

What to do before the end of 2026

The extension gives you breathing room, but only if you use it. The practical priority right now is a gap assessment: compare your current technical documentation against both MDR Annex II and the AI Act’s requirements for high-risk systems. Don’t start from scratch; start by understanding what you have and what’s missing.

If you’re planning significant feature updates for 2027, make sure the change management process includes a determination of whether those updates trigger new compliance obligations under the Omnibus grandfathering rules. And if you haven’t briefed your development team on the AI Act’s specific requirements for logging, human oversight, and data governance, that conversation is overdue.

For broader context on how the DACH regulatory stack fits together, including MDR, DiGA, IEC 62304, and the ePA, our article on healthcare software development in Germany and Austria covers the full picture.

We’ve been working through the MDR and AI Act intersection with healthtech clients for several years. If you’re trying to understand what it means for your specific product, we’re happy to think it through. Let’s talk.