Which vendor pages should I monitor for changes?

Start with the sub-processor list and the data processing agreement: the first is the highest-yield page in this record by a wide margin, and the second is what turns any change into an obligation. Then the trust page, the privacy policy and the changelog.

Is it worth monitoring a vendor's pricing page?

For contractual facts, the measurement here says no. We watch 141 of them, they produce among the highest volume of page changes in the record, and they have yielded five facts — all of them date stamps. Watch it for commercial reasons if you need to, not for compliance ones.

Where do vendors announce model deprecations?

Usually a changelog or release-notes page, occasionally a dedicated deprecations page, and sometimes a model card. None of them sends anything; the page simply changes, and often after the retirement has already happened.

How many pages does a vendor typically publish?

Across the vendors watched here the median is a handful — a privacy policy and terms almost always, a trust page usually, a sub-processor list and DPA often, a changelog if the product has an API. Absence is itself worth recording.

Inventory

Resource · Watching AI vendors

Which vendor pages to capture, and what each one is worth

The 10 page types Xither watches across 186AI vendors, with what each one actually yields — measured, not assumed.

The point

Anyone can write the list; the yields are the useful part

Privacy policy, terms, DPA, trust page. Every vendor-monitoring runbook arrives at roughly the same set from intuition, and none of them says which pages repay the effort of watching.

Across 1,078 watched pages the record holds 7,478 extracted facts. They are not evenly distributed, and the distribution is the advice.

Start here

The first three

Sub-processor list · 115 vendors · 3,589 facts

The companies your vendor passes data to. Additions are the event most data processing agreements actually cover, and the one that starts an objection window.

Trust or security page · 168 vendors · 1,250 facts

Certifications, and what you are allowed to repeat to your own customers about them.

Changelog or release notes · 78 vendors · 1,061 facts

Where a retirement is announced. Nothing is sent; the page simply says it, usually after the fact.

The sub-processor list is the highest-yield page in the record by a wide margin, and the data processing agreement is the one that turns any of it into an obligation. Capture both before anything else.

All of them

Every page type, and what it yields

Page	Vendors	Facts	Changes	Facts / change	What comes off it
Sub-processor list	115	3589	70	51.27	subprocessor 3433, page date 106, notice channel 26, training use 17
Trust or security page	168	1250	124	10.08	certification 1124, training use 77, page date 27, residency 15
Changelog or release notes	78	1061	290	3.66	deprecation 975, page date 86
Privacy policy	182	741	177	4.19	training use 342, page date 294, residency 71, retention 32
Terms of service	155	387	127	3.05	page date 191, training use 178, retention 10, residency 5
Data processing agreement	101	289	75	3.85	page date 126, training use 50, notice channel 43, residency 32
Deprecation page	9	75	18	4.17	deprecation 63, page date 12
Model card	51	49	134	0.37	page date 28, deprecation 21
Status page	28	32	61	0.52	incident 27, page date 5
Pricing page	141	5	152	0.03	page date 5

“Facts per change” is the column to read if you are deciding what to watch rather than what to file. A page that changes often and yields nothing spends attention without repaying it.

The bad one

The page we watch for nothing

The pricing page is the worst of them, and it stays in the table on purpose. We watch 141 of them. They have produced 152 recorded page changes — among the highest of any surface — and 5 facts, every one of them a date stamp.

A page type that changes constantly and states nothing a contract counts is exactly what an alerting rule has to survive, and it is why a rule that alerts on diffs rather than on facts is unusable. Publishing our own worst-yielding surface is the only thing that makes the rest of the table trustworthy.

Caveat on the numbers

The yields are about our extractors too

A low number means we get little from that page type — not that the page type carries nothing. Model cards are the clear case: they hold a great deal a reader would want, and our extractors currently read dates and end-of-life notes off them and little else.

Treat the column as a measurement of this record rather than a verdict on the page, and capture anything your own agreements depend on regardless of where it sits here.

Per page

What to record

The URL, the date you read it, a hash of what you read, and the copy itself. The date and the hash are what make the copy evidence later: without them you have a screenshot of a page that has since changed, and no way to show when it said what.

Then check where the page announces changes, if anywhere. Most of these page types change silently, and the ones carrying a notice mechanism usually say so in the agreement rather than on the page.

Download

Take it with you

The full table as a Word document, useful as the basis of a capture runbook. It is generated when you download it, so it carries the measurements as they stand that day.

Method

How these were counted

Counts come from the watch targets, extracted facts and recorded page changes in the Xither record. Facts are attributed to the page type they were read from. A page we cannot fetch produces no facts and no changes, so a low row can mean a page type that resists reading as easily as one that says little — the two are not separated here. How the record is kept.

Questions

Common questions

Which vendor pages should I monitor for changes?: Start with the sub-processor list and the data processing agreement: the first is the highest-yield page in this record by a wide margin, and the second is what turns any change into an obligation. Then the trust page, the privacy policy and the changelog.
What should I record when I capture a vendor page?: The URL, the date you read it, a hash of what you read, and the copy itself. The date and the hash are what make the copy evidence later — without them you have a screenshot of a page that has since changed and no way to show when it said what.
Is it worth monitoring a vendor's pricing page?: For contractual facts, the measurement here says no. We watch 141 of them, they produce among the highest volume of page changes in the record, and they have yielded five facts — all of them date stamps. Watch it for commercial reasons if you need to, not for compliance ones.
Where do vendors announce model deprecations?: Usually a changelog or release-notes page, occasionally a dedicated deprecations page, and sometimes a model card. None of them sends anything; the page simply changes, and often after the retirement has already happened.
How many pages does a vendor typically publish?: Across the vendors watched here the median is a handful — a privacy policy and terms almost always, a trust page usually, a sub-processor list and DPA often, a changelog if the product has an API. Absence is itself worth recording.

Watching AI vendors

Know which pages to read and how often.

Where AI vendors publish their sub-processor lists and DPAs
The URL for each document we read, the date each was last read, and what happened where a page could not be read.
The AI Vendor Change Lexicon
Sub-processor drift, objection window, silence as consent — each term defined and illustrated with a real clause.
What AI vendors have retired, and where they announced it
235 retirement announcements from 26 vendors, quoted with the page each appeared on — because a retirement is published, not sent.

Everything in the resources section

Caveat

This is not legal advice. The measurements describe the Xither record and the pages it reads; your own vendors may publish more or fewer surfaces, and your agreements govern which of them matter. The record is free to read, and corrections are free to request.