Why AI-Enabled Medical Devices Cannot Use a Normal SaaS Release Process

For an ordinary SaaS product, the release unit is usually an application build. Engineers merge code, run automated tests, deploy to a controlled environment, observe technical and business metrics, and roll back when the change behaves badly.

An AI-enabled medical device has a different release unit.

The released product is a controlled configuration containing the model, dataset provenance, preprocessing logic, application code, dependencies, infrastructure, cybersecurity controls, labelling, validation evidence, monitoring thresholds, and recovery plan. A change to any one of these can alter the behaviour, clinical performance, security posture, or authorised state of the device.

This is why adding a quality approval ticket to an existing SaaS pipeline does not create a regulated medical AI delivery process. The underlying process still assumes that code is the product, a passed test suite is sufficient evidence, production monitoring is mainly an operational concern, and rollback is a routine technical action.

Those assumptions break down when software output can influence diagnosis, triage, treatment, or another clinical decision.

The practical goal is not to make every release slow. It is to build a delivery system that produces the right evidence while the product is being built, tested, approved, deployed, monitored, and, when necessary, recovered.

This article explains that delivery problem from an engineering and executive perspective. It is not a regulatory-law summary, and product-specific submission decisions should remain with the responsible quality and regulatory team.

The Problem Is Not Simply That Medical Device Releases Need More Approval

Teams sometimes frame the difference between SaaS and medical-device delivery as a difference in approval speed. The SaaS team deploys frequently, while the medical-device team adds reviews and therefore deploys more slowly.

That explanation misses the engineering issue.

The real difference is that a medical-device organisation must maintain objective evidence connecting the intended use of the device to its requirements, risk controls, implementation, verification, validation, released configuration, and postmarket behaviour. The organisation also needs to determine whether a proposed change is already covered by an authorised change mechanism or requires a separate regulatory assessment.

A conventional SaaS pipeline can confirm that a service compiled, passed tests, met a security policy, and deployed successfully. It does not automatically establish that:

• The model remains suitable for the intended patient population and clinical use.
• The training and evaluation data remain representative and sufficiently independent.
• The preprocessing path used during validation matches the path running in production.
• The selected decision threshold and calibration remain appropriate.
• The application presents model output to the user in the validated manner.
• The deployment infrastructure preserves the timing, availability, security, and data-handling assumptions used during validation.
• The change is within an authorised PCCP or another acceptable regulatory pathway.
• The monitoring system can detect clinically relevant degradation after deployment.
• The recovery procedure can restore a known and approved product configuration.

These are product questions, not merely deployment questions.

Why the Normal SaaS Release Unit Breaks Down

A model can change behaviour without an application-code change

A team can keep the API contract, user interface, container image, and application source unchanged while replacing a model artefact. The software deploy may look technically identical, but sensitivity, specificity, calibration, subgroup performance, confidence behaviour, and failure modes may all change.

Even a retraining run using the same architecture can produce a materially different device behaviour because the data, sampling rules, labels, random seeds, optimisation settings, thresholds, or post-processing changed.

A release system that treats the model as an interchangeable file cannot explain the resulting product change.

Data is part of the device development record

In ordinary application development, production data is usually an input to the software. In machine learning development, data also shapes the software behaviour.

A medical AI release therefore needs more than a pointer to a storage bucket. The organisation needs to identify the dataset versions, acquisition sources, inclusion and exclusion criteria, labelling methods, transformations, deduplication rules, quality checks, known limitations, and the relationship among training, tuning, validation, and independent test sets.

Without that lineage, the team cannot reliably reproduce the model or explain why a new model performed differently. It also becomes difficult to determine whether a later dataset introduced leakage, shifted the evaluated population, or weakened independence between development and testing.

Infrastructure can affect clinically relevant behaviour

Infrastructure is often treated as interchangeable plumbing. That is risky for a clinical AI system.

