Twenty percent of breached organizations in 2025 traced the incident back to shadow AI, unsanctioned AI tools operating outside security oversight, and those breaches cost an average of $670,000 more than the rest, according to IBM’s Cost of a Data Breach report. Most of that exposure did not come from AI your engineers built. It came from AI embedded in the vendors you already pay.
Third-party AI risk management is the discipline built to catch that gap, and it looks different from the vendor security review your procurement team has run for the last decade. A vendor’s AI model can change behavior after a routine update, inherit a foundation model you never vetted, or push your organization into a regulatory role you did not sign up for.
This piece walks through where vendor AI risk actually lives, how ISO/IEC 42001, the EU AI Act, and NIST AI RMF 1.0 each define your obligations, and how to build a vendor AI program that survives an audit instead of just a sales pitch.
Why Vendor AI Breaks Traditional Third-Party Risk Management
A standard vendor security questionnaire assumes the product you are buying today behaves the same way in six months. AI vendors break that assumption by design. A model update, a new fine-tuning pass, or a swapped foundation model can change how a system scores a loan applicant or screens a resume, without a single line of your contract changing.
As many as 78% of organizations now use third-party AI tools, and more than half rely on them exclusively rather than building anything in-house [VERIFY]. Traditional TPRM programs were built around deterministic software: fixed inputs, fixed logic, auditable outputs. Generative and predictive AI systems violate all three. The same prompt can produce different outputs on different days. The reasoning behind a specific decision often cannot be reconstructed after the fact, which is a real problem when a regulator or a rejected applicant asks why.
There is a second layer most procurement teams miss entirely: the vendor’s own supply chain. A SaaS product that added an AI assistant last quarter may be routing your data through a foundation model provider you have never heard of and never contracted with. Your vendor risk assessment covered the software company. It did not cover the model underneath it.
Where Vendor AI Risk Actually Lives
Vendor AI risk clusters into four areas that a conventional security review does not test for.
- Fourth-party model exposure. Many AI vendors embed a foundation model or third-party API inside their product. Your data reaches a company you never evaluated, under terms you never negotiated.
- Opacity and explainability gaps. Large language models and deep learning systems frequently operate as black boxes. When a vendor cannot explain why its system produced a specific output, you inherit that accountability gap in any regulated decision.
- Hallucination and reliability risk. Generative systems produce confident, fluent, and sometimes false outputs. In legal, financial, or clinical workflows, that is a direct liability exposure, not a quality nuisance.
- Data flow drift. A vendor’s AI feature can change what data it touches after you have already signed. What started as a support chatbot can quietly begin ingesting customer records for model improvement unless the contract says otherwise.
None of these risks show up on a standard SOC 2 review, which is precisely why AI-specific vendor assessment has become its own discipline rather than an addendum to existing TPRM workflows.
Your Compliance Exposure Does Not Transfer to the Vendor
The single most common misunderstanding in AI procurement is the belief that buying a compliant-sounding product makes you compliant. It does not. Under the EU AI Act, Article 25 sets out conditions under which a distributor, importer, or deployer is automatically reclassified as a provider, and inherits the full provider obligation set under Article 16. Put your name or logo on a vendor’s high-risk AI system, substantially modify it, or repurpose a general-purpose model into a high-risk use case, and the reclassification happens by operation of law. No registration step. No warning.
If you remain a deployer rather than a provider, Article 26 still binds you directly to the vendor’s system. You must use it according to the provider’s instructions, assign competent human oversight, monitor its operation, retain the logs it generates for at least six months, and report serious incidents to the provider and market surveillance authorities without undue delay. Buying the AI from someone else does not move these obligations off your desk.
US state law follows a similar logic. Colorado’s SB 26-189 requires deployers using ADMT to give consumers notice and disclosure regardless of whether the system was built in-house or licensed from a vendor, and NYC Local Law 144 places the bias audit obligation for automated employment decision tools on the employer using the tool, not solely on the company that built it. A vendor’s marketing claim of “compliant AI” is not a substitute for your own documentation showing you assessed, monitored, and can account for how that system is used.
Cross-Framework Mapping: ISO 42001, EU AI Act, and NIST AI RMF for Vendor AI Risk
Most vendor AI governance content treats these three frameworks separately, which leaves compliance teams re-reading three different documents to answer one question: what does my vendor program actually need to do at each stage of the relationship? The table below maps the same vendor lifecycle decision point against all three frameworks simultaneously, clause by clause. This kind of simultaneous mapping is the gap most published guidance on vendor AI risk leaves unfilled.
Vendor AI lifecycle mapped across ISO/IEC 42001, EU AI Act, and NIST AI RMF 1.0
| Lifecycle Stage | ISO/IEC 42001 | EU AI Act | NIST AI RMF 1.0 |
|---|---|---|---|
| Pre-contract due diligence | Annex A.10.3, Suppliers [VERIFY sub-clause numbering] | Article 25(4), written agreement with third-party supplier specifying compliance information | GOVERN 6.1, policies addressing third-party AI risk |
| Allocating responsibility | Annex A.10.2, Allocating responsibilities | Article 25(1)-(3), provider reclassification triggers | GOVERN 6.1, MAP 4.1 |
| Onboarding and system inventory | Clause 8.1, Operational planning and control | Article 49, EU database registration (public deployers) | MAP 1.1, MAP 4 |
| Ongoing monitoring | Annex A.10.3, ongoing supplier monitoring | Article 26(5), deployer monitoring of operation | MANAGE 3.1, MANAGE 4.1 |
| Incident and failure response | Clause 10.1, Nonconformity and corrective action | Article 26(5)-(6), serious incident reporting | GOVERN 6.2, contingency processes |
| Audit evidence and documentation | Clause 7.5, Documented information | Article 26(6), log retention, minimum six months | MEASURE 2.x, documentation of AI system performance |
Building an AI Vendor Risk Assessment That Catches What Standard Questionnaires Miss
A security questionnaire asks whether a vendor encrypts data at rest. An AI vendor questionnaire needs to ask a different category of question, one that most procurement teams have never had to write before.
- Model provenance. Which foundation model or models power this system, and does the vendor commit to disclosing changes before they take effect?
- Training data sourcing. What data trained the model, does it include your organization’s or your customers’ data, and under what terms can that data be reused?
- Fourth-party disclosure. Which subprocessors or model providers sit behind this product, and what happens to your data when it reaches them?
- Explainability commitments. Can the vendor produce a rationale for a specific output on request, and how quickly?
- Bias testing evidence. Has the system been tested for disparate impact in the specific use case you are deploying it for, not just in general?
- Update and drift notification. What is the vendor’s process and timeline for notifying you before a material model change goes live?
- Regulatory role mapping. Does the vendor’s own documentation state whether it considers itself a provider under the EU AI Act, and does that match your own Article 25 analysis?
Weight these questions by the AI system’s role in the decision it supports. A vendor tool that drafts internal marketing copy carries a different risk profile than a vendor tool that scores creditworthiness or screens job applicants, and your assessment depth should scale accordingly rather than applying one questionnaire to every AI purchase.
Contract Clauses Every AI Vendor Agreement Needs
Most AI vendor contracts still read like software licensing agreements from a decade before generative AI existed. Five clauses close the gap.
- Model change notification. A defined notice period, ideally 30 to 60 days, before any material change to the underlying model, training data, or subprocessor list.
- Audit and information rights. The right to request documentation supporting the vendor’s own conformity assessment, bias testing results, and Article 25(4) compliance information.
- Data use restrictions. Explicit limits on whether your data or your customers’ data can be used to train or fine-tune the vendor’s models, with no default opt-in.
- Incident notification timelines. A specific window, matched to your own regulatory reporting deadlines, for the vendor to notify you of a security incident, model failure, or discovered bias issue.
- Termination and data portability. A clear exit path, including data return or deletion timelines, if the vendor’s AI practices fall out of alignment with your risk tolerance or a framework you certify against.
None of these clauses require a specialized AI lawyer to draft. They require someone on the compliance or legal team to recognize that a standard master services agreement was never built to cover a system that can change its own behavior between contract renewals.
Continuous Monitoring: Vendor AI Doesn’t Stay the Same After You Sign
A vendor questionnaire captures a single moment in time. The vendor that passed assessment in January can look different in July after a model swap, a new subprocessor, or a feature update that expands what data the AI touches. Point-in-time review is not sufficient for a system that evolves on its own schedule.
A working monitoring cadence ties review frequency to risk tier rather than applying a single annual cycle to every AI vendor. High-risk systems, those touching employment, credit, healthcare, or other consequential decisions, warrant quarterly reassessment and a standing channel for the vendor to disclose material changes as they happen. Lower-risk systems, such as internal productivity tools, can reasonably sit on an annual cycle with lighter-touch spot checks in between.
Three triggers should force an off-cycle review regardless of the standard schedule: a vendor-disclosed model change, a publicly reported incident involving the vendor or its underlying model provider, and a shift in how your organization uses the tool, such as expanding a drafting assistant into a decision-support role it was not originally assessed for.
Building the Program: A Practical Implementation Path
Most compliance teams do not need a new department to manage this. They need to sequence four steps correctly.
- Inventory every AI system, including the ones you did not buy for AI. Shadow AI research consistently shows that a large share of enterprise AI usage runs through features embedded in existing tools rather than dedicated AI purchases. Start with an inventory sweep across procurement, IT asset management, and a short survey to department heads asking what AI features they have turned on.
- Tier every system by decision impact. Map each system against EU AI Act risk categories and your own internal materiality scale. A system influencing employment, credit, healthcare, or safety decisions sits in your highest tier regardless of contract size.
- Apply the assessment depth to match the tier. Run the full AI-specific vendor questionnaire on high-tier systems. Apply a lighter version to lower-tier tools, but do not skip the exercise entirely, since low-tier tools are exactly where shadow AI tends to originate.
- Build the monitoring cadence into your GRC calendar, not a separate spreadsheet. Vendor AI reviews should live inside the same governance rhythm as your broader AI management system, not as a side project that quietly stops getting updated after the first audit passes.
Many of the AI systems that create third-party risk are never formally procured as standalone AI tools. They often appear as new AI features inside existing software, creating a shadow AI problem that organizations need to identify before those systems can be assessed and governed. Learn more about finding and governing unapproved AI use across your organization.
Govern365.ai’s AI model registry builds this inventory automatically, mapping each system, including vendor-supplied ones, to its applicable ISO 42001 controls and EU AI Act risk category as soon as it is added, rather than waiting for the next annual review cycle to catch it.
Frequently Asked Questions
What is third-party AI risk management?
It is the process of identifying, assessing, and continuously monitoring the risks introduced when your organization uses AI tools, models, or platforms built by an external vendor. It builds on traditional vendor risk management but adds AI-specific concerns: model provenance, training data, explainability, and the regulatory role you may inherit under frameworks like the EU AI Act.
Do I need to assess vendor AI systems differently than regular software vendors?
Yes. Standard software vendor reviews assume deterministic, unchanging behavior. AI systems can shift after a model update without any change to your contract, so the assessment needs to cover model provenance, training data sourcing, and a defined process for the vendor to disclose material changes.
What is fourth-party AI risk?
Fourth-party risk arises when your AI vendor embeds a foundation model or API from a separate company you never evaluated or contracted with directly. Your data can reach that fourth party even though your due diligence stopped at the vendor you actually signed with.
Can I contractually transfer EU AI Act compliance obligations to my AI vendor?
Only in limited circumstances. Article 25(1)(a) allows contractual reallocation of provider obligations specifically in a rebranding scenario, but that carve-out does not apply where you substantially modify the system or repurpose it into a high-risk use case. Deployer obligations under Article 26 bind you directly regardless of what the vendor contract says.
What should an AI vendor questionnaire include that a standard security questionnaire doesn’t?
Add questions on model provenance, training data sourcing, subprocessor and fourth-party model disclosure, explainability commitments, use-case-specific bias testing evidence, and the vendor’s own EU AI Act role classification. A SOC 2 review does not test for any of these.
How often should I reassess an AI vendor?
Match frequency to risk tier. High-risk systems touching employment, credit, or healthcare decisions warrant quarterly review plus a standing disclosure channel. Lower-risk tools can sit on an annual cycle, but any vendor-disclosed model change or reported incident should trigger an off-cycle review immediately.
What happens if my AI vendor is reclassified as a provider under the EU AI Act?
Reclassification under Article 25 works the other direction: it is you, the distributor, importer, or deployer, who can be reclassified as a provider if you rebrand, substantially modify, or repurpose the vendor’s system. When that happens, you inherit the full Article 16 provider obligation set, and the original vendor is no longer considered the provider for that system.
Does ISO 42001 certification cover my vendors automatically?
No. ISO/IEC 42001 Annex A.10 requires you to manage third-party and customer relationships within your own AI management system, including supplier assessment and ongoing monitoring, but your vendors are not automatically certified by extension. You still need documented evidence that you assessed and monitor each supplier.
Getting Started
Vendor AI risk is not a subset of your existing TPRM program that a checkbox can absorb. It is a distinct discipline because the system you are governing can change behavior on a schedule you do not control, and because the frameworks that matter, ISO 42001, the EU AI Act, and NIST AI RMF, all place real accountability on your organization regardless of who built the model.
Start with the inventory. Most organizations discover AI systems they never formally procured, sitting inside tools they have used for years. Once that inventory is tiered and mapped against the frameworks above, the questionnaire, contract clauses, and monitoring cadence follow naturally.
Start your 14-day free trial of Govern365.ai and map your vendor AI inventory against ISO 42001, the EU AI Act, and NIST AI RMF from day one.
