Chapter 1. Vendor policies and data terms

Learning objectives

• Distinguish what terms of service, usage policies, privacy policies and Data Processing Addenda (DPAs) each govern.
• Compare data terms by access route, separating a vendor's consumer plans, enterprise plans, API and cloud-mediated use.
• Read training use, retention, human review, data location and contractual processing status as independent questions, and identify the exceptions to each.
• Check vendor usage policy effective dates and high-risk use requirements, and reflect them in organizational rules.
• Create and update a plan-by-plan data terms comparison table with supporting documents and check dates.

Introduction

Suppose a company's planning team leader says, "I have a paid account, so it is safe to put company documents into it." This statement combines three misconceptions: that payment determines the terms, that "not used for training" means "not retained", and that terms accepted by an individual protect the company.

An AI tool's data terms appear in contractual documents, not on its product screen. Those documents differ depending on who uses which plan and through which route. Even for the same model, different terms govern a personal-account chat app, a business plan contracted by the company, an API called by developers and a managed model accessed through a cloud provider.

All figures and settings in the tables are as of the check date, and the tasks ask you to check them again yourself. This chapter first maps vendor document types and their roles, then explains how to specify the access route. It next divides data terms into five independent questions, using official OpenAI, Anthropic, Google, Microsoft and AWS documents as examples. Finally, it covers usage policies and output clauses, and how to consolidate and update everything in one comparison table.

Key concepts

A map of contractual documents

Your relationship with a vendor is governed by a set of documents, not a single sheet. Each document answers a different question.

A Data Processing Addendum (DPA) contractually establishes the terms on which a vendor processes data entrusted by a customer. If the terms of service are a building lease, the DPA is an agreement on how entrusted property is stored and returned. A help page is more like a building information sign. Changing the sign does not automatically change the contract, but the sign may explain actual operations most accurately.

The order of precedence among conflicting documents also differs by contract, so record both the supporting document and its relevant provision in the comparison table.

Same company, different terms

Even within the same vendor, a consumer plan that an individual signs up for and a commercial product contracted by an organization have different terms. It is like a bank: personal and corporate accounts have different agreements. Depositing more money in a personal account does not make the corporate agreement apply.

Major vendors' official documents state the following training defaults.

Specify the access route first

Before comparing, specify in one line which route is used. There are several routes to the same model.

1. An app with a personal account: The employee is the contracting party.
2. An organization-contracted business plan: The company contracts and issues accounts.
3. The vendor's direct API: This has terms distinct from its business chat plan.
4. Through a cloud provider: Managed models on AWS, Azure or Google Cloud. The cloud provider's terms and DPA are the starting point.
5. An AI feature embedded in another product: Check that SaaS product's terms and subprocessor terms together.

Anthropic states that when Claude is used through a third-party platform, that platform's terms govern use. Microsoft also states that Copilot can use Anthropic and OpenAI models as subprocessors, that admins decide whether to enable them, and that additional terms may apply. Without specifying the route, you may reach an incorrect conclusion based on documents for a different route.

Always put the product name, plan, contracting party, access route and check date at the top of the comparison table.

From three axes to five questions

The three basic axes for reading vendor data terms are training use, retention and contractual processing status. In practice, it is safer to add two more and read them as five questions.

The five questions are independent. A product that does not use data for training may still retain it for 30 days, and data stored in Korea may be processed abroad.

Training defaults and exceptions

Commercial products generally promise no training use by default. The exceptions that follow are what matter in exams and practice.

• Feedback: Anthropic states that even for commercial products, conversations explicitly submitted with feedback or bug reports may be used for training, and that the entire conversation attached to thumbs-up or thumbs-down feedback is retained for up to 5 years. Microsoft explains that optional feedback may improve Copilot but is not used to train foundation LLMs, and that admins can manage feedback.
• Explicit opt-in: OpenAI API data sharing occurs if the customer opts in through the dashboard.
• Personal settings on consumer plans: Training use for personal accounts generally follows individual settings. Even with training turned off, conversations submitted with feedback (OpenAI) or flagged for safety review (Anthropic) may be exceptions. The company cannot view or enforce those settings.

Retention: defaults, admin settings and zero retention

Retention concerns how long data remains in the vendor's systems. Representative terms stated in official documents are as follows.

