AI vendor diligence.

Why this matters.

The professional-responsibility analysis around AI use, set out in ABA Formal Opinion 512 and the state opinions tracking it, runs on the contract terms more than on the marketing site. The ABA position, the NC State Bar position in 2024 FEO 1, and the sister-state guidance all reach the same operational point: an attorney inputting client material into a third-party AI tool must satisfy a reasonable-efforts confidentiality standard, and the contract is where the analysis lives.

Most legal-AI vendor contracts in 2026 have been drafted to be vendor-favourable in patterns that an attorney unfamiliar with software contracts will not always recognise. The patterns are consistent enough to catalogue. What follows is the catalogue, not legal advice on any specific contract.

Training data rights.

The single most consequential clause. The question: does the vendor have the right to use the customer\'s inputs (and outputs) to train its models?

Acceptable patterns:

• Vendor expressly disclaims any right to use customer inputs for training.
• Vendor uses inputs to train only with customer\'s separate, opt-in written consent (and the default is off).
• Vendor uses inputs only for the immediate provision of the contracted service, with no derivative or training use.

Unacceptable patterns:

• Vendor reserves a "perpetual, irrevocable, worldwide, royalty-free licence" to inputs (any phrasing close to that).
• Customer must affirmatively opt out of training, with the opt-out buried in the settings UI.
• Training rights granted "for service-improvement purposes" without a defined limit; this is a back door.
• Vendor distinguishes between consumer and enterprise plans on training rights, but the customer is on the consumer plan; assume the consumer-plan terms apply regardless of the marketing.

What to redline: the right to use inputs for training. Substitute language requiring written, opt-in customer consent for any non-service use of inputs.

Confidentiality and data use.

The vendor\'s confidentiality obligations as a data processor / vendor to the law firm. Distinct from training data rights; addresses what the vendor does with inputs even where training is disclaimed.

Acceptable patterns:

• Vendor commits to standard data-processor confidentiality (no use beyond service provision).
• Vendor commits not to disclose customer data to third parties absent legal compulsion.
• Vendor commits to commercially reasonable security controls (SOC 2 Type II is a minimum bar).
• Subprocessors disclosed; customer notified before changes.

Unacceptable patterns:

• Vendor reserves the right to share data with "affiliates" (often undefined) or "service providers" (also often undefined).
• Vendor disclaims any specific security commitments and points to a "best practices" page that can be changed unilaterally.
• Subprocessors not disclosed.

What to redline: any non-essential third-party disclosure. Pin the security commitment to a specific certification or audited control set.

Output ownership.

Who owns the AI tool\'s outputs? In legal practice this question has a particular cast: an attorney generating a draft motion using an AI tool needs the output to be the attorney\'s (and ultimately the client\'s) work product, not the vendor\'s.

Acceptable patterns:

• Customer owns the outputs.
• Customer has an unrestricted licence to use, modify, and distribute outputs without further vendor permission.
• Vendor expressly disclaims any IP claim over customer outputs.

Unacceptable patterns:

