Ask a CISO whether their TPRM program covers AI vendors and most will say yes. The vendor filled out the SIG. The CAIQ is on file. Procurement signed off. The control evidence sits in the GRC tool.

None of that is wrong. None of it is enough.

SIG and CAIQ were built on two assumptions that don't hold for AI vendors. The first is that vendor behavior is deterministic: given the same input, you get the same output, controlled by code the vendor wrote and tested. The second is that the vendor's stack is bounded: what they describe in the questionnaire is what's in production, and it changes on a release cadence the questionnaire is fast enough to track.

Both assumptions break the moment the vendor adds a model. And almost every vendor your company buys from is adding a model.

The three things your questionnaire can't see

1. Model behavior under adversarial input

Standard questionnaires ask whether the vendor has secure development, code review, and vulnerability management. Necessary, but for an AI feature those answers cover the wrapper, not the model.

The risk surface that matters is behavior under adversarial input: prompt injection, jailbreaks, output filtering bypass, model extraction. None of these are tested by SIG. None show up in CAIQ. And model behavior changes, sometimes weekly, when the vendor swaps in a new base model or fine-tune. The control evidence on file may describe a model that is no longer in production by the time you read it.

2. Training data lineage

The next set of questions a questionnaire doesn't have a slot for: was our data used to train? Is the model trained on data the vendor had the right to use? Can the vendor produce a provenance trail for the training corpus? If the vendor fine-tunes on customer data, what's the isolation guarantee?

These aren't theoretical. They're already showing up in litigation, in regulatory inquiries, and in customer contracts that flow rights down to vendors. SIG asks about data handling. It does not ask about data lineage going into a model. The asymmetry is enormous.

3. AI sub-processors

This is the one that surprises CISOs the most. Your SaaS vendor adds an "AI assistant" feature. Behind that feature is, almost always, a call out to OpenAI, Anthropic, Google, or an open-weights model running on a third-party inference provider.

That second hop is your fourth party. Sub-processor disclosure forms ask about hosting providers (AWS, Azure, GCP). They do not ask about model providers. Most don't even have a category for it. You have a fourth-party AI dependency that your third-party program cannot see, and your fourth party isn't bound by the contract you signed with the third.

The questionnaire is a snapshot. AI risk is a stream.

Four questions to insert into the next cycle

These are tactical. Paste them into the AI appendix of your SIG, or into a vendor-specific addendum. They map directly to the blind spots above.

1. "Describe your model evaluation regime for adversarial inputs, and the cadence at which it runs."

What you're listening for: a real answer names red-teaming, a defined eval set, results tied to releases, and a cadence shorter than your questionnaire cycle. "We follow the OWASP LLM Top 10" is not an answer.

2. "What models power the AI features in this product, who hosts them, and what is your change management process when the underlying model is updated?"

The first half of this question gets you the sub-processor map. The second half tells you whether the vendor has a process for telling you the model changed, or whether you'll find out from a behavioral incident.

3. "Confirm whether customer data (including prompts, outputs, and metadata) is used for model training, fine-tuning, evaluation, or human review. If so, describe the opt-out path and isolation guarantees."

This question fails the most vendors. The honest answer from many AI-feature vendors is "we don't fully know" because the underlying model provider's terms have changed since the integration was built. That's the answer you need to hear.

4. "Provide a data provenance attestation for the training corpus, including any copyrighted, licensed, or scraped data."

Most vendors cannot answer this for the base models they use because they don't own them. That is still an answer. The control isn't to refuse the vendor. It is to know that the answer is "no attestation available, third-party model" and to price that into the residual risk decision.

The artifact you actually need is continuous

Add these four questions and your program is meaningfully better. It is not adequate.

The reason is that AI vendor posture is not a state the questionnaire is fast enough to track. The vendor's underlying model provider ships an upgrade. Your vendor's "AI assistant" now uses a different model than the one whose evaluations you have on file. Sub-processor changes happen by config flip, not contract amendment. Behavior drifts. Training-data terms get updated unilaterally and apply retroactively.

The shape of this risk is continuous. The artifact has to be too.

That means three things in practice:

  • Continuous monitoring of vendor AI posture, not annual recertification. If your TPRM tool can't track the AI sub-processor graph, model versions, and behavior changes between assessment cycles, it is not built for this.
  • Contract terms that anticipate model change, not just stack change. That means notification of underlying model swaps, training-data-use changes, and sub-processor additions for AI specifically.
  • Internal escalation triggers for AI vendor posture changes that justify re-assessment outside the normal cycle.

If your program does not have a way to see the stream, you do not have an AI vendor risk program. You have a compliance artifact.

Bottom line

If your next TPRM update to the audit committee describes AI vendor risk in the same shape as it describes SaaS vendor risk, it's wrong. The shape is different. The artifact has to be different.

The four questions in this note are a place to start. They are not a place to stop.

If you'd like the questions in this note as a one-pager you can hand to your TPRM team, reach out. We'll send it.