Does AI-generated code and documentation hold up in an FDA submission?

Yes, because a qualified engineer reviews, verifies, and signs off on every AI-generated artifact, exactly as they would for hand-written work, and independent V&V exercises the result. What a reviewer evaluates is the evidence, and the evidence is identical whether an artifact was drafted by a person or by an AI aid: the IEC 62304 lifecycle, the verification records, and the 21 CFR Part 11 account of who did what.

How do you validate the AI tool itself?

We treat AI as an unvalidated development aid, not a validated tool that produces final work product on its own, and under the QMSR (ISO 13485 clause 4.1.6) and IEC 62304 that distinction is what matters. Because a seasoned engineer reviews and verifies every AI-generated artifact, and independent V&V confirms the result, the output is treated like any draft that must be checked, never relied on unverified. We record where and how AI was used, who reviewed it, and the tests that confirm it, in the design history file. Where a tool's output is relied on directly (for example, automated test execution), that tool is qualified for its intended use under GAMP 5 risk-based principles.

Is our code or IP exposed to AI models?

No. We use AI under enterprise agreements that keep your code and documents out of public model training, scope exactly what tooling touches your project with you before we start, and do not use AI on a project where your contracts prohibit it. Confidentiality is handled the same way it is for any regulated engagement.

How is this actually faster if a human reviews everything?

AI is fastest on the high-volume, mechanical work: first-draft requirements and tests, boilerplate, documentation drafts, and keeping traceability current. That is where reviewing is far quicker than authoring from scratch. It is not a shortcut on architecture, risk, or safety decisions, and we do not claim one. We scope where the gain is real rather than promising blanket speed.

Where do you draw the line on what AI does?

AI never makes a safety, architecture, or risk decision, never sets a software safety classification, and never signs off its own work. Those stay with experienced engineers. Reviewers also check specifically for the ways AI fails: plausible-but-wrong logic, hallucinated interfaces, and missing edge cases, not just style.

Is this the same as building AI into our device?

No, that is a different service. AI-assisted engineering is how we build *your* software. Putting an AI/ML algorithm inside your device, with a predetermined change control plan (PCCP) and good machine learning practice (GMLP), is our [AI/ML in medical devices](/services/ai-ml-medical-devices) work.

Services · Teams who want AI's speed on regulated software without risking the submission, and device companies that want their own engineers working this way

AI-Assisted Engineering

RND builds AI into its design and development workflow to shorten time to market and lower development cost on regulated medical device software. Every AI-assisted artifact, and the IEC 62304 and 21 CFR Part 11 records behind it, is reviewed by a seasoned engineer, traced into the design history file, and verified by our independent V&V team, so the quality and design-control rigor of an FDA submission stay intact. We can also bring your own team into AI-assisted engineering, adapting our process to your quality system.

Talk to us about governed AI delivery

IEC 62304ISO 1497121 CFR Part 11QMSR (21 CFR Part 820)ISO 13485:2016GAMP 5SOUP

AI-assisted developmentPull-request review gatesTraceability automationTool qualificationDesign history file

How does RND use AI on regulated device software?

AI speeds up the high-volume parts of the work: first drafts of requirements, code, tests, and documentation. RND runs it inside the same IEC 62304 lifecycle, ISO 14971 risk process, and quality system we use on every project. AI drafts; a seasoned engineer reviews, corrects, and approves; and our independent V&V team verifies the result.

How we treat the AI

This is the question a good QA or regulatory reviewer will ask, so here is the plain answer. We treat AI as an unvalidated development aid whose output is fully verified downstream, not a validated tool relied on unchecked. Under the QMSR (ISO 13485 clause 4.1.6) and IEC 62304, that distinction is what carries:

Every AI-drafted artifact is reviewed and approved by a seasoned engineer, then exercised by independent V&V (a separate team), the same as any project.
We record where and how AI was used, who reviewed it, and the tests that confirm it, in the design history file (DHF), with a 21 CFR Part 11 account of who did what.
Where a tool’s output is relied on directly (for example automated test execution), that tool is qualified for its intended use under GAMP 5 risk-based principles.

Because the output is always verified, the non-determinism of AI is handled the way any draft is: it is checked, not trusted.

Where AI moves fast, and where people stay in control

AI-assisted: first-draft requirements and tests · boilerplate and scaffolding · documentation drafts · traceability upkeep · refactoring suggestions.

Human-owned: architecture · software safety classification · ISO 14971 risk decisions · code and artifact review · final sign-off and the submission story.

AI never makes a safety, architecture, or risk decision. Reviewers check its output for the ways AI fails: plausible-but-wrong logic, hallucinated interfaces, and missing edge cases, not just style.

The process

