Data compliance for AI coding tools:
the questions to ask before you buy
Sort your data into 3 classes first — source, secrets, customer data — then put 5 questions to the vendor that belong in the contract. Only 2 of them can be verified by you; the rest rest on written terms, and a verbal assurance is worth nothing at audit.
Four numbers to settle first
Classify your data
The source itself, the secrets embedded in it, and any customer data it carries — three very different sensitivities and remedies.
That belong in the contract
Where data sits, how long it is kept, whether it trains anything, who can read it, and how fast you are told after an incident. Each one missing is a blank at audit.
You can verify yourself
Which endpoint requests actually reach (client config or a packet capture) and whether transport is TLS end to end. Everything else rests on terms.
Written basis
Only something in writing can be shown to legal and audit. What a salesperson said and what a community thread claims are not a basis.
AI coding compliance is not ordinary SaaS compliance
With ordinary SaaS you upload business data. With AI coding you upload the source itself, often whole files and directory structures. Worse, source tends to carry other things along with it: hard-coded keys, connection strings, real customer records used in tests, internal hostnames. Once those travel out with the context, the exposure is no longer just "someone saw our code". So the first step is not to question the vendor — it is to find out what is actually in your repository.
The five things to establish before buying
① Which jurisdiction the data sits in and whether it crosses borders. ② How long requests and responses are retained and whether that can be switched off. ③ Whether any of it feeds model training or evaluation. ④ Who inside the vendor can read it and under what conditions. ⑤ How quickly, and to whom, you are notified after an incident. Get all five in writing — terms of service, a data processing addendum or the contract itself all count, as long as it is a document you can hand to legal. Anything answered only verbally should be treated as a blank.
Three steps, in this order
Look inward first: scan the repositories you intend to connect and remove hard-coded secrets, real customer records and internal hostnames. The benefit here is independent of which vendor you pick, and it is the only part of the chain fully under your control.
Then look outward: send the five questions to your candidates and require written answers. In parallel, verify the two things you can — which endpoint requests actually reach, and whether transport is encrypted end to end.
Finally, get it on paper: retention period, training use and notification window go into the contract or DPA. If a vendor can only offer "we generally do not", assess the risk as though they do.
What you can verify vs what rests on terms
You can verify this
① Where the endpoint in your client config points (environment variables, config files or a packet capture will show it). ② Whether transport is TLS end to end. ③ Whether the model echoed in the response is the one you requested. ④ Whether the billing basis reconciles with usage. These are technical facts — one test settles them.
This rests on terms only
① Which jurisdiction the data physically sits in. ② How long it is actually kept and how it is deleted. ③ Whether it enters a training or evaluation set. ④ How internal access is partitioned. ⑤ Who it is subprocessed to. None of this is observable from the client side — treat them as contract questions rather than hoping to measure them.
Buying direct vs through a reseller or gateway
Buying the vendor's own service
The shortest chain of terms and an unambiguous counterparty; enterprise tiers usually offer a DPA, audit logs and retention controls. The cost is admission — region, seats, contract minimums — plus settlement and invoicing formats that may not match what your finance function needs.
Through a reseller or your own gateway
This solves admission and settlement at the price of one more hop: your requests pass through a third party. The evaluation therefore becomes "what does that layer do, what does it keep, and where is that written down". Note that a reseller is not the vendor's official channel and cannot commit on the vendor's behalf — the upstream terms still apply to you.
Phrase the questions so they can be answered
Do not ask "are you secure". Ask questions that take a yes or no and can go into a contract: "How many days are request and response bodies retained?" "Which roles can access them during that period?" "Are they used for any form of model training or evaluation?" "Which jurisdictions does the data sit in?" "What is the notification window, in hours, after a security incident?" Archive the answers with their date. If the vendor's position later shifts, you at least have a baseline.
On QCode — only what can be verified
We are a resale platform for multiple model APIs: your requests are ultimately served by the official APIs of Anthropic, OpenAI, Google and others. We do not train our own models and we do not train on your requests. Billing follows the usage block in the response and the bill can be reconciled line by line. The security note on our /enterprise page states in writing that we do not store user code, conversation content or business data, that requests are forwarded transparently to the upstream API, and that no data is cached in between — the "cache benefit" on the pricing page refers to the upstream vendors' own prompt-caching discount, not to storage on our side. That is a written statement you can hand to legal. We are not an official channel for any upstream vendor and cannot commit on their behalf — their terms of service still apply to you. Retention and access provisions are governed by our terms of service; if enterprise procurement needs something in writing, raise it during commercial discussion.
FAQ
Will my source be used to train a model?
It depends on the path your traffic takes and the terms attached to it. This is not a question a test can answer — get a written statement from every party in the chain. For our own part: we do not train our own models and we do not train on your requests; each upstream vendor's policy is governed by its own terms.
How do I confirm requests really reach the endpoint I think they do?
Read the endpoint variable in your client configuration and, if needed, capture the traffic once. This is one of the few facts you can settle yourself. If the model echoed back carries a prefix or provider name that was not in your request, a rewriting layer sits in between and is worth asking about.
What is the single most useful thing to do first?
Scan the repositories you plan to connect and remove hard-coded secrets, real customer data and internal hostnames. The benefit is independent of vendor choice, and it is the only link in the chain entirely under your control.
The vendor says "we do not store data". Is that enough?
No. Get written terms stating the retention period, how data is disposed of at expiry, and what scope that covers. A verbal assurance is not a basis at audit, and "we generally do not" should be risk-assessed as though they do.
Can a reseller give compliance commitments on the vendor's behalf?
No. A reseller can only commit to what its own layer does and keeps. Upstream terms still apply to the end user, and any claim of being "authorised to commit on the vendor's behalf" deserves a request for the document that says so.
How do we make this stick in a team rather than stay a policy document?
Three concrete things: ① add secret scanning to CI so new hard-coded credentials cannot land; ② issue a separate API key per person and per pipeline so an incident traces to a source; ③ put the retention period and notification window into the purchase contract rather than leaving them in an email thread.
Sources
This page is a buyer-side question list and does not restate any vendor's specific figures — retention, training use and access control at each vendor are governed by their own terms of service and data processing addenda, and change over time. Statements about QCode itself (resale positioning, no own models, billing basis) come from our terms of service and pricing page (checked 2026-09-02).
Clean the repository before you shortlist vendors
Secret scanning and per-person keys are two things you can do without waiting on anyone.
Further reading
How to judge whether an AI API relay is worth using
Four self-tests: multiplier conversion, cache hits, echoed model and usage reconciliation.
Buying an AI coding API for a team
Pooled quota, concurrency limits and attributing usage with sub-keys.
MCP security and sandboxing
Permission boundaries and isolation when opening tools to an agent.
This page offers a buyer-side self-assessment framework. It is not legal advice and does not represent any vendor's terms. Compliance judgements should rest on each party's written terms, your local regulations and your own legal counsel.