Software and AI Medical Devices under Moroccan Regulation

1. Key takeaways

Article 1, item 1 of Law No. 84-12 expressly includes, within the definition of a medical device, accessories and software intervening in its operation. Item 5 separately defines software as the whole of the computer programs necessary for the medical device to operate as intended by the manufacturer. These two provisions mean that the software position under Morocco’s current texts leans toward embedded and accompanying software. Whether stand-alone software (SaMD) and artificial intelligence software must be registered separately must be confirmed against the current AMMPS checklist and the classification rules.

The careful reading matters because the Moroccan text predates the era in which regulators wrote software-specific rules. Law No. 84-12, from 2013, does not use the language of stand-alone software that the European Union MDR (2017/745) later adopted. That absence does not leave software unregulated in Morocco; it means the regulatory basis must be sought in the checklist and the classification rules, which introduces an element of uncertainty that projects must manage explicitly.

For software products, Article 16 carries unusual weight. Machine learning products that expand their intended use through post-market updates may trigger the notification obligations of Article 16, and software iterations that change the algorithm or the clinical use may fall under re-application for registration rather than a simple change notification. Version governance is therefore a regulatory question, not merely an engineering one.

2. Legal basis

Verification note: the text of Law No. 84-12 (2013) predates the European Union MDR (2017/745), and its software definition does not adopt the expression stand-alone software. GRZAN has not identified a dedicated Moroccan regulatory text on stand-alone or artificial intelligence software; determinations must rest on the current AMMPS checklist, and the conclusions in this topic are labelled a practical estimate.

3. Expert insights

Insight one: the division of work between Article 1, item 1 and item 5. Item 1 brings software intervening in the operation of the device into the composition of the device itself. Item 5 gives software a functional definition: the whole of the computer programs necessary for the device to operate as intended by the manufacturer. Both formulations revolve around making the device run, which shows that the legislator’s conception was of software as a constituent part of a device rather than as a product category in its own right.

Insight two: there is a generational gap against the European Union MDR. The EU MDR expressly treats stand-alone software as a medical device and provides classification rules for it. The text of Law No. 84-12 has no corresponding wording. This does not mean stand-alone software escapes regulation in Morocco; it means the regulatory basis must be sought in the checklist and the classification rules, and the resulting uncertainty should be treated as a project risk with its own mitigation steps, including early confirmation with AMMPS or the licensed establishment.

Insight three: the extra difficulty for artificial intelligence software is intended use drift. Article 1, item 6 anchors the intended purpose in the use given by the manufacturer in the labelling, the instructions for use, or the promotional material. A machine learning product that expands its use through post-market updates may trigger the change notification obligation of Article 16, because the nature of the device has changed. For AI products, the boundary between improvement and new intended use is the single most consequential line the project team draws.

Insight four: Article 16 matters disproportionately for software products. The provision requires the certificate holder to evaluate clinical data continuously and to notify in writing any change affecting that data or the content of the registration dossier, and any change in the nature of the device requires a new application for registration. A software version iteration that changes the algorithm or the clinical use may therefore fall under re-application rather than change notification. Classifying each iteration correctly requires a documented mapping between versions and intended use.

Insight five: wireless and connected functions stack a second regulatory track. Software devices with Wi-Fi or Bluetooth functions require, in addition to AMMPS registration, type approval from the national telecommunications regulator (ANRT) (see topic 30). Two tracks with different authorities, timelines, and change rules apply to the same product, and both must be represented in the project plan from the start.

4. Practical recommendations

1. Determine first whether the software is embedded or stand-alone. Embedded software is registered together with the host device; for stand-alone software, confirm with AMMPS or the licensed establishment whether separate registration is currently possible, and record the answer in the project file.
2. Fix the intended use in three documents. State the purpose of the algorithm identically in the labelling, the instructions for use, and the promotional material, so a later update cannot be read as a change of intended use.
3. Bring version iterations into change management. Maintain a table mapping versions to intended use, and judge each iteration as either a change notification or a re-application for registration before release.
4. Plan wireless approval early. For products with wireless functions, place the ANRT approval in the project schedule at the start, since it runs on a separate timeline from registration.
5. Cite both the statute and the checklist. Because determinations for software products carry uncertainty, reference Article 1, item 5 together with the current checklist position in the dossier.

5. Verification checklist

• □ Software determined as embedded or stand-alone
• □ Current registration position for stand-alone software confirmed with AMMPS or the licensed establishment
• □ Intended use statements identical across labelling, instructions for use, and promotional material
• □ Table mapping versions to intended use established
• □ Each iteration judged as change notification or re-application for registration
• □ Wireless-function products placed in the ANRT approval plan
• □ Dossier cites both Article 1, item 5 and the current checklist as grounds

GRZAN supports manufacturers of software and AI-enabled medical devices entering the Moroccan market, including embedded versus stand-alone determinations, intended use documentation, version and change management aligned with Article 16, and coordination of registration documentation and conformity files. For assistance, contact GRZAN at info@grzanglobal.com.

Regulatory information verified as of 30 October 2026