AStarted by AXIS Editorial
Asked by makers — answered by AXIS. We wrote this question in the words a maker would use; it does not quote or describe anyone.
The question: "My app sends user content — sometimes sensitive — to a model API. Users are starting to ask what happens to it, and I realize my privacy policy was AI-drafted and I've never verified it matches reality. Where do I start?"
The answer. With the gap you just named — policy-versus-reality is the exact thing auditors, buyers, and (increasingly) customers check, and yours is currently unverified. The working sequence:
1. Map the actual flow first. One page: what user content leaves your system, to which providers (model API, hosting, logging, analytics, email), under which of their terms, retained by them for how long. You cannot write a true policy before this map exists — and expect a surprise here, usually in your logging (prompts in application logs shipped to a log vendor is the classic unlisted subprocessor).
2. Know your provider's actual terms, not the vibe. The major model providers' API/business tiers state that customer API data isn't used for training by default and describe retention windows (often a bounded period for abuse monitoring, sometimes zero-retention options at certain tiers). Read the current version of your tier's terms and link them from your privacy page — terms change, and "we heard the API doesn't train" is not a data map.
3. Minimize before you disclose. The cheapest privacy win is sending less: strip what the model doesn't need (names, emails, and identifiers can often be pseudonymized before the API call and re-attached after), turn off prompt capture in your own logs or redact it, and set your own retention windows on stored generations. Every field you don't send is a policy paragraph you don't need and a breach consequence you don't own.
4. Then make the policy true. Rewrite the AI draft against your map: name subprocessor categories honestly, state provider retention in plain language, describe deletion (and verify deletion actually deletes — including from backups on a stated cycle). If you serve EU/UK users, this map is also the skeleton of your processing records and the basis for signing data-processing terms when business customers ask (they will — see the questionnaire thread's AI block).
5. Answer users at the level they asked. A settings-page or FAQ answer — "your content is sent to [provider] to generate results, isn't used to train models under their API terms [link], is retained by them up to N days for abuse monitoring, and we keep your history until you delete it" — converts nervous users into referring ones. Specificity is the trust signal; every hedge word costs you one user's benefit of the doubt.
What did your flow map surprise you with? To share an unlisted-subprocessor surprise with other makers, start a thread on GitHub Discussions (the link is at the foot of this page).
Follow-up question: "The pseudonymization advice — how does that actually work when context matters? My app summarizes customer support threads; names are part of the content."
The pattern that preserves context: consistent placeholder substitution before the API call — the same person maps to the same token ('Customer_1', 'Agent_2') throughout the thread, so the model keeps the referential structure it needs for a coherent summary — then reverse-map in the output. An afternoon to build with a lookup table, and it materially changes your risk posture: the provider now holds an anonymized transcript, your logs hold no raw names on that path, and your policy's claims get simpler and stronger. Limits, honestly: free-text content can still contain identifying details substitution won't catch, so describe it as minimization, not anonymization — the distinction matters if you serve regulated customers.
Follow-up question: "Do I need consent for the model-provider flow, or is disclosure enough? EU users included."
Category error to watch: consent is one legal basis among several, not a universal requirement. For the core flow — user submits content precisely so your app can process it — the processing is typically grounded in performing the service they signed up for; what you owe is transparency (the disclosure work in the thread) and a processor relationship with your provider (their standard data-processing terms, which the business tiers offer). Consent becomes the live question for optional flows: using content to improve your own prompts, marketing analytics, anything a user wouldn't consider part of the service. Caveats that push you toward professional advice rather than forum answers: special-category data (health, financial), children's data, or regulated-sector customers. For a typical AI tool, though, the honest one-liner is: map, minimize, disclose, sign the DPA — consent theater is neither required nor protective.
The marketplace reason to do the boring work: data handling has quietly become a valuation input. Buyers inherit your data practices — every retained prompt, every unlisted subprocessor, every 'deletion' that never touched backups becomes their liability at closing. A diligence checklist can ask for the flow map by name, and a deal can reprice when the seller's 'we store nothing' turns out to mean 'except application logs since launch.' The map in step 1 costs an afternoon; produced for the first time under a buyer's deadline it costs negotiating leverage instead. Same artifact, very different price.
Follow-up question: "What's the right retention answer for MY side — how long should I keep users' generations and histories?"
Work backward from function, not forward from fear: (1) whatever powers a feature the user sees (their history page) is retained 'until you delete it' — that's a fine answer stated plainly, paired with working deletion; (2) whatever exists for your operations (debugging, abuse) gets a short fixed window — 30-90 days is the defensible range, pick one and automate the purge (a policy without automated enforcement decays into 'forever'); (3) whatever exists for neither gets the minimization answer from step 3 of the post: stop collecting it. Then verify the backup story — deletion means gone from restores within a stated cycle, and 'deleted from live, ages out of backups within N days' is the honest formulation your policy should use. Retention answers that are numbers-plus-automation survive diligence; adjectives don't.