AI-Specific Risks in SaaS Vendor Due Diligence

The question seems simple enough: does your AI feature train on our data? In practice, most vendor representatives can't answer it on the spot, and that gap says everything about where vendor due diligence stands right now. Standard due diligence was built to answer one question: will this software keep doing what it did yesterday. AI-enabled SaaS breaks that premise entirely. A model can change its behavior overnight, use your data in ways your contract never named, and route your prompts through a sub-processor nobody on your team has heard of.

The average mid-market company runs dozens, sometimes hundreds, of SaaS applications, and most of those now carry some form of AI feature. Here's the part that should give any TPRM lead pause: most of these tools were never bought as AI products. They're CRMs, HR platforms, project management tools, the productivity suite everyone already had a contract with. The AI showed up later, folded into a routine product update. No new sales call, no amended contract, often not even an email flagging the change.

That's the quiet part nobody puts in the board deck. Updates land without a formal notice to IT or security, and without triggering the kind of vendor review that would normally accompany a net-new AI purchase. So a company's actual AI exposure across its vendor stack runs well ahead of what its vendor inventory says on paper. Some security teams have started scanning DNS traffic and web logs just to figure out which approved tools are quietly calling out to AI APIs. That's a rough workaround, and needing it at all tells you how blind the standard channels really are.

What standard due diligence actually checks — and what that leaves unexamined

Walk into most vendor risk reviews and you'll find the same four pillars: financial stability, uptime history, security controls, compliance attestations like SOC 2. All useful. None of it touches what an AI model actually does with your data, or how it might behave differently next quarter.

SOC 2 tells you a vendor had certain controls in place on the day of the audit. It says nothing about whether that vendor retrains on customer inputs, what its model does with an edge-case prompt, or how its safety filters are tuned. A standard questionnaire asks whether data is encrypted at rest and in transit; it doesn't ask whether your support tickets are getting fed into the next training run. Industry analysis has pointed to exactly this gap: SOC 2 reports and generic risk questionnaires often lack the detail needed to pin down how a vendor actually uses AI.

Call it the audit snapshot problem. A vendor reviewed in January can swap model weights, rewrite system prompts, or loosen a safety filter by March, and nothing obligates them to tell you. No renewal trigger, no re-review, no flag anywhere in your GRC tool. The vendor you approved and the vendor now sitting inside your environment can be, functionally, two different products wearing the same name. Standard frameworks have no way to catch that kind of drift, because software that doesn't learn never needed one.

Four risk categories fall through this gap entirely. I want to walk through each one, because they don't get equal airtime in most conversations I've had with security teams, and they should.

Model behavior risks that no questionnaire can capture at a point in time

Traditional software runs the same today as it did last Tuesday. AI models don't carry that guarantee. Weights change, training data changes, safety filters get retuned, system prompts get rewritten, and none of it requires a notice to you.

The result is non-determinism: same input, different answer, depending on the day. The vendor's actual risk posture can shift week over week even though nothing in your contract changed.

Model drift is the technical name for one version of this. A model that behaved fine at onboarding, one that passed whatever validation you ran, can wander into unreliable or non-compliant territory as it keeps getting retrained on new data. Nobody signs off on that drift. It just happens in the background, and the enterprise finds out when something breaks, usually in front of a customer.

Hallucination turns this from a curiosity into an operational risk once you're in legal, financial, or clinical work. An output that reads confident and sounds correct but is factually wrong doesn't stay the vendor's problem. It becomes yours, because you're the one who deployed it into a workflow that touched a client or a patient or a filing. AI washing makes the whole thing worse, too: vendors have every incentive to oversell accuracy, and most enterprises don't have the technical bench to independently test those claims during a routine review.

None of this is a one-time check. Model behavior needs to be watched continuously, and that's not how most vendor risk programs run today.

How vendors use your data to train their models, and why contract language often obscures it

Here's the question standard due diligence almost never asks directly: does this vendor use what I feed it to make its model smarter? For consumer-grade AI tools, the historical default has been yes, unless you find the opt-out and click it. A lot of enterprise deployments inherit that same default without anyone realizing it happened.

