Start with the data your team will send
Before reading an AI vendor’s terms, list what people will put into the service. A brainstorming prompt, a customer support transcript and a document containing employee details present different risks. Include uploaded files, conversation history, generated outputs, account information and usage logs. If the tool connects to email, storage or another app, note what those connections can access as well.
Then find the documents that apply to the product and plan you intend to use. A vendor may publish a privacy notice, product terms, a data processing agreement and separate documentation for enterprise controls. Do not assume a promise made for an API or enterprise plan also applies to a consumer chat account. Check definitions such as “customer content,” “personal data” and “service data”: the same retention or training commitment may not cover all three.
A useful first question is: what can the vendor do with our inputs and outputs? Look for language about providing the service, monitoring misuse, improving products and training models. These are different purposes. If a setting controls training use, check who can change it, whether it is on by default and whether it applies to data already submitted.
Understand who else may process the data
A subprocessor is another organization the vendor uses to help deliver its service while processing data on the vendor’s behalf. Common roles can include hosting, support, analytics and security operations. The name of a company alone may not tell you what it handles, so look for a subprocessor list that describes each provider’s role and, where available, processing location.
Check how the list changes. Does the vendor provide notice before adding a subprocessor, publish an updated list or offer a way to raise an objection? Read what happens if you object; an objection process is less useful if its practical outcome is unclear. Also distinguish subprocessors from integrations you choose to enable. Sending data from an AI tool into another app may create a separate flow governed by that app’s terms.
You do not need to treat every subprocessor as equally concerning. Focus on whether its stated role fits the data it could receive. If the terms say a provider handles support requests, for example, ask whether support staff can view customer content and what controls govern that access.
Trace transfers, not just storage regions
A statement that data is “stored in” a particular region does not necessarily mean it is processed only there. Requests may be routed elsewhere, and authorized staff or subprocessors may access data from other locations. Look separately for where content is stored, where it is processed, where backups reside and where human access may occur.
Terms may also describe a mechanism for cross-border transfers. Rather than relying on a label alone, identify which data it covers and which parties are involved. If regional controls matter to your team, ask whether they apply to prompts, files, outputs, logs and backups, and whether they are available on your chosen plan. A clear answer about scope is more useful than a broad statement about data residency.
Check what “delete” means in practice
Deletion can refer to several actions: removing a conversation from your view, deleting an account, ending a contract or removing data from active systems. These may follow different timelines. Find the terms for each action, including what happens to uploaded files, outputs, logs, backups and copies shared through integrations.
Look for exceptions and their boundaries. A vendor may retain some information for security, abuse prevention or other stated purposes after customer content is deleted. The key questions are what is retained, why, for how long and who can access it. Also check whether you can export data before deletion, whether administrators can manage retention centrally and how you request confirmation that a deletion request was completed.
Avoid assuming that deleting a chat reverses all prior processing. For example, a deletion control may not address data already sent to an enabled integration. If the answer is ambiguous, use a low-sensitivity test workflow until the vendor clarifies it.
Turn the terms into a short decision record
Summarize what you found in a page your team can actually use: approved data types, applicable product plan, training setting, key subprocessors, transfer locations or controls, deletion steps and unanswered questions. Link each conclusion to the vendor document or setting you checked, and record when your team reviewed it. This makes later changes easier to assess.
If a term is vague, ask a specific question rather than requesting a general assurance that the service is “private.” For example: “Does the 30-day deletion period include uploaded files in backups?” or “Can support personnel outside our selected region access prompts?” Treat unclear answers as a reason to limit sensitive inputs, choose a narrower workflow or pause adoption. This is a practical review framework, not legal advice; for contractual obligations, involve the appropriate qualified reviewer.
