IEC 62304 Software Safety Classification When Agents Write the Code

In short

IEC 62304 assigns each medical device software system a software safety class, A, B or C, from the harm a failure of the software could contribute to, after the risk control measures that sit outside the software. The class sets which lifecycle activities the standard requires and how much evidence they leave. Nothing in that decision depends on who or what wrote the code, so an AI coding agent does not change the class. What it changes is the evidence: the development plan has to name the tool, every item it produced needs verification that the agent did not perform on itself, dependencies it pulled in are software of unknown provenance and carry that clause's requirements, and the approved design has to precede the code it implements. The accountable authority for all of it remains the manufacturer.

What IEC 62304 asks

IEC 62304 is the lifecycle standard for medical device software, published in 2006, amended in 2015, and recognized by the FDA as a complete standard under recognition number 13-79 (FDA recognized consensus standards database). It sets its own limit in its scope: "This standard does not cover validation and final release of the MEDICAL DEVICE, even when the MEDICAL DEVICE consists entirely of software." The FDA states the validation the standard leaves out: "software validation refers to establishing, by objective evidence, that the software specifications conform to user needs and intended uses" (June 2023 guidance, section IV).

Its introduction and its compliance clause set the terms. The standard "does not prescribe a specific life cycle model" and "does not prescribe the name, format, or explicit content of the documentation to be produced". Its risk process "has to be embedded in the device RISK MANAGEMENT PROCESS according to ISO 14971", which is its single normative reference. And compliance is tied to the class: "Compliance with this standard is defined as implementing all of the PROCESSES, ACTIVITIES, and TASKS identified in this standard in accordance with the software safety class." The class markers sit in the normative text after each requirement, and Annex A summarizes them in Table A.1. Compliance "is determined by inspection of all documentation required by this standard including the RISK MANAGEMENT FILE", by internal or external audit (IEC 62304:2006+AMD1:2015, public preview: introduction, clauses 1.2 and 1.4).

How the software safety class is decided

Clause 4.3 and Figure 3 of the amended standard carry the decision. In the standard's terms, the manufacturer asks whether a failure of the software system can contribute to a hazardous situation. If it cannot, the system is class A. If it can, the manufacturer asks whether the risk control measures outside the software bring the risk to an acceptable level. If they do, the system is class A. If they do not, the question is what harm could follow: class C where the harm could be death or serious injury, class B otherwise. The 2015 amendment, in the words of its own introduction, updated the classification "to include a risk-based approach", and the consolidated text keeps a premise the IEC committee quotes in its public rationale for the next edition: "probability of software failure is assumed to be 1" (IEC SC 62A, change rationales for the second edition).

The classified system decomposes into software items. An item inherits the class of the system unless the manufacturer documents a rationale explaining how it is segregated, and software that implements a risk control measure takes the class of the hazard it controls; at class C the segregation needed for risk control is identified and its effectiveness stated under clause 5.3.5. The FDA decides how much software documentation a submission needs with a test of its own. Its 2023 guidance on premarket submissions sets two documentation levels, and beyond three device types it names, the test that turns on the software is this: "Enhanced Documentation should be provided for any premarket submission that includes device software function(s) where a failure or flaw of any device software function(s) could present a hazardous situation with a probable risk of death or serious injury, either to a patient, user of the device, or others in the environment of use. These risks should be assessed prior to implementation of risk control measures." (Content of Premarket Submissions for Device Software Functions, June 2023, section V) The FDA decides its level before risk controls; the standard lets controls outside the software lower the class.

The second edition, as drafted, would replace the three classes and keep the same inputs: the committee's public rationale describes the "Replacement of the three software safety classes with two software process rigor levels", and the IEC project page lists it at committee draft stage with a forecast publication date of 26 October 2028 (IEC webstore, under development). Until then the three classes stand.

What changes when an agent writes the code

