AI Vendor Risk Assessment Guide

Selecting an AI vendor is not only a build-vs-buy product decision. Prompts, documents, and logs may leave your boundary; model behaviour can change without a classic “software release”; and exit is harder when your product UX is glued to one API.

This guide helps technology and risk professionals structure vendor due diligence for foundation model APIs, hosted copilots, AI SaaS features, and agent platforms. It is educational and practical — not a procurement policy or legal opinion.

Vendor governance

Start with ownership and scope.

• Who inside your organisation owns the relationship and the use case?
• Which environments will send data (dev, staging, production)?
• What assurance packs exist (SOC reports, ISO certificates, security whitepapers)? Treat them as inputs, not automatic approval.
• How will renewals and material changes re-trigger review?

Data use

Be explicit about what the vendor receives.

• Categories of personal and confidential data in prompts, files, and metadata
• Whether support or success teams can view customer content
• Purpose limitation: service delivery vs analytics vs model improvement
• Alignment with your internal AI risk assessment

Training data questions

Ask — and verify in the product console — questions such as:

• May customer prompts or outputs be used to train or improve models?
• Are there enterprise tiers with training opt-out or zero data retention?
• Do fine-tuning or evaluation features create separate data stores?
• How long are abuse/safety review samples kept?

Do not rely on marketing pages alone; capture the setting screenshots or contract clause.

Retention

Map the lifecycle of AI artefacts.

• Prompt and completion logs
• Embeddings and vector indexes
• Tool/agent traces
• Support tickets that paste model output
• Deletion and export SLAs

Subprocessors

AI vendors often chain cloud hosts, content filters, telemetry, and specialised model providers.

• Obtain the current subprocessor list
• Understand notification rights when the list changes
• Note any subprocessors that change residency or sector constraints for you

Hosting

Clarify where processing happens.

• Regions and residency options
• Shared multi-tenant vs dedicated capacity
• Whether customer-managed keys or private networking are available (and needed)

Security

Review baseline controls with an AI lens.

• Encryption in transit/at rest
• Vulnerability and penetration testing cadence (as disclosed)
• Isolation between customers
• Incident notification windows and contacts
• How the vendor handles prompt-injection and abuse at platform level (and what remains your responsibility)

Access controls

Cover both sides of the fence.

• Vendor staff access to customer content (who, when, logging)
• Your admins: SSO/SAML, MFA, SCIM, role design
• API key hygiene, key rotation, and secret scanning expectations
• See also the IAM risk checklist

Model transparency

You cannot manage what you cannot name.

• Which models are available, default, and deprecated
• How version changes are communicated
• Documented limitations for your domain
• Safety filters, moderation endpoints, and what they do not catch

Service resilience

Assume the API will be slow, limited, or down.

• Status page and incident history (qualitative, not a guarantee)
• Rate limits and fair-use policies
• Your degraded mode and user messaging
• Themes in the DORA educational guide for ICT dependency thinking

Exit strategy

Design for replaceability before you are locked in.

• Export of conversation history, embeddings, and configs
• Prompt/eval portability
• Contractual termination assistance
• Time and cost to re-point integrations

Contract considerations

Work with legal/procurement as appropriate. Typical discussion points include:

• Data processing terms for prompts and outputs
• Training and retention commitments
• Confidentiality and publicity restrictions
• Liability caps and carve-outs for data incidents
• Audit or assurance rights
• Service levels (and meaningful remedies)

This guide does not draft or approve contracts.

Monitoring

Vendor risk is continuous.

• Usage and spend anomalies
• Security bulletins and model deprecations
• Periodic re-attestation for high-dependency use cases
• User-reported quality or safety issues tied back to the vendor capability

Suggested workflow

1. Complete an internal use-case assessment first.
2. Send a focused questionnaire (use the checklist groups above).
3. Verify critical answers in console settings and contract drafts.
4. Record residual risks and owners.
5. Revisit on renewal, region change, or major model shift.