Almost every organisation using AI in 2026 is using at least some third-party AI: cloud provider APIs, foundation model services, embedded AI in SaaS products, or AI-powered analytics tools from specialist vendors. The EU AI Act and emerging UK guidance make clear that buying AI rather than building it does not eliminate your compliance obligations—it redistributes them between you (as deployer) and your vendor (as provider), and requires you to actively manage the risks you inherit.

This guide provides a practical five-step due diligence framework for assessing AI risk in third-party vendors, including a questionnaire template you can send to vendors and the contract clauses that actually provide protection.

Why Third-Party AI Risk Matters: EU AI Act Article 28

Article 28 of the EU AI Act assigns specific obligations to deployers—organisations that use a high-risk AI system under their own authority. Critically, these obligations apply even when the AI system was developed by a third-party provider. Deployers cannot simply rely on the provider's EU declaration of conformity and consider themselves done.

Under Article 26 and 28, as a deployer you must:

  • Use the system only in accordance with the provider's instructions for use.
  • Assign human oversight to appropriately competent persons.
  • Monitor the system's operation in your specific deployment context.
  • Inform the provider and relevant market surveillance authority of any serious incidents or malfunctions.
  • Suspend use where you identify a risk not adequately addressed by the provider's risk management.
  • Conduct a DPIA where the system processes personal data under GDPR.
  • Inform and consult workers' representatives when AI is used in employment contexts.

The key implication: your compliance programme cannot simply delegate AI risk management to your vendors. You need enough information about how their systems work to make an informed deployment decision, monitor operation effectively, and respond when things go wrong.

Step 1: Inventory All AI in Your Stack

Before you can assess vendor AI risk, you need a complete inventory of every AI system your organisation uses or is exposed to. This is consistently underestimated in scope. Sources of third-party AI to include:

  • Direct AI API integrations: OpenAI, Anthropic, Google Vertex AI, AWS Bedrock, Azure OpenAI—any API call to a foundation model or AI service.
  • Embedded AI in SaaS products: HR platforms with AI-powered candidate screening, CRM tools with AI lead scoring, customer support platforms with AI triage, financial tools with AI anomaly detection. Many SaaS products now have AI features that are on by default without being prominently disclosed.
  • AI from specialist vendors: Purpose-built AI tools for credit scoring, fraud detection, document processing, identity verification, medical imaging, or any other domain-specific application.
  • AI in infrastructure tooling: Code review AI, security monitoring AI, IT operations AI. These are often overlooked because they are procured by technical teams rather than business units.
  • AI in data and analytics platforms: Business intelligence tools with AI-generated insights, automated reporting tools, forecasting systems.

Produce a register with: vendor name, product/feature name, what AI capability it uses, which business function uses it, what data it processes, and what decisions it informs or makes. This register is the input to all subsequent steps.

Step 2: Classify Each Vendor AI System

Apply the EU AI Act classification decision tree to each item in your inventory. The key question for each system: does it fall within an Annex III category AND substantially influence decisions affecting persons?

For vendor AI systems, the classification analysis should focus on how you use the system, not just how the vendor markets it. A vendor may market their product as a "HR analytics tool" (which sounds neutral), but if you use it to shortlist job applicants, it is almost certainly high-risk under Annex III category 4 regardless of the vendor's classification.

Document your classification for each vendor system. Your classification may differ from the vendor's own classification—that is acceptable and sometimes expected (vendors may classify conservatively for commercial reasons, or may not know how you intend to use their system).

Prioritise the highest-risk systems for steps 3–5. For minimal-risk vendor AI (content generation tools, search, etc.), a lighter-touch review is proportionate.

Step 3: Send the Due Diligence Questionnaire

For any vendor AI system classified as high-risk (or borderline), send a formal due diligence questionnaire before signing or renewing a contract. Below is a 12-question template covering the key areas.

AI Vendor Due Diligence Questionnaire Template

Send to: [Vendor legal/compliance contact]. Reference: [Your organisation name] due diligence review for [Product name], [Date].

  1. Provide the current model card or equivalent technical documentation for the AI system, including: intended purpose, training data description, evaluation metrics on representative test sets, known limitations, and bias testing results.
  2. Has the AI system been classified under the EU AI Act? If so, what risk tier? If classified as high-risk, has the conformity assessment been completed and is an EU declaration of conformity available?
  3. What is the training data composition? Please describe data sources, collection methodology, geographic and demographic coverage, and any known gaps or biases.
  4. What bias testing has been conducted? Provide results disaggregated by protected characteristics relevant to the system's use case (gender, age, ethnicity as applicable).
  5. How does the system handle data inputs that fall outside its training distribution? What is the expected behaviour on edge cases or adversarial inputs?
  6. What human oversight mechanisms are designed into the system? Specifically: can operators override or pause the system's outputs? Is there a confidence score or uncertainty estimate provided alongside predictions?
  7. What personal data does the system process, and under what legal basis? Is a Data Processing Agreement (DPA) in place or available?
  8. Describe the model update and versioning process. How are customers notified of model updates that may affect system behaviour? What is the minimum advance notice period for material changes?
  9. What monitoring does the vendor conduct on the model in production? What drift or performance degradation has been observed since the system's launch, and how was it addressed?
  10. Describe any significant incidents (material errors, harmful outputs, data breaches, regulatory actions) involving this AI system in the past 24 months and the corrective measures taken.
  11. What sub-processors or third-party AI providers does the system depend on? Are any foundation models (e.g. from OpenAI, Anthropic, Google) used in the system's pipeline?
  12. What audit rights does the customer have with respect to the AI system's documentation, testing records, and incident history?

