Fitting an AI/ML model into the IEC 62304 lifecycle means classifying the software item that contains it, tracing requirements through design to verification, keeping versioned test records for every release, and sending post-deployment drift back into the lifecycle through problem resolution and change control. The edition that governs this work today is IEC 62304:2006 with Amendment 1:2015, harmonised in the EU as EN 62304:2006+A1:2015. The base standard was written for deterministic software and has no specific provisions for learned parameters, so medical device software development teams have had to extend it with AI/ML guidance.

Is IEC 62304 mandatory, and does the FDA recognise it?

Using IEC 62304 is voluntary, but Team-NB, the association of European notified bodies, says in its implementation FAQ that the standard represents the current state of the art. Notified bodies use it as their frame of reference when they assess a manufacturer’s evidence. Complying with the harmonised edition gives a presumption of conformity with the relevant essential requirements. A manufacturer that does not apply it has to show conformance with other objective evidence. Team-NB also warns that conformance cannot be partial: tailoring the “degree of compliance” is not allowed, so a claim of compliance means full compliance with every applicable clause, scaled by safety class.

The FDA recognises IEC 62304 as a consensus standard, in the form of IEC 62304 Edition 1.1 (2015-06) and ANSI AAMI IEC 62304:2006/A1:2016. The FDA’s June 2023 final guidance on premarket submissions for device software functions lets a sponsor provide a Declaration of Conformity to specific clauses of the recognised version, or to the whole standard, in place of describing its development, configuration management and maintenance practices from scratch.

Conformance alone does not cover every essential requirement. Team-NB notes that the standard does not cover usability, clinical evaluation, final validation of the software product or accompanying documents such as user instructions. IEC 62304 also points to ISO 14971 for the risk management process instead of replacing it.

What about Edition 2?

Edition 2 is where the standard’s own AI-specific requirements are, and it is not published yet. Genorma’s listing of the IEC project shows Edition 2 at stage 30.20, with a committee draft ballot initiated on 7 August 2026 and the next stage, PCC, dated 27 November 2026. Once it is published, it will still need its own EU harmonisation process. Until then EN 62304:2006+A1:2015 remains the harmonised standard, although notified bodies are already folding its principles into their expectations for AI/ML.

According to the IEC change rationales, the draft replaces the three safety classes with two rigour levels: level I replaces class A, and level II replaces classes B and C. Its scope widens from medical device software to health software. We cover its AI planning clause in the AI/ML section below.

How do you justify the safety class of a module that contains a model?

You classify by the worst credible harm a software failure could contribute to, assessed before any risk control measures are applied, and you record the reasoning in the risk management file. IEC 62304 defines class A as no injury or damage to health possible, class B as non-serious injury possible, and class C as death or serious injury possible. Assigning a class is compulsory. Team-NB’s FAQ describes starting from class C and justifying any lower class through hazard analysis, which depends on a clear intended use.

For an AI module, the question we would ask is what happens to the patient when the model is confidently wrong. A missed finding in a triage model, or a wrong dose suggestion, reaches the patient through the clinical workflow, and every such chain of events contributing to a hazard must be addressed. It cannot stop at “the model only advises”. The FDA’s 2023 guidance shows the same logic with a sepsis alarm that analyses patient records: a failure to raise the alarm is treated as a probable risk of death or serious injury, which puts it at the Enhanced documentation level.

The class cannot be talked down using the software’s own safeguards. Risk controls implemented in software do not lower the class of the software that implements them. Controls outside the software, such as hardware interlocks, independent monitoring or clinical procedures, can lower it, but only where segregation is demonstrated in the architecture. The 2015 amendment allows items inside one system to carry different classes when the architecture shows effective segregation. Claimed segregation must itself be verified, typically with static analysis, fault-injection testing and review of the runtime isolation. Segregation that is asserted but not verified will not support a lower class.

A stated class needs a documented, risk-based justification. For AI modules we would be especially wary of using “a clinician reviews every output” as the external control unless there is evidence that the review actually catches model errors. The draft Edition 2 adds a requirement to verify the effectiveness of external risk controls used to lower the rigour level.

Do the architecture and design documents for an AI component have to trace to the requirements?

Yes, and the depth of tracing scales with class. Clause 5.1.1 requires traceability among lifecycle outputs. The MD Regulatory guide on 62304 verification sets out the expected granularity as follows: class A links software requirements to system tests; class B adds architecture, with requirements traced to architectural items and those items traced to integration tests; class C is full and bidirectional, running from requirements through architecture, detailed design, unit tests, integration tests and system tests, with risk control measures traced through to verification evidence.

The sources disagree on bidirectionality. Team-NB’s FAQ says the standard requires traceability only in clauses 5.1.1.c, 7.3.3 and 8.2.4, with no explicit requirement that it run both ways, though it does not forbid it. We read the notified-body text as the stronger statement of what the standard literally demands, and bidirectional tracing as the practice that makes coverage gaps visible at audit. The FDA does not ask for a separate traceability document in a submission. It assesses traceability through the risk assessment, the requirements specification, the design specification and the test documentation, and expects the analysis to live in the design history file.

