AI Vendor Due Diligence: A Legal Review for Safer Contracts

Legal approval should not rest on a vendor’s product demo, security badge, or standard contract. AI vendor due diligence gives legal teams a structured way to verify how an AI provider handles data, intellectual property, confidentiality, security, regulatory obligations, liability, and operational change before the organization signs or deploys the service. The review should connect the vendor’s technical behavior to enforceable contract terms, documented evidence, and a clear internal owner.

An AI vendor is not simply another software supplier. Depending on the product, it may process confidential business information, personal data, privileged material, employee records, customer communications, or proprietary content. It may also generate outputs that influence decisions, trigger workflows, or become part of a company’s records. Legal teams therefore need to examine both the vendor’s promises and the mechanisms that make those promises verifiable.

Why AI vendor approval requires more than a standard software review

Traditional software due diligence focuses on familiar issues such as uptime, access controls, data protection, service levels, and termination rights. Those issues still matter, but AI introduces additional questions about model training, prompt and output handling, automated decisions, hallucinations, human review, model changes, and ownership of generated content.

The legal risk also depends on the system’s role. A tool that summarizes internal documents presents a different risk profile from an AI agent that can send emails, modify records, approve transactions, or call external systems. Legal review should assess the actual workflow, not just the vendor’s product category.

Our existing guidance on evaluating AI companies for business, technical, and operational fit addresses the broader provider-selection process. This article takes a narrower legal angle: how counsel can test the vendor’s claims, translate them into contract protections, and identify approval conditions before signature or production access.

A useful starting point is to classify the proposed use by four factors:

• What data enters the system?

• What does the model or AI workflow produce?

• Who relies on the output?

• What actions can the system take without human approval?

The more sensitive the data and the more consequential the action, the more evidence and contractual precision legal should require.

What should legal teams verify before approving an AI vendor?

Legal teams should verify the vendor’s data practices, security controls, intellectual property position, regulatory responsibilities, liability allocation, subcontractor use, operational change process, and exit obligations. Each area should be supported by documentation such as a data processing addendum, security exhibits, audit reports, insurance evidence, product documentation, subprocessors lists, and written answers to use-case-specific questions. Approval should be conditional when the vendor cannot explain how the service behaves in the organization’s intended workflow.

The following review areas provide a practical legal framework.

Data use, retention, and model training

The first question is whether the vendor uses customer data to train, fine-tune, evaluate, or improve a model. “We do not train on your data” is useful, but it is not enough on its own. The contract should define customer data broadly and state exactly whether prompts, uploaded files, retrieved documents, metadata, usage logs, feedback, and outputs are included or excluded from model improvement.

Legal should verify:

• Whether customer content is used for general model training or service improvement.

• Whether data is retained after a request completes.

• How deleted data is handled across production systems, backups, caches, and logs.

• Whether the vendor creates embeddings, vector indexes, profiles, or derived data.

• Whether customer data is logically or physically separated from other customers.

• Whether the vendor can access content for support, debugging, abuse monitoring, or human review.

• Whether the customer can configure retention, regional processing, and training preferences.

A particularly important distinction is between transient processing and persistent storage. An AI provider might not use prompts to train a foundation model but still retain them in application logs for a period of time. Those logs may contain confidential or regulated information and should be covered by the same data governance expectations as the main service.

If the system uses retrieval-augmented generation, legal should also ask where indexed source documents, embeddings, access permissions, and retrieval logs reside. Removing the original document does not automatically answer what happens to derived indexes or cached representations.

Privacy, data protection, and international transfers

An AI vendor may process personal data even when the customer does not intend to purchase a “data analytics” product. Names in email threads, customer support transcripts, employee records, invoices, voice recordings, and free-text notes can all be personal data.

The privacy review should identify the parties’ roles, the processing purpose, the categories of data, retention periods, data-subject rights, security measures, and international transfer mechanism. Where applicable, the agreement should include a data processing addendum with instructions that are specific to the AI service rather than copied from a generic software template.

Legal teams should examine whether:

• The vendor acts as a processor, independent controller, or another legally recognized role.

• The vendor’s subprocessors are disclosed and subject to notice or objection rights.

• Data is transferred across jurisdictions and supported by an appropriate mechanism.

• The vendor can assist with deletion, access, correction, restriction, and audit requests.

• The service processes sensitive or special-category data.

• Data residency commitments apply to prompts, outputs, telemetry, backups, and support access.

• The vendor uses automated profiling or produces decisions with legal or similarly significant effects.

A vendor’s public privacy policy does not replace negotiated terms. Product policies can change independently, while a contract should establish the specific commitments that apply to the customer’s deployment.

For higher-risk use cases, legal should coordinate with privacy, security, procurement, and the business owner before approval. A privacy review that ignores the system’s actual prompts and connected data sources is incomplete.

Security evidence and AI-specific attack paths

