Does every AI model used by a medical-device company become a medical device?

No. Intended use and function drive the medical-device analysis. A model that performs or supports a regulated diagnostic or therapeutic function may fall within the device framework. An internal assistant used to draft meeting notes follows the company's security and quality policies according to its actual impact. Inventory both, then record separate regulatory status and rationale. Ask qualified regulatory counsel to resolve borderline functions and changes in claims or deployment context.

What should an AI change request contain?

The request should identify the affected function and proposed version. Include changed dependencies, risk impact, validation plan, regulatory assessment, approvers, deployment method, and monitoring update. If a PCCP applies, identify the planned modification and protocol step. Link the release to test results and deployed configuration. A vendor notice alone cannot show the effect on the device.

Can a PCCP cover continuous model updates?

A PCCP can cover modifications described and controlled within its authorized scope. The final FDA guidance recommends a description of modifications, modification protocol, and impact assessment. The manufacturer still needs to execute the protocol and preserve evidence for each implementation. Updates outside the described range or with an unevaluated combined effect require a fresh regulatory assessment. Marketing language such as continuous learning supplies no substitute for that boundary.

How should post-market monitoring handle a hosted model change?

Record the provider change and affected device functions. Pause use when the approved plan sets that response. Run the defined regression and clinical-performance evaluation, document the impact assessment, and obtain required approval before release. Examine field signals after activation. Contractual notice helps, while route-level version evidence shows what production called.

Can an AI gateway prove FDA or EU MDR compliance?

A request gateway can prove a bounded event for authenticated HTTP traffic: who initiated the request, which context the application supplied, what classification applied, which endpoint was requested, and what outcome followed. FDA and EU MDR compliance also depends on intended-use analysis and quality-system operation. Device validation, clinical evidence, supplier controls, post-market surveillance, and regulatory action remain separate. Gateway evidence supports those processes for traffic it receives and cannot certify the device.

AI Governance for Medical Devices Connects Change Control to Field Evidence

A release board shows model version 4.2 queued, but the field-evidence row is blank. The change may alter a device software function, a hosted clinical assistant, or both. AI governance medical devices teams can defend starts by identifying the function and intended use. Record the regulatory role and patient risk, then name the evidence owner. I would stop a release when the team cannot connect its model change to a named validation record and monitoring plan. A polished chart cannot repair missing control lineage.

TL;DR

Govern each AI function by intended use and patient risk. Record its regulatory status and quality-system owner. Give it an evidence path.
Put model and data changes through a documented impact assessment before release. Apply the same rule to prompts, retrieval, endpoints, and other dependencies.
Connect production monitoring to complaints and incident review. Feed findings into corrective action and approved change controls.
An authenticated HTTP policy point can govern routed LLM calls; embedded inference and device validation remain separate controls. Clinical performance and regulatory submissions do too.

Intended use determines the governance route

A manufacturer may use AI inside a diagnostic device, in service operations, or as an engineering assistant. Those uses need separate records. Intended purpose and claims determine if software performs a medical-device function. Device classification shapes the submission path and evidence depth. An internal quality assistant presents a different risk than image-prioritization software.

Build the inventory at function level. Record the product and software component, intended user, patient population, operating environment, and input source. Add the output use and regulatory status, then name the accountable owner. Include the deployed model plus its hosting route and version. A general vendor approval cannot answer which function was evaluated.

AI governance frameworks provide a shared lifecycle. Medical-device governance adds design history and regulatory submission status. It also links clinical evaluation, complaint handling, and post-market evidence. The inventory should connect those records rather than replace them with another spreadsheet.

FDA lifecycle guidance makes context and evidence specific

The FDA's January 2025 draft guidance for AI-enabled device software functions gives recommendations for marketing submissions and proposes risk-management considerations across the total product lifecycle. FDA labels it draft guidance. It describes current proposed thinking rather than a binding rule, so governance records should preserve that status.

For each device function, connect the intended use to its model description and development data. Link the applicable performance evaluation and human factors work. Add cybersecurity material plus the post-market plan. The exact package depends on the device and pathway. Governance owns the cross-reference and approval state. Qualified teams own the conclusions.

The release rule must cover dependencies outside the manufacturer's repository. A hosted model alias or API behavior can alter performance. Record the endpoint and dependency version where available. For a moving alias, document drift detection and the event that pauses use.

Predetermined change control needs executable boundaries

FDA's final guidance on predetermined change control plans for AI-enabled device software functions recommends that a PCCP include a description of planned modifications, a modification protocol, and an impact assessment. A PCCP offers a planned route for specified changes. It does not turn every future model update into an approved change.

