FDA AI/ML-Enabled Medical Devices + SaMD + Clinical Decision Support: The 2026 Governance Playbook

The FDA has spent the last six years moving from a 2019 SaMD Discussion Paper into a working operational regime for AI/ML-enabled medical devices. The four pillars to know in 2026 are the AI/ML SaMD Action Plan (January 2021), the predetermined change control plan (PCCP) guidance (final October 2023), the Software as a Medical Device guiding principles (FDA, Health Canada, MHRA co-published 2019 with subsequent updates), and HHS Section 1557 of the Affordable Care Act (final rule May 2024) which explicitly covers AI-based clinical decision support tools. This playbook maps each pillar onto the governance artefacts a hospital, payer, or device manufacturer needs in production. Updated 2026-05-20.

The FDA's AI/ML medical device track is older than the generative AI wave and has been the operational training ground for how the agency thinks about adaptive software. The first PMA approval of an AI-enabled device (IDx-DR) dates to 2018, and the FDA's running list of authorised AI/ML-enabled medical devices passed 950 entries by the end of 2024. The agency's current public posture rests on four primary documents.

Document 1: The FDA Software as a Medical Device (SaMD) Action Plan (January 2021). The Action Plan set five workstreams: tailored regulatory framework, Good Machine Learning Practice (GMLP), patient-centered approach, regulatory science methods, and real-world performance monitoring. The 10 GMLP guiding principles, jointly published by FDA, Health Canada, and the UK MHRA in October 2021 with subsequent updates, became the de facto checklist that audit teams now read against.

Document 2: The PCCP guidance (final October 2023, draft from April 2023). The PCCP - "Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence/Machine Learning (AI/ML)-Enabled Device Software Functions" - is the operational answer to the question of how to modify an AI/ML device after authorisation without filing a new 510(k), De Novo, or PMA for every change. The PCCP is a submitted plan that defines the modifications the sponsor may make and the protocols by which those modifications will be validated.

Document 3: The FDA premarket software guidance (June 2023 final). "Content of Premarket Submissions for Device Software Functions" establishes the documentation expectations for any software-driven device including AI/ML systems - architecture, requirements, testing, and risk management.

Document 4: HHS Section 1557 of the Affordable Care Act (final rule May 2024). The HHS Office for Civil Rights' May 2024 final rule made explicit that covered entities (most hospitals, payers, and federally-funded healthcare programmes) are responsible for ensuring that AI-based "patient care decision support tools" do not discriminate on protected grounds. Section 1557's expectation is now an enforceable obligation that sits beside FDA device clearance.

The Areebi HIPAA compliance hub and the governing GenAI in healthcare operations guide cover the privacy and operational mechanics; this playbook focuses on the device-track and Section 1557 obligations specifically.

Before any AI clinical decision support tool reaches a production governance review, it has to be placed in the SaMD risk categorisation matrix. The matrix, published by the International Medical Device Regulators Forum (IMDRF) and adopted by the FDA, classifies SaMD by combining the "significance of information provided" (treat or diagnose, drive clinical management, inform clinical management) with the "state of healthcare situation" (critical, serious, non-serious).

The resulting four categories - I, II, III, IV - drive the regulatory rigour expected. Category IV (treat or diagnose in a critical situation) demands the highest controls, including pre-market authorisation, full clinical validation, and the most rigorous PCCP if change control is in scope. Category I (inform clinical management in a non-serious situation) may not even require pre-market authorisation but still falls inside the post-market surveillance regime if the device meets the FDCA definition of a medical device.

The categorisation is the first artefact a device sponsor and a deploying hospital should align on. A misclassification - placing what is actually a Category III tool into Category I to avoid the validation burden - is the failure pattern that has driven several of the most public FDA warning letters since 2022. The Areebi healthcare AI learning track walks through the categorisation worked examples; the HIPAA clinical AI playbook covers the data-side mechanics that interact with categorisation.

The PCCP is the mechanism that lets sponsors update AI/ML-enabled devices on a planned cadence without going back to the FDA for every change. The October 2023 final guidance identifies three required components.

Component 1: A description of modifications. The sponsor must enumerate, with specificity, the modifications anticipated over the device lifecycle. Examples include retraining the model on additional data, swapping inference architecture, expanding the input data sources, or updating clinical reference labels. Generic language ("we will improve the model from time to time") will not pass review.

Component 2: A modification protocol. The modification protocol describes the data management practices, retraining practices, performance evaluation protocols, and update procedures that the sponsor will follow when applying any modification listed in Component 1. It is the methodological backbone the agency relies on to trust that future modifications will be safe and effective.

