Is AI vendor risk different from traditional vendor risk?

Yes, in three ways. The data flow is more complex because the prompt is the data, and the prompt is constructed by the application from multiple sources. The supervisory obligation is heavier because regulators now expect ongoing visibility into AI behavior, not just procurement attestations. The evidence requirements are sharper because per-decision audit records are mandated by regulation. Traditional vendor risk artefacts (SOC 2, ISO 27001) are necessary but no longer sufficient.

Does the deployer's liability transfer to the vendor when the vendor's AI causes harm?

No. Regulatory regimes consistently place the supervisory obligation on the deployer. Fannie Mae LL-2026-04 is explicit: lenders are liable for AI mistakes by subcontractors and vendors. The deployer can pursue the vendor under contract for indemnity, but the regulatory exposure stays with the deployer. The contractual indemnity is downstream of the regulatory penalty. The deployer is the insurer of last resort.

How does this intersect with DORA for financial services?

DORA's ICT third-party risk requirements were already heavy before the AI Act. The AI Act sits on top. Financial services deployers have to map AI vendor risk against the DORA register of contractual arrangements, the DORA exit-strategy obligations, and the DORA incident-reporting timelines. The runtime evidence that satisfies AI Act Article 12 is the same evidence that supports DORA's ICT-related incident reporting.

What is the right escalation path for a vendor that does not produce audit records?

The escalation path runs through procurement, legal, and the risk function. The vendor is either onboarded into the deployer's supervisory framework with documented residual risk, or the deployment is constrained to use cases that do not require the records, or the contract is renegotiated to require the records, or the deployer moves to an alternative vendor. The choice depends on the use case's regulatory exposure and the vendor's strategic importance.

How often should the questionnaire be re-issued?

Annually as a baseline. Event-driven re-issue when the vendor changes underlying model providers, when the vendor is acquired or restructured, when the vendor experiences a significant incident, or when the regulatory landscape shifts materially. The cadence is the same as the deployer's risk register review cadence for the corresponding rows

AI Vendor Risk Management: The Diligence Questions That Actually Bind Under Audit

AI vendor risk management sits at the intersection of traditional third-party risk and the new AI-specific obligations the deployer carries under EU AI Act Article 26, Fannie Mae LL-2026-04, DORA, and sector-specific regimes. The deployer is liable for AI mistakes by subcontractors and vendors. SOC 2 attestation on the vendor is due diligence at the procurement boundary. It does not satisfy the operational obligation to supervise how that vendor's AI tools handle the deployer's data on an ongoing basis.

I want to walk through the questionnaire that actually binds under audit, the runtime evidence behind each answer, and the supervisory obligation that procurement attestations leave open.

The questionnaire that holds up

A diligence questionnaire is only useful if the answers map to evidence the vendor can produce on demand. The question set below has been calibrated against the four regulatory regimes most enterprises currently care about.

Model provenance and configuration

| Question | Evidence the vendor has to produce | |---|---| | Which LLMs power the AI features in your product, by feature? | A feature-to-model mapping with version IDs | | Are the models you use Code-of-Practice signatories under the EU AI Act? | The provider's signature status and the transparency form | | Do you fine-tune the models on customer data? | The fine-tuning policy and any per-customer carve-outs | | What is your model upgrade policy and notification timeline? | The version change log and the customer notification process |

Data handling

| Question | Evidence the vendor has to produce | |---|---| | What customer data is sent to the underlying model? | The data flow diagram from the deployer's tenant to the model API | | Is customer prompt content used to train future models? | The contractual position and any opt-out mechanism | | Do you support customer-managed encryption keys? | The CMEK configuration and the audit log | | What is the retention policy on prompts and responses at the vendor's tier? | The retention schedule, broken down by data type |

Identity and authorization

| Question | Evidence the vendor has to produce | |---|---| | How is the natural person behind each AI request identified to the model? | The identity context propagation diagram | | Do you support per-user policy on AI features? | The policy configuration options and the documentation | | Can the deployer enforce its own policy at a layer the vendor's product respects? | The integration pattern, if any |

Audit and evidence