With the class fixed by the hazard, an agent changes the evidence in five places. Which of them the standard itself requires depends on the class, as Table A.1 marks: the tools clause at class C, unit verification and design at classes B and C, configuration management and problem resolution at every class; below those markers the same questions are asked by the design controls of the quality system, and the volume of what they are asked about rises with the agent, the shift our article on agentic engineering describes. Authorship does not move the class, and an agent's change can, if it breaches a segregation rationale or touches a risk control measure; the architecture row below catches that.

The development plan has to name the tool. Clause 5.1.4 asks for the standards, methods and tools used in development to be planned. In the amended standard that requirement applies to class C; the committee's rationale for the second edition extends it to both rigor levels and explains how the tools themselves are handled: "These methods and tools are typically validated under Quality Management System requirements, such as Computer Software Validation or Computer Software Assurance programs within medical devices." A coding agent is a development tool. The standard has no tool qualification clause; the tool is handled by the quality system, where the committee's rationale places it, under the validation of software used in the quality system that ISO 13485 asks for before first use and after changes, with the FDA's February 2026 guidance on computer software assurance supplying the risk-based method, "a risk-based approach for establishing and maintaining confidence that software is fit for its intended use", while leaving the verification of the device software itself to clause 5 (Computer Software Assurance for Production and Quality Management System Software, February 2026). A tool whose output is fully verified by independent means needs less assurance of its own, and a hosted model that changes without notice needs its version and settings recorded. The agent belongs in the plan by name and version; the premarket summary already asks for "Software coding standards, methods, and tools used in software development" (June 2023 guidance, section VI.G).

Every item the agent produced needs verification the agent did not perform on itself. Clause 5.5 covers software unit implementation and verification. The FDA states its own definition of verification in public: "software verification is confirmation by objective evidence that the output of a particular phase of development meets all the input requirements for that phase", through testing, "source code evaluations (e.g., code inspections and walkthroughs), document inspections, design reviews, technical evaluations" and "traceability analyses" (June 2023 guidance, section IV). An agent that writes a unit and its unit tests has produced both sides of that comparison. The standard's own mechanism is sequence: acceptance criteria established before verification, verification against them, results recorded. Our white paper The Agentic Engineering Assurance Layer states the structural limit: "Producer-generated evidence is useful but structurally limited. Higher assurance requires mechanisms that a producing agent cannot silently rewrite, such as trusted build provenance, separate test execution, independent review, or human specialist assessment. Independence can be technical, organizational, or methodological." For class C, the review record should show who verified the item, what they compared it against, and that the comparison was not the agent's own. The committee's public rationale lists a new static code analysis clause at level II as part of unit verification, one more verification source that the producer does not control.

Dependencies the agent pulled in are software of unknown provenance, and the record is what lets the manufacturer discharge the requirements. The scope of the standard applies "including the requirements concerning software of unknown provenance (see 8.1.2)". In the standard's terms, software of unknown provenance is software already developed and generally available that was not developed for incorporation into the device, or previously developed software for which adequate records of the development process are not available. A public package an agent adds meets the first limb, and the manufacturer "generally gives up software life cycle control, but still bears the responsibility for the continued safe and effective performance of the medical device" (Off-The-Shelf Software Use in Medical Devices, August 2023). What the record does is let the manufacturer meet the obligations that follow: identification of the item in configuration management (8.1.2), its functional, performance, hardware and software requirements (5.3.3 and 5.3.4), its failure as a potential cause in the hazard analysis (clause 7.1), and its upgrades and obsolescence in the maintenance plan (clause 6). The second limb concerns the agent's own output: the manufacturer's code is its own software only while the lifecycle records of clause 5 exist for it. For a cyber device, each added package is also a line in the software bill of materials and a vulnerability to monitor, and a package name an agent invents can be registered by anyone, as our piece on AI code checkers documents. The practical consequence is a rule for the agent's session: every dependency it adds is logged with its name, version and reason at the time, and reviewed as a SOUP decision. Our provenance checklist for AI-assisted changes covers how that record is kept.

