AI Vendor Agreements: What In-House Legal Teams Must Get Right

The legal industry's AI adoption story has reached an inflection point — and the defining challenge is no longer whether to use AI, but how to govern it without creating liability that dwarfs the efficiency gains. A 2024 survey by the Association of Corporate Counsel found that 73% of chief legal officers plan to increase AI investment in the next 12 months, yet fewer than one-third have a formal AI governance framework in place. That gap — between deployment velocity and governance maturity — is where careers, client relationships, and regulatory standing are being put at risk.

For in-house legal teams and the AmLaw 200 firms that serve them, the scramble is now on to build frameworks that can scale AI responsibly. That means tackling two distinct but intertwined problems: what your vendor agreements actually say (and what they quietly permit), and what your internal policies require of the humans and systems using these tools. Get either wrong, and the productivity gains from AI become a footnote in a much more uncomfortable conversation.

The Vendor Agreement Problem Nobody Is Talking About Loudly Enough

Legal AI vendors — from well-funded entrants like Harvey and CoCounsel to platform extensions like Lexis+ Protege and general-purpose tools like ChatGPT Enterprise — have made significant improvements to their standard terms over the past 18 months. But "improved" is not the same as "adequate for legal work."

The core issue is architectural opacity. Most SaaS legal AI tools present a relatively clean user interface while obscuring a complex infrastructure stack underneath — one that often involves multiple sub-processors, model providers, and data pipelines. When legal teams sign a standard subscription agreement, they're frequently consenting to terms that govern only the top layer of that stack.

