How to manage vendor and third-party AI risk

Most of the AI an organisation runs was built by someone else. Foundation models come from a handful of providers, AI features arrive inside software you already pay for, and even in-house systems call third-party models underneath. For most organisations that makes vendor risk a large share of AI risk, and it is the part most often left to a generic procurement questionnaire that asks nothing about models.

Why vendor AI risk is different

Traditional third-party risk focuses on security, resilience and financial stability. Those still matter for an AI vendor. Four things are different.

The product changes under you. A vendor can replace the model behind a product without changing its name, its interface or its price. Output that was tested last quarter may come from a different model today.

Your data can become their asset. Unless the contract says otherwise, inputs may be retained, reviewed by people or used to train future models.

AI arrives without a procurement event. A vendor switches on an AI feature in a product you bought years ago. No new contract, no review, nothing added to the register.

Accountability does not transfer. Using a vendor’s model does not move responsibility for what it does to your customers. The EU AI Act sets out responsibilities along the value chain. Deployers, the organisations using high-risk systems, must use them according to the provider’s instructions, assign competent human oversight, monitor operation and keep logs (Article 26). A deployer that puts its name on a high-risk system, substantially modifies it or changes its purpose so that it becomes high-risk is treated as a provider (Article 25(1)). Where a provider of a high-risk system relies on a third party for models, tools or components, the two must agree in writing the information and access the provider needs (Article 25(4)).

Frameworks outside the EU say the same thing in their own terms. The NIST AI RMF expects policies and procedures that address AI risks from third-party entities (GOVERN 6.1) and contingency processes for failures in third-party systems (GOVERN 6.2). ISO/IEC 42001 includes controls on third-party and customer relationships in Annex A.10.

Step 1: Find every vendor that supplies AI

Build the vendor list from four sources.

• Products that are AI. Chat assistants, coding assistants, transcription, AI-native SaaS.
• AI inside existing products. Copilots and assistants in the CRM, office suite, help desk, HR system and analytics tools. Check release notes and admin consoles, and run discovery.
• Model providers behind your own systems. The providers your in-house systems call, directly or through a cloud platform.
• Service providers. Consultancies and integrators that build or run AI for you.

Cross-check against the AI register. Every company the register names as the provider behind a system should have a vendor record, and every vendor record that supplies AI should map to at least one system in the register.

Step 2: Tier vendors by what they touch

Not every vendor needs the same scrutiny. Tier on three factors.

• Data. Does it receive personal, confidential or special-category information?
• Decisions. Does its output shape decisions about customers, staff or the public?
• Dependence. How hard would it be to replace, and what stops if it fails?

A transcription tool used for internal meetings and a model that scores loan applications are both AI vendors. They do not need the same depth of review.

Step 3: Ask the due-diligence questions

Ask these in writing and keep the answers. The first six drive most of the risk.

1. Training. Do you use our inputs, outputs or files to train or improve any model? Can that be switched off contractually, not only in a setting?
2. Retention. How long are inputs and outputs kept, where, and who at your company can see them?
3. Location. In which countries are our data processed and stored, including for abuse monitoring?
4. Sub-processors. Which third parties process our data, including the model providers you use? How do you notify us of changes?
5. Model changes. Which models does the product use? How and how far in advance do you tell us when a model is changed, updated or retired? Can we stay on a fixed version?
6. Incidents. How quickly will you notify us of a security incident, a data leak or a model failure affecting our use?
7. Evaluation. How do you test accuracy, bias and robustness, and can we see the results for our use case?
8. Security testing. Do you red-team the product, deliberately attacking it to find weaknesses, including prompt injection and data being extracted? Will you share a summary?
9. Transparency. Can you provide a model card, a standard summary of what the model does, how it was tested and where it falls short, or equivalent documentation, and the information we need to explain decisions to affected people?
10. Regulatory role. Where the EU AI Act or similar laws apply, do you consider yourself the provider, and what documentation and instructions for use will you supply?
11. Human oversight. What controls does the product give us to review, override or stop AI output and actions?
12. Logging. What logs can we access, for how long, and in what format?
13. Exit. On termination, how are our data returned and deleted, and how do we get confirmation?

Many organisations hold these as a standing AI vendor due-diligence checklist that sits beside the general security questionnaire.

Step 4: Put the answers into the contract

An answer in a questionnaire is a statement of current practice. A contract term is a commitment. Turn the answers that matter into terms.

• No training on customer data, without a separate opt-in.
• Defined retention and deletion periods for inputs, outputs and logs.
• Processing locations, and notice before they change.
• A sub-processor list with notice and a right to object.
• Advance notice of model changes and retirements, with a minimum period.
• Incident notification within a defined number of hours.
• Cooperation with your assessments, audits and regulatory inquiries, including the information a deployer needs under laws such as the EU AI Act.
• Data return and certified deletion on exit.

Where the vendor processes personal data on your behalf, privacy law usually sets minimum contract terms already. In the EU and UK, Article 28 of the GDPR lists what a contract between the organisation responsible for the data and the one processing it must contain. Make sure the AI-specific terms sit alongside those, not instead of them.

Step 5: Register and assess the product

Add the vendor’s product to the AI register as its own system. Record the vendor, the model it runs on, the data it receives, the decisions it shapes and a named internal owner. Then run a risk assessment as you would for a system built in house. The vendor’s own documentation is input to the assessment, not a substitute for it. A vendor can tell you how its model performs in general. Only you can assess how it performs in your setting, at your volume, for your customers.

Use controls on live traffic to hold the vendor to what you approved. A list of approved models at the AI gateway stops a product quietly switching to a provider or model you did not approve, and guardrails can redact the data the contract says should never reach it.

Step 6: Watch for change

Vendor AI risk is not settled at signature. Track the following.

• Model changes and retirements. Providers publish retirement schedules and notices about their models. Each one that affects a model you depend on should reach the system owner and get a recorded response, whether that is accepting it, replacing the model or noting that it does not apply.
• Term and policy changes. Changes to privacy policies, acceptable use terms or data processing terms.
• Spend. Contracted spend against what the vendor bills and what your traffic suggests, which also reveals unapproved use.
• Incidents and performance. Outages, incidents and drift in output quality, which the drift guide covers.

A material change is a trigger to rerun the assessment, not a note for the annual review.

Step 7: Review and exit cleanly

Set the review interval by tier, at least annually for high-tier vendors. Each review rechecks the due-diligence answers, the contract, the incidents and the registered systems that depend on the vendor. Plan exit before you need it. Know which systems depend on the vendor, how you would replace it and how you will confirm your data was deleted.

Where Aicura fits

Step 1’s cross-check is built in. At Pro, Aicura keeps a vendor record for each company you buy AI from, with what it supplies, its status, where its due diligence stands, a relationship owner, a review date and its contracts, one in force at a time. Beside the vendor list, a Not registered table names every company the AI Register shows as a provider behind a system that has no vendor record yet, so the list you work down comes from the register rather than from memory. The AI Vendor Due Diligence Checklist template drafts the questions in step 3 for you to adapt.

For step 6, each system in the register names the models it runs on. When a provider retires or changes one, the provider’s notice reaches every system that uses it, and the owner records a response there. Spend for each system is shown three ways, contracted, billed and observed from traffic, and lists of approved models at the gateway keep traffic to the providers and models you approved. Decisions about which vendors to use remain yours.

A note on this page

This guide is general information on managing vendor AI risk. It is not legal advice and it does not replace your organisation’s procurement, privacy or legal review. For how the laws mentioned apply to your contracts, take your own professional advice.