AI vendor due diligence and contract review checklist

Hello, this is Legal Agent.

A business unit's request to approve a new AI tool typically arrives with a price sheet and a features page attached, and a security checklist still built for ordinary SaaS. Reading price, features and uptime the way one would for any other SaaS product is not enough for an AI tool, because these services are often connected to a company's core information. Whether the input trains the model, how much of a log persists, and who answers for an output error all need checking before the review is complete.

Fix five things before questioning the vendor

Before any vendor gets a single question, the company should have already settled: whether confidential information, personal data or third-party copyrighted material appears in what will be fed to the AI; who uses the output, for which task, and within what limits; whether external transmission, training use, log retention and reuse can be explained through the contract and internal rules; whether the terms of service, privacy policy, internal policy and vendor contract share the same premises; and who makes the final call so an AI answer is never adopted without review.

The same product category can hide very different risk

Two services both marketed as a meeting-notes AI can differ enormously: one processes audio temporarily and discards it, another retains it to improve the model, another sends it to an external foundation model, another processes it on an overseas server, and another lets an administrator browse the log. The product category tells you nothing; only the actual data flow does, and confirming it usually needs input from information systems and security staff alongside the business unit that wants the tool.

Where the contract has to answer, not guess

An AI tool reads, summarises, infers and proposes a next step, and an agentic tool may call external tools, draft emails and advance a workflow on its own, so if the contract leaves responsibility unclear, there is no answer ready when something goes wrong: an AI-drafted reply to a customer turns out wrong, an employee accidentally feeds in customer data, a model update degrades output quality, or an outage raises the question of how the service-level commitment applies. Because an app provider, a foundation-model provider and a cloud operator often sit behind a single service, tracing where data actually goes usually requires the security documentation, the admin console and the subprocessor list alongside the contract text itself. Training use deserves the closest look of all: where the sales pitch says data is not used for training, the contract terms and the account settings should say the same thing, because if a dispute arises, the contract, not the pitch, is what protects the company.