Before You Approve an AI Tool, Read the Terms That Control the Data

Executive summary

An AI product name does not tell you what happens to the data.

The answer can change based on the plan, account type, settings, contract, feature, integration, region, and way the product is purchased. A free personal account, a paid business workspace, an application programming interface, and an AI feature embedded inside another platform may carry the same brand while operating under different terms.

That is why "Does this company train on our prompts?" is usually the wrong first question.

The better review is:

• Which exact service are we approving?
• Which documents govern it?
• What information will we enter, upload, retrieve, or connect?
• How may the provider use, retain, review, disclose, and delete that information?
• Which settings and contract terms change the answer?
• What can the tool read or do through connectors and automations?
• Which output requires human verification?
• What evidence will we keep, and when will we review the decision again?

This article gives a practical way to answer those questions without turning a small-business tool review into a six-month procurement project.

It is intentionally dated and was last reviewed on August 4, 2026. Product names, features, terms, controls, and privacy practices can change. Use this as a review method, then verify the current first-party documents for the exact service being considered.

Start with the exact product boundary

Do not approve "AI."

Do not even approve a provider by name.

Approve a defined boundary:

• Provider and contracting entity.
• Product and feature.
• Plan or tier.
• Personal, business, enterprise, education, developer, or application programming interface account.
• Direct purchase, reseller purchase, or feature bundled inside another platform.
• Browser, desktop, mobile, extension, integration, or embedded use.
• Users and administrators.
• Intended business purpose.
• Information involved.

This sounds tedious until the first time two employees are using the same brand under different accounts. One signs into a managed business workspace. The other pastes customer information into a personal account created with a company email address. Leadership thinks the product was approved once. In reality, two different data-handling decisions are happening.

Write the boundary at the top of the review. If the product or plan changes, the approval does not automatically follow it.

Find the documents that actually govern the service

A privacy policy is not the whole contract.

Depending on the purchase, the relevant set may include:

1. An order form or subscription agreement.
2. Master service or commercial terms.
3. Product-specific or service-specific terms.
4. A data processing addendum.
5. A privacy notice.
6. Acceptable-use or prohibited-use terms.
7. A security or trust-center description.
8. A subprocessor list.
9. Feature documentation for connectors, memory, browsing, file upload, agents, or data controls.
10. Settings inside the administrator and user interfaces.

These documents do not always carry the same authority. An order form may modify the general terms. Product-specific terms may govern one feature. A data processing addendum may address personal data without answering what happens to confidential engineering material. A marketing page may describe a control without becoming a contractual commitment.

Record the document title, link, effective date, access date, and the product boundary it appears to cover. Save a copy or screenshot for important decisions if the terms permit it. A bookmark to a page that changes tomorrow is weak evidence of what leadership reviewed today.

Qualified counsel should resolve contract priority, legal obligations, intellectual-property terms, regulated data, and negotiated language when the consequence warrants it. The cybersecurity review should still make the operating assumptions visible.

Describe the data before reading promises about it

"Business data" is too vague.

List what the use will involve:

• Prompts and chat history.
• Uploaded documents, images, audio, video, or spreadsheets.
• Customer, employee, applicant, patient, financial, insurance, legal, or identity information.
• Source code, configurations, logs, incident material, or vulnerability information.
• Controlled Unclassified Information, export-controlled information, or contract-restricted material.
• Content retrieved from email, cloud drives, calendars, customer systems, code repositories, or internal search.
• Feedback, ratings, support tickets, and diagnostic data.
• Generated output and derived artifacts such as summaries, embeddings, indexes, or saved memory.
• Metadata about users, devices, location, usage, and administrators.

Then ask whether every category is necessary.

The FTC's privacy and security guidance keeps returning to a durable principle: collect and retain information with care, protect it appropriately, and honor the promises made about it. AI does not erase those obligations. The word "prompt" does not make customer information less sensitive.

If a representative excerpt, synthetic record, or de-identified example answers the question, do not upload the complete live record.

Training is not a yes-or-no question

This is where reviews often become sloppy.

One person says, "AI companies train on everything."

Another says, "The provider says it does not train on business data."

Neither sentence is enough to approve the use.

Ask:

• Does the statement apply to this exact service and plan?
• Does it cover prompts, files, retrieved content, output, feedback, support data, and metadata?
• Is the behavior a default, a setting, an opt-out, or a contract commitment?
• Who can change the setting?
• Does the answer change for beta, preview, experimental, or third-party features?
• Does abuse monitoring, safety review, debugging, or support create a separate use or retention path?
• What happens if a user submits feedback or shares a conversation?
• Does an embedded product send information to a different model provider?

A provider may distinguish model training from other processing. Information might still be stored, scanned, reviewed, logged, used for security, or disclosed to subprocessors even when it is not used to train a general model.

Conversely, do not claim every AI prompt is permanently added to a model. That is not how every service, plan, or control works.

Record the exact statement and where it came from. Then set an internal data rule that employees can follow without interpreting product terms mid-prompt.

Retention and deletion need a timeline

"We delete your data" is incomplete.

Ask what is retained, for how long, in which systems, and after which event.

The relevant event might be:

• The user deletes a conversation.
• An administrator deletes a user.
• The workspace is cancelled.
• A file is removed from a connected source.
• A support case closes.
• A safety or abuse flag is raised.
• A legal hold or other required preservation applies.

Also distinguish active-system deletion from backup expiration, security-log retention, de-identification, aggregation, and derived artifacts.

Important questions include:

• Can administrators set or shorten retention?
• Can users create public links or persistent shared artifacts?
• Does "temporary" or "private" mode change all retention, or only chat history?
• Are uploaded files deleted with the conversation?
• What happens to indexes, embeddings, memory, or cached connector data?
• Can the business export records before deletion?
• What proof is available after account termination?

