Legal AI RFP Template: Questions, Evidence, and Scoring

A useful legal AI request for proposal does not ask vendors to describe their innovation. It asks them to prove how a defined system behaves with your work, data, people, and constraints. The distinction matters. Broad promises are difficult to compare, while evidence requests create a record that legal, security, privacy, procurement, and practice leaders can test.

This template draws organizing ideas from the NIST AI Risk Management Framework, ISO/IEC 42001, the OWASP Top 10 for LLM Applications, and official material from MeitY. Those sources serve different purposes. Referencing them does not prove compliance, certification, or suitability.

What should happen before the RFP is issued?

Start with a one-page use-case statement. Name the users, tasks, source material, intended recipients, jurisdictions, systems touched, and decisions the output may influence. State what the system must never do. An RFP for public-law research should not look identical to one for privileged transaction documents.

Run this intake workflow:

1. Interview the people who perform the work today.
2. Map inputs, outputs, approvals, failure points, and manual fallback.
3. Classify information that could enter the service.
4. Identify professional, contractual, privacy, security, and records constraints.
5. Build representative tests with authorised or synthetic material.
6. Agree scoring weights and minimum gates before opening responses.
7. Assign an owner for every claim that requires verification.

The final step prevents attractive demonstrations from quietly changing the evaluation criteria. Use the legal AI accuracy evaluation method to design test cases, and the legal AI governance policy guide to connect procurement with approved use.

Which product and architecture questions belong in the RFP?

Ask the vendor to identify the exact product, features, model providers, deployment pattern, regions, integrations, and administrative controls in scope. “Enterprise grade” is not an architecture answer.

• Which models are used for each function, and can they change without notice?
• Which components are vendor-operated, customer-operated, or supplied by subprocessors?
• Where are prompts, files, embeddings, logs, backups, and support records processed?
• How are tenants and matters isolated?
• Can administrators restrict models, connectors, exports, sharing, and retention?
• What happens when a model, retrieval service, or integration is unavailable?
• Which functions can act on another system rather than merely draft an output?

Request a current data-flow diagram and responsibility matrix. During clarification, walk through one realistic file from upload to deletion. Note every copy, derived record, log, cache, and backup. A diagram that omits support access or telemetry is incomplete.

How should AI governance and accuracy be tested?

NIST AI RMF groups work around governing, mapping, measuring, and managing risk. Turn those verbs into evidence requests. Ask who owns model risk, how intended use and affected parties are mapped, which evaluations are run, and how findings change release or customer controls.

Require results relevant to your workflow, not a single generic benchmark. Test citation existence and proposition support, extraction coverage, conflicting documents, poor scans, long inputs, ambiguous instructions, multilingual material, and abstention when sources are missing. Keep a fixed test set and score the delivered configuration.

Do not average away a serious failure. A system that performs well overall but crosses a confidentiality boundary should fail the relevant gate.

Which security questions reveal meaningful controls?

Use OWASP’s LLM risks to ask about prompt injection, insecure output handling, sensitive-information disclosure, excessive agency, model denial of service, and supply-chain exposure. Also cover ordinary application security, because an AI feature still depends on identity, code, infrastructure, and operations.

Ask for evidence of authentication options, role design, encryption, secrets handling, secure development, dependency management, penetration testing, vulnerability intake, logging, incident response, recovery, and employee access control. Request the scope and date of any certification or assessment, plus exceptions relevant to the service. A logo on a trust page is not enough.

Test permission boundaries yourself. Can a user retrieve another matter, expose hidden instructions, cause a connector to exceed authority, or make rendered output execute unsafe content? Review the security questionnaire companion and Gotham’s security overview as starting points, then verify the configuration offered to you.

What privacy and information-handling questions should be asked?

Ask the bidder to complete a data inventory covering purpose, categories, roles, location, retention, deletion, training use, subprocessors, transfers, data-subject support, and incident handling. Obtain advice on applicable Indian law and current rules from authoritative sources, including India Code and MeitY.

Require plain answers to these questions:

• Is customer content used to train or improve any model, and under what setting or term?
• Can the customer set and verify retention by data type?
• How does deletion propagate to indexes, derived data, logs, and backups?
• Who can access content for support, and how is access approved and recorded?
• Can the service support legal holds, export, correction, and account closure?
• What notice precedes a new subprocessor, region, or purpose?

For higher-risk uses, run a documented impact assessment before the pilot. The legal AI DPIA guide provides a working structure.

How should implementation and service operations be evaluated?

Ask vendors to propose a bounded pilot with acceptance criteria, responsibilities, training, support, migration, and rollback. Require named assumptions. If success depends on pristine OCR, curated templates, or extensive customer labelling, that should be visible before pricing is compared.

Score operating fit separately from feature breadth:

Interview customer references about incidents, difficult migrations, support escalations, and actual reviewer effort. Prepared praise tells you less than how the vendor behaved when something broke.

How should commercial and contractual responses be compared?

Model the total cost for expected documents, tokens, storage, connectors, environments, implementation, support, and exit. Ask what causes overages and which controls prevent an unexpected bill. Compare like-for-like configurations.

The contract review should address confidentiality, security obligations, processing instructions, subprocessors, audit evidence, incident cooperation, intellectual property, service levels, change notice, suspension, liability, termination assistance, export, and deletion evidence. The data-processing agreement checklist can support that review, but counsel must adapt it.

Record each vendor exception in a decision log. A favorable price should not erase a failed minimum gate. Conversely, a request for a certification that does not cover the proposed service should not become a substitute for examining actual controls.

What does a defensible final scorecard look like?

Use a 100-point model only after mandatory gates are applied: functional fit 20, accuracy and review 20, security 15, privacy 15, governance 10, implementation 10, commercial and exit 10. Require evaluators to cite the response, document, or test behind every score.

Finish with four records: the scored matrix, unresolved-risk register, approval decision, and post-contract validation plan. Set triggers for reassessment when the model, feature, subprocessor, region, terms, integration, or use changes.

Teams comparing deployment models can read self-hosted versus SaaS legal AI, explore Gotham’s practice solutions, review legal workflows, or contact Gotham. The aim is not to buy the product with the longest questionnaire. It is to choose a configuration whose evidence supports a clearly bounded use.