Zero Data Retention (ZDR) is a condition under which a vendor does not record requests and responses in abuse monitoring logs and similar records. It is usually obtained through approval or a separate contract, not a settings switch. Nor does zero retention cover every feature. OpenAI documentation excludes features that need server storage, such as conversation state and files, and explains that Responses API storage is always treated as disabled for zero retention organizations. Safety exceptions remain. OpenAI states that image and file inputs are checked for child sexual abuse material; flagged images are retained for human review even under zero retention. It may also exclude certain models from zero retention for specific customers after prior written notice.

Human review and abuse monitoring

Abuse monitoring is the process through which a vendor automatically classifies requests and responses to detect usage policy violations and has a person inspect them when necessary. Its purpose differs from training, but organizations handling confidential material must ask whether vendor staff can view it, as well as whether it is used for training.

• Microsoft explains that, for models sold by Azure in Foundry (including Azure OpenAI), samples are automatically reviewed when abuse signals are detected, with human review by authorized Microsoft staff when necessary. Managed customers can apply for Modified Abuse Monitoring; approval disables storage for human review. Microsoft Copilot services are excluded from this form of human-review abuse monitoring.
• AWS Amazon Bedrock controls data retention through data_retention_mode. none means zero retention, with requests and responses not written to persistent storage; default follows model-specific defaults; aws_review permits AWS to conduct human review within its boundary. An account set below a model's required mode cannot invoke that model.

Bedrock illustrates the principle that an organization sets its retention policy first and uses only models meeting it. Its documentation also gives examples of enforcing zero retention across an organization through service control policies (SCPs) and IAM condition keys.

Storage location and processing location

Data residency sets where data is stored and processed. Here too, separate two questions: storage location is where data rests; processing location is where the model actually computes.

• The OpenAI API region table lists South Korea as a region that supports storage but not in-region processing. In regions without processing support, customer content may be processed and temporarily stored outside the region. Using a non-US region requires approval for zero retention or Modified Abuse Monitoring.
• Microsoft Foundry processing locations differ by deployment type. Standard deployments process within the customer's designated geography; "Global" deployments can process in any region where the model is deployed; "DataZone" deployments can process within the designated data zone. In all cases, data at rest remains in the customer's designated geography.
• Microsoft Copilot applies the EU Data Boundary for EU users, but states that Anthropic models provided as subprocessors are currently excluded from it.

Overseas processing leads to the cross-border transfer review in Chapter 3. Do not leave cross-border transfer entries blank in the privacy policy based only on domestic storage without checking processing locations.

DPA and processing status

From a PIPA perspective, a vendor can have two roles. When processing customer data on the customer's instructions, it is a processor, comparable to an entrusted processor under Korean law. When using data for its own purposes, it is a controller that determines those purposes itself. A DPA contractually governs the former relationship.

Microsoft's web search example shows how contractual status can differ between features in one product. Its documentation explains that queries are usually a few words extracted from a prompt (a very short prompt may be included in full), and that Microsoft Entra ID-based identifying information is removed. This does not mean names within the prompt are removed, and the contractual status is different too.

Reading usage policies

A Usage Policy (AUP) defines prohibited uses and uses subject to additional conditions. Data terms answer "How is data handled?"; a usage policy answers "What may it be used for?" Check three things first.

1. Effective date and version: As of the check date, Anthropic's usage policy page displays a revision effective 12 November 2026; until then, the version effective 15 September 2025 applies. OpenAI's latest usage policy is marked effective 29 October 2025. When a revision is posted in advance, record both the currently applicable version and the upcoming version.
2. Structure: Anthropic's policy comprises universal usage standards applying to all uses, high-risk use case requirements for uses posing a greater risk of harm to individuals, and additional guidelines for consumer-facing chatbots, agents, services for minors and agentic use, among others.
3. High-risk use requirements: The 2025 version lists legal, healthcare, insurance, financial, employment and housing, academic testing, certification and admissions, and media and journalism content as high-risk areas. It requires a qualified professional in the field to review content before deployment or finalization, and disclosure of AI use. The November 2026 revision reorganizes these into eleven areas: legal, healthcare, financial, credit, insurance, housing, employment, education and qualifications, access to healthcare, public benefits and services, and legal status and determinations. It requires meaningful review by a qualified person with authority to change or correct the outcome, and clear disclosure of AI use. The revision excludes tasks such as internal drafting that do not actually deliver high-risk recommendations. Where lawful, it also does not require prior human review for the entirely favorable decisions it lists, such as paying insurance claims or providing public benefits. Partial approvals or reduced amounts do not qualify.