A change to an inference runtime, accelerator, numerical library, image codec, feature store, database schema, message queue, network timeout, memory limit, or concurrency setting can affect output precision, latency, ordering, missing-data behaviour, or availability.

Consider an imaging device that was validated with one image-normalisation library and deployed with another. The model file has not changed, but the input presented to the model may have changed. Similar problems occur when a feature pipeline applies a revised unit conversion, a dependency handles missing values differently, or an infrastructure limit causes requests to time out and retry in a different order.

The infrastructure configuration used for validation must therefore be connected to the configuration released into use.

The user interface is part of the clinical behaviour

Clinical performance is not only a model metric. The way output is presented can change how a user interprets or acts on it.

A probability score, category label, colour, ranking, warning, explanation, or default filter can affect clinical workflow. A model can remain unchanged while a user-interface modification changes reliance, response time, or the likelihood that a result is overlooked.

This is one reason device validation must consider the complete product and its intended use, not only the statistical performance of an isolated model.

Cybersecurity changes can alter the validated configuration

Medical-device teams must patch vulnerable dependencies and infrastructure. They must also understand what the patch changes.

A security update may replace a library used for image decoding, authentication, data transfer, encryption, logging, or model execution. The vulnerability may be resolved, but the altered component still needs an impact assessment and proportionate verification.

Conversely, refusing to patch because a component belongs to a validated configuration creates a different patient and operational risk. The answer is not to freeze the system. The answer is to create a secure update process that preserves traceability and defines what must be retested for each class of change.

This is where medical-device quality controls and DevSecOps controls for build and release pipelines need to operate as one process.

The Root Cause: Evidence Is Split Across Teams and Tools

Most delivery failures in regulated AI are not caused by a complete absence of documentation. They occur because each team has a partial record.

• Data scientists track experiments in notebooks and an experiment platform.
• Software engineers track source changes and application builds in Git and CI.
• Platform engineers track infrastructure in Terraform, Helm, cloud consoles, and cluster configuration.
• Security teams track vulnerabilities and threat findings in separate scanning and ticketing systems.
• Quality teams track requirements, risks, reviews, and approvals in an electronic quality management system.
• Regulatory teams track submission commitments, PCCP boundaries, and labelling decisions in controlled documents.
• Operations teams track deployments, incidents, and monitoring changes in production systems.

Every team may be doing useful work, yet no system can reconstruct the released device as one controlled configuration.

This fragmentation creates predictable problems:

• Quality review starts after the technical work is complete.
• Engineers manually collect screenshots and test reports for each release.
• Reviewers cannot tell which failed tests were rerun or which artefacts were replaced.
• A model version can be linked to a training run but not to the deployed preprocessing service.
• An infrastructure change can reach production without a device-level impact assessment.
• A monitoring alert can identify degradation but not the dataset, model, application, and infrastructure combination involved.
• A rollback can restore a container while leaving a changed feature pipeline or database schema in place.

The solution is not one enormous tool. It is a controlled identity and evidence model that connects the tools already used by each discipline.

The Regulated Release Unit

A useful way to redesign the process is to define a medical AI release as an immutable manifest.

The manifest identifies every artefact and decision required to reproduce, assess, approve, deploy, and monitor the product configuration. It becomes the common reference used by engineering, clinical, quality, regulatory, security, and operations.

Model identity

The release should identify the exact model artefact, architecture, parameters, framework, runtime, decision thresholds, calibration configuration, feature definitions, preprocessing, and post-processing logic.

A friendly model name such as lesion-detector-v7 is not sufficient. The record should include an immutable artefact digest and the training-run identity that produced it.

Dataset identity and lineage

The release should identify the data snapshots and transformation code used for training, tuning, validation, and independent testing. It should preserve the population definition, labelling approach, exclusions, quality controls, known limitations, and independence controls.

The organisation should be able to move backwards from a production model to the data and code that produced it, and forwards from a source dataset to every model and evaluation that used it.

Application and dependency identity

