AI Vendor Due Diligence: Questions to Ask Before Signing a High-Risk Contract

Buying AI software is no longer just a feature comparison exercise. For many teams, it is a decision about what data leaves the business, who can inspect it, how long it is retained, and whether the vendor’s model governance creates hidden legal, security, or surveillance exposure. If you are evaluating an AI platform for customer support, document processing, analytics, or internal copilots, the contract matters as much as the demo. That is why strong AI vendor due diligence must combine procurement, privacy review, security validation, and practical operational checks before you sign.

This guide is built for buyers who need a real-world procurement checklist, not a generic checklist copied from a sales deck. It focuses on the questions that reveal whether a vendor truly controls data use, whether its systems create surveillance risk, whether its vendor security posture matches your threat model, and whether the legal terms expose your company to unacceptable third-party risk. If you are building your own evaluation process, pair this guide with our broader playbook on build vs. buy in 2026 and our guidance on technical RFP templates for AI-adjacent vendors.

Pro tip: If a vendor cannot answer data-flow questions clearly in writing, do not assume the contract fixes it. Ambiguity in the demo often becomes liability in production.

1) Why AI vendor due diligence is different from ordinary SaaS review

AI tools can process sensitive data in ways buyers do not expect

Traditional SaaS stores data and executes workflows. AI systems often do more: they infer, summarize, score, classify, and generate content from the material you submit. That means a prompt, uploaded file, transcript, or API payload may be transformed into outputs, logs, embeddings, evaluation data, or model improvement signals. In practical terms, your due diligence has to ask not only where data is stored, but also how it is transformed, whether it can be used to train models, and whether a human can review it later. For teams handling customer records, employee data, financial information, or regulated content, those are not side questions—they are the core risk.

The contract can quietly expand vendor rights

Many AI agreements contain broad language around “service improvement,” “quality assurance,” or “fraud prevention,” which can mask expansive rights to analyze customer content. The recent public dispute around government AI contracts and data analysis has made one point obvious: parties can have radically different assumptions about bulk analysis, retention, and lawful access even when the vendor says the product is “enterprise-ready.” That is why buyers should scrutinize privacy terms, model governance, and subcontractor language with the same care used for payment processors or health-tech vendors. If your organization has dealt with procurement and contract lifecycle complexity before, the patterns will feel familiar; our guide on pricing and contract lifecycle for SaaS e-sign vendors on federal schedules shows why terms can matter more than marketing.

AI risk is both technical and policy-driven

With AI vendors, security controls are only half the story. A technically well-architected system can still be unacceptable if the provider reserves the right to retain prompts indefinitely, use customer inputs for training, or hand content to multiple subprocessors for unspecified purposes. Conversely, a vendor with stronger privacy terms may still be too risky if its model governance is immature, its audit logs are weak, or its data segregation is unclear. Buyers need a blended review that covers security architecture, policy posture, and contractual enforceability. That is the only way to make a defensible procurement decision.

2) The first gate: classify the use case before you evaluate the vendor

Start by defining what the AI will touch

Before you send a questionnaire, define the exact use case and the data classes involved. Are you asking the AI to draft marketing copy, process HR files, summarize legal documents, analyze support tickets, or ingest customer PII? Different use cases carry different retention, disclosure, and compliance burdens. A low-risk brainstorming assistant is not the same as a tool that parses invoices, medical records, or internal investigations. The more specific you are, the easier it becomes to assess whether the vendor’s security and privacy model is a match.

Map the data lifecycle, not just the input field

For every use case, document where data originates, what the vendor does with it, where outputs are sent, how long logs are retained, and whether those logs are accessible to vendor staff or subprocessors. This matters because many AI risks happen after the user submits the prompt. For instance, a customer support agent may paste account details into an AI chatbot, and the issue is not just the generated response—it is whether the vendor stores the transcript, indexes it for later retrieval, or uses it for training. That is the same mindset you need when reviewing employee workflow tools and remote collaboration products, similar to the operational control concerns raised in how remote work reshapes employee experience.

