Kazakhstan Software and AI Medical Devices: Classification, Data Governance and Change Strategy

1. Key takeaways

Dedicated software for medical purposes, whether standalone software or embedded software, qualifies as a medical device under the legal frameworks of both the Eurasian Economic Union and Kazakhstan. Its classification follows the classification rules of Union Decision No. 173, and Amendment No. 18 dated February 18, 2025 specifically updated the assessment approach for the software category. A software dossier must add three blocks of evidence beyond the conventional technical documentation: algorithm description and verification, data governance (origin of training data, annotation quality, population representativeness), and software lifecycle and version management. Because software versions iterate rapidly, the change strategy must be designed at first registration, not improvised later; leaving the boundary between registered configuration and internal updates undefined is the most expensive mistake a software manufacturer can make in this jurisdiction.

2. Legal basis

3. Expert insights

Insight one: Amendment No. 18 of February 18, 2025 is required reading for every software product. The Union classification rules updated the approach for the software category in this amendment. Any classification conclusion for a software product formed before 2025 should be rechecked against the new approach, and the differences between the Kazakh national classification rules and the Union rules are most concentrated in exactly this area, so a single recheck protects both the national and the Union filing simultaneously. For products already registered, the recheck should be documented as a formal reclassification memo, so that the basis for the current class is on file if the authority ever asks.

Insight two: the software validation report is one of the bilingual documents in the Kazakh dossier. Under Order No. ҚР ДСМ-16, validation reports on software belong to the list of documents required in both Russian and Kazakh. Chinese manufacturers frequently miss this item, because most markets do not require software documentation to be localized into two languages, and discovering the requirement mid-review costs a translation cycle and an avoidable deficiency letter.

Insight three: for AI devices the evidentiary weight sits on data, not on code. For devices with adaptive learning algorithms, the reviewing authorities focus on the lawful origin of training data, annotation quality, population representativeness and bias control, together with the mechanism that preserves performance after algorithm updates. The code itself is rarely the object of review; data governance and validation are. An AI dossier that documents its datasets as rigorously as its architecture is the one that survives questioning. Describing the update retraining pipeline in the same file, with acceptance criteria for each release, further reduces the number of open questions.

Insight four: version iteration is the largest source of compliance cost for software products. Software updates far more frequently than hardware, yet the labeling and instructions for use are dossier content. The change strategy must therefore be designed at first registration: which updates go through a dossier change and which are recorded internally only. Excluding high-frequency minor updates from the change procedure is the key to keeping long-term cost bounded, and that boundary must be written into the quality system, not left to case-by-case judgment. Classifying each release by its impact on safety and effectiveness, in a table agreed at registration, turns a recurring debate into a lookup.

Insight five: embedded software and standalone software carry different documentation duties. Embedded software can be presented as part of the host device’s technical documentation, while standalone software requires its own self-contained technical documentation and risk management file. Determining which type a product is, is the first step of documentation planning, because it decides the shape of the dossier, the depth of the risk file and the structure of the review conversation that follows. Misjudging the type at the outset is a structural error that surfaces late and is costly to unwind.

4. Practical recommendations

1. Recheck the classification of software products against the approach introduced by Amendment No. 18 of February 18, 2025.
2. Prepare the software validation report in both Russian and Kazakh and add it to the bilingual document list.
3. Place the evidence focus for AI products on data governance: lawful origin, annotation quality, population representativeness and bias control.
4. Design the change strategy at first registration, defining which updates go through a dossier change and which are recorded internally.
5. Determine the embedded or standalone software type first, then plan the documentation structure.

5. Verification checklist

• □ Software classification has been rechecked against the approach of Amendment No. 18 of 2025
• □ The software validation report has been prepared in both Russian and Kazakh
• □ Algorithm description and verification evidence are filed in the technical documentation
• □ Data governance materials are complete (origin, annotation, population representativeness, bias control)
• □ Software lifecycle and version management documentation is established
• □ The change strategy is defined, with criteria for dossier changes versus internal records

GRZAN provides registration support in Kazakhstan for manufacturers, importers and authorized representatives, covering software and AI device classification, dossier preparation and expert review liaison. For assistance, contact info@grzanglobal.com.

Regulatory information verified as of October 29, 2026.