The European AI Act and medical devices: what US founders need to know

Why US founders should care

Even companies with no near-term European commercialization plans are finding themselves affected. Global partners, multinational health systems, and international clinical trials all pull EU requirements into the picture.

The intersection with MDR

The AI Act does not replace the Medical Device Regulation — it layers on top of it. Founders need a quality system that satisfies both. Retrofitting later is expensive.

Data governance requirements

The AI Act's data governance provisions are among the strictest globally. Training data lineage, bias assessment, and documentation of representativeness are all explicit obligations.

Practical steps

Assign one person to own AI Act readiness. Map every training dataset against the required documentation. Do this while the datasets are small — it becomes impossible at scale.

The default global standard problem

Global device companies have long dealt with the reality that the strictest major regulatory regime tends to become the de facto design standard, because building two separate versions of a product is rarely worth the engineering cost. The EU AI Act is positioned to play that role for AI-enabled medical devices, meaning that a company designed only for the US market from the start is more likely to need a costly redesign later if it ever wants to sell in Europe, or even if US regulators later adopt similar expectations.

Founders sometimes assume they can defer EU compliance entirely until they have US commercial traction, but the AI Act's documentation and risk-management requirements touch decisions made early in product design — how training data is sourced and documented, how the system's limitations are disclosed — that are far cheaper to build in from the start than to retrofit.

How the Act interacts with existing MDR requirements

Medical devices sold in the EU already have to satisfy the Medical Device Regulation, and the AI Act does not replace that framework so much as layer additional requirements on top of it for devices that qualify as high-risk AI systems. In practice this means a device manufacturer may need to satisfy two overlapping but not identical sets of documentation, conformity assessment, and post-market surveillance obligations.

The practical challenge for a lean team is sequencing: building a quality system that satisfies MDR's device-specific requirements while also building the AI-specific risk management file the Act expects, without duplicating effort across two separate documentation tracks. The companies handling this well are designing a single integrated technical file from the outset rather than maintaining parallel compliance efforts.

What the Act expects of your training data

The Act places real weight on being able to describe the provenance, representativeness, and known limitations of the data used to train a clinical AI system, including whether the population represented in that data resembles the population the device will actually be used on. This is a substantively different bar than simply demonstrating that a model performs well on a held-out test set.

Founders building models now should keep detailed records of dataset composition — sourcing, demographic representation, exclusion criteria — even before they have a specific EU launch planned, because reconstructing that provenance history after the fact, once data has been merged from multiple sources over time, is often impossible to do credibly.

A realistic first-year plan

Founders do not need to build full EU compliance before their first US customer, but they should assign a single owner, even part-time, to track the Act's implementing guidance and map it against their existing MDR-oriented quality processes, so that gaps are visible well before an actual EU launch is imminent.

The single highest-leverage early step is usually establishing rigorous, well-documented data governance practices — for provenance, consent, and representativeness — because those practices are useful and often required regardless of jurisdiction, and they are the piece of the compliance puzzle that is most expensive to reconstruct retroactively once a product has scaled.