The manifest should identify source revisions, compiled artefacts, containers, third-party components, external services, configuration, API contracts, database migrations, and the SBOM associated with the release.

Traceability is needed at the binary level because the source repository alone does not prove which dependency resolution or build output reached production.

Infrastructure identity

The record should identify infrastructure code, deployment templates, runtime versions, compute class, accelerator, operating-system image, network and identity policies, storage configuration, feature services, secrets policy, and relevant managed-service versions.

Manual production changes should either be prohibited or captured through a controlled process that updates the release state.

Product and regulatory identity

The release should link to intended use, relevant requirements, hazards, risk controls, validation protocols, acceptance criteria, labelling, regulatory commitments, and the applicable change pathway.

For a PCCP-controlled change, it should identify the planned modification and the authorised method used to develop, validate, implement, communicate, and monitor that modification.

Operational identity

The release should also identify deployment strategy, monitoring configuration, baseline performance, alert thresholds, escalation ownership, user communication, recovery configuration, and the period of heightened observation after release.

This connection is what allows release observability and post-deployment monitoring to support quality decisions rather than remain a separate operations dashboard.

Model Validation Is Not a Metric Check

Machine learning teams often use the term validation for the dataset used during model selection or hyperparameter tuning. Medical-device validation has a broader meaning.

The relevant question is whether objective evidence demonstrates that the finished device fulfils the requirements associated with its intended use.

That assessment can include:

• The evaluation dataset represents the intended patient population, use environment, equipment, acquisition conditions, and clinically relevant subgroups.
• The independent test data was not used to make development decisions that weakened its independence.
• The reference standard and labelling process are suitable for the intended clinical claim.
• The selected metrics and acceptance criteria reflect the clinical risk rather than only aggregate model performance.
• The model, preprocessing, post-processing, application, user interface, and deployment environment are tested together.
• The device behaves safely when data is missing, corrupted, outside expected limits, or unsuitable for analysis.
• The human user receives enough information to interpret, question, or disregard the output where appropriate.
• The cybersecurity and availability controls support the intended use environment.
• The monitoring and recovery processes are ready before the change reaches users.

This does not mean every update needs a full clinical study. It means the extent of evidence should follow the change, risk, device claims, authorised change pathway, and applicable requirements.

A well-designed regulated MLOps delivery system makes that evidence repeatable. It does not replace clinical, quality, or regulatory judgement.

PCCPs Change the Release Process, but They Do Not Remove Control

A Predetermined Change Control Plan can provide an authorised route for specified future modifications to an AI-enabled device. It is valuable because it allows the manufacturer to define certain changes and the methods used to develop, validate, implement, and assess them in advance.

It should not be interpreted as advance approval for any future retraining or model improvement.

A release team still needs to establish that:

• The proposed modification matches a modification described by the authorised PCCP.
• The approved data-management and retraining methods were followed.
• The required performance-evaluation methods were executed.
• Every acceptance criterion was met.
• The implementation and update procedures were followed.
• The impact assessment remains valid for the actual change.
• The required labelling, transparency, communication, and monitoring actions are complete.
• The evidence is traceable to the exact configuration proposed for release.

A change that fails an acceptance criterion should not move forward merely because it has an engineering approval or appears to improve an aggregate metric.

The delivery platform should therefore encode PCCP scope as release policy. It should be able to block a release when the modification type, data source, evaluation method, threshold, subgroup result, or implementation procedure falls outside the approved boundary.

The final regulatory decision should remain visible and attributable to the responsible function. It should not be hidden inside a generic green pipeline status.

Cybersecurity Evidence Belongs in the Same Release Record

Cybersecurity cannot operate as a scan performed after model and device validation.

An AI-enabled medical device can be affected by ordinary software vulnerabilities and by AI-specific threats such as training-data poisoning, model theft, adversarial input, sensitive-data leakage, model bias, and drift.

The release evidence should connect:

