The most common AI risk in regulated organizations today is not a model your team built. It is a feature that was quietly added to a SaaS product you already pay for. The CRM that now drafts emails. The ticketing tool that summarizes conversations. The HR platform that scores candidates. Every one of those is a third-party AI system in production, and most of them entered the environment without a vendor security review that asked a single AI-specific question. The vendor risk program that worked for ordinary SaaS is producing answers that do not address how these products actually behave.
Most of the AI exposure sitting in regulated environments right now is third-party exposure. Closing that gap is one of the higher-value moves a security and compliance team can make this year, and it does not require a new program. It requires the existing third-party risk program to ask different questions.
What Has Changed in the Vendor Relationship
For most of the last decade, vendor security review treated a SaaS product as a stable artifact. The vendor described what the system did, evidenced its controls, and barring a material change, the assessment was good for a renewal cycle. AI features have broken that assumption. A vendor can ship a generative feature into a product mid-contract, route customer data through a model provider you have not assessed, and the only signal you receive is a release note. The system you reviewed last year is not the system in production today.
The chain of custody also got longer. A typical AI-enabled SaaS product now involves the vendor itself, one or more model providers behind their feature, sometimes a vector database, and a layer of orchestration software. Each link can have its own data handling, its own subprocessors, and its own retention behavior. The standard vendor questionnaire was built for a two-party relationship. The relationship is now a chain, and the weakest link defines the risk.
The Questions a Modern Diligence Has to Answer
What model providers are in the path, and under what terms. The vendor's third-party AI providers are now your fourth parties. You need their identity, the geographic location of their inference endpoints, whether your data is used for training, the retention window for prompts and outputs, and what enterprise terms the vendor has negotiated. A vendor that cannot tell you which model provider sits behind a given feature is a vendor whose data handling you cannot characterize.
What data the AI feature actually sees. Not what the vendor processes generally. What the AI feature sees, specifically. A support ticketing tool may have access to PHI in the broader product but route only metadata to the summarization model. Or the opposite. The answer changes the risk classification, and most vendors have not documented this clearly enough for their own engineers, let alone for a customer security review.
How model outputs are validated before they reach a customer system. A model that generates a record update, sends a customer email, or files a support response is producing output that can affect downstream business processes. The vendor's controls on hallucination, jailbreak resistance, and output validation are now part of your operational risk. "The model is reliable in our testing" is not a control. Show me the gate.
Whether the vendor can ship AI changes without notifying you. Read the contract. Many SaaS agreements give the vendor latitude to add features without notice. AI features that handle your data should not fall under that latitude. If the contract does not require advance notice and an opt-out for material AI changes, the renewal is the moment to fix that. Vendors that resist this are vendors whose product roadmap will outpace your governance.
What logging and audit access the vendor provides for AI activity. When an incident touches an AI feature, can your team see what the feature did, with what inputs, on whose behalf, and when? Most vendors do not expose this. The ones that do are visibly ahead, and that capability is becoming a procurement differentiator in regulated buyer segments.
How the vendor handles data deletion for AI components. Deletion from the primary database is one thing. Deletion from cached prompts, fine-tuning datasets, vector indexes, and the model provider's logs is another. The vendor's deletion guarantee should explicitly extend to AI-adjacent storage, and the answer for most vendors today is murky enough to matter.
Where Existing Frameworks Help and Where They Stop
SOC 2 reports are useful but not sufficient. The control framework was not written for AI, and a clean SOC 2 tells you the vendor has a working control program, not that the control program addresses AI-specific risks. Read the system description in the report carefully. Many vendors have added AI features without scoping them into the audit, which means the report's assurance does not cover those features at all.
ISO 27001 is in the same position. The certification confirms an information security management system. It does not confirm AI-specific governance. Vendors that have added ISO 42001 to their certification stack are signaling that they have built an AI management system on top of the existing ISMS, and that addition matters more in 2026 than it did a year ago.
Standardized questionnaires are catching up. The CSA AI questionnaire, additions to the SIG, and the customer-specific AI addenda we are seeing in procurement cycles are converging on a workable baseline. None of them yet replace a custom assessment for high-risk AI features, but they are now reasonable starting points instead of empty templates.
"The vendor security review that worked five years ago will pass an AI-enabled product that introduces material risk into a regulated environment. The questionnaire didn't get worse. The product got more complicated."
Tiering the Vendor Population
Not every AI-enabled vendor needs the same depth of review. A reasonable tiering model in practice has three levels.
Tier one is AI as a core feature in a high-risk context. The vendor's AI does something that materially affects regulated processes, customer interactions, clinical or financial decisions, or sensitive data handling. This tier needs full AI-specific diligence: model providers, data flows, output controls, audit access, contract terms covering AI changes, and a documented review at every renewal regardless of contract clock.
Tier two is AI as a feature in a moderate-risk product. Productivity tools, knowledge management, internal automation. The AI exposure is real but bounded. A streamlined AI-specific addendum to the standard vendor review is appropriate, focused on data handling, retention, and the right to opt out of AI features.
Tier three is AI as an incidental feature in a low-risk product. Marketing tools, scheduling, internal communications without sensitive content. The standard vendor review with two or three AI-specific questions is enough. The cost of deeper review is not justified by the risk.
The tiering needs to be enforced at intake, not after the fact. If procurement requests do not flag AI features for tiering before the contract is signed, the program is reacting to a problem instead of preventing it.
Contract Language That Holds Up
Three clauses are worth pushing for on any tier-one vendor, and worth attempting on tier two.
Notice and opt-out for material AI changes. The vendor commits to notify the customer in advance of any material change to AI features that process customer data, with a right to opt out without affecting non-AI functionality. This is the clause that protects the security review's shelf life.
Disclosure of subprocessors including model providers. The vendor maintains a current list of model providers and AI subprocessors, with notification of additions or substitutions. This converts the unknown chain of custody into a known one.
Audit rights and incident reporting covering AI activity. The vendor's incident reporting obligations and audit cooperation explicitly extend to AI features. Many vendor incident clauses were written before AI was in scope and do not clearly cover an AI-specific failure.
None of these clauses are exotic. The legal teams negotiating them increasingly accept them. The vendors that resist all three are signaling something about their AI maturity, and that signal is worth listening to.
What to Do This Quarter
Inventory the AI-enabled vendors in your environment. Most teams underestimate this number by half. Include any vendor that has shipped an AI feature in the last twelve months, whether or not the feature is in use.
Tier the inventory. Most of the vendors will land in tier two or three. The handful in tier one are where the program's attention should concentrate.
Refresh the questionnaire. Add the questions above as a standard AI addendum. Send the addendum to tier-one vendors regardless of where they sit in their assessment cycle. The findings will inform renewal strategy.
Push the contract language at the next renewal window. Not every renewal will get all three clauses. Some will get one, and that one is progress. Track which vendors accept which terms and use the pattern to inform negotiating posture going forward.
The Bottom Line
Third-party AI risk is the part of the AI risk surface that most regulated organizations are underweighting right now. The internal programs get attention because they are visible. The vendors are quieter, and their changes land in your environment whether you reviewed them or not. The teams that close this gap in 2026 will not do it by building a new program. They will do it by asking the third-party risk program to look at vendors the way the threat landscape now requires.