The short answer
The right AI vendor review starts with the intended use, information sent to the system and consequences of an incorrect output.
Review the use case, not just the vendor label
An AI vendor risk assessment examines the risks of using an externally supplied AI product or service. The same system may be relatively low exposure for drafting public text and much higher exposure when handling confidential records or influencing consequential decisions. Begin with intended use, users, data and the actions the system can take.
NIST's AI Risk Management Framework is voluntary guidance built around Govern, Map, Measure and Manage. It supports structured consideration of AI risks but is not a universal compliance checklist. Use it alongside security, privacy, legal and business review appropriate to your context.
Draw the data and dependency map
Identify prompts, uploaded documents, retrieval sources, logs and outputs. Ask where each is processed and retained, who can access it and which terms apply to training or other reuse. Do not assume that a provider's consumer product and enterprise service have identical data practices.
- What information leaves your environment and which entities receive it?
- Which retention, deletion and training-use controls apply to your contract?
- Which model providers, subprocessors or connected tools are involved?
- What permissions do agents and integrations receive?
Evaluate failure in the real workflow
Incorrect or fabricated outputs, bias, sensitive-data disclosure and misuse can create different harms depending on the task. Define what a failure looks like before running evaluations. A polished demonstration is not evidence that the system is reliable for your documents, languages or users.
Use representative, permissioned test cases and compare outputs with independently established answers where possible. Record limits, error patterns and circumstances that require human review. Avoid uploading personal or confidential information to an unapproved trial simply to complete vendor diligence.
Treat connected actions as a separate exposure
An assistant that only suggests text is different from an agent that sends messages, queries records or changes systems. Review least-privilege access, action approval, logging and rollback. Treat retrieved documents and third-party content as untrusted inputs, particularly when they can influence tool use.
Ask how the provider addresses prompt injection and data leakage, but do not treat a claim of protection as proof that all attacks are prevented. Apply safeguards in your own integration, including limited permissions and human approval for consequential actions. CISA's secure-deployment guidance provides a useful operational starting point.
Reassess when the system changes
Model updates, new tools, expanded data sources and changed business use can invalidate earlier conclusions. Agree notification expectations where possible and keep a record of the evaluated configuration. Define who can pause use when performance or security falls outside accepted conditions.
The final decision should state approved uses, prohibited data or actions, required human oversight, unresolved concerns and reassessment triggers. An AI feature should not silently inherit approval from an older non-AI service. Make the decision specific enough that employees can tell whether a new workflow is covered.
Sources & further reading
Primary-source guidance informs these articles. Example workflows are illustrative, not regulatory requirements.