AI Vendor Risk Management: Due Diligence, Contracts and Monitoring

Practical guide · Vendors · Version 1.0 · October 2026

Most organizations buy far more AI than they build, which means a lot of their AI risk walks in through procurement.

It usually goes like this. A team finds a tool that saves them hours, someone runs a pilot, the users love it, and procurement gets involved. The contract gets signed, and only afterward does anyone ask where the data actually goes, which model sits underneath the product, or whether the vendor can swap that model tomorrow without telling you.

AI vendors aren’t just another SaaS vendor. Keep asking the questions you already ask about security, privacy, availability, and financial stability, because they still matter. But AI adds another layer. Is the vendor training its models on your data? Which foundation model provider does it rely on, and who are the subprocessors? What happens to your data once it reaches the model provider? Can the underlying model change without notice, and what does that do to your results? Who is responsible if the system makes a discriminatory recommendation, and what evidence will the vendor give you if a regulator asks how it works? Your standard security questionnaire probably doesn’t answer much of that.

This guide answers one practical question: what should I know before I allow this AI vendor into the organization? It covers the full lifecycle, from intake through exit, and gives you the working tools: an inherent-risk screen, a due-diligence questionnaire, an evidence request list, a risk-rating method, a contract checklist, red flags, approval conditions, reassessment triggers, and an annual review checklist.

The AI vendor lifecycle at a glance

Most vendor programs are reasonably good at the middle. They send the questionnaire, security reviews the SOC report, legal negotiates the contract, procurement gets the signature, and everyone moves on. With AI, the steps after approval matter just as much, because the product you approved in January may not be the product you’re using in October. The vendor may change the underlying model or switch foundation model providers. A new AI feature may be switched on. A subprocessor or a retention term may change. Your own business team may start using the tool for something you never approved. You need controls over the relationship, not just the purchase.

Step 1: Intake and inherent-risk screening

Not every AI vendor deserves the same level of review. A grammar tool cleaning up public marketing copy and an AI platform ranking job applicants are completely different risk conversations. Treat them the same and one of two things happens: either your team drowns in low-risk reviews, or genuinely high-risk systems get pushed through a generic vendor review that never looks deeply enough.

So start with a short inherent-risk screen. The requesting business owner answers these as part of your AI intake process:

1. What will the tool be used for, and who will use it?
2. What data will go into it: public, internal, confidential, personal, sensitive, regulated, or client data?
3. Will its output make or materially influence a decision about a person, such as employment, credit, insurance, healthcare, education, or access to services?
4. Will customers, employees, or the public interact with it directly?
5. Can it take actions in other systems, such as sending messages, changing records, executing transactions, or moving money?
6. Will it connect to internal systems or data stores?
7. Where will it be used, and where are the people it affects?
8. How important is it to the business process?
9. What happens if it’s wrong?
10. What happens if it’s unavailable for a week?

Don’t skip the last two. A system can handle low-sensitivity data and still create significant risk because people rely heavily on what it tells them.

Inherent-risk tiers

I don’t use a mathematical score and pretend it produces an objective answer. Some characteristics push a vendor straight into high-risk treatment: making or materially influencing consequential decisions about people, processing highly sensitive or regulated information, taking autonomous actions with significant consequences, or the potential for serious legal, financial, safety, or individual harm if it fails. For everything else, look at the combination of data sensitivity, affected people, autonomy, external exposure, integrations, business criticality, and how easily you could replace it.

One important point: don’t lower inherent risk because the vendor has good controls. A hiring AI doesn’t become inherently low risk because the vendor has a SOC 2 report. Good controls reduce residual risk, and you assess that later.

Step 2: Understand the vendor and the product

For medium- and high-risk vendors, these are the areas I want to understand, what a good answer looks like, and what makes me dig deeper.

Follow the dependency chain

Don’t stop when the vendor tells you “we use OpenAI,” “we use Anthropic,” or “we run on Azure.” That’s useful, but it isn’t the end of the review. Draw the chain:

Your organization → AI vendor → model provider → cloud and infrastructure → other relevant subprocessors

Then ask who controls each important risk. Who keeps the prompts? Who stores uploaded files and hosts the embeddings? Who applies content filtering? Who can change the underlying model, and who investigates a model-related incident? Whose logs would you need if something went wrong, and which assurance report covers which part of the service?