• The threat model to the current architecture and use environment.
• Cybersecurity risks to design controls and verification evidence.
• The SBOM to the binaries and services in the release.
• Known vulnerabilities to exploitability, compensating controls, remediation decisions, and support status.
• Penetration and security test results to the configuration that was tested.
• Patch and update procedures to the device change-control process.
• Recovery capabilities to a trusted configuration that the organisation can verify.

A security patch still needs proportionate regression testing. A model update still needs a cybersecurity assessment. An infrastructure change still needs to be checked against the threat model.

These are not three parallel release processes. They are three views of one product change.

What the Release Evidence Pack Should Contain

The evidence pack should be assembled automatically where practical, but its contents should remain understandable to a reviewer. It is not enough to archive thousands of logs without showing why the evidence supports the release decision.

A practical evidence pack commonly includes:

• The change record explains what changed, why it changed, who owns it, and which products or users may be affected.
• The impact assessment explains the effect on intended use, clinical claims, requirements, hazards, risk controls, labelling, cybersecurity, and postmarket monitoring.
• The change-pathway record identifies whether the change follows an authorised PCCP, another established procedure, or requires further regulatory assessment.
• The release manifest identifies immutable versions and digests for the model, data, code, dependencies, container, configuration, and infrastructure.
• The dataset lineage record identifies sources, cohorts, labels, transformations, exclusions, quality checks, and development-versus-test independence.
• The model evaluation report presents clinically relevant performance, subgroup results, uncertainty, acceptance criteria, and known limitations.
• The system verification and validation evidence covers the integrated product rather than only the model artefact.
• The cybersecurity evidence connects the architecture, threat model, SBOM, vulnerabilities, security tests, risk decisions, and update plan.
• The environment record proves which hardware, runtime, libraries, services, and infrastructure configuration were used during validation.
• The approval record identifies each reviewer, decision, timestamp, exception, and electronic signature where applicable.
• The deployment plan defines rollout stages, verification checks, user communication, monitoring ownership, and stop conditions.
• The recovery plan identifies the trusted configuration, restoration method, data compatibility, validation status, and decision authority.
• The postmarket plan identifies performance indicators, data-quality signals, drift checks, subgroup analysis, alert thresholds, review frequency, and escalation paths.

The evidence pack should be generated from controlled source systems. Manually edited summaries can provide context, but they should not be the only record of what was built and tested.

A Practical Regulated MLOps Release Process

1. Classify the change before implementation

Every change should enter through a common intake process. The initial assessment should identify whether the proposal affects the model, data, intended population, clinical workflow, software, infrastructure, cybersecurity, labelling, or monitoring.

Early classification prevents teams from completing development before discovering that the change needs different evidence or a different regulatory pathway.

2. Create a release identity at the start

The release identifier should exist before testing begins. Model runs, datasets, builds, infrastructure plans, test executions, review records, and deployment events should attach to that identity.

This avoids the common practice of constructing the release history retrospectively from timestamps and screenshots.

3. Build reproducibly

The organisation should control the training environment, source revision, dependencies, parameters, random seeds where relevant, data snapshot, and model packaging process.

Reproducibility does not always mean producing bit-for-bit identical training output. It means the organisation can reconstruct the development process, explain expected variation, and show which exact artefact was selected and released.

4. Test the complete configuration

Model evaluation, software verification, integration testing, cybersecurity testing, infrastructure validation, and workflow assessment should converge on the same proposed release manifest.

When a material artefact changes after testing, the pipeline should invalidate the affected evidence. A reviewer should not unknowingly approve model results from one configuration and system results from another.

5. Evaluate against explicit acceptance criteria

Acceptance criteria should be defined before the final evaluation. They should address clinically relevant performance, subgroups, safety controls, software behaviour, security, operational readiness, and any applicable PCCP conditions.

Exceptions need documented ownership and a clear decision pathway. A release system should not convert every warning into an informal approval request.

6. Assemble and review the release evidence

The pipeline should collect immutable artefacts and generate a readable release summary. Quality, regulatory, clinical, engineering, security, and operations reviewers should see the evidence relevant to their responsibilities without losing the common release identity.

