Is Your AI-Enabled Medical Device Creating Regulatory Debt?
How to determine whether your product may be classified as high-risk under the EU AI Act, and why classification is only the beginning.
“Many AI-enabled medical devices will be affected by the EU AI Act. Far fewer manufacturers are asking whether they're prepared for the additional regulatory scrutiny it may bring.”
Alastair Selby
Managing Director, SciMed Consultancy Ltd
Executive Summary
Manufacturers of AI-enabled medical devices and IVDs are increasingly asking whether their products may be classified as high-risk under the EU AI Act.
It is the right question to ask, but it is not the only one.
For many manufacturers, the bigger issue is not simply whether the AI Act applies. It is whether the product has been developed with enough governance, evidence, documentation, and lifecycle control to support future regulatory scrutiny.
This article explains:
Why high-risk classification matters for AI-enabled medical devices and IVDs.
How the EU AI Act interacts with MDR and IVDR requirements.
Why classification should be treated as the start of the compliance conversation, not the end.
How manufacturers can avoid creating regulatory debt during AI product development.
What practical questions should be asked before technical documentation and regulatory strategy become difficult to remediate.
Introduction
One of the questions we expect MedTech manufacturers to ask more often over the next couple of years is:
Will our AI-enabled medical device be classified as high-risk under the EU AI Act?
It is a reasonable question.
For manufacturers developing AI-enabled Software as a Medical Device, diagnostic algorithms, clinical decision support tools, imaging software, or AI-supported IVDs, high-risk classification can have significant implications for regulatory strategy, technical documentation, lifecycle governance, and post-market monitoring.
But I think there is a danger in treating classification as the whole problem.
Classification matters. However, by the time a manufacturer is asking whether its device is high-risk, many of the decisions that shape future compliance burden may already have been made.
The intended use may already be fixed. The data strategy may already be embedded. The validation plan may already be underway. The technical documentation may already be structured around traditional software assumptions. The post-market monitoring plan may not yet account for model drift, retraining, or AI-specific performance changes.
That is where regulatory debt starts to build.
Regulatory Debt
At SciMed, we use the term “regulatory debt” to describe the future compliance burden created when governance, evidence generation, documentation, and oversight considerations are deferred during product development.
It rarely looks like a problem at first; the product is moving. The software works. The development team has momentum. Regulatory questions can appear manageable.
Then the manufacturer reaches a Notified Body discussion, technical documentation review, regulatory submission, acquisition diligence process, or post-market planning stage, and discovers that the evidence needed to defend the AI system was not designed into the product lifecycle early enough.
That is the real risk.
Not simply being classified as high-risk, but being unprepared for what that classification means.
Quick Answer
Will My Medical Device Be Considered High-Risk Under the EU AI Act?
Many AI-enabled medical devices and IVDs may be classified as high-risk under the EU AI Act where they are themselves products covered by MDR or IVDR, or are safety components of those products, and the product is subject to third-party conformity assessment.
However, classification depends on the product’s intended use, regulatory status, conformity assessment route, and the role AI plays within the device or IVD.
Manufacturers should not assess AI Act applicability in isolation. The more useful question is how AI-specific obligations interact with existing MDR or IVDR requirements for risk management, clinical or performance evidence, technical documentation, quality management, lifecycle controls, and post-market monitoring.
Why High-Risk Classification Matters
High-risk classification matters because it changes the level of governance expected around the AI system.
For MedTech manufacturers, this is unlikely to be a completely separate compliance universe. Manufacturers already operate within structured regulatory systems. They already manage risk. They already generate clinical or performance evidence. They already maintain technical documentation. They already operate quality management systems. They already conduct post-market surveillance.
The issue is that AI introduces additional expectations into those systems.
A manufacturer may need to show not only that the device is safe and performs as intended, but that the AI system has been developed, validated, monitored, and controlled appropriately across its lifecycle.
That can affect areas such as:
data governance
dataset representativeness
validation strategy
human oversight
transparency
model updates
retraining
performance monitoring
post-market learning
technical documentation structure
For some manufacturers, the difficulty will not be that these areas are entirely new, but rather showing that existing MDR or IVDR processes properly account for AI-specific risks, and that distinction matters.
If the work is approached early, AI governance can often be integrated into existing regulatory, quality, risk management, and post-market systems, but if it’s left late, the same work can become a remediation exercise.
Understanding the Relationship Between MDR, IVDR and the EU AI Act
For AI-enabled medical devices and IVDs, one of the most practical mistakes is to treat the EU AI Act and MDR or IVDR as entirely separate compliance programmes; that creates unnecessary duplication. It does, however, also make ownership harder. Regulatory, quality, clinical, software, data science, and product teams may all assume that someone else is handling part of the obligation.
Because of this, the better starting point is to ask:
Which AI-related requirements can be addressed through systems we already have, and where do we need additional controls?
MDR and IVDR already require manufacturers to establish evidence, risk management, technical documentation, quality management, and post-market systems. These remain central. The EU AI Act adds a further layer of expectation around the AI system itself, particularly in areas such as data governance, transparency, human oversight, technical documentation, performance, monitoring, and lifecycle control.
The overlap is where many manufacturers can make progress quickly.
For example:
Existing risk management processes may already provide a structure for identifying AI-related hazards, but they may need to be expanded to consider risks such as model drift, dataset bias, inappropriate reliance by users, or performance degradation in real-world use.
Existing PMS and PMCF processes may already collect relevant post-market evidence, but they may need to be adapted to monitor AI-specific performance signals.
Existing technical documentation may already describe the device architecture, software lifecycle, and performance evidence, but it may need to provide clearer traceability between intended use, training and validation data, AI model behaviour, human oversight, and post-market controls.
This is why a crosswalk approach is useful, not because it reduces compliance to a table, but because it helps manufacturers identify where existing MDR or IVDR systems can be used, where they need strengthening, and where genuinely new AI-specific controls may be required.
The Main Compliance Question Is Not “AI Act or MDR?”
For most MedTech manufacturers, the relevant question is not whether to comply with MDR or IVDR on one side and the AI Act on the other.
The practical question is:
“How do we build one defensible evidence and governance model that satisfies both?”
That is where many organisations risk creating regulatory debt. They treat AI Act readiness as a future legal question rather than a current development and documentation question.
But AI compliance is shaped by decisions being made now:
How intended use is defined.
How datasets are selected.
How validation is designed.
How human oversight is described.
How performance monitoring is structured.
How updates and retraining are controlled.
How post-market data are reviewed.
These decisions are not cosmetic. They influence whether the future technical file is coherent, whether the evidence package is persuasive, and whether the manufacturer can explain how the AI system remains controlled after deployment.
The manufacturers best positioned for future compliance will be those that do not wait for a late-stage AI Act gap assessment to discover weaknesses that could have been designed out earlier.
At SciMed, we find it useful to think about AI readiness across five interconnected domains:
Govern | Assess | Validate | Control | Monitor
Together, these domains provide a practical framework for understanding how governance, regulatory positioning, validation, documentation, change management, and post-market oversight interact throughout the product lifecycle.
We will return to these themes throughout this article.
Manufacturers that address all five areas early are often better positioned to integrate AI governance into existing quality, regulatory, and post-market systems. Those that address them later frequently find themselves undertaking remediation activities that could have been avoided.
This is one of the reasons we advocate a crosswalk approach rather than treating MDR, IVDR, and the EU AI Act as separate compliance programmes.
EU AI Act × MDR/IVDR Compliance Crosswalk
If you are currently assessing how AI-related obligations interact with your existing MDR or IVDR compliance activities, SciMed’s EU AI Act × MDR/IVDR Compliance Crosswalk is designed to help.
It helps manufacturers identify:
Where existing MDR or IVDR systems may already support AI compliance
Where AI-specific gaps commonly emerge
What evidence and documentation may need to be reviewed
Which governance activities should be prioritised before regulatory scrutiny increases
Download the Crosswalk to review your current position and identify where further assessment may be needed.
Five Questions to Ask About Your Product
One of the difficulties with AI compliance is that manufacturers often look for a single question that determines whether they have a problem. In reality though, there usually isn’t one.
In practice, high-risk classification, AI Act applicability, and future compliance burden are influenced by a combination of factors.
The good news is that most manufacturers can develop a reasonably accurate picture of their likely obligations by asking a handful of practical questions early. These questions are not a substitute for a formal regulatory assessment, however, they are often enough to identify whether AI governance should already be influencing development decisions.
1. Does Your Product Meet the Definition of an AI System?
This may sound obvious, but it is becoming one of the first questions manufacturers need to answer.
Many software products incorporate automation, algorithms, statistical models, rules engines, or decision-support functionality. Not all of these necessarily create the same regulatory considerations. The challenge is that manufacturers sometimes assume that if a product contains software, AI obligations automatically follow. Others assume the opposite and treat AI functionality as simply another software feature.
Neither approach is particularly helpful.
What matters is understanding how the technology functions and whether it falls within the scope of the regulatory definition being applied. More importantly, manufacturers should avoid treating this as a purely legal exercise.
In our experience, the more useful discussion is often operational: If the product relies on training data, model development, performance validation, ongoing monitoring, or future model updates, there is a strong possibility that AI governance considerations will influence development activities regardless of how the final classification question is resolved.
A surprising number of future compliance challenges begin because organisations spend months debating definitions while overlooking governance decisions that need to be made anyway.
2. Is Your Product Already Regulated Under MDR or IVDR?
For most MedTech manufacturers, this question is relatively straightforward, but, it remains one of the most important.
Many AI Act discussions focus on artificial intelligence as though it exists independently of the existing medical device regulatory framework. For manufacturers of medical devices and IVDs, that is never the reality.
MDR and IVDR already require organisations to demonstrate safety, performance, risk management, clinical or performance evidence, quality management, and post-market surveillance:
Those requirements do not disappear because AI is introduced.
If anything, they become more important. One of the assumptions we occasionally encounter is that AI compliance will require a completely separate programme of work. In reality, the strongest compliance strategies often build upon systems manufacturers already have in place.
The challenge is identifying where those systems are sufficient, where they require strengthening, and where genuinely new controls may be needed, This is one of the reasons we advocate a crosswalk approach rather than treating the regulations in isolation.
3. Does Your Product Require Third-Party Conformity Assessment?
This is often one of the most significant questions in determining potential regulatory obligations, manufacturers sometimes focus heavily on the sophistication of the AI system itself.
Regulators, however, are more interested in the regulatory pathway associated with the product. The practical implication is that two technically similar systems may face different regulatory expectations depending on their intended use, classification, and conformity assessment route.
This is where many early-stage companies become frustrated.
They assume the complexity of the technology is the determining factor. In reality, regulatory obligations are frequently shaped by how the product is intended to be used and how conformity is demonstrated. Understanding this distinction early can prevent a considerable amount of unnecessary planning, rework, and uncertainty later in development.
4. Does AI Influence Diagnosis, Treatment, or Clinical Decision-Making?
This is often the point where the discussion becomes more tangible. Many AI-enabled products support activities that directly or indirectly influence healthcare decisions.
Examples may include:
diagnostic support
image interpretation
risk prediction
triage support
treatment recommendations
clinical workflow prioritisation
The question is not whether AI makes the final decision, and in many cases, it does not. The more relevant question is whether the output influences a decision that could ultimately affect patient care. Manufacturers sometimes underestimate the importance of this distinction. The rationale is understandable, human oversight exists, clinicians remain responsible, and any final decisions are reviewed.
However, regulators are often interested in how the AI system influences those decisions, how users interact with outputs, and how inappropriate reliance is prevented.
This is one of the reasons why concepts such as transparency, human oversight, validation, and performance monitoring continue to appear throughout AI governance discussions.
5. Could Incorrect AI Outputs Affect Patient Outcomes?
If there is a single question that manufacturers should spend time discussing, it is probably this one.
Not because it determines classification in isolation, but because it forces organisations to think about risk in practical terms.
What happens if the model performs unexpectedly?
What happens if performance changes over time?
What happens if the underlying data changes?
What happens if users rely on outputs differently than originally anticipated?
These are not hypothetical questions, they are lifecycle questions. Historically, many software compliance discussions focused on whether a system worked at the point of release, but AI introduces a different challenge. Manufacturers must increasingly think about how confidence in performance is maintained after release.
For some organisations, this may require relatively minor adaptations to existing lifecycle processes, but for others, it may require a much broader rethink of governance, monitoring, and evidence generation strategies.
The earlier these discussions happen, the easier they tend to be. The later they happen, the more likely they are to become remediation projects.
Quick Assessment
If you answered “yes” to several of the questions above, there is a strong possibility that AI governance considerations should already be influencing your development strategy.
That does not automatically mean your product will be classified as high-risk, nor does it mean significant compliance gaps necessarily exist. However, it does suggest that classification alone is unlikely to provide a complete picture of future obligations.
In many cases, the more useful exercise is understanding whether governance, validation, documentation, monitoring, and lifecycle controls are developing at the same pace as the technology itself. That is where many organisations begin to discover whether they are building regulatory confidence, or accumulating regulatory debt.
The Most Common Classification Mistakes
One of the challenges with emerging regulation is that manufacturers often focus on the wrong problems first, and that is understandable.
The EU AI Act is new. Guidance is still developing. Industry understanding is evolving. Many organisations are trying to understand obligations while simultaneously developing products, preparing submissions, managing investment expectations, and navigating increasingly complex regulatory pathways.
The result is that certain assumptions begin to appear repeatedly. And whilst some of these assumptions are relatively harmless, others have the potential to create significant regulatory debt.
The following are some of the most common mistakes we expect manufacturers to make as AI governance requirements continue to mature.
Mistake 1: Treating High-Risk Classification as the Finish Line
One of the most common misconceptions is that classification is the primary compliance challenge, but let’s be clear: It isn’t.
Classification is important because it helps determine which obligations may apply, however, knowing that a product may be classified as high-risk does not automatically explain how those obligations will be met.
In many organisations, the discussion becomes heavily focused on:
Will we be classified as high-risk?
Which requirements apply?
What documentation will be needed?
These are sensible questions, but the problem is that they can distract from a more important discussion:
Are we already generating the evidence, governance controls, and lifecycle documentation we will eventually need?
A manufacturer can understand classification perfectly and still discover significant compliance gaps later in development. The strongest organisations treat classification as an input into governance planning, not the final objective.
Mistake 2: Assuming MDR or IVDR Compliance Automatically Solves the Problem
At the opposite end of the spectrum are organisations that assume existing MDR or IVDR compliance activities are already sufficient, and there is some logic to this position; Many of the foundations do already exist.
Manufacturers already perform:
risk management
clinical evaluation
performance evaluation
software lifecycle management
post-market surveillance
quality management
However, AI introduces additional questions, such as:
How was training data selected?
How was validation performed?
How will performance be monitored over time?
How are updates controlled?
How is human oversight maintained?
These questions may align with existing systems, but that does not necessarily mean these systems answer by them.
One of the most productive exercises manufacturers can undertake is identifying where current processes already support AI governance and where further controls may be required, that is considerably more efficient than assuming complete overlap or complete separation.
Mistake 3: Leaving AI Governance Until Technical Documentation Is Being Written
This is where regulatory debt often starts to become visible. The organisation has built a product, development has progressed, performance appears strong, documentation work has begun.
Then the team discovers that important questions have never been formally addressed.
Examples might include:
data governance decisions
dataset provenance
validation rationale
human oversight assumptions
model update processes
performance monitoring plans
None of these issues are necessarily difficult to address, but rather the difficulty arises when they are discovered late. A recurring pattern in regulatory projects is that documentation rarely creates problems on its own, but it is often the documentation that exposes decisions that were never fully considered during development.
When that happens, remediation becomes more expensive, slower, and harder to justify.
Mistake 4: Treating AI as a Software Feature Rather Than a Lifecycle Responsibility
This is a subtle distinction, but an important one. Many organisations understandably focus on the AI model itself, they ask questions like “How accurate is it?” “How well does it perform?” “How does it compare to alternatives?” and these questions matter.
However, regulators are increasingly interested in how performance is maintained over time. Artificial Intelligence is not just a technical capability. It is a capability that must remain safe, effective, and controlled throughout its lifecycle.
That shifts the discussion from: “What does the model do?” to “How do we continue demonstrating confidence in the model after deployment?” and this is where governance, monitoring, oversight, change management, and post-market evidence become increasingly important.
Mistake 5: Underestimating the Importance of Human Oversight
Many AI governance discussions eventually arrive at the same topic: Human oversight. In practice, most manufacturers understand the concept without any issues, but the challenge is demonstrating it.
Statements such as “A clinician remains responsible for the final decision” are often only the starting point, but manufacturers may also need to consider:
how outputs are presented
how limitations are communicated
how inappropriate reliance is mitigated
how users are expected to interact with the system
how performance issues are identified and escalated
Human oversight is not simply about assigning responsibility, it is about designing systems that support appropriate decision-making.
The Hidden Cost: Regulatory Debt
Across all five mistakes, a common theme emerges. Most regulatory debt accumulates gradually; very few organisations deliberately create compliance problems, but some actions have delayed or hidden long-term implications:
A decision made during development.
A validation assumption that was never documented.
A monitoring activity deferred until after launch
A governance process left undefined because it appeared non-essential at the time.
Individually, these decisions rarely seem significant, but it is when the coalesce collectively that substantial remediation work will be created later.
One of the reasons we introduced the concept of regulatory debt is because it reflects a pattern we have observed repeatedly across regulated industries. The compliance burden associated with a product is not determined solely by the regulations themselves, it is also determined by the quality of the decisions made before regulatory scrutiny begins.
The manufacturers that navigate emerging AI requirements most effectively are unlikely to be those that wait for perfect regulatory certainty. They are more likely to be the organisations that start building governance, evidence, oversight, and lifecycle controls alongside product development, and it is that approach creates regulatory confidence.
The alternative will create regulatory debt.
How Much Regulatory Debt Is Your Product Accumulating?
Many manufacturers are still in a strong position to address potential gaps before they become significant remediation projects.
The challenge is knowing where to look.
Our EU AI Act × MDR/IVDR Compliance Crosswalk is designed to help manufacturers identify:
where existing MDR and IVDR activities may already support AI compliance
where common governance gaps emerge
what evidence may need strengthening
which areas should be prioritised before regulatory scrutiny increases
Download the Crosswalk to assess your current position and identify where further review may be beneficial.
Why Classification Is Only the Beginning
One of the risks in any emerging regulatory area is becoming overly focused on a single question, and in the context of the EU AI Act, that question is often:
“Will our product be classified as high-risk?”
As we have discussed, classification matters, but it is not, however, the be-all-and-end-al. Classification does not determine whether a manufacturer is prepared. A manufacturer can understand its classification perfectly and still face challenges relating to:
Governance,
Evidence generation,
Technical documentation,
Validation,
Lifecycle management, or
Post-market monitoring
In many ways, classification is best viewed as the starting point for compliance planning rather than the final objective, with the more important question is often:
“If regulatory scrutiny increased tomorrow, could we clearly demonstrate how our AI system is governed, validated, monitored, and controlled?”
That is where readiness begins.
The SciMed Medical AI Governance Framework
As manufacturers begin evaluating AI-related obligations, one challenge becomes immediately apparent; the requirements are spread across multiple domains:
Regulatory.
Clinical.
Technical.
Quality.
Post-market.
Software.
Data governance.
This can make compliance planning feel fragmented. In order to simplify this, we developed the SciMed Medical AI Governance Framework. The framework is designed to help manufacturers assess AI readiness across five interconnected areas.
1) Govern
Who owns AI governance?
Who is accountable?
How are responsibilities defined?
How are decisions documented?
Governance weaknesses often remain invisible until organisations attempt to justify decisions retrospectively.
2) Assess
What obligations apply?
What risks exist?
Where are the gaps?
Which assumptions need validating?
Effective compliance begins with understanding the problem accurately.
3) Validate
How do we know the system performs as intended?
How is performance supported?
How are outputs reviewed?
How is confidence maintained?
For many manufacturers, validation becomes one of the most important areas of future regulatory scrutiny.
4) Control
How are changes managed?
How is documentation maintained?
How are risks controlled?
How is compliance embedded into day-to-day operations?
This is where governance becomes operational rather than theoretical.
5) Monitor
How will confidence be maintained after deployment?
How are issues identified?
How are trends reviewed?
How are corrective actions triggered?
AI governance does not end at market access.
In many respects, that is where it begins.
A Quick AI Compliance Readiness Sense Check
Before undertaking a detailed assessment, manufacturers can often gain valuable insight by asking a handful of practical questions.
Consider the following:
Do we have clear ownership and accountability for AI-related activities?
Have we identified applicable AI-related obligations and potential compliance gaps?
Can we demonstrate how AI performance has been validated and reviewed?
Do we have documented processes for managing AI-related changes and lifecycle activities?
Do we have mechanisms for ongoing monitoring and oversight?
If you are uncertain about several of these areas, it may indicate that AI governance considerations have not yet been fully integrated into development, quality, or regulatory processes. Whilst that does not necessarily mean significant compliance gaps exist, it does, however, suggest that a more structured readiness assessment may be worthwhile.
If you would like a more structured benchmark of your current position, our Medical AI Compliance Scorecard provides a practical self-assessment across the same five domains discussed throughout this article:
Govern | Assess | Validate | Control | Monitor
The scorecard is designed to help manufacturers identify areas of relative strength, highlight potential governance gaps, and prioritise future activities before regulatory scrutiny increases.
Many organisations discover that they have mature processes in some areas while other aspects of AI governance remain underdeveloped. Understanding these imbalances can often be more valuable than any single overall readiness score.
What Should Manufacturers Do Next?
The answer depends largely on where the organisation currently sits in their development lifecycle:
If You Are Still Determining Applicability
Focus on understanding:
AI Act relevance
MDR and IVDR interaction
Conformity assessment implications
Governance expectations
The objective is clarity.
If Development Is Already Underway
Focus on identifying potential sources of regulatory debt.
Review:
Validation activities
Data governance
Oversight arrangements
Technical documentation strategy
Post-market planning
The objective is readiness.
If Your Product Is Already On The Market
Many manufacturers are assessing AI obligations for products that were developed before the EU AI Act was finalised.
This is particularly common for:
AI-enabled software
Image analysis tools
Diagnostic support systems
Clinical decision support technologies
In these cases we know the product functions effectively, but rather the challenge is determining whether the evidence, governance, documentation, and lifecycle controls supporting the AI system remain sufficient in light of evolving regulatory expectations.
Manufacturers should consider:
Whether intended use has evolved,
Whether AI functionality has changed over time,
Whether validation evidence remains appropriate,
Whether post-market monitoring adequately addresses AI-specific risks, or
Whether governance decisions can be clearly justified and documented.
For existing products, the objective is often less about building compliance.
The objective is to identify where regulatory debt may already exist.
A structured gap assessment can help determine whether governance, documentation, and monitoring activities need strengthening before future regulatory scrutiny increases.
If Technical Documentation Is Being Prepared
Focus on demonstrating traceability.
Ensure governance, evidence, validation, monitoring, and lifecycle activities are supported by documentation and rationale.
The objective is defensibility.
If Market Access Activities Are Approaching
Focus on confidence.
By this stage, organisations should be able to clearly explain:
how the AI system functions
how performance is supported
how risks are managed
how oversight is maintained
how ongoing monitoring will occur
The objective is regulatory confidence.
Final Thoughts
Many organisations currently view the EU AI Act as a future compliance challenge, and whilst that may be true, the decisions that determine future compliance success are often being made today.
How intended use is defined?
How validation is approached?
How evidence is generated?
How governance is established?
How monitoring is planned?
The organisations best positioned for future success are unlikely to be those waiting for complete regulatory certainty, they will be the organisations building governance, evidence, oversight, and lifecycle controls alongside innovation.
That is ultimately what regulatory confidence looks like and it is usually the most effective way to avoid regulatory debt.
EU AI Act × MDR/IVDR Compliance Crosswalk
If you are assessing the impact of AI-related obligations on an existing or planned medical device, our practical compliance crosswalk is designed to help.
It provides:
✓ Mapping between AI Act and MDR/IVDR requirements
✓ Areas of regulatory overlap
✓ Common governance and documentation gaps
✓ Practical implementation considerations
✓ A structured starting point for AI compliance planning
In addition, you will receive the Medical AI Compliance Scorecard, a practical self-assessment designed to help manufacturers benchmark readiness across governance, validation, documentation, change control, and post-market monitoring activities.
Together, the Crosswalk and Scorecard provide a structured starting point for understanding where AI governance considerations may already be influencing regulatory readiness.
Download the EU AI Act × MDR/IVDR Compliance Crosswalk
Frequently Asked Questions
Does the EU AI Act apply to all AI-enabled medical devices?
Not necessarily. Applicability depends on factors including intended use, regulatory status, and the role of AI within the product.
What makes a medical device high-risk under the EU AI Act?
Many medical devices and IVDs subject to third-party conformity assessment may fall within the high-risk category. However, classification should always be assessed within the context of the specific product and regulatory pathway.
How does the EU AI Act interact with MDR and IVDR?
The regulations address different but overlapping areas. MDR and IVDR focus on safety, performance, and market access, while the AI Act introduces additional expectations relating to governance, transparency, oversight, monitoring, and lifecycle management.
Can Software as a Medical Device (SaMD) be classified as high-risk?
Potentially, yes. Classification depends on the intended use of the software, its regulatory status, and the conformity assessment route that applies.
What documentation may be required for AI-enabled medical devices?
Requirements will depend on the product, but manufacturers should expect increasing scrutiny around governance, validation, risk management, monitoring, and technical documentation supporting AI functionality.
What is regulatory debt?
At SciMed, we use the term regulatory debt to describe the future compliance burden created when governance, evidence generation, documentation, oversight, and lifecycle considerations are deferred during product development. Like technical debt, regulatory debt often accumulates gradually and becomes visible only when regulatory scrutiny increases
