AI in Medical-device Development and Quality Management

Define the task and its authority

AI can assist teams developing and maintaining any medical device, including products with no AI functionality. Useful tasks include finding inconsistent requirements, reviewing changes, analysing test logs, inspecting manufactured parts and identifying patterns in complaints. The starting question is what decision will depend on the output and what happens if it is wrong.

Separate assistance from execution and approval. A tool may draft a test, another system may execute it, and an authorised person may approve the result. Draft text cannot demonstrate that testing occurred. Likewise, a suggested root cause is a hypothesis until investigation supports it. Define the tool’s permitted use and the records needed to show what actually happened.

Not every task needs a language model. Rules may be better for mandatory fields, statistical methods for stable process measures, computer vision for visual inspection and language models for searching or drafting. Compare with the existing process using the same evidence and success criteria. For AI functions in the medical product, see MTL-502 — Applications of AI in Medical Devices.

Requirements, architecture and engineering

A requirements assistant can compare user needs, specifications and interface descriptions, flag ambiguous wording and suggest missing acceptance criteria. Require source references and distinguish direct contradictions from suggestions. For example, “rapid response” needs a justified time limit; AI must not invent that limit and present it as an agreed clinical need.

Architecture review can expose missing states, unclear ownership and inconsistent interface assumptions. Give the tool approved boundaries and versions. Ask what happens when a controller reconnects after a timeout, then compare the proposal with the actual state machine. A convincing explanation is not proof that the implemented system behaves that way.

In mechanical and electronics design, AI can help explore configurations, interpret simulation results and identify potentially sensitive tolerances. Treat suggested geometries, materials and components as candidates. Verify calculations, supplier specifications, physical assumptions, manufacturability and performance using suitable engineering methods. A fast surrogate model is useful only within the domain for which its approximation is justified.

Software assistants can explain legacy code, propose changes and draft tests. Review generated code for correctness, licensing, dependencies and security. Tests generated from the implementation alone may reproduce its misunderstanding. Derive independent acceptance criteria from requirements and risk controls, then verify the released configuration.

Safety, cybersecurity and change impact

AI can challenge a risk analysis by suggesting failure sequences or comparing controls with requirements and tests. It is useful as a second perspective, but cannot establish completeness. Supply the operating context, known hazards, foreseeable misuse and existing controls. Ask for reasons and sources; do not accept invented failure rates or numerical risk estimates.

Cybersecurity applications include dependency review, threat-model support and vulnerability triage. A component match does not prove exploitability, and lack of an obvious match does not prove absence. Evaluate the actual version, configuration, reachable interfaces, privileges and potential safety consequences. Preserve the underlying advisory and the engineering assessment.

Change-impact analysis can propose affected requirements, architecture elements, risks and tests. Every proposed link should identify both ends and explain the relationship. Missing links deserve particular attention: a tool that returns five convincing links may have missed a sixth that matters more. Independent review should examine completeness against the product architecture and controlled change process.

Use MTL-139 — AI Security, Robustness and Adversarial Resilience for security principles and MTL-134 — AI Risk Management and Human Oversight for the relationship between failure, human oversight and harm. These concepts are useful for internal tools, but the assurance scope must follow the internal task rather than copying a medical-AI product plan unchanged.

Testing, evidence and release readiness

AI can draft boundary cases, identify untested fault paths, group log anomalies and compare executed results with acceptance criteria. Give it the test configuration, expected behaviour and record structure. Ensure it can represent incomplete, invalid and inconclusive results without turning them into passes.

Traceability assistance is strongest when the tool can point to an exact requirement, test step and recorded outcome. Keyword similarity is not sufficient evidence of coverage. A test mentioning “battery” may verify an icon while leaving low-voltage behaviour untested. Review whether the test actually challenges the requirement at the right level.

For release preparation, a tool can identify missing approvals, inconsistent versions and unresolved anomalies. It should produce an evidence-gap list with source locations. The designated release authority still applies the release criteria. AI must not fill missing results with reconstructed narratives or infer an approval from an email that only discusses a draft.

Retain raw records and distinguish transformation from interpretation. If logs are filtered before analysis, document what was removed and why. A summary should allow a reviewer to return to the original event, timestamp and configuration.

Suppliers, manufacturing and servicing

Supplier-quality tools can compare specifications, flag changed materials and identify recurring nonconformities. Historical supplier scores can be misleading when exposure, part criticality or reporting practices differ. Assess the actual supplied item, process and evidence, rather than letting a ranking silently determine acceptance.

Computer vision may inspect assembly, labelling or surface defects. Evaluate known defects, borderline parts, acceptable variation, lighting, camera position and production speed. False acceptance is especially important when a missed defect can affect safety. Define the treatment of uncertain images and whether independent inspection remains part of the process.

Process analytics can identify drift and help investigate correlations between settings and failures. Correlation supplies a lead, not a verified mechanism. Validate proposed process changes through the established controls; do not allow an optimisation tool to alter critical settings outside approved boundaries.

