AI Vendor Due Diligence Checklist: What Companies Need to Ask Before Buying AI Software

Most companies will not build every AI system they use.

They will buy it.

They will subscribe to it.

They will turn it on inside software they already use.

They will connect to it through an API.

They will allow employees, vendors, agencies, contractors, and business units to use it in workflows that already process customer data, employee data, applicant data, patient data, financial data, marketing data, legal documents, support tickets, and internal business records.

That is why AI vendor due diligence has become one of the most important parts of AI governance.

The risk is not limited to the AI company building the model. The risk extends to the company deploying the AI system, feeding it data, relying on its outputs, exposing it to customers, using it in employment, connecting it to internal systems, or allowing it to influence decisions.

That creates a dangerous gap.

Many companies still review AI vendors like normal software vendors. They ask for a SOC 2 report, a privacy policy, a security questionnaire, a data processing agreement, a subprocessor list, and maybe a cyber insurance certificate.

Those are important.

They are not enough.

AI vendors create additional questions that traditional vendor review often misses:

• Does the vendor use customer data to train or improve models?
• Are prompts stored?
• Are outputs stored?
• Can training be disabled?
• Does the vendor use a third-party foundation model?
• Does the vendor use subprocessors that also touch AI data?
• Can the vendor explain what the system is designed to do?
• Can the vendor explain what the system should not be used for?
• Does the system make, support, or materially influence decisions?
• Has the system been tested for accuracy, bias, security, and reliability?
• Does the system create audit logs?
• Can humans override the AI output?
• Does the vendor notify customers of model changes?
• Does the contract prohibit unauthorized model training?
• Does the vendor support EU AI Act, NIST AI RMF, and state AI law compliance?

If a company cannot answer those questions, it does not have AI vendor governance.

It has vendor trust.

And vendor trust is not a control.

What Is AI Vendor Due Diligence?

AI vendor due diligence is the process of reviewing an AI vendor, AI-enabled SaaS product, AI model provider, embedded AI feature, chatbot, automated decision-making tool, or AI service provider before the company approves the technology for use.

The purpose is to understand the legal, privacy, security, operational, contractual, and human-impact risks created by the vendor’s AI system.

A strong AI vendor due diligence process should determine:

• What the AI system does
• Who provides the AI system
• Whether the vendor built the model or relies on another model provider
• What data the system processes
• Whether personal data is involved
• Whether sensitive data is involved
• Whether customer data is used for training
• Whether prompts and outputs are retained
• Whether the system affects people
• Whether the system influences decisions
• Whether the system is used in a high-risk area
• Whether the vendor has tested for bias, accuracy, robustness, privacy, and security
• Whether the vendor supports human oversight
• Whether the vendor supports audit logs
• Whether the vendor contract gives the company enough control
• Whether the vendor can support regulatory, customer, and audit requests

AI vendor due diligence should not be a one-time questionnaire buried in procurement.

It should be connected to the company’s broader AI governance framework, AI inventory, vendor management program, privacy compliance program, security review, contract review, and ongoing monitoring process.

If the vendor’s AI system is high-impact, customer-facing, employee-facing, or connected to personal data, the review should be deeper.

The higher the risk, the more evidence the company should require.

Why Normal Vendor Review Is Not Enough for AI

Traditional vendor review usually focuses on security, privacy, availability, and contract terms.

That review may ask:

• Does the vendor have SOC 2?
• Does the vendor encrypt data?
• Does the vendor have a privacy policy?
• Does the vendor use subprocessors?
• Does the vendor sign a data processing agreement?
• Does the vendor have breach notification obligations?
• Does the vendor have access controls?
• Where does the vendor host data?
• How long does the vendor retain data?

Those questions still matter. But AI adds new risks.

AI systems do not just store data. They may generate outputs, make recommendations, classify people, score people, infer sensitive attributes, summarize records, automate workflows, influence decisions, and create new derived information.

AI vendors may also use customer data, prompts, outputs, interactions, corrections, feedback, or usage telemetry to train, fine-tune, evaluate, or improve models.

That creates risk traditional vendor review often misses.

For example, a standard vendor review may approve a recruiting platform because it has strong security documentation.

But the AI review needs to ask whether the platform ranks candidates, analyzes resumes, uses protected-class proxies, requires applicant notice, has been tested for bias, supports human review, and can produce audit evidence.

A standard vendor review may approve a chatbot platform because it encrypts data.

But the AI review needs to ask whether the chatbot collects sensitive data, generates inaccurate answers, requires user disclosure, retains transcripts, trains on conversations, or escalates regulated questions to humans.

A standard vendor review may approve a marketing platform because it has a data processing agreement.

But the AI review needs to ask whether the platform uses AI for profiling, lead scoring, audience segmentation, lookalike modeling, personalized pricing, targeted advertising, or sensitive inferences.

A standard vendor review may approve a document review tool because the vendor has a security program.

But the AI review needs to ask whether the tool uses privileged documents for model improvement, retains prompts, generates hallucinated summaries, or exposes confidential information to a third-party model provider.