Assign a risk tier before legal review

Not every AI contract requires the same level of scrutiny. A practical procurement program should assign tiers such as low, medium, high, and restricted based on the sensitivity of data, regulatory exposure, and business impact. High-risk cases may require legal review, security review, privacy review, and executive approval before a contract is signed. Restricted use cases may prohibit third-party AI entirely unless the vendor meets strict controls. If your team already uses a standard control framework, you can translate this into an approval workflow and a tracked risk register, similar in spirit to the disciplined documentation approach used in human-in-the-loop review for high-risk AI workflows.

3) Data use questions that expose hidden retention and training risk

What exactly happens to our prompts, files, and outputs?

Ask the vendor to describe, in plain English, what happens to every category of data you provide. Does the vendor store raw prompts, metadata, output text, embeddings, voice recordings, or uploaded attachments? Are these items segregated by tenant, encrypted separately, and excluded from model training by default? The answer should be written, not verbal, and it should be specific enough that your legal team can compare it against the MSA and DPA. If a vendor answers with marketing language like “we value privacy” without operational detail, that is a red flag.

Can the vendor use customer data to train or improve models?

This is one of the most important questions in any privacy terms review. You need to know whether customer data is ever used for training, evaluation, fine-tuning, product improvement, abuse detection, or human review. If the answer is yes, ask whether the customer can opt out, whether the opt-out covers both training and human review, and whether the vendor uses synthetic or de-identified data instead. Many buyers assume “not used for training” means “not used at all,” but vendors sometimes preserve rights to analyze content for safety or quality. If you need guidance on building a policy around acceptable data use, see our template approach in archiving B2B interactions and insights, which shows how policy and retention choices shape the risk profile of captured content.

How long is data retained, and can we force deletion?

Data retention is a contractual issue, not just a technical setting. Ask for default retention periods for prompts, logs, support tickets, outputs, backups, and audit records. Then ask how deletion requests are handled, how quickly deletion propagates to backups, and whether deletion can be certified. For regulated businesses, indefinite retention is often unacceptable, and even 30-day retention can be too long if the content includes customer records or trade secrets. A strong vendor should let you set retention periods by workspace or tenant, and should describe whether deleted content remains in cold storage, security archives, or model training corpora.

Does the vendor keep data for legal or surveillance purposes?

Buyers should ask whether the vendor may disclose your content in response to legal process, government requests, or national security demands, and whether it can notify customers before doing so. The issue is not simply whether the vendor complies with law; it is whether the terms create broad discretion for bulk analysis or surveillance-like access. This is where procurement, privacy, and public policy collide. If the contract references law enforcement access, intelligence requests, or “lawful orders,” your legal review should assess whether that language is narrow, notice-based, and consistent with your own obligations. To understand how control over content can become a business issue in adjacent ecosystems, look at our article on monitoring screen time with family-friendly apps, which shows how surveillance concerns can emerge even in consumer-facing tools.

4) Security controls every AI buyer should verify

Identity, access, and tenant isolation

Your vendor should provide clear answers about authentication options, role-based access control, SSO support, MFA enforcement, and separation between tenants. The most basic question is whether an admin at one customer can ever access another customer’s data, even accidentally. You should also confirm whether privileged vendor staff have just-in-time access, whether access is logged, and whether customer data access is limited to named support roles. For small businesses, this can feel abstract, but it is the same principle used in high-trust environments like secure deployment and maintenance workflows, similar to the approach in high-trust service bay design.

Encryption, key management, and logging

Ask whether data is encrypted in transit and at rest, and whether the vendor supports customer-managed keys, bring-your-own-key, or hardware security modules. Then ask how logs are protected, how long they are kept, and who can inspect them. AI systems generate rich logs, and those logs can become a secondary data store full of prompts, snippets, identifiers, and outputs. If those logs are not controlled as tightly as production records, your risk exposure can be worse than the app itself. Buyers should also ask whether logs are included in retention policies and whether they can be exported for incident response without leaking customer data.

