Does enterprise AI train on company data? What to check in your plan and contract

The short answer is: not by default. In the commercial OpenAI and Anthropic products we reviewed, model training on your prompts and responses is disabled by default. But “the model is not trained” does not mean “nothing is stored.” Chat history, uploaded files, feedback on responses, and calls to external tools follow separate rules.

The key qualification is that this conclusion applies to a specific product, feature, and contract—not to a brand as a whole. An employee’s personal account, a company workspace, and an API have different terms.

This article will help you decide which categories of data your company may send to a chosen service and what to check before connecting it. The providers’ rules are described according to their documentation as of the research date, 11 October 2026. Provider terms change, so check their current documentation and your contract before making a decision.

The short answer and plan boundaries

The question “does ChatGPT Enterprise or Claude for Work train on our data?” sounds like one question. In practice, it covers three different situations, each with its own rules.

Company workspace. The company buys a plan for employees, and an administrator manages its settings. OpenAI states on its enterprise privacy page that it does not train models on customers’ business data by default. Voluntary data sharing with the provider is described as a separate option, not the default behavior. Anthropic describes a similar rule for its commercial products, with an important qualification about feedback. We return to that below.

API. The company embeds a model in its own product or process: a website chatbot, request processing, or internal search. OpenAI includes the API Platform among its business products covered by the no-training-by-default rule. Anthropic also explicitly lists the Anthropic API among its commercial products. If an intermediary or another cloud platform provides access, check the terms for that route too. Retention depends on the specific API features and selected mode.

Personal account. If an employee opens an AI service through a personal account, enterprise protections do not apply to that conversation. Applying consumer account terms to Enterprise or the API is incorrect, and the reverse is also true. So the question “which plan should we choose?” cannot be separated from “what are employees already using?”

There is another caveat about product names. Providers rename and combine plans. Look beyond the name on the invoice and check two facts. First, whether your account belongs to the business products described in the provider’s documentation. Second, whether the relevant terms have been signed. Record the date you checked. For our research, that date is 11 October 2026. The Anthropic help articles reviewed during preparation had versions dated 18 August 2026 and 1 July 2026, while OpenAI pages were dynamic and had no fixed date.

Four different data activities that should not be conflated

The phrase “our data is safe” often describes one of four processes. A provider’s promise usually covers only one of them. Let’s separate them.

1. Model training. Using your prompts and responses to improve future versions of a model. This is what business owners most often worry about, and what the promise “no training by default” addresses.

2. History retention. Chats, files, and projects remain in the workspace so an employee can return to them. This is useful, but until the history is deleted under the retention rules, the data remains with the provider and is accessible to people granted access in your workspace.

3. Logs and safety processing. Separately from chat history, a provider may keep technical records, for example to detect abuse. Whether this processing exists in your product, which data it covers, and how long it lasts are matters for the documentation and contract. Both providers describe retention modes and periods separately from their training rules.

4. Transfer to an external tool. When AI calls a connector to a CRM, email, cloud drive, or third-party service, data leaves the model boundary. The terms of that tool and your access settings govern this route, not just the model provider’s promise.

So “the model is not trained” addresses the first item. The other three need separate checks, settings, and often separate documents.

Training example: one contract, three routes

This scenario is fictional and is included only for illustration. A manager uploads a supplier contract to a company AI chat and asks it to list payment terms and penalties. To verify the details, the model uses a connector to query the CRM and retrieve the counterparty’s record. The answer is useful, so the manager gives it a positive rating and adds a comment.

For the person responsible for data, this is not one event but three independent routes:

The lesson is simple. A company may have training disabled while the contract remains in chat history, counterparty data passes through a connector, and feedback enters a separate provider mechanism. Each route needs its own decision and owner.

What OpenAI and Anthropic promise: a comparison of the rules

The table below includes only information confirmed in provider documentation for the research conducted on 11 October 2026. Where a specific value is unavailable, we say “confirm.” An unknown retention period is not zero, and those cells should not be filled with guesses.

What does this table not claim? It does not say that either service is “completely safe.” It does not say that using a service automatically complies with GDPR or other personal-data requirements. That is a separate question, dependent on your process, legal basis for processing, and contracts. The table also does not cover connectors, plugins, or other tools through which data may travel onward.

