What is third-party AI risk management?

Third-party AI risk management is the practice of identifying, assessing, and continuously supervising the AI that vendors and their subprocessors run on your data. It extends traditional vendor risk management to account for embedded model calls, which often are not disclosed in a standard contract or captured in a point-in-time assessment. The lifecycle covers discovery of where vendors use AI, tiering by the consequence of the vendor's AI decisions, due-diligence assessment, contractual controls over disclosure and log access, ongoing due care, and offboarding. The distinguishing feature is that the risk lives in model calls a normal vendor review never examines.

Does a vendor's SOC 2 report cover their AI risk?

Only partially, and only as a snapshot. A SOC 2 Type II report attests that a vendor operated controls during an audit window. It does not show what the vendor's AI did with your data outside that window, and it rarely covers the specific model calls, data flows, and subprocessors involved in an AI feature. SOC 2 is due diligence at procurement. The ongoing obligation to supervise how a vendor's AI handles your data is due care, which requires continuous evidence rather than an annual report. Regulations increasingly hold the deployer liable for a vendor's AI mistakes, so the gap is a real exposure.

How do you handle AI that a vendor runs without disclosing it?

Start with direct discovery: ask every vendor touching regulated data whether their product sends that data to an AI model, which model and provider, and where the endpoint runs, and require disclosure of new AI features added mid-contract. Pair that with monitoring your own AI egress, since a vendor integration's model calls often appear as traffic before they appear in a questionnaire. Then add contractual clauses for AI-usage disclosure, log access, and subprocessor governance so undisclosed model use becomes a breach of contract and a source of records, rather than an invisible data flow.

What contract terms matter for third-party AI risk?

Three terms that standard vendor agreements usually lack. First, an AI-usage disclosure clause covering current and future features, so the vendor must tell you when they route your data to a model. Second, a log-access clause giving you the right to request per-decision records of what the vendor's AI did with your data, which you need to satisfy your own regulatory disclosure duties. Third, subprocessor governance over the model providers the vendor depends on, since your data's actual destination is frequently a model provider the vendor contracts with. These terms turn undisclosed AI use into an enforceable obligation.

Third-Party AI Risk Management: The Embedded-Model Problem

The hardest third-party AI risk to manage is the AI a vendor runs without telling you. A customer-service platform summarizes tickets with an LLM. A quality-control vendor scores your files with a model. A pricing engine sends your data to an inference endpoint you never reviewed. In each case your data left your environment for a model, and your third-party risk program never saw the call because the contract said "SaaS platform," not "AI."

I want to walk through a third-party AI risk lifecycle that accounts for embedded and subprocessor AI, and to be specific about the obligation a vendor's SOC 2 report does not discharge.

Discovery is the part everyone skips

Traditional third-party risk starts with a known vendor list. AI risk starts one level down, with the model calls those vendors make under the hood. A vendor you assessed two years ago as a document-storage tool may have shipped an AI summarization feature last quarter. The feature sends your documents to a model, and nothing in your original assessment covered it.

Discovery means asking every vendor that touches regulated data a direct question: does your product send our data to an AI model, which model, which provider, and where does the endpoint run. It also means watching your own AI egress, because a vendor's embedded model call often shows up as traffic from the vendor's integration before it shows up in a questionnaire. I covered the visibility side in the shadow AI breakdown.

Tiering by consequence, not by spend

Most vendor programs tier by contract value. AI risk tiers by what the model decides. A low-spend vendor whose model influences a hiring, credit, or clinical decision carries more risk than a high-spend vendor whose AI drafts internal marketing copy. The tiering question is the same consequential-decision test that regulators use: does the vendor's AI materially influence an outcome for a person.

High-tier AI vendors earn the deeper assessment: what data reaches the model, whether it is used for training, what the retention is, which subprocessors are in the path, and whether the vendor can produce per-decision records on request.

Due diligence is a snapshot; due care is the job

A vendor's SOC 2 Type II report is due diligence at the procurement boundary. It tells you the vendor had controls during an audit window. It does not tell you what the vendor's AI did with your data last Tuesday. That ongoing supervision is due care, and it is a different obligation. I argued this at length in due diligence is not due care.

The distinction has regulatory teeth. Fannie Mae's Lender Letter LL-2026-04 holds lenders liable for AI mistakes made by their subcontractors and vendors. When The Register asked the major AI application vendors how much liability they would accept for their agents' decisions, Microsoft and SAP declined to comment and four others did not respond. The liability lands on the deployer. Vendor attestations move where the risk sits contractually without removing it.

Contracts have to reach the model call

Third-party AI contracts need three clauses that standard vendor agreements omit. First, disclosure of AI usage, including new features added mid-term. Second, log access: the right to request per-decision records of what the vendor's AI did with your data. Third, subprocessor governance covering the model providers the vendor routes to, because your data's real destination is often a model provider two hops away.

Without the log-access clause, you inherit the disclosure obligation under regimes like the EU AI Act and Colorado's reenacted AI law with no way to satisfy it. The regulator asks what the AI did with a specific person's data, and "our vendor will not give us those logs" is not an answer a regulator accepts.

Concentration risk

When five of your vendors all route to the same model provider, you have a concentration you did not choose. An outage, a policy change, or a breach at that provider reaches your environment through five doors at once. DORA's third-party regime treats this directly for financial entities, and I covered it in the DORA third-party AI risk analysis. Mapping which vendors depend on which model providers is the only way to see the concentration before it becomes an incident.

DeepInspect

This is where DeepInspect supports the due-care side of third-party AI risk. DeepInspect sits at the AI request boundary as a stateless proxy between your environment and any LLM endpoint. For the AI traffic that flows through it, including calls your own integrations make to vendor-adjacent models, it records every request with the identity behind it, the data classification, the policy in effect, and the outcome.

That record is the continuous-supervision evidence that due care requires and that a point-in-time SOC 2 report cannot provide. It also gives you a map of which identities and integrations send data to which model endpoints, which is the raw material for concentration analysis. DeepInspect governs the AI traffic you originate; the contractual log-access clause covers the traffic that originates inside a vendor. Together they close the record gap.

If you are managing third-party AI risk and your program stops at the vendor's SOC 2 report, let's talk today.