The first request to an external language-model API is the moment data leaves your control. Most teams make that decision implicitly, in a prototype, and discover later that the prototype was sending names, emails and account numbers to a third party. Here is the checklist I would walk through before the first request. It is an engineering checklist, not legal advice: the final answers depend on your jurisdiction, your contracts and your lawyer.
1. What data is actually in the input?
Take 50 real inputs and look. Typical surprises: names in signatures, phone numbers in free text, order numbers that identify a person, attachments with scanned IDs. If you cannot say what is in the input, you cannot say what you are sending.
2. Do you need it to do the job?
Often the model needs the question, not the identity. Strip or replace what the task does not use:
import re
EMAIL = re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+")
PHONE = re.compile(r"\+?\d[\d\s().-]{7,}\d")
def scrub(text: str) -> str:
return PHONE.sub("[PHONE]", EMAIL.sub("[EMAIL]", text))
Regexes catch the easy cases only. Names and addresses need a proper detector, and you still have to test what slips through on your own data.
3. What do the provider's terms say?
Read, with the person who owns compliance:
- Retention: is the input stored, for how long, can it be switched off?
- Training: is your data used to train models by default? Business and API tiers often differ from consumer products.
- Sub-processors and location: where is it processed?
- Deletion and audit: can you request deletion, and is there a data processing agreement?
Write the answers down with the date. Terms change.
4. Is there a lawful basis and a notice?
If the data is about people, someone has to decide on the legal basis and whether your privacy notice already covers this use. That is a decision for the data owner, not for the developer, but the developer should ask for it before the launch, not after.
5. Do you need the data to leave at all?
Compare honestly:
- A smaller model or classic ML on your own server (no external call).
- A provider with a region and retention setup that fits.
- Redaction plus an external model.
The cheapest compliant option is the one where the sensitive part never goes out.
6. Logs, caches and prompts are data too
Check where else the text lands: application logs, error trackers, analytics, prompt caches, evaluation sets shared in chat. A perfect API policy does not help if the raw text is in your logging stack forever.
7. Secrets and access
API keys in environment variables, not in the repo or chat. Separate keys per environment, a spend limit, and a way to rotate them. Limit who can read the raw logs.
8. Plan for the incident
Decide in advance: who is told, how fast, and how you would find out which requests contained what. That is only possible if you log request metadata (not the raw sensitive content).
Takeaways
- Look at real inputs before deciding anything.
- Send the minimum, scrub the rest, and test the scrubber.
- Read retention, training and location terms, and date your notes.
- Get the legal basis decided by the data owner.
- Treat logs and caches as part of the same data flow.
Portfolio and contacts: @Kotenev01_bot.
I write about practical, measurable AI adoption for business: demos on test data, no invented case studies. Telegram channel: @kotenev01_en
Top comments (0)