AI vendor due diligence is not a replacement for security and privacy review.

It is an additional layer.

AI Vendor Due Diligence Starts with the AI Inventory

Before a company can review AI vendors, it needs to know which vendors use AI.

This is why AI vendor due diligence should connect directly to the company’s AI inventory. The inventory identifies the systems, tools, departments, use cases, owners, data categories, risk levels, and review status. The vendor due diligence process then goes deeper into the vendor’s controls, documentation, contract terms, model behavior, and ongoing obligations.

For a deeper breakdown of the inventory step, see AI Inventory: The First Step in AI Governance.

Vendor due diligence should be triggered when:

• A new AI vendor is being purchased
• An existing vendor adds an AI feature
• A department wants to activate an AI module
• A vendor uses AI on behalf of the company
• A vendor processes personal data with AI
• A vendor uses customer data for model improvement
• A vendor system influences decisions
• A vendor system is customer-facing
• A vendor system is employee-facing
• A vendor system is used in a high-risk industry
• A vendor materially changes its model, subprocessors, or data practices

The mistake many companies make is reviewing AI only when the product is marketed as an AI product.

That is too narrow.

AI may be embedded inside a tool the company already uses. The vendor may add a copilot, summarization feature, recommendation engine, risk score, chatbot, productivity assistant, automated analysis feature, or AI-powered dashboard without the company treating it as a new vendor risk.

That is how AI risk slips in quietly.

The Role of AI Vendor Due Diligence in a Broader AI Governance Framework

AI vendor due diligence is one part of a larger governance system.

A complete program should identify AI systems, classify risk, review data use, map laws, assess vendors, document controls, monitor outputs, train employees, and maintain evidence. Vendor review is where the company determines whether a third-party AI system can support that governance program or whether the vendor creates unacceptable risk.

For a broader program structure, see this AI Governance Framework.

Vendor due diligence should feed into:

• AI inventory
• AI risk classification
• AI impact assessments
• Privacy review
• Security review
• Contract review
• Human oversight planning
• Disclosure review
• Monitoring plans
• Incident response
• Executive reporting
• Customer and regulator evidence

The goal is not to collect vendor answers for the sake of collecting answers.

The goal is to decide whether the vendor can be used safely, lawfully, and defensibly.

The Core AI Vendor Due Diligence Questions

Every AI vendor review should start with a structured set of questions.

The questions should be adjusted based on the vendor’s risk level, the data involved, the use case, and the affected individuals.

A low-risk AI writing assistant used only for generic internal drafting does not require the same review as a hiring platform, insurance underwriting tool, healthcare triage model, financial fraud system, or customer-facing chatbot.

But every AI vendor should be able to answer basic questions about system purpose, data use, training, retention, security, human oversight, and contractual controls.

Vendor Identity and AI System Overview

The company should begin by understanding who the vendor is and what AI system is actually being provided.

Ask:

• What is the legal name of the vendor?
• What product or service is being provided?
• What AI features are included?
• Which AI features are optional?
• Which AI features are enabled by default?
• Is the system internally developed by the vendor?
• Does the vendor rely on a third-party model provider?
• Does the vendor use open-source models?
• Does the vendor use multiple models?
• Does the vendor use agents or autonomous workflows?
• Does the vendor use retrieval augmented generation or customer knowledge bases?
• Does the vendor use AI for support, analytics, ranking, scoring, recommendations, or automated actions?
• Does the vendor use AI only for internal operations, or does AI affect the customer-facing product?

The company should not accept vague answers like “we use proprietary AI” or “our system is AI-powered.”

Those are marketing phrases.

The review needs operational clarity.

Intended Use and Prohibited Use

The company should understand what the vendor says the AI system is designed to do and what it should not be used for.

Ask:

• What is the intended purpose of the AI system?
• What use cases has the vendor designed the system to support?
• What use cases does the vendor prohibit?
• Does the vendor prohibit use in employment, healthcare, credit, insurance, housing, education, legal services, biometric identification, or other high-impact areas?
• Does the vendor provide instructions for use?
• Does the vendor provide limitations or warnings?
• Does the vendor provide customer configuration guidance?
• Does the vendor explain when human review is required?
• Does the vendor explain what data should not be entered?
• Does the vendor explain how outputs should be interpreted?

This matters because a company can create risk by using a vendor’s AI system outside its intended purpose.

If a vendor built a tool for internal productivity and a company uses it to make hiring decisions, the company may be creating a high-risk use the vendor never designed, tested, or approved.

Data Processing and Data Categories

AI vendor review must document what data the vendor processes.

Ask:

• What categories of data does the vendor process?
• Does the vendor process personal data?
• Does the vendor process sensitive personal data?
• Does the vendor process customer data?
• Does the vendor process employee data?
• Does the vendor process applicant data?
• Does the vendor process patient or health data?
• Does the vendor process student data?
• Does the vendor process financial data?
• Does the vendor process insurance data?
• Does the vendor process biometric data?
• Does the vendor process geolocation data?
• Does the vendor process children’s data?
• Does the vendor process behavioral, cookie, pixel, device, or tracking data?
• Does the vendor process confidential business information?
• Does the vendor process source code?
• Does the vendor process privileged or legal information?

