A privacy officer signs off on a new SaaS vendor after reviewing its data processing agreement. The DPA names one AI subprocessor, the risk gets logged, the contract gets executed. What the DPA doesn’t say is that the vendor’s AI feature actually routes data through two or three additional AI providers further down the chain, none of which made it into the disclosure. This is not a hypothetical. Recent industry research suggests it is closer to the norm.
A review of data protection assessments from thousands of business software providers marketing AI capabilities found that nearly two-thirds failed to disclose subprocessing activity performed by another AI provider. Separately, roughly a third of the AI systems examined self-disclosed that they engage in high-risk processing of sensitive data or power automated decision-making. Put plainly: a large share of the vendor paperwork privacy teams rely on to assess AI risk is incomplete on the exact point that matters most, who else is touching the data.
Why This Gap Exists Now
The disclosure gap traces less to bad faith and more to velocity. Engineering teams are shipping new AI-powered features on a cycle that legal and product security teams can’t match. A DPA drafted six months ago may no longer reflect the actual subprocessing chain a feature relies on today, because the vendor added a new model provider, a new inference layer, or a new orchestration tool in the interim without updating its disclosures. Contracts move on a legal review cycle. AI stacks move on a sprint cycle. The mismatch is where undisclosed subprocessing lives.
This matters because disclosure obligations tied to AI processing are tightening across multiple frameworks at once, including the EU AI Act’s transparency requirements for providers and deployers, and risk assessment obligations under laws like the California Consumer Privacy Act. A vendor’s DPA has traditionally functioned as a reliable proxy for what due diligence a company has already performed. When that proxy is wrong on subprocessing more often than it’s right, every downstream risk assessment built on top of it inherits the error.
Shadow AI Is Shadow IT With a One-to-Many Problem
Shadow AI is best understood as an evolution of the older, more familiar problem of shadow IT, where employees or business units adopt tools without going through procurement or security review. What makes shadow AI harder to contain is structural. A traditional unsanctioned SaaS tool typically creates a one-to-one relationship between the organization and that vendor. An AI feature embedded inside an approved vendor’s product can quietly introduce a one-to-many relationship, where a single integration pulls in multiple AI subprocessors that never appear on anyone’s vendor list.
Detecting this is not a network-scanning problem the way shadow IT often was. Traffic monitoring can flag an employee using an unapproved cloud storage tool. It cannot reliably tell a security team that a sanctioned vendor’s “smart search” feature is quietly calling a third-party large language model behind the scenes. AI’s technical footprint is too varied, and too often invisible at the network layer, for legacy discovery methods to catch it.
Where the Regulatory Exposure Lands
Under the GDPR, a technology vendor performing this kind of processing is likely to qualify as a controller in its own right, not merely a processor acting on instructions. That reclassification carries its own consequences. A vendor’s failure to disclose its full subprocessor list can expose that vendor to enforcement independent of its client, provided the client company can demonstrate it conducted reasonable due diligence at onboarding. Undisclosed subprocessing also complicates a company’s ability to fully honor consumer rights requests, since a deletion or access request can only be executed completely if every party actually holding the data is known.
A Practical Framework for Closing the Gap
Several patterns are emerging among organizations that are managing this risk successfully, rather than discovering it after the fact:
- Build a system inventory that goes two layers deep. Track not just the vendors under direct contract, but the subprocessors those vendors rely on for AI functionality specifically. A vendor list without a subprocessor list is an incomplete map.
- Stop treating the DPA as a static source of truth. Given how quickly AI features ship, a DPA reviewed at signing may be stale within a quarter. Build a cadence for re-verifying subprocessor disclosures, not just a one-time intake check.
- Ask vendors to explicitly attest to subprocessing, in writing, as a standing requirement. A general disclosure clause is not the same as a vendor affirmatively confirming which specific AI systems and providers are involved in a given feature.
- Deploy detection tooling rather than relying on self-report alone. Screening tools designed to surface AI usage that hasn’t been formally disclosed give privacy and security teams an independent check against what vendors say in their paperwork.
- Set access controls and acceptable-use policies for employee-side AI adoption. Shadow AI isn’t only a vendor problem. Employees experimenting with public AI tools inside company workflows create the same undisclosed-processing risk from the inside.
- Give experimentation a contained path instead of banning it outright. Organizations that succeed at this tend to offer employees a secure, sanctioned environment to test AI tools and report back what’s useful, rather than pushing curiosity underground where it becomes untraceable.
- Assign clear ownership. AI governance frequently stalls because no single team owns it end to end. Without a designated owner, vendor assessments, employee policy, and subprocessor tracking end up handled inconsistently across legal, security, and product.
The Bottom Line for Privacy Teams
The core issue isn’t that vendors are uniquely dishonest about AI. It’s that the paperwork-based verification model privacy teams have relied on for years was built for a slower-moving technology stack. AI subprocessing chains change faster than contract cycles, and a due diligence process anchored entirely to what a DPA says, rather than what an independent inventory confirms, is now missing the majority of the picture in a meaningful share of cases. Closing that gap requires treating subprocessor disclosure as an ongoing verification process, not a box checked once at vendor intake.
Frequently Asked Questions
What is shadow AI? Shadow AI refers to the use of AI tools or AI-powered features within an organization that haven’t been formally reviewed, approved, or disclosed, whether introduced by employees using public AI tools outside sanctioned channels, or by an approved vendor’s product relying on undisclosed AI subprocessors.
Why do so many vendor DPAs fail to disclose AI subprocessors? The pace of AI feature development is outrunning the legal review cycle that produces and updates data processing agreements, and subprocessing chains can run several layers deep, making them harder to track.
Can a vendor’s undisclosed AI subprocessor create liability for my company? It can complicate your risk assessments and consumer rights obligations, particularly deletion and access requests, since those can only be fully satisfied if every party processing the data is known. Vendors themselves also face independent exposure under frameworks like the GDPR when they’re acting as controllers.
How can companies detect undisclosed AI subprocessing? Traditional network monitoring is poorly suited to this task. Organizations are increasingly turning to dedicated AI discovery and screening tools, paired with a standing requirement that vendors affirmatively attest to their subprocessing chains rather than relying on static contract language.
Captain Compliance helps organizations map vendor and subprocessor relationships, monitor AI-driven data flows, and keep DPA disclosures current as vendor tech stacks evolve. Schedule a demo below to see how continuous vendor monitoring closes the gap self-reported paperwork leaves open.