Engineer's desk with a reviewed code change going through a build server to an infusion pump

Services · AI coding tools in regulated development

AI coding tools inside an IEC 62304 lifecycle.

Developers use AI coding tools, and prototypes are built with them at speed. Code written this way needs a requirement, a recorded review and a test, like any other device code. Silurus Software sets up the procedures in your QMS, and puts code written with the help of AI, or prototype code, under that lifecycle, so that the evidence for a notified body (the independent organisation that certifies a device under the EU MDR) or FDA submission can be built on it.

Book a 30 minute call Write to us

First step: Two week technical assessment
Process: IEC 62304 · ISO 13485 · ISO 14971
Security: IEC 81001-5-1
Route: EU MDR · FDA

What we cover

Code written with the help of AI under control

Procedure for AI tools

We write the tools into your development plan and work instructions: what they may be used for, and where not. Tool versions and settings are recorded, and a change of model or terms of use triggers a new assessment.

Regulatory consulting →

Review and traceability

Every generated change is submitted for review with a named reviewer and traces to a requirement, a risk control or a problem report. Verification follows the software safety class (A, B or C, by the harm a software failure could cause) and the risk analysis.

Prototype to product

We record what it does and add tests that pin the behaviour. The requirements follow from the intended use and the risk analysis, and the code is checked against them. Documents written after the fact are marked as retrospective, and safety relevant parts that cannot be shown to be correct are redesigned.

Retrospective IEC 62304 documentation →

Large generated codebases

Our engineers review, restructure and document the code module by module.

Legacy modernisation and takeover →

Licences and third party code

Reviewers check generated code for copied third party code. Third party components and their licences are recorded in the SBOM (software bill of materials, the list of every software component in the build), and components that meet the IEC 62304 definition of SOUP (software of unknown provenance, meaning third party code used in the device) are also on the SOUP list with their risk assessment.

Security of generated code

Static analysis and dependency checks on every build, secure coding rules checked in review, and the threat model (a structured analysis of how the device could be attacked) updated when generated changes alter the architecture or interfaces.

Medical device cybersecurity →

Confidential data

Which repositories and data the tools may access is agreed in writing, with patient data kept out.

Tools

The AI tools we use and assess

Silurus Software uses these tools in its own development and assesses them for clients before they are named in a development plan.

Agentic coding

Claude Code, OpenAI Codex and the agent mode of Cursor write multi file changes from a task description. Each change goes through the same review, tests and traceability as hand written code.

Coding assistants

GitHub Copilot, ChatGPT and JetBrains AI Assistant suggest code in the editor, and the developer stays the author of every accepted line.

Local models

Open models run on local hardware with Ollama, so code, requirements and test data stay inside your network.

Suggested tests and review

Unit tests and review comments proposed by AI, accepted or rejected by an engineer and recorded in the review record. Expected results are taken from the requirement and never from the generated code.

Security fixes and vulnerability triage

AI suggested fixes for static analysis findings, such as GitHub Copilot Autofix, and triage of new CVEs against the SBOM. Each is reviewed like any other change. Those that address a vulnerability are also entered in the IEC 81001-5-1 vulnerability process, from assessment through fix and verification to release, and are merged after that review.

In practice

Situations we are asked to solve

Situation

Introducing AI coding assistants into a regulated team

A manufacturer wants its developers to use AI coding assistants and needs to know what changes in the QMS before they start.

How we approach it

We run a bounded pilot with one team: the tools are named in the development plan, rules for use and review are written into the work instructions, the tool is assessed for its intended use, and traceability from requirement to test stays in your tools. The pilot ends with a written result on effort, quality and the procedure to roll out.

Situation

An app built quickly with AI tools, heading for Class IIa

A startup built a patient facing app with AI coding tools. It works, nobody fully understands the code, there are no tests, and it has to become a Class IIa product.

How we approach it

We record what the app does, add tests that pin the behaviour, restructure the code and write the requirements, the risk file and the IEC 62304 records, then continue development under that lifecycle.

How it runs

From the code as found to a product you can defend

Weeks 1 to 2

Assessment

What the system is, what it takes to make it releasable and the first steps, in a written report.

Step 2

Tests and requirements

Tests that pin the current behaviour, the requirements written down from the intended use together with a first risk analysis, then verification tests derived from them.

Step 3

Restructuring

Boundaries drawn, duplication removed and the safety relevant parts isolated.

Step 4

Evidence

Risk file completed, traceability and software documentation in your templates.

What you receive

Results you can use with or without us

D-01

Assessment report

What the system does, module by module, and what it takes to release it.

