Glossary
GDPRGeneral Data Protection Regulation
The European data protection regime, which shapes how personal data may be used and which companies far outside Europe routinely work to because of whose data they hold.
In plain terms
A European regime governing what may be done with information about people. Most software buyers meet it indirectly rather than by reading it: it is the reason a vendor offers a particular contract about data, publishes a list of the other companies it passes material to, and can tell you which country your material sits in. If you have wondered why those documents exist and why every vendor seems to have the same ones, this is largely the answer.
Why it matters
Because it shaped the vocabulary and the paperwork of software purchasing well beyond the place it applies, and a buyer who does not recognise it finds the questions arbitrary. Knowing why a vendor offers what it offers turns a procurement exercise from a list of documents to collect into a set of things you can actually evaluate against each other, which is the difference between completing a review and getting something out of one.
How it works
It attaches to whose information is involved rather than to where a company happens to sit, which is why organisations with no European office still work to it. A business anywhere handling information about people in Europe can find itself in scope, and that reach is the reason the regime became a common denominator: it was simpler for many vendors to build one way of working than to maintain two.
It distinguishes between the party deciding what happens to information and the party doing the handling on their behalf. Most of the vendor paperwork a buyer meets exists to record which is which and what the second may do. That distinction is worth recognising because it explains the shape of the documents, and where the line falls in your particular case is a question for somebody qualified.
It is the reason a sub-processor list exists and is published. Your vendor uses other companies to deliver its service, those companies also touch the material, and the practice of naming them and giving notice before the list changes comes from this lineage. For an AI buyer it is one of the more useful documents available, because it shows the actual path material takes.
It is why the location question has an answer at all. Vendors offer a choice of region, and can tell you where processing happens, largely because this regime made that a thing buyers ask. Whether a location commitment settles your situation is a separate question and frequently a more complicated one, which is what the data sovereignty page is about.
It is why the standard vendor commitments about AI training took the shape they did. Being able to say material will not be used to improve a model, and to say it contractually rather than in a help page, is a response to buyers who had to be able to describe what happened to what they sent. The commitment is now offered widely and its origins are here.
It gave people rights over information held about them, and the operational consequence for a buyer is that somebody may ask you to act on material you hold. What that means in practice is on the data subject request page. What it means is that scattering material across many tools has a cost that is invisible until the first time somebody asks.
Where this page stops is where the advice starts, deliberately. Whether you are in scope, what basis you are relying on, what you owe and to whom are questions whose answers turn on specifics, and a general version of them would be confidently wrong for most readers. The useful thing a glossary can do is explain why the documents exist so a buyer can read them.
What you can compare, and what you cannot
Seen in the wild
Comparing what an assistant's administered tier commits to about training and retention against what its individual tier says.
ChatGPTReading which other companies a vendor passes material to before pointing a search tool across internal systems.
GleanChecking where an automation platform processes the records flowing through it, which is a question vendors expect.
MakeRunning a model on your own hardware, where the question of what leaves does not arise because nothing does.
Ollama
Common misconceptions
People assume
It does not apply to us, we are not in Europe.
In fact
It attaches to whose information is involved rather than to where an office is, so organisations well outside Europe commonly find themselves working to it. Many vendors adopted one way of working for everybody rather than maintaining two, which is why its vocabulary turns up in purchasing conversations with no European element at all.
People assume
It is a checkbox in a vendor's marketing.
In fact
What a vendor can actually offer is a set of specific documents and commitments: a contract about data handling, a published list of the companies it passes material to, an answer about where processing happens. Those are readable and comparable between vendors, which a claim of compliance on a web page is not.
People assume
Using a compliant vendor makes us compliant.
In fact
A vendor can only account for what a vendor does. What material you send, what you told people about it and what you do with the results stay yours, which is why the paperwork records a division of responsibility rather than transferring it. Where exactly that line falls in your case is a question for somebody qualified.
Telling them apart
GDPR vs Data processing agreement
GDPR
The regime that shaped what vendors offer and what buyers ask.
The specific contract with one vendor about what they may do.
One is the reason the document exists; the other is the document, and only the second is negotiable.
Questions
- Why does this come up when we have no European operation?
- Because it attaches to whose information is involved rather than to where a company sits, and because many vendors built one way of working for all customers instead of two. The result is that its vocabulary and its documents are now the common denominator of software purchasing almost everywhere.
- What can we actually ask a vendor for?
- The specific things rather than an assurance: the contract about data handling, the published list of other companies they pass material to, an answer about where processing happens, and what they commit to about using your material to improve their models. Those four are comparable between vendors and a compliance badge is not.
- What does it explain about AI tools particularly?
- Why the training commitment exists in contractual form, why administered tiers offer terms that individual ones do not, and why a vendor can tell you which region your material is processed in. Those all predate AI products and were carried into them, which is why they arrived fully formed.
- Why does this page not list the requirements?
- Because whether you are in scope, what you are relying on and what follows all turn on specifics, and a general version would be confidently wrong for most readers who found it by searching. Explaining why the documents exist is genuinely useful and is something a glossary can do accurately.
Key takeaways
- It attaches to whose information is involved, not to where your office is.
- Most buyers meet it as paperwork: a data contract, a sub-processor list, a location answer.
- It is why AI training commitments exist in contractual rather than marketing form.
- A vendor accounts for what a vendor does; what you send stays yours.
- Ask for the specific documents, which compare; a compliance claim does not.
Last checked July 2026