Secure development and AI-specific abuse controls

A strong vendor security review should examine secure SDLC practices, vulnerability management, code review, penetration testing, and incident response. But AI products also need protections against prompt injection, data exfiltration through tool use, model inversion, unsafe retrieval behavior, and jailbreak abuse. Ask how the vendor validates outputs, whether it uses allowlists or tool permissions, and whether dangerous actions require human confirmation. If the AI can send email, move tickets, create records, or trigger payments, you need safeguards comparable to those you would demand from any automated workflow system. For a practical perspective on safer shipping patterns, see robust AI safety patterns for customer-facing agents.

5) Surveillance exposure: the questions most buyers forget to ask

Does the product monitor users, workers, or third parties?

Some AI tools are designed to observe behavior, flag anomalies, score risk, or analyze communications at scale. That can be valuable for fraud prevention, but it can also create employee surveillance concerns, customer trust issues, and regulatory problems if used without clear notice and lawful basis. Ask whether the product profiles individuals, whether outputs are used to make automated decisions, and whether human review is required before action is taken. If the vendor collects keystrokes, browser activity, chat transcripts, or device telemetry, the privacy and labor implications are substantially higher. Buyers evaluating workflow-heavy products should study adjacent concerns in our article on event windows and evergreen planning because timing and visibility can shape what users reasonably expect from a system.

Can the AI reveal sensitive patterns through inference?

Even when a vendor does not explicitly store sensitive categories, model outputs can infer them. A support summarizer might expose health details, a hiring assistant could infer protected characteristics, and a finance tool might reveal risk profiles through repeated recommendations. Ask whether the vendor has tested for data leakage, membership inference, prompt-based disclosure, and unintended classification. If the vendor cannot explain its testing regimen, you should assume the AI may reveal more than the input suggests. This is one reason why due diligence must include model governance and not just cloud-security questions.

What notice, consent, and policy controls are available?

If the product creates surveillance exposure, find out whether you can disable certain telemetry, restrict administrator visibility, or display user notices. Your internal policy may also need to inform employees or end users about when AI is used, what data is collected, and how it is retained. In some cases, the right solution is not a feature flag but a policy framework that limits use to approved content classes. For companies working through broader privacy governance, the discipline is similar to adopting better identity and content controls in tools discussed in privacy concerns around age detection systems.

6) Contract red flags that should trigger legal review

Broad license grants over your data

Watch for clauses that give the vendor a perpetual, irrevocable, sublicensable, or worldwide license to use customer content. In a high-risk AI contract, those terms may be far broader than necessary for service delivery. Your preferred language should limit use to providing, securing, and supporting the contracted services, with separate opt-in terms for training or benchmarking. If the vendor insists on broad license rights, ask why the product cannot function under narrower processing terms. In many cases, the negotiation tells you more than the answer.

Unsupported disclaimers and uncapped liability gaps

AI vendors often disclaim liability for output accuracy, hallucinations, or user reliance. Some level of disclaimer is normal, but you should not accept a contract that shifts all output risk to the buyer while giving the vendor broad control over the system. Ask whether the vendor will warrant baseline security practices, compliance with its DPA, and adherence to documented retention controls. Also review whether liability caps are tied to fees paid in the last 12 months, which can be inadequate for a serious data incident. If the tool will process regulated or mission-critical data, the contract should align with your actual loss exposure.

Hidden subprocessors, change rights, and unilateral policy updates

Another common red flag is a vendor that can add subprocessors, change privacy terms, or update acceptable use policies unilaterally with minimal notice. That may be acceptable for low-risk tools, but not for high-risk AI services that process sensitive data. Ask for a current subprocessor list, notice periods for changes, and the ability to object or terminate if a new vendor is materially risky. You should also review whether the vendor can transfer your data cross-border and whether the contract names applicable transfer mechanisms. For a practical comparison of how terms affect vendor lock-in and lifecycle management, review planning for the sunset of Gmailify, which highlights how platform changes can disrupt business operations.

