AIaMD: When Clinical AI Becomes a Medical Device
Not every clinical algorithm is a medical device, and not every “AI feature” in a health app is harmless productivity software. The line is intended use: what the software claims for diagnosis, treatment, prevention, or clinical decisions, and how far users are expected to rely on that output. Cross that line and you are in AIaMD territory, with lifecycle, change-control, and post-market duties that ordinary IT releases do not carry.
Intended use is the deciding sentence
Teams often argue about model architecture, AUC charts, or GPU cost while leaving the intended-use statement vague. Regulators and notified bodies start with that sentence. Does the software provide information that drives clinical management? Does it diagnose, triage, or recommend therapy? Is it aimed at clinicians, patients, or both? Are there clear limitations and a requirement for independent clinical judgement?
Two products with the same neural network can land on opposite sides of the regulatory fence because one is labelled as general wellness insight and the other as an aid to detect a specific condition. Marketing copy, onboarding screens, and sales decks count as labelling in practice. If commercial language oversells autonomy (“detects cancer,” “prescribes,” “replaces the specialist”), the quality system must catch up — or the claim must be corrected.
IMDRF’s SaMD key definitions remain a shared reference for software with medical purposes that is not part of a hardware device. AIaMD is SaMD (or software in a device) where AI/ML materially generates or shapes the medical output. Starting from that vocabulary prevents circular debates about whether “our AI is just a feature.”
What changes when AI is inside the device software function
Classical SaMD already demands risk management, clinical evaluation proportionate to risk, cybersecurity, and configuration control. AI adds behaviour that can change with data, fine-tuning, prompt updates, or continuous learning. The engineering question is not only “did version 1.2 pass tests?” but “what space of future versions is still the same device, and what requires a new submission?”
FDA’s final guidance on predetermined change control plans for AI-enabled device software functions, announced in the Federal Register notice of 4 December 2024, crystallises that problem for the US market. A PCCP describes planned modifications to AI-enabled device software functions, the methodology to develop and validate those modifications, and an assessment of their impact — reviewed as part of the marketing submission so that listed changes can proceed without a fresh filing for each step. Even outside the US, the pattern is instructive: define the authorised change envelope before you need it.
Rule: If you cannot state the intended use in one precise paragraph and list which AI behaviours are frozen versus which may change under a controlled plan, you are not ready to call the product AIaMD-compliant — you are ready to argue with yourself.
Clinical decision support versus AIaMD
Organisations often hope to stay in “clinical decision support” territory to avoid device regulation. That hope is only valid when the product’s function and labelling truly stay on the non-device side of local law. Hiding a diagnostic claim behind a disclaimer footer is not a strategy. A safer approach is an honest classification workshop with clinical, regulatory, and engineering leads:
- What decision does the output influence?
- How time-critical and reversible is that decision?
- What information must the user still obtain independently?
- What happens if the model is wrong in the dangerous direction?
Document the answers, then design the UI and the quality system to match. If the product is AIaMD, fund IEC 62304-aligned software lifecycle processes, clinical evaluation, and post-market performance monitoring. If it is not, still apply software quality discipline — health IT that misleads clinicians can harm patients even when it is not a device.
Data, drift, and post-market reality
AI systems fail differently from rule engines. Performance can drift when the population shifts, when scanners change, when coding practices evolve, or when users adapt their behaviour to the tool. AIaMD programmes need monitoring metrics tied to clinical risk, not only infrastructure uptime. Define who reviews false-negative trends, how complaints route into CAPA, and when a model update is mandatory rather than optional.
Training, tuning, and test data governance belong in the same file as the model card. Provenance, consent and lawful basis, bias checks proportionate to risk, and separation between development and release evaluation sets are not academic extras; they are how you defend safety when an incident review begins.
Practical build implications
| Topic | Non-device CDS habit | AIaMD habit |
|---|---|---|
| Intended use | Often informal | Controlled labelling artefact |
| Model update | Ship when ready | Impact analysis / PCCP-style envelope |
| Evidence | Internal KPI slides | Clinical evaluation + risk file links |
| Monitoring | App analytics | Performance + complaint + CAPA loop |
Delivery teams that already practise strong SaMD and AIaMD development treat the model as a software item under configuration management. Broader healthcare software development skills still apply — audit trails, access control, integration contracts — but they are not a substitute for device-grade change control when intended use demands it.
Human factors and over-reliance
Even a well-validated model can harm if the interface nudges users to accept outputs without adequate context. AIaMD design should surface uncertainty, contraindications, and the information the clinician must still verify. Quiet automation that “just works” in demos often fails in noisy wards. Usability validation proportionate to risk is part of the safety case, not a cosmetic UX sprint after engineering freeze.
A working sequence for product leaders
First, freeze a draft intended-use and indications statement with clinical owners. Second, map features to that statement and delete or relabel anything that overclaims. Third, decide the regulatory path and the change envelope (including whether a PCCP-like plan is in scope for your markets). Fourth, instrument post-market metrics before launch, not after the first complaint. Fifth, train commercial teams so the sold story matches the cleared or certified story.
Skipping the first step is how programmes spend a year optimising a model for a claim they cannot legally make — or worse, making it in the market without the quality system behind it.
Soft next step
If you are unsure whether a clinical AI roadmap has crossed into AIaMD, run a short intended-use and change-control review before the next model release. Yoctobe’s SaMD / AIaMD development practice and adjacent healthcare software development work are built for that conversation: clear claims, controlled learning systems, and evidence that can travel with the product.