Translate the plan into release controls. The description identifies the permitted modification range. Its protocol defines development and validation activities for implementation. An impact assessment explains the benefits and risks, including how one modification may affect another part of the device. Release evidence should identify the active model version and test results. Keep the approver, deployment time, and applicable PCCP boundary with them.

A model change outside the plan needs regulatory assessment before deployment. So does a combined effect that exceeds the evaluated range. AI data lineage for audit can connect training or evaluation sources to the released artifact. The quality system decides if the change requires a new submission.

Quality systems turn governance into assigned work

The FDA's Quality Management System Regulation final rule became effective on February 2, 2026. It amended 21 CFR Part 820 and incorporated by reference the quality-management requirements of ISO 13485:2016, with additional FDA requirements. AI governance should operate inside that quality system rather than beside it.

Assign an owner for the AI function and connect the record to applicable design and supplier controls. Link production, complaint, and corrective-action processes too. Procurement evidence matters when an external model affects the device. The agreement should address change notice and service versions. It should also cover security events and record access, with support for investigations. Technical monitoring should verify the production route.

My preference is one release packet that a quality engineer can open without hunting across five dashboards. It should show the approved function, risk record, validation result, deployed configuration, and monitoring owner. That packet supports review while each source record remains in its controlled system.

EU MDR adds surveillance and conformity context

For devices placed on the EU market, the official Medical Device Regulation text requires manufacturers to establish a quality management system and keep a post-market surveillance system current. Article 83 requires systematic collection and analysis of device experience throughout the device lifetime, with conclusions used for preventive or corrective actions.

The EU AI Act text adds a separate classification test. Article 6(1) covers an AI safety component, or an AI system that is itself a covered product, when the related product must undergo third-party conformity assessment under listed Union legislation. Annex I includes medical devices and in vitro diagnostic devices. The test depends on those conditions. A manufacturer's administrative assistant is not high-risk merely because a device company uses it.

Map each obligation to the conformity file, quality process, technical control, test, and evidence. MDR surveillance and AI Act records can share source events, while legal conclusions and conformity decisions remain explicit.

Field evidence must connect signals to action

Post-market governance begins with the signals the approved plan says to watch. Depending on the function, those may include performance by intended subgroup, out-of-distribution inputs, overrides, complaints, service interruptions, or a shift in model output after an upstream update. Define the metric and review interval. Name the threshold that triggers investigation and the person authorized to pause the function.

A complaint may identify patient impact, while device telemetry shows the active software version. Model-service metadata and the human disposition complete the useful record. Connect those artifacts through a stable reference under applicable privacy and retention rules.

Feed findings into the existing quality process. Investigation can lead to correction, supplier action, CAPA, regulatory reporting, or a proposed model change. The approved change route then sends the result back into validation and release control. AI governance audit evidence helps sample this operating chain without pretending that a request log proves device safety.

The HTTP control boundary covers routed model calls

A manufacturer-controlled application may send an authenticated HTTPS request to a hosted LLM endpoint for service support, quality-record analysis, or a device-adjacent function. The application can attach the user or agent identity and approved purpose. It can also attach product context and data classification. An inline policy point evaluates that supplied context before forwarding and records the executed rule.

That boundary covers only HTTP model traffic deliberately routed through it. Embedded on-device inference stays inside the device software and its validation controls. Offline analysis, local models, direct browser use, and opaque vendor-managed inference need other controls. IAM owns identity proofing and account lifecycle. The quality system owns design control and CAPA. Regulatory teams determine submission and reporting duties. Clinical owners remain responsible for performance interpretation and patient-facing decisions.

Write the boundary into the system diagram. A narrow arrow labelled authenticated application -> HTTP policy point -> approved model endpoint keeps route evidence separate from the complete device record. AI policy enforcement at the HTTP layer covers that arrow.

DeepInspect

DeepInspect supports manufacturer-controlled applications that route authenticated HTTP requests to LLM endpoints. It operates inline as a stateless proxy. The application supplies the user or agent identity and approved workflow context. DeepInspect evaluates that context with prompt classification, destination, role, and versioned policy before an allowed request reaches the model.

Each routed decision creates a signed, tamper-evident record linking the supplied identity, purpose, content classification, endpoint, policy outcome, and timestamp. On-device inference and offline models remain outside this boundary. DeepInspect also leaves device validation, PCCP execution, quality-system decisions, clinical performance, post-market conclusions, and regulatory submissions with the manufacturer's qualified owners. Book a technical deep dive at deepinspect.ai.