An AI RFP checklist

The short answer

Specify the decision you want improved and the number it should move. Do not specify the technology. The moment an RFP names a model, a framework or an architecture, you have constrained the solution to what you already imagined and invited everyone to agree with you.

The purpose of the document is to produce proposals you can actually compare. Most produce eight brochures that cannot be compared at all.

Why standard IT templates fail here

Traditional procurement assumes you can specify the deliverable in advance: these features, this integration, this SLA. That works when the outcome is deterministic.

With AI, the honest answer to what it will do is a range that narrows as you learn what the data supports. An RFP that demands certainty upfront gets certainty back, and it will be fictional, because the vendors willing to promise it are the ones who have not thought about it.

So ask for the method and the evidence, not for guarantees nobody can make.

Specify the decision, not the technology

Write down where the decision happens today, who makes it, how often, what information they use, and what a wrong call costs. That is the brief.

Then state the number you want to move, its current value, and how it is measured today. If you cannot supply that, say so explicitly, because it changes the first phase for everyone bidding and hiding it just produces incomparable proposals.

Evaluation and acceptance

Ask how correctness will be measured, who defines what a good answer is, and what happens when the number drops after launch. Require a specific method rather than a commitment to quality. The vocabulary of a real answer is in LLM evals.

Define acceptance in terms of the outcome metric and an evaluation threshold, not in terms of features delivered. Feature based acceptance is how you end up signing off a system that works exactly as specified and helps nobody.

Data and access

Ask what data they need, in what form, and what they will do if it is incomplete or contradictory, because it will be. Ask how they handle permissions, and specifically whether the requesting user's rights are carried through to retrieval.

State your own constraints honestly: what cannot leave your environment, what is regulated, which systems have no API. Hiding these until contracting is the most reliable way to produce a repricing conversation in month two.

Ownership and exit

Require that code is delivered into your repositories continuously, not at the end. Ask what you retain if you terminate early. Ask what components are proprietary and what happens to them.

And ask for the handover plan explicitly: who on your team will be able to operate this, and what makes that true. A system your people cannot run is a subscription you did not know you were signing.

Pricing structure to request

Ask for pricing per phase and per use case rather than per hour, with the discovery phase priced separately and required to end in a production price. Ask for the expected monthly running cost at your volume, not at demo volume, and ask what drives it. The buckets are in what it costs.

Ask what is excluded. The gap between what is quoted and what is required is where most budget overruns live, and the question surfaces it before you sign rather than after.

Questions that separate the field

Add these verbatim. What is running in production today that you built for a client, and for how long. Describe an engagement where the result was worse than expected and what you changed. Who specifically will do the work and will they still be here in month four. What would make you tell us not to do this project.

That last one is the most useful question in any AI RFP. A vendor willing to describe when you should not buy is demonstrating the judgment you are actually hiring. More on reading the responses in how to choose a partner.

A scoring rubric

Score each response one to five on: evidence of comparable production work, clarity of the evaluation method, realism about integration, ownership and exit terms, pricing structure aligned to outcomes, quality of the questions they asked you, and a specific date something is live.

Weight the first three double. Presentation quality correlates with nothing, and the strongest predictor of a good engagement is how precisely a vendor talks about the parts that are hard. That is the standard we hold ourselves to when we build production AI, end to end.