TL;DR & Quick Summary
A good RFP for AI development does one job: it makes every bidder show how they would deliver the same outcome. It describes the problem, the success measure, the data you can share, the evaluation you will run and the ownership you expect. It then asks specific questions that separate firms that have shipped AI from firms that have only demoed it.
Start with the decision and the measure, not the technology
Share a representative sample of data, under a confidentiality agreement
Ask for the evaluation method and two or three real test cases
Set ownership terms before the bid, not after
Score every bid on the same criteria, weighting production experience above presentation polish
Key Takeaway: The RFP is a test of how a vendor thinks. The clearer your problem and measure, the easier it is to see who understands the work.
Get Started: Want help drafting one? Schedule a strategy call with Cogniq AI, or see how we approach custom AI development.
Why Most AI RFPs Produce Weak Bids
Vendors respond to what the RFP asks for. If the RFP lists features and asks for a "cutting-edge AI solution", it will get a list of features and a claim to be cutting-edge. Three things commonly go wrong:
- No success measure. Without a baseline and a target, every bid promises "improved efficiency", and you cannot compare them.
- Hidden data realities. The RFP assumes clean data. The first month of the project reveals it is not, and the price rises.
- No evaluation method. Nobody says how quality will be judged, so the vendor who demos best wins.
A well-written RFP fixes all three.
Section 1: The Problem and the Decision
State the business problem in two or three sentences, then name the decision it should change. For example: "Support agents spend about 40 percent of their time answering order-status questions. We want customers to get those answers without waiting, and agents to spend that time on complex cases."
Include what is out of scope. Scope exclusions are as useful as inclusions, because they stop bids from quietly expanding the project.
Section 2: The Success Measure
Give a baseline and a target for one or two measures you can track:
- Resolution rate, cost per resolved request, forecast error, time to decision or similar
- The current value, measured over a recent period
- The target you expect and the date by which it should be reached
If you cannot measure the baseline yet, say so and ask bidders to propose how they will measure it. That question alone separates firms who think about outcomes from firms who think about outputs.
Section 3: Data and Systems
List the data sources, the systems they live in and the access you can provide. Be honest about quality: missing records, inconsistent fields and known gaps are far better disclosed in the RFP than discovered in week six.
Share a representative sample under a confidentiality agreement, not production data. Anonymised or synthetic records are usually enough for a credible proposal. Ask bidders to state what data they would need beyond the sample and how they would obtain it.
Section 4: Constraints
Name the constraints that will shape the design:
- Privacy and data residency requirements
- Security reviews and approved vendors
- Systems that cannot be changed, and systems that can
- Actions the AI may never take on its own, such as refunds above a limit or any change to safety-critical records
- Brand and tone rules for customer-facing output
These are where good bidders show judgement. They will name risks you had not considered and say how they would handle them.
Section 5: Evaluation Method
This is the most important section, and the one most RFPs omit. Describe how you will judge quality:
- The test set you will use, with a minimum number of real examples
- The metrics: accuracy on the test set, failure rate, escalation quality, latency and cost per request
- The release rule: what must be true before the system goes live
- How you will test edge cases, permissions and misuse
Ask bidders to describe their approach to two or three of your real examples, in writing. Judge their reasoning, the failures they anticipate and the team they name. A bid-specific demo tells you little about production behaviour.
For the design of evaluation itself, our AI agent evaluation framework sets out what a credible test set contains.
Section 6: Commercial Terms and Ownership
Set the terms before the bid so no one prices in surprises:
- Ownership: your company owns the code, repositories, cloud and model-provider accounts, evaluation test set, documentation and data pipelines from day one
- Accounts: the vendor works inside accounts you own, not its own
- Handover: a defined transition period, with named deliverables and the internal people who will receive them
- Pricing model: fixed price for a defined scope, or time and materials with a cap, and what happens if scope changes
- Running costs: who pays for model usage, hosting and support after launch, and how it is estimated
Avoid proprietary platforms that only the vendor can operate. If the vendor insists, ask what it would cost you to leave.
Section 7: The Questions Each Bidder Answers
End with a short list of questions every bidder must answer in writing. These are where you separate experience from marketing:
- What broke in production in the first month of your last AI system, and what did you change?
- How did you measure quality before release? Show the test set structure.
- Describe a case where the model was confidently wrong. How did the system catch it?
- Who would maintain the system after launch, and what would you need from our team?
- What would you do differently on this project, given what you know about our data?
- What do we own at the end, and what would it cost us to move the system elsewhere?
Experienced teams answer with specifics: names of failures, numbers, the trade-offs they chose. Teams that have only demoed talk about models, features and frameworks.
Sample Test Cases to Include
The test cases are the most useful thing you can put in an RFP, because they turn "we can do AI" into a claim you can check. Include 10 to 20 real examples, anonymised, in a sample file, and mark each with the expected outcome. A good mix covers:
- Typical requests, the bulk of the work, where the right answer is clear
- Missing information, where the correct response is to ask a question or escalate
- Conflicting records, where two systems disagree and the system must say so
- Permission boundaries, such as a request for another customer's data, which must be refused
- Out-of-scope requests, which should be handed to a person
- Actions requiring approval, where the system must stop and wait
Ask every bidder to explain what their system would return for each case and why. A firm that has built production systems will talk about failure modes unprompted. A firm that has only demoed will show the happy path.
Scoring the Bids
Score every bid against the same criteria, with weights agreed before the responses arrive:
| Criterion | Suggested weight | What good looks like |
|---|---|---|
| Understanding of the problem and measure | 15% | Restates the decision and the target, and names risks |
| Approach and evaluation method | 25% | Concrete test plan, edge cases, release rule |
| Production experience | 25% | Named systems shipped, honest account of failures |
| Team and handover | 15% | Named people, involvement of your team, clear transition |
| Commercials and ownership | 20% | Clear scope, ownership terms, transparent running costs |
These weights are a starting point. The principle is that presentation polish carries little weight. A bid that shows its reasoning should beat one that shows a slick demo.
Before you send the RFP, narrow the field. Our guide on how to shortlist AI agencies for an enterprise build covers the filters and evidence to use.
How Long to Give Bidders
Two to three weeks is typical for a bid that requires a method and a plan. Shorter deadlines produce generic responses. Longer ones slow your decision without improving quality. If you need a firm estimate, ask for a short paid discovery phase: a fixed bid without discovery carries the risk the vendor will cut scope later, or raise the price in the first month.
Common Mistakes
- Writing a feature list instead of a decision. Vendors will build features you do not need.
- Sharing production data too early. It exposes you to firms you may not hire.
- Leaving evaluation out. The winning bid will be the best demo, not the best system.
- Discovering ownership terms after signing. Agree them before the bid, so they are part of the price.
- Comparing totals without scope. A cheaper bid that excludes testing, handover or running costs is not cheaper.
Conclusion
A good AI development RFP describes the decision and the measure, shares a representative sample of data, sets out how quality will be judged, fixes the ownership terms, and asks questions only experienced teams can answer well. Score every bid on the same criteria. Done that way, the RFP tells you who understands the work, not just who presents best.
Schedule a strategy call with Cogniq AI to review your draft RFP or scope the first project, or explore our custom AI development services.
