How to Run a Security Review for AI Vendors (Not Just SaaS)

The standard checklist assumes data comes back out the way it went in

A typical SaaS security review asks about encryption, access controls, and compliance certifications. It's built around a model of software where data goes in, gets stored, and comes back out roughly as it went in. AI tools break that model: data goes in, gets processed by a model that may or may not retain something from it, may or may not belong to a third party the vendor relies on, and the output that comes back is generated rather than retrieved, carrying its own risks that a storage-and-access review was never built to catch.

Seven additions for AI vendors specifically

1. Data training usage. Ask whether your data is used to train or improve the vendor's models, and whether that's opt-out or opt-in by default. Get it in writing, since default settings sometimes change with product updates.

2. Underlying model provider dependency. Identify whether the vendor is built on top of a third-party model provider. If so, your data's security posture depends on that provider too, and their terms may not flow through cleanly to you.

3. Retention for prompts and outputs. Check the retention policy for the actual input and output content, not just stored account data. It's a distinct data flow most reviews don't ask about, and windows vary widely across vendors.

4. Certifications scoped correctly. Confirm certifications cover the AI-specific processing, not just general infrastructure. A SOC 2 report covering data storage doesn't necessarily cover model training practices or the third-party dependency above.

5. Incident response for model-level issues. Ask about response to an output-level failure, such as a model surfacing information it shouldn't have. That's a different failure mode from a traditional breach and most plans weren't written to cover it.

6. Regulatory exposure. Depending on your jurisdiction and use case, ask whether the vendor's practices align with emerging AI-specific regulation, the EU AI Act being the most developed example, particularly for any use case that could be classified as higher-risk.

7. Output filtering and safety measures. For customer-facing or high-stakes use cases, ask what safeguards exist against harmful, biased, or factually incorrect output, and what recourse you have if it happens anyway.

What the gap looks like when nobody closes it

A company runs its standard review on a new AI writing tool, checks the usual boxes, and approves it on the normal timeline. Later, someone discovers the tool is built on a third-party model provider that was never assessed, and that default terms allow prompt data to be used for model improvement unless an admin opts out on a settings page nobody visited. None of that would have been unusual to catch. It simply wasn't on the checklist being used.

Bolting it on rather than starting over

Rather than building a separate AI procurement process, add these seven questions as a required addendum triggered whenever an evaluation involves an AI capability, whether that's the vendor's core product or an AI feature added to an otherwise traditional tool. The standard process stays intact and expands exactly where it needs to.