This matters most when a vendor says “our model provider handles that.” That can be perfectly reasonable, but now you’re relying on an inherited control. Understand what you’re inheriting, what evidence supports it, and which responsibilities still sit with the vendor and with you. You can have three companies in the service chain and still have a control that nobody actually owns.

The AI vendor due-diligence questionnaire

Send this alongside your existing security and privacy questionnaire, not instead of it. For genuinely low-risk vendors, shorten it.

A completed questionnaire is not the review

“No, we don’t train on customer data” is a useful answer, but it isn’t where I stop. For a medium- or high-risk vendor, I want to know where that promise lives. Is it in the contract, the DPA, an enterprise setting, a privacy policy, or a help-center article the vendor can quietly change next month? Then I look at the actual configuration wherever I can. If the contract says customer content won’t be used for training, but the admin console has “use customer content to improve our models” switched on, I have a problem. I do the same for retention, subprocessors, model versions, and logging. Four things should line up and tell the same story:

Questionnaire answer → Supporting evidence → Contractual commitment → Actual configuration

If they don’t, find out why before you approve.

Evidence request list

Questionnaire responses are claims. For medium- and high-risk vendors, ask for the evidence behind the important ones:

• Current SOC 2 Type II or other relevant independent assurance report, with a bridge letter where appropriate
• ISO/IEC 27001 and ISO/IEC 42001 certificates and scope, where applicable
• Current subprocessor list and model-provider information
• Data processing agreement and data-flow documentation
• Product or model documentation, including intended use and known limitations
• Evaluation and accuracy testing relevant to your use
• Bias or fairness testing, where the product affects people
• AI security or red-team testing summary
• Retention schedule and deletion procedure
• Incident response and customer notification procedure
• Model-change and customer notification process
• Business continuity and disaster recovery summary, with the date and results of the latest test
• Applicable regulatory documentation
• Relevant insurance certificates, including cyber and technology errors and omissions where appropriate

And read the assurance reports; don’t just save them to the vendor folder. Confirm the product you’re buying is in scope, check the period covered, read the exceptions, look for relevant subservice organizations, and pay attention to the complementary controls the report expects customers to operate. Those may now be your job.

Test the vendor before you trust the paperwork

For a higher-risk AI product, I don’t want the approval decision to rest entirely on documents. Run a controlled pilot where you can. If the vendor says its RAG system respects source permissions, test it with users at different access levels. If it says sensitive information is filtered, use representative test data and try to make it disclose something. Use the human override workflow if there is one. Check whether its explanations actually mean something for your use case. If the vendor claims a level of accuracy, build a small evaluation set from examples that look like your real environment. If it’s an agent, test what it can actually do with the permissions you plan to give it.

You don’t need the vendor’s model weights for any of this. You’re answering a much more practical question: does this product behave acceptably when we use it the way we intend to? Document the tests, the expected and actual results, and any conditions you attach to approval. For deeper technical procedures, see my AI audit guide.

A simple risk-rating method

The rating should be clear enough that another reviewer, looking at the same evidence, can see how you got there. I use three steps.

1. Determine inherent risk

Start with the use case, data, affected people, autonomy, integrations, business impact, and regulatory exposure, and do it before you give the vendor any credit for its controls. The result is low, medium, or high.

2. Assess control strength

This is based on evidence, not questionnaire answers alone.

3. Determine residual risk

Then decide. Low residual risk: approve through the normal process. Medium: approve with documented conditions and owners. High: escalate to the appropriate governance authority, and depending on the use case, reduce the risk, impose stronger conditions, restrict the use, or don’t approve it. Whatever you decide, record the reasoning. A year from now, someone should be able to answer one simple question: why did we approve this vendor?

Contract clause checklist

Your standard SaaS contract is still the starting point. For medium- and high-risk AI vendors, I also want the contract, DPA, or an AI addendum to cover the AI-specific issues that matter for the use case:

