How to Write an AI RFP (With a Template)

An AI RFP is a normal software RFP plus seven specifications that normal software RFPs never contain: the success metric and how it will be evaluated, what data the vendor gets and in what condition, whether model and provider choices stay yours, the guardrails and governance the system must satisfy, who owns the IP, who pays the run cost, and who owns the system in month two. Put those seven in the document and the bids become comparable. Leave them out and you get five proposals describing five different projects at five different prices, with no defensible way to pick one.

Traditional RFP templates fail here because they assume deterministic software with near-zero marginal running cost. AI is neither: output quality is probabilistic, so "done" has to be defined as a measurement rather than a feature list, and every request costs money forever. According to KPMG, 2026, only 26% of enterprise leaders report full, real-time visibility into what their AI systems cost to operate. An RFP that never asks bidders for a monthly run-cost number is how an organization lands on the wrong side of that figure – the number still exists, it just arrives later, as an invoice nobody forecast.

What does an AI RFP need that a software RFP doesn't?

Here are the seven AI-specific sections, what each one must actually specify, and the shape of the weak bid you get when the section is missing. Read the right-hand column as a diagnostic: proposals that look like these mean the gap is in your document, not in the market.

What sections should an AI RFP include, in order?

Copy this outline into your document. Twelve sections in this sequence, because each constrains the next: a vendor cannot price the work until they know the data, or scope the data work until they know what "good" means.

1. Organization and context – who you are, the business unit buying, and who signs.
2. Problem statement – the workflow as it runs today, in plain language, with volumes. Not the solution you imagine.
3. Success criteria – the metric, the target, the measurement method, the owner. The most important page in the document.
4. Scope: in and out – an explicit exclusions list. Everything you leave ambiguous becomes a change order.
5. Data – sources, systems of record, volumes, formats, quality, sensitivity, access mechanism, and who prepares it.
6. Technical constraints – existing stack, latency budget, data residency, deployment target, providers you cannot use.
7. Evaluation and quality requirements – the eval set, the acceptance bar, regression testing, and pre-release gates.
8. Guardrails, security, and governance – failure handling, human-in-the-loop points, logging, retention, no-training clause, applicable frameworks.
9. Commercial terms – pricing model, build price, twelve-month run cost, payment milestones tied to acceptance.
10. Ownership and exit – IP schedule, account ownership, handoff artifacts, and what happens if you part ways.
11. Vendor questions – the specific written responses you require, each with a page limit.
12. Process and timeline – Q&A window, response deadline, evaluation weights, shortlist date, decision date.

How do you write success criteria a vendor can bid against?

Write four elements: a business metric, a numeric target, a measurement method, and a named owner. "Reduce average handle time on tier-one support tickets by 30%, measured against a held-out set of 500 historical tickets scored by two named reviewers, signed off by the head of support before go-live" is biddable. "High accuracy" is not.

The measurement method matters as much as the target, because in AI the test set is the contract. Say who builds it – you, the vendor, or jointly – and say it is held out, meaning nobody tunes against it. Then state the acceptance rule: what score, on what set, judged by whom, before final payment releases. If you cannot describe the test, you have not defined the purchase. Our guide to evaluating and testing AI agents covers how to build that set well enough to survive a dispute.

What must the RFP say about your data?

Tell the truth about it. The most expensive omission in AI procurement is an RFP that describes data as clean, labeled, current, and reachable through an API when it actually lives in three systems, one of which nobody has admin access to. Bidders price the described world; you live in the real one, and the delta shows up as change orders in week five.

Specify: the source systems and how the vendor gets in, volume and format, how far back it goes, known quality problems, what fraction is labeled, what personal or regulated data is present, retention and residency rules, and – the line most RFPs miss – who prepares the data and whose budget pays for it. Then require bidders to state their data assumptions and to price discovery separately if they need it. A vendor who asks hard questions during the Q&A window is doing the job; one who bids confidently without asking any has not read it.

How do you protect flexibility, IP, and run cost?

Flexibility. Do not name a model in the RFP. Specify the outcome plus the constraints – latency, cost ceiling, residency, barred providers – then make bidders justify their model choice and describe a provider swap. The answer you want is an abstraction layer with pinned model versions, so switching is a configuration change and a re-run of the evals; the answer that should worry you is an architecture that only exists inside one vendor's platform. Our guide to avoiding AI vendor lock-in lists the clauses that keep this real.

IP. Enumerate it rather than gesturing at it: source code, prompts and templates, evaluation sets and labels, retrieval indexes, fine-tuned artifacts trained on your data, documentation, and cloud and provider accounts in your name. State that your data will never train the vendor's or a provider's models. Require bidders to list any carve-outs for pre-existing tooling in their response, with license terms, so you compare them side by side rather than discovering them in redlines.

Run cost. Ask for a monthly figure at a stated volume – say, 50,000 requests – broken into inference, retrieval or vector storage, observability, and hosting, plus the same figure at ten times that volume. The second number reveals whether the architecture scales economically. Then ask who pays it, from which budget line. A full picture of what changes after launch is in the total cost of ownership of an AI system.

How should you score the bids?

Publish the weights inside the RFP. Bidders write to the rubric, which is exactly what you want: comparable answers on the dimensions you care about instead of five essays about different things. Score each criterion independently, and score everything before you open the pricing, so a low number cannot halo the evaluation.

Which required questions separate real builders from demo-ware?

These belong in the RFP as written responses, not sales-call conversation, because written answers are scoreable, comparable, and attached to the contract. Give each a half-page limit.

• "Describe an AI system you took to production, and what broke in the first 90 days." A team that has shipped names a specific incident and a specific fix. A team that has not will describe a launch.
• "How would you measure quality on our problem, and what would you refuse to ship on?" The second half is the test. Real builders name a floor they will not go below.
• "What in this RFP would you push back on?" Every real RFP contains at least one bad assumption. A bidder who finds none has either not read it or will not tell you things you dislike.
• "What is the monthly run cost at our stated volume, and at ten times it?" Vendors who have operated systems answer in minutes; vendors who have only built them go quiet.
• "What does handover look like if we end the relationship?" Ask for the exit story before you sign. Teams confident in their work make leaving easy.

What should you do before you send it?

Shortlist first. Three to five vendors, each screened with a short call and two live production references, gets better proposals than a public blast, which mostly filters for firms with dedicated proposal teams rather than production engineers. Cap responses at roughly 15 pages, run one shared written Q&A round so every bidder sees the same clarifications, and publish your dates. If you want the interview layer that follows the document, the 20 questions to ask an AI development agency covers the live call, and the red flags to watch for covers what to do when an answer goes vague.

A good AI RFP is a forcing function on your own side: you cannot ask a vendor to hit a number you have not chosen, prepare data you have not audited, or hand back IP you never defined. Write those decisions down and vendor selection becomes almost mechanical. That is the document we ask buyers to bring us – see how we scope, evaluate, and ship production AI on our services page. If you are still choosing between an agency, a studio, and in-house, the full buyer's guide to choosing an AI development company walks through that decision first.