| Question | Evidence the vendor has to produce | |---|---| | Do you produce per-decision audit records for AI requests? | A sample audit record and the schema | | Can the deployer retrieve the records on demand? | The API or export mechanism | | Are the records tamper-evident? | The signing scheme or equivalent integrity mechanism | | What is the retention policy on the audit records? | The retention schedule, mapped to applicable regulation |

Incident response

| Question | Evidence the vendor has to produce | |---|---| | What is your AI incident notification timeline? | The contractual notification clock | | What is your process for prompt injection or model abuse incidents? | The runbook and the latest tabletop exercise summary | | How do you communicate model behavior changes that affect customers? | The change communication policy |

Regulatory posture

| Question | Evidence the vendor has to produce | |---|---| | Which regulatory regimes do you certify against and at what level? | Current attestations: SOC 2 Type II, ISO 27001, ISO 42001, HIPAA, BAA, FedRAMP | | Do you have an EU AI Act conformity assessment in progress or completed? | The conformity assessment summary and the timeline | | For high-risk use cases, do you provide Annex IV technical documentation? | The documentation sample |

What the answers actually tell you

Diligence answers come in three flavours.

A clean answer

The vendor describes the mechanism, names the artefact, and offers to produce it under NDA. The risk team verifies on review. The vendor is mature enough on the question to support production deployment.

A hand-wave

The vendor describes intentions, points to a roadmap entry, or references the underlying provider's stance. The risk team flags as a gap. The vendor either commits to a date or the deployment proceeds with a documented residual risk.

A confused answer

The vendor does not understand the question, or the answer contradicts the question. The risk team escalates. Confused answers are the strongest signal of vendor immaturity on AI risk and the most consequential diligence finding.

The risk team's job is to surface the flavour and report it accurately, not to soften it.

The supervisory obligation procurement does not discharge

Procurement attestations are point-in-time. The deployer's obligation under EU AI Act Article 26 and equivalent regimes is continuous. Three properties of the ongoing supervision matter.

Operational monitoring of vendor AI usage on deployer data

The deployer has to know what the vendor's AI did with the deployer's data this week, this quarter, this year. The vendor's monthly summary report is the starting point. The deployer's runtime visibility into the vendor's calls (when the deployer can attain it) is the supplement.

Contractual right to audit on demand

The vendor's contract grants the deployer the right to request evidence on demand: audit records, model documentation, incident summaries. The right has to be invoked when material questions arise. A contract right that the deployer never invokes does not function as a supervisory control.

Renegotiation triggers

The contract identifies the triggers that require renegotiation: model provider change, ownership change, regulatory regime change, significant incident. The deployer reviews each trigger as it occurs.

The vendor inventory

The deployer maintains an inventory of vendors whose products use AI on the deployer's data. The inventory has to be the basis for the AI risk register and the impact assessment work. Three fields matter most.

| Field | What it captures | |---|---| | Vendor name | The contracting entity | | AI feature description | The specific feature and how it uses the deployer's data | | Regulatory exposure | The applicable regimes and the supervisory obligation level |

Inventory completeness is the lowest cost, highest value diligence step. A vendor that does not appear in the inventory is invisible to the supervisory process by definition.

DeepInspect

This is the gap DeepInspect closes for the deployer's first-party AI workloads. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users or agents and any LLM. Every request is evaluated against per-route, per-role policy with identity context the application supplies. Every decision produces a signed audit record.

For the deployer's own AI deployments, the proxy is the supervisory infrastructure the deployer would otherwise have to ask vendors to provide. The per-decision audit record stream is the evidence the regulator expects. The runtime policy is the boundary the regulator inspects.

For third-party AI vendors, the deployer's contract has to require equivalent evidence from the vendor. The proxy's record schema is a reasonable starting point: a vendor whose audit record covers identity, policy version, decision, and timestamp is producing the same primitives the deployer's own infrastructure produces. A vendor whose audit record is application-controlled and aggregated is producing less. The contract has to specify which.

If you are running enterprise AI in 2026 and your vendor diligence stops at the SOC 2 attestation, the supervisory gap is wide. Book a demo today.