Component 3: An impact assessment. The impact assessment justifies why the planned modifications, under the modification protocol, will not adversely affect the safety and effectiveness of the device. It addresses risks specific to AI/ML modifications - performance drift, biased retraining data, model overfitting, label noise, and the human-AI interaction risks that can emerge when the model evolves.

For deploying hospitals, the PCCP matters operationally because it determines what change to a vendor's AI tool counts as an in-PCCP update (continued use under the existing clearance) and what counts as out-of-PCCP (clearance gap until a new submission clears). Hospitals running their own pre-deployment validation should map every vendor's PCCP to their internal change-management policy. The Areebi audit log records the vendor model version per interaction so that a hospital can prove which PCCP-covered version was in use at any clinical event.

The June 2023 final FDA guidance on premarket software functions sets the minimum documentation any AI/ML device submission needs. The agency now distinguishes "Basic Documentation Level" from "Enhanced Documentation Level" based on a risk-based assessment.

For AI/ML-enabled functions, the Enhanced Documentation Level is the practical default. It requires: a software description (purpose, architecture, environment); risk management documentation (hazard analysis, hazard mitigations); software requirement specifications; software design specifications; software development environment information; software development lifecycle; software testing documentation including unit, integration, system, and regression tests; cybersecurity controls; and traceability across requirements, risks, and tests.

For AI/ML systems specifically, the Enhanced Documentation Level expands into: training data lineage and provenance; data preparation and labelling protocols; model selection rationale; bias and fairness assessment; performance metrics across the intended-use population and key subpopulations; verification and validation evidence; and post-market performance monitoring plan. The AI Bill of Materials playbook describes the lineage capture techniques the FDA increasingly expects to see.

HHS Section 1557 of the Affordable Care Act, as updated by the May 2024 final rule, treats AI-based patient care decision support tools as a category that covered entities must actively monitor for discrimination on protected grounds. The rule defines "patient care decision support tools" broadly to include both AI/ML-enabled tools and rule-based clinical algorithms.

The substantive obligations on a covered entity using such a tool are: identify the use of the tool; make reasonable efforts to identify uses that employ inputs measuring race, colour, national origin, sex, age, or disability that could result in discrimination; mitigate identified discrimination risks; train staff on appropriate use; and document the activities above. The rule is enforceable by HHS Office for Civil Rights (OCR) and through private rights of action.

Operationally, this means a covered entity deploying an AI clinical decision support tool has an obligation independent of, and additive to, FDA clearance. A device that has cleared FDA review is not exempt from Section 1557; the deploying covered entity must still demonstrate that, in its specific deployment, the tool does not produce disparate impact on protected groups. The Areebi platform records demographic-aware audit telemetry so that disparate-impact analysis can be performed on actual deployment data, rather than relying on the vendor's pre-market validation alone.

The 10 GMLP principles, jointly published by FDA, Health Canada, and the UK MHRA in October 2021 with subsequent updates, are the closest thing AI medical device sponsors have to a regulator-blessed code of practice. The principles are non-binding but every authoritative US AI medical device submission since 2022 references them.

The 10 principles are: (1) multi-disciplinary expertise is leveraged through the lifecycle; (2) good software engineering and security practices are implemented; (3) clinical study participants and datasets are representative of the intended patient population; (4) training data sets are independent of test sets; (5) selected reference datasets are based upon best available methods; (6) model design is tailored to available data and reflects the intended use; (7) focus is placed on the performance of the human-AI team; (8) testing demonstrates device performance during clinically relevant conditions; (9) users are provided clear, essential information; (10) deployed models are monitored for performance and re-training risks are managed.

For a deploying hospital, principles 7, 8, 9, and 10 are the most operationally relevant. The human-AI team performance metric, the clinically relevant testing, the information surfaced to users at the point of decision, and the post-deployment monitoring loop are exactly the surfaces the hospital owns even when the vendor cleared the device. See the healthcare AI governance CISO guide for the deployment-side controls.

The cybersecurity expectations for AI/ML-enabled medical devices in 2026 sit at the intersection of the FDA's September 2023 cybersecurity guidance ("Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions") and AAMI/UL 2900-1, the consensus standard for network-connectable medical devices.

AAMI/UL 2900-1 is a baseline standard - structured risk management, vulnerability management, security controls, software composition documentation, and security testing - that maps directly to the FDA's premarket cybersecurity expectations. For AI/ML devices, the additional surfaces a sponsor and deployer must consider include: model serving infrastructure exposure, prompt injection (where the AI device accepts free-text input), adversarial input robustness, training data poisoning risk during retraining cycles inside the PCCP, and the integrity of the model artefact itself across the supply chain.

The Areebi policy engine and audit log were designed to give a clinical CISO the runtime evidence that the AAMI/UL 2900-1 controls are operating at the AI interface, complementing the device-level controls the vendor implements. Our model supply chain security guide covers the deeper threat model.

