The Fine Print Problem: Vetting an AI Vendor Before You Deploy

"The AI made the decision" won't hold up. Here's the vendor checklist to run before you deploy any AI tool. 

TL;DR: Every AI tool a business plugs into its systems drags a vendor relationship in behind it, and that relationship rarely gets the scrutiny a new hire with building access would get. When something goes wrong, whether it's a manipulated input or a subprocessor nobody disclosed, "the AI made the decision" doesn't hold up as an excuse to a regulator, a client, or opposing counsel. This piece works through what actually deserves an answer before signing, and lands on a simple conclusion: vetting the vendor is really just vetting your own exposure, so the checklist that matters is the one you run before the ink dries, not after something breaks.

Signing up with a vendor used to mean a stack of paper, a background check maybe, and a gut sense of whether you trusted the person on the other end of the handshake. Signing up with an AI vendor today often means clicking "accept" on a demo that took fifteen minutes and felt genuinely impressive.

Picture hiring a subcontractor to work inside your building. You wouldn't hand over a key and skip the background check just because the pitch was smooth and the guy seemed nice. You'd want to know who he answers to, what happens if something goes wrong, and what becomes of anything of yours he touches while he's in there. Somehow, that same instinct evaporates the moment the subcontractor is a piece of software instead of a person, and a slick onboarding flow has a way of making due diligence feel like an unnecessary formality.

That instinct matters more with AI vendors than with regular software, for a specific reason. The tool itself can act on your data, not just store it. A normal piece of software holds information. An AI agent connected to your systems can read it, reason over it, and take action based on what it finds, which means the vendor behind it carries a different kind of weight than a typical software contract ever did. This sits inside a bigger shift happening across how businesses think about AI risk generally, one that treats a vendor's tool as an extension of your own environment rather than something safely outside it.

This is the checklist for asking the right questions…before you sign.

Table of Contents

1. Why AI Vendors Need a Different Kind of Vetting
2. What Happens to Your Inputs, and Who Trains On Them
3. Who Else Touches Your Data, and How Fast You'll Hear About It
4. Where Liability Actually Lands
5. Vetting the Vendor Is Vetting Your Own Exposure
6. The Checklist That Actually Protects You
7. Key Takeaways
8. Frequently Asked Questions

Why AI Vendors Need a Different Kind of Vetting

Traditional vendor review runs on a fairly stable set of questions, and most businesses could answer them half asleep. Where's the data hosted, who has access, what's the uptime guarantee? Those still matter, sure, but they've stopped being enough on their own, and honestly, most vendor questionnaires haven't caught up to that yet.

NIST's AI Risk Management Framework exists precisely because AI systems bring risk categories that a normal software checklist was never built to catch, things like how the system was trained and whether your data becomes part of that training without anyone at your business ever noticing. The Cloud Security Alliance's ongoing AI safety research makes a related point worth sitting with: a vendor's general security posture, their SOC 2 report, their tidy customer list tell you very little about how their specific AI model handles your data once it's actually inside your walls.

We've talked throughout this series about what happens when an agent's access outpaces what its job actually requires, and a vendor's AI tool is no exception to that pattern. That exact point came up in our previous post about an AI agent that ran a ransomware attack with no human involved past picking the target, and it applies just as directly here. The agent was somebody's, the access was somebody's, and pretending a vendor relationship changes that math is exactly how businesses end up surprised.

A review that only asks the old questions is missing the half that actually matters now.

What Happens to Your Inputs, and Who Trains On Them

Start with the most basic question, and don't let a vendor slide past it with a vague answer. Once you send data into this tool, what actually happens to it? Processed and dropped right after, or kept around, and for how long? For a law firm or any business handling sensitive information, that's not a nice-to-have detail; it's the whole ballgame. Privileged material flowing into a third-party tool needs a real, written answer, not a comforting shrug about how the vendor "takes security seriously."

Then ask the part vendors most often bury in language built to be skimmed right past. Does anything submitted get used to train, tune, or improve the vendor's models? Plenty of enterprise AI contracts now explicitly exclude customer data from training use, and that exclusion needs to show up as an actual clause, not something inferred from a marketing page with a lot of confident adjectives on it. If a vendor can't point to the specific line, assume it isn't excluded. It's one of the clearest red flags in the whole review, mostly because it's refreshingly binary. Either the clause exists or it doesn't.

This is really the same access question we keep coming back to across this series, just wearing a different outfit. Scoping exactly what an agent can reach matters just as much when the agent belongs to someone else's platform. Your data doesn't care whose logo is on the login screen.

Who Else Touches Your Data, and How Fast You'll Hear About It

Very few AI vendors run their entire stack on infrastructure they built end-to-end, and that surprises people every time it comes up. Most lean on underlying model providers and a handful of other subprocessors, each one another link your data, and your liability, passes through on its way somewhere. Ask for a current subprocessor list, and ask what happens when it changes, because it will change. A vendor with a mature process notifies you with real advance notice and gives you a genuine way to object, not a one-line update buried in a changelog nobody reads.

Every vendor contract should also spell out, in an actual number, how fast you'll hear about a breach that could involve your data. "As soon as reasonably possible" isn't a number; it's a vendor buying itself wiggle room. Check that window against your own regulatory obligations, since your vendor's notification clock needs to leave you enough runway to actually meet your own deadline, not eat up the whole window before you've even heard there's a problem.