The review should also identify whether the data is uploaded by employees, collected automatically, pulled from integrations, retrieved from internal systems, generated by the AI system, or inferred from other data.

This is where AI vendor review connects to data governance, privacy notices, DSAR workflows, retention, consent, and security controls.

Model Training, Fine-Tuning, and Improvement

This is one of the most important parts of AI vendor due diligence.

The company needs to know whether its data will be used to train, fine-tune, improve, evaluate, or monitor AI models.

Ask:

• Does the vendor use customer data to train models?
• Does the vendor use customer data to fine-tune models?
• Does the vendor use customer data to improve the product?
• Does the vendor use prompts for model training or improvement?
• Does the vendor use outputs for model training or improvement?
• Does the vendor use user feedback for model training or improvement?
• Does the vendor use usage telemetry for model training or improvement?
• Does the vendor use customer documents to improve model performance?
• Can model training be disabled?
• Is model training disabled by default?
• Can the customer opt out of training?
• Does opting out apply to all models and subprocessors?
• Does the vendor contractually commit not to train on customer data without permission?
• Are sensitive data categories excluded from training?
• Can data be deleted from training pipelines?
• Does the vendor provide written documentation of training practices?

Do not rely on a salesperson’s verbal statement.

The answer should be reflected in the contract, product settings, data processing terms, security documentation, and vendor AI documentation.

If the vendor cannot clearly answer whether it trains on customer data, that is a major red flag.

Prompt and Output Retention

AI tools often retain prompts, inputs, outputs, logs, transcripts, embeddings, feedback, or interaction history.

That retention can create privacy, confidentiality, security, legal, and data rights issues.

Ask:

• Are prompts retained?
• Are outputs retained?
• Are chat transcripts retained?
• Are uploaded documents retained?
• Are embeddings retained?
• Are user corrections retained?
• Are audit logs retained?
• How long is each category retained?
• Can retention be configured?
• Can prompts and outputs be deleted?
• Can deletion be performed at the individual level?
• Can deletion be performed at the customer account level?
• Are retained prompts or outputs used for training?
• Are retained prompts or outputs accessible to vendor personnel?
• Are retained prompts or outputs shared with subprocessors?
• Are retained prompts or outputs included in backups?

A company should pay special attention to AI systems used for legal, healthcare, HR, security, finance, customer support, or product development workflows.

Those systems may process sensitive or confidential information that should not be retained longer than necessary.

Subprocessors and Foundation Model Providers

Many AI vendors are not the only party involved.

The vendor may use cloud providers, model providers, data labeling vendors, analytics tools, content moderation services, monitoring platforms, or other subprocessors.

Ask:

• Does the vendor use subprocessors?
• Which subprocessors process customer data?
• Which subprocessors process prompts?
• Which subprocessors process outputs?
• Which subprocessors provide foundation models?
• Which subprocessors provide hosting?
• Which subprocessors provide logging or monitoring?
• Which subprocessors provide human review or annotation?
• Where are subprocessors located?
• Can the customer object to new subprocessors?
• Does the vendor notify customers of subprocessor changes?
• Do subprocessors train on customer data?
• Do subprocessors retain prompts or outputs?
• Do subprocessors support deletion?

Subprocessor review matters because the company’s data may travel farther than the vendor’s sales materials suggest.

For AI systems, the hidden chain of model providers and infrastructure providers can become a major governance issue.

Security Controls

AI vendor due diligence must include security review.

But AI security is not limited to ordinary application security.

Ask:

• Does the vendor have a security program?
• Does the vendor have SOC 2, ISO 27001, or other relevant security documentation?
• How is data encrypted in transit and at rest?
• How are prompts and outputs protected?
• How are API keys protected?
• How are integrations secured?
• How does the vendor prevent unauthorized access to customer data?
• How does the vendor restrict employee access?
• How does the vendor monitor suspicious activity?
• How does the vendor protect against prompt injection?
• How does the vendor protect against data exfiltration?
• How does the vendor protect against model manipulation?
• How does the vendor prevent leakage of confidential data through outputs?
• How does the vendor test AI-specific security risks?
• Does the vendor conduct red teaming?
• Does the vendor provide vulnerability disclosure or bug bounty information?
• Does the vendor notify customers of AI security incidents?

AI security review becomes more important when the system connects to internal databases, CRM tools, HR platforms, ticketing systems, cloud systems, code repositories, email, calendars, payment systems, health records, customer records, or production workflows.

A standalone AI drafting tool is one risk profile.

An AI agent that can retrieve records, update systems, email customers, call APIs, or trigger workflows is a much larger risk profile.

Accuracy, Reliability, and Performance Claims

AI vendors often make bold claims.