Service analytics may identify early signs of wear, battery deterioration or calibration problems. Measure warning lead time, missed failures and unnecessary service actions. Consider the consequences of devices with missing telemetry. Maintenance predictions should support a defined action and must not silently extend validated service intervals.

Complaints, CAPA and the quality system

Language models can group differently worded complaints, retrieve similar investigations and draft summaries. Preserve the original narrative, dates, device identity and reported harm. Duplicate detection must avoid merging distinct events. Potentially urgent cases need a timely escalation route, including when the AI service is unavailable.

For corrective and preventive action, AI can propose investigation hypotheses and identify recurrence patterns across complaints, service and production records. Teams must test those hypotheses. A common supplier lot could be a cause, a coincidental association or a consequence of how records were collected. Effectiveness checks need defined measures and enough follow-up to detect recurrence.

QMS assistants can retrieve controlled procedures, compare forms and draft audit questions. Answers should identify document revision and relevant passage. A procedure that exists is not evidence that people followed it. Audit preparation should check completed records, decisions and effectiveness as well as document availability.

Literature screening and regulatory-change monitoring can help prioritise reading. Keep search scope, dates, inclusion decisions and source links. Verify important conclusions against the current primary document. Training support can explain procedures and generate practice scenarios, while competence is assessed through the organisation’s established methods.

Assure the tool for its actual use

The FDA guidance on Computer Software Assurance for Production and Quality Management System Software describes a risk-based approach to establishing confidence in production and QMS automation. Its February 2026 final version supersedes the September 2025 guidance. Apply it within its scope; it is not blanket approval of an AI tool.

The NIST AI Risk Management Framework provides a voluntary structure for managing AI risks. For an internal tool, translate broad principles into a defined task, evaluated performance, assigned ownership and operational controls.

• Intended use: specify users, inputs, output decisions, exclusions and required review. Distinguish advice from automated acceptance.
• Evaluation: use representative examples, known difficult cases and independent reference decisions. Measure missed issues as well as incorrect suggestions.
• Data protection: establish permitted data, access, retention, supplier use and deletion. Protect personal data, intellectual property and confidential records.
• Configuration: identify the model or service version where available, prompts, retrieval sources, rules and integrations used for the evaluated workflow.
• Change control: assess provider updates, prompt changes and revised document collections. Re-evaluate affected functions before continued reliance when necessary.
• Operations: define failure escalation, manual fallback, monitoring, periodic review and suspension criteria. Treat retrieved documents as data, not trusted instructions.

Human review is a control only when reviewers have the time, expertise and source access to detect the relevant error. Reviewing a convincing answer without checking the evidence may simply move the error into an approved record.

Worked example: a requirements review pilot

Fictional team: an engineering group wants AI to flag ambiguous requirements and missing test links. The first pilot is read-only; it cannot alter the controlled baseline or approve coverage. Engineers create an adjudicated reference set containing clear requirements, genuine defects and difficult cases. They keep it separate from prompt development.

In a synthetic evaluation of 120 requirements, the reference review identifies 30 requirements needing correction. The assistant flags 36: 24 are genuine issues and 12 are unsupported findings. It misses six genuine issues. For this defined issue-detection task, recall is 24 / 30 = 80%, while precision is 24 / 36 ≈ 67%. These illustrative values are not suggested acceptance thresholds.

The team examines the six misses rather than celebrating the volume of output. If the tool repeatedly misses interface-state contradictions, it cannot replace that part of engineering review. Reviewers also assess the twelve false findings: correcting a valid requirement to satisfy a mistaken AI suggestion would introduce defects.

The pilot compares total effort, including preparation and review, against the current process. The decision may be to use AI for a supplementary language check while keeping full engineering review. Approval for that limited use does not authorise automatic traceability acceptance or release decisions.

Practice: complaint triage under pressure

A supplier demonstrates an AI complaint classifier with “95% accuracy”. Management proposes automatically closing cases classified as non-reportable. What information is missing, and what initial use would you consider?

Choose a useful first deployment

Choose one frequent, bounded task with accessible source evidence and a measurable baseline. Requirements language review, evidence retrieval and test-log grouping are often practical candidates, provided the required checks remain workable. Avoid a broad “AI quality manager” mandate whose decisions and failure modes cannot be evaluated.

Agree success criteria before the pilot: confirmed useful findings, acceptable missed-issue performance, total review effort, record quality and user behaviour. Run a shadow phase alongside the existing process. Record the go, restrict or stop decision, then monitor performance after introduction. A successful demonstration is the beginning of operational evidence, not the end.

Use MTL-132 — Data Governance for Medical AI for data governance principles, MTL-135 — Verification, Validation and Clinical Evidence for Medical AI for evaluation thinking and MTL-138 — Generative AI and Large Language Models in MedTech for generative-AI limitations. The clinical case in MTL-408 — Medical AI — From Claim to Controlled Use illustrates evidence connections; adapt the reasoning to the internal process rather than treating internal tools as automatically subject to the same product submission pathway.

Source review: 21 September 2026. Scenarios and numerical examples are fictional. Establish applicable obligations for the organisation, task and markets, and retain responsibility within the quality system.