It usually starts with one product, one deadline, and six documents open at once: the AI Act’s Article 6(1) criteria, the MDR or IVDR technical documentation, the harmonized standards, the risk file, last year’s classification memo, and a message from Engineering asking whether any of this changes the sprint. 

That is the moment behind the question every regulatory professional is now being asked to answer with confidence: is our software a high-risk AI system under the EU AI Act? And when? 

The instinct is to treat this as a question about how advanced the AI is. It rarely is. In practice, the answer usually turns on a small, answerable set of questions about intended purpose, safety role, and whether a Notified Body is already involved. Many regulatory teams are closer to a defensible answer than they realize. The uncertainty comes less from the legislation itself than from holding several sources of truth in your head at once, with Clinical Affairs, Quality, Engineering, and leadership all waiting on the answer before a submission ever reaches a Notified Body. 

For lean teams, an incorrect assumption can consume months of limited capacity through avoidable rework. For larger manufacturers, inconsistent decisions across products or business units can result in a fragmented regulatory approach across the portfolio. And the clock is real: AI literacy obligations under Article 4, while recently weakened, already apply to providers and deployers, and the AI Act’s Chapter III, Sections 1-3 high-risk requirements for qualifying Article 6(1) systems apply from 2 August 2028.  

The four-question screening test 

Most classification exercises get complicated because they start in the wrong place, with the AI itself, rather than with the product’s existing regulatory status. A more reliable route runs through four questions, each one narrowing the answer before the next is asked: 

1. Is it an AI system at all? The starting point is the AI Act’s own definition in Article 3(1). Not every algorithm, rule engine, or statistical model qualifies. But on the other hand, it does not always have to be a system we tend to call AI, like a large language model. Getting this wrong in either direction wastes effort: assuming coverage where none exists builds unnecessary process, while missing genuine coverage creates exposure that surfaces later, at a worse time. 

2. Is it software for medical purposes? If the software qualifies as medical device software under the MDR or IVDR, that classification becomes the foundation for everything that follows. This is where AI Act analysis and MDR/IVDR analysis stop being separate exercises. 

3. Is the AI itself the medical device, or a safety component of one? This is the core trigger under Article 6(1), read together with the safety-component definition in Article 3(14). It is a narrower question than “does this product use AI?” 

New this year is that AI used solely for non-safety user assistance, performance optimisation, service efficiency, automation, convenience, or quality control is not a safety component. Conversely, an AI system whose failure or malfunction would endanger health and safety may qualify as one. Answering this question precisely is what prevents both over- and under-classification. 

4. Does it require third-party conformity assessment under the MDR or IVDR? This is the second part of the Article 6(1) test. An AI system is high-risk under Article 6(1) only when both relevant conditions are met: the AI system is itself an Annex I product or is intended as its safety component, and that product requires third-party conformity assessment. If both conditions are met, the AI system is high risk. 
 

A qualifying Article 5(5) in-house device normally does not meet the Article 6(1)(b) criterion, because it is not subject to the MDR/IVDR third-party conformity-assessment route. This does not remove other applicable AI Act duties, and the in-house-device exemption itself is subject to specific conditions. As a rough conformity-assessment map: MDR Class I without Notified Body involvement, and IVDR non-sterile Class A, are generally outside the third-party conformity assessment limb. MDR Class Is, Im, Ir, IIa, IIb, and III, along with IVDR sterile Class A and Classes B through D, may meet that limb. The Article 6(1) product/safety-component condition still needs to be assessed separately. 

Four questions rarely feel like enough for a decision this consequential. That instinct is usually right, but the missing piece is rarely a fifth question. It is confirming the answer to each of these four against the product’s actual technical file, rather than against a general impression of how the product works. 

The most common false assumptions 

Two assumptions account for most of the rework we see. The first is assuming that any product with a machine learning component is automatically high-risk, when the real trigger is the safety role that component plays, together with the other Article 6(1) conditions. 

 The second runs the other way: assuming that because a product isn’t “AI” in the popular sense, the classification question doesn’t apply, when the Article 3(1) definition is broader than most engineering teams expect. 

