Do we have to disclose that AI wrote part of the code?

Your quality system governs how changes are reviewed, verified, and traced regardless of authorship. The obligations that matter - design controls, verification, and traceability - attach to the change, not to the tool that produced it. Check your own procedures, since some organizations have added authorship requirements of their own.

What is the biggest practical risk?

Review capacity. These tools raise the volume of proposed change far more than they raise the capacity to review it carefully, and unreviewed change is where defects enter.

Using AI Coding Assistants in a Regulated Codebase

The question I get asked is whether AI coding assistants are allowed in a regulated codebase. That is the wrong question, and it has a boring answer: your quality system governs how a change is reviewed, verified, and traced. It does not specify who typed it.

The useful question is what these tools break when you scale them up.

Review capacity is the bottleneck

An assistant can propose more change in an afternoon than a team can carefully review in a week. The constraint was never typing speed - it was the attention required to be confident a change is correct.

If review throughput does not rise with proposal throughput, the gap fills with code that nobody examined closely. In a regulated codebase, that is exactly the material your design controls exist to catch, arriving faster than the controls can process it.

The mitigation is unglamorous: keep changes small enough to review properly, and treat review capacity as the thing that sets your pace.

Provenance is a real question

These tools are trained on public code. A generated implementation may closely resemble something that carries a license, and your SBOM and third-party software controls exist precisely to answer "what is in this product and under what terms."

For a device submission, that matters. You are asserting what your software comprises. Code of uncertain provenance sits awkwardly against that assertion.

Practically: keep humans accountable for what enters the repository, and treat generated code that looks like a recognizable library implementation as something to check rather than assume.

Verification does not get easier

A generated test that passes tells you the code does what the generator thought it should. If the same tool wrote the implementation and the test, a shared misunderstanding produces a green build and a wrong device.

Requirements-derived tests are the point of verification in a regulated context. Those still trace back to a requirement written by a person who understood the clinical or operational intent.

Where they genuinely help

I use them heavily, including on regulated work, for the tasks where output is easy to verify: reading unfamiliar code, drafting documentation from a diff, mechanical refactors, exploring an approach before committing to it. Anywhere the cost of checking the answer is low, the leverage is real.

The trap is the opposite case - complex logic where the output looks plausible and checking it properly takes longer than writing it would have.