AI vendor due diligence is failing in a very specific way: companies are reviewing the vendor as if they were buying ordinary SaaS, while the product behaves more like a moving supply chain.
That mismatch matters. A vendor can hand over a clean SOC 2, sign a reasonable DPA, and still create serious enterprise risk once the product starts handling prompts, files, metadata, model outputs, and customer configurations across a stack of subcontractors and rapidly changing model providers. Procurement says the box is checked. Security says the review is complete. Six months later, nobody can clearly explain where sensitive data goes, which model processed it, what changed, or who approved the change.
This is not a paperwork problem. It is an operating model problem.
Why normal vendor review breaks on AI products
Most enterprise third-party review processes were built for software with relatively stable boundaries. You assess hosting, identity controls, logging, encryption, incident response, and maybe some privacy terms. That works reasonably well when the product architecture is predictable and major changes move through formal release cycles.
AI products do not stay still long enough for that assumption.
A vendor may start with one model provider, then add another for cost or performance. They may move from API access to fine-tuning. They may retain prompts for abuse monitoring. They may add admin features that expose usage data in new ways. They may quietly route traffic through additional subprocessors for evaluation, annotation, search, or content safety. None of that necessarily shows up in the initial security questionnaire in a meaningful way.
The result is a familiar enterprise mistake: you reviewed the wrapper, not the workflow.
That is where risk hides.
The real failure mode: approved vendor, unapproved data path
The cleanest way to think about AI vendor risk is this: what data enters the system, what happens to it in transit and at rest, what external systems touch it, and what can change without you noticing?
Most reviews spend too much time on control statements and not enough on data path reality.
A few common examples:
An employee uploads a customer contract into an AI assistant embedded in a sales platform. The platform vendor is approved. What was not understood is that the document is parsed by one service, enriched by another, screened by a third-party safety layer, and then sent to a model provider with separate retention rules. The approved vendor was only the front door.
A coding assistant is deployed for engineers. Security reviews the vendor and confirms enterprise settings are available. But the actual risk sits in repository scoping, telemetry defaults, prompt retention, and whether the provider uses customer interactions for model improvement outside the enterprise tier. The dangerous choice is not buying the product. It is deploying it with the wrong defaults.
A contract analysis tool passes legal review because the DPA looks acceptable. Six weeks later, the vendor switches model providers to improve extraction quality in certain regions. The enterprise never learns about it because the change was considered part of normal service delivery. Privacy and residency assumptions are now wrong, but the paperwork still says everything is fine.
This is why static due diligence produces false confidence. The most important part of the risk picture is often the part that changes after signature.
What security teams should actually verify
Better AI vendor due diligence is less about asking more questions and more about asking the questions that force architectural clarity.
Start with data classes, not product features. What exact enterprise data will users submit, intentionally or accidentally? Prompts, files, screenshots, source code, customer records, HR data, meeting transcripts, and usage metadata do not carry the same risk. If the vendor cannot map which data types may enter which functions, your review is already weaker than it looks.
Then map the processing chain. Not the marketing architecture. The actual path. Which subprocessors, model providers, safety layers, retrieval services, and storage environments touch customer data? Which ones are optional? Which ones vary by feature, geography, or service tier? If the answer is buried in a generic subprocessor page, you do not have enough detail.
Then test for change risk. What can the vendor change unilaterally that would alter your risk posture? Model provider changes, retention defaults, training usage, new features enabled by default, cross-border processing, admin visibility, and logging behavior all matter. If the contract has no meaningful notice requirement for material AI stack changes, your review has a large blind spot.
Then examine control reality at the configuration layer. Many AI products are safe enough only when enterprise settings are actively configured and monitored. Admin toggles for retention, tenant isolation, connector permissions, workspace sharing, human review, or external model access are not implementation details. They are the control set.
Finally, force an answer on accountability. Who in your company owns reevaluation when the vendor changes the model, adds a feature, or expands data use? If nobody owns that trigger, the initial review is just ceremonial.
Procurement should stop treating AI as a one-time intake event
This is where many enterprises quietly lose the plot.
They have a due diligence gate before purchase and almost nothing credible after go-live except annual reassessment. That cadence is detached from how AI vendors actually evolve. A yearly review is fine for checking certificates and policies. It is weak for services that can materially shift behavior, dependencies, and data handling in one release cycle.
The practical fix is not to create a giant governance machine. It is to define a small set of event-driven review triggers.
Examples: a change in model provider, introduction of training on customer data, launch of new connectors, expansion into regulated use cases, changes to retention policy, or new subprocessors handling customer content. Those events should trigger a targeted reassessment by security, privacy, or both.
This is manageable if you keep it focused. It is miserable if you wait until after rollout and then discover no one can tell whether the new feature sits inside the approved boundary.
What executives should ask before approving deployment
Executives do not need to become AI architects, but they should stop accepting generic assurance language.
Three questions are usually enough to expose whether the review was real.
First: what sensitive data could realistically enter this product, even if that is not the intended use case?
Second: what external parties or model providers can touch that data today?
Third: what changes could the vendor make without coming back for approval?
If the answers are vague, the risk is not understood. If the answers depend on enterprise settings, ask who is accountable for verifying those settings remain in place.
That last point matters more than most steering committees admit. Plenty of AI incidents are not caused by malicious vendors or dramatic failures. They come from mundane drift: a default changed, a connector was enabled, a team used the tool on data it was never approved for, or a vendor updated the service faster than internal governance could keep up.
The practical takeaway
AI vendor due diligence should be treated as a living control, not a procurement checkpoint.
That means reviewing the actual data path, identifying where the vendor can change your risk without much notice, locking down the configuration layer, and defining specific triggers for reassessment. It also means being honest about what your team can monitor after deployment. If you cannot see important changes, you do not control the risk. You are renting reassurance.
That is the uncomfortable truth in a lot of enterprise AI procurement right now. The issue is not that companies are moving too fast. It is that they are approving products with the habits of old SaaS review and the confidence of people who think a signed questionnaire means the system will stay the same.
It will not.
And that is exactly why the review needs to be built for motion, not just for purchase.