I was assessing a vendor relationship that covered several different business functions.
AI existed in parts of the vendor’s broader product portfolio, so it would have been easy to look at the company and say: this is an AI-enabled vendor.
But that didn’t tell me which AI capabilities were actually part of the relationship I was assessing.
I asked the vendor directly which AI features were being used. The response helped, but I still didn’t have a clear answer for every AI capability.
That left me with a scoping problem.
I couldn’t treat AI as one “Yes” or “No” answer and then assume every AI question belonged in the assessment. I had to start with what the AI was actually doing.
Some questions applied. Others didn’t.
A vendor might use a third-party model without training or fine-tuning it. Data might pass through an AI feature without being used to train the model. And AI that helps a user do something can raise very different questions from AI that influences a decision.
Those differences matter.
If the vendor isn’t training or fine-tuning models, questions specifically about those activities may not apply.
But that doesn’t make the AI use irrelevant.
I still need to know what the feature does, what data reaches it, who uses it, what happens to the data, and what the output is used for.
In this assessment, I couldn’t assume that every AI capability somewhere in the vendor’s portfolio was part of the service being used.
I also couldn’t assume that once I confirmed some AI use, the entire AI questionnaire suddenly applied.
The use case had to come first.
I think broad AI questionnaires can sometimes put that order backwards.
Instead of first understanding the AI use and then deciding which questions matter, the questionnaire becomes the way we discover what the vendor is actually doing.
The vendor gets a long list of AI questions and figures out applicability while answering them.
Sometimes that may be unavoidable, especially when very little is known at the start.
But it shouldn’t be the goal.
I’d rather understand enough about the AI use first to know which questions actually belong in the assessment.
That doesn’t mean I need every technical detail before I begin.
I just need enough to distinguish between things that create very different risks.
A simple field that says AI: “Yes” doesn’t give me that.
It would be more useful to capture the actual use case and a few basic facts about it, then use those to narrow the questions that probably apply and identify what still needs clarification.
That still doesn’t make the decision for the assessor.
The vendor’s description may be incomplete. Two AI features that sound similar may still work very differently. I still have to decide whether I understand the use well enough to scope the assessment properly.
But I want to make that decision based on the AI that is actually being used, not everything the vendor happens to offer.
When AI is present in a vendor relationship, what do you establish about the actual use case before deciding which AI controls belong in the assessment?