They may claim their systems are accurate, unbiased, secure, explainable, compliant, enterprise-ready, hallucination-resistant, or able to replace manual work.

Those claims need support.

Ask:

• What accuracy claims does the vendor make?
• How were those claims tested?
• What datasets were used for testing?
• Are test results specific to the customer’s intended use case?
• Does the vendor provide validation reports?
• Does the vendor provide performance metrics?
• Does the vendor provide confidence scoring?
• Does the vendor disclose known failure modes?
• Does the vendor disclose limitations?
• How often does the vendor retest the system?
• How does the vendor handle model drift?
• How does the vendor handle hallucinations?
• How does the vendor handle false positives?
• How does the vendor handle false negatives?
• Can the customer run a proof of concept with representative data?
• Can the customer test edge cases before deployment?

Do not accept “99% accurate” without context.

Accurate for what task?

Accurate on what data?

Accurate for which population?

Accurate under what conditions?

Accurate compared to what baseline?

A vendor’s general accuracy claim may be meaningless for the company’s specific use case.

Bias, Fairness, and Discrimination Testing

Bias review is essential when AI affects people.

It is especially important in employment, housing, credit, lending, insurance, healthcare, education, fraud, pricing, benefits, access, and safety contexts.

Ask:

• Has the vendor tested for bias?
• Has the vendor tested for disparate impact?
• What protected or sensitive characteristics were considered?
• What proxy variables were reviewed?
• What datasets were used?
• Were the tests performed by the vendor or an independent third party?
• How often is testing repeated?
• Does the vendor provide bias audit results?
• Does the vendor provide methodology?
• Does the vendor support customer-specific bias testing?
• Does the vendor disclose known bias limitations?
• Does the vendor support remediation if bias is identified?
• Does the vendor allow customers to configure or restrict risky features?
• Does the vendor provide documentation for employment, lending, healthcare, insurance, or education use cases?

Bias testing should be tied to the actual use case.

A vendor’s general fairness statement does not prove that the tool is safe for a specific employer, lender, insurer, healthcare provider, school, or platform.

Human Oversight and Override

Human oversight is only meaningful if the human can understand, challenge, and override the AI output.

Ask:

• Does the system require human review?
• Can the customer configure human review?
• Can the human reviewer see the information needed to evaluate the output?
• Does the system explain why it produced a recommendation?
• Can the human reviewer override the output?
• Are overrides logged?
• Are reviewer decisions logged?
• Does the vendor provide reviewer training materials?
• Does the vendor warn against overreliance on AI outputs?
• Does the system support escalation to a human?
• Does the system prevent automated action without approval in high-risk contexts?
• Can the system be configured to require approval before taking action?

Human oversight should be stronger where the AI system affects rights, opportunities, access, eligibility, pricing, safety, employment, healthcare, insurance, lending, education, housing, or legal services.

A checkbox that says “human in the loop” is not enough.

Transparency and Disclosure Support

Many AI systems require transparency to users, employees, applicants, customers, or consumers.

Ask:

• Does the vendor support AI disclosures?
• Does the product identify AI-generated outputs?
• Does the product disclose chatbot interactions?
• Can the customer customize disclosures?
• Does the vendor provide recommended disclosure language?
• Does the vendor support notices for employment use?
• Does the vendor support notices for consumer use?
• Does the vendor support synthetic media labeling?
• Does the vendor support explanation requests?
• Does the vendor support access, correction, opt-out, appeal, or human review workflows where required?
• Does the vendor provide documentation that can be used in privacy notices?

Disclosure should not be an afterthought.

If users are interacting with AI or AI materially influences a decision, the company needs to know what notice is required and whether the vendor’s product supports it.

Audit Logs and Evidence

AI governance depends on evidence.

If the company cannot reconstruct what happened, it will struggle during audits, disputes, investigations, litigation, customer reviews, or regulator inquiries.

Ask:

• Does the system create audit logs?
• What events are logged?
• Are prompts logged?
• Are outputs logged?
• Are model versions logged?
• Are system configuration changes logged?
• Are human review actions logged?
• Are overrides logged?
• Are user interactions logged?
• Are disclosures logged?
• How long are logs retained?
• Can logs be exported?
• Can logs be searched?
• Can logs be preserved for legal hold?
• Can logs support audits and regulatory inquiries?

Audit logs are especially important for high-impact AI systems.

The company should be able to show what system was used, what data was entered, what output was generated, who reviewed it, what decision was made, what version was active, and what controls applied.

Model Changes and Product Updates

AI systems change.

Vendors update models, prompts, weights, safety controls, retrieval systems, features, integrations, user interfaces, subprocessors, and terms.

Those changes can alter the risk profile.

Ask:

• How often does the vendor update the model?
• Does the vendor notify customers of material model changes?
• Does the vendor notify customers of changes to AI features?
• Does the vendor notify customers of new subprocessors?
• Does the vendor notify customers of changes to data use?
• Does the vendor notify customers of changes to retention?
• Does the vendor allow customers to delay or reject material updates?
• Does the vendor provide release notes?
• Does the vendor provide updated documentation after changes?
• Does the vendor retest after model changes?
• Can the customer monitor performance before and after changes?