What Standard DPAs Actually Say (and Don't Say)

A review of publicly available or commonly circulated data processing agreements from major legal AI vendors reveals several recurring gaps:

The training prohibition issue deserves particular attention. In 2023, several enterprise SaaS vendors updated their terms following public pressure to clarify that user data wasn't used to train foundation models — but the fine print still permitted use of "aggregated, anonymized" data for "service improvement." For legal work, where the value of information is often in its specificity and pattern, that distinction is almost meaningless.

The question in-house teams should be asking isn't "do you train on my data?" It's "what can you do with my data, ever, in any form?"

The Architecture Question That Changes Everything

Understanding what to ask vendors requires understanding how modern legal AI systems are actually built. This isn't a technical exercise — it's a governance necessity.

When a lawyer uses a SaaS legal AI tool to analyze a contract or search precedent, several things happen in sequence: the system retrieves relevant document chunks from an index, assembles those chunks into a prompt context, sends that context to a large language model (often GPT-4, Claude, or a fine-tuned variant), and returns the synthesized response. Each step involves a different infrastructure component — and each component represents a different data custody question.

In a typical SaaS deployment:

• The document corpus (your contracts, briefs, memos) lives on vendor infrastructure
• The retrieval index and vector store live on vendor infrastructure
• The agent orchestration layer — the logic that decides what to retrieve and how to assemble it — lives on vendor infrastructure
• The permissions and access controls are managed by the vendor
• The audit logs showing who queried what are stored by the vendor
• Chunks sent to the LLM are transmitted under the vendor's API agreement with the model provider

This matters because data risk in legal AI isn't just about what the LLM sees — it's about everything the system touches. A breach, a subpoena, a rogue employee, or a vendor acquisition changes the risk calculus for every layer of that stack.

Private AI deployment architectures flip this model. In a properly implemented on-premise or private cloud deployment, the document corpus, vector store, retrieval index, agent logic, permissions framework, and audit logs all remain on infrastructure the firm or enterprise controls. The only data that may leave is the minimal retrieved chunks needed to answer a specific query — sent to a chosen LLM API under the enterprise's own contractual terms with that provider.

This is not a semantic distinction. It means that even if a vendor relationship sours, a model provider changes its terms, or a regulatory inquiry arrives, the full evidentiary record and document corpus is under client control. The blast radius of any external dependency is bounded and defined.

For firms handling M&A due diligence, regulatory investigations, or cross-border litigation — workloads where the documents themselves are often the most sensitive assets — this architectural difference isn't a feature preference. It's a fiduciary question.

Building an Internal AI Policy Framework That Actually Works

Vendor agreements address external risk. Internal policies address the human layer — and this is where most legal departments are furthest behind.

The challenge is that AI policy in legal contexts sits at the intersection of professional responsibility rules, employment policy, data governance, and operational risk — four domains that rarely have the same owner. The result is either fragmented guidance (different memos from HR, IT, and Legal Ops, often contradictory) or no guidance at all.

Leading in-house teams are converging on a four-pillar framework:

Pillar 1: Approved Vendor Registry with Documented DPA Review

Every AI tool used for legal work — including general-purpose tools like ChatGPT or Copilot that lawyers may use informally — should be catalogued, reviewed, and either approved, conditionally approved, or prohibited for specific use cases. This isn't about blocking innovation; it's about ensuring that when something goes wrong, the response is "we had a process" rather than "we didn't know."

The registry should document: vendor name, data processing agreement version and review date, approved use cases, prohibited use cases (e.g., "not for matters involving EU data subjects" or "not for M&A due diligence"), and the internal owner responsible for annual review.

Pillar 2: Data Classification Mapped to AI Tool Permissions

Not all legal work carries the same sensitivity, and AI policy shouldn't treat it as if it does. A tiered classification system — typically three to four levels, from publicly available information to highly confidential matter data — should map directly to which AI tools can be used for each tier.

For example:

• Tier 1 (Public / Non-sensitive): Any approved tool, including SaaS
• Tier 2 (Internal / Business confidential): Approved SaaS tools with reviewed DPAs
• Tier 3 (Client confidential / Privileged): Tools with reviewed DPAs and explicit data residency commitments, or private deployment
• Tier 4 (Regulatory-sensitive / Highly confidential): Private or on-premise deployment only, with full audit logging

This tiering approach — similar to frameworks used by financial services legal departments under FINRA and OCC guidance — gives practitioners a clear decision rule without requiring them to re-litigate vendor risk every time they open a new matter.

Pillar 3: Human Review Requirements for Client-Facing Output

Bar association guidance in New York, California, Florida, and Texas — as well as emerging guidance from the ABA — consistently requires that lawyers supervising AI-assisted work apply independent professional judgment to AI outputs before those outputs influence client advice or court filings. The specific rules vary; the underlying principle does not.

Internal policy should codify this as a workflow requirement, not just an aspirational standard. That means: AI-generated drafts are marked as drafts, reviewed by a qualified attorney before transmission, and the review is documented. For case search and research tools, it means treating AI-retrieved citations as leads to be verified, not authorities to be cited directly.

The 2023 Mata v. Avianca case — in which an attorney filed a brief citing AI-hallucinated case citations, resulting in sanctions — remains the canonical cautionary tale. It's not an edge case; it's a preview of what happens when human review requirements aren't enforced by process.

Pillar 4: Quarterly Audit Cycle

AI tools are not static. Model versions change, sub-processors are added, terms are updated. A policy that was adequate at signing may be inadequate six months later — and vendors are not uniformly proactive about surfacing these changes.

A quarterly audit cycle should cover: active vendor registry review, log-level spot checks ("who used this tool, for what matters, when?"), model version change review, and sub-processor update review. This cycle should have a named owner — typically Legal Ops or GC's office — and documented output.

What the Governance Gap Costs in Practice

The risk of inadequate AI governance in legal isn't primarily regulatory — though regulatory risk is real and growing, particularly for firms with EU clients under GDPR and the AI Act. The more immediate risk is professional.

Consider three scenarios that have either occurred or are plausible given current practice:

Privilege waiver through infrastructure exposure. A firm uses a SaaS legal AI tool to analyze privileged communications during litigation support. The vendor's terms permit storage of document chunks on infrastructure shared with other clients. Opposing counsel discovers this during discovery and argues that transmission to a third-party system constitutes waiver. The argument may not succeed — but litigating it costs $200,000 and delays the matter by four months.

Confidentiality breach through vendor acquisition. A legal AI vendor is acquired by a strategic buyer with interests adverse to one of the firm's major clients. The acquiring entity's terms of service, applied retroactively under an assignment clause the firm's team missed, permit broader data use. The firm discovers this six months post-acquisition.

Compliance exposure through model drift. A firm's AI tool is updated to a new model version that produces different outputs for the same regulatory analysis inputs. The change is logged in a vendor changelog but never surfaced to the firm's compliance team. Outputs used in regulatory submissions are later identified as inconsistent with prior submissions, triggering a regulatory inquiry.

None of these scenarios require malicious intent. They require only the combination of inadequate governance and the normal velocity of change in AI infrastructure.

The Emerging Standard: Sovereignty-Aware AI Architecture

Among the more sophisticated legal departments and AmLaw 200 firms, a new standard is emerging for what "responsible AI scaling" actually means in practice. It's not about refusing to use AI — the competitive and efficiency stakes are too high for that. It's about calibrating the architecture to the sensitivity of the workload.

For lower-sensitivity, high-volume tasks — document summarization, research drafts, internal memos — SaaS tools with well-reviewed DPAs are often appropriate and efficient. For sovereignty-critical workloads — M&A due diligence, regulatory investigations, cross-border litigation, IP prosecution — the governance standard is shifting toward architectures where the full agentic stack stays under client control.

This is the distinction that matters when evaluating solutions like RAGbase Legal for AI for law firms. The architecture keeps the retrieval index, vector stores, agent orchestration, permissions, workflows, and complete audit logs on the firm's infrastructure. What may be transmitted externally — only the minimal retrieved chunks needed to answer a query — travels under the firm's own API agreement with its chosen model provider. The full corpus and agent layer never leave.

That's not a marketing claim about never sending data out. It's an architectural fact about where custody lives and who controls the terms under which any data moves. For sovereignty-critical workloads, that distinction is the difference between a defensible governance position and an improvised one.

The firms and legal departments that will scale AI most successfully over the next three years aren't the ones moving fastest — they're the ones building governance infrastructure fast enough to match their deployment velocity. That means treating vendor agreements as legal instruments deserving the same rigor as client contracts, building internal policies that give practitioners clear decision rules rather than vague aspirations, and making deliberate architectural choices about which workloads require what level of data sovereignty.

If your team is currently evaluating AI governance frameworks or assessing vendor agreements for renewal, the most useful starting point is a workload-by-workload sensitivity analysis — mapping your actual matter types to the data custody implications of your current tool stack. The gaps that analysis reveals will tell you exactly where your governance framework needs to go next.