Law firms are accustomed to reviewing vendors for security, confidentiality, privacy, availability, and contractual risk. AI adds another layer: the visible product may not reveal which models, providers, data flows, and settings are actually involved.
A vendor can appear mature and secure while still leaving important governance questions unanswered. The issue is not necessarily misconduct. It is that traditional vendor review was not designed for products whose behavior can change through model routing, feature releases, and configuration.
The right AI vendor question is not only, “Is the product secure?” It is also, “What happens to our information, through which systems, under which settings, and when those systems change?”
01 · The Review Gap Why standard vendor diligence can miss the real AI risk
Traditional diligence often focuses on encryption, access controls, certifications, incident response, business continuity, and contract terms. Those remain important.
AI systems add questions about model providers, model improvement, prompt and file retention, automated routing, generated outputs, training permissions, subprocessors, data residency, and administrative controls.
A vendor may answer a high-level question accurately while leaving the firm without enough information to evaluate a specific feature or configuration.
02 · The Questions What law firms should ask before approving an AI capability
What is retained?
Are prompts, files, outputs, metadata, logs, or conversation histories retained, and for how long?
What is used for training?
Can firm information be used to train, improve, evaluate, or develop models, products, or related services?
Which model providers are involved?
Does the vendor operate its own model, rely on third parties, or route work among several providers?
How does model routing work?
Can requests move between models based on task, cost, performance, region, availability, or product tier?
Which subprocessors receive data?
Which outside entities may process firm information, and can that list change by feature or geography?
Where is data processed?
What data-residency, regional-processing, or cross-border considerations apply to prompts, files, outputs, and logs?
Which controls can administrators enforce?
Can the firm restrict models, disable features, control sharing, manage connectors, and enforce retention settings?
How are material changes communicated?
Will the firm receive notice of model changes, new subprocessors, altered retention, or significant feature releases?
03 · Evaluating the Answers A response is useful only if it is specific enough to support a decision
Distinguish default settings from available settings
A vendor may offer strong enterprise controls that are not enabled by default. The firm needs to know both what the product can do and how its own environment will actually be configured.
Distinguish contractual promises from technical behavior
Contract language may state that customer data is not used for training, while logs, metadata, or certain features are handled differently. The firm should understand the operational detail behind the assurance.
Distinguish the core product from optional features
Connectors, plug-ins, agents, browser tools, transcription, analytics, or third-party integrations may introduce additional processors and data flows.
Distinguish the vendor from the model provider
The vendor may control the user relationship while relying on another company for model processing. Responsibility, notice, retention, and contractual protections may be split across that chain.
Vendor approval should attach to the relevant product, plan, model, configuration, and use case—not merely to the company name.
04 · Ongoing Risk Why vendor approval cannot be a permanent one-time decision
AI products change rapidly. A vendor can introduce new models, agents, connectors, integrations, or data-handling options without requiring the firm to purchase a different product.
That does not mean every update requires a complete reassessment. It does mean firms should identify which changes are material enough to trigger review.
- A new model provider or automatic routing path.
- A change in retention or training-use terms.
- A new connector that accesses firm repositories.
- A new agent or automated-action capability.
- A material change in subprocessors or data location.
- A configuration change affecting access, sharing, or confidentiality.
- A new intended use involving more sensitive information or higher-consequence work.
05 · Practical Response How to create a useful AI vendor review process
Five practical steps
Define the intended use first
Review the vendor in the context of the information, workflow, and legal task the firm intends to support.
Document the actual plan and configuration
Record the product tier, model options, retention settings, administrative controls, and enabled features.
Preserve evidence behind the decision
Keep relevant contract terms, vendor responses, security materials, configuration records, and approval notes.
Set conditions and boundaries
Define permitted uses, prohibited information, required human review, client restrictions, and escalation rules.
Review material changes
Reassess when the model, provider, routing, retention, configuration, feature set, or intended use changes materially.
Conclusion Good vendor review follows the information, not just the logo.
AI vendor diligence should not become an endless technical investigation. The goal is to identify the material facts that determine whether a capability is appropriate for the firm's intended use.
Firms that ask better questions can make more confident approvals, communicate clearer boundaries, and respond more credibly when clients ask how their information is protected.
The most important vendor question is not whether the company appears trustworthy. It is whether the firm understands the system well enough to make and maintain a responsible decision.
