The Questions Your AI Vendor Should Answer in Writing

I went to law school before I ever sold a piece of software.

I earned my JD at Brooklyn Law School and hold bar admission in New York and New Jersey. Before I was Head of Sales at OurFirm.ai, I helped operationalize the implementation and customer management of a new Public Sector division at Own Company. This included Federal Government Customers with strict security requirements. Working closely with federal agencies meant consulting on security-related matters, helping complete ATOs and ensure SSO is set-up properly. I later ran security-focused sales cycles for Public Sector accounts at Salesforce: the conversations where a CISO or admin team walks through their own security posture before a deal closes. Building that muscle from inside a vendor, then sitting across from security teams year after year, taught me the same lesson from two directions: what a genuine security control looks like, and what a policy promise dressed up as one looks like.

I carried that instinct into legal tech. And I have noticed something. Law firms, some of the most risk-averse institutions in American business, are buying AI tools with less security scrutiny than a mid-market SaaS deal would get from a federal procurement officer.

That is not a knock on litigators. Evaluating a legal research platform on citation accuracy or drafting quality is the job you trained for. Evaluating whether the vendor's contracts bar its subprocessors from training on your client's documents is a different discipline entirely. Implementing that process, and auditing with some frequency is the last lever to redundancy and control. It is that same rigor law firms should use.

That includes:

Where does the isolation happen?

Not "is our data secure," which every vendor will answer yes to without blinking. The real question is whether the vendor logically segregates your matter data at the tenant level, and whether that segregation is architectural or just a policy promise. A privilege log means nothing if the underlying storage commingles firms.

Does the model train on what you upload?

This is the question I watch most legal buyers skim. The simple answer, the checkbox, is not enough. It's not only whether the vendor trains on your data. Ask whether a contract enforces that "no" with every subprocessor in the chain, including the underlying model providers, and whether zero data retention beyond the session needed for inference backs it up. Verbal assurance is not a control.

It is worth naming the mechanism here. The major model providers offer contractual zero-data-retention endpoints for enterprise customers. A vendor should be able to confirm in writing that they use one. That is the enforceable version of "we don't train on your data." If the vendor cannot point to a specific contractual provision with its model provider, the assurance is not a control. It is a talking point.

What happens in the first 72 hours of an incident?

Every vendor has a breach response plan on a slide somewhere. Fewer have a contractual notification timeline. Ask what they must tell you, and by when, if something goes wrong. Then ask what "without undue delay" means in their paper, because that phrase alone tells you how they negotiated the addendum.

The 72-hour window is not arbitrary. It echoes the GDPR Article 33 notification deadline, which has become the de facto standard even for vendors operating entirely within the United States. If your vendor's incident response timeline is longer than 72 hours, or if the contract language leaves the window undefined, that is a gap your security team should flag before signing.

Two more things to ask in this conversation. First, does the vendor have a named security contact your firm can reach directly during an incident, or does everything route through a general support queue? Second, does the vendor maintain a public status page? Silence during an incident is its own red flag. A vendor that does not publish operational status in real time is asking you to trust that you will be informed on their schedule, not yours.

Who else touches the data, and did anyone vet them?

Subprocessor lists are not a formality. Every AI vendor sits on top of other vendors: model providers, cloud infrastructure, sometimes a third-party research index. Ask for the list. Ask what security and privacy review the vendor ran on each subprocessor before onboarding, and whether that review is ongoing or a one-time gate.

One clause matters more than the rest. The contract should require the vendor to give you advance notice before onboarding any new subprocessor, with a right to object. That clause is what keeps the subprocessor list meaningful after signing, not just at signing. Without it, the vendor can swap in a new model provider or infrastructure partner on any timeline, and you find out after your data is already flowing through an entity you never reviewed.

What are the actual remediation timelines?

Not "we take security seriously." Specific numbers. How fast do they patch a critical vulnerability versus a low-severity one? How often do they penetration test the platform, and who runs it? A vendor that has never had a third party try to break in has never had to find out where the gaps are.

Can you get your data back, and can you make them delete it?

Retention policy should be something you configure, not something you discover. Ask what happens to your data on termination, how quickly they honor a deletion request, and whether backups age out on a schedule you can see.

Push one layer deeper on how deletion actually works in backups. There is a meaningful difference between cryptographic erasure, where the vendor destroys the encryption key so the data becomes unreadable even if the backup persists, and standard backup rotation, where the data remains recoverable until the backup cycle overwrites it. Ask which method the vendor uses. Then ask whether they issue a deletion certificate on termination. A certificate does not guarantee deletion happened correctly, but a vendor unwilling to issue one is telling you something about how much confidence they have in their own process.

Why this matters more as platforms consolidate

None of this is exotic. It is the standard checklist any enterprise security team runs before signing anything. The gap is that most litigation teams are not bringing IT or security into an AI purchase the way they would for a case management system or a document repository, even though the AI tool is often now holding more sensitive matter data than either.

That gap matters more, not less, as firms move toward running an entire case through a single platform. The more of the litigation lifecycle (filing, research, drafting, judge intelligence) that firms consolidate into one command center, the more concentrated the risk sits in that one vendor relationship. Centralization is a genuine advantage when it comes to speed and consistency. It is also exactly why the security questions above stop being optional. You are not just trusting a tool with a document anymore. You are trusting it with the case.

We publish ours. Read our own answers to these questions in the Security Addendum and the Data Processing Addendum, or start at the Trust Center for the full picture.

Ask every vendor the same. If they cannot answer in writing, that is your answer.