For a model, the requirement end of the chain is a set of quantitative quality criteria derived from the intended use. Examples are sensitivity and specificity for classification, or mean absolute error for regression. Team-NB’s 2024 AI questionnaire ties these criteria to EN 62304 clause 5.2. The informative Annex E of the draft Edition 2 addresses how to keep traceability when a system’s “design” is partly set by training data instead of explicit specification.

The matrix should be maintained continuously and under change control as development proceeds. We treat the matrix as an engineering output that a non-engineer has to be able to read and sign against, not as a compliance appendix.

What unit and integration test records does each release need?

Each release needs verification reports that reference the controlled build under test and record the verifier’s signed conclusion. Unit verification under clause 5.5 and integration testing under clause 5.6 apply to classes B and C. Since the 2015 amendment, system testing under clause 5.7 is mandatory for every class, including A. Class C adds defined acceptance criteria for unit verification that are applied and evaluated (clause 5.5.5). Reports must reference the controlled build under test, the controlled test procedure and the controlled environment.

The records do have to be under version control. Team-NB states that documents must be consistent and managed under configuration management, and that configuration management, including formal change control, starts when testing and integration begin. Its list of required documents includes the test plan, the traceability of test procedures to requirements (5.7.4), the test report (5.7.5), the residual anomalies (5.8) and configuration management records.

Class	Traceability	Test records expected	FDA documentation in a submission
A	Requirements to system tests	System test plan and report	Basic: summary of unit, integration and system testing, plus full system-level protocols and reports
B	Requirements to architecture to integration tests; requirements to system tests	Unit verification, integration and system test records	Basic or Enhanced, depending on whether a failure could present a probable risk of death or serious injury
C	Full chain to unit tests, with risk controls traced to verification	Unit verification against defined acceptance criteria, plus integration and system records	Enhanced: Basic plus full unit and integration protocols and reports

The FDA’s level follows the risk of the device software functions in the context of intended use, not the device class. An FDA presenter at the 2023 guidance webinar said that, largely, class C under 62304 matches up with Enhanced, and classes A and B with the lower level. In either case the FDA wants executed evidence: test cases with pass or fail outcomes and a justification for any failures, not blank protocols. It also recommends a history of tested software versions, with dates, version numbers and changes, starting from the version that came under design control.

Coverage thresholds are not in the standard. The MD Regulatory guide reports that auditors have come to expect statement coverage above 95% and branch coverage above 90% for class C safety-critical functions, while noting that IEC 62304 itself only requires acceptance criteria that the manufacturer defines. For the model, verification evidence is statistical, measured on data kept separate from the training data, and a validation dataset can be used in integration tests to confirm that the model has been integrated correctly.

System testing under IEC 62304 is not design validation under ISO 13485. The two need separate reports with separate acceptance criteria and separate sign-offs. The FDA’s 2002 and 2023 guidance likewise treats software validation as part of design validation of the finished device. Turning these records into a package an auditor can work through is a separate step, which we cover in our piece on packaging verification evidence that survives audit scrutiny.

How do you document verification and change control for the trained model itself?

Put the model under configuration control as a documented unit with its own verification against predefined acceptance criteria. The unit covers the weights, architecture and hyperparameters, the training code, the exact training, validation and test datasets, and the resulting metrics. The Team-NB AI questionnaire asks about each of these: model and training code under version and configuration control, the datasets under version control, records of which data trained, validated and tested the model, documented hyperparameters and quality metrics, and the ability to reproduce test and validation results.

TechnoLynx builds the engineering side of this. TechnoLynx starts by mapping which parts of the component (training data, model weights, inference pipeline) correspond to IEC 62304 software items and where the lifecycle has gaps. TechnoLynx then builds model versioning, training-data lineage and performance-monitoring instrumentation into the deployment pipeline, runs verification against defined acceptance criteria and documents the evidence for IEC 62304 audit. TechnoLynx does this as part of its AI engineering work for life sciences and healthcare. This is engineering evidence, not regulatory sign-off or certification.

Two sources bear on whether the model counts as SOUP. Stirbu et al. argue that a third-party model, whether integrated as a library, a service or data loaded at runtime, qualifies as SOUP. It then brings the SOUP obligations of clauses 5.1.5, 5.1.7, 5.3.3, 5.3.4, 7.1.3, 7.4.1 and 7.4.2, along with documentation of its input data, algorithm design and output decisions. Team-NB’s FAQ treats open-source code taken as-is as SOUP, but once modified it becomes a software item the manufacturer developed. By the same reasoning, we would treat a model you fine-tune or train yourself as your own software item, not SOUP.

Data is in scope as well. The draft Edition 2 lists data and simulators explicitly among the supporting items that must be controlled, and Team-NB asks that data-processing software and its libraries be documented and versioned. Changes to parameters or architecture need a defined procedure before and after market release, which Team-NB references to EN 62304 clauses 5.3, 8.2.1 and 9.4. Code review alone will not verify a model. Peer review of the architecture, the training data and the validation process should supplement it.

