How to Read an AI Vendor's Security Page Before You Buy

What a security page is actually for

A vendor's security or trust page exists to get you through procurement, which is a different goal from telling you how the system works. That does not make it dishonest — most of what is on it is true and verifiable — but it does mean the page is organised around the questions that are easy to answer well, and quiet about the ones that are not. Reading it usefully means treating it as a starting point for a conversation rather than as the conversation. The aim is to leave the page with a short list of specific questions, not a general feeling of reassurance.

Trace the data flow before you look at the badges

The first thing to establish is what actually leaves your systems, where it goes, and who else touches it on the way. For an AI product this usually means your users' input text, any files they attach, and often metadata about who submitted what. Follow that path through every hop: your browser, the vendor's application, the model provider behind it, and any analytics or logging service in between. Most security pages describe the vendor's own infrastructure well and become vague at the boundary where a third-party model provider takes over — which is precisely the boundary that matters, because it is where your data leaves the company you signed a contract with.

Retention and training are two separate promises

These get conflated constantly, and vendors rarely correct the confusion because it works in their favour. Retention is about whether your content is stored and for how long. Training is about whether it is used to improve a model. They are independent: a vendor can hold your data for thirty days for abuse monitoring and never train on it, or store nothing at all and still be running a model trained on an earlier corpus. Look for both commitments stated separately, note whether they apply to your plan tier or only to enterprise agreements, and check whether zero retention is the default or something an administrator has to switch on per workspace.

Subprocessors are the list nobody reads

Every vendor of any size publishes a subprocessor list — the other companies it shares your data with to deliver the service. It is the most informative page in the whole trust centre and the least read. Go through it and ask what each entry is for. A cloud host and an email provider are expected. A model provider you did not know was involved changes your risk picture, because your data is now governed by a contract you have never seen. Also check whether the vendor commits to notifying customers before adding a subprocessor, and whether that notice gives you any right to object.

Certifications describe process, not your product

A SOC 2 Type II report or an ISO 27001 certificate tells you the company has controls and that an auditor checked they operate. That is genuinely worth something: it means someone external looked at access management, change control, and incident response. What it does not tell you is whether the specific feature you are buying is well built, or whether the controls cover the AI product at all rather than the older parts of the platform. Ask for the report itself under NDA rather than accepting the badge, then read the scope section first — it names which systems were assessed, and a recently launched AI product is often not among them.

Check what your administrators can actually control

A security page describes what the vendor does. It rarely describes what you can do, and for day-to-day risk that matters more. Can an administrator see which users submitted what, and export that log? Can retention or data-sharing settings be enforced organisation-wide, or does each user hold a toggle they can flip? Is there a way to restrict which parts of the product are available to which teams? Controls that exist only as per-user preferences are not controls in any meaningful sense, because the setting most likely to be changed is the one on the account of the person under deadline pressure.

Turn the page into a short list of questions

Finish by writing down what the page did not answer, and send that list before the security review meeting rather than during it. Good questions are specific and have factual answers: which model provider serves our region, is zero retention enabled by default on our plan, does the retention commitment cover file attachments, what is the notice period for adding a subprocessor, what is in scope on the latest audit report. A vendor that answers these clearly and in writing has told you more than any trust page can. A vendor that redirects to marketing language has also told you something, and it is worth noticing before you sign rather than after.