• Training: your content isn’t used for model training or improvement without explicit agreement, with matching obligations flowing to relevant subprocessors
• Inputs and outputs: your rights and confidentiality in the content you provide are preserved, and you have the rights you need to use, modify, and commercialize outputs for your intended purpose
• Vendor-use limits: the vendor’s rights in your content are limited to what’s reasonably needed to provide and secure the service
• Confidentiality expressly covering prompts, outputs, uploaded content, and other AI-related information
• Retention: defined periods for each relevant data category
• Deletion on request and at termination, with defined handling of backups
• Backups: defined retention periods, access restrictions, and treatment of deleted data after a restore
• Subprocessors: current disclosure, notice of material changes, and contractual protections
• Data location and transfers: processing locations and the transfer mechanisms used
• Security commitments appropriate to the data and the AI-specific risks
• Material changes: notice of model, functionality, or data-use changes that could materially affect your use
• Testing and versioning: a reasonable test window or version control where the risk justifies it
• Incidents: defined notification obligations for relevant security and AI incidents
• Assurance: continued delivery of appropriate assurance information
• Regulatory cooperation: the information and reasonable help you need to meet your own obligations
• IP protection: representations, warranties, and indemnities appropriate to the product and risk
• Continuity: appropriate service-level and continuity commitments
• Liability allocation and limits that reflect the actual risk
• Exit: usable data export, transition obligations, and deletion confirmation

The exact language belongs with counsel. Your job in vendor risk is to make sure the risk is visible in the negotiation. If a product handles confidential information and the vendor wants broad rights to use it for model improvement, that isn’t a minor legal redline. It’s part of the approval decision.

Be realistic about backup deletion

“Can you delete our data from every backup immediately?” sounds like a good due-diligence question, but it isn’t always a realistic requirement. Plenty of legitimate services use immutable or rotating backups where individual records can’t be removed right away. What I want to understand is how long backups are kept, whether they’re isolated from normal processing, who can access them, whether they’re used for anything other than recovery, what happens to deleted information if a backup is restored, and when it finally expires.

“We can’t selectively remove individual records from immutable backups, but backups expire after 35 days, aren’t available to production users, and deletion controls are reapplied if we restore.”

That’s a very different answer from “we keep backups indefinitely.” Understand the control instead of turning the questionnaire into a yes-or-no exercise.

Red flags that should pause approval

For a medium- or high-risk use, any one of these is enough for me to stop and investigate:

• The vendor won’t identify material model or provider dependencies.
• Your content is used for training by default, and the opt-out is unclear or not in the contract.
• The assurance evidence doesn’t cover the service you’re buying.
• Retention is indefinite or poorly defined, or backup practices can’t be explained.
• Material model changes can happen silently.
• Accuracy or fairness claims aren’t backed by evidence.
• AI-specific questions get generic, copy-and-paste answers.
• The vendor claims unnecessarily broad rights over your content.
• There’s no meaningful process for AI-related incidents.
• The vendor says every regulatory responsibility belongs to you, whatever its own role.
• The vendor can’t explain where your data goes.
• A high-impact AI system can’t produce useful logs.
• There’s no workable exit or export path.

A red flag doesn’t automatically mean rejection. Sometimes the fix is a contract term, a configuration change, a restriction on the data or use case, or a pilot first. But someone should make that decision deliberately. Don’t let a red flag quietly turn into “accepted” because the business wants the tool next week.

Approval conditions: most decisions are “yes, if”

Medium-risk AI vendors are rarely a clean yes or no. Often the right answer is “yes, if these things happen first.” Write those conditions down and give each one an owner and a deadline. Typical examples:

• Data restriction: no confidential, personal, or client information until the contractual data-use terms are resolved.
• Configuration: disable model training, reduce retention, restrict integrations, or turn off unnecessary AI features. Then verify the settings.
• Limited use: approved only for the stated team and use case; expansion needs a new review.
• Pilot: a controlled pilot and defined evaluation before production use.
• Human oversight: review required before outputs reach customers or materially influence decisions about people.
• Contract remediation: specific terms agreed before go-live or renewal.
• Evidence: the vendor provides an updated assurance report by a set date.
• Enhanced monitoring: the business owner reviews performance or incidents on an agreed schedule.
• Earlier reassessment: review again in six months instead of twelve.

Track approval conditions the same way you’d track audit findings. An approval condition nobody follows up on is just an undocumented acceptance of the original risk.

Ongoing monitoring and material changes

Approval is the beginning of the relationship. AI vendors can change faster than traditional software vendors, and some of the most important changes happen underneath the interface, where nobody sees them. During the year, watch the things that can change your risk:

• Models and features: relevant release notes and change notices.
• Data use: changes to training, retention, or privacy terms.
• Subprocessors: new model, hosting, or other important providers.
• Performance: complaints, errors, and the results of your own recurring tests where appropriate.
• Usage: whether people are using the product beyond the approved use case or with data it wasn’t approved for.
• Incidents: both vendor-reported incidents and problems raised inside your organization.
• Contract and policy terms: don’t assume the web page you reviewed last year still says the same thing.
• Approval conditions: follow up on anything still open.

