How to read an AI vendor's security page

Read it the way you'd read a contract you didn't draft

Somebody at the firm gets assigned to "look into the security" of a tool the litigation group wants. They land on a page with a shield icon, a row of logos, and a lot of calm sentences about how seriously the company takes data protection. Fifteen minutes later they report back that it looks fine. It usually does. These pages are written by marketing teams for exactly that outcome.

That doesn't make the page useless. It was written by people who knew a buyer's lawyer might read it, which means the careful wording is deliberate and the omissions are too. Read it the way you'd read a form contract from the other side: slowly, looking for scope, and paying more attention to what isn't promised than to what is.

Adjectives are free. Scope isn't.

"Bank-grade encryption," "enterprise security," "your data is protected." None of these narrow anything down. Encryption in transit and at rest is table stakes, and every vendor worth considering has it, so the presence of that sentence tells you nothing about the vendor you're evaluating.

Where the page starts being informative is scope. If it names a security audit or certification, the useful questions are which systems the audit covered, what period it covered, and whether the specific product your firm would use was in it. A company can hold a real, current report that covers its core platform while the AI feature you're about to feed deposition transcripts into was built after the audit window closed. That's not fraud. It's just a boundary the page doesn't draw for you, and drawing it is the whole job.

Three specifics worth hunting for

Skim past the reassurance and look for these three. If the page addresses all of them plainly, you're dealing with a company that has thought about firm buyers. If it addresses none, you're reading a brochure.

• Retention, stated as a duration. "We retain your content only as long as necessary" describes a policy without ever stating one. You want a stated period, a way to shorten it, and a description of what happens to backups, which are usually where the real answer lives.
• Subprocessors, listed by name. Every cloud AI product runs on other people's infrastructure, and often on someone else's model. A vendor that publishes the list and commits to notice before adding to it is telling you something real. A vendor that won't name them is asking your firm to accept a chain of custody it can't see.
• Training, scoped precisely. "We don't train on your data" is a good sentence with a lot of room in it. Train what, using which data, and for how long? Does it cover the underlying model provider, or only the vendor's own systems? Does it cover prompts and outputs, or only uploaded files? We wrote about the second category before: the derived text, indexes, and logs that clients think of as their file even when a vendor doesn't.

What's missing tells you more

Now read for holes. Four are common, and each one is a question you should ask out loud.

The first is deletion on termination. Plenty of pages describe how well data is protected while you're a customer and go quiet about what happens when you leave. The second is vendor-side access: who at the company can read what you upload, under what circumstances, and is that logged in a way you could see later? Support staff often can, for good reasons, and a page that acknowledges this straightforwardly is more trustworthy than one that pretends nobody has a key.

The third is incident notification, specifically the timing and who gets told. The fourth is the page's own date. An undated security page has no shelf life, and you can't tell whether it describes the product today or the product two years ago.

Turn the reading into a short memo

When you're done, write half a page: what the vendor claims, which claims you could verify, which ones you couldn't, and which ones you moved into the contract. Keep it with the matter file for the tool. That memo is what you hand a client or an insurer who asks how your firm vets the software touching their records, and it's a far better answer than "their website said it was encrypted."

The questions that stop applying

Here's the part that's easy to miss while you're deep in a vendor's fine print. Most of these questions exist because your documents are going somewhere else. Retention, subprocessors, deletion on termination, who at the vendor can read your files: all of it is downstream of a single architectural choice.

The Tiber River Legal Workbench runs on hardware the firm owns, so most of those questions simply stop applying. There's no retention schedule because we hold nothing. There's no subprocessor list because nothing is in the path. There's no vendor access log because there's no vendor access. What replaces the reading exercise is a test your own IT person can run on your own network, and a set of controls you administer: matter-level access, ethical walls, and a record of who saw what.

You should still read our page carefully. Ask us the same questions, and ask for the answers in writing. A vendor who flinches at that has told you something useful.

Related reading: Private AI for law firms: why client files should stay in the building, the verification tax, and why AI output should wait in an approval queue.