SOC 2, Security Questionnaires and AI-Written Code

A customer's security questionnaire arrives. Somewhere in it, next to the familiar questions about encryption at rest and sub-processors, is a newer one: what is your retention policy for prompts sent to AI coding tools, and can you produce the record. Your change-management narrative says code changes are reviewed prior to merge. It does not say what fraction of the diff was written by a model, what the model was asked for, or what review depth actually applied to that part.

This article is about the gap between those two documents: what is genuinely required today, what is merely being asked, and what is not required at all despite a great deal of writing implying otherwise.

Start with what is not required

The EU AI Act is invoked constantly in this context and mostly incorrectly. Its main high-risk framework became enforceable on 2 August 2026, which is why it is in every vendor deck. But ordinary AI coding assistance does not fall under it. Annex III enumerates specific high-risk uses — biometrics, critical infrastructure, employment decisions, essential services — and a developer using a model to write a function is not among them. Standard code-completion tooling is generally treated as limited-risk, which engages transparency obligations under Article 50 rather than the Articles 8-15 conformity regime.

If a vendor tells you the AI Act requires you to log your developers' prompts, they are selling, not advising. It does not.

There is one way to bring AI development tooling inside the high-risk regime, and it is worth knowing precisely because it is a trap: use it to evaluate people.

Annex III covers AI used in employment contexts — including systems that evaluate worker performance or allocate tasks. A dashboard that measures which engineers produce the most AI-assisted output, ranks them, or feeds performance review is an employment-context system, and the obligations that attach to it are substantial. This is the single most important thing an engineering leader can understand before rolling out any AI-usage visibility: a record kept so the team can understand its own work is one thing, and a record kept to grade individuals is a different regulated category. Decide which one you are building, write it down, and make sure the tooling you choose is not quietly the second.

Now what is actually being asked

The real pressure is not regulatory. It is commercial, and it arrives through procurement. Vendor risk teams have added AI-specific sections to their questionnaires, and they now ask for things like model versioning policies, prompt logging and retention, training-data lineage, and the sub-processor chain behind any LLM provider you use. These are not statutes. They are the price of closing an enterprise deal, and they are harder to argue with than a regulation because there is no interpretation to debate — the buyer either accepts your answer or does not.

The answer most engineering organisations can give today is that prompts are not retained, are stored on individual laptops, and are deleted automatically after thirty days by a default nobody set. That is an honest answer and it is a weak one.

The change-management gap

SOC 2 does not contain an AI clause. What it contains is a change-management expectation that predates all of this: changes should be authorised, documented, tested and approved before they reach production. That framing assumed a person decided to make each change.

Most control narratives resolve this with a single sentence — code changes are reviewed prior to merge — and stop. Auditors have started reading past it. The follow-up questions are the uncomfortable ones: how much of the merged diff was model-authored, was the reviewer aware of that, and did review depth differ. If the honest answer to the first question is that nobody records it, the control is not evidenced; it is asserted.

The reason this is getting attention rather than being waved through is the defect rate. Veracode's March 2026 analysis across more than 150 models found that 45% of AI-generated samples introduced at least one OWASP Top 10 vulnerability. Whatever one thinks of the exact figure, a reviewer who does not know which lines came from a model is reviewing the higher-risk half of the diff with the same attention as the rest.

What evidence actually looks like

Evidence is not a policy document saying prompts are retained. It is the retained prompts, tied to what they produced, retrievable months later by someone who was not there. Concretely, an organisation that can answer these questions is in a materially different position from one that cannot:

• For a given merged change, which parts were model-authored and what was the model asked to do.
• For a given incident, which AI session introduced the failing code, and what constraint was stated at the time.
• For a given retention question, where the prompts live, who can read them, and how long they are kept — with a setting somebody deliberately chose rather than a default nobody saw.
• For a given departing engineer, whether the record of their AI-assisted work survives their laptop.

None of that requires a product. It requires that the record exists somewhere other than an individual machine, and that somebody decided how long it is kept. A team can get most of the way there by setting retention explicitly on every developer's machine and backing up the history directories — which is worth doing today regardless of what else you conclude, because the deletion runs whether or not anyone is watching.

Where that approach stops is the part procurement asks about: it is per-machine, applied by whoever happened to read the instructions, invisible to anyone but the person whose laptop it is, and impossible to show to an auditor as a functioning control.

A reasonable position to take

Overreacting to this is as expensive as ignoring it. A sensible posture for most engineering organisations in 2026 has four parts, and only the last one involves buying anything.

First, decide and write down what the record is for. Understanding and reconstructing work, not evaluating people — and if it is ever going to be the second, treat that as the regulated decision it is.

Second, set retention deliberately on the tools in use, rather than inheriting a default. This is a one-line change per machine and it removes the deadline.

Third, answer the questionnaire honestly. If prompts are not currently retained, say so, and say what you are changing. Procurement teams are considerably more forgiving of a clear gap with a date on it than of a vague claim that turns out to be unsupported.

Fourth, if the record genuinely matters for your review, incident and audit workflows, move it off individual laptops into something the team holds. That is the problem PromptWake was built for — it captures the prompt, the response and the resulting diff from the tools your team already uses, keeps them locally by default, and syncs them into one searchable, access-controlled timeline on the paid tiers. It is deliberately not an employee-monitoring product, and for the reason set out above, you should be wary of any tool in this space that is comfortable being used as one.