This is critical because an AI system approved in January may not be the same system operating in June.

Vendor due diligence needs a change-management process.

Regulatory and Customer Support

AI vendors should be able to support the company when customers, regulators, auditors, insurers, or plaintiffs ask questions.

Ask:

• Will the vendor cooperate with regulatory inquiries?
• Will the vendor provide documentation for audits?
• Will the vendor support customer questionnaires?
• Will the vendor support EU AI Act classification?
• Will the vendor support impact assessments?
• Will the vendor support data protection assessments?
• Will the vendor support bias audit requirements?
• Will the vendor support DSAR or privacy rights requests?
• Will the vendor support deletion requests?
• Will the vendor support litigation holds?
• Will the vendor provide incident reports?
• Will the vendor provide records of model changes?

A vendor that cannot support compliance evidence may be a poor fit for high-impact use cases.

AI Vendor Contract Terms Companies Should Require

AI vendor diligence should not end with a questionnaire.

The contract needs to match the risk.

For AI vendors, companies should consider contract terms covering the following areas.

Data Use Restrictions

The contract should state exactly how the vendor may use company data, customer data, employee data, prompts, outputs, logs, feedback, and usage data.

The company should avoid broad language that allows the vendor to use data to “improve services” without clear limits.

For AI systems, “improve services” can become the doorway to model training.

No Unauthorized Model Training

The contract should prohibit the vendor from using customer data, prompts, outputs, documents, or user interactions to train, fine-tune, or improve models unless expressly permitted.

If training is allowed, the contract should define the scope, data categories, safeguards, deletion rules, opt-out process, and any required consent or notice.

Prompt and Output Handling

The contract should address whether prompts and outputs are retained, for how long, who can access them, whether they are shared with subprocessors, whether they are used for training, and how they can be deleted.

Subprocessor Controls

The contract should require disclosure of subprocessors, notice of changes, flow-down obligations, and restrictions on subprocessor use of customer data.

This is especially important where a vendor relies on a foundation model provider or third-party AI infrastructure.

Security Commitments

The contract should include security controls appropriate to the data and use case.

For higher-risk systems, the contract should address AI-specific security risks, including prompt injection, data leakage, unauthorized access, model manipulation, and incident notification.

Confidentiality

The contract should protect confidential information, trade secrets, source code, business data, legal documents, customer information, employee information, and other sensitive materials entered into or generated by the AI system.

Documentation Obligations

The vendor should provide documentation needed for AI governance, including system descriptions, intended use, limitations, instructions for use, data practices, model-change notices, testing summaries, security documentation, and compliance support.

Human Oversight Support

If the system is used in a high-impact process, the contract should require the vendor to support human review, override, logging, and explainability features where appropriate.

Audit Rights

The company should consider audit rights or at least documentation-review rights for higher-risk AI vendors.

Where direct audit is unrealistic, the company should require independent reports, certifications, testing summaries, or other evidence.

Regulatory Cooperation

The contract should require the vendor to cooperate with regulatory inquiries, customer audits, impact assessments, data protection assessments, AI law compliance reviews, and legally required requests.

Model Change Notification

The vendor should notify the company before material changes to models, features, subprocessors, data use, retention, or system behavior.

Incident Notification

The contract should require prompt notice of security incidents, privacy incidents, AI system failures, unlawful data use, model behavior issues, or material non-compliance.

Indemnity

AI indemnity should be reviewed carefully.

Some vendors may offer narrow indemnity that does not cover the company’s actual risk. The company should consider whether indemnity covers intellectual property claims, data misuse, confidentiality breaches, privacy violations, regulatory claims, discrimination claims, AI output issues, and vendor non-compliance.

Limitation of Liability

AI risks can exceed ordinary SaaS risk. The company should consider whether liability caps are appropriate for the data, use case, and potential harm.

Higher-risk AI systems may require higher caps, exclusions from caps, or specific remedies.

Termination and Deletion

The contract should address what happens when the relationship ends.

The company should be able to retrieve data, delete data, disable access, delete prompts and outputs where appropriate, and receive confirmation of deletion.

AI Vendor Due Diligence by Risk Level

Not every AI vendor needs the same review.

A practical AI vendor due diligence program should scale based on risk.

Low-Risk AI Vendors

Low-risk vendors may include tools used for internal drafting, formatting, brainstorming, translation, or summarization where no confidential data, personal data, sensitive data, or customer-facing output is involved.

Review should focus on acceptable use, data restrictions, training practices, retention, security, and employee guidance.

Moderate-Risk AI Vendors

Moderate-risk vendors may process personal data, support business decisions, generate external content, analyze customer interactions, or integrate with internal systems.

Review should include privacy, security, data use, training restrictions, retention, disclosures, logging, vendor documentation, and monitoring.