If it is meant to be retrained, the drift and change process below has to exist before release.

Does performance drift after deployment trigger re-entry into the lifecycle?

Yes, in our view: we would raise a detected drop in performance below the thresholds set in advance as a problem report and handle it as a potential change. If the model is retrained, the work goes back into the development activities through change-request evaluation and impact analysis. The RAISE lifecycle paper describes three sources of drift: data drift (changes in input characteristics such as new scanners or protocols), phenotype drift (disease presentation changing over time) and concept drift (diagnostic standards changing), plus degenerate feedback loops between AI recommendations and outcomes. When degradation is observed, the paper calls for a full clinical review and a repeat of the quality control study.

Monitoring cannot be bolted on later. The IEC change rationales for Edition 2 say monitoring planning should start early, with metrics defined and tested and, where possible, coded into the system as automatic alerts, because manual checks are not enough post-market. They add that locked algorithms drift as well, though more slowly. Team-NB expects the post-market surveillance plan to state the quality criteria and thresholds at which action is needed, and to identify concept and data drift. Re-validating ad hoc after a problem has already surfaced is weaker evidence. Drift detection is a release discipline, distinct from model accuracy, and it is what catches silent regressions before patients do.

The re-entry path, in order

1. Detect. Monitoring, coded where possible into the system as automatic alerts, flags degradation or drift in the deployed model’s performance.
2. Report. The breach is logged as a problem report under the problem resolution process, which applies to released software as well as software in development. Not every problem report must lead to a change, but reports on released products require extra decision steps under clause 6 to identify regulatory actions.
3. Analyse. A retrospective analysis of model errors, ideally with blinded expert validation on recent data, sizes the degradation and decides between retraining, threshold adjustment or retirement.
4. Evaluate the change. The change request for the released software is evaluated and approved, and any change is assessed for its effects to decide which lifecycle activities must be repeated.
5. Rebuild and re-verify. Retraining runs under the controlled data and model versions, test datasets are revised where new data enters, and regression analysis decides which tests to rerun.
6. Release. The retested version gets a new entry in the history of tested software versions.

Two regulatory limits sit on top of this path. Team-NB notes that learning-driven performance changes beyond a threshold may count as significant changes that need a new conformity assessment, and that notified bodies currently do not consider in-field self-learning devices certifiable unless safe operation is kept within the validated scope. In the US, a Predetermined Change Control Plan cleared or approved by the FDA lets changes consistent with that plan proceed without a new submission. The RAISE authors also note that fully automated continuous recalibration is currently infeasible in some geographies because of regulation.

Which supplementary guidance do teams use alongside IEC 62304 for AI/ML?

No harmonised standard specifically covers AI-enabled medical devices. One recommended approach adopts a widely recognised, sector-independent standard and supplements it with medical device-specific requirements. The main candidates the sources point to are listed below.

• IMDRF Good Machine Learning Practice: ten principles, including independent training and test sets and monitoring of deployed models with controls on retraining risks.
• BS/AAMI 34971:2023: guidance on applying ISO 14971 to machine learning.
• ISO/IEC 5338:2023: AI system lifecycle processes, which one EU industry lifecycle model adapts for medical devices.
• Team-NB AI questionnaire: the notified bodies’ own checklist, referenced to EN 62304.
• FDA 2023 premarket software guidance: questions for ML-enabled functions on methods, training data, bias and transparency.

Edition 2 will bring much of this inside the standard. Its draft clause 5.1.15 requires an AI plan whenever software includes AI or ML. Per the industry summary, the plan covers the technology type, the component’s intended function, data sources and governance, the training, validation and testing approach, performance metrics and acceptance criteria, monitoring and retraining strategy, and bias mitigation. The IEC rationales say the scope runs from basic decision trees to large language models. The plan breaks down into an AI Development Lifecycle with phases from planning and data engineering through model maintenance and decommission. That lifecycle sits on top of the existing software lifecycle requirements, so the software development plan still applies, with an AI plan added beside it. Under Edition 1.1, a team can already structure its AI plan along these lines, but it should cite it as good practice and not as conformance to a standard that has not been published.

The test an auditor will actually apply

All of this reduces to one check an assessor can run on any release: pick a deployed model version and follow it back to its class justification, its requirements, its datasets, its executed verification records and every change request since. If each link exists as a controlled record made at the time, the lifecycle mapping holds. If any link has to be reconstructed, the module is not ready to be relied on in a regulated submission, whatever the quality manual says. What remains genuinely uncertain is how Edition 2 will settle once it is published and harmonised.

FAQ

What is the difference between IEC 62304 and IEC 82304?

IEC 62304 covers the software lifecycle processes, while IEC 82304-1 sets general requirements for health software product safety. Both are among the core standards for medical software. The boundary matters because validation evidence under IEC 82304-1 and ISO 13485 should be kept apart from verification evidence under IEC 62304.