AI vendor risk checklist before you adopt a new AI tool

Someone on your team wants to buy or connect a new AI tool. It looks useful, the demo was good, and there's a Slack thread already forming around "can we just start using this." Before that happens, there's a short list of questions worth answering, in writing, from the vendor. Most vendors can answer all of them in an email. The ones that can't, or won't, are telling you something.

This isn't about slowing down adoption for its own sake. It's about knowing what you're agreeing to before your data is already in someone else's system.

Where does the data actually go

Ask specifically what data the tool touches, not just what you type into it. A "writing assistant" browser extension can read every page you visit while it's active, not just the document you're editing. A "meeting assistant" often records and transcribes the whole call, not just the parts relevant to its summary. Get the actual data flow: what's collected, what's sent to the vendor's servers, and what stays local. If the vendor's answer is a general privacy policy rather than a specific description of this product's data flow, ask again.

Is it used for training

This is the single most consequential question and the one most often skipped. Many consumer and even some business-tier AI products use customer input to train or fine-tune future models by default, meaning your prompts, documents, or code could influence outputs shown to other customers, or in rare cases be reconstructed from the model later. Enterprise tiers of major AI products usually offer an opt-out, or exclude training by default, but "usually" is not "always", and the default often differs from what a sales rep implies in a demo. Get this in writing, tied to the specific plan you're actually buying, not the vendor's general marketing claim.

What's on the subprocessor list

Almost no AI vendor runs entirely on its own infrastructure. There's typically a cloud provider underneath, sometimes a separate model provider (a "wrapper" product calling OpenAI or Anthropic's API on the back end), sometimes an analytics or logging vendor with a copy of your data too. A responsible vendor publishes a subprocessor list, usually a page or a section in their DPA, naming every third party that touches customer data and what each one does with it. If a vendor can't produce this list, you don't actually know how many companies your data passes through, and neither do they.

Is there a signed DPA

A Data Processing Agreement is the actual contract governing how the vendor handles personal data, and it exists separately from the general terms of service almost everyone clicks through unread. If you're in the EU or handling EU personal data, a DPA is a GDPR requirement for any processor, not optional paperwork. Ask for the DPA before signup, not after you've already loaded data in, since some vendors' DPA terms turn out to be worse than expected and you want that leverage before you're dependent on the tool.

What's the retention and deletion policy

Ask three separate questions here, because vendors often answer only the first: how long is data retained during active use, how long after you delete an account or a document, and can you actually request deletion and get confirmation it happened. "We delete data within 30 days of account closure" is a real answer. "Data is retained as needed to provide the service" is not an answer, it's a way of avoiding one.

Is there a real security certification

SOC 2 Type II and ISO 27001 are the two certifications worth checking for, and the distinction between them and a vendor's own claim of being "secure" matters: both require an independent auditor to verify controls over time, not just a one-time checklist the vendor filled out itself. Ask for the actual report or certificate, not just a badge on the website, since badges get left up after certifications lapse more often than you'd expect. Absence of a certification isn't automatically disqualifying for a small or early-stage vendor, but it does mean you're taking their word for their security practices rather than an auditor's.

A few more worth asking

• Where is data processed, geographically? If you have data-residency obligations, "US-based" and "EU-based" are not interchangeable answers, and a vendor headquartered in one region can still process data in the other.
• What happens if the vendor is acquired or shuts down? A surprising number of DPAs say nothing about this. Data doesn't just get deleted when a company folds; someone acquires the assets, sometimes including the data.
• Can you get an audit log of who accessed what? For anything touching regulated data, the ability to answer "who looked at this and when" after the fact is often a compliance requirement in itself, not just a nice-to-have.
• Does the free or trial tier have different data terms than the paid tier? This trips up more teams than it should: someone starts on a trial with default training-enabled terms, then the team migrates the workflow before anyone checks whether the paid tier's terms are actually different.

The alternative that sidesteps most of this list

Every question above exists because the data leaves your organization and someone else now controls what happens to it. A model you host yourself, on your own hardware, makes most of this checklist moot: there's no subprocessor list because there's no processor, no training-use question because the vendor never sees your prompts, no retention policy to verify because the data never left your infrastructure to begin with. GPUwerk is one example of a vendor in the "we host the hardware" category rather than the "we process your data" category, and we publish plain answers to the questions on this list, including our own DPA and subprocessor position, in our privacy policy and terms. That's not a reason to skip the checklist for us or anyone else. It's a reason the checklist is short when you ask it.