A third, quieter assumption causes the most expensive rework: treating classification as a one-time answer rather than something that has to be re-confirmed when the software changes. A model retrain, a new intended purpose, or an added feature does not automatically constitute a substantial modification. Article 3(23) defines what counts as a substantial modification, while Article 43(4) addresses the need for a new conformity assessment where an already-assessed high-risk system undergoes such a modification. Teams that treat classification as a static memo, rather than a living decision tied to change control, are the ones who discover the problem during an audit instead of during development. 

What changes if the answer is yes? 

A high-risk classification is not, by itself, a reason to build new infrastructure. It is a reason to look closely at what the organization already has. 

Risk management, data governance, logging, human oversight, quality management, technical documentation, and post-market monitoring all need to be considered under the AI Act. Articles 9, 10, 12, 14 and 17 address risk management, data governance, logging, human oversight and quality-management system respectively, while Article 72 addresses post-market monitoring. For many manufacturers, these requirements can be integrated into processes they already run under the MDR or IVDR. The risk file already exists. The technical documentation already exists; the post-market surveillance plan already exists. The question is not whether to build parallel systems. It’s what has to be added to the ones already in place, and who owns adding it. 

Engineering typically owns the logging and human-oversight design that Articles 12 and 14 expect to see reflected in the technical file. Quality owns whether QMS procedures already cover AI-specific lifecycle activities. Clinical owns whether the evidence plan accounts for data governance and representativeness. When these functions decide independently, Regulatory Affairs ends up reconciling mismatched documents later, typically during submission preparation, when it is far more expensive to fix. 

Reusing what you already have 

This is the part of the AI Act that most teams miss, and it is genuinely good news.  For Article 6(1) high-risk systems, AI Act requirements form part of the applicable MDR or IVDR conformity assessment under Article 43(3). Article 8(2) separately permits integration of the necessary testing, reporting, information and documentation into existing MDR/IVDR processes and documentation. 

 
A single technical-documentation set is required, although the use of the same Notified Body depends on the applicable conditions and designation arrangements. The AI Act does notnecessarily require manufacturers to build an entirely parallel regulatory system alongside the one they already operate. That relief depends entirely on recognizing early which existing artifacts – the risk file, the technical documentation, the PMS plan – can absorb the new requirements, and which genuinely need to be built. Getting that mapping right the first time is the difference between an AI Act response that feels like an integration and one that feels like a second compliance program bolted onto the first. 

Will it all go away? 

When the AI Act was updated this summer, the deadline when Article 6(1) would apply to AI devices mentioned in Annex I was moved from 2027 to 2028. In the December 2025 omnibus proposal, MDR and IVDR were proposed to be moved out of Annex I section A, meaning the automatic link between conformity assessment of the device and high-risk classification under the AI Act could be broken. 

 
However, smart regulatory professionals act now anyway. Yes, 2028 is two years away and it could turn into ‘never’ as far as the Article 6(1) connection goes. MDR and IVDR already requirestate-of-the-art software lifecycle controls, risk management, information security, verification and validation. For an AI-enabled device, related controls may be relevant where needed to demonstrate safety and performance. In other words, the same work will come into your compliance process via an alternate route. Unless you want to hedge your bets and see what happens between now and 2028, it’s better to prepare for it based on the current, stable regulatory basis. 

Conclusion 

The question “Is our software a high-risk AI system?” looks like it needs a legal opinion. Often, it needs four honest answers about whether the system falls within the AI Act, its intended purpose, its safety role, and its conformity-assessment route, checked against a technical file the organization already has, and refreshed each time the product changes. 

That is a more tractable problem than it first appears, and for qualifying Article 6(1) high-risk AI systems, there is a real milestone ahead: 2 August 2028. 

The competitive advantage in Regulatory Affairs will not come from understanding the AI Act or the MDR and IVDR in isolation. It will come from connecting them, quickly and defensibly, so classification stops being a bottleneck and becomes what it should be: an early, confident decision that everyone downstream can build on. That is what Regulatory Intelligence is for, not replacing the judgment behind the answer, but making it faster to reach and easier to defend. 

P.S. This article was written by humans and reviewed by Raiana Strati.