AI Vendor Risk Assessment for Mid-Market Teams

Before You Read On

An AI vendor risk assessment checks what a third-party AI product does with your data, how its model changes, what it logs and how you get out. For a mid-market team it takes one structured questionnaire, one owner and a short list of technical controls, applied to approved vendors and to the tools staff adopted without asking.

• Cost: mostly staff time; the controls run on a platform you likely already own.
• Effort: one questionnaire, reused for every AI purchase and renewal.
• Risk: unapproved tools carry the same data exposure as approved ones, with no contract behind them.
• Fit: start with any vendor that receives customer, employee or financial data.

Unapproved AI is no longer a side issue. IBM’s Cost of a Data Breach Report 2026 found that security incidents involving shadow AI, where workers use unapproved AI tools, more than doubled to 43% from 20% the year before. The same report found that 68% of breached organizations lacked AI governance to manage AI or detect shadow AI.

Mid-market companies sit at the weak end of that curve. The Retool AI Governance Report 2026, a May 2026 survey of 307 senior technology and security leaders, found 19% of companies with 200 to 999 employees had no formal governance approach at all, against 8% of enterprises.

So the procurement question has changed. It used to be “is this vendor secure?” Now it is “which AI vendors already hold our data, which of them did we approve, and can we prove what each one received?” You cannot answer that from a spreadsheet of contracts while the data that flows to those vendors sits in a dozen silos with no lineage.

Why Does a Standard Vendor Questionnaire Miss AI Risk?

A classic third-party questionnaire asks about encryption, access control, breach history and certifications. Those still matter. They just stop short of the four places AI products behave differently from ordinary SaaS.

• Your data may become their training data. Prompts, uploaded files and retrieved context can feed model improvement unless the contract and the admin setting both say otherwise. A questionnaire that asks only “where is data stored” never surfaces it.
• The model changes under you. A vendor can swap the underlying model, retrain it or change a system prompt without a release note. An output you validated in March is not the output you get in June.
• A fourth party is usually involved. Many AI products call a foundation model from another company. Your data travels to a provider you never assessed and may never have heard of.
• The logs you need may not exist. If the product cannot export who asked what, which data it read and what it returned, you cannot investigate an incident or answer an auditor.
• Shadow tools skip the questionnaire entirely. A browser extension or a personal subscription never reaches procurement, so none of the questions above get asked.

IBM’s 2026 research adds a useful point for buyers. It found AI-related breaches at similar rates whether the model was open source, a vendor product delivered as SaaS or vendor software run on premises, and it traced root causes to compromised connected APIs, applications and cloud misconfigurations. That means the integration around the model deserves as much scrutiny as the model.

What Should an AI Vendor Risk Assessment Cover?

Group the work into six domains. Each domain has a question for the vendor and a control on your side, because a vendor’s answer is a promise and your control is the evidence.

The NIST AI Risk Management Framework is voluntary, but it gives you vocabulary a customer or auditor will recognise. Its Govern function includes policies for risks from third-party software, data and AI, which is the slot this assessment fills. We map the wider program in our AI governance framework.

How Do You Find the Shadow AI Already in Use?

You cannot assess a vendor you do not know about. Before the questionnaire, build the inventory, and build it from data rather than a staff survey alone.

Four sources usually find most of it. Expense reports and corporate card statements show paid subscriptions. Identity provider sign-in logs show which AI products staff log into with company credentials. Network or secure web gateway logs show traffic to AI domains. Browser extension inventories from device management show the add-ons nobody mentions.

Land each source in bronze, conform them in silver to one record per tool, per user, per month, and publish a gold table of AI tools with owner, user count, data categories touched and approval status. That table is the start of your vendor register. It also turns shadow AI from an accusation into a queue: unapproved tools with heavy use become assessment candidates, and the rest get a sanctioned alternative. Our guide to shadow AI covers the detection side in more depth.

This is the same pattern we use for security logs. Cybersecurity is a data engineering problem, and so is vendor oversight: the evidence lives in logs spread across systems that were never designed to talk to each other.

Which Lakehouse Controls Back Up a Vendor’s Promises?

A vendor questionnaire records claims. The lakehouse is where you make those claims checkable. Three controls do most of the work.

