Resource · Evidence and audit
Vendor onboarding: day-one capture
What to capture and what to ask the day you add an AI vendor, so that a change eighteen months from now is provable.
The work is worth doing on a day when nothing has happened
On day one there is nothing to see. No page has changed, no clause has moved, and the natural thing is to file the contract and come back when something happens.
A change is only provable against a copy you already hold. Day one is not about watching — it is about creating the thing a later change will be measured against. Miss it and the first movement you notice has no before.
It is also the only day you have leverage. Of the ten answers worth having on file, 5 are published by fewer than a fifth of the 186 vendors we watch. Those are the terms that decide what a later change costs you, and they are the ones you have to ask for. After the signature the answer is whatever the standard page says.
Part 1 · Capture these pages
For each: the URL, the date you read it, and a stored copy — not a bookmark. A link points at the page as it stands today, and the question you will be asked is what it said in March.
| Page | Where to find it | Vendors publishing one |
|---|---|---|
| Privacy policy | Linked from the footer. Capture the version with an effective date on it rather than a print view. | 182 of 186 |
| Trust center | trust.<vendor> or security.<vendor>. Certifications, sub-processors and residency statements often live here rather than in the legal pages. | 168 of 186 |
| Terms of service | The self-serve terms, which govern anyone in your company who signs up outside procurement. | 155 of 186 |
| Sub-processor list | Usually /subprocessors or a tab inside the trust center. A trust center ROOT previews a few and links the rest — capture the full list, not the preview. | 115 of 186 |
| Data processing agreement | The published template, even when yours is negotiated. It is the document their notice clause is drafted from and the one they will amend. | 101 of 186 |
| Changelog or release notes | Where a retirement is announced. There is rarely an email. | 78 of 186 |
| Model card | Per-model documentation. What it says about training data and evaluation is the part a later change tends to move. | 51 of 186a floor — our list |
| Status page | status.<vendor>. Not a compliance document, but the record of what an incident looked like from outside. | 28 of 186a floor — our list |
| Deprecation schedule | A separate page from the changelog for the vendors that keep one. Most fold retirements into release notes instead. | 9 of 186a floor — our list |
A count here measures our own list as much as vendor behavior, and the three marked as a floor measure it more than the others: we watch a deprecation page for nine vendors, which says nothing about how many keep one.
Part 2 · Record these answers, and ask for the ones not on a page
| Question | On a page today | If not, ask for |
|---|---|---|
| When was each of these documents last changed? | 159 of 186 (85%) | Nothing — this one you take from the page. Record it, because a document with no date is one you cannot show moved. |
| Will our data train their models? | 154 of 186 (83%) | A commitment covering the model provider they sit on, not only themselves. Their sub-processor's terms are not theirs to promise. |
| What do they say they hold? | 120 of 186 (65%) | The report, under NDA, and the level. A trust page saying SOC 2 has not said Type II. |
| Who else touches our data? | 95 of 186 (51%) | The list, and a commitment to notify additions. Their list names companies your contract is not with. |
| Where is our data processed, and where can it go? | 56 of 186 (30%) | A commitment about a place, not a disclosure that transfers happen. They look alike and mean opposite things. |
| How long do we have to object to a new sub-processor, and how are we told? | 36 of 186 (19%) | A period that runs from an email to a named address, not from a page being updated. A window you cannot see start is not a window. |
| How much notice before a model we depend on is retired? | 26 of 186 (14%) | A minimum period in the agreement. Retirements are published, not sent. |
| How long is our data kept after we stop using the service? | 23 of 186 (12%) | A period per category, in writing. A vendor states several windows and they cover different data. |
| Does not objecting count as approving? | 14 of 186 (8%) | If silence approves, ask for the notice to be delivered rather than published. If they will not move the clause, they will often agree to send the email. |
| How fast are we told about a breach, and by what route? | 6 of 186 (3%) | A stated number of hours and a named contact of yours. A status page is not notice. |
† How much notice before a model we depend on is retired? — A floor rather than a reading: we watch a changelog for 78 vendors and a deprecation page for 9, so this counts where we looked.
Part 3 · The baseline
Three things turn the capture into something a later change can be measured against.
Store the copy, not the link.
A link resolves to today. Keep the page as text or PDF, with the date you read it and a hash of what you stored.
Write down where you looked and found nothing.
A page missing from your file reads later as a page that does not exist. Record the URL you tried and what it returned, so a gap is a gap rather than an oversight.
Put the re-read on a schedule before you need it.
A sub-processor list is a page: an addition arrives as an edit and nothing announces it. A date in a calendar is the whole mechanism.
What a stored copy has to carry to be worth anything is its own checklist.
Take it with you
Both tables and the baseline as a Word document. It is generated when you download it, so the coverage figures are the ones the record holds that day.
How this was assembled
The pages and the questions are written. Every figure beside them is counted from the record: how many of 186watched vendors we hold each surface for, and how many publish something we could read under each heading. A vendor that publishes nothing we could read is counted as neither publishing nor refusing — we record only that we looked. How the record is kept.
Common questions
- What should I capture when onboarding an AI vendor?
- The sub-processor list, the data processing agreement, the privacy policy, the trust center, the terms and the changelog — stored as copies with the date you read each, not saved as links. Then the answers to ten questions, the five you can read off a page and the five you have to ask for.
- Why capture anything on day one when nothing has changed?
- Because a change is only provable against a copy you already hold. Day one is not about watching; it is about creating the thing a later change will be measured against.
- Which answers will not be on a vendor's page?
- The objection window, how much notice before a model is retired, how long data is kept, whether silence approves a sub-processor, and how an incident is notified. Each is published by fewer than a fifth of the vendors in the record, and each is a term that decides what a later change costs you.
- Is a bookmark enough?
- No. A link resolves to the page as it stands today, and the question you will be asked is what it said eighteen months ago. Store the text or a PDF, with the date and a hash of what you stored.
- What if a vendor publishes nothing under one of these headings?
- Record the URL you tried and what it returned. A page missing from your file reads later as a page that does not exist, and a vendor that refused an automated reader is not a vendor that publishes nothing.
Evidence and audit
Prove what a page said, and when.
- Evidence pack template
The eight sections a dated copy needs — with one real pack: two readings, their hashes, the verbatim difference and the signed timestamp over each.
This is not legal advice, and the questions are a starting point rather than a set anyone has approved for your situation. The coverage figures count published pages read on the dates the record holds; your negotiated contract governs. The record is free to read, and corrections are free to request.