Contract language often doesn't help. Industry observers have found a large share of enterprise AI contracts missing real clauses on data residency and model deprecation, the two things that actually determine what happens to your data over time.

Two traps show up often enough that I've started warning clients about them by name. First, the aggregation loophole: a vendor offers a training opt-out, then carves out "aggregated and anonymized data," meaning a de-identified version of what you gave them can still feed the model, technically without breaking the opt-out you thought you had. Second, the rolling amendment clause: plenty of AI vendor contracts let terms change with short notice, so a training opt-out you negotiated this year can quietly disappear at the next renewal, as long as the vendor gave you the notice period the contract requires.

The FTC flagged this pattern directly in February 2024, warning that companies quietly rewriting their terms of service to expand data practices — particularly to support AI training — risk unfair or deceptive conduct violations, and that affirmative consent is required before adopting more permissive practices retroactively.

Then there's the geography problem. Where your data sits and gets processed carries its own compliance weight under GDPR, the EU AI Act, and various sector rules, and generic vendor questionnaires almost never dig into that with any real precision. An employee dropping a client proposal or a personnel file into an approved AI tool may be feeding a system with no data processing agreement behind it, no retention limit, and no audit trail to check later.

The fourth-party problem: most AI SaaS tools are wrappers around models the enterprise never evaluated

Most AI features bolted onto SaaS tools aren't built from scratch. They're wrappers. Your note-taking assistant calls one foundation model, your support chatbot calls another, your code review tool routes through a third, and in each case, that underlying model provider is a company your vendor onboarding process never touched.

The direct vendor is the third party you signed with. The model underneath is the fourth party, and its risk becomes your risk the moment your data crosses into it. Standard questionnaires rarely surface these sub-processor relationships, and vendors have little reason to volunteer a list they didn't have to disclose.

There's a concentration problem sitting underneath all of this too. A small handful of foundation model providers now sit beneath a large share of AI features across the enterprise software market. So a pricing change, a policy shift, or a regional restriction at any one of those providers ripples out across a wide swath of tools at once, regardless of how many separate vendor contracts you hold. A major AI provider outage in mid-2025 made this concrete: companies that hadn't built any fallback found core business functions simply stop working, with no vendor-level lever to pull.

FINRA's mid-2024 guidance names this fourth-party layer outright, calling it a distinct due diligence obligation for financial firms rather than folding it into general vendor risk. Industry breach cost data backs up why this matters: supply chain attacks carry the highest average cost of any breach vector and the longest time to contain. AI features stretch that supply chain further than either the enterprise or its direct vendor has fully mapped.

Algorithmic bias as a vendor risk — and why the enterprise bears the liability

AI features inside HR, lending, housing, and screening tools can produce discriminatory outcomes, whether or not anyone intended that outcome. The EEOC has been direct about who owns that problem: the employer, not the vendor. An employer stays liable for the discriminatory effects of an algorithmic tool built by an outside company, and can't lean on that vendor's own internal assessment of its own bias.

Scale is what makes algorithmic bias different from a single biased human decision-maker. One flawed model, deployed across many employers or platforms at once, multiplies its errors across thousands of decisions simultaneously, something no individual manager could ever replicate on their own.

Two cases make this concrete. SafeRent settled a case involving an AI scoring tool used for housing recommendations, built on an algorithm applicants never got to see, for a settlement north of two million dollars. Workday is facing a nationwide class action from applicants over forty who say its AI screening system rejected them; that case got certified in May 2025, a signal that class-action exposure over vendor AI discrimination has moved from theory to active litigation.

Meanwhile, contract language often works against the enterprise here too. A large majority of AI vendor contracts cap liability, frequently at the monthly subscription fee, which means the company deploying the tool absorbs legal exposure that the vendor has already written itself out of. Standard due diligence doesn't ask vendors to show bias audit results, disclose disparate impact testing, or grant the enterprise any visibility into how the model actually makes its decisions. All of that is now legally material, and none of it shows up on a standard questionnaire.

Shadow AI inside approved vendor relationships — the risk that lives between the contract and the workflow

Shadow AI isn't the same animal as shadow SaaS. A rogue SaaS subscription just stores your data somewhere you didn't approve. A shadow AI tool might train on that data, generate outputs that turn into real business decisions, or ship your data to sub-processors nobody on your team ever assessed.