Customer-Facing AI Vendors

Customer-facing AI vendors may include chatbots, support assistants, recommendation engines, personalization tools, or AI-generated content systems.

Review should include user disclosures, sensitive data controls, hallucination risk, escalation paths, transcript retention, monitoring, and incident response.

High-Impact AI Vendors

High-impact AI vendors may influence employment, lending, credit, insurance, housing, healthcare, education, legal services, fraud, account access, benefits, pricing, or essential services.

Review should include AI impact assessments, bias testing, accuracy testing, explainability, human oversight, audit logs, legal mapping, vendor documentation, contract controls, monitoring, and executive approval.

Prohibited or Restricted AI Vendors

Some vendors or use cases should be blocked.

This may include AI systems that cannot explain data use, refuse to restrict training on customer data, cannot support deletion, are designed for deceptive practices, cannot support human oversight in high-impact uses, cannot provide basic security documentation, or are used in legally prohibited ways.

A company should not approve an AI vendor just because the business team wants speed.

Some vendors are not worth the risk.

AI Vendor Due Diligence for SaaS Companies

SaaS companies face AI vendor risk from both product and operations.

They may use AI vendors for product features, customer support, engineering, analytics, sales, marketing, security, customer success, documentation, and internal productivity.

SaaS vendor review should ask:

• Does the vendor process customer data?
• Does the vendor train on customer data?
• Can customer data training be disabled?
• Does the vendor create outputs shown to customers?
• Does the vendor integrate into the SaaS product?
• Does the vendor become part of the customer-facing service?
• Does the vendor support enterprise customer questionnaires?
• Does the vendor support subprocessor disclosures?
• Does the vendor support audit logs?
• Does the vendor support deletion and DSAR workflows?
• Does the vendor create AI features customers need to disclose to their own users?

For SaaS companies, AI vendor governance is not just compliance.

It is revenue protection.

Enterprise customers are increasingly asking how AI vendors are reviewed, whether customer data is used for training, whether AI features can be disabled, and whether AI systems are documented.

A SaaS company that cannot answer those questions will slow down security and privacy review.

AI Vendor Due Diligence for HR and Employment Tools

HR AI vendors require special scrutiny.

These vendors may process applicant data, employee data, performance data, compensation data, productivity data, interview data, resume data, assessment results, or workforce analytics.

HR vendor review should ask:

• Does the tool rank candidates?
• Does the tool score resumes?
• Does the tool analyze interviews?
• Does the tool recommend applicants?
• Does the tool support promotion, discipline, compensation, or termination decisions?
• Does the tool monitor productivity?
• Does the tool analyze employee communications?
• Has the vendor tested for bias?
• Does the vendor provide bias audit documentation?
• Does the vendor support applicant notice?
• Does the vendor support human review?
• Does the vendor allow configuration to avoid prohibited factors?
• Does the vendor explain the factors influencing output?
• Does the vendor support audit logs?
• Does the vendor contractually restrict use of applicant and employee data?

Employment AI is one of the highest-risk areas in AI governance.

Employers should not rely on generic vendor assurances.

AI Vendor Due Diligence for Healthcare

Healthcare AI vendors can create major risk because they may process sensitive health data, patient records, claims data, appointment data, clinical notes, communications, care recommendations, triage information, or billing data.

Healthcare vendor review should ask:

• Does the vendor process protected health information?
• Is a business associate agreement required?
• Does the vendor use patient data for model training?
• Does the vendor provide clinical decision support?
• Does the system influence triage, treatment, scheduling, billing, coding, or patient outreach?
• Does the system require clinician oversight?
• Has the system been validated for the healthcare use case?
• Does the system create patient safety risk?
• Does the vendor support audit logs?
• Does the vendor support deletion and retention requirements?
• Does the vendor provide incident notification?
• Does the vendor rely on third-party model providers?

Healthcare AI should not be treated like ordinary workflow automation.

When patient data and care-related outputs are involved, the review needs to be deeper.

AI Vendor Due Diligence for Financial Services, Lending, and Insurance

AI vendors in financial services, lending, and insurance can influence decisions that directly affect people’s access to money, credit, coverage, pricing, claims, fraud review, account access, or benefits.

Vendor review should ask:

• Does the system influence credit, lending, underwriting, claims, fraud, pricing, or eligibility?
• Does the system use consumer reports or financial data?
• Does the system create adverse action explanation issues?
• Does the vendor provide model documentation?
• Does the vendor provide validation results?
• Does the vendor test for protected-class proxies?
• Does the vendor support explainability?
• Does the vendor support appeals or human review?
• Does the vendor support audit logs?
• Does the vendor notify customers of model changes?
• Does the vendor support regulator examination?
• Does the contract allocate responsibility for model failures?

Financial and insurance AI systems should be reviewed as high-impact systems whenever they affect eligibility, pricing, access, or adverse outcomes.

AI Vendor Due Diligence for Marketing and Adtech

Marketing AI often looks harmless because it does not sit inside HR, healthcare, or finance.