Both versions require consumer-facing chatbots and AI agents conversing with external users to disclose that users are interacting with AI rather than a human. The revision specifies disclosure at the start of each conversation session or in the product interface. The vendor or model name need not be disclosed.

Output rights and indemnity conditions

Output clauses generally cover ownership, commitments to defend and compensate against third-party rights infringement claims, and conditions for those commitments.

Microsoft states that it does not claim ownership of Copilot outputs, but does not determine whether they qualify for copyright protection. It also promises to defend commercial customers sued for copyright infringement arising from Copilot or its outputs, and to pay adverse judgments or settlements, on condition that customers used the product's built-in guardrails and content filters.

The principle is simple: indemnity commitments are conditional, and use that fails to satisfy the conditions falls outside the commitment. Bypassing filters may forfeit contractual protection, so record both the indemnity commitment and its conditions in the comparison table.

Building a plan-by-plan data terms comparison table

This chapter's practical skill is comparing data terms across plans. Build the table as follows.

1. Specify the routes to compare. Even for the same vendor, give consumer plans, business plans and the API separate columns.
2. Break the five questions into rows: training default, training exceptions, default retention, admin retention settings, zero retention availability and conditions, human review, storage location, processing location, DPA, subprocessors, usage policy version and indemnity conditions.
3. Put an official document link, supporting sentence and check date in each cell.
4. Mark missing information "Unconfirmed" rather than leaving cells blank, and irrelevant cells "Not applicable". Add unconfirmed items to a vendor inquiry list.
5. Below the table, state conditionally which data levels may be entered through each route.
6. Set a recheck date. Also recheck on terms revision notices, contract renewal and introduction of new features.

Going deeper

More features mean more data routes

A new feature on an approved tool creates a new route for data to leave. Web search sends data to search engines, connectors send data to other repositories, and agents and external tool connections send data to third-party services. OpenAI documentation states that remote MCP servers (Model Context Protocol servers connecting external tools to models) are third-party services with their own retention policies. Microsoft documentation advises checking an agent's own privacy policy and terms when using Copilot agents.

Manage approval at feature level, not just tool level. Copilot has different contractual status with web search on or off, and even the same API's zero retention coverage differs depending on file storage use. When a feature launches, copy the relevant comparison-table column, add feature-specific rows, and reconsider whether existing approval conditions can apply unchanged.

Vendor terms themselves also change. This chapter alone included an upcoming usage policy revision and renamed products. Assign an owner and recheck interval to each key document, receive subprocessor and policy change notices at a team address rather than an individual's, and when a document changes, trace back and reopen approval conditions that depend on it. This traceability is why supporting documents and check dates belong in the table.

The cost of zero retention

Zero retention has costs. Features that keep server state, such as conversation history, file storage and batch processing, may be unavailable or require your own implementation. Models available only with safety review cannot be invoked from zero retention accounts (Bedrock and Anthropic Covered Models), and approval procedures and additional requirements apply.

"Zero retention for all data" is therefore not always the right answer. Start with the data level. For data whose vendor retention is contractually prohibited or whose storage location is restricted by law, choose zero retention and compatible features. For internally shareable data, default 30-day retention and no training use may suffice. Base the decision on data classification and contractual requirements, not a vague sense of reassurance from choosing the strictest option.

At work

Wave Daily: before bringing AI into the newsroom

The editor-in-chief of the local newspaper Wave Daily learned that reporters wanted AI for proofreading drafts and classifying reader comments. An internal survey found several reporters pasting reporting notes into paid personal accounts. Those notes included contact details of sources promised anonymity.

The information security officer first separated the routes. Reporters' personal accounts were under consumer terms, and training depended on individual settings; the company could not control retention or accounts. The claim "It is paid, so it is fine" was rejected because payment does not change which category of terms of service applies.

Next, two business plans and an API were compared using the five questions. Both business plans defaulted to no training use but had feedback exceptions, so the officer checked whether feedback submission could be disabled in admin settings. Notes containing source information were prohibited through every route. Someone suggested applying for zero retention, but the issue was the promise to protect sources, not the retention period. Prohibiting input was the appropriate control.

The officer also checked usage policies. The Anthropic policy then in force treated automated creation and external publication of media and journalism content as high-risk; the posted revision removed that area from the list. The officer decided to retain the company rule that no AI-written text could be published without human review, even after the revision took effect. A relaxation of vendor policy did not change editorial responsibility. Developers would classify reader comments through the API without stateful features, so the original comments would remain only for the default retention period.

