Procurement for AI in law firms: what actually gets scrutinised (and how to get through it without slowing product delivery)

Procurement for AI in law firms: a practical guide for pricing leaders

If you are a pricing director, head of client value, or legal operations director trying to buy an AI tool, procurement can feel like a separate project that starts the moment the business case is finally clear.

This guide is written for buyers inside law firms. It is deliberately practical: what typically happens, what gets asked, and what you can do to keep momentum without cutting corners.

A quick caveat

This is a generic blueprint. Every firm has its own policies, risk appetite, and internal politics. Some steps below may be skipped, reordered, or expanded depending on your firm and the type of tool you are buying.

What to expect: the procurement journey in plain English

Most AI purchases in law firms follow a pattern.

1. Business sponsor and use case: you have a clear workflow and a clear owner (often you).
2. Initial vendor screen: a demo, a short Q&A, and early comfort that this is not “AI for AI’s sake”.
3. Security and IT review: the deep dive on data, identity, hosting, and model providers.
4. Commercial and legal review: pricing, contract terms, risk allocation.
5. Pilot approval (sometimes): a controlled trial with clear scope and success criteria.
6. Go-live planning: access, training, data onboarding, and a plan for ongoing governance.

Your job as the buyer is not to become a security expert. It is to help the firm ask the right questions early, and make sure nothing stalls because information is missing.

Before you go to procurement: three things to do (that save weeks)

1) Write the one-paragraph use case

Procurement moves faster when the request is specific.

A good paragraph covers:

• Who will use the tool
• What decisions it supports (pricing, budgeting, matter planning)
• What changes in the day-to-day workflow
• What “success” looks like in 60 to 90 days

2) Agree what you are buying

Procurement questions vary hugely depending on category.

Try to label the product clearly:

• Workflow tool that uses AI (common for pricing and matter management)
• Data enrichment product (creates structured data from internal records)
• General-purpose assistant (usually triggers broader policy questions)

If you describe a controlled workflow with defined inputs and outputs, you reduce the feeling that the firm is buying an unpredictable “black box”.

3) Identify your internal counterparts

The fastest deals have a named counterpart in each area:

• Business owner (usually the buyer)
• IT/security owner (the person who will run point on due diligence)
• Procurement/legal owner (the person who negotiates terms)

If you do nothing else, get those three people into the loop early.

What procurement and security will scrutinise (and how to prepare)

Below are the questions that come up again and again. You do not need perfect answers. You need clear answers.

1) Data flow: “Where does our data go?”

Expect to be asked:

• What data is sent to the vendor (time narratives, matter metadata, documents)
• How it gets there (SFTP, API upload, manual upload)
• Where it is stored
• What systems process it
• What data leaves the environment (including to model providers)

Practical tip: ask the vendor for a one-page data flow diagram and a short narrative. If you can forward that internally before the first review call, you will move faster.

2) Identity and access: “Are we adding another login?”

Expect questions about:

• SSO support (SAML or OIDC)
• Role-based access controls
• Who can provision and deprovision users
• Whether multiple modules share the same authentication

Practical tip: if your firm cares about centralised access control (most do), push the vendor to be specific on how admin rights and user lifecycle management work.

3) Subprocessors and model providers: “Who else touches the data?”

Security teams want a list, not a story.

Expect to provide:

• Subprocessors
• What they do
• Where processing happens (region)
• Whether they retain data

Practical tip: if you get stuck here, it is usually because the vendor has not written it down in a buyer-friendly way. Ask for a subprocessor list and retention terms in writing.

4) Data retention: “What do you store, and for how long?”

This is often the make-or-break section.

Expect questions like:

• Are prompts stored?
• Are uploaded documents stored?
• Are model outputs stored?
• What is retained in logs?
• How is deletion handled on exit?

Practical tip: if your firm has strict policies, ask early whether the vendor can configure retention windows (and what the operational trade-offs are).

5) Data separation: “Is our data isolated from other customers?”

Expect the vendor to explain:

• Tenant isolation (technical and operational)
• How cross-tenant access is prevented
• Testing and monitoring for isolation failures

Practical tip: most buyers do not need the full architecture. You just need enough clarity to reassure security that isolation is real and actively tested.

6) Security assurance: “What evidence do you have?”

Common asks include:

• Security policies
• Pen testing summaries
• Certifications (for example, ISO 27001)
• Incident response process

Practical tip: certifications help, but they rarely remove the need for workflow-specific questions. Treat them as supporting evidence, not the finish line.

The commercial bits that slow things down (and how to anticipate them)

Even when security is comfortable, deals often stall on contract details.

Expect negotiation around:

• Liability caps
• Security incident timelines
• Audit rights
• Subprocessor change notifications
• Data deletion and exit support

Practical tip: ask procurement or legal what their “non-negotiables” are before the vendor redlines arrive. It prevents late surprises.

Pilots: how to keep them controlled and meaningful

Some firms will insist on a pilot. Others will not. When pilots work, they are deliberately narrow.

A useful pilot usually has:

• One practice area or one matter type
• A defined data set
• A short list of success criteria
• A named owner on your side and on the vendor side
• A weekly check-in

Practical tip: be explicit about what is out of scope (for example, broad integrations, firmwide rollout, or complex customisations). Procurement relaxes when there are boundaries.

A buyer-friendly “pre-read” checklist you can forward internally

If you want to accelerate the first procurement round, ask the vendor for:

• Data flow summary (one page)
• Hosting and architecture overview
• Subprocessor list
• Retention and deletion policy
• SSO and access control summary
• Pilot proposal (scope, success criteria, timelines)

Closing thought: procurement is part of adoption

Procurement can be frustrating, but it is also a forcing function.

If you can get clear on the use case, bring the right counterparts in early, and gather the key artefacts up front, you can usually move through procurement without slowing delivery.

And when you do, you often end up with something you can reuse: a documented, defensible blueprint that makes the next AI purchase easier.

‍