This is exactly the kind of scenario worth rehearsing before it happens for real. Knowing how fast you'll hear from a vendor feeds directly into how fast your team can actually respond, and a runbook built without that piece is missing a step it'll need on the worst possible day to discover it.

Where Liability Actually Lands

This is the part of the contract everyone skims fastest during a sales call, and it's exactly the part that matters most the day something actually breaks. Read the limitation of liability clause specifically for how it treats AI-driven mistakes, not just the garden-variety software bug it was probably written for. Does the vendor's cap apply the same way to damage from the AI's own autonomous action as it does to a regular glitch? Some contracts draw a real distinction here, shrinking the vendor's exposure for anything the AI "decided" to do on its own, which quietly shifts a lot more risk onto you than a standard deal ever would. And nobody points that out on the sales call, for what it's worth.

Also, confirm directly whether the contract addresses what happens if the agent acts outside its intended scope, whether from manipulation, a plain error, or a gap in its own guardrails. A vendor who's actually thought this through has specific language built for that exact scenario. One who hasn't falls back on generic boilerplate written for a world where software didn't act on its own, and that gap is precisely where "the AI made the decision" stops being the vendor's problem and starts being yours.

None of this is theoretical. Knowing whether an autonomous action reached outside your walls is the same question our monitoring guide walks through for tools built in-house, and it applies just as much to a vendor's agent running inside your systems. If you can't answer it for your own tools, there's no chance you're answering it for someone else's.

Vetting the Vendor Is Vetting Your Own Exposure

Pull it all together and the checklist is honestly shorter than it feels while you're working through it. Confirm what happens to your data once it's submitted. Get the training exclusion in writing, with the clause named, not implied. Get the current subprocessor list and a real process for hearing about changes to it. Nail down a breach notification window measured against your own regulatory deadlines. And read the liability language specifically for how it treats autonomous action, not just ordinary bugs.

Businesses that handle this well treat vendor review as an extension of the access scoping work covered earlier in this series. The same discipline about what an agent is allowed to do applies just as much to one somebody else built. Not writing the code yourself doesn't shrink your exposure; if anything, it adds a layer, since now you're trusting the vendor's governance stacked on top of your own.

There's an issue here too. An agent connected to a vendor's platform still holds real credentials inside your systems, whether you built it or licensed it, and that's exactly the frame our piece on AI agents as an insider threat works through. A vendor's tool going sideways doesn't feel any less like an inside job just because the code came from somewhere else.

The Checklist That Actually Protects You

This post has worked through one shift in how vendor relationships need to be handled. An AI vendor isn't just a tool; it's a relationship that carries data handling, training use, subprocessors, and liability wherever your business connects to it. Most vendor reviews still run on questions built for regular software, and that gap between what gets asked and what actually matters is where real exposure quietly builds.

That gap only grows as more AI features get bolted onto tools a business already vetted years ago, often without anyone re-running the review for the new capability. It also connects straight back to the discipline that opened this whole series: none of these vendor questions mean much if a business doesn't even know which agents and vendor tools it's running in the first place.

Heroic Technologies runs this exact kind of vendor vetting for law firms and other compliance-heavy businesses across the West Coast, since an unreviewed AI vendor isn't a hypothetical to Heroic's team; it's the gap showing up in nearly every environment worth a second look. Building this discipline into how a business evaluates new tools and reviewing the vendors already in place is core to how Heroic approaches AI governance for clients.

Connect with Heroic's team before signing your next AI vendor contract. It's a much easier conversation to have before the ink dries.

Key Takeaways

• An AI vendor connected to your systems isn't just a software purchase; it's a relationship that carries data handling, training use, and liability questions a normal vendor review often misses.
• Get a written answer on what happens to submitted data, and confirm training exclusion with the actual clause named, not implied.
• Request a current subprocessor list and a real notification process for changes.
• Insist on a specific breach notification window measured against your own regulatory deadlines.
• Read the liability clause specifically for how it treats autonomous AI action, not just ordinary software bugs.
• Vendor vetting is really just an extension of the access scoping discipline that applies to any AI agent, whether you built it or licensed it.

Frequently Asked Questions

1. What if a vendor won't share their subprocessor list?
Treat that as a real red flag, not a small gap to work around. A vendor unwilling to say who else touches your data is one you genuinely can't assess, no matter how good the demo looked. That unwillingness usually says more about their own maturity as a company than about the specific answer they're avoiding, and it's worth taking seriously before you sign anything.

2. Does this apply to AI features bundled into tools we already use, or just standalone vendors?
Yes, and it's one of the most commonly missed spots in the whole process. An AI feature added to a platform vetted years ago deserves its own version of this review, since the original vetting never accounted for a capability that didn't exist yet. Businesses tend to assume a platform they already trust extends that trust automatically to every new feature it ships, and that assumption is exactly where gaps open up.

3. How does this connect to what happens if a vendor's AI actually causes a problem?
Vendor review and incident response are really two ends of the same rope. The review lowers the odds of a bad outcome happening in the first place, and the response plan handles the day one happens anyway, since no amount of vetting gets you to zero risk. That's exactly what our incident response guide walks through, and the two pieces work best when a business has both in place rather than leaning on just one.