What an auditor will actually ask about AI-written code

The preparation I keep seeing is a document. It has a title like AI Usage Policy, it lists approved tools, it has a section on prohibited data, it has been reviewed by legal, and somebody is proud of it. It took two months.

It will be read in about ninety seconds and it will not change a single finding.

My position: an auditor is not going to interrogate your relationship with AI. They are going to ask the same four things they have asked for twenty years, and the only relevant question is which of your standard answers quietly stopped being true. Preparing a new framework is effort spent in the wrong place. I am not a lawyer and none of this is legal advice.

What the questions have always been

Strip any change management audit down and it is testing four assertions. Everything else is sampling and evidence.

Authorisation. This change happened because an accountable person decided it should. There is a record of that decision that predates the change.

Independent review. Someone other than the author, competent to judge it, examined it and approved it. Competence and independence are both load-bearing.

Segregation of duties. The person who made the change did not unilaterally approve and release it.

A complete, contemporaneous record. What is written down was written at the time, covers all changes rather than a convenient subset, and has not been altered since.

None of these mention tooling and none of them need to. An auditor testing them will pick four or five changes, follow each one end to end, and see whether the assertions hold. Your policy document is not part of that test.

Which assertion actually broke

Here is the useful exercise, and it takes an afternoon rather than two months.

The answer you have been giving

• The ticket authorises the change
• A named engineer authored it
• A second engineer reviewed and approved it
• Author and approver are different people
• The record is the pull request history

What a sample will now show

• The ticket says "improve error handling" and settles nothing
• The committer is a shared service identity
• Approval arrived in four minutes on eighty files
• The approver is the person who ran the agent
• History was squashed, so the sequence is gone

Independent review is where most organisations are most exposed, and the exposure is quantifiable. LinearB’s 2026 benchmarks put pull requests merged with zero review up over 31 percent, with median review duration up more than 400 percent on the ones that are reviewed. An auditor does not need those benchmarks. They need your merge data, and the arithmetic is the same.

Segregation of duties is the subtler one. When an engineer directs an agent to produce a change and then approves it, the letter of the control is satisfied, since the committer identity and the approver identity differ. The substance is not, because one human made every decision. That gap is exactly the sort of thing an experienced auditor finds by asking who told the agent what to do, and most pipelines cannot answer.

The one genuinely new question

There is one question that is actually about AI, and it is the one nobody prepares for.

“How do you know which of your changes were produced this way?”

It sounds procedural and it is not. It is testing whether your controls have a defined population. Every assertion above is meaningless if the set of changes it covers cannot be established. If some agent activity runs through a governed pipeline and some runs from engineers’ laptops with no marking at all, then you cannot state what proportion of production your controls actually cover, and an auditor who works that out will discount everything else you showed them.

Two related expectations sit underneath this. Transparency obligations in the EU AI Act point toward AI systems disclosing themselves and generated content being marked. And there is a notable gap in the tooling landscape: native provenance attribution exists for generated images, with no documented equivalent for generated code. So the marking, for now, is something your organisation has to construct rather than something you inherit from a format.

Being unable to answer this question is not a compliance failure in itself. It is worse than that operationally: it means you cannot tell your own leadership what share of your codebase arrived through a path nobody inspected.

Preparing properly, in a quarter

Sample yourself firstPull ten changes from the last quarter at random. Follow each end to end against the four assertions. Write down where each one fails before anyone external does.

Establish the populationDecide how a change is marked as agent-assisted, apply it at the point the change is created, and make the unmarked path harder than the marked one.

Fix substance, not wordingWhere review is nominal, change what triggers it rather than the policy describing it. Route by blast radius so the attention lands somewhere real.

Record the human decisionCapture who directed the work and on what authority, separately from which identity committed it. This is what restores segregation of duties.

If you do write the policy, write it last and write it to describe what your pipeline actually does. A policy that describes controls you do not operate converts a control gap into a documented control gap, which is a materially worse finding.

Where this breaks down

Some auditors will ask about the model. Data residency, whether code left the organisation, what the vendor retains, whether customer data reached a third party. Those are real questions with real answers required, and my framing underweights them. They are usually asked by a security reviewer rather than a change management auditor, and preparing for one does not prepare you for the other.

The policy document is not worthless. It is genuinely useful for setting expectations internally and for answering customer security questionnaires, which arrive far more often than audits do. My objection is to it being the whole preparation, not to its existence.

Self-sampling is easy to do badly. Ten changes chosen by the person who wants to pass will not be random, and following your own trail is much easier than following a stranger’s because you fill gaps from memory without noticing. If you can get someone from another team to run it, the exercise is worth several times more.

Marking agent involvement is harder than one line makes it sound. Mixed authorship is the normal case: an agent drafts, a human rewrites half of it, a second agent reformats. Any binary marking is a simplification, and a scheme that pretends otherwise will produce records that are precise and wrong. Start with something coarse and honest rather than fine and fictional.

And nobody has done this at scale yet. Enforcement of the AI Act began in August 2026, most audit cycles have not yet run against a codebase with 41 percent AI-generated content, and I am reasoning from what these controls have always tested rather than from a body of completed findings. If your experience differs, weight it above mine.

The takeaway

An audit will not be about AI. It will be four assertions about authorisation, independent review, segregation of duties and the record, tested against a handful of real changes, exactly as it always was.

What changed is that several of your standard answers are now supported by mechanisms that no longer support them. Find that out yourself, on your own sample, before someone else finds it out on theirs.

If you take one thing into next week: pick five changes from last quarter at random and try to name, for each one, the human being who is accountable for the decision that it should exist. Where you cannot, you have found the finding.