Software as a Medical Device: Where Kenya’s Current Framework Falls Short

The Pharmacy and Poisons Board’s new guideline on medical device software gives Kenya real, detailed rules for AI-enabled health tools for the first time. It does not give those rules a new statutory foundation. Software as a Medical Device sits in Kenya today on a guideline issued under a 1957 statute never written with software in mind, and a company relying on that guideline should understand exactly where it is solid ground and where it is not.

A Guideline Sitting on an Old Statute

The Pharmacy and Poisons Board’s authority ultimately traces back to the Pharmacy and Poisons Act, Cap 244, a statute whose text is built around drugs, poisons, and the professionals who handle them, not medical devices and certainly not software. Kenya has no standalone medical devices Act. Device regulation, including the new Medical Device Software guideline published on 16 April 2026, exists as PPB administrative guidance rather than as a regulation made under a statute that expressly defines “medical device” or “software” in its own text. That is a materially different legal footing from a gazetted statutory instrument. A guideline can generally be revised or withdrawn by the regulator issuing it far more easily than a regulation can, and a company relying on it should treat it as current expectation rather than settled law with the enforcement certainty of a statutory provision. This is precisely the structural gap the pending Health Products and Technologies Regulatory Authority Bill is designed to close: as originally drafted, it would repeal the Pharmacy and Poisons Act outright and create a new Authority with jurisdiction expressly extending to medical devices, in-vitro diagnostics, and digital health products, an authority the current PPB regime does not clearly have on the face of its own founding statute. Until that Bill passes the Senate and receives assent, Kenya’s SaMD framework runs on guidance layered onto a statute that predates it by nearly seventy years.

Registration Assumes a Fixed Product

Kenya’s device registration model, including the five-year registration certificate and the post-market variation-notification process built for physical devices, was designed around a product that does not change after approval. A pacemaker approved today is, materially, the same pacemaker in year four of its certificate. An adaptive AI model is not. The Medical Device Software guideline’s own answer to this, requiring manufacturers to define permitted model evolution and build in rollback capability, is a genuine attempt to address the mismatch, but it is a guideline-level patch on a registration architecture that was never rebuilt around continuously changing products. Whether PPB’s existing variation-notification process, designed for a manufacturer changing a physical specification, actually functions well for a model that updates itself between scheduled reviews is an open operational question this article cannot resolve from published materials alone, and a company should raise it directly with PPB rather than assume the guideline has fully solved it.

A Second, Separate Compliance Track

An AI-enabled SaMD that processes patient data to train or monitor itself does not only face PPB device regulation. It separately triggers Kenya’s Data Protection Act 2019, which requires registration as a data handler for any organisation processing health data, regardless of company size, since the small-business exemption under the 2021 Regulations does not apply to health administration or patient care processing. Where the underlying data includes genetic or other especially sensitive categories, a Data Protection Impact Assessment becomes a separate mandatory step under regulation 49 of the 2021 General Regulations. Neither obligation is addressed by the Medical Device Software guideline itself, which is a PPB instrument focused on device safety and performance, not data protection. A company building an AI SaMD in Kenya is really managing two parallel regulatory tracks, PPB device classification and ODPC data handler registration, and treating the MDSW guideline as the complete compliance picture will leave a real gap.

An Unresolved Liability Question

Kenya has no reported case law or specific statutory provision allocating liability when an AI-enabled device produces an autonomous erroneous output that harms a patient, as distinct from an ordinary product liability claim over a static, non-adaptive device. Existing tort principles around negligence and product liability would presumably apply in some form, but how a court would treat a continuously learning model that behaved differently at the point of harm than it did at the point of PPB approval is genuinely untested here. A company deploying an adaptive AI tool in Kenya should not assume its existing product liability insurance and contractual indemnity structures, likely drafted for conventional software or hardware, adequately anticipate this scenario.