The design comes before the code, and the record has to show it. The FDA's enhanced documentation asks for a software design specification, and its guidance is explicit about the order: "the creation of the SDS is expected to have occurred as a prospective activity where the SDS was used to guide the design, development and testing of the software rather than documented retrospectively after the software design has been implemented by ad hoc design methods" (June 2023 guidance, section VI.F). The standard's clause 5.4 asks for the detailed design to exist and be verified before the unit that implements it, and the FDA's sentence targets a design reconstructed from finished code; in iterative development that holds per increment. An agent may draft the design. A reviewer approves it before the agent implements it, and the record shows the approved design as the input.

The record of each change has to outlive the session. Clause 8 on configuration management and clause 9 on problem resolution ask for change requests, their approval, their implementation and their verification to be traceable. Our white paper AI Has Moved the Bottleneck describes the same need from the other side: the engineering system should hold "the implementation artifacts and their provenance" and "verification results tied to exact versions and environments". Agent-initiated dependency upgrades are changes under clause 6, and anomalies the agent found and fixed mid-task are problem reports under clause 9, even when the agent closed them. The change record must stand on its own; the session transcript, or a reviewed summary, is supporting evidence kept under the manufacturer's records procedure.

What an accountable authority will want, by level

The table uses the FDA's two documentation levels, which are public, and marks what an agent-produced change adds to each element. The standard's Table A.1 does the same by class in the standard's own numbering; the mapping below is ours.

The right-hand column is the agent question from the figure, written out per element; the other columns stay as the guidance lists them, and the assurance case is where the answers are kept together.

Where the guidance on AI in the device stops

A separate body of guidance covers artificial intelligence inside the device, and it is easy to confuse the two. The FDA's January 2025 draft defines its subject as "a device software function that implements one or more 'AI models' (referred to as 'models' in this guidance) to achieve its intended purpose" (Artificial Intelligence-Enabled Device Software Functions, draft, January 2025). The European guidance on medical device AI under the AI Act covers "AI systems used for medical purposes" (MDCG 2025-6). None of them addresses an AI tool used to write conventional device software, and as of October 2026 we found no regulator or notified body document that does.

Where Kealu Vector fits

The Agentic Engineering Assurance Layer is the proposed category for the layer that governs how agentic engineering work is performed and evidenced, so that humans can trust and accept the resulting work. The white paper The Agentic Engineering Assurance Layer develops it as a vendor-neutral category, and the questions raised here hold whatever tools a team uses to answer them. Kealu Vector, currently designated Vector Assurance Assist, is our early-access implementation of that category.

FAQ

What are the IEC 62304 software safety classes?

Class A, B and C, assigned to each software system under clause 4.3 from the harm a failure of the software could contribute to. In the amended standard's terms, class A where the software cannot contribute to a hazardous situation, or where the risk is acceptable after the risk control measures outside the software; otherwise class B where the harm could be non-serious injury and class C where it could be death or serious injury. The class sets which processes, activities and tasks the standard requires.

Does AI-generated code change the IEC 62304 software safety class?

No. The class depends on the hazard the software can contribute to, the risk controls outside the software and the severity of the harm, and none of those depends on who wrote the code. What changes is the evidence: the agent is named in the development plan under clause 5.1.4, its output is verified by means it did not control, dependencies it added are handled as software of unknown provenance, and the approved design is shown to have preceded the implementation.

Is code written by an AI coding agent SOUP under IEC 62304?

Code the manufacturer's team produced with an agent, under its own lifecycle and with its development records kept, is the manufacturer's software. A package the agent pulled in, already developed and generally available and not developed for the device, or one whose development records are not available, meets the standard's description of software of unknown provenance and is handled under clauses 5.3.3, 5.3.4 and 8.1.2. The record does not change that designation; it is what lets the manufacturer meet the requirements, which is why every dependency an agent adds should be logged with its reason at the time.

Does the FDA guidance on AI-enabled devices apply to AI-written code?

No. The January 2025 draft guidance covers device software functions that implement AI models to achieve their intended purpose, meaning AI that runs in the device. Code written by an agent at development time and shipped as conventional software falls under the June 2023 guidance on premarket submissions for device software functions, and the agent itself is a development tool handled under the quality system.