Narrow what leaves. Give an AI vendor a governed view, never a raw table. Column masks and row filters in Unity Catalog strip fields the vendor does not need before anything is sent. Because Unity Catalog captures lineage automatically, you can show which source columns feed the view a vendor reads.

Route model calls through one door. When internal apps call external models, send them through a gateway. Unity AI Gateway, generally available since 4 August 2026, governs models, agents, MCP servers and tools with identity-aware access, rate limits, spend caps, guardrails for PII and prompt injection, and unified tracing. A single route gives you one list of approved providers and one place to switch a provider off.

Keep the record. Land gateway traces and any vendor log exports in Delta tables with a retention period your counsel signs off. When a vendor changes its model, rerun a fixed evaluation set against the new version and store the results next to the old ones.

Copy-Ready AI Vendor Risk Assessment Checklist

Paste this into your procurement template. Score each item Yes, Partial or No, and require a named owner for every Partial or No before signature or renewal.

1. Inventory: The tool is in the AI vendor register with a business owner, a technical owner and the data categories it touches.
2. Use case: The intended use and the decisions it informs are written down in one paragraph.
3. Training use: The contract states whether customer data, prompts and outputs are used for training, and the tenant setting matches the contract.
4. Fourth parties: The vendor names every foundation model provider and subprocessor that receives your data.
5. Data residency and retention: Storage regions and retention periods for prompts, files and outputs are stated.
6. Data minimisation: The vendor reads only a governed view with masked or filtered columns.
7. Identity: Access runs through your single sign-on, with a dedicated service identity for any integration and no shared keys.
8. Change notice: The vendor commits to notice before model or system prompt changes, and you hold an evaluation set to retest after each change.
9. Security testing: The vendor describes its testing for prompt injection, data leakage and tool misuse, and shares a summary of results.
10. Logging: Per-request logs (user, input, data read, output, timestamp) are exportable, and the export has been tested.
11. Incident notice: The contract sets a notification window for incidents involving your data.
12. Assurance artefacts: Current third-party reports or certifications are on file, with their scope checked against the product you are buying.
13. Exit: A full data export has been tested and deletion on exit is confirmed in writing.
14. Review date: A reassessment date is set, no later than the renewal.

Item 12 deserves a warning. A certification scoped to the vendor’s corporate IT says nothing about the AI feature you are buying. Read the scope statement, not the logo.

Should You Build This Process, Buy a Tool, or Wait?

The checklist above works with or without software. What changes is how much of it you automate, and the right call depends on volume and data sensitivity.

• Build it on your own data platform when you already run a governed lakehouse and the evidence you need sits in your logs. The deciding signal: your identity, expense and network logs are already landing somewhere you can query, so the shadow AI inventory is a few pipelines away.
• Buy a third-party risk tool when the bottleneck is questionnaire volume, not evidence. The deciding signal: procurement is chasing dozens of vendor responses a quarter by email, and nobody can say which assessments are overdue.
• Wait, with one interim control, when you have only a handful of AI vendors and none touches regulated data. The deciding signal: the full register fits on one page. Put the checklist into procurement now and revisit when the list doubles.

Whichever you choose, the ownership question comes first. An assessment with no named owner is a form, not a control. If you want help standing up the register and the lakehouse controls behind it, our AI governance and compliance work starts there.

Frequently Asked Questions (FAQs)

How long does an AI vendor risk assessment take?

For a single vendor with a prepared questionnaire, expect days of elapsed time, mostly waiting on vendor answers. The first assessment takes longer because you are building the template and the register. After that, renewals reuse the same evidence.

Who should own AI vendor risk in a mid-market company?

Give procurement the process, security the technical review and a named business owner the decision for each tool. One person, often the security lead, should own the register itself so nothing falls between teams.

Should we ban unapproved AI tools?

A ban without a sanctioned alternative pushes use further out of sight. Inventory first, approve a governed option for the common use cases, then retire the unapproved tools that remain.

Do we need to reassess a vendor when it changes its model?

Yes, at least the parts that the change affects. Rerun your evaluation set against the new version, confirm the training-use setting has not reset, and check whether a new fourth-party provider now receives your data.