Quick answerAI third-party risk is the risk arising from external AI capabilities – model providers, AI-enabled SaaS, AI consultants and AI service providers. It deserves separate treatment from standard vendor risk because AI introduces dimensions that generic questionnaires miss: model provenance, training data lineage, behavioural patterns, hallucination handling and oversight responsibilities.
Why AI deserves separate attention
AI-enabled vendors introduce new questions that standard vendor assessments rarely surface. Where did the underlying model come from? What was it trained on? How does it behave under stress? What guardrails apply? How does the vendor handle confidently-wrong outputs? Who is responsible for oversight – you, the vendor, or both? These are not adjacent topics to standard vendor risk; they are different topics altogether.
Categories of AI third party
Model providers
Foundation-model providers (OpenAI, Anthropic, Google, Meta, Mistral) and specialist model providers. Typically accessed through APIs.
AI-enabled SaaS
Software products with AI features bolted on – CRM with AI summarisation, support tools with AI suggestions, productivity apps with AI assistance. Often the most common category by volume.
AI-native products
Products built around AI as the core capability – copy assistants, code assistants, voice-cloning tools.
AI consultants and services
Consultants delivering AI strategy, implementation, evaluation or governance work.
AI service providers
Outsourced functions delivered with AI – content moderation, transcription, translation, summarisation.
What to assess
- Use case – what does this AI do for your business
- Data exposure – what flows to the vendor, in inference and (if applicable) training
- Model provenance – built in-house, foundation, fine-tuned, licensed
- Training data – sources, consent, sensitive categories
- Model behaviour – accuracy, bias testing, robustness
- Hallucination handling – guardrails, user disclosures, remediation
- Human-oversight model – who reviews AI outputs
- Sub-processors – including the underlying model provider
- Data retention and training opt-outs
- Incident reporting commitments
- Vendor’s own AI governance – do they apply NIST AI RMF, ISO 42001, EU AI Act controls
Where standard vendor risk falls short
Model provenance
Standard questionnaires don’t ask where the underlying model came from. For AI vendors this materially changes the risk picture.
Training data lineage
Was the model trained on data the vendor had the right to use? Was personal data involved? Standard questionnaires don’t go here.
Behavioural testing
Has the AI been tested for bias, accuracy, robustness? Standard vendor reviews assume deterministic software. AI is not deterministic.
Hallucination handling
How does the vendor handle confidently-wrong outputs? Standard questionnaires assume software is correct when it runs.
Sub-processor cascades in AI
AI vendors often have substantial sub-processor cascades – particularly when the vendor wraps a foundation model. A ‘co-pilot for X’ product typically depends on a foundation model from OpenAI, Anthropic, Google or Meta, hosted on AWS, Azure or GCP, with monitoring through one or more observability vendors. Sub-processor traceability for AI vendors is unusually important because each layer introduces its own AI risk profile.
How PrivIQ supports AI third-party risk
PrivIQ AI Governance ships AI vendor assessment templates tailorable by vendor category, AI use case and risk profile. Assessments link back to the AI use-case register and the third-party register. Sub-processor cascades are visible. Periodic reassessment runs against the defined cycle.
- AI third-party risk is distinct from standard vendor risk – model provenance, training data, behaviour and oversight are AI-specific.
- Sub-processor cascades matter unusually much for AI – the foundation model behind the product is itself a third party.
- Standard SOC 2 / ISO 27001 reports are necessary but not sufficient for AI vendors.
- Vendor AI governance (do they apply NIST AI RMF, ISO 42001) is itself a useful signal.
PrivIQ helps organisations and consultants put this into practice — with policies, controls, evidence, tasks, registers and reporting that survive audit.
More on Third-Party Risk.
Are consumer-tier AI tools (free ChatGPT, free Copilot) third parties I need to assess?
They are third parties, but the consumer tier usually fails basic due diligence: no DPA, training-on-prompt opt-outs unclear, no enterprise SLAs. The correct response is usually ‘enterprise tier or no use’, enforced through your acceptable-use policy.
Do I need to assess the underlying foundation-model provider?
At least at a high level for tier-1 AI vendors. Most enterprise AI vendors will provide disclosure about their underlying model choice and the model provider’s commitments.
What’s the difference between AI vendor due diligence and AI third-party risk?
Due diligence is the assessment phase. Third-party risk is the ongoing oversight – periodic reassessment, incident monitoring, contract review. Same data, different cycle.
What happens when an AI vendor changes its underlying model?
This is a material change. Most enterprise AI contracts require disclosure; some require advance notice. The decision (continue, renegotiate, exit) should be documented through the same workflow as a standard sub-processor change.
How do I handle AI features in tools I already use?
Treat the AI feature as a separate use case, even though the vendor is the same. Document what the AI feature does, what data it processes, what oversight applies. The existing vendor relationship doesn’t extend automatically to new AI capabilities the vendor adds.