A large share of generative AI use inside companies happens through personal accounts, sidestepping whatever controls IT put in place. That flips the logic of vendor due diligence on its head: the approved vendor's own data handling now needs to be the primary line of defense, not the backup plan.

Industry breach data tied a meaningful share of enterprise breaches to shadow AI, with each of those incidents adding significant cost on top of the average breach cost. But here's the trickier version of the problem: an employee using an AI feature inside a sanctioned platform isn't breaking any policy. They're just using the tool the company approved. That feature might still be routing data through a sub-processor nobody vetted, under training terms nobody negotiated.

This is where onboarding, a single moment in time, and vendor reality, a capability set that keeps evolving, pull apart. That gap is where the actual damage happens.

The regulatory framework that now attaches liability to vendor AI choices the enterprise makes

The EU AI Act took effect in August 2024, with obligations rolling out in phases through late 2027. Buried in it is a detail that catches a lot of companies off guard: if you integrate a third-party AI service into your own product or workflow, and you substantially modify it or put it on the market under your own name, you can become the "provider" of that system under the law. You inherit compliance duties for a model you didn't build and don't control.

The penalties aren't symbolic. Fines run into the tens of millions of euros, or a percentage of global annual revenue, whichever number is bigger. High-risk categories under the Act, covering employment, credit, biometrics, critical infrastructure, come with conformity assessments, data governance documentation, and human oversight requirements that flow straight down into vendor contracts.

The US is building its own patchwork alongside this. Colorado's AI Act takes effect in 2026 and classifies employment AI as high-risk. New York City's Local Law 144 already requires bias audits and public disclosure for automated employment tools. Illinois requires disclosure whenever AI plays a role in an employment decision. Every one of these rules lands on the company deploying the tool, regardless of who built it. FINRA's mid-2024 notice adds another layer specific to financial services: due diligence on third-party AI vendors, validation of data protection terms inside vendor contracts, and fourth-party exposure, named as distinct regulatory obligations rather than general best practice.

The pattern across all of it is the same. Liability flows down the value chain. A company can end up answering for a vendor's non-compliant AI system, and the boilerplate due diligence questionnaire most teams still run was never built to catch that exposure, let alone allocate it in a contract.

What AI-specific due diligence actually requires — the questions, controls, and ongoing visibility that standard programs lack

So what does a program built for this actually look like? I think about it in three parts, and they only work if they run together.

Start with the questions a standard questionnaire skips entirely. Does the vendor train on customer inputs, and does the opt-out actually hold up against future term changes? Who are the sub-processors behind the AI features, what data reaches them, and where does it get processed? Has the vendor run bias or disparate impact testing, and will they let you see the results? What happens to your data on deletion, and does that deletion reach backup and archival copies too? If the vendor's underlying model provider goes down or changes policy overnight, what's the fallback?

Then come the contract terms that need to be negotiated by name rather than assumed. Training opt-outs that survive a rolling amendment, with an explicit line drawn around aggregated or anonymized data. Data residency terms specified down to the sub-processor level, not just the vendor's own address. Liability language that doesn't cap AI-specific harm at the price of the monthly subscription. And a requirement that the vendor notify you before making a material change to model behavior or safety filters, not after the fact.

Last comes monitoring, because a point-in-time review can't hold for something that keeps changing shape. A model cleared in January can behave differently by March. New AI features show up inside tools you already approved, often without any announcement. Sub-processor relationships shift after the contract's signed, not before, so tracking that exposure has to continue past onboarding.

Frameworks like ISO/IEC 42001 and the NIST AI Risk Management Framework give assessors real structure for judging how mature a vendor's AI governance actually is, a sharper signal than a generic compliance badge. Purpose-built AI risk intelligence tools, the kind designed for continuous vendor AI monitoring, are what make ongoing visibility possible at all: they surface new threats across a vendor ecosystem as they emerge, covering ground that a governance framework or an annual questionnaire simply can't reach by design. For TPRM, InfoSec, privacy, and legal teams working this problem together, that's the real gap to close: knowing what a vendor's AI looked like the day you signed tells you almost nothing about what it looks like right now, on the Tuesday when it actually matters.