How should organisations assess third-party AI risk in vendor contracts?

What should a third-party AI contract actually prove?

Vendor contracts for AI should do more than restate generic procurement language. They need to make the supplier accountable for the AI system’s scope, operating boundaries, and evidence of control. For organisations, the point is to move from “we bought a service” to “we understand the system we are relying on”, including where it can change, what data it may touch, and which obligations remain with the buyer.

That matters because AI risk is often introduced through vague service descriptions, weak change notification, and unclear responsibility for model updates or tool access. A contract can define a baseline, but it cannot verify behaviour on its own. That is why teams should look for evidence obligations, audit rights, escalation paths, and explicit statements about data handling and human oversight. For AI-related supplier reviews, the NIST AI Risk Management Framework is useful because it centres measurable governance rather than trust in assurances alone. In practice, many organisations discover the gap only after a vendor has already changed a model, connector, or workflow without a review cycle.

The practical test is whether the contract helps the organisation answer three questions: what the AI is allowed to do, what evidence the vendor must produce, and what happens when the system changes in a way that affects risk.

How should organisations structure the AI-specific review?

The review should separate general supplier risk from AI-specific risk. A normal third-party assessment still needs to cover security, privacy, business continuity, subcontractors, and service levels. The AI layer then asks whether the vendor can explain the system’s lineage, training and tuning sources, update process, and decision boundaries. If the supplier cannot describe those points clearly, the organisation does not have enough assurance to treat the AI as a stable service.

Practitioners should treat autonomy and access as first-class contract issues. If an AI feature can call tools, trigger actions, or read enterprise content, the contract needs to state the approval model, logging expectations, and revocation process. That is especially important where AI is embedded in workflows that touch customer data, internal knowledge bases, or privileged business actions. Where the question extends into non-human identity, the contract should also address which machine credentials, tokens, or delegated accesses are in scope for the vendor-managed system.

• Define the exact AI functionality covered, including human-in-the-loop assumptions.
• Require notice for material model, prompt, tool, policy, or hosting changes.
• Ask for evidence of testing, monitoring, and incident escalation, not just policy statements.
• Confirm who owns accountability for outputs, logs, retention, and rollback.

Organisations should also check whether the vendor’s assurance artifacts are current, because stale attestations often hide operational drift. The relevant benchmark is whether the supplier can show how changes are controlled, not whether the contract contains a generic right to audit. For a broader governance lens on system-level accountability, ISO/IEC 42001:2023 AI Management System Standard is helpful where the supplier operates AI as a managed process rather than a one-off product. This guidance breaks down when the vendor will not disclose enough about model behaviour, update triggers, or downstream access paths to support a meaningful review.

Where do third-party AI reviews usually go wrong?

Tighter AI oversight often increases procurement and legal effort, requiring organisations to balance faster deal-making against a more reliable control posture. The most common mistake is treating the contract as evidence of control instead of evidence of commitment. A signed clause about “responsible AI” does not tell you whether the system is monitored, whether changes are tested, or whether the supplier can actually enforce the promised boundaries.

Another weak point is overreliance on generic security schedules that do not cover AI-specific failure modes. Teams often ask for standard confidentiality and breach language, but miss the implications of model updates, data re-use, retraining, tool chaining, and third-party sub-processors. Where the vendor can repurpose customer prompts or outputs for training, the risk profile changes materially. Where the supplier can alter the model without notice, the buyer may be unable to assess whether yesterday’s approval still holds today. This is a governance issue as much as a technical one, and industry practice is not fully settled on how much disclosure is reasonable in every case, so the contract should be explicit about the minimum evidence needed for continued use.

Practitioner judgement matters most when the AI service is embedded in a critical workflow. In those cases, the organisation should assume that a purely paper-based review is incomplete and should require operational proof before allowing production reliance. In practice, many security teams encounter the real problem only after a vendor has already changed behaviour in production, rather than through intentional change control.

Practitioner takeaway: The strongest contracts do not promise that AI is “safe”; they create a repeatable basis for deciding when the supplier has changed enough to require re-approval.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on static questionnaires to assess third-party script and AI risk?
• How should organisations govern third-party access in a vendor risk policy?
• What do organisations get wrong about third-party AI risk reviews?
• How should organisations assess third-party risk when vendors touch sensitive workflows?