Define what triggers reassessment

The annual review is a backstop; it shouldn’t be the only trigger. I reopen a vendor assessment early when something material changes: a new underlying model or a significant version change; a major new AI capability; a new use case or expansion to another business unit; use with more sensitive data; new autonomous actions or integrations with sensitive systems; a material subprocessor or model-provider change; changed training or retention practices; a significant security or AI incident; repeated performance problems; expansion into a new jurisdiction; or a regulatory change that materially affects the product or how you use it.

When the model changes materially, treat it like a change to your own AI system. Re-run the important test cases, check that your settings survived the update, read the release notes, update the inventory, and decide whether the residual risk has changed.

Annual reassessment checklist

For medium- and high-risk vendors, review at least annually, and earlier when one of the triggers above occurs.

• Approved use case still matches actual use, and the AI inventory record is current
• Data categories are still accurate, and the inherent-risk tier is reconfirmed
• Current assurance reports obtained and reviewed, including scope, exceptions, and complementary controls
• Model, provider, and subprocessor changes identified and reviewed
• Training and retention terms reconfirmed against the current contract and privacy terms
• Training opt-out, retention settings, and enabled AI features re-verified in the actual configuration
• Material changes identified, and required re-testing completed
• Incidents, complaints, and performance issues reviewed
• Approval conditions closed or escalated
• Regulatory changes assessed
• Exit process still workable
• Residual risk re-rated, and the approval or re-approval decision recorded

Exit, termination, and concentration risk

Plan the exit before you sign. It’s far easier to negotiate data export, transition support, and deletion while the vendor wants your business than when you’re trying to leave. At termination, you should be able to export the data and artifacts you actually need in a usable format, get appropriate confirmation of deletion, understand when residual backup copies expire, revoke integrations, API keys, and service accounts, remove vendor access, update the AI inventory, and close or transfer the vendor risk record.

Concentration risk

This is the risk I see most programs miss. You can have eight AI vendors and still have one underlying dependency. Maybe six of them use the same foundation model provider, or they all run on the same cloud, or several critical processes depend on the same API. On your vendor list that looks diversified. Operationally, it isn’t.

Record the important model and infrastructure dependencies in your inventory and look across the whole portfolio. Then ask: if this provider had a major outage tomorrow, which of our AI systems would stop working? And the harder version: if this provider materially changed its model, pricing, data terms, or acceptable-use policy tomorrow, how many critical processes would we have to reassess at once? For critical systems, understand the fallback. Sometimes there is one and sometimes there isn’t, but leadership should know which situation you’re in.

Frequently asked questions

Isn’t our existing vendor risk process enough?

It’s the right foundation, and you shouldn’t create a separate procurement process just because a product contains AI. Add AI-specific screening and due diligence to the process you already have. Your security, privacy, resilience, and financial reviews still matter; the AI module adds what they usually miss: training, models, model changes, AI-specific testing, foundation model dependencies, autonomous actions, and AI incidents.

Do we need to assess AI features inside tools we already use?

Yes. A vendor relationship that was low risk three years ago can change overnight when the vendor switches on an AI assistant, starts indexing your documents, or adds an agent that can take actions. Treat a material new AI feature as a change, and at minimum run it back through the inherent-risk screen.

Is an ISO/IEC 42001 certificate enough to approve an AI vendor?

No. It can be valuable independent evidence that the vendor runs an AI management system, but read the scope and make sure the relevant organization, activities, and service are covered. And remember what a certificate can’t answer: is this product appropriate for our use case, our data, and our risk? That’s still your decision.

What if a small vendor doesn’t have a SOC 2 report or ISO certification?

Scale the review to the risk. For a lower-risk use, a strong questionnaire, an appropriate security review, contract protections, and limits on the data you share may be enough. For a high-risk use, the lack of independent assurance matters much more. The answer isn’t automatically “reject the startup.” It’s: what evidence do we need at this level of risk, and can the vendor give us enough confidence without the certification?

Who should own AI vendor risk?

Usually your existing third-party risk or procurement function runs the process. The business owner stays accountable for the relationship and the intended use. Security reviews security, privacy reviews privacy, legal handles the legal and contract issues, and AI governance looks across the AI-specific risk. High-risk approvals and exceptions go to the appropriate governance authority. The goal isn’t a new team for every AI risk; it’s making sure somebody actually owns each decision.