Quantising a validated model from FP32 to INT8, or recompiling it for a new accelerator, needs a new submission when a risk-based assessment finds the change could significantly affect safety or effectiveness. The FDA’s test for a software change to a cleared device is exactly that question, and the agency expects manufacturers to answer it through a risk-based assessment, not from the name of the change. The name of the change therefore does not decide its status. What feeds that assessment is equivalence evidence measured on every target the model will run on.
The practical route to the hardware depends on that same evidence and on how much risk the organisation carries: which toolchain to use, whether to build the skills or buy them, and what to do when a device can never be updated after release.
Does an FP32-to-INT8 swap count as a significant change under our quality system?
The swap counts as significant when a risk-based assessment concludes that it could significantly affect safety or effectiveness. The engineering change alone does not settle it.
TechnoLynx, through its AI Governance and Trust work, starts by reproducing the INT8 requalification on your target hardware, covering the accuracy, calibration and latency-under-SLA comparisons an equivalence dossier needs, then maps the measured deltas and test protocols to your significance criteria and gives your regulatory and quality team the technical rationale while they negotiate the reduced package. LynxBenchAI measures latency and throughput on the target hardware itself.
How the regulators frame the test
Under the FDA’s software-change guidance, a change triggers a new 510(k) when it could significantly affect safety or effectiveness, and the guidance counts a positive effect as well as a negative one. Switching compilers or changing drivers and libraries is classed as an infrastructure change, and software changes made to support a new hardware platform are classed as architecture changes. In both cases the extent and impact of the change decide whether a submission is needed. An INT8 engine built by a vendor compiler for a new accelerator involves both a compiler change and a new hardware platform. Response time and throughput are listed among the performance specifications the guidance asks you to consider, so even the latency gain you quantised for has to be assessed.
Testing confirms the assessment but cannot overrule it. If routine verification and validation turn up unexpected results, the guidance says to revisit the decision. If the risk-based assessment concludes the change could significantly affect safety or effectiveness, a submission is required even when every test passes. Whether or not a submission is needed, the quality system still requires the change to be reviewed, approved and documented. The FDA’s General Principles of Software Validation adds that after any change, however small, the validation status has to be re-established through an impact analysis and regression testing sized to that analysis. Since 2 February 2026 the US quality system has been the QMSR, which incorporates ISO 13485:2016 by reference and explicitly requires risk management.
In the EU, MDCG 2020-3 Rev.1 covers changes to devices on AIMDD/MDD certificates during the MDR transitional period. Its reasoning is still the clearest statement of the test: a significant change needs two cumulative elements, a change to design or intended purpose and a finding that the change is significant. A design change that leaves the control mechanism, operating principle, energy source and alarm systems unchanged, and does not harm safety, performance, usability or the benefit-risk ratio, is treated as non-significant. Health Canada’s guidance for Class III and IV devices likewise requires every change to be documented in the quality management system, and changes judged non-significant are reported at annual renewal with a short rationale for each.
Across these frameworks, the manufacturer has to show with evidence, case by case, why a change is or is not significant. Definitions and thresholds differ between jurisdictions and device classes, so your regulatory affairs function has to read the rules that apply to your product and market.
Can the reduced package be agreed in advance?
At the regulator level, yes, through a predetermined change control plan (PCCP). Its modification protocol sets out verification and validation activities with pre-defined acceptance criteria. A modification consistent with an authorised PCCP needs no new marketing submission and is documented in the quality system. A modification that falls outside the plan has to be evaluated separately. The PCCP is authorised as part of the device’s marketing authorisation, together with each modification it specifies.
Internally, we would apply the same logic at smaller scale. Regulatory and quality sign off on the reduced package before anyone relies on it, not after the INT8 build is already in the field. We would tie each piece of evidence to a named significance criterion and date the sign-off before deployment.
What an auditor needs to trace
The FDA lists the documentation it expects for validated software: defined user requirements, the validation protocol, acceptance criteria, test cases and results, and a summary confirming the software is validated for its intended use. How those decisions are documented is something the manufacturer establishes in its own quality system. Auditors look at changes so closely for a reason. In the FDA’s analysis of recalls between 1992 and 1998, 192 of the 242 software-related recalls (79%) came from defects introduced by changes made after initial production and distribution.
How much equivalence evidence does Regulatory/Quality need before INT8 counts as a deployment change?
No external rule fixes that threshold. Each organisation’s Regulatory/Quality function sets it in its own policy, and the right step is to take the question to them, not to adopt a generic numerical-equivalence figure as if it were a clinical regulatory decision. TechnoLynx can produce the measured evidence that goes in front of that decision under the same AI Governance and Trust engagement. The threshold itself stays with your quality function.
INT8 behaviour belongs to the target, not the model
A 2026 cross-platform study of quantised inference found that FP32 top-1 predictions were bit-identical across every platform pair tested (1000 of 1000 inputs). INT8 predictions agreed on 958 to 965 of 1000 inputs whenever two targets used different integer kernels, while top-1 accuracy was preserved. The same study found that vendor NPUs own the quantisation. Qualcomm’s Hexagon HTP silently ignored externally supplied INT8 scales, and accuracy collapsed from 0.75 to 0.005 while the model compiled, profiled and ran without any error. The authors’ recommendation is to re-validate INT8 on each target, not once. AMD’s Vitis AI documentation makes the same point at the toolchain level: a model compiled for one DPU architecture has to be recompiled for another.
The FDA describes a locked algorithm as one that gives the same result every time it receives the same input. In that study, INT8 predictions matched on every input only when two targets shared an integer kernel. Equivalence evidence therefore has to be re-run for each target, as the study’s authors recommend.
An equivalence evidence checklist
Begin by freezing a gold-standard baseline before an inference-stack upgrade: fixed reference data, fixed preprocessing and the FP32 outputs every INT8 build is compared against.
| Evidence item | Why aggregate accuracy is not enough |
|---|---|
| Fixed preprocessing and full test set | In the 2026 portability study, the choice of resize and crop moved top-1 by 1.07 points, about nine times the 0.12-point cost of quantisation, and a 1000-image subset overstated top-1 by 9.77 points on average. |
| Sensitivity, specificity, PPV and NPV with confidence intervals | These are preferred measures for binary outputs, and acceptance criteria can compare a confidence limit with a pre-specified performance goal. |
| Calibration (ECE, NLL) | A quantised model can keep its global AUC or Dice while becoming overconfident in wrong predictions. |
| Rare-class and subgroup sensitivity | Compression errors concentrate on a small subset of examples, where they amplify existing bias, even when top-line accuracy hardly moves. |
| Per-input agreement with FP32 on the target | Prediction disagreement across integer kernels does not show up in top-1 accuracy. |
| Latency under the SLA, measured on target hardware | Latency comes from co-design of hardware and compiler, so the guidance is to benchmark on the target, not rely on reported figures. |
| Robustness to foreseeable input changes | FDA draft guidance asks for robustness to reasonably foreseeable changes in input data and conditions of use, scaled to risk. |
| Built configuration versus intended configuration | In one Jetson deployment, TensorRT’s INT8 calibration quantised the vision backbone but accepted none of 145 transformer layers, which stayed in FP16. |
Choose the metrics that reflect the clinical task, not numerical fidelity alone. In an embedded robotics study, a 40-fold increase in worst-case numerical deviation made no detectable difference to task success. The authors add that their task was forgiving and that a less tolerant one might not have absorbed the error. When the evidence falls short, published work describes ways to recover accuracy. Leaving the most quantisation-sensitive layers in floating point brought all tested networks except BERT back within 1% of FP32, and a review found quantisation-aware training more reliable than post-training quantisation for medical imaging.
Set the bounds before you see the results
Equivalence testing asks whether the data rule out a difference large enough to matter, which is a different question from whether the difference is statistically significant. The bounds have to be set and documented before anyone looks at the results, and justified by risk, engineering tolerances, measurement capability and the applicable regulations. Two one-sided tests (TOST) conclude equivalence only when both nulls are rejected. At alpha 0.05 that corresponds to a 90% confidence interval lying entirely within the bounds. A process-improvement guide on equivalence testing lists software updates and site transfers among its example uses. The FDA’s own wording for a passing test is that actual results are “acceptably equivalent” to expected results. Clinical validation practice adds one more discipline: freeze the algorithm before the test data are collected or unmasked.
Which protocol it attaches to, and who signs before hospital data
The FDA’s validation guidance says the existing validation plan for previously validated software should be revised to cover the revised software. We would therefore attach the equivalence addendum to the original FP32 validation protocol. Whether your policy allows an addendum or requires a new protocol is still your quality function’s decision. The same applies to running the study on hospital data: confirm the sign-off first. Test data should also be independent of development data and kept away from the developers.
Performance also varies with the acquisition conditions at each site. In a simulated CT lung-nodule study, increasing slice thickness to 5 mm cut detection sensitivity by 42% relative to baseline, an acquisition change rather than a precision change.
What extra validation rigour do we need because we can’t patch the device after implantation?
We would treat a device that cannot be updated after implantation as a one-shot release. In our approach, pre-release validation covers the full operating envelope, because no field correction is possible. We would set the release gate to block shipment if any metric misses its pre-defined accuracy or safety threshold. TechnoLynx’s healthcare AI engineering team sets the one-shot thresholds with your regulatory and clinical team, implements the model on the implantable accelerator with the fallback kept, and produces the release-gate evidence and design-history documentation.
Software whose failure could cause a hazardous situation with a probable risk of death or serious injury needs FDA Enhanced Documentation. The FDA’s own examples include failure to pace and incorrect sensing of an ectopic beat. Risk acceptability criteria belong in the risk management plan before the first risk evaluation is carried out. FDA draft guidance also recommends considering the intended duration of implantation or patient exposure when designing performance testing. Software validation guidance asks for testing across the full range of operating conditions, run long enough to expose latent faults. Release gates on regulated workflows and validation packages are part of production AI reliability. That is an engineering discipline distinct from model accuracy.
For the gate itself, we would borrow the rule the PCCP guidance sets for modifications: if pre-defined acceptance criteria are not met, the failure is recorded and the change is not implemented.
What the submission needs to show about irreversibility
FDA expects the software version history to record any differences between the tested and released versions, with an assessment of how they might affect safety and effectiveness. For AI-enabled devices that includes the model version. For an INT8 build, we would also record which layers actually ran at which precision. Residual risk after controls has to be judged against the plan’s acceptability criteria. Where it is unacceptable and cannot be reduced further, the sponsor should document a benefit-risk analysis showing the benefits outweigh it.
In our view, non-updatability should go into that residual-risk evaluation as an input in its own right. Any edge case the validation misses stays in the field for the device’s life.
Should we keep an FP32 fallback, and how quickly can we fall back?
We would keep an on-device FP32 fallback when the clinical consequence of an INT8 failure is serious and the extra silicon and power cost is acceptable. The fallback is part of the device, so it has to be validated to the same standard as the primary path. On an implant, falling back cannot mean shipping a rollback. The speed depends on the on-device logic that detects an edge case and switches paths. The arbitration logic also has to expect disagreement. Redundant compute assumes two units agree on the same input, and the 2026 portability study shows that assumption holding under FP32 but failing across heterogeneous INT8 kernels.
For devices that can be updated, the same idea is easier to apply. The PCCP guiding principles call for mechanisms that detect a change failing its performance criteria and revert or stop it. Configuration management of the validated FP32 build, its specifications and test suites keeps it identifiable and accessible for that reversion. Our piece on change-triggered revalidation, monitoring and rollback for deployed models covers that operating side, including the post-deployment monitoring auditors may still expect even after a reduced package.
Who can port our quantised model onto an ASIC with a small FPGA co-processor?
TechnoLynx ports quantised models onto fixed-function accelerators and FPGA co-processors through its AI Porting & Deployment Pack. The work covers confirming quantisation targets against the ASIC’s fixed datapath and the FPGA’s limits, choosing techniques the vendor toolchain accepts, compiling and optimising the model, validating functional and performance parity on the target hardware, and handing over a qualified compiled model with documentation. On build versus buy: in our judgement, a team without ASIC or FPGA toolchain experience and with a fixed refresh deadline is better served by a specialist. Building in-house makes sense when the timeline has slack and there is a strategic reason to keep the skill. On track records, ask any provider, including us, for shipped work on your exact silicon class, not embedded AI in general. Timeline and cost come out of scoping.
The silicon vendor’s own quantisation path is a real alternative, because in a cross-platform study both NPUs tested produced a correct engine only through it. Growing the skill in-house on the vendor’s toolchain is another fair route. Either way, check for lock-in to a proprietary toolchain before committing.
Why the port is more than a recompile
The Vitis AI compiler splits a quantised graph into subgraphs depending on whether their operators can run on the DPU, and layer ordering changes what the quantiser and compiler can fuse. In one YOLO port to a Xilinx DPU, SiLU activations had to be replaced with ReLU, and the attention block’s reshape, transpose, matrix-multiply and softmax operations had to be approximated with convolutions. Those modifications cost about 3% mAP before quantisation, and the final FPGA deployment lost about 5% accuracy compared with CPU execution. A different model ported through Vitis AI to a VCK5000 lost around 1% when converted to INT8. The size of the loss depends on the model and has to be measured.
That has a regulatory consequence. We would therefore restart the significance assessment from that broader change, since operator substitutions and retraining change the model itself, not just its precision. FDA guidance notes that a complete rewrite of a core algorithm can require a new 510(k) even when the performance claims and risk profile stay the same.
What drives timeline and cost
Three things bound the schedule: how far the model has to shrink to fit the fixed datapath, how early you get real access to the target hardware, and how many qualification cycles the change triggers. An estimate given before the model and the ASIC constraints have been scoped is a guess, and a refresh deadline does not make it any more reliable.
If a product will run on more than one accelerator during its life, plan for one equivalence study per target and per recompile from the design stage onwards. Leaving it until the first hardware refresh is the expensive option. TechnoLynx covers that per-target validation in its AI Governance and Trust work.
FAQ
What is the FDA 21 CFR 820.30 guidance?
21 CFR 820.30 covers design controls. Section 820.30(g) requires procedures for validating the device design, including software validation and risk analysis, and 820.30(i) requires design changes to be documented, validated or verified, reviewed and approved before implementation. The QMSR no longer uses the term “design controls”; the equivalent elements now sit in ISO 13485:2016 clause 7.3, which the regulation incorporates by reference.
