What should we read first?

The clause on what the vendor may do with your material beyond delivering the service, and whether the training answer is recorded there at all rather than in a settings page. Then who else may touch it, what notice you get when that changes, and what happens when you leave.

Is a product setting not enough?

A setting is a configuration that can change; a contract is a commitment that constrains what happens next. Where a training or retention answer matters to you, having it in the agreement rather than in a preferences screen is the difference between a promise and a current state.

Larger buyers do and smaller ones usually accept the standard version, which is a reasonable position rather than a failure. The valuable step available to everybody is reading the few clauses that vary, so that whatever you accepted was accepted knowingly.

Why does it matter more for AI tools?

Because the material sent is frequently unstructured and richer than anybody intends, and because the chain behind your vendor is often longer. The training clause has no real equivalent in ordinary software contracts, and it is the one an AI buyer most needs to have read.

Glossary

Data processing agreement (DPA)

The contract setting out what a vendor may do with personal information you send them, which is usually settled before any real material moves.

In plain terms

A contract about your material rather than about the software. It records what the vendor may do with information about people that you send them, what they may not, who else may touch it, and what happens when you stop being a customer. Most vendors have a standard one, most buyers sign it unread, and the parts that matter for AI are usually only a few paragraphs.

Why it matters

Because it is where the answers actually live. A vendor's marketing describes intentions, a certification describes process, and this document describes what they may do, in terms that would be enforced. For an AI buyer the question worth asking is where the training commitment sits: if the answer is a settings page or a help article rather than the agreement, that is the difference between a current configuration and something that constrains what happens next.

How it works

It records the division of responsibility, which is the shape of the whole document. One party decides what happens to the material and the other handles it on their behalf and within instructions. Almost everything else in the contract elaborates what the second may do, and reading it with that structure in mind makes an otherwise dense document navigable.

The clause an AI buyer should find first is what the vendor may do with your material beyond delivering the service. Whether it may be used to improve or train models, whether that is on by default, and whether it can be switched off are the questions. Ask where each answer is recorded, because an answer in the agreement holds and an answer in a preferences screen is true only until the screen changes.

It names the others who may touch the material, usually by reference to a list, and says what notice you get before that list changes. That mechanism matters more for AI tools than for most software, because the chain is frequently longer than buyers expect and a model provider behind your vendor is a party to what happens to your material.

It says what happens at the end, and that clause is easy to skip while signing up. Whether material is returned or deleted, how quickly, and what remains in backups for how long are all settled here. Leaving a vendor is exactly when you most want that to have been agreed in advance.

The standard version is usually reasonable and usually not negotiated by smaller buyers, which is a legitimate position rather than a failure. The useful thing a smaller buyer can do is read the four points above and know what they have agreed to, since knowing you accepted something is a different position from not knowing what it says.

Where the same answer can live

This distinction is worth holding because the left-hand version is genuinely reassuring and genuinely sufficient much of the time. A toggle set correctly does what it says, and for exploratory work nobody needs more than that. What changes is not the truthfulness of the setting but who is relying on it and for how long: once a tool is embedded in real work, the question becomes what was agreed rather than what is currently configured, and a configuration cannot answer it retrospectively. The practical consequence is a timing one. The agreement is easiest to obtain at the point of purchase, when a vendor is arranging things for you anyway, and hardest to raise a year later when nothing has gone wrong and the request needs explaining. That asymmetry argues for reading it early even where the setting would have done.

Seen in the wild

Finding whether an assistant's agreement rules out using your material for training, or merely lets you turn it off in a setting.
ChatGPT
Checking the list of other companies a search vendor may pass material to before it reaches across internal systems.
Glean
Reading what happens to stored records and credentials when an automation account is closed.
Make

Common misconceptions

People assume

It is boilerplate, so there is nothing to read.

In fact

Most of it is standard and four paragraphs are not: what may be done with your material beyond delivering the service, who else may touch it, what notice you get when that changes, and what happens at the end. Those differ between vendors and are the reason to open the document at all.

People assume

A setting in the product covers the same ground.

In fact

A setting is a current configuration and a contract is a commitment. Both may say material is not used for training, and only one of them constrains what happens after an interface is redesigned. For anything that matters, having it in the agreement is what makes it durable.

Telling them apart

Data processing agreement vs GDPR

Data processing agreement

The specific contract with one vendor. Readable, and sometimes negotiable.

GDPR

The regime that made this document standard practice.

You can sign one of these. The other is why it was put in front of you.

Questions

What should we read first?: The clause on what the vendor may do with your material beyond delivering the service, and whether the training answer is recorded there at all rather than in a settings page. Then who else may touch it, what notice you get when that changes, and what happens when you leave.
Is a product setting not enough?: A setting is a configuration that can change; a contract is a commitment that constrains what happens next. Where a training or retention answer matters to you, having it in the agreement rather than in a preferences screen is the difference between a promise and a current state.
Can we negotiate it?: Larger buyers do and smaller ones usually accept the standard version, which is a reasonable position rather than a failure. The valuable step available to everybody is reading the few clauses that vary, so that whatever you accepted was accepted knowingly.
Why does it matter more for AI tools?: Because the material sent is frequently unstructured and richer than anybody intends, and because the chain behind your vendor is often longer. The training clause has no real equivalent in ordinary software contracts, and it is the one an AI buyer most needs to have read.

Key takeaways

It records what the vendor may do with your material, in enforceable terms.
The training clause is the one with no equivalent in ordinary software contracts.
It names who else may touch the material and what notice you get.
The end-of-relationship clause is settled at the start and needed at the end.
A contract commitment and a product setting are different things.

Tools that use this

ChatGPT
Whether training is ruled out contractually or merely switchable in a setting.
Glean
The list of others who may touch material reaching across internal systems.
Make
What happens to stored records and credentials when an account closes.