Software and AI Medical Devices in Turkey: Rule 11 of Annex VIII

1. Key takeaways

Standalone software, including artificial intelligence products, is not a grey zone in Turkish law: it is regulated squarely as a medical device, and its class follows a single, sharply consequential rule. Before any AI software project is scheduled for Turkey, the classification outcome under Rule 11 of Annex VIII should be established in writing, because it drives notified body involvement and the depth of the technical file. The points below capture the legal anchors and the practical outcome for typical diagnostic-support products.

• Software in Turkey is a device. The definition of an active device (aktif cihaz) in item 2 of subparagraph (b) of paragraph 1 of Madde 3 of the Regulation expressly includes yazılım (software).
• The classification rules for software sit in Section 6.3 of Ek VIII, Rule 11 (Kural 11). Following its logic: software intended to provide information used to take diagnostic or therapeutic decisions generally falls into Class IIa; where such decisions may cause death or an irreversible deterioration of a person’s state of health, the class rises to Class III; where the decisions may lead to serious deterioration or require surgical intervention, the class is IIb; software intended for monitoring of physiological processes is Class IIa, and where it monitors vital physiological parameters it is IIb; all other software is Class I.
• GRZAN performed a full-site search of the TİTCK website and found no dedicated guideline or announcement on software or artificial intelligence. This means Turkey currently has no independent AI device pathway; classification can only return to Section 6.3 of Ek VIII, Rule 11.
• From this flows a clear practical conclusion: the overwhelming majority of Chinese medical AI software products with diagnostic-support or decision-support functions will not fall below Class IIa in Turkey, and therefore need notified body involvement and a more complete technical documentation set.

2. Legal basis

The table below consolidates the instruments cited in this article. Note the third entry: the communiqué on electronic instructions for use is recorded in the TİTCK regulatory library, but its Official Gazette issue number was not obtained from a gazette source, so the publication date is handled as a practical estimate rather than a verified figure.

3. Expert insights

Insight one: software was written into the definition of an active device, not into a separate category. This legislative choice determines that software must borrow the classification channel for active devices (Section 6 of Ek VIII) rather than walking the invasiveness and duration-of-use logic of Sections 1 to 5. The result is that the classification of software is driven entirely by the severity of the consequences of the decision it supports, not by whether the product touches the human body. A cloud-based image analysis tool and a bedside monitor are therefore assessed on the same axis: what happens to the patient if the output is wrong.

Insight two: IIa is the starting point, not the ceiling. A common misjudgement is to plan an AI product at the lowest class. Under Kural 11, as soon as the output of the software is used to support diagnostic or therapeutic decisions, IIa is already the lowest tier; once life and death or irreversible harm is in play, the class jumps directly to III. GRZAN has assessed a number of domestic imaging AI projects, and where the intended purpose statement says the product replaces the physician in making the diagnosis, the Turkish route is Class III. The wording of the intended purpose is therefore not a marketing question but a classification question, and it should be settled before the notified body quotation is requested.

Insight three: the absence of a dedicated guideline is both a gap and a window of opportunity. Turkey currently has no dedicated software or AI guideline, which means the regulator relies in enforcement mainly on the rule text of Ek VIII and the technical judgement of notified bodies. This makes the intended-purpose wording in the technical documentation a controllable variable: framing the output rigorously as supporting rather than replacing the clinician is a legitimate and compliant route-optimisation measure. The drafting must remain truthful to the actual behaviour of the product, because the notified body will test the claim against the algorithm description and the clinical evidence in the file.

4. Practical recommendations

• At project initiation, run a four-tier trial classification with Kural 11 (I / IIa / IIb / III) and record the conclusion and reasoning in the classification rationale.
• Draft the intended purpose with care. Any wording such as automatic diagnosis, autonomous decision-making or replacing the physician should trigger planning of cost and timeline at Class III.
• Establish change management for software versions and training data. Where a model iteration changes the performance boundary, it is a change that must be re-assessed, and this should be written into the quality system documentation.

5. Verification checklist

• □ The product has been confirmed as standalone software or software within a device, citing Madde 3, paragraph 1 (b)-2.
• □ A four-tier trial classification has been completed under Ek VIII, Section 6.3, Kural 11, with a written record.
• □ The intended-purpose text has been reviewed and contains no wording that raises the class, such as autonomous decision-making or replacing the physician.
• □ It has been confirmed that no TİTCK dedicated software guideline applies (as of the verification date).
• □ An assessment procedure for software versions and algorithm changes has been established.

Regulatory information verified to 29 October 2026. The provisions listed in this article were checked against the original text on the Turkish legislative information system (MevzuatNo 38657); the conclusion that no dedicated software guideline exists is based on a full-site search of the TİTCK website and is valid only for the status on the verification date; the publication date of the electronic instructions for use communiqué was not obtained from gazette text and is handled as a practical estimate.

How GRZAN can help. GRZAN provides medical device and IVD registration, quality system, authorised representative and local testing support for the Turkish market. Our team manages TITCK approval applications and UTS registrations, and supports post-market vigilance obligations. Business enquiries: info@grzanglobal.com