Regulating AI-Enabled Medical Devices: A Preview of What’s Coming to the PPB

The Pharmacy and Poisons Board published its Guideline on Regulation of Medical Device Software in Kenya on 16 April 2026, giving Kenya its first dedicated framework for software-based medical devices, including artificial intelligence and machine learning tools. A health-tech company building or importing an AI-enabled diagnostic, triage, or monitoring tool into Kenya needs to understand what this guideline actually requires before treating an existing app as exempt from device regulation simply because it has no hardware component.

Two Categories, Not One

The guideline distinguishes Medical Device Software, or MDSW, into two categories with different risk profiles. Software as a Medical Device, SaMD, covers standalone software that performs a medical function on its own, such as a symptom-checking or diagnostic-support application that runs independently of any specific hardware. Software in a Medical Device, SiMD, covers software embedded within a physical device, such as the control software inside an infusion pump or imaging machine. The distinction matters because the two carry different risk assessments: an SiMD failure is bounded by what the attached hardware can physically do, while a standalone SaMD’s failure mode depends entirely on how clinicians or patients act on its output, which the guideline treats as its own distinct risk to manage.

Risk Classification Extends the Existing Device Framework

Kenya’s underlying medical device risk classification already runs from Class A, low risk, through Class D, high risk, broadly mirroring the International Medical Device Regulators Forum’s classification principles, and it already governs registration timelines and fees for physical devices under the Pharmacy and Poisons Board’s general medical device guidelines. The MDSW guideline extends this same classification logic to software rather than creating a separate scale, meaning a diagnostic algorithm that could materially affect a clinical decision is expected to sit at a higher class, with correspondingly more documentation, than a purely administrative or wellness-tracking application. The guideline references internationally recognized standards, including IEC 62304 for software lifecycle processes and ISO 14971 for risk management, as the technical baseline manufacturers are expected to demonstrate compliance against.

What the Guideline Requires Specifically for AI and Machine Learning

The guideline’s treatment of AI-enabled software goes further than a generic software safety framework. Developers are expected to follow Good Machine Learning Practice principles, meaning training data must be broad and genuinely representative of the patient population the tool will be used on in Kenya, and training data must be kept separate from the data used to test the model’s performance, a basic safeguard against a model that only looks accurate because it was tested on data it already learned from. Beyond initial approval, the guideline requires ongoing monitoring of real-world performance with periodic reporting back to the regulator, rather than treating a one-time pre-market evaluation as sufficient. For continuously learning systems, meaning models that keep updating themselves after deployment rather than staying fixed once approved, manufacturers must specifically define how the model is allowed to evolve, maintain data integrity controls, and build in anomaly detection with the ability to roll back to an earlier, previously validated version of the model if something goes wrong. Cybersecurity is treated as a mandatory design requirement rather than an afterthought, with secure-by-design and secure-by-default expectations covering encryption, user authentication, and continuous vulnerability monitoring.

What This Means for a Company Building or Deploying AI Health Tools in Kenya

A company should not assume a purely digital health product falls outside PPB oversight simply because it involves no physical device. If the software performs a diagnostic, monitoring, or treatment-support function, it is now within scope of a specific published guideline that expects documentation most digital health startups do not maintain by default, including formal risk classification, real-world performance monitoring commitments, and, for adaptive AI models, an explicit rollback and anomaly-detection design. Because this guideline was published only recently, a company should confirm directly with the Pharmacy and Poisons Board whether it is being applied as final, binding guidance or is still being refined in practice, and should not assume the classification and documentation expectations described here are the last word without checking current PPB guidance at the point of application.