How to Document AI-Generated Code for a Regulatory Review

Last updated October 2026

To document AI-generated code for a regulatory review, capture five things for every change: the tool and model that helped write it, the human who owns it, proof that someone other than that owner reviewed it, the test and security scan results, and every dependency the assistant brought in. Store that evidence alongside the code for as long as your regulations demand.

What does a regulator actually want to see about AI-generated code?

Regulators and auditors aren’t interested in who typed a given line. What they want to know is whether a qualified, accountable person was in control of what shipped. Every framework a regulated product team runs into asks some form of the same four questions: who is responsible for this code, how was it reviewed, how was it tested, and can you trace it from requirement to release.

AI assistance leaves those questions unchanged. It just makes them harder to answer, since the usual evidence trail assumes the committer wrote the code. If a developer accepts 300 lines from an assistant, the commit still carries one human name and the review record still shows a second human signing off. Nothing in that record tells an auditor that neither of them wrote the logic from scratch.

You don’t need a new document type to fix this. You need three extra facts attached to evidence you already produce: which AI tool and model were involved, which human takes ownership, and a review done by someone other than that owner. PCI DSS v4.0.1 already covers part of this in requirement 6.2.3.1, which says that where manual code reviews are performed, code changes are reviewed by individuals other than the originating code author. Once an assistant is in the loop, count the developer who prompted and accepted the code as the author, which means the approving reviewer must be someone else.

What does it take to document AI-generated code for compliance?

These eight evidence items cover what reviews in HealthTech, FinServ, and logistics usually ask for. You can generate most of them from your repository and CI system instead of writing them by hand.

Evidence item	Where it lives	What the reviewer checks
AI coding policy	Policy repository or wiki, versioned	Approved tools and models, banned data (secrets, PHI, cardholder data), review rules for AI-assisted changes
Tool and model inventory	Config file or asset register	Every assistant in use, its model versions, data retention terms, and approval date
Commit attribution	Git commit trailers	Which changes were AI-assisted, with tool and model named
Human ownership	Commit sign-off and CODEOWNERS	A named person accountable for each AI-assisted change
Independent review	Pull request approvals	Approver is not the person who generated the change
Test and scan results	CI artifacts linked to the merge	Unit, integration, SAST, and secret scans ran and passed before release
Dependency record	SBOM per release	Every package the assistant introduced was verified, pinned, and approved
Exceptions log	Ticket system	Each accepted policy violation has a reason, an approver, and an expiry date

The two items teams skip most often are the inventory and the exceptions log. An inventory that only says “developers use Copilot” falls short; reviewers want the model versions and the vendor terms that control what happens to your code. The exceptions log is what makes everything else believable. A process that records zero exceptions across a full year looks like a process no one checks.

How should commits record AI assistance?

Record AI assistance with a structured commit trailer rather than a free-text comment. The Linux kernel has already worked this out for one of the most closely examined codebases anywhere. Its coding assistants policy in the kernel documentation asks contributors to add a tag in the form Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2], and it says AI agents must not add Signed-off-by tags, because only a human can certify the Developer Certificate of Origin. The human submitter reviews the AI-generated code and takes full responsibility for it.

Splitting it that way, with the machine credited and a human certifying, gives a regulatory reviewer exactly what they need. You can adapt it in three steps:

Put the trailer in your commit template and add a matching checkbox to the pull request template, so disclosure happens by default instead of as an extra step.
Make every AI-assisted commit carry a human sign-off trailer from the person who takes ownership.
Enforce the rule in CI. A merge check fails if an AI-assisted pull request has no independent approver, or if the approver is the same person who signed off the change.

Since the trailers live as plain text in git history, a single git log query can list every AI-assisted change in a release. That list is the heart of the evidence pack.

Is AI-generated code SOUP under IEC 62304?

In most cases it isn’t, and getting it wrong puts the paperwork in the wrong place. As the Johner Institute explains in its guide to OTS versus SOUP, IEC 62304 defines SOUP as a software item that is already developed and generally available and was not developed for incorporation into the medical device, or one for which adequate records of the development process are not available. Code that an assistant writes into your repository was built for your device, which makes it your software. It runs through your full lifecycle: requirements, architecture, unit verification, and the safety class rules for whatever item it sits in.

Dependencies are another matter. When an assistant proposes a third-party package, that package counts as SOUP or OTS and needs an entry of its own: name, version, manufacturer, requirements, and a way to follow its known anomalies after release. Assistants also propose packages that don’t exist, or that someone registered to take advantage of that habit, which we cover in hallucinated dependencies. Your SOUP list is where that risk gets caught.

