AI vendor data handling: what to ask
Stefan-Iulian Tesoi · · 6 min read
Five things: what is sent, who else receives it, how long it is kept, whether it trains a model, and what happens when you cancel. Ask for each as written policy rather than as an assurance on a call, because a call is not a document anyone can be held to afterwards.
AI vendor data handling is unusually easy to evaluate badly, because every vendor has a confident answer to all five and only some of them have written any of it down. The difference is not in the answers. It is in whether the answers exist somewhere you could point at in a year.
Which AI vendor data handling questions actually matter?
Five, and each has a shape of answer that means the vendor has thought about it.
- What exactly is sent, and when? Not "your data" — which fields, at which moment. "Backlog content and your messages, at the moment a request is made" is an answer. "Data necessary to provide the service" is a category.
- Who else receives it? A named list, not "industry-standard providers". Every model provider, every host, every analytics tool.
- How long is it kept? Data retention stated per kind of data, with numbers. One period covering everything usually means nobody has looked.
- Does it train a model? Ask about model training of the vendor and of everyone on their list, because the answers differ and only the first is theirs to give.
- What happens when we cancel? What is deleted, when, and what survives in backups.
The fourth is the one most AI vendor security questionnaire templates get wrong. They ask the vendor whether it trains on your data, get a no, and stop — but the vendor is usually not the one running the model.
"We do not train on your content" and "nobody trains on your content" are different sentences. The first is a promise the vendor can keep. The second depends on terms they did not write.
Laimonade's own privacy policy states the first: it does not train any model on your content, and does not use one customer's content to answer another's. It also says plainly that what each provider does with an API request is governed by that provider's own terms and the data-processing agreement with them. That second sentence is the one worth insisting every vendor writes down, because its absence is where does my data train their model quietly stops being answerable.
Why does written policy beat a reassuring call?
Because the person reassuring you is not the person who will be there when it matters, and because the law already expects it in writing.
Article 28 of the GDPR requires processing by a processor to be governed by a contract setting out the subject matter, duration, nature and purpose, the type of personal data, and the obligations of both parties — the article text is short and worth reading once. Engaging another processor requires the controller's authorisation, which is what turns a subprocessor list from marketing into an obligation.
The practical version is narrower. A call produces a shared memory that both sides recall differently within a quarter. A policy page produces a URL with a date on it, and a vendor who changes it has to change it in public. When you ask for something in writing you are not doubting the person; you are removing them from the loop.
How do you read a subprocessor list?
Look at what each row tells you, then at how the list is maintained. Both matter, and the second is invisible unless you ask.
| A row should name | Why it matters |
|---|---|
| The provider | You may already have a relationship, or a prohibition |
| Its purpose | "Analytics" and "model provider" carry different risk |
| What data it receives | The only field that bounds the exposure |
| Whether it is required | A list with optional entries lets you reduce the surface |
Laimonade's list runs to fourteen entries and names all four for each. That is worth stating not because fourteen is a good number but because a subprocessor list with no per-entry detail is a list of logos.
The maintenance question is the better one: is the list written by hand, or derived? A hand-maintained list is accurate on the day it is written. Laimonade's is checked on every build against the backend's actual outbound calls, so a new destination added in code fails the build until it appears in the policy. Ask a vendor how their list is kept current, and listen for whether the answer describes a process or a person's diligence.
What connects to what is in integrations, and what the contract says is in the terms.
Which answers should end the evaluation?
Four, and none of them is a judgement call about risk appetite. Each one means the question cannot be answered at all.
- "We don't store your data." Almost never true, and when it is, retention has been confused with persistence. Ask what the retention table says and watch whether one exists.
- "It's encrypted." An answer to a different question. Encryption at rest says nothing about who is sent it, for how long, or what they do with it.
- "We can't disclose our providers." The subprocessor list is a controller's entitlement, not a courtesy. A vendor treating it as commercially sensitive is telling you they have not prepared for a real review.
- "Deletion is handled on request." Without a stated timeframe and a statement about backups, this is a support ticket rather than a policy.
The honest counterweight: none of this is unique to AI vendors, and a coding agent connected to your backlog is not obviously riskier than the CI system that already holds deploy credentials. What is different is that the data flowing to an AI vendor is unstructured content rather than a scoped API call — backlog items contain customer names, revenue notes and unannounced plans — and the providers behind it change more often than infrastructure does. Judge the connection by what it can reach, which is the subject of coding agent security.
Frequently asked questions
Does our code get used to train models?
Ask twice: once of the vendor, once of every provider on their subprocessor list. A vendor can commit not to train on your content and usually does; what happens inside a model provider's API is governed by that provider's terms and by the data-processing agreement between them. Get both answers in writing, because only the first one is the vendor's to give.
What happens to our data if we cancel?
It should be stated per kind of data, with periods. Project content that lives until you delete it or close the account is a different commitment from logs kept thirty days and usage records kept ninety, and a policy that gives one number for everything has not been thought through. Ask specifically about backups, which is where most policies go quiet.
Is a SOC 2 report enough on its own?
No. A SOC 2 attests that controls the vendor chose were operating as described over a period; it does not tell you which providers receive your content or how long it is kept. It is good evidence that a process exists and poor evidence about the specific questions above. Read the report's scope section before treating it as an answer.
Should a small team bother with any of this?
Yes, and it is quicker than it sounds. Four of the five questions are answered by reading two pages the vendor already published, and the fifth is one email. The point is not to run a procurement process; it is to find out before connecting anything whether the answers exist in a form you could show somebody later.