A separate note on ZDR (Zero Data Retention). It is not another term for opting out of training. An opt-out from training describes whether your data is used to improve a model. ZDR describes retention conditions and, according to OpenAI documentation, applies to defined API capabilities. In other words, it is not available for every use case. If your architecture depends on ZDR, check every feature you enable, not just the mode’s name.

Where exceptions arise

Most unpleasant surprises come from exceptions to the main rule. Here are five areas to check first.

Feedback. Response-rating buttons look harmless, so they are rarely discussed when choosing a plan. Anthropic explicitly says that submitted feedback may be used for training and that an administrator can disable this mechanism. Decide whether you need ratings at all. If so, agree on which data must not be rated and check the relevant setting in the admin console.

Files. An uploaded document becomes part of a chat or project history. Check where the file is stored, which colleagues can see it, whether it is deleted with the chat, and what happens to it when an employee’s account is removed. Answers vary by product, so look in the documentation for your specific plan rather than a general provider article.

Integrations and connectors. The model provider’s promise does not extend to a CRM, email, cloud drive, or third-party plugin. Each tool has its own terms, logs, and access permissions. A connector acting on behalf of an employee with broad permissions may expose more data to the model than the task requires. Restrict connector permissions as carefully as you would a new employee’s access.

Special models. Anthropic’s data-retention help separately mentions exceptions, including Covered Models. If your use case relies on models or features with separate terms, find out which rules apply to those specifically, rather than to the product as a whole.

Contractual modes. Some terms apply as a separate mode rather than by default. One example is OpenAI ZDR, which applies to defined API capabilities. Record in the contract or official correspondence with the provider which modes apply to your organization, and keep those documents with the date.

What an administrator should check before connecting a service

Use the list below as a working document. It is not tied to one provider; only the places where you look for answers will change.

Permitted data categories. Divide company data into groups: public; internal; confidential commercial; personal data about customers and employees; passwords, keys, and tokens. Assign each group one of three statuses: allowed, allowed with conditions, or prohibited. We recommend always prohibiting passwords and access keys. This security-hygiene rule does not depend on the plan.

Workspace settings. Check the admin console for what your plan lets you change: feedback, available connectors, who can connect them, and sharing rules for chats and projects. Record the current values and the date. This will help you notice later if settings have changed.

Roles. Identify the administrator, who can access other employees’ conversations or export data, and who approves new integrations. The fewer people with broad permissions, the easier it is to determine who saw specific data and when.

Deletion periods. Find out what happens to chats and files when an employee deletes them and when the employee leaves the company. Compare those periods with your internal document-retention policy. If the documentation does not answer the question, mark it as open with the provider instead of treating it as “zero.”

API and modes. If the company integrates a model through an API, list the capabilities actually in use and check the retention mode for each. A new feature added by developers later may have different terms from the ones you checked at launch.

Contract and records. Keep the business terms, data-processing agreement (if required in your case), and policy versions with their review date in one folder. Separately record how the provider announces changes and who in your company reads those notices. Our article on GDPR and HIPAA covers processor agreements and personal-data requirements in more detail.

How to decide: an approved-use-case record

A general rule that “AI is allowed” or “AI is not allowed” does not work in practice. An employee will not know whether a ban covers a short customer email, and a permission does not answer a question about a medical certificate. A decision for a specific use case works better. We suggest recording it in a short, one-page use-case document.

Why name an owner and a review date? Provider terms change, and new features appear without your involvement. A record made once may describe a different product six months later.

What to do next:

1. List two or three real use cases where employees already use or want to use AI.
2. Map data routes for each, as in the contract example: conversation and files, integrations, and feedback.
3. Fill in the provider-rules table and the date you checked it. Mark unknown values as open questions.
4. Check admin settings for feedback, connectors, roles, and deletion.
5. Create a use-case record for each scenario and assign an owner to review the terms again by a set date.

It is normal to still have open questions for the provider after this. It is better to know exactly what you do not know than to rely on a general statement about security.

Frequently asked questions