Vendor and Third-Party AI Risk Management
Deliberate Academy Editorial Team
Reviewed for accuracy and professional relevance
You're 8 lessons in — don't lose your progress.
Sign up free to save where you are and earn a verified certificate when you pass.
- Explain why deploying a third-party AI system does not transfer or eliminate an organization's own regulatory obligations as a deployer
- Design a vendor AI due diligence process covering data handling, model change notification, and relevant certifications
- Apply a risk-tiering approach to vendor AI relationships so due diligence depth is proportionate to the risk the vendor relationship actually carries
- Identify silent model version changes as a specific, recurring failure mode in third-party AI risk, and design a monitoring control to catch it
Most AI systems in enterprise use were not built in-house. They arrive embedded in a vendor's software, delivered through an API to a foundation model provider, or bundled into an HR, marketing, or customer service platform an organization already licenses. This creates a persistent and dangerous misconception: that because the AI capability came from a vendor, the vendor carries the compliance risk. It does not — or, more precisely, it does not carry all of it, and the portion your organization retains as a deployer is often exactly the portion regulators, auditors, and affected individuals will ask your organization to answer for.
Provider and Deployer: Shared but Unequal Responsibility
Under the EU AI Act's structure, the organization that builds and places an AI system on the market — the provider — carries obligations related to the system itself: for a high-risk system, building the technical file, conducting the conformity assessment, and ensuring the system meets accuracy, robustness, and data governance requirements before release. The organization that puts that system into operational use — the deployer — carries a separate, related set of obligations: using the system in accordance with its stated instructions, ensuring meaningful human oversight in its actual operating context, monitoring the system's performance in that context, and maintaining its own records of how the system was used and reviewed. A vendor contract can allocate commercial liability between the parties. It cannot reassign your organization's own deployer obligations to the vendor — those attach to whoever is actually putting the system into use, regardless of what the contract says about who pays if something goes wrong.
Do not accept "our vendor is responsible for AI compliance" as a complete answer from a business unit onboarding a new AI-powered tool. It is frequently wrong, and even where a vendor genuinely does carry significant provider-side obligations, your organization almost always retains deployer-side obligations — human oversight in your specific operational context, monitoring for your specific population, and your own documentation of how the tool is actually used — that a vendor contract cannot discharge on your behalf.
A Silent Model Update and an Undetected Adverse Impact Spike — Consumer Products Company
Context
A consumer products company used a widely adopted third-party AI recruitment platform to rank incoming applications for retail management roles, processing roughly 6,000 applications per quarter. The company's vendor contract did not include a clause requiring advance notification of material model updates. The vendor updated the underlying scoring model mid-quarter as part of a routine platform release, a change the vendor's release notes described only as a general 'ranking quality improvement' with no detail on what had changed in the model's behavior.
Action
The company's quarterly internal bias monitoring process — which compared the demographic composition of AI-shortlisted candidates against the applicant pool — flagged a statistically significant shift in shortlist composition partway through the quarter, coinciding with the undisclosed model update. The AI Governance Lead escalated to the vendor, who confirmed the update after being pressed, and separately escalated internally to pause reliance on the tool's automated shortlist for two weeks while the company's own legal and data science teams assessed whether the new model version introduced a disparate impact concern. No contractual notification obligation had existed, so the discovery relied entirely on the company's own internal monitoring rather than any vendor disclosure.
Outcome
The internal assessment found the shift was within the company's defined risk tolerance and did not represent a legally actionable disparate impact, but the AI Governance Lead's post-incident review concluded that discovering a material model change purely through downstream monitoring, rather than through vendor notification, was a governance gap the company could not accept as a standing practice. The next vendor contract renewal added a mandatory model-change notification clause with a defined advance notice period, and the company extended its quarterly bias monitoring to a monthly cadence specifically for AI-powered vendor tools without a notification clause already in place.
A company's legal team reviews a new AI vendor's contract and confirms it includes a strong indemnification clause stating the vendor is liable for any regulatory penalty arising from the AI tool's operation. The AI Governance Lead is asked whether this clause means the company's own EU AI Act deployer obligations — such as human oversight and monitoring — can be treated as satisfied by the vendor's indemnification. What is the correct answer?
Select one answer.
Building a Vendor AI Due Diligence Process
A structured vendor AI due diligence process should establish, before onboarding and at defined intervals afterward: what data the tool processes and whether that data is used to train or improve the vendor's models beyond your own instance; where data is hosted and processed, and what jurisdictional implications that carries; what relevant certifications the vendor holds — ISO/IEC 27001 for information security, increasingly ISO/IEC 42001 for AI management, and SOC 2 reports where applicable; what the vendor's incident notification commitment is, including timelines; whether the vendor will notify you of material model version changes before they take effect, and what "material" means in the contract; and what audit rights or evidence-sharing commitments the vendor provides — will they supply documentation sufficient for your own technical file and conformity obligations as a deployer, or does obtaining that evidence require separate negotiation.
Model-change notification is the single most commonly missing clause in AI vendor contracts, and the consumer products case study in this lesson shows why it matters: a vendor's routine model update can shift your tool's real-world behavior without any code change on your side and without any visibility unless you either have a notification clause or run your own independent monitoring. If a notification clause is not achievable during contract negotiation — smaller vendors in particular may resist it — compensate by increasing the frequency of your own downstream monitoring for that specific vendor relationship, rather than accepting the blind spot.
Tiering Vendor Relationships by Risk
Not every AI vendor relationship warrants the same due diligence depth. Apply a version of the five-factor rubric from earlier in this course to vendor relationships specifically: what regulatory tier does the deployed use case trigger, what data sensitivity is involved, what decision consequence follows from the tool's output, how reversible is an error, and what population does it affect. A vendor providing an AI tool that screens job candidates or scores credit risk warrants the full due diligence process, contractual model-change notification, and at least annual re-assessment. A vendor providing an AI-powered internal meeting-notes summarization tool, with no bearing on any consequential decision, warrants a lighter-weight review focused primarily on data handling and confidentiality, reviewed less frequently. Tools such as OneTrust and Credo AI, mentioned earlier in this course for internal governance tracking, also offer vendor-risk-specific modules that adapt standard third-party risk questionnaires (in the pattern of the Standardized Information Gathering questionnaire used broadly in security due diligence) to include AI-specific questions — useful for organizations managing dozens or hundreds of AI vendor relationships where a fully manual process does not scale.
Exercise
Your Task
Design a vendor AI due diligence questionnaire with eight to ten questions, organized into three sections: data handling (what data is processed, whether it trains the vendor's models, where it is hosted), model transparency and change management (what documentation the vendor provides, whether material model changes trigger advance notification), and certifications and audit rights (what security or AI management certifications the vendor holds, what audit evidence they will provide). For each question, note what a concerning answer would look like.
Success looks like
- The questionnaire includes at least one question specifically addressing whether the vendor uses your organization's data to train or improve models beyond your own instance
- The model change notification question specifies what "material change" should mean, rather than leaving it undefined
- Each question has a stated concerning-answer criterion, making the questionnaire usable by someone other than its author
Watch out for
- Writing only data-handling questions and omitting model-change notification, which the case study in this lesson identifies as the most commonly missing and most consequential gap
- Accepting "we take security seriously" or equivalent vague vendor marketing language as a passing answer to any question
- Applying the same ten-question depth to every vendor regardless of risk tier — pair this questionnaire with the tiering approach in this lesson so low-risk vendor relationships are not over-scrutinized at the expense of high-risk ones
Hint
For the model-change notification question, ask specifically what advance notice period the vendor commits to and whether that commitment is written into the contract or only described informally in a sales conversation — the difference matters enormously if a dispute ever arises.
A compliance team is deciding how much due diligence depth to apply to two new AI vendor relationships: one provides an AI tool that generates draft social media captions for the marketing team, and the other provides an AI tool that scores mortgage applicants for creditworthiness. What does this lesson recommend?
Select one answer.
- A vendor contract can allocate commercial liability, but it cannot transfer your organization's deployer-specific regulatory obligations — human oversight, contextual monitoring, and your own documentation remain yours to fulfill regardless of what the contract says about who pays if something goes wrong.
- Provider and deployer obligations under the EU AI Act are distinct and complementary — know which obligations the vendor genuinely carries as the system's provider, and which remain with your organization as the deployer.
- A structured due diligence process should cover data handling, model transparency and change notification, and certifications and audit rights — with model-change notification the most commonly missing and most consequential clause.
- Tier vendor relationships by the same risk factors used elsewhere in this course — regulatory tier, data sensitivity, decision consequence, reversibility, and population affected — so due diligence depth is proportionate rather than uniformly applied.
- A vendor's silent model update can materially change a tool's real-world behavior without any visibility on your side — compensate with contractual notification requirements where possible, and independent downstream monitoring where they are not.