Security diligence should cover normal application controls and risks that are specific to AI systems. These include prompt injection, insecure retrieval, unauthorized tool calls, sensitive information disclosure, model extraction, and unsafe handling of uploaded content.

We cover related control issues in our guide to AI security risks involving external agents and LLMs. For legal approval, the important question is how those risks are assigned and managed under the agreement.

Request evidence that addresses:

• Independent security assessments or recognized assurance reports.

• Encryption in transit and at rest.

• Identity and access management, including role-based access controls.

• Administrative access logging and privileged-user monitoring.

• Vulnerability management and penetration testing.

• Incident detection, investigation, notification, and cooperation.

• Environment separation between development, testing, and production.

• Secure deletion and media disposal.

• Business continuity, disaster recovery, and recovery testing.

• Controls for connected tools, APIs, plugins, and retrieval sources.

The AI-specific question is whether untrusted content can influence trusted instructions. For example, a retrieved document could contain an instruction designed to manipulate the model into exposing information or taking an unauthorized action. The vendor should explain how it separates system instructions, user instructions, retrieved content, and tool permissions.

Counsel should avoid accepting vague language such as “industry-standard security” without identifying the actual controls, evidence, notification timeline, and remedies. A contract that promises security but does not provide audit rights, cooperation obligations, or meaningful incident notice leaves the customer with limited recourse.

Intellectual property, confidentiality, and output ownership

AI contracts frequently use broad definitions that blur the difference between customer input, vendor technology, model parameters, generated output, and usage data. Legal teams should separate these categories before reviewing ownership language.

The agreement should address:

Customer input. The customer should retain ownership of information, documents, prompts, instructions, and other material submitted to the service.

Customer output. The parties should state who receives rights in generated content, recognizing that copyright protection for AI-generated material depends on human contribution and applicable law. Contractual rights do not automatically guarantee exclusive intellectual property protection.

Vendor technology. The vendor should retain its pre-existing software, models, tools, documentation, and general know-how, subject to the customer’s right to use the service and its outputs.

Derived data. Embeddings, evaluation data, usage telemetry, and aggregated analytics need specific treatment. “De-identified” or “aggregated” should not be accepted as a conclusion without a definition and appropriate restrictions.

Third-party material. The vendor should explain whether the service can generate content that resembles third-party protected material and what support it provides for infringement claims.

Confidentiality provisions should also cover prompts, uploaded files, generated responses, model feedback, support tickets, evaluation datasets, and system configurations. If the vendor uses human reviewers or subcontractors, the agreement should state how those parties are bound by confidentiality and access limitations.

Legal should also assess whether the vendor offers an indemnity for third-party intellectual property claims. If it does, review exclusions related to customer prompts, customer data, modifications, combinations with other systems, or failure to follow documentation. These exclusions can significantly reduce the practical value of the indemnity.

Accuracy, human review, and regulatory accountability

A vendor should not be treated as responsible for every business decision merely because its product generated a recommendation. At the same time, the customer should not accept all responsibility when the vendor’s design, documentation, or failure to disclose limitations contributed to an error.

The contract and implementation plan should define:

• What the AI system is designed to do.

• What it is not designed to do.

• Which outputs require human validation.

• Whether the vendor monitors accuracy, drift, bias, or unsafe behavior.

• How errors are reported and investigated.

• What testing data and evaluation methods support the vendor’s claims.

• Whether the customer receives notice about material performance changes.

• Which decisions are prohibited from being fully automated.

A practical control is to require human approval before an AI system completes a consequential action. This is especially important when the workflow affects payments, employment, eligibility, regulated advice, customer rights, financial reporting, or external communications.

Counsel should be careful with performance language. “Highly accurate” is not a measurable warranty. A stronger approach defines the relevant task, evaluation method, material failure threshold, remediation process, and customer right to suspend the feature if performance falls below an agreed standard.

AI governance frameworks can help structure this review. The NIST AI Risk Management Framework, for example, organizes risk management around governing, mapping, measuring, and managing activities. It does not replace legal advice or contractual negotiation, but it provides useful language for connecting risk identification to ongoing oversight.

Liability, indemnification, and insurance

AI risk should not be hidden inside a general limitation-of-liability clause. Legal teams need to test whether the proposed liability structure matches the consequences of the intended use.

Review whether the contract includes separate treatment for:

• Breach of confidentiality.

• Data protection violations.

• Security incidents.

• Intellectual property infringement.

• Fraud, willful misconduct, or gross negligence.

• Unauthorized use of customer data.

• Regulatory fines or investigation costs, where legally recoverable.

• Failure to meet critical service obligations.

A single low liability cap may be unreasonable when the vendor processes sensitive data or controls actions in a critical workflow. The appropriate structure depends on the use case, bargaining position, insurance coverage, and available safeguards, but the analysis should be explicit rather than automatic.

Ask for evidence of relevant insurance, including cyber liability, technology errors and omissions, and professional liability where applicable. Insurance does not replace contractual protection, but it provides evidence about how the vendor finances certain risks.

