The Next Third-Party Risk May Be a Fourth-Party AI Model You Never Contracted With

Most third-party risk programs are built to answer a specific question well: is this vendor, as a company, trustworthy enough to work with. That question still matters. But a growing share of the exposure enterprises now carry doesn't live at the vendor level at all — it lives one layer beneath it, in the specific AI model the vendor's product actually calls to process customer data, screen resumes, draft communications, or make a recommendation. That model is frequently not the one named in the contract, and in a majority of cases, it isn't named anywhere in the vendor's formal disclosures at all.

This is a distinct and, in practical terms, newer problem than the fourth-party risk most TPRM programs already track — the cloud hosts, material subcontractors, and infrastructure providers a vendor depends on operationally. Crest.Digital has covered that broader dependency chain separately. The AI model sitting inside a vendor's product is a sharper version of the same blind spot: it changes more often than a hosting provider, it touches the most sensitive data a vendor processes, and — unlike a subcontractor named in an SOC 2 report — it is frequently absent from the documentation an enterprise relies on to evaluate the relationship in the first place.

Independent research published in 2026 puts a number on how wide that gap actually is. A privacy industry analysis of 2,400 enterprise software vendors that prominently advertise AI capabilities found that the majority do not disclose a third-party AI subprocessor in their data processing agreement — even when product documentation, API connections, and engineering environments show a specific foundation model is actively in use. For a risk or procurement leader, the implication is uncomfortable: the contract you signed to establish what a vendor may do with your data may no longer describe which AI is actually doing it.

The AI Model Your Vendor Didn't Mention

Consider a scenario that's become common rather than exceptional: an enterprise adopts an AI-enabled recruiting tool. The vendor's data processing agreement names a specific foundation model provider as the tool's AI backbone. The buyer, doing its job properly, performs security due diligence on that named provider — reviews its enterprise agreements, checks its safety commitments, satisfies itself the relationship is defensible. What the DPA doesn't disclose is that the same recruiting tool also routes certain features through two additional models entirely, quietly layered in as the vendor expanded functionality. Those undisclosed models are the ones actually processing thousands of resumes, home addresses, and — depending on the role — financial or background-check data, and influencing automated hiring decisions the buyer never separately reviewed.

The pattern behind this gap isn't primarily deliberate concealment. Software vendors are racing to ship AI features into existing products faster than their legal and privacy teams can update contractual paperwork to match, and a product built on one model at launch can route to a different or additional model months later as the vendor optimizes for cost, latency, or capability — without that shift ever triggering a formal contract amendment. The result is the same regardless of intent: the enterprise's system of record for AI risk, the DPA, quietly drifts out of sync with what the product is actually doing.

This matters more, not less, as AI features become table stakes rather than a differentiator. When nearly every SaaS category — recruiting, customer support, finance automation, procurement, legal tech — ships some form of AI-assisted functionality, the number of vendor relationships carrying an undisclosed model dependency scales with a company's entire vendor portfolio, not just the handful of tools explicitly onboarded as "AI vendors."

Why the Contract Alone Can No Longer Be Trusted

TPRM programs have long treated the signed contract and its accompanying data processing agreement as the authoritative record of what a vendor is permitted to do with enterprise data. That assumption held reasonably well when the risk being documented — where data is hosted, which subcontractors touch it, what security controls apply — changed infrequently and predictably. AI model dependencies break that assumption on two fronts at once: they change faster than a typical contract renewal cycle, and a meaningful share were never accurately documented to begin with.

Nearly a third of AI-enabled systems reviewed in the same 2026 research disclose at least one additional high-risk activity alongside AI usage — processing sensitive personal information, or contributing to automated decision-making — and researchers note the true figure is almost certainly higher, since these numbers reflect only what vendors chose to formally disclose. Among AI systems with self-reported risk factors, close to half process personal data and roughly one in five have the potential to power automated decisions, the exact category of processing that draws the most direct regulatory scrutiny.

The regulatory backdrop is tightening in parallel. Risk assessment requirements taking effect under several U.S. state privacy frameworks now specifically require documenting significant AI-related processing activities, with some jurisdictions moving toward executive attestation of those assessments under penalty of perjury. The FTC has separately signaled active enforcement interest in AI-assisted automated decision-making that touches employment, credit, or housing outcomes. Satisfying either obligation is close to impossible when the enterprise itself doesn't reliably know which model is processing its data — which turns an AI subprocessor disclosure gap from a vendor-side paperwork problem into a buyer-side compliance exposure.

Mapping the Real Chain: Vendor, Subprocessor, Model, and Data

