AI data privacy checklist: questions before you send data
Before your customers' data goes into an AI service, someone on your side should be able to answer a short list of questions. If nobody can, that is the answer.
This checklist is for the person who has to sign off: a product lead, a security reviewer, a founder doing it all. It fits on one page, and every question can be sent to a provider as written. For background on the location questions, read data residency in one page.
Five groups of questions
- What you sendList the data, cut what is not needed, check what you promised.
- Where it runsNamed places for processing, and where requests go if busy.
- Who can see itWhich staff and other companies can access it, and from where.
- What is keptPrompts, outputs and files: how long, and whether used to train.
- How you would knowRecords, audit reports and incident notice you can check later.
First, know what you are sending
Before you ask a provider anything, answer three questions about your own feature.
What data goes in? List it plainly: support emails, call transcripts, contracts, medical notes, account numbers. "Customer data" is too vague to review.
Does all of it need to go in? Many tasks work as well with names, emails and account numbers removed or replaced. Less data in means less to worry about.
What did you tell customers? Check your privacy notice and customer contracts. If they promise something about where data goes or who processes it, the AI feature has to keep that promise.
Write the answers down in a few lines. That note becomes the first page of your review, and it tells the provider exactly what you need. Now you are ready to talk to providers.
Where does it run?
Location is the question most often skipped and most often asked later by auditors.
- In which countries or regions will my requests be processed?
- Can I choose or restrict the location? Is that a setting I control or a clause in the contract?
- If that location is busy or unavailable, where do my requests go?
- Does the location change if I switch to a different model or a newer version?
You want named places, not "our global infrastructure". To see why the answers differ from where files are stored, follow one document through the journey in stored here, processed there.
Who can see it?
Data that reaches a provider can be seen by more than the model.
- Which of your staff can access my requests or outputs, and for what reasons?
- From which countries can they access them?
- Do any other companies process my data on your behalf? Who, and where?
- How is access logged, and can I see those logs?
A good provider will have a short, specific answer to each. A long, general one is a reason to dig further.
What is kept, and for how long?
AI services can keep more than you expect: the prompt, the output, files you uploaded and metadata about each request.
- Do you store my prompts and outputs? Where, and for how long?
- Can I turn retention off or shorten it?
- Is any of my data used to train or improve your models? Is that off by default, and is it in the contract?
- When I delete data or close my account, what is deleted, how fast, and how do I get confirmation?
The training question matters most. If your customers' data could end up shaping a model other companies use, you need to know before you send it, and so do your customers.
How would you know?
The last group is about evidence. Answers in a sales call are a starting point. You need something you can check later.
- Can I get a record of where each request ran and when?
- What security certifications or audit reports can you share?
- How and how quickly will you tell me about a security incident that affects my data?
- If I leave, can I take my data and records with me?
If the only evidence is the provider's word, your audit trail ends at their door. Ask for a sample of any record or report before you sign, so you know what you will actually receive.
Inside your own company
A few questions are for your own team, not the provider.
- Who owns this feature's data decisions after launch?
- Is the AI provider listed wherever your company records its suppliers and subprocessors?
- Have you tested what the feature does with unexpected input, such as a customer pasting in someone else's details?
- Is there a way to switch the feature off quickly if something goes wrong?
How to use the answers
You will rarely get a perfect set of answers. Use them to choose the right setup for each kind of data. This is general guidance, not legal advice.
- Low-sensitivity data, such as public product descriptions, may be fine with a general-purpose service.
- Personal or confidential data may need retention turned off, training excluded and a named processing location.
- Regulated or contract-bound data may need processing in a specific country, with records to prove it.
Write down what you decided and why. When a customer or auditor asks next year, that note will save days.
What we are building
These questions are hard to answer when AI capacity is concentrated in a few places and the processing is out of view. With Starfield Fabric, we are building standardized compute close to power, connectivity and demand, connected through one programmable network for AI inference.
The network is designed for residency-aware placement: data stays where your policies say it stays, and workloads are placed by policy, on latency, data residency, model and load. Every workload can generate an auditable record of commitment, placement and delivery, which gives you something to show when you are asked, "How do you know?"
Related
Starfield Fabric · Data residency for AI inference, in one page · Stored here, processed there: the AI gap auditors find