That is a mistake.

Marketing AI can involve profiling, tracking, cookies, pixels, data broker data, lead scoring, audience segmentation, ad targeting, personalization, and predictive analytics.

Marketing AI vendor review should ask:

• Does the vendor use AI for audience segmentation?
• Does the vendor use AI for lead scoring?
• Does the vendor use AI for personalization?
• Does the vendor use AI for targeted advertising?
• Does the vendor use cookie, pixel, or tracking data?
• Does the vendor use data broker data?
• Does the vendor infer sensitive attributes?
• Does the vendor support opt-out rights?
• Does the vendor support consent signals?
• Does the vendor process sale, sharing, or targeted advertising data?
• Does the vendor use customer data for model training?
• Does the vendor provide downstream use restrictions?
• Does the vendor create deceptive or manipulative content risk?

AI-powered marketing can create privacy, consumer protection, and discrimination risk even when it is framed as “optimization.”

AI Vendor Red Flags

Some vendor answers should immediately raise concern.

Red flags include:

• The vendor cannot explain what AI features are used.
• The vendor cannot identify its model providers.
• The vendor refuses to explain whether customer data is used for training.
• The vendor uses broad “service improvement” language without training restrictions.
• The vendor cannot provide prompt or output retention terms.
• The vendor cannot support deletion.
• The vendor cannot identify subprocessors.
• The vendor cannot provide security documentation.
• The vendor cannot explain model changes.
• The vendor cannot provide audit logs.
• The vendor cannot support human review.
• The vendor makes broad accuracy claims without validation.
• The vendor claims the system is unbiased without methodology.
• The vendor shifts all testing responsibility to the customer.
• The vendor prohibits testing with representative data.
• The vendor refuses contractual restrictions on model training.
• The vendor will not cooperate with regulatory or customer inquiries.
• The vendor markets the tool for high-impact uses but provides no high-impact compliance documentation.

One red flag may be manageable.

Several red flags should stop the process.

Proof of Concept Testing for AI Vendors

For higher-risk AI vendors, a proof of concept should be part of the due diligence process.

A proof of concept should test the vendor’s system against realistic scenarios before full deployment.

The company should test:

• Normal use cases
• Edge cases
• High-risk scenarios
• Sensitive data scenarios
• Ambiguous inputs
• Incorrect inputs
• Adversarial prompts
• Bias-sensitive examples
• Expected escalation scenarios
• Known failure modes
• Human override workflows
• Logging and export functionality

The goal is not to become the vendor’s quality assurance department.

The goal is to determine whether the system is safe enough for the company’s specific use case.

Vendor claims are not a substitute for testing.

How AI Vendor Due Diligence Should Be Documented

AI vendor diligence should create an evidence file.

That file should include:

• Vendor questionnaire
• Vendor documentation
• Security reports
• Privacy terms
• Data processing agreement
• AI documentation
• Training-data terms
• Subprocessor list
• Model provider information
• Contract redlines
• Proof of concept results
• Risk classification
• Impact assessment
• Approval decision
• Required controls
• Monitoring plan
• Review date

This evidence file should be connected to the AI inventory and broader vendor management system.

If the company later receives a customer questionnaire, regulator inquiry, internal audit request, incident report, or legal demand, it should not have to dig through email threads to reconstruct the vendor review.

Why AI Vendor Due Diligence Software Matters

AI vendor due diligence becomes difficult to manage manually.

Spreadsheets and email threads may work for a small number of vendors, but they break down as AI adoption expands across the business.

AI vendor due diligence software should support:

• AI vendor intake
• AI inventory integration
• AI risk scoring
• Vendor questionnaires
• Training-data review
• Prompt and output retention review
• Subprocessor tracking
• EU AI Act mapping
• NIST AI RMF mapping
• State law mapping
• Privacy review
• Security review
• Contract review tracking
• AI impact assessment triggers
• Approval workflows
• Evidence storage
• Renewal reminders
• Model change review
• Incident tracking
• Executive reporting

The purpose of AI compliance software is to make the review repeatable.

Every AI vendor should not require a brand-new process. The company should have structured workflows that route the vendor to the right reviewers based on risk.

Low-risk AI tools may receive a lighter review.

High-impact AI vendors should receive deeper review.

Vendors that process sensitive data, influence decisions, or train on customer data should not be approved casually.

The AI Vendor Due Diligence Checklist

Companies can use the following checklist as a starting point before approving an AI vendor.

Vendor Overview

• Have we identified the vendor’s legal name?
• Have we identified the AI product or feature?
• Have we identified whether AI is core to the product or embedded in a broader platform?
• Have we identified whether the AI system is internally built, third-party, open-source, or foundation-model based?
• Have we identified the intended use and prohibited uses?

Business Use

• Have we documented why the company wants to use the vendor?
• Have we documented the department using it?
• Have we documented the business process affected?
• Have we documented whether the system is customer-facing?
• Have we documented whether the system is employee-facing?
• Have we documented whether the system influences decisions?