7) Buyer-focused AI procurement checklist

Questions to ask before signature

Use the following questions as a minimum procurement checklist. If a vendor hesitates, escalates, or answers vaguely, treat that as signal—not noise. The goal is to force clarity before contract execution, when you still have leverage. You should document each answer and require confirmation from both sales and legal contacts. In regulated environments, keep the answers in the procurement record so future auditors can see how the decision was made.

Documents to request during diligence

Ask for the MSA, DPA, security whitepaper, subprocessor list, incident response summary, data retention schedule, model governance policy, penetration-test summary, and any third-party assurance reports. If the vendor provides SOC 2 or ISO 27001 reports, review the scope carefully; a certificate is useful only if it covers the actual product and operating entity you are buying. For internal procurement workflows, map these documents to ownership lines so legal, privacy, security, and business stakeholders each review the right evidence. This is no different in principle from using structured evaluation methods in turning product showcases into effective manuals: evidence should support action, not just decorate a sales conversation.

Decision rules for approval, conditional approval, or rejection

Create formal decision rules before vendor review begins. For example, approve only if the vendor offers opt-out from training, defined deletion timelines, SSO and MFA, named subprocessors, and acceptable liability language. Approve conditionally if one or two items can be mitigated through contract addenda or technical configuration. Reject if the vendor retains broad data rights, will not document retention, or cannot explain its security posture with credible detail. That kind of consistency makes procurement faster over time and reduces the chance of exceptions becoming the norm.

8) Model governance questions that distinguish mature vendors from risky ones

How is the model updated, tested, and rolled back?

AI vendors should be able to explain release management: how new models are tested, how regressions are detected, and how failures are rolled back. Ask whether model changes are versioned, whether customers are notified, and whether the vendor maintains test sets for accuracy, safety, and prompt-injection resistance. Mature model governance usually includes stage gates, human review for high-risk changes, and clear ownership across product, security, and legal teams. If a vendor treats the model like a black box that updates itself without customer visibility, that is a sign of operational immaturity.

How do they handle model drift and unsafe outputs?

Because models change over time, a system that was safe at pilot launch may become risky later. Ask whether the vendor monitors drift, tracks complaint patterns, and investigates unsafe or inaccurate outputs. Buyers should also ask about escalation paths for abuse reports, customer complaints, and critical errors. This matters especially when AI is used in customer support, hiring, finance, or other high-impact workflows. If your organization already uses oversight in sensitive workflows, the logic will feel similar to the review model discussed in human-in-the-loop high-risk AI workflows.

Can you audit the system in practice?

Some vendors say they are “transparent,” but transparency is only useful if it leads to auditability. Ask whether you can export logs, inspect prompts, review access history, and receive explanations for automated decisions. If the vendor cannot support meaningful auditing, your ability to investigate incidents will be limited. This is especially important for teams that must explain decisions to customers, regulators, or internal auditors. If the vendor’s answer is that auditing is reserved for premium customers, you should treat that as a business-risk decision, not just a feature gap.

9) A practical review process for small and midsize businesses

Use a four-lane workflow

SMBs do not need a thousand-question questionnaire. They need a repeatable process that is fast, defensible, and focused on real risk. A four-lane workflow works well: business owner review, privacy/legal review, security review, and final approval. The business owner explains the use case, the privacy/legal reviewer checks data rights and retention, the security reviewer validates controls, and the approver signs only when the risk is understood and documented. This keeps the process lean without skipping the questions that matter.

Start with the “no-go” list

Create a short list of unacceptable terms. Examples may include: vendor may train on customer data by default, retention is undefined, subcontractors are undisclosed, data is shared for advertising, or the vendor refuses to provide an incident notice timeline. Having a no-go list speeds decisions and prevents sales pressure from blurring your standards. It also gives non-legal stakeholders a simple framework for escalation. For teams that like operational checklists, our guidance on smart security deal evaluation shows how to separate feature value from hidden risk.

Negotiate for the controls, not just the price