The approval should record the configuration that was reviewed. Rebuilding or retagging an artefact after approval should create a new release candidate.

7. Deploy progressively with defined stop conditions

Where the product and use environment permit it, deployment can use staged release, limited sites, defined user groups, shadow evaluation, or controlled activation.

The rollout design should reflect clinical and regulatory constraints. A consumer-style experiment that exposes patients to unapproved behaviour is not an acceptable substitute for validation.

Before deployment, the team should define which signals stop the rollout, who makes that decision, how users are informed, and which trusted configuration will be restored.

8. Verify the deployed state

A successful deployment command does not prove that the intended device configuration is running.

The release process should verify model digest, application version, configuration, feature schema, dependency and runtime state, infrastructure version, monitoring activation, and connectivity to required services. The deployment record should link these observations to the approved manifest.

9. Monitor clinical and technical behaviour

Monitoring should cover more than CPU, memory, errors, and latency. Depending on the device, it may include input-data quality, missingness, population changes, output distribution, calibration, subgroup performance, user overrides, workflow changes, safety signals, cybersecurity events, and the continued suitability of external dependencies.

Some clinical outcomes arrive slowly or incompletely. Monitoring design must account for delayed labels, biased feedback, site differences, and changes in how clinicians use the product.

10. Feed postmarket findings back into change control

Monitoring should trigger defined actions rather than only dashboard review.

An action may include investigation, increased observation, user communication, configuration mitigation, model suspension, rollback, corrective action, cybersecurity response, regulatory assessment, or a new development cycle.

The evidence from those actions should attach to the affected release so that the organisation retains a continuous product history.

Postmarket Monitoring Is Part of Release Readiness

A medical AI team should not postpone monitoring design until the model reaches production. The ability to detect and investigate degradation is part of deciding whether the release is ready.

The monitoring plan should answer five operational questions.

What can change after release?

The patient population, clinical practice, imaging equipment, data interfaces, prevalence, user behaviour, upstream software, input quality, attack surface, or external infrastructure can change even when the model remains untouched.

Which signals can detect the change?

Teams may need a combination of direct performance measures, delayed outcome measures, proxy indicators, data-quality checks, distribution analysis, user feedback, complaints, incident reports, and cybersecurity monitoring.

What threshold triggers investigation?

A statistically detectable difference is not automatically a clinically meaningful problem. Conversely, a sparse but serious safety signal may require action before a conventional performance threshold is crossed.

Thresholds should reflect risk, evidence availability, baseline variability, subgroup impact, and the consequences of delayed action.

Who owns the decision?

Operations can identify an alert, but it may not be authorised to suspend a device, communicate with users, initiate a correction, or determine regulatory reporting. The escalation model should identify clinical, engineering, security, quality, regulatory, and executive decision owners.

What happens after the alert?

The process should define investigation steps, evidence preservation, affected-release identification, user communication, mitigation, rollback, corrective action, and reporting assessment.

A dashboard without an action model provides visibility but not control.

Rollback Is a Controlled Product Change

SaaS teams often describe rollback as redeploying the previous container. That may be inadequate for a clinical AI system.

A safe recovery unit can include:

• The previous model artefact and its decision thresholds.
• The compatible preprocessing and post-processing implementation.
• The application and user-interface behaviour validated with that model.
• The feature schema, database state, and external interface version.
• The runtime, dependencies, infrastructure, and cybersecurity configuration.
• The labelling and user information associated with the restored device version.
• The monitoring configuration and baseline appropriate to the restored release.

The organisation should test recovery before it is needed. That test should cover artefact availability, access controls, data compatibility, database migration reversal or forward compatibility, configuration restoration, deployment verification, monitoring activation, and communication responsibilities.

Rollback also does not erase the event that triggered it. The team should preserve evidence from the affected release, determine which users or patients may have been exposed, continue monitoring, investigate root cause, and assess whether correction, removal, adverse-event reporting, or other action is required.