Model Card Red Flags

When reviewing vendor-provided model cards or technical documentation, the following are red flags that warrant deeper investigation or renegotiation:

  • Vague accuracy claims without test set description: "99% accurate" with no description of the dataset, metric, or evaluation conditions.
  • No disaggregated performance data: Aggregate accuracy figures only, with no subgroup analysis by relevant demographics.
  • No training data description: "Proprietary data" with no further detail on geographic coverage, time period, or known limitations.
  • Missing bias testing section: A model card that simply states "the system is designed to be fair" without any testing evidence.
  • No known limitations section: All AI systems have limitations; a model card that claims none is either incomplete or misleading.
  • No incident history disclosure: Vendors that refuse to disclose any incident history create an information asymmetry that makes informed deployment decisions impossible.
  • Outdated documentation: Model card dated more than 18 months ago for a production system, with no version history indicating it has been maintained.

Step 4: Contractual Controls

Due diligence questionnaire responses are only as useful as the contractual obligations that back them up. When procuring or renewing vendor AI contracts, include the following provisions:

Essential Clauses

  • Data Processing Agreement (DPA): Required under GDPR/UK GDPR where personal data is processed. The DPA must specify the subject matter, duration, nature and purpose of processing, type of personal data, and categories of data subjects. For AI systems, also specify whether personal data is used for model training or improvement, and the basis for that use.
  • Model change notification: Vendor must provide minimum [30/60/90] days written notice of any material change to the AI system's model, training data, or functionality that could affect its performance or compliance status. "Material change" should be defined to include model retraining, significant architecture changes, changes to training data composition, and changes to output format or scoring methodology.
  • Sub-processor list: Vendor must maintain and disclose a complete list of sub-processors involved in the AI system's operation, including any foundation model providers. Changes to sub-processors must be notified [30] days in advance.
  • Incident notification: Vendor must notify customer within [24/48/72] hours of becoming aware of any serious incident involving the AI system, including: significant accuracy degradation, harmful outputs, data breach, or regulatory investigation. Notification must include a description of the incident, affected customers, and initial corrective measures.
  • Right to audit: Customer has the right to request documentation of the AI system's technical file, bias testing results, and incident history. Vendor must respond to documentation requests within [10] business days. For high-risk systems, consider including a right to conduct or commission an independent technical audit.
  • Data deletion: On contract termination, vendor must delete all customer data (including any data used for fine-tuning or model improvement) within [30] days and provide written confirmation of deletion.
  • EU AI Act compliance warranty: Where the vendor system is deployed in the EU, vendor warrants that the system complies with applicable EU AI Act obligations for providers, including maintenance of the technical file and EU declaration of conformity for high-risk systems.

Step 5: Ongoing Monitoring

Due diligence is not a one-time event. Third-party AI risk requires ongoing monitoring because the risk profile of a vendor system can change: the vendor may update the model, change sub-processors, experience an incident, or come under regulatory investigation. Your ongoing monitoring programme should include:

  • Annual reassessment: Re-run the due diligence questionnaire or a shortened version on an annual cadence. Check whether the system's risk classification has changed (new use cases, new features, regulatory changes).
  • Model change tracking: Maintain a log of vendor model change notifications. Each notification should trigger a review: does the change affect the system's risk classification? Does it affect performance characteristics documented in the instructions for use?
  • Incident alert monitoring: Subscribe to the vendor's status page and security bulletins. Track any public incident reports, regulatory actions, or news coverage relating to the vendor's AI system.
  • Performance monitoring in your context: Where feasible, monitor the vendor system's outputs in your specific deployment context. You are in a better position than the vendor to detect performance degradation for your specific use case and user population.
  • Contract renewal review: At every contract renewal, review the AI risk assessment and update the contractual controls based on any changes in your use case, the regulatory environment, or the vendor's risk profile.

Tooling Options

  • Holistic AI: Has a dedicated vendor risk module that structures the questionnaire process and tracks vendor responses against a standardised control framework. Suitable for organisations with 10+ vendor AI systems to manage.
  • Credo AI: Supports third-party AI system records, allowing you to create a system record for each vendor AI system and track evidence of the vendor's compliance claims. Less structured for the questionnaire process than Holistic AI's vendor module.
  • Manual spreadsheet: For organisations with fewer than 10 vendor AI systems, a well-structured spreadsheet (inventory tab, questionnaire response tab, risk rating tab, contract controls tab) is sufficient and avoids platform procurement overhead.
  • GRC platform (OneTrust, ServiceNow): If you already use a GRC platform for supplier risk management, the AI vendor due diligence process can be integrated into your existing supplier risk workflow rather than running as a separate process.