How Minor Code Updates Can Trigger High‑Risk AI Classification

The EU AI Act classifies an AI system as high‑risk when it directly influences health, safety or fundamental rights, or when it is used in regulated sectors such as medical device procurement. Even minor code tweaks can move a compliant tool into that category if they affect the system’s intended use, data handling or decision‑making transparency.

Typical updates that trigger re‑classification include adding new data sources, altering matching algorithms, or expanding the scope of automated recommendations. In a recent supply‑matching module upgrade, a simple rule change introduced dynamic pricing, prompting a high‑risk assessment. Before rollout, teams should run an impact matrix, involve legal counsel, and document the change in the system’s technical file. Governance steps—code review, risk register update, and a pre‑deployment audit—keep the update low‑risk and streamline regulator interaction.

What the EU AI Act defines as high‑risk AI

The EU Artificial Intelligence Act designates an AI system as high‑risk when its intended purpose matches any category in Annex III. Annex III lists medical‑device functions that influence clinical decisions, such as scheduling surgeries or matching supplies to procedures. The classification depends on the function’s effect on patient safety, not on the amount of code changed.

Regulators ask whether the AI directly impacts diagnosis, treatment, or ongoing patient monitoring. A "yes" answer places the system in the high‑risk regime, even if the change is a routine bug fix or a minor feature addition.

Criterion	Implication for operations
Intended purpose	Supports clinical decision‑making (e.g., surgery scheduling, supply matching)
Patient safety impact	Potential harm if the AI makes an error
Regulatory focus	Functions that directly shape treatment pathways

Consider an autonomous procurement module that selects sterilized instruments for a planned procedure. If the module selects the wrong set, the sterile field is compromised and patient outcomes are at risk. Adding a new vendor to the database, while seemingly minor, must be reviewed against these criteria before release to ensure compliance and maintain safety.

Typical software changes that raise the risk level

Adding an autonomous ordering algorithm that selects items based on patient data changes a simple procurement tool into a decision-making system. The algorithm evaluates patient-specific criteria—such as allergy status, procedure type, and implant compatibility—before placing an order. Because the output directly influences clinical care, the software moves into the high-risk category under the EU AI Act.

Enabling real-time decision support for operating-room block allocation creates another risk trigger. The module continuously balances surgeon schedules, equipment availability, and case urgency. Any error can cause a mismatch of resources, leading to delays or unsafe conditions. Real-time adjustments qualify as high-risk functions that affect health outcomes.

Integrating new data sources, such as synthetic surgical schedules, expands the system’s input scope. When these synthetic feeds are incorporated into clinical workflows—such as predicting supply needs for upcoming cases—the AI’s influence widens. The act treats added data pipelines that affect patient care as high-risk, especially if the data are used for autonomous decisions.

Checklist for developers

• Does the change make a direct recommendation that impacts patient treatment?
• Is the output used to trigger autonomous actions without human verification?
• Are new data streams linked to clinical decision points?

When any answer is yes, the update likely raises the AI’s risk classification. For teams working with synthetic inputs, see our synthetic data solutions for compliance guidance.

Case study: Updating a supply‑matching module

Consider a case where a healthcare organization updates its supply-matching module. Initially, this module only suggested items based on surgical schedules and existing contracts. However, the update introduces a significant change: the system now automatically places orders after verifying contract terms and regulatory compliance.

This new functionality alters how procurement timing is managed. For example, if a surgical procedure is scheduled and the system identifies a necessary supply, it can now place the order without manual intervention. This directly impacts the availability of supplies, which is crucial for ensuring timely patient care.

Regulators may interpret this enhancement as a function that influences patient outcomes, potentially categorizing it as a medical device under the EU AI Act. Such a classification would trigger high-risk status, subjecting the module to stricter regulatory oversight.

To illustrate the implications:

Functionality	Risk Level
Item suggestion only	Low Risk
Auto-order placement	High Risk

This shift necessitates careful consideration of how updates are implemented. Organizations must assess whether new features align with regulatory definitions and prepare for potential scrutiny from regulators. Integrating a system like mintHealth can help streamline procurement while maintaining compliance through its designed checks and balances.

How to assess impact before deployment

Before deploying any updates, assess the potential impact on the AI system's risk classification. Conduct a functional impact analysis that links each change to the criteria outlined in Annex III of the EU AI Act. This will help identify whether the modifications could elevate the risk level of your AI system.

Document the intended use, data flow, and safety implications for the update. Consider the following checklist to ensure thorough analysis:

• Intended Use: How will the updated system be utilized? Will it change the context in which it operates?
• Data Flow: What data will be inputted or generated? Are there new data sources or changes in data processing?
• Safety Implications: Will the changes introduce new risks? How could they affect operational efficiency?

Engage a compliance officer early in the process. Their expertise is crucial to verify if the change alters the system's risk status. For example, if you update a supply-matching module to incorporate real-time inventory data, this change may enhance efficiency but could also impact risk classification due to new data handling. The compliance officer can provide guidance on whether this adjustment necessitates a reassessment of compliance with the EU AI Act.

Governance steps to keep updates low‑risk

To minimize the risk associated with software updates in high-risk AI systems, implement robust governance measures.

First, maintain a detailed change-log. This log should document the purpose of each update, the data inputs involved, and the outcomes of any regulatory reviews. A simple template could look like this:

Update Date	Purpose	Data Inputs	Regulatory Review Outcome
2023-10-01	Enhance supply-matching accuracy	Contract data, inventory levels	Approved

Second, establish a review board that includes stakeholders from legal, clinical, and engineering backgrounds. This team should evaluate each planned update for potential regulatory implications, ensuring that all perspectives are considered before deployment.

Lastly, employ automated testing to verify that new code does not expand the system’s decision-making scope. For example, if an update introduces new algorithms, tests should confirm that they do not alter the core functions or intended uses of the AI system.

By following these steps, organizations can better manage the risks associated with software updates and remain compliant with regulatory standards. For more guidance on maintaining compliance, contact our team.

Preparing for regulator interaction

Engaging with regulators after a software update requires thorough preparation. Start by compiling evidence of compliance with the EU AI Act’s transparency and documentation requirements. This includes:

• Documentation of the AI system's development process.
• Records of data used for training and validation.
• Details of the risk management process applied to the update.

Next, be ready to provide a risk assessment report that maps the update to Annex III items of the EU AI Act. This report should detail:

• The nature of the software change.
• Potential risks introduced by the update.
• Mitigation strategies implemented to address those risks.

For example, if the update involves a supply-matching module that alters how items are selected based on regulatory compliance, the risk assessment should address potential impacts on operational efficiency.

If the change is likely to be classified as high-risk, schedule a pre-submission meeting with the notified body. This proactive approach can clarify expectations and streamline the approval process. Prepare a checklist for this meeting:

• Summary of the update and its implications.
• Documentation of compliance efforts.
• Risk assessment findings.
• Questions or concerns regarding the regulatory process.