When budgets are tight, it is tempting to focus only on license cost. But a slightly more expensive vendor with clean privacy terms and better security controls can be much cheaper than a bargain tool that creates incident response, regulatory, or reputational damage later. Negotiate around retention, training restrictions, audit rights, indemnity, and support obligations, not just seat price. For SMBs, “affordable” should mean total cost of ownership, including compliance burden and operational overhead. If you are comparing tools across a broader tech stack, the logic is similar to making choices in subscription tools and future-proofing spend.

10) Vendor comparison table: what strong, moderate, and weak answers look like

Use the table as a scoring guide

One of the easiest ways to standardize third-party risk review is to score vendors against common questions. The table below helps procurement teams compare answers quickly and spot patterns. Use it during demos, security calls, and legal redlines. Over time, you will build a benchmark for what “good” looks like in your environment.

11) Redlines that should appear in every high-risk AI contract

Privacy and data processing language

At minimum, your contract should say the vendor processes customer data only on documented instructions, does not use customer content for training unless explicitly agreed, deletes or returns data on termination, and notifies you of subprocessors and security incidents within defined timeframes. If possible, require a narrow purpose clause and a clear definition of customer data that includes prompts, uploaded files, embeddings, and outputs. This reduces the chance of a legal gap between what users think the tool does and what the contract authorizes.

Security, incident response, and audit rights

Ask for written commitments on encryption, access control, vulnerability remediation, logging, and incident notification. If the vendor handles sensitive data, consider audit rights or at least the right to receive independent assurance reports and remediation summaries. Also require the vendor to preserve evidence after incidents and cooperate with investigations. These terms are especially important if the AI system is integrated into customer-facing or regulated workflows.

Termination, deletion, and transition support

Termination should not leave your data stranded in a proprietary service with no export path. Your contract should define how data will be returned, in what format, and within what timeframe. It should also require deletion from active systems and backups according to a documented schedule, with certification upon completion. This prevents a rushed migration from becoming an uncontrolled data retention event, especially when switching vendors quickly under pressure. If your team wants a migration mindset for policy-heavy platforms, see our practical guide to step-by-step migration playbooks.

12) Final procurement checklist before you sign

The last-minute sanity check

Before signature, confirm five things: you know what data the AI touches, you know whether the vendor can train on it, you know how long it is retained, you know what security controls are in place, and you know which contract clauses govern disclosure and deletion. If any answer is unclear, stop and escalate. This is the point where many teams relax because the vendor has “passed security,” but security alone is not sufficient if privacy rights or surveillance exposure remain unresolved.

What good looks like in a mature buying process

A mature buyer does not ask for perfection. It asks for clarity, evidence, and contractual control. The best vendors will be able to explain their data flows, present a credible model governance program, accept reasonable limits on training and retention, and support the audits your business needs. They will not make you choose between usability and compliance. That is the standard to hold for every high-risk AI procurement.

Bottom line

AI purchasing is now a governance exercise, not just an IT purchase. If the vendor touches sensitive information, employee data, or regulated content, your team needs a disciplined review that covers data use, surveillance exposure, security controls, and contract red flags. Use the questions in this guide as your starting checklist, and do not sign until the answers are in writing. The right contract protects your business; the wrong one can turn a productivity gain into a compliance and incident-response burden.

Pro tip: When a vendor says “everyone signs this,” translate that as “everyone accepts our defaults.” Your job is to decide whether those defaults are acceptable for your risk profile.

Frequently Asked Questions

Related Reading

• Build vs. Buy in 2026 - Learn how to choose between open models and proprietary stacks with less risk.
• Picking a Predictive Analytics Vendor - A technical RFP template you can adapt for AI evaluations.
• Robust AI Safety Patterns - Practical safeguards for teams shipping customer-facing AI agents.
• Human-in-the-Loop Review for AI Workflows - A control framework for higher-risk automation.
• SaaS Contract Lifecycle on Federal Schedules - Understand how procurement terms shape long-term vendor risk.