AI in Biomedical Engineering

What is AI in biomedical engineering?

AI in biomedical engineering applies machine learning to the work of creating medical technology: analyzing biosignals and lab data, guiding device design, running inside devices as software functions, and monitoring devices in the field. When a model becomes part of a device's intended use, FDA device rules apply to it.

The field spans two worlds with different rules. Research tools that help engineers explore data or design hardware are judged by scientific rigor and internal review. Software functions that affect diagnosis or treatment are judged by FDA, through the device's marketing submission and its quality system.

Many teams work in both worlds at once. A model may begin as an R&D analysis tool and later become a device feature, and the records kept in the first stage decide how hard the second will be.

Where does AI show up in biomedical work?

AI shows up at four points in a device's life: research, the product itself, manufacturing and the field. Each point has a different owner and a different standard of evidence.

• Research and design: Signal processing for ECG, EEG, EMG and PPG data, simulation surrogates that speed up design studies, and models that screen biomaterials or sensor layouts.
• In the product: Software functions that detect events, estimate a physiological value, classify a waveform or adjust therapy, either on the device or in a connected app or cloud service.
• Manufacturing and quality: Visual inspection on production lines, anomaly detection in test data and models that sort complaints or nonconformance reports.
• Postmarket: Monitoring field performance, detecting drift in input data and flagging complaint patterns that need an investigation.

The first and third groups usually stay outside the device itself, but they still need controls. A design model that steers a safety decision, or a production model that passes or fails units, carries risk that the quality system must cover.

Which AI uses count as device functions?

An AI use counts as a device function when its intended use is to diagnose, treat, mitigate or prevent disease, or to affect the body's structure or function. The model type does not decide it; the claim does.

• Likely a device function: A model that detects arrhythmia from a patch recording and reports it to a clinician.
• Likely a device function: A closed-loop algorithm that adjusts insulin or stimulation settings based on sensor data.
• Depends on the claim: A model that summarizes biosignal trends for a clinician, where FDA's clinical decision support guidance and the signal analysis criterion need careful reading.
• Usually not a device function: An R&D tool that clusters lab results for engineers and never reaches patient care.
• Quality system software: A model used to inspect parts or sort complaints, which is validated as production or quality system software rather than reviewed as a device function.

Settle the classification early with regulatory staff and write it down for each model. Teams that decide late often rebuild data records that a device submission needs.

How does FDA expect AI device changes to be planned?

FDA expects changes to AI-enabled device software to be planned and described before they happen. Its final guidance on predetermined change control plans says a plan should describe the planned device modifications, the methodology to develop, validate and implement them, and an assessment of their impact.

A plan like this lets a manufacturer retrain or update a model within agreed limits without a new submission for each change. It also forces engineering discipline: the retraining data, the acceptance tests and the rollback steps must be written before the first update.

In January 2025 FDA also issued draft guidance on AI-enabled device software functions covering lifecycle management and the contents of marketing submissions. It takes a total product life cycle view of risk, from design through postmarket performance monitoring.

These sit on top of the device quality system. FDA's Quality Management System Regulation, 21 CFR Part 820, now incorporates ISO 13485:2016 by reference, effective 2 February 2026, so AI design controls, data records and change control live inside that system rather than beside it.

How does a model move from data to a released device function?

A model moves through seven steps, each with a record the quality system keeps. Skipping a record early makes a later step harder to defend.

• 1. Intended use: Write the claim, the patient population, the clinical setting and the user, because each later step tests against them.
• 2. Data plan: Define sources, inclusion and exclusion rules, labeling methods and the split between training, tuning and test sets, keeping test data separate from the start.
• 3. Development: Train and tune the model with versioned code, data and settings, so any result can be reproduced.
• 4. Verification: Test the model against requirements on the held-out set, including subgroups by age, sex, skin tone or device type where relevant.
• 5. Integration: Place the model in the device or app, test it with real hardware and signal conditions, and run the software through the team's IEC 62304 based life cycle where one is used.
• 6. Validation: Show that users get the intended result in realistic conditions, with human factors work for any screen or alert the model drives.
• 7. Release and monitoring: Ship with a monitoring plan for input drift and field performance, and a change plan for retraining.

Steps 2 and 7 are linked. The monitoring plan can only spot drift if the team recorded what the training data looked like, so keep summary statistics of every dataset alongside the model.

Should the model run on the device or in the cloud?

Run the model where its output is needed in time and where it can be controlled. A model that drives therapy or a time-critical alarm usually belongs on the device; a model that reviews days of recordings for a clinician can run in the cloud.

• On the device: Works without a connection and responds fast, but is limited by memory, processor and battery, and every update is a firmware release.
• On a phone or gateway: Has more computing power and easier updates, but depends on the patient keeping the app installed, paired and running.
• In the cloud: Allows larger models and central monitoring, but adds network delay, data transfer of patient signals and a dependency on uptime.
• Split design: A small on-device model screens the signal and sends candidate events to a larger cloud model for review, which balances battery use and accuracy.

Whichever placement is chosen, test the model on the exact runtime it will use. Quantizing a model to fit a microcontroller can change its outputs, and those changes need verification like any other.

Records an AI device file needs

• Dataset cards: Source, dates, inclusion rules, labeling method, demographics and known gaps for each dataset.
• Model card: Architecture, inputs, outputs, training settings, performance by subgroup and known limits, kept for each released version.
• Traceability: Links from each requirement to its tests and results, including model performance requirements.
• Risk file: Hazards linked to model errors, such as missed events and false alarms, with their controls.
• Change log: Every retraining or threshold change, the data used, the tests run and who approved it.
• Cybersecurity: For a connected device, the software bill of materials and a plan for postmarket vulnerabilities.

Keep these records in the same system as the rest of the device file, not in a data science notebook. Auditors and reviewers look for them where design records normally live.

Where biomedical AI projects stall

• Test data leakage: Recordings from the same patient appear in training and test sets, and reported accuracy is higher than real performance.
• Narrow data: Training data comes from one site or one device model, and performance falls in a new population.
• Unplanned retraining: A team retrains a released model to fix an issue, then finds the change needs a new submission.
• Notebook-only records: Data choices and results live in personal notebooks and cannot be traced during an audit.
• Hardware mismatch: A model trained on lab-grade signals runs on a cheaper sensor with more noise.
• No field signal: The device ships without telemetry or a way to measure field performance, so drift goes unseen.

Each one is cheaper to prevent than to fix. Patient-level data splits, multi-site data, a change plan, controlled records, testing on production hardware and planned telemetry address them in turn.

How Agnotic can help

AI in a device succeeds when the model, the software around it and the records behind it are built as one system. Agnotic Technologies supports device makers with that work: data pipelines and dataset records, model integration into device and app software, verification tooling, monitoring for field performance, and sustaining engineering for released software.

The client keeps ownership of the intended use, the regulatory strategy and the device file. Agnotic works inside the client's quality system and supplies the design, test and traceability records it requires.

Sources

• FDA: Predetermined Change Control Plan for AI-Enabled Device Software Functions (final guidance)
• FDA: AI-Enabled Device Software Functions, Lifecycle Management and Marketing Submission Recommendations (draft, January 2025)
• eCFR: 21 CFR Part 820, Quality Management System Regulation