We respect attorney-client confidentiality. No tracking pixels in our emails.
Most enterprise legal AI RFPs fail because they use generic SaaS templates that miss the issues specific to privileged data, model transparency, and legal-specific SLAs. Here are 40 questions that do not.
Move from this guide to practical legal AI tool shortlists and comparison pages.
In 2025, a 200-attorney firm's legal operations team spent four months evaluating AI platforms, issued an RFP to seven vendors, and selected a platform — only to discover after contract execution that the vendor's model retained client query data for internal quality improvement purposes. The firm's general counsel had not asked about data retention for model training during the RFP process because the standard SaaS RFP template the team used had no such question. They had asked about data storage location, data encryption, and backup procedures — all important, all answered satisfactorily — but not about the specific question that mattered most for attorney-client privilege and bar compliance.
This is the problem with generic RFP templates applied to legal AI procurement: the legal context creates specific risks — privileged data, ethical obligations, model transparency requirements — that do not appear in standard enterprise software evaluations. The template below addresses those gaps with 40 questions organized by category, including for each the underlying concern and the red-flag answers that should give a procurement team pause.
Enterprise legal AI procurement occupies a unique position in enterprise software buying. The stakes are higher than generic software procurement because the data being processed is privileged, the users are licensed professionals with independent ethical obligations, and the outputs of the software can directly affect client outcomes and attorney licensure.
At the same time, the legal AI vendor landscape is less mature than enterprise software markets like CRM or ERP. Vendors range from established legal technology companies with decades of enterprise procurement experience to AI-native startups that may have sophisticated technology but limited experience with enterprise legal procurement requirements. The RFP process has to work for both types.
The 40 questions below are designed to surface the issues that distinguish legally appropriate enterprise AI platforms from those that create hidden risks. They are not designed to be exhaustive — your specific practice areas, jurisdictions, and security requirements will add questions — but they cover the issues that appear most frequently in post-procurement disputes and bar compliance analyses.
Note that these questions are designed for procurement of AI platforms that will process client matter data. Tools used purely for internal firm operations without client data (scheduling tools, HR software, etc.) do not require the full set of data handling and privilege questions.
Q1: Do you hold SOC 2 Type II certification? If yes, please provide the most recent audit report and auditor letter. Concern: Self-reported security claims are not verifiable. Type II (vs Type I) covers actual operation over a period, not just design. Red flag: vendor provides a Type I report, a "letter of attestation" that is not a full audit, or declines to share the report.
Q2: What is your encryption standard for data at rest and in transit? Is encryption applied at the individual record level or the storage level? Concern: Storage-level encryption protects against physical media theft but not against unauthorized access by vendor personnel or compromised credentials. Red flag: vendor cannot specify encryption standard (AES-256 is the baseline) or cannot distinguish between storage and record-level encryption.
Q3: Who within your organization has access to client data processed on your platform? What controls govern that access? Concern: Internal access controls are a primary attack vector. Red flag: vendor describes access as "limited to engineers" without specifying access logging, approval requirements, or audit procedures.
Q4: Describe your security incident response plan, including notification timelines. Concern: See our separate article on vendor incident response. Red flag: vendor does not have a written IR plan, describes notification as "prompt" without a specific number of hours, or cannot describe who in their organization is responsible for client notification.
Q5: Have you experienced any security incidents in the past 24 months involving client data? If yes, describe each incident, its scope, and your response. Concern: Incident history is more informative than incident-free claims. Red flag: vendor refuses to answer or claims no incidents ever — a more credible answer acknowledges minor incidents and describes how they were handled.
Q6: What is your penetration testing cadence, and will you share the executive summary of your most recent pentest? Concern: Annual pentests are the minimum standard. Red flag: vendor does testing less frequently than annually or declines to share any results.
Q7: Describe your employee background check and security training program. Concern: Insider threat is a significant attack vector for legal data. Red flag: vendor has no background check requirement for roles with data access.
Q8: What is your business continuity and disaster recovery plan? What is your documented RTO (recovery time objective) and RPO (recovery point objective)? Concern: Platform unavailability affects attorney workflow and deadlines. Red flag: vendor cannot state specific RTO/RPO figures or states figures above 24 hours for RTO.
Q9: Do you undergo external security audits beyond SOC 2? (ISO 27001, FedRAMP, etc.) Concern: Additional certifications provide corroborating evidence of security posture. Not required, but informative.
Q10: What is your process for securely deleting client data upon contract termination? Concern: Data persistence after contract end creates ongoing risk. Red flag: vendor cannot describe a deletion process, has a retention period beyond 90 days post-termination, or cannot provide a deletion certificate upon request.
Q11: Is client data inputted into your platform used to train or fine-tune your AI models? Please describe your data handling policy in writing. Concern: This is the single most important data handling question. Using client data for model training may constitute a disclosure under Rule 1.6. Red flag: vendor policy permits training data use without explicit client opt-out, or vendor cannot answer the question definitively.
Q12: Where is client data stored? In which geographic regions, and under which data residency framework? Concern: Data residency matters for GDPR compliance and for firms with client obligations around data location. Red flag: vendor cannot specify storage regions or stores data in regions incompatible with your client obligations.
Q13: How does your platform handle metadata associated with client queries and documents? Is metadata subject to the same retention and deletion policies as content data? Concern: Metadata (query patterns, document access logs) can reveal privileged information even without content. Red flag: vendor distinguishes metadata from content in its retention policy and applies less stringent controls to metadata.
Q14: Describe your data isolation architecture. Is client data logically or physically isolated from other customers' data? Concern: Multi-tenant architectures with inadequate isolation create risk of data bleeding between customers. Red flag: vendor cannot describe isolation architecture or describes only application-level (not infrastructure-level) isolation.
Q15: Do you have a sub-processor list? Will you contractually notify us before adding new sub-processors with data access? Concern: Sub-processors (cloud providers, analytics vendors) inherit data access risks. Red flag: vendor does not maintain a sub-processor list or requires only post-hoc notification of sub-processor changes.
Q16: What is your data retention schedule for different categories of data (documents, queries, usage logs)? Concern: Excessive retention creates ongoing risk. Red flag: retention periods significantly exceed operational necessity or vendor cannot specify retention schedules by data category.
Q17: Can you support a bring-your-own-key (BYOK) encryption model for our data? Concern: BYOK allows the firm to revoke vendor access to encrypted data. Relevant for highest-sensitivity deployments. Not a disqualifier if unavailable, but a differentiator.
Q18: How do you handle privilege review and work product protection for documents processed on your platform? Concern: The platform processing privileged documents needs to understand and respect that status. Red flag: vendor has no specific policy addressing privileged material or treats all documents identically regardless of privilege status.
Q19: What large language model or models does your platform use? Are they proprietary, licensed, or open-source? Concern: Model identity affects risk assessment, known limitations, and audit trail requirements. Red flag: vendor refuses to disclose any information about model architecture citing proprietary concerns — some disclosure is reasonable and appropriate.
Q20: What is the training data cutoff for your model(s)? How frequently are models updated? Concern: Outdated training data produces outdated legal information, particularly for regulatory and case law research. Red flag: vendor cannot state a specific cutoff date, or cutoff is more than 18 months in the past without a retrieval-augmentation layer.
Q21: Is your platform retrieval-augmented (RAG) or purely generative? If RAG, what databases does it retrieve from? Concern: Retrieval-augmented generation against authenticated legal databases significantly reduces hallucination risk. Red flag: purely generative platform without RAG for legal research applications, or RAG against non-authenticated sources.
Q22: What is your documented AI hallucination rate for legal citation tasks? How was this measured? Concern: Vendors should be able to characterize error rates. Red flag: vendor claims zero hallucinations or cannot provide any benchmark data on accuracy.
Q23: Does your platform provide citation provenance — links to the specific source text that supports each claim or citation? Concern: Provenance enables attorney verification of AI output. Red flag: platform does not provide source citations or provides citations without links to underlying text.
Q24: How does your platform handle topics outside its training coverage — does it abstain, flag uncertainty, or generate plausible-sounding responses? Concern: Confident generation in areas of uncertainty is the core hallucination risk. Red flag: vendor cannot describe uncertainty handling or implies the model does not produce uncertain output.
Q25: What are your native integrations with major legal practice management platforms? Concern: Integration depth affects adoption and workflow efficiency. Red flag: vendor has no native integrations and requires custom API development for all connections.
Q26: Do you offer an API? What is the API rate limit, and is API access included in the enterprise pricing tier? Concern: API access enables custom integrations and automation. Red flag: API is significantly restricted or priced separately at a level that makes integration cost-prohibitive.
Q27: What is your data migration process for importing existing documents and matter data? Concern: Data migration scope and cost is frequently underestimated. Red flag: vendor has no documented migration process or requires significant professional services for standard migrations.
Q28: Describe your SSO and identity management capabilities. Do you support SAML 2.0 and SCIM provisioning? Concern: Enterprise identity management is required for large deployments. Red flag: vendor does not support standard SSO protocols.
Q29: What document formats does your platform support natively? Concern: Legal documents come in PDF, Word, and various other formats. Red flag: limited format support requiring pre-processing before upload.
Q30: What is your process for providing audit logs of platform activity for compliance and e-discovery purposes? Concern: Ediscovery obligations may require production of AI usage logs in litigation. Red flag: vendor does not maintain audit logs or has logs that cannot be exported in standard formats.
Q31: Is pricing per-seat, per-matter, consumption-based, or firm-wide? Provide a detailed pricing matrix for our firm size.
Q32: What is included in the base pricing versus what is additional — API calls, storage, support tiers, training?
Q33: What are your annual price increase provisions? Is there a cap on year-over-year increases?
Q34: What are your contract termination provisions? Is there a penalty for early termination?
Q35: Do you offer volume discounts for annual prepay or multi-year commitments? What specific discount percentages apply?
For each pricing question, the red flag is ambiguity — pricing schedules that require a sales conversation to understand are pricing schedules designed to be negotiated rather than standardized.
Q36: What is your guaranteed uptime SLA? What credits apply if the SLA is not met?
Q37: What is your support response time SLA by severity level? Do you provide 24/7 support for Severity 1 issues?
Q38: Do you provide a dedicated customer success manager for enterprise accounts?
Q39: What is your product roadmap communication process? How much notice do you provide before deprecating features?
Q40: What is your customer reference policy? Can you provide references from law firms of similar size and practice area composition?
A 150-attorney AmLaw 200 firm used a version of this framework to evaluate five enterprise AI platforms over 12 weeks. The model training data retention question (Q11) immediately disqualified one vendor whose policy permitted use of client queries for model improvement. The SLA questions revealed that two vendors offered uptime guarantees below 99.5% — below the firm's internal threshold. Of the remaining two vendors, the proof-of-concept phase surfaced citation accuracy differences that were not apparent from vendor-provided benchmarks. The selected vendor was not the cheapest — but the procurement team was able to explain to firm leadership precisely why the selected vendor was worth the premium, using the documented evaluation framework.
Q: How long should an enterprise legal AI RFP process take?
A: Plan for 10-16 weeks for a thorough process: 2 weeks to distribute and receive RFP responses, 3-4 weeks for initial scoring and shortlisting, 4-6 weeks for demos and proof-of-concept, 2-3 weeks for final evaluation and contract negotiation. Compressed processes consistently produce procurement regrets.
Q: Should we use a third-party legal technology consultant for RFP evaluation?
A: For deployments above $100,000/year, a consultant with experience evaluating legal AI platforms adds significant value in technical evaluation and contract negotiation. The consultant fee is typically recovered in better contract terms.
Q: A vendor told us their proprietary architecture prevents them from answering our model transparency questions. Should we accept that?
A: No. Vendors can appropriately decline to share specific model weights or training methodologies, but they should be able to answer whether the model is retrieval-augmented, what the training data cutoff is, and what their measured accuracy rates are. These are operational questions, not intellectual property questions.
Q: How should we score RFP responses — equal weight per question or weighted by category?
A: Weight data handling and security questions at 2x standard weight for legal AI procurement. A vendor who cannot answer Q11 (training data retention) satisfactorily should be disqualified regardless of their scores on other questions.
Q: Is a proof-of-concept always necessary or can we skip it for well-known vendors?
A: Proof-of-concept is particularly valuable for legal AI because performance in your specific practice areas with your specific document types may differ significantly from vendor-provided benchmarks. Even well-known vendors should complete a 30-day PoC on representative matters before final selection.
Enterprise legal AI procurement fails when it applies generic SaaS evaluation frameworks to a context with specific legal requirements. The 40 questions above address the gaps: data handling for privileged information, model transparency for malpractice risk management, security documentation beyond certifications, and pricing clarity that enables accurate total cost of ownership analysis.
The single most important question in any legal AI RFP is Q11: whether client data is used to train or improve vendor AI models. This question directly affects attorney-client privilege preservation and bar compliance. A vendor who cannot answer it clearly, or whose answer is yes without opt-out, should be removed from consideration regardless of other merits.
Build a proof-of-concept requirement into your procurement process. Documented evaluation with your own matters is more protective — in both directions — than representations in an RFP response.
This article reflects independent editorial analysis. LawyerAI does not accept payment for editorial coverage. Tool scores are based on methodology described in Our 5-Dimension Methodology. Last reviewed: 2026-08-28.