The aim is not an instant technical reversal at any cost. The aim is controlled restoration of a known state while the organisation manages the safety and regulatory consequences of the event.

Medical AI Delivery-Readiness Checklist

Executives can use the following questions to determine whether the current delivery process is ready for repeated regulated AI releases.

• The organisation can identify one immutable release record covering the model, data, application, dependencies, configuration, infrastructure, security controls, and monitoring configuration.
• The organisation can reproduce the data transformations and training process used to create every released model.
• The organisation can demonstrate that independent test data remained protected from model-selection decisions.
• The organisation can trace intended-use requirements and risk controls to system-level verification and validation evidence.
• The organisation can determine before development whether a proposed change is inside an authorised PCCP or needs another regulatory assessment.
• The delivery pipeline enforces the authorised development, validation, implementation, and acceptance methods for PCCP-covered changes.
• The organisation can invalidate affected evidence automatically when a model, dataset, dependency, configuration, or infrastructure artefact changes.
• The SBOM and cybersecurity assessment correspond to the exact binaries and services proposed for release.
• The approved release manifest can be compared automatically with the configuration actually deployed.
• The monitoring plan includes clinically relevant performance, data-quality, subgroup, workflow, reliability, and cybersecurity signals.
• Every monitoring alert has an owner, investigation path, decision authority, and defined action options.
• The organisation can restore and verify a complete trusted configuration rather than only a previous application container.
• The rollback process includes evidence preservation, affected-user assessment, communication, quality review, and reporting assessment.
• The quality and regulatory teams can review pipeline-generated evidence without manually reconstructing the technical history.
• The engineering team understands which changes require new evidence and does not treat quality review as an unpredictable final gate.

A large number of negative answers usually indicates an operating-model problem rather than a missing MLOps product. Tool selection should follow the definition of the controlled release process.

Trade-Offs and Implementation Constraints

More traceability creates more integration work

Connecting experiment tracking, source control, CI, artefact repositories, infrastructure code, security systems, requirements, risk records, electronic approvals, deployment platforms, and observability is not a small configuration task.

The organisation needs a common identity model, controlled metadata, retention rules, access controls, interfaces, and ownership. Some evidence can be generated automatically. Clinical rationale and regulatory decisions still require qualified human judgement.

Immutability can conflict with existing data practices

Large datasets are expensive to copy and retain. Source data may also be subject to privacy, contractual, residency, or retention constraints.

Dataset versioning therefore needs a deliberate architecture. It may use immutable manifests, content hashes, governed snapshots, transformation versions, lineage metadata, and controlled references rather than uncontrolled duplication.

Perfect reproducibility may not be technically possible

Some training processes are nondeterministic because of hardware, parallel execution, framework behaviour, or stochastic algorithms. The organisation should define the required reproducibility level, control known sources of variation, retain the selected artefact, and document residual variability.

Claiming bit-for-bit reproducibility when the process cannot provide it is less useful than a clear and tested reconstruction strategy.

Continuous deployment may not suit every device

Continuous integration and continuous evidence generation remain valuable. Continuous production deployment may be inappropriate for some devices, sites, or change types.

A mature process separates the ability to produce a release candidate quickly from the authority to activate it. Deployment frequency should follow product risk, evidence, user environment, regulatory status, and operational readiness rather than a generic SaaS maturity target.

Legacy products create migration friction

Existing devices may lack immutable builds, dataset lineage, infrastructure code, structured requirements, or reliable production telemetry. Reconstructing every historical decision may be unrealistic.

A practical migration usually establishes a controlled baseline, records known gaps, prioritises high-risk interfaces and changes, and applies the new evidence model prospectively. Broader remediation can then proceed through the quality system.

Organisational boundaries are often harder than tool changes

Data science may optimise for experimentation speed. Platform engineering may optimise for reliability. Quality may optimise for controlled evidence. Regulatory may optimise for submission consistency. Clinical teams may optimise for patient safety and workflow suitability.