The correct answer depends on the business. A short retention period may reduce exposure. It may also conflict with a recordkeeping, investigation, quality, or customer obligation. That tradeoff belongs to the accountable business owner with legal and records guidance where needed.

Human access and subprocessors still matter

"The model processes the data" can hide a larger service chain.

Review:

• Whether provider staff or contractors may access content for support, safety, abuse, quality, or debugging.
• How that access is approved, limited, logged, and reviewed.
• Which subprocessors host, analyze, secure, support, or otherwise handle the service.
• Where the current subprocessor list is maintained.
• How customers are notified of changes.
• Whether data location or cross-border processing matters to the business.

The NIST Generative AI Profile treats third-party components, data, governance, monitoring, and incident disclosure as connected risk-management concerns. That is useful framing. A tool is not only a model. It is an operating service with people, infrastructure, dependencies, and changes.

Connectors change the review more than the chat box

The product may look acceptable when a user pastes public text into a blank conversation.

Then somebody connects the entire mailbox.

Review each connector, plugin, extension, action, retrieval source, automation, and agent separately:

• What can it read?
• Which user's permissions does it inherit?
• Can the scope be limited to selected folders, sites, records, repositories, or actions?
• Can it send, publish, delete, purchase, approve, execute, or change anything?
• Does it maintain another copy, index, cache, or embedding of connected content?
• Can instructions inside a document, email, website, or retrieved record influence the tool?
• Are actions logged and attributable?
• Is confirmation required before consequential action?
• Can access be revoked quickly without disabling the entire business system?

A connector is an access-control decision. An agent is a delegation decision. Treating either one as a productivity checkbox is how a limited pilot becomes broad data access without a deliberate approval.

Start read-only. Start narrow. Test with non-sensitive information. Add write or action permissions only after the business can explain the boundary and recovery path.

Administrator controls are part of the product

A business-ready tool should be reviewed as an account and identity system, not only as a model.

Look for:

• Central account ownership.
• Named administrators.
• Multifactor authentication.
• Single sign-on and automated user lifecycle options when appropriate.
• Restrictions on personal accounts and external sharing.
• Role-based access.
• Workspace, project, and connector boundaries.
• Audit and usage logs.
• Retention and data-control settings.
• User export, suspension, and deletion.
• A tested recovery path if the primary administrator is unavailable.

Do not purchase an enterprise-sounding tier merely because it has more controls. Confirm that the business will actually configure and operate the controls it is paying for.

A feature that exists but has no owner is not a control yet.

Output terms do not make the output correct

Contract language about ownership, licenses, indemnity, or similarity of output can matter. It should be reviewed by qualified counsel when the business will publish, sell, license, patent, or rely heavily on generated material.

Cybersecurity and operating review still needs to ask:

• Who verifies facts and citations?
• Who reviews confidential or personal information in the output?
• Who checks code, formulas, calculations, and security recommendations?
• Who looks for copied or unexpectedly similar material?
• Can the business explain the source and approval of a consequential decision?
• What happens when the output is challenged?

NIST's AI Risk Management Framework emphasizes context, measurement, human roles, and continued management. A terms-of-service clause does not validate a recommendation. A person still has to decide whether the output is fit for the actual task.

High-impact use deserves a different process

Ordinary self-service approval is not enough when the tool affects employment, lending, insurance, healthcare, legal rights, safety, eligibility, critical security actions, or other consequential decisions.

That does not mean every use is forbidden.

It means the business should involve the functions qualified to address:

• Applicable law and regulation.
• Validity for the intended population and context.
• Bias, fairness, accommodation, and appeal.
• Required notice or disclosure.
• Human authority and override.
• Recordkeeping and explanation.
• Monitoring after deployment.

The product terms will not design that operating process for the customer.

Run a small pilot with an exit

Before broad rollout:

1. Define the use and owner.
2. Use the approved account and settings.
3. Limit users, data, and integrations.
4. Build normal, ambiguous, failure, and refusal test cases.
5. Define which errors are tolerable.
6. Record human-review expectations.
7. Monitor support issues, unsafe behavior, sharing, and unexpected access.
8. Decide how to export work and remove data if the pilot ends.

Keep a short approval record with the documents reviewed, important settings, test results, limitations, approval date, and next review date.

Revisit the decision when:

• The product, model, plan, or contracting entity changes.
• Terms or privacy notices change.
• A new connector, memory feature, action, or agent is enabled.
• New information or users enter scope.
• A material incident, unsafe result, or provider notice occurs.
• The use begins affecting customers, employees, regulated work, or critical decisions.

The practical approval record

A small business can do this on one or two pages.

Record:

• Exact product boundary.
• Approved business purpose.
• Owner and users.
• Allowed and prohibited information.
• Terms and settings reviewed.
• Training, retention, deletion, human-access, and subprocessor assumptions.
• Integrations and permissions.
• Human-review process.
• Test evidence and known limits.
• Incident contact and exit path.
• Approval and review dates.

That record will not answer every legal or technical question.

It will answer the one leadership needs first: what exactly did we approve, and why?

Summary

Do not approve an AI tool from a logo, demo, privacy-policy headline, or one sentence about training.

Approve the exact service. Understand the document hierarchy. Describe the data. Separate training from retention and other processing. Review human access and subprocessors. Treat connectors as access decisions. Confirm administrator controls. Require human verification that matches the consequence. Pilot narrowly. Keep an exit.

Product terms will keep changing.

The review method should not.

Use the Safe Business AI guide to turn this review into employee rules, approval lanes, testing, and mistake reporting. If the tool will touch sensitive data, broad integrations, code, customers, or critical business decisions, bring the proposed boundary to a security architecture review before it becomes difficult to unwind.