Before choosing an AI vendor, establish what the system will do, whose data and decisions it will affect, which jurisdictions and sector rules apply, and whether your organization is acting as a buyer, deployer, provider, or in more than one role. Then assess the vendor, its supply chain, the system’s evidence and limitations, data and usage rights, contractual controls, and what happens when the service changes or fails. No single certification, questionnaire, or framework proves that a vendor or use case is compliant.
Start with the use case and your legal role
A vendor review is only meaningful against a defined use. “We want to use generative AI” is not enough: a tool that drafts internal notes presents different risks from one that ranks applicants, supports a clinical decision, or communicates directly with customers. Requirements depend on the application, affected people, data, location, and the organization’s role—not simply on the vendor’s product label.
Write down the intended use
- Describe the task, users, outputs, and decisions the system may influence.
- Identify affected people, including customers, employees, applicants, patients, or members of the public.
- Specify what the system will not be used for, and consider foreseeable misuse or use outside the intended workflow.
- Record whether people will rely on, review, override, or act on its outputs, and what human oversight is practical.
Map scope before applying a checklist
List the jurisdictions where the organization, vendor, users, and affected people are located, plus the sector rules and internal policies that may apply. Determine whether your organization is buying a tool for internal use, deploying an AI system in a regulated process, providing an AI system, or taking on multiple roles. Ask legal and compliance owners to confirm the applicable requirements for the particular use rather than assuming every regulated business has the same AI obligations.
For the EU AI Act, first determine whether the system is in scope and whether it is classified as high-risk. Provider and deployer duties are not interchangeable. For high-risk systems in scope, Article 9 requires a continuous risk-management process across the lifecycle, including assessment of foreseeable risks and misuse. Testing should be conducted against predefined metrics and thresholds suited to the intended purpose. A vendor’s general statement that it follows “AI risk management” does not establish that these requirements are met for your deployment.
Use a review framework, not a compliance shortcut
NIST’s AI Risk Management Framework (AI RMF) is voluntary guidance, not a certification or a substitute for applicable law. Its Core is organized around four functions: Govern, Map, Measure, and Manage. NIST says more than 240 organizations contributed to its development over 18 months; that is development history, not evidence that a particular vendor or system is effective. NIST is updating the AI RMF, so check its current status when adopting it.
NIST’s broader Risk Management Framework (RMF) can help organize security, privacy, and supply-chain risk while accounting for applicable laws, policies, standards, and regulations. Neither framework creates a universal pass/fail threshold for AI procurement. Use them to make the review systematic, then map the resulting controls to the requirements that actually apply.
NIST SP 1326, published in final form in July 2026, focuses on ICT supplier due diligence. It describes due diligence research as “the investigative process of researching all available, pertinent information about a given supplier or product so that informed decisions can be made on new acquisitions or existing systems.” Its scope is ICT-focused; use it to inform supplier review, not as a complete AI-specific legal checklist.
Rank #2
Assess the vendor across six areas
Request evidence that is relevant to the proposed use, not just a completed security questionnaire. NIST’s generative AI procurement guidance emphasizes use-case-specific and ongoing assessment, including privacy, security, intellectual property, third parties, and risks that can change across models, APIs, fine-tunes, and embedded tools. The questions below help turn that principle into a documented review.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →| Review area | Questions to ask | Evidence to request |
|---|---|---|
| Use case and legal scope | What purpose, users, affected people, jurisdictions, sector rules, and roles apply? What misuse or unintended use is foreseeable? | Use-case description, system boundaries, role allocation, applicable-requirements mapping, and documented assumptions. |
| Vendor and supply chain | Who owns or controls the supplier? Which subcontractors, models, APIs, fine-tunes, and other dependencies are involved? How are resilience and foundational cyber practices managed? | Ownership and control information, supplier and dependency details, relevant security evidence, resilience arrangements, and notice of material supply-chain changes. |
| Data and rights | What inputs are collected, retained, or used to improve services? Who can access them? What rights apply to inputs, outputs, and third-party content? | Data-flow and retention documentation, permitted-use terms, access controls, confidentiality commitments, and relevant rights and provenance information. |
| System performance and risk | How well does the system fit this purpose? What are its known limitations and risks for reliability, safety, security, privacy, explainability, or fairness? What oversight is needed? | Evaluation methods and results relevant to the use, limitations, safety and security documentation, and information supporting human oversight. |
| Evidence and accountability | Can you monitor use and investigate problems? Who is responsible for decisions, incidents, and approving changes? | Relevant documentation and logs, change notices, incident records, audit or evaluation rights, named contacts, and post-deployment monitoring arrangements. |
| Contract and continuity | What service and security commitments apply? How will the parties handle incidents, changes, service disruption, and exit? | Contract terms for ownership and usage rights, quality, security, provenance, third-party processes, incident cooperation, data return or deletion, and transition assistance. |
Vendor and supply-chain evidence
Look beyond the entity named on the contract. Supplier ownership and control, information provenance, supply-chain tiers, resilience, and foundational cyber practices can affect the risk of a product even when the vendor’s own security program appears strong. Ask which model providers, hosting services, APIs, subcontractors, and embedded tools support the service; what data they can access; and how the vendor assesses and oversees them. Establish how you will be told about material changes to those dependencies.
Data, confidentiality, and rights
Trace data from collection through processing, storage, access, and deletion. Ask whether prompts, uploaded files, outputs, or feedback are retained or used for training or service improvement; whether those uses can be disabled or restricted; and which third parties can receive the information. Confirm how the terms treat confidential, personal, regulated, and third-party information, and what rights the customer and vendor claim in inputs, outputs, and incorporated content. Do not infer a data practice from a product description when the contract or technical documentation is silent.
Rank #3
Fit, evaluation, and limitations
Ask how the vendor evaluates the system and whether the method and evidence match your intended use, users, language, operating conditions, and consequences of error. Request known limitations, relevant evaluation results, and information on how the vendor handles safety, security, privacy, reliability, explainability, and fairness risks. These are trustworthiness characteristics identified by NIST, not a universal scorecard in which every characteristic has equal weight. Decide which matter most for your context, what evidence is sufficient, and what human review or other controls are needed.
Make the review ongoing for generative AI
A procurement decision captures a point in time; a generative AI service can change after approval. A vendor may update its underlying model, API, fine-tune, retrieval system, or embedded tools, and a change can alter behavior, data flows, or dependencies. Agree what changes require notice, reassessment, or approval, and define how your organization will monitor the service after deployment.
Set change and monitoring triggers
- Define which changes are material—for example, a change to the model or subprocessors, retention or training practices, intended functionality, or security controls.
- Agree how much notice the vendor will provide and what information will accompany a change.
- Set conditions for renewed evaluation, such as a material change, incident, drift in observed performance, new use, or change in applicable requirements.
- Decide what usage, output, and incident information your team needs to monitor the deployed system, consistent with privacy and other applicable rules.
For each deployment, define how staff can report harmful or unreliable output, who triages it, and how a concern can lead to restricted use, additional safeguards, or suspension. Monitoring responsibilities should be assigned to named roles rather than left as a general expectation that the vendor or business will “keep an eye on it.”
Put evidence, responsibilities, and remedies in the contract
Documentation and contract terms are part of the control system, not administrative follow-up. NIST’s generative AI procurement guidance recommends addressing ownership, usage rights, quality, security, and provenance, and including clauses that enable evaluation of third-party processes. Ask for the evidence needed to verify commitments and keep the right to review it during the service term.
Agree what each party must do
- Specify permitted uses, data handling, confidentiality, ownership and usage rights, and relevant quality or service commitments.
- Define security responsibilities, incident notification and cooperation, investigation support, and access to relevant records.
- Require notice of material system or supply-chain changes and describe the reassessment or approval process.
- Set out available evaluation, audit, or assurance rights, including how evidence about important third-party processes can be obtained.
- Name the vendor and customer roles responsible for operational questions, incidents, risk acceptance, and escalation.
Where a vendor cannot provide direct access to a third party, decide whether alternative evidence—such as documented assessments or independent assurance—is adequate for the risk. Record any restriction and the residual risk it leaves; do not treat an unavailable audit right as proof that a control exists.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Plan for incidents, failure, and exit
Decide how the business will operate if the vendor’s service is unavailable, produces unsafe or unusable results, or must be suspended. NIST recommends contingency planning for third-party AI failures and incidents, including identifying fallback options and rehearsing incident response.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Best Value
Make continuity practical
- Identify which business processes depend on the AI service and what manual or alternative process can keep them running.
- Define who can restrict or stop use, and how affected teams and stakeholders will be notified.
- Agree incident-cooperation expectations with the vendor, including prompt access to information needed to investigate and respond.
- Document how to export or recover business data, return or delete it at termination, and transition to another service or process.
- Rehearse the fallback and incident process so that responsibilities and operational gaps are discovered before a disruption.
Contractual exit rights matter only if the organization can execute them. Check whether data can be returned in a usable form, whether deletion can be confirmed, and whether transition assistance and continued access are sufficient for the business to move safely.
Record the decision and its conditions
A defensible decision record should make clear why this particular system is acceptable—or not—for this particular use. It should enable a reviewer to distinguish verified controls from vendor assertions, accepted risks from unresolved questions, and a conditional approval from an unrestricted one.
- Define the use and scope. Record intended purpose, affected people, data, jurisdictions, organizational role, and applicable requirements.
- State the criteria. Identify the risk and performance questions that matter for this use, and what evidence or threshold will satisfy each one.
- List evidence reviewed. Include its date, source, scope, and any limitations; distinguish documentation, test results, contractual promises, and verbal assurances.
- Assign owners. Name the people accountable for legal and compliance interpretation, security and privacy review, business use, and residual-risk acceptance.
- Track open issues. Record unresolved risks, their impact, mitigations, deadlines, and any compensating controls.
- Set approval conditions. State any limits on data, users, purpose, geography, human review, or vendor changes, along with monitoring and reassessment triggers.
- Decide and revisit. Approve, conditionally approve, defer, or reject the use, and set the event or date that will prompt the next review.
Use the same criteria and evidence standard when comparing vendors. A completed questionnaire or favorable certification can support the record, but it does not replace use-case analysis, contract review, or a reasoned decision about remaining risk.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
