Before handing your data to an AI project, these eight questions separate a serious provider from a legal and operational risk. A practical guide for founders and public-sector teams.
Before you sign an AI contract, the technical questions matter — but the data questions matter more. Once your documents, customer records or internal emails leave your infrastructure, you can't un-send them. The eight questions below are the ones I would ask any provider, including myself. They apply whether you're a founder buying your first LLM assistant or a public-sector team under stricter scrutiny.
1. Where exactly does our data go?
"Cloud-based" is not an answer. Ask for the specific hosting region, the subprocessors involved, and whether data transits outside your jurisdiction. For a European company, that means knowing whether processing happens in the EU and what legal framework covers any transfer. A serious provider has a written list of subprocessors and updates it when things change. If the answer is vague, treat that as the answer.
2. Is our data used to train models?
This is the question most often buried in terms of service. Consumer AI tools frequently reserve the right to use inputs for improvement; enterprise API tiers usually do not — but "usually" is not a contract. Ask for the clause in writing. Then ask the follow-up: does that hold for every model in the pipeline, including any open-source model they host themselves?
3. How long is data retained, and can we delete it?
Retention periods should be explicit and short by default. Ask what happens to prompts, uploaded documents, generated outputs, and logs — they are often stored in different places with different lifetimes. Then ask how deletion actually works: can you trigger it, how long does it take, and does it cascade to backups and third-party providers? Under the GDPR, deletion on request is an obligation, not a favour.
4. What is the legal basis and the data processing agreement?
If the provider processes personal data on your behalf, you need a data processing agreement (DPA) that meets GDPR Article 28 requirements. Ask who signs it, whether it covers subprocessors, and whether they will accept your version or only theirs. For public-sector teams, also ask about records of processing, impact assessments, and whether they can support a DPIA — an AI system that profiles people or makes automated decisions usually requires one.
5. What data do you actually need to send?
The strongest security measure is sending less. Before signing, map which fields are genuinely necessary for the use case. A support assistant rarely needs full customer records; a document search tool doesn't need your whole drive. Ask the provider how they handle minimisation, redaction and pseudonymisation, and whether the architecture allows you to keep sensitive fields out of the model entirely. If they can't explain their data flow, they can't protect it.
6. Who can see our data inside your organisation?
Access control is where many promising pilots quietly fail an audit. Ask who on their team can read your data, under what conditions, and whether access is logged. Ask about encryption at rest and in transit, key management, and whether they support customer-managed keys. Then ask about incident response: how quickly would you be notified of a breach, and what does their notification process look like in practice?
7. What happens when we leave?
Exit is part of security. Ask how you export your data, in what format, and whether your configuration — prompts, workflows, integrations — comes with it. Ask what is deleted after termination and whether you get written confirmation. Providers who make leaving difficult are telling you something about how they'll treat you while you stay.
8. Can you show evidence, not just assurances?
Certifications such as ISO 27001 or SOC 2 are useful signals, not guarantees. Ask for the scope of the certification, the date of the last audit, and whether a summary report is available. For AI-specific risks, ask how they test for prompt injection, data leakage between users, and hallucinated outputs in sensitive contexts. A provider who answers "we take security seriously" without documents is asking you to take a risk on their confidence.
A practical way to use these questions
Send them in writing before the second meeting and ask for written answers. Compare responses side by side; the gaps are usually more informative than the strengths. Involve whoever owns legal and compliance early — retrofitting a DPA after a pilot has gone live is expensive and sometimes impossible. And scale the depth to the sensitivity: a public marketing chatbot needs fewer guarantees than an assistant reading HR files.
None of this is meant to make AI projects feel impossible. Most of these questions have good answers, and providers who have done the work are usually glad to be asked — it separates them from the ones who haven't.
If you're planning an AI project and want to talk through the data side before you commit to a vendor or an architecture, I'm happy to look at your situation and share what I'd check first. You can reach me at contact@hamzabelgacem.com.