The release process must make these responsibilities explicit. A shared platform cannot compensate for unclear decision rights or unresolved ownership.

Frequently Asked Questions

Can an AI-enabled medical device use CI/CD?

Yes. CI/CD can support an AI-enabled medical device, but the pipeline must operate as a controlled evidence-generating system rather than an automatic route from a passed build to production. It should identify the complete release configuration, run the required validation and cybersecurity checks, enforce approval boundaries, preserve immutable evidence, and verify deployment. Automation remains valuable. The difference is that successful technical tests do not, by themselves, establish that a device change is authorised or safe to release.

Does every medical AI model update require a new FDA submission?

Not necessarily. The answer depends on the authorised device, the nature and effect of the modification, applicable FDA policies, and whether the change is covered by an authorised Predetermined Change Control Plan. A PCCP is not blanket permission to change a model. The modification must remain within the described scope, follow the authorised modification protocol, meet its acceptance criteria, and produce the required evidence. Changes outside those boundaries require a separate regulatory assessment and may require a new marketing submission.

Is model validation the same as testing against a validation dataset?

No. In machine learning, a validation dataset is commonly used during model development or tuning. Medical-device validation is broader. It requires objective evidence that the finished device satisfies requirements associated with its intended use. That assessment can include independent test data, subgroup performance, software integration, clinical workflow, human factors, cybersecurity controls, deployment configuration, failure behaviour, and monitoring readiness. A strong offline model result is useful evidence, but it does not validate the complete medical device.

What should a regulated medical AI release record contain?

The release record should identify the model, training and evaluation data lineage, source and binary versions, dependencies, application configuration, infrastructure configuration, security findings, SBOM, requirements, risk controls, validation results, approval decisions, deployment method, labelling impact, monitoring thresholds, and recovery plan. It should also show which PCCP or other change pathway applies. The exact contents depend on the device, but the record must allow the organisation to reconstruct what changed, why it was accepted, and exactly what reached users.

How should rollback work for a clinical AI release?

Rollback should restore a known, tested and approved product configuration rather than replacing only the model file. The recovery unit may include the model, preprocessing logic, application, dependencies, feature definitions, infrastructure, security configuration and user-facing information. The organisation should retain the failed release evidence, verify the restored configuration, continue monitoring, assess affected patients or users, and involve quality and regulatory personnel. Depending on the risk and circumstances, the action may also require correction, removal or adverse-event reporting assessment.

Conclusion

An AI-enabled medical device cannot be released safely through a process that sees only application code.

The product behaviour emerges from the relationship among data, model, preprocessing, application, user interface, dependencies, infrastructure, cybersecurity controls, and clinical workflow. The release decision also depends on intended use, risk controls, validation evidence, regulatory status, monitoring readiness, and the ability to recover a trusted configuration.

This does not require abandoning CI/CD or slowing every change through a manual committee. It requires redesigning CI/CD as a controlled evidence system.

The best regulated MLOps processes create evidence during engineering work, classify changes before development, connect PCCP conditions to pipeline policy, validate the complete product configuration, verify what reached production, and turn postmarket signals into controlled action.

That approach gives engineering teams clearer release boundaries and gives quality and regulatory teams evidence they can trust. It also gives executives a more honest view of delivery readiness than deployment frequency alone.

Further Reading

• FDA: Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions
• FDA: Artificial Intelligence-Enabled Device Software Functions, Lifecycle Management and Marketing Submission Recommendations
• FDA: Cybersecurity in Medical Devices, Quality Management System Considerations and Content of Premarket Submissions
• FDA: Content of Premarket Submissions for Device Software Functions
• FDA: Quality Management System Regulation
• IMDRF: Good Machine Learning Practice for Medical Device Development
• FDA: Mandatory Medical Device Reporting Requirements
• FDA: Recalls, Corrections and Removals
• NIST: Artificial Intelligence Risk Management Framework