Indemnities also require close reading. Confirm whether the vendor will defend claims, pay covered losses, control the defense, and provide assistance. Check whether the indemnity covers AI-generated output, training data claims, model-related infringement, and the vendor’s use of subprocessors.

Model changes, subprocessors, and the right to object

AI services change more frequently than traditional software. A provider can change the underlying model, inference infrastructure, content filters, retention behavior, or subcontractors without changing the product name.

The contract should therefore define a material change and establish notice, testing, objection, and termination rights. A material change might affect data location, training use, security controls, output behavior, supported features, regulatory status, or the customer’s compliance obligations.

Legal should request:

• A current list of subprocessors and their functions.

• Advance notice of new subprocessors.

• A right to object when a change creates material risk.

• Notice before changing data-use or retention practices.

• Commitments to maintain equivalent protections after a model change.

• A transition period for testing or migration.

• Termination rights if the customer cannot reasonably accept the change.

This is where governance becomes operational. A contract that gives notice but no meaningful remedy does not provide much control. The customer needs a process for deciding whether to accept a new model, test it in a sandbox, restrict its use, or exit the service.

Audit rights, records, and evidence of compliance

Audit rights should be proportionate and practical. A vendor may not allow unrestricted onsite inspections of a shared cloud environment, but it should provide credible evidence and reasonable cooperation.

Useful evidence can include security reports, penetration-test summaries, control descriptions, compliance certifications, subprocessor information, data-flow diagrams, incident records, and answers to focused questionnaires. For a high-risk deployment, the customer may need additional testing rights or a right to commission an assessment under defined conditions.

The contract should also clarify ownership and access to operational records. Depending on the workflow, relevant records may include:

• User identity and access events.

• Prompts and retrieved source references.

• Model or feature version.

• Output and human review decision.

• Tool calls and resulting actions.

• Exceptions, overrides, and incidents.

• Retention and deletion events.

Auditability matters because an organization may need to explain how a decision was reached, investigate an incident, respond to a regulator, or prove that a human reviewed an output. Logging everything is not automatically correct, particularly where logs contain personal or confidential information. The record design should balance traceability with data minimization.

Termination, migration, and exit assistance

Legal approval is incomplete without an exit plan. The organization should know how to retrieve its data, disable integrations, revoke access, preserve required records, and move to another provider.

The contract should state:

• What data is exportable.

• Which formats are available.

• Whether prompts, outputs, metadata, configurations, indexes, and logs are included.

• How long export remains available after termination.

• When the vendor must delete remaining data.

• How deletion is certified.

• Whether transition support is available.

• What happens to custom models, prompts, workflows, and evaluation assets.

Portability is particularly important when an AI workflow includes proprietary prompt libraries, retrieval indexes, business rules, or tool connections. Exporting raw documents may not be enough to recreate the system elsewhere.

If the vendor refuses to explain deletion or migration, legal should treat that as a material approval concern. Switching costs become a governance risk when the organization cannot verify what remains in the vendor environment or reproduce essential controls with another provider.

A practical legal approval framework

Legal teams can make the review more consistent by assigning one of three outcomes to each issue:

The approval record should identify the business owner, data owner, security reviewer, privacy reviewer, legal reviewer, intended users, connected systems, and escalation path. It should also specify whether the review applies only to one feature or to the vendor relationship as a whole.

This prevents a common mistake: approving an AI vendor once and treating every future capability as pre-approved. A new agent, model, connector, data class, or autonomous action can require a fresh review even when the supplier remains the same.

How much does AI vendor due diligence cost?

AI vendor due diligence costs depend on the use case, data sensitivity, contract complexity, regulatory exposure, and amount of technical validation required. A low-risk tool using non-confidential information may need a focused questionnaire and contract review, while an AI agent connected to regulated or sensitive systems requires privacy analysis, security evidence, testing, negotiation, and ongoing governance.

The cost of review should be compared with the cost of an uncontrolled data disclosure, invalid automated decision, service outage, regulatory investigation, or difficult vendor exit. Legal teams can control effort by using risk tiers, reserving deep diligence for higher-impact deployments, and reusing approved evidence where the product and processing conditions remain unchanged.

If the organization needs help connecting legal requirements to workflow controls, contact Versich to discuss an AI implementation and governance approach.

Conclusion

AI vendor approval is a legal and operational decision, not a procurement checkbox. The strongest review verifies how the system handles data, what the vendor can change, who owns the resulting content, how errors and incidents are managed, and whether the organization can leave without losing critical records or controls.

Legal teams should connect every material promise to evidence, contract language, an accountable owner, and a practical remedy. When a vendor cannot explain its data flows, model behavior, security boundaries, or exit process, the right response is to pause approval until those gaps are resolved. A disciplined AI vendor due diligence process protects the organization before signature and creates the governance foundation needed for responsible use after launch.