Is this the same as a security questionnaire?

No. The security questionnaire collects answers. The risk assessment evaluates those answers against the buyer's tolerance, use case and data classes. The two are usually run side by side.

Why include dependency risk for AI vendors?

AI vendors often sit between the buyer and a model provider. Whether the buyer owns the provider relationship (BYOK) or the vendor pools keys materially changes lock-in, billing and retention terms — and therefore risk.

How does Privian map to this framework?

Privian is one narrow hop — mask, route, rehydrate, retain nothing raw — with BYOK for the provider relationship. The Trust Center and Blueprint document Privian's posture in each of the six risk dimensions.

AI vendor risk assessment

Q: What is an AI vendor risk assessment?

A structured evaluation of the risks an AI vendor introduces — operational, privacy, compliance, dependency, data-exposure and governance — used to inform a procurement decision and the conditions attached to it.

By Privian TeamUpdated June 15, 202611 min read

AI vendor risk has six dimensions: operational, privacy, compliance, dependency, data exposure and governance.

AI vendor risk is not a single number. It is a small set of dimensions, each with its own failure modes and its own compensating controls. The framework below is the one Privian uses internally and recommends to buyers; it is deliberately vendor-neutral.

Risk is not removed by a single control; it is reduced by stacking compensating controls across the six dimensions.

Layered AI controls— No single layer is sufficient. Each compensates for the others' gaps.

Framework

Six dimensions of AI vendor risk

01
Operational risk
Availability, capacity, change control, runbook quality, on-call posture. What happens when the vendor has an incident, and how the buyer is notified.
02
Privacy risk
What the vendor sees and stores, in raw or processed form. Whether prompt data is retained, whether it is used for model training, and whether responses are post-processed.
03
Compliance risk
Fit with the buyer's regulatory obligations: GDPR, sectoral rules, data-residency commitments. Whether the contractual posture (DPA, SCCs) is in place.
04
Vendor dependency risk
Lock-in to a single vendor, model or routing layer. Whether the buyer can exit cleanly, and whether the vendor sits between the buyer and the provider in a way that complicates the provider relationship.
05
Data exposure risk
Cross-tenant, cross-region or cross-customer leakage paths. Whether the request hot path can read or persist data outside its scope, and what the blast radius of a single bug would be.
06
Governance risk
Audit trail, human oversight, model-use policy, sunset criteria. Whether the buyer can govern the feature after the purchase, not just at the purchase.

How to run the assessment

For each dimension, capture the vendor's answer, the implementation reference, and a residual-risk rating against the buyer's tolerance for the specific use case. The output is a one-page summary that a steering committee can act on, not a report nobody reads.

The six dimensions

Operational risk

Availability, capacity, change control, runbook quality, on-call posture. What happens when the vendor has an incident, and how the buyer is notified.

Documented SLOs and incident-response timing
Change-control and rollback story
Status page and post-incident write-ups

Privacy risk

What the vendor sees and stores, in raw or processed form. Whether prompt data is retained, whether it is used for model training, and whether responses are post-processed.

Raw prompt and response retention policy
Use of customer data for model training (explicit opt-out)
Masking and minimisation before egress

Compliance risk

Fit with the buyer's regulatory obligations: GDPR, sectoral rules, data-residency commitments. Whether the contractual posture (DPA, SCCs) is in place.

Active DPA and current subprocessor list
Data-residency story per provider
Alignment with sectoral rules (HIPAA, PCI, AI Act)

Vendor dependency risk

Lock-in to a single vendor, model or routing layer. Whether the buyer can exit cleanly, and whether the vendor sits between the buyer and the provider in a way that complicates the provider relationship.

BYOK vs pooled provider credentials
Provider portability — change provider without rewrite
Exit plan: data export, contract termination, key revocation

Data exposure risk

Cross-tenant, cross-region or cross-customer leakage paths. Whether the request hot path can read or persist data outside its scope, and what the blast radius of a single bug would be.

Per-request scoping of any in-memory state
Sanitisation of observability payloads
Encryption posture for credentials and at-rest data

Governance risk

Audit trail, human oversight, model-use policy, sunset criteria. Whether the buyer can govern the feature after the purchase, not just at the purchase.

Audit log of model use and admin actions
Policy hooks for allowed models per data class
Documented sunset criteria for the feature

Where Privian sits

Privian's posture in each dimension is documented on the Trust Center and condensed into the Privian Blueprint. The security resource and the architecture resource cover the implementation detail behind each answer.

Written under our editorial principles: implementation-grounded, honest about limitations, educational first.