The checklist below is the one Areebi recommends to hospitals, payers, and integrated delivery networks deploying an AI clinical decision support tool in 2026. It assumes the device is FDA-cleared and the deploying organisation is a Section 1557 covered entity.

Where the deploying organisation is also the developer of the AI clinical decision support tool, the checklist expands to include the full PCCP development cycle, GMLP self-assessment as a developer rather than a deployer, and the post-market surveillance reporting obligations under 21 CFR Part 803.

Pitfall 1: Treating FDA clearance as the end of the governance work. An FDA-cleared device is one whose pre-market evidence the FDA has assessed. It is not a device that the deploying covered entity is exempt from monitoring. Section 1557, internal quality, and HIPAA all impose continuing obligations on the deployer that begin the moment the device touches the clinical workflow.

Pitfall 2: Confusing clinical decision support exemptions with clearance. The 21st Century Cures Act amended the FDCA in Section 520(o) to exclude certain clinical decision support software from the definition of a medical device under specific conditions. The four criteria are narrow - the software must not acquire signals or images, must display only certain types of medical information, must enable the clinician to independently review the basis for the recommendation, and the recommendation must not be used in time-critical decisions. AI clinical decision support tools that surface a recommendation alongside its reasoning may fall inside the exemption; tools that produce diagnostic outputs or operate in time-critical workflows generally do not. A misclassification under this exemption is a frequent pre-deployment finding.

Pitfall 3: Ignoring post-market drift. A model that performed well on the pre-market validation population can deteriorate against an evolving deployment population. The FDA's post-market reporting expectations and Section 1557's disparate-impact obligations both depend on the deploying organisation noticing the drift. Without per-interaction audit telemetry and a quarterly review cadence, drift goes undetected until a clinical incident or a regulatory enquiry surfaces it.

Areebi was built on AnythingLLM specifically for the kind of audit-grade telemetry that healthcare regulators expect. Three platform capabilities map directly to the FDA SaMD and Section 1557 workstreams.

Audit log for PCCP and GMLP principle 10. Every clinical AI interaction is logged with model identifier, model version, policy version, clinician identity, patient cohort metadata (with appropriate access controls), data classes touched, and the response chain. For a PCCP-bounded change or an FDA post-market enquiry, the reconstruction window collapses from days to minutes.

Policy engine for GMLP principles 7, 8, 9. Every clinical AI guardrail - the populations the tool may operate on, the data classes that may flow in, the human oversight checkpoints required - is a versioned policy. The policy engine enforces the guardrails at runtime, and the policy version is recorded with every interaction in the audit log.

Demographic-aware analytics for Section 1557. The Areebi reporting layer supports disparate-impact analysis on actual deployment data, segmented by protected groups under Section 1557, with the privacy and access controls a covered entity requires. The platform overview and our healthcare AI governance CISO guide walk through the integration patterns.

The Areebi AI Governance Assessment includes a healthcare module that scores your current state against the FDA SaMD and Section 1557 expectations and produces a prioritised remediation plan, typically completed inside 30 minutes by a clinical informatics lead or CISO.

We chose to invest disproportionate engineering in the audit-log schema specifically because clinical AI deployments are the place where the evidence stakes are highest. A bad recommendation in a marketing copy assistant is embarrassing; a bad recommendation in a clinical decision support tool can be fatal. The platforms that win in healthcare will be the ones that make demonstrating safety as cheap as deploying the tool itself. That is the bar we hold ourselves to.

The references below are the primary sources cited throughout this post. All URLs were verified at the time of publication.

• FDA AI/ML-enabled medical device hub - the agency's running list and primary policy pages.
• FDA SaMD Action Plan (January 2021) - the five-workstream agenda.
• FDA PCCP guidance (October 2023 final) - the change control plan mechanics.
• FDA Content of Premarket Submissions for Device Software Functions (June 2023 final) - the software documentation baseline.
• HHS Section 1557 final rule (May 2024) - the nondiscrimination obligations for AI clinical decision support.
• FDA/MHRA/Health Canada GMLP 10 principles - the de facto checklist for AI medical device development.
• AAMI/UL 2900-1 - the consensus cybersecurity standard for network-connectable medical devices.

To take this playbook from understanding to operational programme, work through this cluster.

• HIPAA clinical AI PHI playbook - the privacy-side mechanics that interact with FDA clearance.
• Governing GenAI in healthcare operations - the broader operational scope outside the device track.
• Healthcare AI governance CISO guide - the CISO-perspective deployment guide.
• AI incident response runbook - the playbooks for clinical AI failures.
• Model supply chain security - the technical mechanics behind PCCP modifications.