Your AI Vendor's Vendors: The Fourth-Party Problem Nobody Contracted For
Your AI provider fine-tunes on someone else's model, hosts on someone else's cloud and labels data through someone else's workforce. Your risk assessment covered none of them.
Third-party risk management is mature: you assess your vendor, sign the DPA, file the report. But AI vendors are unusually deep stacks. The SaaS assistant you assessed sits on a foundation model from another company, hosted on a hyperscaler, fine-tuned with data from a broker, labelled by a subcontracted workforce, moderated by yet another API. Your contract covers one link. Your exposure covers the chain.
Where fourth parties hide in AI stacks
- Foundation models behind your vendor's product, with their own training-data provenance questions.
- Data brokers and labelling workforces, whose handling of your fine-tuning data you never see.
- Open-source model hubs, where a poisoned checkpoint propagates into every product built on it.
- Sub-processors of sub-processors, hosting and moderation layers that appear in no questionnaire.
- Evaluation and red-team providers, who receive your most sensitive prompts as test data.
Why AI makes this worse than classic SaaS
In classic SaaS, a fourth party mostly threatens availability and data confidentiality. In AI stacks, a fourth party can alter behaviour: a poisoned fine-tune, a compromised model update or a manipulated evaluation changes what the system *does*, not just where the data sits. Behavioural risk does not show up in a SOC 2 report.
What regulators are starting to ask
Under the EU AI Act's GPAI provisions and NIS2's supply-chain requirements, the direction is clear: deployers and providers are expected to know their chain, not just their counterparty. 'Our vendor handles that' is ceasing to be an acceptable answer in an audit.
Practical steps
1. Ask for the stack, not the badge
Request the model provider, hosting chain, data sources for fine-tuning and the sub-processor list of sub-processors. Refusal is itself a finding.
2. Contract for flow-down
Your security requirements should bind the vendor's critical suppliers. If the vendor cannot flow terms down, cap what data the service may touch.
3. Test behaviour, not just paperwork
Periodic output evaluations and canary prompts detect behavioural drift that no questionnaire will ever reveal.
4. Plan the exit per layer
Know which layer of the stack you could swap — model, host, vendor — and how fast. Concentration you cannot escape is risk you cannot manage.
You do not have one AI vendor. You have a stack of them, and you are only looking at the top.