The outcome was a business plan contract, disabled feedback submission, a custom retention period, a ban on entering source information, and a comparison table recording both usage policy versions. The criterion was whether each of the five questions allowed the newspaper to keep its promises, rather than which company was better known.

Dasom Trading: reading contracts through a cloud provider

Dasom Trading wants an internal pipeline that extracts payment terms and dispute clauses from import and export contracts. The contracts include names and contact details of counterparties' staff. Some nondisclosure agreements state that contract information must not be processed outside countries designated by the company. The company already has an organization-wide agreement with a cloud provider.

Developers proposed using the model developer's API directly. The legal officer placed the two routes side by side. A direct API required a fresh review of commercial terms and the DPA, plus a separate check of in-region processing in the desired country. The cloud route could reuse the existing DPA and security review, but processing locations could broaden depending on deployment type.

The officer checked processing locations by deployment type in the cloud documentation. Global deployments could process in any region where the model was deployed, conflicting with the nondisclosure agreement. Standard deployments limited to the designated geography could meet the condition. The officer also confirmed that abuse monitoring could store some requests for human review, and asked about eligibility for Modified Abuse Monitoring.

Developers wanted to upload original contracts to a file store for repeated queries, but that would leave the originals in the service. The officer required keeping originals in the company repository and sending only necessary clauses with each request. Costs rose slightly, but the company retained control over storage scope.

The decision memo recorded rejected options and reasons (direct API deferred; global deployment and file storage rejected), plus the statement that the decision was as of the check date and would be reviewed if deployment documentation changed.

Common mistakes

1. "If it is paid, enterprise terms apply." Payment and the type of terms are separate. Individually paid plans are usually consumer plans, with the individual rather than the company as the contracting party.
2. "If it is not used for training, it is not stored." Training and retention are separate questions. APIs also have default retention for abuse monitoring.
3. "You can just switch on zero retention." Zero retention usually requires approval or a separate agreement, and stateful features may be excluded.
4. "Domestic storage means no overseas processing." Storage and processing locations are determined separately. Check processing support in the region table.
5. "Every feature in one product has the same DPA." Some features within a product, such as web search queries, fall outside the DPA.
6. "If the vendor's usage policy allows it, it is legally fine." A usage policy is a contractual condition with the vendor; legal and customer contractual obligations require separate review.
7. "With indemnity, how we use outputs does not matter." Indemnity is conditional. Bypassing built-in filters can breach those conditions.

Summary at a glance

Check the official docs

• OpenAI — Business data privacy, security, and compliance: No training use for enterprise products, retention controls and DPA.
• OpenAI — Data controls in the OpenAI platform: API training default, 30-day abuse logs, zero retention approval conditions, feature-specific retention and region table.
• Anthropic Privacy Center: Training use by commercial and consumer plan, retention periods, custom retention and DPA.
• Anthropic — Usage Policy: Effective dates, universal standards, high-risk requirements and chatbot disclosure. Also use the page's Previous Version link to read the currently applicable version.
• Google — Generative AI in Google Workspace Privacy Hub: Gemini data protection commitments, CDPA and retention settings.
• Microsoft Learn — Data, Privacy, and Security for Microsoft Copilot: No training use, permissions model, EU Data Boundary, subprocessors and copyright defense conditions.
• Microsoft Learn — Data, privacy, and security for Foundry Models sold by Azure: Processing locations by deployment type and abuse monitoring.
• AWS — Amazon Bedrock data retention: Retention modes and enforcing organizational policies.

Self-check

1-1. List the five questions used to read vendor data terms, and select the two most often confused with training use.

1-2. Explain in one line each what question terms of service, usage policies and DPAs answer.

1-3. A developer says, "Our organization has zero retention approval, so material uploaded to file storage and conversation-state features will not remain with the vendor either." Identify the problem in light of OpenAI's official documentation.

1-4. State what must be checked about processing locations for an OpenAI API project using the South Korea region, and how the result affects drafting a privacy policy.

1-5. Give one example in which the vendor's contractual processing status differs by feature within a product, and state how organizational rules must address that difference.

1-6. A currently applicable usage policy and an upcoming revision are posted together. State what the usage policy row in the comparison table must record, and two internal checks needed before the revision takes effect.

1-7. (Design) Design at least six comparison-table rows for an AI tool your company uses, and identify the evidence for each cell. Include how to handle "Unconfirmed" cells.

Hands-on tasks