How to Write a Privacy Policy for an AI App
Sending user data to a model changes eight sections of your privacy policy. The facts to establish first, and what each section actually has to say.
If your app sends user data to an AI model, your privacy policy has to say so, name who the model provider is, explain whether inputs are used for training, and give people a way to object. A generic template written before 2023 does none of that, and the gap is exactly the part regulators and enterprise buyers now read first.
This walks through the sections that change when AI enters the picture. It is not legal advice, and a policy that governs anything sensitive should be reviewed by a lawyer in your jurisdiction. Disclosure is one of the cheaper items on the list of AI risks to get right, and one of the more expensive to get wrong. What it will do is get you to a draft that is honest and specific enough for that review to be short.
Work out the facts before you write a word
Almost every bad AI privacy policy is bad because it was written before anyone established what the system actually does. Answer these six questions first, on paper.
What user data reaches a model? Be specific. Not "user content", but "the text of support messages, including any personal details the user chose to include".
Which providers receive it? Name them. If you route between several, name all of them.
Where is it processed? Country or region, because this determines what transfer language you need.
Is it used for training? Check the actual terms of the tier you are on. Consumer tiers and business tiers frequently differ on this, and the difference is material.
What is retained, by whom, for how long? Both your retention and the provider's. Many providers hold inputs for a period for abuse monitoring even when they do not train on them.
Does any output get stored against a user? Generated summaries, embeddings, and conversation histories are personal data when they are tied to a person.
Write the answers down. That document is the input to the policy, and it is also what you hand a buyer's security reviewer, who will ask for exactly this.
The privacy policy sections an AI app changes
What data you collect
Add the AI-specific categories explicitly. Prompts and inputs, generated outputs stored against an account, any derived data such as embeddings or classifications, and usage metadata like token counts. "User content" alone does not tell a reader that their support ticket was sent to a third party.
Why you process it, and on what basis
Say what the AI feature does for the user, in a sentence they can picture. "We send the text of your message to a language model to draft a suggested reply, which you review before sending" beats "we may use artificial intelligence to enhance our services".
If you are relying on legitimate interests rather than consent under a framework like the GDPR, that assessment needs to exist as a document, not as an intention.
Who you share it with
This is the section most often wrong. Model providers are processors or sub-processors and belong in the list by name, with a link to their terms and a description of what they receive. A generic reference to "trusted third parties" is not a disclosure.
Maintain a sub-processor list on a stable URL and reference it from the policy. Then you can update the list without republishing the policy, which you will need to do the first time you change providers.
Training
State plainly whether user data is used to train models, yours or anyone else's. If it is not, say so, because it is a genuine reassurance and people are looking for it. If it is, say so clearly and explain how to opt out. The version that causes trouble is the ambiguous middle: "we may use data to improve our services" reads to a careful reader as training with extra steps.
International transfers
If the model runs in a different jurisdiction from your users, say where and name the transfer mechanism you rely on. This is a two-line addition that enterprise procurement will look for and its absence stalls deals.
Retention
Two clocks: yours and your provider's. Say both. "Conversation history is kept in your account until you delete it. Our model provider retains request data for up to thirty days for abuse monitoring and does not use it for training."
Automated decision-making
If a model's output materially affects someone, deciding eligibility, ranking an application, flagging an account, that is a category regulators treat separately, and people generally have rights to an explanation and to human review. Drafting a suggested email does not fall in this bucket. Declining a refund does.
Accuracy and human review
Worth a short paragraph even where it is not strictly required, because it sets expectations honestly: outputs can be wrong, here is where a human checks them, here is how to tell us when something about you is inaccurate. Given how confidently models produce wrong information, silence on this reads as either naivety or evasion.
Children, if relevant
If under-18s can use the product, the AI features need their own consideration rather than inheriting the general position.
Practical drafting notes
Write for a person, not for a court. Short sentences, active voice, concrete nouns. Regulators have been explicit for years that intelligibility is part of compliance, and a policy nobody can read fails at its actual job.
Do not promise what you cannot verify. "Your data is never stored anywhere" is a claim about your provider's infrastructure that you probably cannot substantiate. Say what you control, and describe what your provider says it does with a link.
Version it and date it. Show a last-updated date and keep old versions available. When something goes wrong, the question is always what the policy said at the time.
Update it when you change model provider. This is the most commonly missed trigger. Swapping providers changes who receives the data, and the policy is now inaccurate the moment the switch ships.
Get the retention numbers from the actual contract, not from a marketing page. Vendor marketing sites and vendor terms disagree more often than they should.
Where a generated draft helps and where it does not
Using a model to draft the plain-language sections is sensible. It is good at turning your six answers into readable prose, and readability is genuinely part of the requirement.
It is not good at knowing your provider's current retention period, your jurisdiction's transfer rules this year, or whether your legitimate interests assessment holds. Those come from documents and from a lawyer. The realistic split is that the model saves you the writing time and none of the checking time, which is roughly the same split as everywhere else AI is genuinely useful in a small business.
If your app also handles uploads, note that file upload flows frequently send document contents to a model for extraction, and people forget to mention it because the feature does not look like an AI feature from the outside.
Common questions
Do I need to mention which AI provider I use by name?
In practice, yes. Transparency requirements are about identifying recipients of personal data, and enterprise buyers will ask regardless. A named sub-processor list on a stable URL is the standard way to do it.
Does a privacy policy alone make my AI feature compliant?
No. The policy describes what you do. If what you do is not lawful, an accurate description of it does not fix that. The upstream work is establishing a lawful basis, minimising what you send, and having a data processing agreement with your provider.
Can I use a template?
As a skeleton, yes. Every AI-specific section above needs facts a template cannot know, and a template that fills those in with vague language is worse than no template, because it reads as a disclosure while disclosing nothing.
What if I only use AI on data users typed into a chat box?
That is still personal data if the person is identifiable, and users routinely paste more than you expect into free-text fields. The disclosure obligation follows the data, not your intentions for the field.
How often should I review it?
Whenever you change provider, change model tier, add a feature that sends new data, or change retention. Failing that, annually. The provider change is the one that catches people out.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
