On a security questionnaire, name the AI coding tools your engineers use and the paid plan each runs on, say customer data never goes into them, and say agents act only with human approval. Source code does reach the vendor, and on those plans the vendors say they don't train on it. We'd make all three claims true first, then answer each row with one sentence and one document.
What is the customer really asking?
Two questions hide in the AI section. One is about AI inside your product. The other is about AI used to build it, and that's the one a software team gets when the customer's reviewer has noticed that your engineers use Copilot or Claude Code.
Behind both sits one concern: whose data goes where, and who or what can act on their systems. They don't care that you use AI. They care whether it widens who can see their data.
Some buyers send a standard form, such as the Cloud Security Alliance's AI extension of its CAIQ. Ask the customer's security contact which form they're using before you start, and ask for their approved AI vendor list if they have one. Their list is the test a named tool has to meet.
Does customer data go to an AI vendor?
This is the row that decides the rest, and the answer you want to give is "no, by rule." Source code and prompts go to the vendor. Customer data should not: no production exports in prompts, no real records pasted into a chat to reproduce a bug.
The rule matters because of what a "yes" costs. If an AI vendor receives your customers' personal data, it will usually be processing it on your behalf, which puts it on your sub-processor list under a data processing agreement. The EDPB's Opinion 22/2024 says controllers should have the identity of all processors and sub-processors readily available at all times, so a reviewer can fairly ask for that list.
If you don't have a data processing agreement in place yet, start with what a data processing agreement must contain. The list format is in answering the contractor rows of a security questionnaire. For the wider GDPR picture on EU engineers, read the legal requirements for hiring developers in Europe.
Attach the written data rule and your sub-processor list, with a date on both. If the list has no AI vendor on it, the rule has to be true, so tell your engineers before you tell the customer.
Do the AI vendors train on our code?
The honest answer depends on the plan, not the product. As of 1 November 2026, the three vendors split like this.
Anthropic's Claude Code documentation draws the line at the plan. On commercial terms (Team, Enterprise, API) it doesn't train on code or prompts unless the customer chooses to share them. On consumer plans (Free, Pro, Max, Ultra) it trains when the setting is on, Claude Code included.
For Copilot, GitHub's announcement says that from 24 April 2026, data from Copilot Free, Pro and Pro+ trains models unless the user opts out. Business and Enterprise users aren't affected. Cursor's security page says that with Privacy Mode enabled it won't train on your data, and a team or enterprise admin can enable it for the team.
So your answer is only as true as the seat people actually use. One engineer on a personal Copilot Pro account makes "we don't train on your code" false. That's why the answer should name plans and the evidence should be the seat list.
Reviewers also ask about retention. In that row, write 30 days for Claude's commercial plans; qualified Enterprise accounts can get zero data retention, set per organisation. For Cursor, don't write a number. Its page states no retention period, so get one from Cursor in writing before you promise anything.
Can an AI agent change code or reach production?
Your answer: agents propose, humans approve, and secrets are off limits. For Claude Code, the permissions documentation backs this up. File edits and most shell commands ask for approval by default, while reading inside the working directory doesn't. A deny rule such as Read(./.env) blocks Claude's file tools from reading that file; add sandboxing so shell commands can't read it either. Sandboxed commands run without a prompt by default, so keep your approval rule for commands that leave the sandbox.
The part a reviewer will want to hear is that settings can't be quietly changed. Managed settings that an administrator deploys can't be overridden by user, project or command-line settings. Setting permissions.disableBypassPermissionsMode to "disable" turns off bypass mode. Attach the managed settings your administrator deploys, with those rules in it. It's a better exhibit than any paragraph about intent.
We'd add one claim: agents get no production credentials. If an agent can't reach production, the question of what it might do there goes away.
What do we say about contractors using AI?
Say that contractors use the same company-paid seats under the same rules as employees, and that the approved tools are named in the contract. No personal accounts, for the same training reason as above. Attach the contract clause and the contractor's line in the seat list, so the reviewer sees a seat you administer.
The rest of the contractor contract (IP, confidentiality, data protection) is covered in EU engineering hiring compliance: contracts, IP and GDPR.
A worked example: answering six rows
Take an illustrative 25-engineer SaaS company with four contractors, all on Copilot Business and Claude Team. This is what it would send.
| Customer asks | Short answer | Attach |
|---|---|---|
| Which AI coding tools do engineers use? | Copilot Business and Claude Team, company seats only. | Seat list from each admin console |
| Is our data used for training? | Not on these plans. | Vendor data-usage pages, dated |
| Does our data go to AI vendors? | No. Customer data stays out of prompts. | Data rule, dated sub-processor list |
| Can agents act without approval? | No. Edits and commands need approval; .env reads denied. | Managed settings file |
| Do contractors use AI? | Same company seats and rules, named in the contract. | Contract clause, seat list |
| How is AI-written code reviewed? | Same pull request review as any other code. | Branch protection settings |
Every answer is one sentence, and every one points at a document you can produce in minutes.
If a row isn't true yet, say "not yet, due on this date" instead of rounding up. A dated plan reads better than a claim that falls apart when the reviewer asks for the export.
What this means for your next review
You have one decision before the review closes: which seats and settings to lock down, and what to promise. Do three things first. Move every engineer and contractor onto a company seat on a plan that doesn't train on code. Write the customer-data rule and send it to the team. Then collect the managed settings file and an up-to-date sub-processor list.
Do it in that order, because the answers are only as good as the weakest seat. A promise you can't evidence is worse than a gap you've dated.
The policy these answers rest on is the next thing to write if you haven't: start from our AI acceptable use policy for engineering teams.
FAQ
Do we have to name our AI coding tools?
Yes, if the question asks, and naming the plan matters as much as the product. "We use Copilot" says nothing about training; "Copilot Business on company seats" does. A vague answer invites a follow-up, and naming the tools shows you know where your code goes.
Is an AI coding vendor a sub-processor?
It is one when customer personal data reaches it and you process that data for the customer. If your rule keeps customer data out of prompts, the vendor shouldn't be a sub-processor for that data. It still sees source code, and your rule is what keeps personal data out of it.
Can we answer without SOC 2 or ISO 42001?
You can answer the questionnaire without either. Whether a customer requires a report is their call. We'd start with the rule, the seat list and the settings. A report helps when you have one, and our piece on SOC 2 Type 1 vs Type 2 explains what each gives you.
Do contractors' personal AI accounts count?
They count against you. A personal plan can train on code the contractor touches, and you can't show a reviewer a seat you don't administer. Require company-paid seats and name the approved tools in the contract.
How often should we update the answers?
Whenever a tool, plan or setting changes, and at least before each new review. Vendor terms move, so re-read the data-usage pages each time and date the attachments. An answer sheet with a stale date undermines the evidence behind it.