AI data terms in Microsoft contracts, three documents, four data types
Microsoft AI services run on three overlapping contracts, the MCA or EA, the Product Terms, and the Data Protection Addendum, and every clause on AI data usage lives in one of them. The 2025 and 2026 Product Terms added specific Copilot and Azure OpenAI language that splits Customer Data, prompts, completions, and telemetry into different commitments, and the differences are where the negotiation lives.
Prepared by Redress Compliance · August 6, 2026 · Microsoft advisory. Based on the AI contract negotiation record of the Microsoft practice.
Executive summary
Three documents hold every clause. The Microsoft Customer Agreement or Enterprise Agreement carries the commercial frame, the Product Terms carry the service specific commitments, and the Data Protection Addendum carries the privacy machinery.
The 2025 and 2026 Product Terms versions added specific language for Copilot, Azure OpenAI Service, Azure AI Foundry, and Copilot Studio, and knowing which document holds which clause is half the negotiation, because amendments land document by document.
Customer Data is protected by default; confirm it in writing anyway.
Microsoft's contracts do not train foundation models on Customer Data by default, and the written confirmation, scoped to your services and referenced to the current Product Terms version, is the sentence that survives reorganizations, service renames.
And clause evolution. Prompt and Completion content is treated as Customer Data in current terms, but the clause has evolved across versions, which is exactly why the version reference matters.
Abuse monitoring stores prompts. Azure OpenAI Service retains prompts and completions for 30 days for abuse monitoring unless the customer applies for and receives an exception, a stored copy most deployments never knew existed.
For regulated workloads the exception application is a standard step, and for everyone it is a disclosure the internal privacy review should hold before launch.
Residency is negotiable terrain. The EU Data Boundary, in country processing, and named region commitments are all available on enterprise paper for buyers who ask, and unavailable to those who assume the defaults.
The four data types, Customer Data, prompts, completions, and product telemetry, each carry their own residency and retention posture, and the negotiation maps each type to its requirement rather than accepting one blended answer.
The contract stack, which document holds what
| Document | What it holds | The negotiation surface |
|---|---|---|
| The MCA or EA | The commercial frame the services ride inside | Where custom amendments and written confirmations actually attach |
| The Product Terms | Service specific commitments: Copilot, Azure OpenAI, Foundry, Copilot Studio | Version referenced clauses, because the terms evolve release by release |
| The Data Protection Addendum | The privacy machinery: processing roles, security, subprocessors | The residency commitments and the audit rights the regulators ask about |
The stack updates itself; your amendments do not. Product Terms change on Microsoft's cadence, and a protection that exists as a default today is a version away from evolution, which is what already happened to the prompt and completion clause.
The clauses your compliance posture depends on belong as written, version referenced commitments on the enterprise paper, not as screenshots of a website that will change.
The four data types, and what each commitment says
- Customer Data. The protected category: not used to train foundation models by default, processed under the DPA's machinery, and the anchor every other commitment references.
- Prompt content. Treated as Customer Data in current Product Terms, after evolution across versions, and stored by Azure OpenAI abuse monitoring for 30 days absent an exception.
- Completion content. The model's outputs, paired with prompts in the current treatment, and the category where ownership and usage rights deserve explicit language.
- Product telemetry. The service metadata outside the Customer Data commitments, on its own retention and usage posture, and the category blended answers quietly hide.
The enterprise AI contract negotiation playbook
The AI clause set across the vendor estate: the data usage confirmations, the retention and residency asks, the consumption terms, and the amendment language that survives version changes.
Get the white paper →The asks that negotiate, and the ones to verify
The negotiable set is concrete: the written no training confirmation scoped to your services, the abuse monitoring exception for regulated workloads, the EU Data Boundary or named region commitments per data type, retention periods stated in numbers.
And subprocessor change notification with objection rights.
Each ask is routine on enterprise paper and absent by default, and together they form the AI annex the Copilot and Azure OpenAI licensing analysis assumes and the Azure agreement negotiation attaches.
The verification set is the quieter work: which Product Terms version your services actually run under, whether the Copilot Studio and Foundry language reaches your custom agents, and how the commitments interact with the permission sprawl the assistants inherit.
The exposure the assistant comparison flags as landing before any productivity gain.
The contract answers are necessary and not sufficient; the deployment has to honor them.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What the negotiation record shows
Customer Data not training foundation models, the baseline worth confirming in writing rather than renegotiating.
The abuse monitoring retention carve out, standard for regulated workloads and unknown to most deployments.
The pattern across the AI contract work is asymmetric effort: the protective defaults are stronger than buyers assume, and the gaps, the 30 day retention, the telemetry category, the version drift, are narrower but completely invisible until mapped.
The mapping is an afternoon with the three documents; the alternative is discovering the stored prompts during a regulator's questionnaire.
Your first five moves
- Map every AI service to its documents: which Product Terms version, which DPA commitments, which agreement carries the amendments.
- Confirm the no training posture in writing, version referenced, scoped to your services, on the enterprise paper.
- Apply for the abuse monitoring exception where regulated workloads run on Azure OpenAI, and disclose the 30 day retention internally either way.
- Negotiate residency per data type: Customer Data, prompts, completions, and telemetry each mapped to their requirement, never one blended answer.
- Re verify at every Product Terms revision, because the clauses evolve and the deployment inherits whatever they become. The Microsoft practice and Vendor Shield hold the watch with you.
Frequently asked questions
Where do Microsoft's AI data usage terms actually live?
In three overlapping documents: the MCA or EA carrying the commercial frame and any amendments, the Product Terms carrying service specific commitments for Copilot, Azure OpenAI, Foundry, and Copilot Studio, and the Data Protection Addendum carrying the privacy machinery.
Every clause sits in exactly one, and amendments attach document by document.
Does Microsoft train AI models on our data?
Not on Customer Data by default under current contracts, and prompt and completion content is treated as Customer Data in the current Product Terms.
The clause has evolved across versions, which is why the written, version referenced confirmation on enterprise paper is the standard ask rather than paranoia.
Does Azure OpenAI store our prompts?
Yes, for 30 days for abuse monitoring, unless the customer applies for and receives an exception. Most deployments never knew the stored copy existed, which makes the exception application standard for regulated workloads and the internal disclosure mandatory for everyone before launch.
Can data residency be negotiated for Microsoft AI services?
Yes: the EU Data Boundary, in country processing, and named region commitments are available on enterprise agreements for buyers who ask, mapped per data type.
Customer Data, prompts, completions, and telemetry each carry their own residency and retention posture, and the blended answer hides the one that matters.
What AI privacy terms should be confirmed in writing?
The no training confirmation scoped to your services and referenced to the Product Terms version, the abuse monitoring posture, retention periods in numbers, residency per data type, and subprocessor notification rights.
Each is routine on enterprise paper and absent by default, and the version reference is what survives clause evolution.
How often should the AI contract terms be re verified?
At every Product Terms revision, because the terms update on Microsoft's cadence and the deployment inherits whatever they become: the prompt and completion treatment has already evolved across versions.
The standing review, three documents against your service map, is an afternoon that keeps the compliance posture real.