D-02

Procedure for AI tools

The section of your development plan and work instructions that governs the tools, with the assessment record for each tool.

D-03

Tests and requirements

Regression tests and the written requirements and intended use.

D-04

Remediation plan

The steps in order of risk and effort, with the effort for each.

EU and US

One set of records for both markets

European Union

EU MDR

Generated code goes through the same lifecycle and documentation as any other code in the technical documentation.

United States

FDA

The same development records feed the software documentation of the FDA submission, which is written separately from the MDR technical documentation. For the US the QMS is mapped to the FDA QMSR (21 CFR 820). The documentation level, Basic or Enhanced, follows the FDA's own criteria and is not the same as the IEC 62304 software safety class. Our FDA consultants work with you where needed.

Technologies and standards

What we work with

Technologies and tools

GitGitHub ActionsGitLab CIAzure DevOpsSonarQubeCodeQLSemgrepOWASP Dependency-CheckSyftGrypeClaude CodeOpenAI CodexCursorGitHub CopilotGitHub Copilot AutofixChatGPTJetBrains AI AssistantOllamaLocal open models

Standards, regulations and practices

IEC 62304ISO 13485ISO 14971IEC 81001-5-1Code reviewStatic analysisDependency checksSBOMSOUP listLicence reviewCharacterisation testsTraceability matrixRoot cause analysisCAPAEU MDRFDA

Silurus Software

Silurus Software, founded in 2017, offices in Budapest, Hungary, and Singapore
More than 40 engineers, EU MDR regulatory specialists and FDA consultants
Work inside the client's ISO 13485 quality management system, with the split of tasks written down before the work starts. Where the client has no documented software process yet, we bring IEC 62304 templates for the client to adopt into its own system
Multi-year engineering partner of a European MedTech manufacturer
Founder and CTO Péter Török, in medical technology software since 1999, formerly software development director at Siemens Healthcare (syngo.via) and head of R&D at Mediso Medical Imaging Systems
ISO 9001:2015 (NQA, certificate 171041, valid until March 2027) and ISO/IEC 27001:2022 (NQA, certificate 728872, valid until August 2029)
Awarded AAA, Highest Creditworthiness, by Dun & Bradstreet in 2025
Research partner of ELTE Eötvös Loránd University, Budapest
Industrial partner of the University of Bologna, the University of Pisa, the University of Amsterdam and Masaryk University, Brno, in the EU Horizon Europe project LOGOS from 2027
Female Business Leader of the Year 2025 and The Pioneer Award 2026, awarded to CEO Dr. Linda Szántó

How we work →Quality and standards →Sample deliverables →Case studies →

Related work and pages.

Retrospective IEC 62304 documentation Legacy modernisation and takeover AI model to medical device Regulatory consulting, EU MDR and FDA

FAQ

Frequently asked questions

Can our developers use AI coding tools under IEC 62304?

Yes. The development plan names the tools, every change is reviewed and verified, and each one traces to a requirement. We set this up in your QMS.

Who is responsible for code an AI tool wrote?

The manufacturer, as for any code in the device, including the release decision and the acceptance of residual risk. Every generated change is submitted for review with a named reviewer and traces to a requirement, a risk control or a problem report. Verification follows the software safety class and the risk analysis.

Can a prototype be brought under an IEC 62304 lifecycle?

Yes, or the assessment shows which parts cost less to rewrite. We record what it does and add tests that pin the behaviour. The requirements follow from the intended use and the risk analysis, documents written after the fact are marked as retrospective, and safety relevant parts that cannot be shown to be correct are redesigned.

How does a project start?

With a two week technical assessment under NDA, ending in a written report. The tests, the requirements and the procedure for AI tools come in the work that follows, quoted and agreed in writing. Code and documents are yours once paid, with a full handover if you stop.

Do AI coding tools have to be validated?

Yes, in proportion to risk, as ISO 13485 clause 4.1.6 asks for software used in the quality system. The depth depends on the role of the tool. For a coding assistant whose output a named engineer reviews, the assessment records the intended use, the controls around it and the residual risk, and the generated code is verified as device code. A tool whose output enters the quality system or the device record unchecked needs more.

How do you protect our code and data when AI tools are used?

Which repositories and data each tool may access is agreed in writing, patient data stays out of the tools, and the tool settings and contracts are checked for how code is stored and used.

Can you run a pilot with one team first?

Yes. A bounded pilot with one team, a written procedure and a result on effort and quality, before the tools are rolled out.

Talk to us

Tell us about the code.

The system, how it was built and the market. We reply with the first step.

Book a 30 minute technical call