• Vendor retains IP in outputs.
• Customer\'s licence in outputs is "non-transferable" or terminates with the contract.
• Vendor reserves rights to similar outputs generated for other customers (this is inherent in generative AI; the question is whether the customer\'s outputs themselves are constrained).

What to redline: any vendor retention of IP in outputs. Customer ownership and a clean licence are the standard.

Retention and deletion.

How long does the vendor retain customer inputs and outputs? What happens when the contract ends?

Acceptable patterns:

• Inputs retained only for service-provision duration; deleted after session or after a short, defined window.
• Customer can delete data on demand via UI or API.
• On contract termination, vendor returns or deletes all customer data within a specified period (30 days is typical).
• Logs retained for security/audit purposes only, not for training, with a defined retention period.

Unacceptable patterns:

• "Vendor may retain customer data for as long as it deems necessary."
• No deletion-on-demand mechanism.
• On termination, no data return or deletion commitment.
• Backups exempt from deletion (some retention is unavoidable, but the contract should commit to a defined backup-deletion period).

What to redline: indefinite retention. Specify deletion timelines.

Indemnity and limitation of liability.

The most one-sided clause in most legal-AI vendor agreements. Vendor indemnifies customer for nothing; customer indemnifies vendor for everything; liability capped at three months of subscription fees.

Acceptable patterns (rare, worth pursuing):

• Vendor indemnifies customer against IP infringement claims arising from outputs.
• Vendor indemnifies customer for breach of the vendor\'s confidentiality obligations.
• Liability cap is at least 12 months of fees, with carve-outs for confidentiality, IP, and gross negligence.

Unacceptable patterns (the default):

• No vendor indemnity at all.
• Customer indemnifies vendor for "any claim arising from customer\'s use of the service" (so broad it covers the vendor\'s own breaches).
• Liability cap below 12 months of fees, with no carve-outs.
• "In no event shall vendor be liable for any indirect, special, incidental, or consequential damages, including loss of data" with no exceptions.

What to redline: ask for IP infringement indemnity (some vendors will give it, especially enterprise-tier). Carve confidentiality and gross negligence out of the liability cap.

Breach notification.

If the vendor\'s system is breached and customer data is exposed, when must the vendor tell the customer?

Acceptable patterns:

• Vendor notifies customer within 72 hours of confirming a breach affecting customer data.
• Notice includes scope of the breach and remediation steps taken.
• Vendor cooperates with customer\'s investigation and customer\'s downstream notice obligations to clients.

Unacceptable patterns:

• "Vendor will notify customer within a reasonable time."
• Notice deferred until "vendor has determined the cause" (which can take months).
• No cooperation commitment for the customer\'s investigation.

What to redline: set a hard 72-hour notice. Specify the contents of the notice.

Termination and data return.

Contract termination is the moment the customer\'s leverage is at its maximum (the cheque has not yet been written for the next year) and the vendor\'s incentive to retain customer data is at its highest (a customer leaving with the data is a customer harder to lock back in).

Acceptable patterns:

• Customer may terminate for convenience on notice; pro-rata refund of prepaid amounts.
• Customer can export all data in a usable format at termination.
• Vendor deletes customer data within a defined period after termination.
• Auto-renewal disclosed prominently; customer can opt out without onerous notice requirements.

Unacceptable patterns:

• "For-cause" termination only.
• Auto-renewal with 90-day notice required to opt out.
• No data export, or export only in a non-portable format.
• Vendor retains data after termination for vendor\'s own purposes.

What to redline: termination for convenience. A clean export. A defined deletion period.

Audit and compliance.

The customer\'s ability to verify the vendor is doing what the vendor said it does. Often missing entirely from off-the-shelf vendor terms; standard in enterprise contracts.

Acceptable patterns:

• Vendor maintains and provides on request its SOC 2 Type II report or equivalent third-party audit.
• Customer can request a security questionnaire response annually.
• Vendor commits to maintaining specified compliance certifications throughout the term.

Unacceptable patterns:

• No audit rights at all.
• Vendor "reserves the right to charge" for compliance documentation.
• Compliance commitments described on the marketing site but not in the contract.

What to redline: ask for a security questionnaire response and right to receive the SOC 2 report. Most enterprise vendors comply.

Modification of terms.

Can the vendor change the terms during the contract by posting an update on its website?

Acceptable patterns:

• Material changes require notice and customer assent (or right to terminate without penalty).
• Pricing changes require advance notice and apply only at renewal.
• Privacy policy and DPA changes require customer notice; material changes give termination right.

Unacceptable patterns:

• Vendor "may modify the agreement at any time by posting updated terms" with no customer assent or termination right.
• Continued use deemed acceptance.
• Pricing changes effective immediately on posting.

What to redline: the unilateral-modification clause. At a minimum, require notice and a termination-without-penalty right for material adverse changes.

Operational workflow.

The catalogue above is the substance. The workflow that converts it into a vendor-diligence file is what reduces the work to a fixed-time exercise.

• Read the contract once before signing. Twenty pages of vendor terms, read once, takes about an hour. The savings on the back end are substantial.
• Score against the catalogue. For each clause type above, mark whether the contract is acceptable, requires redline, or is a walk-away.
• Negotiate the top three. Most enterprise vendors will negotiate a small number of redlines. Pick the three highest-impact (typically: training rights, indemnity, breach notice).
• Document. Save the scored catalogue, the negotiated agreement, and the security materials in the vendor-diligence file. This is the artefact a malpractice carrier or state-bar disciplinary panel will want to see.
• Re-review at renewal. Vendor terms drift. The renewal moment is the moment to re-score.

When to walk away.

Most vendor contracts can be redlined into acceptability. A small number cannot. Three patterns are walk-away material for a small or solo firm with privileged client data.

• Training rights that cannot be removed. If the vendor\'s contract reserves training rights and the vendor will not negotiate them out, and the customer\'s use will involve privileged material, the contract is incompatible with the firm\'s confidentiality obligations.
• Liability cap below one month\'s fees with no carve-outs. The risk allocation is so one-sided that a single incident wipes the firm.
• Modification at vendor\'s discretion with continued-use-equals-assent. The customer cannot rely on any term in the contract; the contract is whatever the vendor says it is at the moment of dispute.

Walking away is a real option. There are usually three or four credible vendors offering similar capability. Switching cost is small; reputational and ethical exposure of a bad contract is not.

Citations and further reading.

Bar opinions on vendor diligence:

• ABA Formal Opinion 512: An Implementation Playbook (IXSOR reading). The federal Model Rules statement; treats vendor selection as a competence + supervision issue.
• NC State Bar 2024 FEO 1: What It Actually Requires (IXSOR reading). The Rule 5.3 application to third-party software vendors is the central NC analytical move.
• State Bar AI Opinions: A Comparative Tracker (IXSOR survey). For multi-state practices.

Standards referenced:

• SOC 2 Type II (AICPA / Trust Services Criteria). The minimum audit standard for vendor-security claims.
• ISO/IEC 27001. International equivalent; useful as a comparative reference.

This article is a pattern catalogue, not legal advice. Specific contract review is fact-specific and is properly performed by counsel with the actual contract in hand. Engage qualified counsel for advice on your firm\'s specific situation.

About the author.

Dan Hughes is the founder of IXSOR. Ex-BBC. Ex-Apple. Lifelong technologist. And most importantly: not an attorney. He writes about legal AI from the operational and infrastructure side, where the rules meet the machines. Reach: [email protected].