AI vendor due diligence should produce a decision, not merely a completed questionnaire. The review should identify what the organization is buying, which risks matter for the intended use, what evidence supports the vendor’s claims, which controls are required before deployment, and who accepts unresolved risk.
Use the questions below as a starting point and scale the depth of review to the sensitivity, autonomy, business criticality, and consequence of the proposed use.
Business purpose and ownership
- What specific business problem will the service address?
- Who is the accountable business owner?
- Which employees, customers, or other people may be affected?
- What happens if the service is unavailable or produces an incorrect result?
- Is the proposed use consistent with internal AI policy and risk classification?
AI capability and limitations
- Which AI or model capabilities are actually used in the proposed product?
- What evidence supports performance claims relevant to our use case?
- What known limitations, failure modes, or inappropriate uses does the vendor document?
- Can model or configuration changes materially alter behavior?
- How are significant changes communicated to customers?
Data and privacy
- What data will the service receive, generate, store, or log?
- Where is data processed and retained?
- How long is it retained and how is deletion handled?
- Can customer data be used for model training or service improvement?
- Which subprocessors can receive or process relevant data?
- What options exist to restrict unnecessary data collection or retention?
Security and access
- How are administrative users authenticated?
- Can service identities and API permissions be limited to required access?
- How are secrets and credentials stored, rotated, and revoked?
- What security logging and audit information is available to customers?
- How does the vendor manage vulnerabilities and security updates?
- What relevant independent security assessments or assurance evidence can the vendor provide, if any?
Human oversight and control
- Which actions can occur automatically?
- Can consequential actions require human approval?
- How are exceptions, uncertain cases, or validation failures handled?
- Can administrators pause or restrict automated behavior quickly?
- What information will a human reviewer receive when intervention is required?
Incident and resilience planning
- How does the vendor notify customers of relevant security or privacy incidents?
- What support and escalation channels are available during an incident?
- What service availability commitments apply to the purchased offering?
- What dependencies or subprocessors are critical to operation?
- What fallback process will our organization use during an outage?
Legal, contractual, and governance review
- Which contractual terms govern data use, confidentiality, liability, and termination?
- Do our intended uses create sector-specific, geographic, contractual, or other legal obligations requiring specialist review?
- Who owns or may use inputs, outputs, configurations, and related business data?
- What commitments are made about material changes to service terms or subprocessors?
- Which unresolved risks require formal acceptance and by whom?
Exit and portability
- Can required business data and configuration be exported in a usable form?
- How are integrations and credentials revoked at termination?
- What data remains after termination and for how long?
- What would it take to move the workflow to another provider or back to a manual process?
Document the decision
Record the intended use, risk classification, evidence reviewed, conditions of approval, required controls, unresolved issues, accountable owner, reviewers, and review date. A vendor may be acceptable for one low-consequence use and inappropriate for another. Approval should therefore describe the approved use rather than treating the vendor name as a blanket authorization.