Draft with AI. Starting from your inputs (a PRD, architecture, existing specs, or current code), AI generates first-pass requirements, code, and tests inside the IEC 62304 lifecycle.
Human reviews every artifact. A seasoned engineer reviews and approves everything generated (code, documentation, diagrams) through pull requests. Nothing merges without human review.
Traceability & DHF. Requirements, design, code, and tests stay linked in the design history file, with the 21 CFR Part 11 record intact.
Independent V&V. A separate team verifies the result.
Regulatory-ready delivery. The evidence a submission needs is generated by the work, not assembled at the end.

Can RND help our own team adopt AI-assisted engineering?

Yes. The process on this page is the one we run on our own projects: the review gates, the design history file records, and the line between what AI drafts and what people decide. We can adapt it to your quality system, tooling, and software safety class, then work alongside your engineers while they put it into practice. That typically covers:

Mapping where AI fits in your IEC 62304 lifecycle, and where it does not.
Updating your procedures so AI use, review, and sign-off are recorded under 21 CFR Part 11 and your ISO 13485 quality system.
Qualifying any tool whose output you rely on directly, using GAMP 5 risk-based principles, as ISO 13485 clause 4.1.6 requires (now part of the FDA’s QMSR).
Running the first project together, so your team owns the process afterward.

Where it pays off first: legacy remediation

The clearest, most provable place AI-assisted engineering earns its keep is legacy remediation: bringing older device software up to current expectations. It is exactly what AI is strongest at, reading and documenting an existing codebase, and exactly where the speed math holds up. On a typical engagement we:

Reconstruct requirements and design documentation from an undocumented codebase.
Rebuild traceability between existing code, tests, and the ISO 14971 risk file.
Generate the SOUP inventory and flag gaps against IEC 62304 and the QMSR.
Draft the missing design history file artifacts an auditor or an acquirer expects.

Every output is still reviewed and approved by a seasoned engineer and verified by independent V&V, but the first draft that used to take weeks of code archaeology arrives in days. It pairs directly with the legacy remediation in our Quality & Compliance practice.

What you get

Regulated software delivered with the pace AI enables and the evidence a submission requires, plus a clear, honest account of where AI helped and how every artifact was verified. Or, if you want your own engineers working this way, a documented process fitted to your quality system and a team that has already run it once. Built on our Application Accelerator foundation and paired with independent verification and validation.

25+: 25+ years in business
15+ yrs: Engineers average 15+ years of experience
2 teams · 1 QMS: Separate development and V&V teams under one quality system

One partner, end to end

Software built alongside the instrument.

RND writes and verifies the software. Gener8 designs and manufactures the instrument, cartridges, and consumables around it, mechanical, electronics, optics, and microfluidics, under one roof. Software, device, and disposables from a single partner.

Explore Gener8 capabilities

Frequently asked questions

Does AI-generated code and documentation hold up in an FDA submission?: Yes, because a qualified engineer reviews, verifies, and signs off on every AI-generated artifact, exactly as they would for hand-written work, and independent V&V exercises the result. What a reviewer evaluates is the evidence, and the evidence is identical whether an artifact was drafted by a person or by an AI aid: the IEC 62304 lifecycle, the verification records, and the 21 CFR Part 11 account of who did what.
How do you validate the AI tool itself?: We treat AI as an unvalidated development aid, not a validated tool that produces final work product on its own, and under the QMSR (ISO 13485 clause 4.1.6) and IEC 62304 that distinction is what matters. Because a seasoned engineer reviews and verifies every AI-generated artifact, and independent V&V confirms the result, the output is treated like any draft that must be checked, never relied on unverified. We record where and how AI was used, who reviewed it, and the tests that confirm it, in the design history file. Where a tool's output is relied on directly (for example, automated test execution), that tool is qualified for its intended use under GAMP 5 risk-based principles.
Is our code or IP exposed to AI models?: No. We use AI under enterprise agreements that keep your code and documents out of public model training, scope exactly what tooling touches your project with you before we start, and do not use AI on a project where your contracts prohibit it. Confidentiality is handled the same way it is for any regulated engagement.
How is this actually faster if a human reviews everything?: AI is fastest on the high-volume, mechanical work: first-draft requirements and tests, boilerplate, documentation drafts, and keeping traceability current. That is where reviewing is far quicker than authoring from scratch. It is not a shortcut on architecture, risk, or safety decisions, and we do not claim one. We scope where the gain is real rather than promising blanket speed.
Where do you draw the line on what AI does?: AI never makes a safety, architecture, or risk decision, never sets a software safety classification, and never signs off its own work. Those stay with experienced engineers. Reviewers also check specifically for the ways AI fails: plausible-but-wrong logic, hallucinated interfaces, and missing edge cases, not just style.
Is this the same as building AI into our device?: No, that is a different service. AI-assisted engineering is how we build *your* software. Putting an AI/ML algorithm inside your device, with a predetermined change control plan (PCCP) and good machine learning practice (GMLP), is our [AI/ML in medical devices](/services/ai-ml-medical-devices) work.

Last reviewed October 1, 2026.