Data Use

• Have we documented all data categories processed?
• Have we identified whether personal data is involved?
• Have we identified whether sensitive data is involved?
• Have we identified whether customer, employee, applicant, patient, student, financial, or children’s data is involved?
• Have we documented whether the vendor uses data for training, fine-tuning, or model improvement?
• Have we documented prompt and output retention?

Vendor Controls

• Have we reviewed security documentation?
• Have we reviewed AI documentation?
• Have we reviewed model documentation where available?
• Have we reviewed subprocessor documentation?
• Have we reviewed model provider dependencies?
• Have we reviewed incident notification terms?
• Have we reviewed deletion support?

Risk and Testing

• Have we classified the vendor’s risk level?
• Have we reviewed accuracy claims?
• Have we reviewed bias or fairness testing?
• Have we reviewed security testing?
• Have we reviewed explainability?
• Have we tested the system with representative scenarios where appropriate?
• Have we identified known limitations?

Human Oversight

• Have we documented whether human review is required?
• Have we confirmed whether the system supports human override?
• Have we confirmed whether overrides are logged?
• Have we confirmed whether users receive enough information to review outputs?
• Have we documented reviewer training needs?

Legal and Compliance

• Have we reviewed EU AI Act applicability?
• Have we reviewed NIST AI RMF alignment?
• Have we reviewed state AI law applicability?
• Have we reviewed privacy law obligations?
• Have we reviewed employment AI obligations if applicable?
• Have we reviewed sector-specific obligations if applicable?
• Have we reviewed whether disclosures are required?
• Have we reviewed whether opt-out, appeal, correction, or human review rights apply?

Contract Controls

• Does the contract restrict data use?
• Does the contract prohibit unauthorized model training?
• Does the contract address prompt and output retention?
• Does the contract include subprocessor controls?
• Does the contract include security obligations?
• Does the contract include confidentiality protections?
• Does the contract include AI documentation obligations?
• Does the contract include model change notification?
• Does the contract include regulatory cooperation?
• Does the contract include incident notification?
• Does the contract include deletion obligations?
• Does the contract include appropriate indemnity and liability terms?

Approval and Monitoring

• Has the vendor been approved, rejected, or approved with conditions?
• Have required controls been assigned?
• Has a business owner been assigned?
• Has a review date been set?
• Has monitoring cadence been documented?
• Has the evidence file been saved?
• Has the AI inventory been updated?

Common AI Vendor Due Diligence Mistakes

Companies usually make the same mistakes when reviewing AI vendors.

Mistake One: Treating AI Vendors Like Ordinary SaaS Vendors

AI vendors need privacy and security review, but they also need AI-specific review around training, outputs, bias, human oversight, model changes, and decision impact.

Mistake Two: Trusting the Sales Deck

AI sales materials often overstate capabilities. Due diligence should rely on documentation, testing, contracts, and evidence.

Mistake Three: Ignoring Embedded AI

Many AI risks come from features inside software the company already uses. Existing vendors should be reviewed when they add AI capabilities.

Mistake Four: Failing to Restrict Model Training

If the contract does not clearly restrict training on customer data, the company may have less control than it thinks.

Mistake Five: Ignoring Prompt and Output Retention

Prompts and outputs can contain sensitive, confidential, or regulated information. Retention must be reviewed.

Mistake Six: Assuming a Human in the Loop Solves Everything

Human review only helps if the reviewer is trained, informed, empowered, and able to override the AI output.

Mistake Seven: Skipping Bias Review

Any AI vendor used in employment, lending, insurance, housing, healthcare, education, fraud, pricing, or access decisions should be reviewed for discrimination risk.

Mistake Eight: Not Testing the System

Vendor claims should be tested against realistic use cases, especially for higher-risk deployments.

Mistake Nine: Forgetting Model Change Management

An AI system can change after approval. Vendor updates should trigger review when they affect risk.

Mistake Ten: Not Keeping Evidence

If the company cannot produce the vendor review, it cannot prove the vendor was governed.

Final Takeaway

AI vendor due diligence is no longer optional.

Most companies will use AI through vendors. That means the quality of the company’s AI governance program depends heavily on how well it reviews, contracts with, monitors, and documents AI vendors.

A standard SaaS review is not enough.

AI vendors create additional risks around model training, prompt retention, output accuracy, hallucinations, bias, human oversight, automated decision-making, audit logs, disclosure, model changes, subprocessors, and regulatory support.

The company buying the tool cannot assume the vendor has handled everything.

If the company deploys the AI system, feeds it data, relies on its output, uses it with customers, applies it to employees or applicants, connects it to internal systems, or lets it influence decisions, the company owns part of the risk.

That risk needs to be reviewed before deployment.

It needs to be written into the contract.

It needs to be connected to the AI inventory.

It needs to be mapped to the broader AI governance framework.

It needs to be monitored over time.

And it needs to be supported by evidence.

AI vendor trust is not AI governance.

AI vendor due diligence is.