Privacy policy for a custom GPT and GPT actions

Use your action schema and backend configuration to draft the policy. Identify the service receiving the request and describe what it does with those inputs after the call arrives. Include account linking, logging, and downstream services where used. The policy should let someone understand your part of the interaction without needing to read an API specification:

1. Who operates the action: your name or company, the GPT or service name, and a privacy contact.
2. What you receive: the parameters your schema accepts, any conversation text sent with them, and account data if you use OAuth.
3. Why you use it: to answer the request, to run the user's account features, to prevent abuse, and nothing else unless true.
4. Who else receives it: hosting, database, logging, and any AI model provider you call, with a short description of each.
5. How long you keep it: request logs, stored results, and account data, each with a real period.
6. User rights and deletion: how to ask for access or deletion, and how to disconnect an OAuth account.
7. Children: OpenAI's services have their own age rules; say whether your service is directed to children.
8. Changes and effective date.

If your action supports user accounts, add how data in those accounts is handled. The AI chatbot privacy policy guide and the AI product privacy disclosures guide go deeper on model providers, prompts, and training.

The requirement is tied to actions, the feature that lets a GPT call an external API you define. OpenAI's Help Center says that if your GPT uses actions and you want to share it publicly or publish it to the GPT Store, each public action must include a valid Privacy Policy URL. Its article on configuring actions says the same thing in shorter form: each action can include a Privacy Policy URL, and public GPTs, whether shared by link or in the GPT Store, with actions must include a valid one. The publishing article lists a GPT that uses actions without a valid Privacy Policy URL as one of the reasons public publishing can be blocked.

A GPT that only uses instructions and knowledge files, with no actions, is not caught by this specific rule. A GPT kept private or shared only inside a workspace is also outside it, though workspace admins can set their own controls.

Why does OpenAI insist? Because once an action runs, data leaves ChatGPT and reaches your server, and OpenAI states it does not audit or control how third-party services use or store that data. Your policy is how users find out. The same logic applies to other platforms; our guide on how to get a privacy policy URL covers hosting and testing the link.

Your policy has to describe what your server sees, so be precise. OpenAI's production notes for actions say that when a user interacts with a GPT's custom action, ChatGPT may send parts of their conversation to the action's endpoint. The model turns the user's request into the parameters defined in your OpenAPI schema, so whatever the user types can end up in those parameters, including names, email addresses, or anything else they choose to share. OpenAI also says ChatGPT calls actions from its published IP ranges, so your server sees requests from OpenAI's infrastructure.

What else reaches you depends on your design:

• Authentication: OpenAI lists None, API key, and OAuth options. With OAuth, users sign in to your service, so requests are linked to their account with you.
• Your own logs: request bodies, timestamps, and errors stored by your web server, API gateway, or monitoring tools.
• Downstream services: databases, search APIs, or AI model providers your backend calls.

OpenAI's GPT privacy FAQ notes that GPT builders cannot view individual conversations users have with their GPTs. Your exposure is what your action receives and what you keep, and that is exactly what your policy should explain.

Your choice of authentication changes what your policy needs to say.

No authentication. Every request is anonymous from your point of view, but it can still contain personal data the user typed. Your policy should explain that you process the request content, keep minimal logs, and do not try to identify users.

API key. The key authenticates the GPT, not individual users. Requests look the same to you regardless of who is chatting, which keeps your data footprint small. The policy is similar to the anonymous case, plus rate limiting and abuse prevention if you use them.

OAuth. Users sign in to your service, and requests are linked to their account. Now your policy must cover your full account relationship: profile data, stored content, how actions update their account, and how users can disconnect. OpenAI's configuration article says that for OAuth actions, users can review and manage connected accounts in ChatGPT, and that users may be asked to approve actions before they run.

Whatever you choose, ask for the narrowest scopes and inputs that make the feature work. That keeps both your policy and your security work shorter.

Review rejections and confused users usually trace back to a handful of errors:

• Linking OpenAI's privacy policy. OpenAI's policy covers ChatGPT, not your server. You need your own.
• Linking a homepage or a generic company policy that never mentions the GPT, the action, or the data your API receives.
• Saying you store nothing while your logs keep full request bodies. Check your web server, gateway, and monitoring settings.
• Leaving out the AI provider your backend calls. If your action forwards text to another model API, name it and describe its retention.
• Vague retention like “as long as necessary” with no period or criteria.
• Using a document link that requires sign-in or can be edited by visitors.
• Forgetting to update the policy when you add an endpoint that accepts new kinds of data.

A quick test: read your OpenAPI schema and your policy side by side. Every parameter that could carry personal data should be explained in the policy, and every provider your code calls should appear in it.

Before you invest in a GPT, check where the product is heading. As of October 2026, OpenAI's Help Center says it is planning to retire custom GPTs and recommends moving workflows to plugins, which bring reusable instructions and connected apps together. According to the same notice:

• a migration experience was targeted for September 17, 2026, and may not reach every account or workspace at once
• retirement for affected Enterprise workspaces is planned for December 11, 2026, with other plans expected to follow the same timeline
• existing GPTs remain usable until retirement
• personal ChatGPT accounts, including Free, Go, Plus, and Pro, cannot create or publish new GPTs, while Business, Enterprise, and Edu workspaces depend on workspace settings and permissions

These dates come from OpenAI's own notices and may change, so check the current Help Center articles before you plan a launch.

For privacy policies, the change is less disruptive than it sounds. The data flow is similar: a user's request in ChatGPT reaches your backend. A policy written accurately for your action API can be updated for a plugin, as described below, rather than rewritten from scratch.

If you migrate to a plugin, the privacy rules get more detailed, not less. OpenAI's plugin guidelines, which cover plugins listed in the directory shared by ChatGPT and Codex, say submissions must include a clear, published privacy policy explaining, at minimum, the categories of personal data collected, the purposes of use, the categories of recipients, data retention timelines, and any controls offered to users. Users can review the policy before installing.

The guidelines also set data rules your policy should reflect:

• collect only the minimum data needed, with no “just in case” fields
• do not collect restricted data such as payment card data covered by PCI DSS, protected health information, government identifiers, or access credentials
• do not request full conversation history or raw chat transcripts
• do not track or profile users, including through metadata such as IP addresses, unless it is disclosed, narrowly scoped, and under meaningful user control
• plugins must be suitable for users aged 13 to 17 and may not target children under 13

If your GPT action policy already lists categories, purposes, recipients, retention, and controls, you are most of the way there. Review it against these guidelines when you submit.

The AI privacy policy generator is designed for this kind of service. Choose the AI use case, then describe what your action receives, the providers you use, whether you have user accounts, retention periods, and the regions your users are in. The questionnaire, full preview, and simple HTML and PDF download are free with no account.

Clauses are selected deterministically from a versioned library based on your answers. No AI writes the clauses at runtime, so the result is predictable and only describes what you confirm. Advanced regional modules such as GDPR, UK, and California cost $5, and optional public hosting adds $0.99 once, which gives you a public page to paste into the action's Privacy Policy field or a plugin submission.

If your backend lives in a repository, an AI coding agent such as Codex, Claude Code, or ChatGPT can inspect the codebase through the developer MCP server and create a private draft from what it finds, which you then review and confirm. That is useful for catching logging and provider calls you forgot. Generated text reflects your answers and is not legal advice.