Why this deserves a pause
When a project calls an online model, the input does not stay on your device. Text, images, audio or sensor readings travel across the network to a server run by someone else, are processed there, and a result comes back. That is often perfectly reasonable, but it means you are handing information to a third party, and you should decide deliberately what and how much.
This article is a list of questions, not legal advice. Rules about personal data differ between countries and sectors, and a provider’s terms differ between services and change over time. Read the current terms for the service you use, and if your project handles other people’s data in a business or public setting, seek proper advice.
1. What exactly is being sent?
Start by listing the data, field by field. It is easy to underestimate. A “simple” request may include:
- The text you typed, plus any earlier conversation history included automatically.
- Attached files, with metadata such as author names, locations in photos or timestamps.
- Images with faces, screens, documents or house numbers in the background.
- Audio that captures other people’s voices or background conversation.
- Identifiers such as device IDs, account names or IP addresses added by your code or the network.
Check what your own program actually transmits, not what you think it does. Logging the outgoing request during development is a good habit.
2. Whose data is it?
Your own notes are yours to share. Data about other people is different. Family members, houseguests, customers and neighbours have not necessarily agreed to their images, voices or messages being processed by an outside service. Cameras and microphones in particular raise this issue, and the considerations in camera privacy apply equally when the processing happens in a cloud service rather than at home.
3. How long is it kept?
Ask what the provider does with data after returning a result. Possibilities include discarding it almost immediately, keeping it for a limited period for abuse monitoring, or keeping it until you delete it. Look for retention periods in the terms and whether settings let you change them. Do not assume the answer; it varies between providers and between plans or account types.
4. Will it be used to train or improve models?
Some services may use submitted content to improve their products unless you opt out, while others state that they do not by default, and the answer may differ between consumer and business offerings. This matters because material used in training could, in principle, influence future outputs. Read the data-use section of the current terms and look for an opt-out or a business tier with stronger commitments. If the statement is unclear, treat the data as though it might be used.
5. Who can see it?
Beyond the provider’s systems, consider:
- Whether staff or contractors may review samples, and under what conditions.
- Whether the provider passes data to sub-processors such as hosting companies.
- Whether others on a shared account or team workspace can read your history.
- Whether the content could be disclosed in response to legal demands, which varies by jurisdiction.
6. Where is it processed and stored?
Data may cross borders. For some personal data, location rules apply. Providers often publish where their servers sit and whether regional options exist. If your project involves other people’s data and you are subject to such rules, this is a point to check early rather than after you have built the project.
7. How is it protected?
Look for encryption in transit, which is standard for reputable services, and ask about protection at rest. The basics are explained under data encryption. Note what encryption does and does not cover: it protects against interception on the way and some theft of storage, but it does not stop the provider itself from reading content it processes unless the service explicitly offers a design where it cannot.
On your side, secure the connection details. Keeping API key secrecy matters because a leaked key lets strangers run requests on your account, at your cost and possibly against your data. Never commit keys to a public repository, and rotate any that are exposed. The wider habits in connected project security apply here.
8. What happens when something goes wrong?
Services have outages, change terms, and occasionally suffer breaches. Consider:
- Would your project still behave safely if the service were down or slow?
- Would a leak of what you sent cause harm? If so, send less.
- Can you delete your data, and does deletion cover backups and logs?
- What notice do you get if terms or prices change?
9. Can you send less?
Data minimisation is the most effective single measure. Options include:
- Strip identifiers: remove names, addresses, account numbers and similar details before sending. Be aware that removing obvious identifiers does not always make data anonymous, since combinations of details can still point to a person.
- Reduce the content: send a cropped region, a short transcript, or summary figures rather than a full image, recording or log.
- Process locally first: run a lightweight check on the device and only send what needs the larger model. Edge computing takes this approach in general terms.
- Choose a local model for sensitive material: running language models on your own machine means text never leaves it, with trade-offs in memory and speed, covered under local language models.
10. Is the benefit worth the exposure?
Finally, weigh it. Sensitive categories such as health information, financial details, children’s data, precise location, private messages and credentials call for particular caution, and for many of them the safe default is not to send them to a general-purpose online service at all. This is one of the questions that belongs in any AI feature evaluation, alongside cost and reliability.
A short pre-flight checklist
- List every field being sent and remove what is not needed.
- Confirm you have the right to share it, including other people’s data.
- Read the retention, training-use and access terms for your actual plan.
- Check where it is processed and how it is protected.
- Keep keys out of code that is shared, and limit what a key can do.
- Decide what happens when the service fails or terms change.
- Re-check periodically, because terms and settings are not fixed.