A flat vendor register — one row per contracted company — was never designed to capture this kind of dependency, and it shows. The chain that actually determines exposure runs: the contracted vendor, the subprocessor disclosed or undisclosed in the DPA, the specific AI model that subprocessor operates or resells, the cloud infrastructure that model runs on, and the data provider or data category feeding it. A vendor risk program that stops at the first link in that chain — is this company reputable — is answering only a fraction of the question a board, regulator, or customer will eventually ask.

This is where autonomous AI agents add a further layer of urgency rather than being a separate concern. As vendors increasingly wire agentic capabilities into their own products — an agent that autonomously calls external tools, APIs, or models to complete a task — the number of hops between the enterprise's data and an unreviewed AI model can grow without a corresponding increase in human oversight at any single point in the chain. An agent making its own tool-and-model selection at runtime is, by definition, harder to pin to a single documented dependency than a static integration decided once at build time.

Executive-level anxiety about this is already measurable. Surveys of enterprise leadership have found that a large majority are at least somewhat concerned about their organization's dependency on a specific AI vendor or model, while only a small fraction believe they could switch their primary AI provider without material operational disruption — a concentration risk that compounds the disclosure problem, since an enterprise that doesn't know which model it depends on can't accurately assess how exposed it would be if that model were retired, degraded, or breached. Gartner has separately projected that task-specific AI agents will be embedded in a large share of enterprise applications by the end of 2026, widening this dependency footprint well beyond the tools formally classified as "AI vendors" today.

An 8-Point Framework for Fourth-Party AI Model Intelligence

Closing this gap doesn't require rebuilding a vendor risk program from scratch. It requires extending the same evidentiary discipline TPRM programs already apply to vendor claims — verify, don't just accept — specifically to the AI model layer.

The eighth point is the one most programs skip, and the one that matters most in practice. A model dependency verified once at onboarding and never revisited provides a false sense of assurance — the underlying model can already be several versions removed from the one that was actually reviewed.

Building the Program: A Six-Step Playbook

Turning the framework into an operating practice starts narrow — with vendors already known to have shipped AI features — rather than attempting a full re-review of every contract in the vendor portfolio at once.

The last step is where most of the practical value sits. A disclosure gap discovered and escalated during a routine review is an inexpensive fix. The same gap discovered during a breach investigation or a regulator's inquiry — after sensitive data has already reached an unreviewed model for months — is a materially different conversation.

Where Agentic AI Fits — Verification at a Scale Manual Review Can't Match

Manually cross-referencing contractual disclosures against product documentation, API telemetry, and questionnaire responses across an entire vendor portfolio is not a realistic ongoing task for a human team — it's precisely the kind of continuous, evidence-correlation work agentic AI is well matched to, applied specifically to the AI model layer rather than vendor risk in general. ISACA and the NIST AI Risk Management Framework both point in the same direction: continuous, evidence-based verification of AI dependencies, not a point-in-time contract review, is what a defensible program now looks like.

Continuous Discovery of Undisclosed Model Dependencies

An agentic workflow can continuously scan available vendor documentation, questionnaire responses, and public technical references for signals of an AI model dependency that isn't reflected in the vendor's formal disclosures — surfacing the gap on an ongoing basis rather than relying on a single point-in-time review at onboarding to catch it.

AI-Assisted Cross-Referencing at Portfolio Scale

Once a potential gap is identified, an agentic layer can correlate it against the enterprise's own data-sensitivity classifications and prior questionnaire history, prioritizing which disclosure gaps carry the highest exposure — a vendor processing biometric or financial data through an undisclosed model warrants faster escalation than one processing low-sensitivity internal content. This mirrors the same discovery discipline Crest.Digital has applied to shadow AI tools entering the enterprise outside formal review — an undisclosed fourth-party model is, functionally, a shadow dependency hiding inside an already-approved vendor.

Human-in-the-Loop on Risk Acceptance

What the agentic layer doesn't do is decide whether a flagged gap is acceptable or how it should be remediated. That determination — whether to escalate to the vendor, restrict the data the vendor can access, or terminate the relationship — stays with a named risk or procurement owner, informed by the evidence the agent assembled rather than replaced by it. This is the same human-in-the-loop principle Crest.Digital applies across agentic AI for vendor risk operations: automation handles the continuous, correlation-heavy discovery work at a scale no team could sustain manually, while judgment on what to do with each finding stays firmly human.

Enterprises that have already built continuous monitoring into their vendor risk program hold a structural advantage here — the discipline of verifying claims against evidence, rather than accepting a signed contract at face value, is the same one. It simply needs to extend one layer deeper, to the model quietly operating beneath the vendor everyone already assessed.

Frequently Asked Questions