How long must AI-generated code compliance records be kept?

Keep them for as long as the strictest rule that applies to the product. These are the usual minimums for teams selling into regulated markets:

HIPAA: required Security Rule documentation has to be kept for six years from its creation or last effective date, under 45 CFR 164.316(b)(2). If your AI coding policy and review records support your security program, they’re covered by this.
EU AI Act, high-risk systems: Article 18 of the EU AI Act says providers must keep technical documentation and quality management system documentation available to authorities for 10 years after the system is placed on the market. That page shows it applying from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems.
Your own contracts: enterprise customers in finance and health often write retention into the master services agreement. Read it, since it’s often longer than the regulation.

For the practice baseline, as opposed to the retention period, point reviewers to NIST SP 800-218A, the Secure Software Development Framework community profile for generative AI, published in July 2024. Mapping your AI coding controls to SSDF practices hands an auditor a recognized reference rather than a checklist you made up yourself.

How do you build the evidence pack for code that already shipped?

Most teams only start documenting once a review is on the calendar, with months of undisclosed AI-assisted code already running in production. Prompts nobody saved can’t be reconstructed, so don’t pretend otherwise. Here’s what to do instead:

Pick a cutoff date. Disclosure, sign-off, and CI enforcement cover every change from that date on.
Write a historical use statement. Using tool licenses and expense records, state which assistants were in use before the cutoff, and note that attribution wasn’t recorded.
Sort the legacy code by risk. Authentication, authorization, payment flows, PHI handling, and audit logging go first.
Have an independent senior reviewer re-review the high-risk modules, and record the findings as though they were new changes.
Rebuild the SBOM and confirm that every dependency exists, is pinned, and is really the package you believe it is.
Record the gaps you accept in the exceptions log, each with an owner and a date.

An honest statement backed by a remediation plan stands up better than a rebuilt trail that collapses after one follow-up question. Our article on SOC 2 and AI-generated code walks through the questions that tend to come next.

What do teams get wrong when they document AI-generated code?

Saving prompts instead of decisions. Prompt transcripts are bulky, can hold secrets or regulated data, and seldom answer an auditor’s question. The commit, the review, and the test result do.
Making disclosure optional. When the trailer relies on someone remembering, coverage slips and the record stops being useful. Let the template and the CI check carry the load.
Allowing the prompter to approve. When someone approves their own AI output, the independent review the whole record relies on disappears, and a CI rule stops it.
Mixing up product AI and coding AI. Documentation for an AI feature, like the decision records in our guide to audit trails for AI decisions, is not the same as documentation of how the code was written. More and more reviews ask for both.

For the complete control set around regulated health data, read our pillar on HIPAA-compliant software development.

Who should do the independent review?

Pick someone who can catch what an assistant gets wrong: missing authorization checks, swallowed errors, and code that looks right but ignores your data handling rules. That depends more on experience than on tooling. The engineers behind TopDevz reviews average 10+ years of experience, and our $4,950 Rescue Audit delivers a findings register you can give straight to an auditor, with the fee credited toward remediation if you have us fix what it turns up.

Frequently asked questions

Do regulators require you to disclose AI-generated code?

Very few rules mention AI-generated code by name. What they demand is accountable ownership, independent review, testing, and traceability for all code. Disclosing AI assistance in commits is the easiest way to show those controls also covered the changes AI wrote.

Should we store the prompts used to generate code?

Not as primary evidence, in most cases. Prompts can hold secrets or regulated data and seldom answer an auditor’s question. For each change, record the tool, model, human owner, independent reviewer, and test results instead.

Is AI-generated code considered SOUP under IEC 62304?

Generally, no. SOUP is software that’s already developed, generally available, and not built for your device. Code generated into your repository is your own software and goes through your full lifecycle. Third-party packages an assistant suggests do count as SOUP and need their own entries.

How long should AI coding records be retained?

Keep them for the longest period any applicable rule sets: six years for HIPAA Security Rule documentation, and 10 years for technical documentation of high-risk AI systems under Article 18 of the EU AI Act. Customer contracts may ask for longer.

Book a Code Review

If a regulatory review is coming up and your repository holds months of undisclosed AI-assisted code, learn what an auditor will find before they find it. A senior review of your high-risk modules, dependencies, and review history turns that into a dated list of gaps. Book a Code Review.