Your security questionnaire still says human-in-the-loop.

The questionnaire arrived on a Tuesday. Row 14 asks whether AI-assisted code is reviewed by a human before merge. Someone on the security team typed “Yes.” That sentence has been in the policy since Copilot was autocomplete. The repo has not been that product for a year.

I am not writing another explainer of what an AI code audit covers — we already published the audit guide and which SKU to buy first. This is the questionnaire half of that conversation: why “human in the loop” is no longer evidence, what a buyer is actually asking, and why a process paragraph fails when they want a findings trail. If you need the residue itself — what Copilot, Cursor, and Claude Code actually leave in main — that is the production-repo piece.

The sentence that used to be true

Human-in-the-loop meant a person wrote most of the lines, an assistant filled a few, and a second person who had the system in their head read the diff. Volume was low. Familiarity was high. The checkbox matched the work.

Assistants inverted the volume. The author and the reviewer often use the same tool, so both have already seen a plausible version of the change. CI is green because the generated tests landed in the same pull request as the generated code. Nobody left a comment that says “AI wrote this,” because the tools do not leave a flag. They leave a repository that looks reviewed.

A policy that still says “a human reviews every AI-assisted change” is describing last year’s job. It is not describing the merge you shipped on Thursday. The commercial version of that gap is a point-in-time AI code audit — named engineer, written findings, read-only access, days rather than a quarter. Tool-specific search still has a landing: Copilot & Cursor code audit.

What the buyer is actually asking

Enterprise security questionnaires, SOC 2 fieldwork, and diligence rooms have stopped asking whether you use Copilot. They assume you do. The harder questions are the ones a checkbox cannot answer:

• Which tools are approved — Copilot, Cursor, Claude Code — and which are prohibited?
• How do you know a change was AI-assisted, if the tools do not label the diff?
• Who reviews those paths, at what seniority, before merge?
• What did they write down — a thumbs-up, or a severity-ranked finding?
• Can you attach that artifact to an email, from someone who does not also ship the same diffs?

“Human in the loop” answers none of those. It is a process claim. A buyer who has been through a real questionnaire wants evidence: who looked, at which paths, what they found, and what you fixed. Scanners are hygiene. They are not that packet. The free AI Code Risk Checklist is the self-serve version of the same gap.

A loop is not a control

Internal review of your own Copilot output is still review. It is necessary. It is not independent. The person who prompted the function is a poor sole witness to whether the authorization check matches the product’s tenant model. The reviewer who accepted the same assistant’s plausible version is not a second pair of eyes. Familiarity is not inspection.

Two other things make the loop look closed. Generated tests prove the function returns what it already returns, and they skip the abuse case the prompt never named. Coverage goes up. The critical path does not get safer. And comments that mention a BAA, a retention rule, or least privilege survive because they sound finished. A buyer will ask for the log, the retention, and the code path. If those three disagree, the document is the liability — including the questionnaire you just signed.

If the next question is where the remote lives, that is a different SKU: AI coding platform governance and the Cursor Origin checklist. If the next question is whether Claude Code may run unattended, that is the auto mode checklist and Claude Code governance. Mixing “who clicked approve” with “where source is hosted” and “who approved the bash” in one Slack thread is how all three get skipped.

What good evidence looks like

A control you can show a buyer is boring on purpose:

1. Tool inventory in writing — approved assistants, prohibited assistants, and where each may run.
2. A review bar that names seniority — not “the team reviews everything.” Who, on which paths, before merge.
3. Artifacts, not vibes — severity-ranked findings, overrides, and remediation, dated, attachable.
4. Independence when the stakes are high — a named senior engineer who does not also ship the same diffs. That is what an AI-generated code review or a full audit is for.
5. A snapshot before the date — fundraise, customer questionnaire, SOC 2 fieldwork, incident debrief. The policy paragraph is not the snapshot.

If you cannot produce (3) and (4) this week, you are not ready for the buyer who is about to look — regardless of how fast the team ships. Healthcare and PHI do not change that bar. They change the access model. Clinical product and BAA-capable architecture live at Maxiom Labs. Say PHI on the scoping call so nobody pretends a generic SaaS review is a healthcare engagement.

Hire vs DIY

Keep it internal when AI-assisted volume is small, senior reviewers already have capacity, and nobody is asking for an independent findings trail. Write the review bar down anyway. The next questionnaire will.

Buy a snapshot when a date is on the calendar, when leadership does not trust the last two quarters of “we review everything,” or when the questionnaire language still says human-in-the-loop and the repo does not. That is an AI code audit: fixed scope, client code in your environment, no third-party model on your source, written findings in 5–10 business days after read-only access.

Buy the retainer in the same conversation if you will keep merging assistant output after the date. The snapshot goes stale. That is AI code oversight, not a reason to skip the snapshot. Buy governed MCP only if the actual blocker is agents on CRM, EHR, or ERP. An audit of Copilot diffs will not authorize Claude against the system of record. Two questionnaires. Two engagements. If findings need to become controls in the product, that is compliance engineering — not a PDF in a shared drive.

FAQ: human-in-the-loop and Copilot questionnaires

Is “human in the loop” enough for a security questionnaire in 2026?

No. It is a process claim. Buyers ask who reviewed, at what seniority, on which paths, and what they wrote down. A checkbox that says “yes, a human reviews AI-assisted code” does not attach to an email.

We already require PR review. Why isn’t that the control?

Pull request review was built for a human writing fewer lines, more slowly. Assistants invert the volume. If the author and the reviewer use the same assistant, familiarity is not inspection. Internal review is necessary. It is not independent evidence.

Can we just attach scanner output to the questionnaire?

No. Run the scanner. Keep it in CI. Do not hand a green badge to a buyer as the review program. Scanners do not judge architecture against your roadmap or map a finding to the control the questionnaire named.

How do we prove which code was AI-assisted if the tools do not flag it?

You usually cannot, line by line. That is why a point-in-time senior review of the tree matters more than a perfect provenance log. Scope the paths that matter — auth, tenancy, PHI, payments, secrets — and inspect them as they exist, not as a policy hoped they were written.

Is this the same as a pentest?

No. A pentest hits a running system. This is source and design — including paths a pentest never exercises because the feature is behind a flag or the abuse case is a tenant boundary, not a CVE.

Will Maxiom run our repo through an AI reviewer?

No. Client code stays in client environments. Inspection is a named senior engineer. That is the product.

Do we have to stop using Copilot or Cursor?

No. You have to stop pretending last year’s human-in-the-loop paragraph describes a repo that merged a year of assistant output without an independent pass.

What if we have no questionnaire on the calendar?

Then you can wait, or you can use the free AI Code Risk Checklist tonight and decide whether the gap is real. Most teams who wait do it until a date appears. The date is a worse time to start looking.

If you want the snapshot written as an engineering artifact — not a slide — request an AI code audit or request a scoping call. Thirty minutes is enough to pick a scope, or to hear that we are not the fit.

I write from the seat of a working engineering company, not a tool vendor. More at antoniochagoury.com.