Marketing pages, questionnaire answers, and contracts are three different things
A public trust page is a statement of intent with no remedy attached. A written questionnaire response is better, because it is attributable to a named person and you can attach it to the file. A contract term is the only layer with consequences. When you review a vendor, sort every claim into one of those three buckets and notice how many of the ones you care about are sitting in the first.
Certifications deserve the same sorting. A SOC 2 badge on a website is not a report. What tells you something is the Type II report itself: the scope section, the period it covers, and the exceptions the auditor noted. Ask for it under NDA and read those three parts. It is common for a vendor's audit to cover the core platform while the AI feature shipped eight months ago sits outside the scope, and the badge looks identical either way.
The practical move is one repeated question: where does that live in the agreement? If the answer is that it lives on the website, ask for it to be written into the order form or the addendum. Vendors who mean what they say will usually agree to restate it. The ones who will not have told you something useful.
Follow the data, not the architecture diagram
Ask the vendor to walk one realistic record through the system end to end. Use a real example from your business: a customer support email with a name, an address, and an order history. When your employee pastes that into the product, which company receives it, in which region, and over what path? Ask them to name the model provider outright. Many AI products are a layer over someone else's model. That is fine and normal, but it means your data has at least two custodians and the one you signed with is not the one running the inference.
There are almost always more copies than the diagram shows. Prompts land in debug logs. Outputs land in a product analytics pipeline. Uploaded documents land in a vector index for retrieval. Support engineers get a tool that lets them reproduce a customer's session. Safety systems keep a rolling buffer for abuse monitoring. Each of those copies has its own retention clock, and a vendor who has thought about this can list them without stalling. Ask for the list.
Residency claims need the same scrutiny. Hosted in the US usually describes primary storage. It often does not describe where a support engineer sits when they open your tenant at 2am, or where a subprocessor's queue runs. If residency actually matters to you because of a customer contract or a regulated data type, ask for it to cover processing, storage, and human access, and confirm which of the three the vendor is willing to commit to.
Training, retention, and deletion are three questions, not one
Every vendor has learned to say that they do not train on your data. The sentence is usually true of the base model and not true of everything downstream, so break it into parts. Are our inputs or outputs used to train, fine-tune, or evaluate any model, including one dedicated to us? Are they used to build embeddings or indexes that persist after the session ends? Does any human, at your company or a subprocessor, read our content for quality or abuse review? Is the protective setting the default on our plan, or something an admin has to switch on, and does it apply to the API and the web app alike?
Retention is a separate question with a separate answer. Zero-retention modes frequently carve out a short abuse-monitoring window, often around thirty days. That is a reasonable design, not a scandal, but you should know it before a customer asks you about it. Note also that deleted within N days almost always means deleted from live systems. Backups expire on their own schedule, which is fine as long as the vendor will tell you what that schedule is.
Deletion at the end of the relationship is where the sharp edge sits. Your documents are easy to delete. The artifacts derived from them are not always covered: embeddings, retrieval indexes, fine-tuned weights, cached completions, and evaluation sets built from your traffic. Get a deletion commitment that names derived data explicitly, states a deadline, and includes written confirmation that it happened.
Tenancy, retrieval permissions, and who at the vendor can read your data
Ask how your data is separated from other customers, and accept a plain answer. Shared tables with a tenant identifier, a separate schema per customer, and a separate instance are all real designs with different cost and risk. Shared storage keyed by tenant is the most common and it is defensible, but it means the isolation lives in application code, so the follow-up matters: has an outside tester tried to break it, and was tenant isolation named in the scope of that test or the bug bounty?
Retrieval is where isolation quietly fails in AI products. If the tool indexes your files so the assistant can answer questions about them, ask whether permissions from the source system are enforced per user at query time. The frequent failure is that the connector was authorized by an admin, so it indexed everything that admin could see, and now the assistant will happily summarize the compensation folder for anyone who asks the right question. That is a permissions bug rather than a model bug, and it is the most likely incident you will actually experience.
Then look at both sides of the access question. On the vendor's side: which roles can read customer data in production, does that access require approval, is it time-limited, and is it logged where you can see it. On your side: can you enforce SSO, can you automatically remove access when someone leaves, can you scope roles so that not every user is an admin, and can you export an audit log. A vendor with no admin audit log is asking you to take incident response on faith.
Incident notification and the terms that decide how you leave
Without undue delay is not a clock. Ask for a specific window in hours or days, ask who at your company gets notified, and ask what channel counts as notification. A banner on a status page is not the same as an email to your named contact. Then widen the definition of what triggers it, because AI products fail in ways that do not resemble a classic network breach: one tenant's content surfaces in another tenant's output, an agent takes an action it was not supposed to take after processing hostile input, or a model swap changes behavior in a way that exposes data in logs. If the incident clause only covers unauthorized access to systems, those events may not trigger anything.
Exit terms decide how much the relationship costs you when it ends. The test is simple: could you leave in a week with your data in a form another tool can read. Ask what the export contains and in what format, whether it includes conversation history and the prompts or configurations your team built, and how long the export stays available after termination. Confirm in writing that you own the prompts, the fine-tunes, and the outputs generated in your account, because default terms vary more than buyers expect.
Two change-control terms are worth the negotiation as well. First, notice before a new subprocessor is added, with a window to object, since a subprocessor list is a snapshot and yours will change. Second, notice when the underlying model version changes, because your prompts and your quality checks were tuned against the old one. You are a small buyer with limited leverage, so do not try to redline the whole agreement. Pick the three terms that matter most for your data and spend your leverage there.
Anything a vendor will not put in writing is a preference, not a control. Decide which few answers actually matter for your data, get those into the agreement, and do it before you sign, because that is the only day you have leverage.