SaMD and AI Software Registration in Russia

1. Key takeaways

Autonomously operating software is registered in Russia as an active medical device, with the risk class determined by the application scenario. Devices incorporating artificial intelligence technologies are additionally covered by a dedicated chapter of Resolution No. 1684, which establishes separate rules for their registration and modification (involving the change grounds of p. 135 and the revocation ground in item “z” of p. 137). Beyond the registration track, Order No. 540n designates the data that AI software uploads automatically to the RZN information system as one of the formal sources of safety monitoring data. Software developers must therefore plan for two regulatory dimensions at once: the registration dossier and the post-market data flow.

The combination is demanding but manageable with early design decisions. The version strategy, the change boundary and the monitoring data handling need to be defined before the application is filed, because after registration the permitted change grounds become fixed and unauthorised changes can endanger the certificate itself. Teams that treat the Russian AI rules as a product design input, rather than as a compliance afterthought, avoid the costly rework of retrofitting a release process onto a registered algorithm.

The classification premise matters as much as the AI chapter. Treating autonomous software as an active device means that the risk class, and with it the depth of the evidence plan, follows from the clinical scenario in which the software operates rather than from the technology stack. The same algorithm supporting triage and supporting scheduling can land in different classes, and the classification conclusion should therefore be documented early, stating the application scenario, the intended user and the decision the software supports. This documentation later anchors both the dossier narrative and the monitoring obligations.

2. Legal basis

The instruments governing SaMD and AI software registration in Russia are summarised below.

3. Expert insights

Insight 1: AI iteration and registration modification are in tension. Resolution No. 1684 establishes a dedicated list of permitted change grounds for AI software, and changes made on grounds outside that list conversely constitute a ground for revoking the registration certificate (item “z” of p. 137). This means the version strategy must be designed at the registration stage and cannot follow the rapid-iteration habits of the internet industry. The practical answer is a defined change list: which modifications are covered by permitted grounds, which require a formal change application, and which are deferred to the next registered version. Publishing, retraining and model updates all need to be mapped onto this list before the certificate is issued.

Insight 2: the monitoring side brings machine data into regulatory view for the first time. Order No. 540n designates the data that AI-enabled device software with automatic upload functionality sends to the RZN information system as a monitoring data source. Data dictionaries, upload frequencies and the handling of anomalies therefore need SOP support just like traditional complaint handling. A manufacturer whose algorithm automatically transmits performance indicators must operate the pipeline with the same discipline as a vigilance system: defined owners, defined response times and documented escalation, because the regulator now sees the machine-level data directly.

Insight 3: the classification approach changed with the 2025 amendment. The amendment by Decision No. 18 aligns with the IMDRF treatment of software as a medical device and consolidates the criteria for merging multiple models into one registration unit. When preparing a new Russian submission for an existing software product, previous classification conclusions should not be carried over unexamined: the product family boundaries, the risk class and the registration unit structure may all differ under the amended rules, and the classification outcome shapes the entire evidence plan.

Operationally, the automatic upload pipeline needs an owner inside the manufacturer organisation. Data quality problems, transmission failures and unexpected values in uploaded indicators can all trigger regulatory questions, and the answer must come from someone who understands both the algorithm and the monitoring rules. Building a small cross-functional routine, in which the quality function reviews the uploaded data periodically and the software team maintains the data dictionary, keeps the pipeline defensible. The cost of this routine is small compared with the exposure created by an unmonitored data stream that the regulator reads as part of the safety picture.

4. Practical recommendations

1. Determine the software version and the change boundary before registration, form a defined change list, and design the release process around it.
2. Establish a unified process for handling software complaints and automatically uploaded data, and respond within the time limits set by Order No. 540n.
3. Prepare lifecycle and risk management documentation in accordance with GOST IEC 62304-2022 and GOST ISO 14971, aligned with the focus areas of the Russian expert organisations.
4. Re-verify the risk class under Decision No. 173 as amended by Decision No. 18 for any product previously classified, rather than reusing old conclusions.
5. Document the data dictionary and upload behaviour of the AI software in the dossier, so that the monitoring data flow is transparent to the reviewer.

5. Verification checklist

• □ The risk class of the software has been re-checked under Decision No. 173 (including the amendment by Decision No. 18)
• □ The change grounds for the AI product have been confirmed item by item against p. 135
• □ The software release process is bound to the defined change list
• □ An SOP for handling automatically uploaded data has been established
• □ The lifecycle and risk management documents comply with GOST IEC 62304-2022 and GOST ISO 14971

Regulatory information verified as of October 29, 2026.

GRZAN supports software and AI developers registering medical device software for the Russian market, including classification under the EAEU rules, the design of version and change strategies compatible with p. 135 of Resolution No. 1684, and the establishment of safety monitoring processes for automatically uploaded data under Order No. 540n. For assistance with SaMD and AI registration in Russia, contact us at info@grzanglobal.com.