Templates

AI development RFP template (with scoring sheet)

An RFP for teams that will build AI, not sell it: what to disclose about your data, how to specify quality and evals, and the questions that expose demo-only vendors.

By the Ryz Labs team · Updated October 2026

An AI development RFP asks vendors how they would build and run a specific AI system on your data, so it needs sections a normal software RFP leaves out: the state of your data, how quality will be measured with an eval set, security and personal data handling, cost per request, and how the system and its evals are handed over to your team. The strongest RFPs also ask who exactly will build it and what AI systems those engineers have put in production. The template below gives you the sections, the vendor questions and a weighted scoring sheet.

AI development RFP template

Use it alongside the general software development RFP template if you also need standard procurement sections. This one covers what is specific to AI work.

1. RFP sections to send to vendors

Section 1: The problem and the users

☐ The workflow the AI system changes, who uses it and how often
☐ How the task is done today, with its time, cost and error rate if you have them
☐ The decision or action the system's output feeds, and who is accountable for it

Section 2: Data readiness

☐ Data sources the system will use, their owners and formats (documents, tables, tickets, transcripts)
☐ Volume, age and quality issues you already know about
☐ Access status: approved, pending or not requested
☐ Permissions the system must respect (who may see which records)
☐ Labeled examples or expert reviewers available for building an eval set

Section 3: Model and quality requirements

☐ Approved model providers or deployment constraints (provider APIs, your cloud only, open-weight models)
☐ Quality bar in plain terms, and how you expect it to be measured
☐ Requirement for an eval set built from real tasks, run on every change
☐ Latency target and expected volume per day
☐ Cost per request or per task you are prepared to pay at expected volume

Section 4: Security, privacy and compliance

☐ Personal or sensitive data involved (PII, financial, health) and where it may be processed
☐ Retention rules for prompts, outputs and logs
☐ Prompt injection and data leakage testing expected before launch
☐ Limits on actions the system may take without human approval
☐ Standards the work must meet (for example SOC 2 controls, HIPAA, GDPR)

Section 5: Production and handoff

☐ Where the system runs (your cloud accounts and repos) and who operates it after launch
☐ Required tracing, monitoring and cost dashboards
☐ What is handed over: code, eval sets, prompts, runbooks, documentation and training for your engineers

Section 6: Team and timeline

☐ Team composition you expect to see proposed (tech lead, AI, data, backend, MLOps)
☐ Working hours and overlap with your team
☐ Milestones: proof of concept, pilot with real users, production
☐ Response deadline, shortlist interviews with proposed engineers, decision date

2. AI-specific questions every vendor must answer

#	Question	What a strong answer includes
1	Which engineers will build this, and which AI systems have they put in production?	Named or profiled senior engineers; production systems with users, not demos
2	What would you need from our data in the first 30 days, and what risks do you see in it?	Specific access requests and data risks tied to our sources
3	How will you build the eval set and decide when quality is good enough?	Real tasks, expert labels, automated evals in CI, a bar agreed before the build
4	Which models would you start with, and how would you switch if needed?	A reasoned choice plus a plan to compare models on our eval set
5	How will you estimate and control cost per request?	Measured cost on realistic volume; caching, routing or batching where it fits
6	How do you test for prompt injection and data leakage?	Concrete tests, including through retrieved documents and tool outputs
7	Where do our data and prompts go, and what is retained?	Data stays in our accounts or approved providers; retention stated
8	What is the path from proof of concept to production?	Gates with evidence: quality, security, cost, monitoring, rollout, ownership
9	What will our team own at handoff, and how will you transfer knowledge?	Code, evals, prompts and runbooks in our repos; pairing with our engineers
10	Show us a production AI system you built that failed in some way. What did you change?	An honest example with the fix, not a perfect record

3. Proposal scoring sheet

Criterion	Weight	Vendor A (1-5)	Vendor B (1-5)	Vendor C (1-5)	Notes
Proposed team: seniority and production AI experience	25%	[ ]	[ ]	[ ]	[ ]
Data plan and risks identified	15%	[ ]	[ ]	[ ]	[ ]
Evaluation approach and quality bar	20%	[ ]	[ ]	[ ]	[ ]
Security, privacy and data handling	15%	[ ]	[ ]	[ ]	[ ]
Production path, operations and handoff	15%	[ ]	[ ]	[ ]	[ ]
Cost clarity (team cost and cost per request)	10%	[ ]	[ ]	[ ]	[ ]
Weighted total	100%	[ ]	[ ]	[ ]	Shortlist two; interview their proposed engineers

Use this template

How to use this AI RFP template

Write section 1 with the business owner and section 2 with whoever owns the data. Vague data sections produce vague proposals.
Request data access approvals before you send the RFP, so the chosen vendor can start on real data.
Set the scoring weights with the buying group, including security, before any vendor responds.
Send the RFP to three to five vendors and answer questions in one shared document.
Score proposals independently, then compare and discuss the biggest differences.
Shortlist two and interview the engineers each proposed, with a question about an AI system they shipped and how they measured its quality.
Ask the finalist for a short written plan for the first 30 days, including the eval set and data access steps.

Example: a filled-in data readiness section

Field	Example
Sources	Claims documents (PDF scans and emails) in a document store; claim records in Postgres; adjuster notes in the claims system
Known issues	Older scans have poor OCR quality; notes use internal abbreviations
Access status	Claim records approved; documents pending privacy review
Permissions	Adjusters may only see claims in their region
Eval support	Two senior adjusters can label 200 past claims over a month

Common mistakes in AI development RFPs

Asking for "AI" without a workflow. Vendors respond with platform pitches. Describe the task, the users and today's process.
Hiding the data problems. Vendors find them in week two anyway. Disclose them so proposals price them in.
No quality definition. Without an eval requirement, every vendor promises accuracy and none can be held to it.
Judging the demo. A polished demo on sample data says little about your data. Weight production experience and the eval plan.
Forgetting handoff. If evals, prompts and runbooks stay with the vendor, you depend on them indefinitely.
Ignoring run cost. Ask for cost per request at your volume, not only the build cost.

Sending an RFP to build AI?

Ryz answers with named engineers. Our AI pod teams are dedicated pods of senior engineers, typically a tech lead with AI, ML and backend engineers, that build AI systems in your cloud and repos and ship them to production alongside your team, with evals, tracing and runbooks in your repos. Pods have shipped production systems for fraud detection, marketing compliance review, voice platforms and driver support; see the case studies. Only the top 1% of the tens of thousands of engineers we interview make it, on US business hours including New York hours. You own all code and IP. Typical cost is $7,000 to $15,000 per engineer per month. Send us your brief, or read about AI pod teams.

FAQ

What should an AI development RFP include?

The problem and users, the state of your data and access, model and deployment constraints, the quality bar and eval requirements, latency and cost targets, security and personal data rules, the production and handoff plan, expected team composition, timeline and a weighted scoring sheet.

How is an AI RFP different from a software development RFP?

It adds data readiness, evaluation, model choice, cost per request, prompt injection and data leakage testing, and handoff of evals and prompts. Quality cannot be specified as a feature list, so the RFP must say how quality will be measured.

How do you evaluate AI development vendors?

Weight the production AI experience of the proposed engineers and their evaluation approach highest, then data plan, security, production path and cost clarity. Interview the engineers each shortlisted vendor proposes and ask how they measured quality on a system they shipped.

Should an AI RFP ask for a proof of concept?

Ask for a plan for one, with success criteria, rather than a free demo before selection. A short paid proof of concept on your real data with the chosen vendor is a better test than demos on sample data.

What data should we share in an AI RFP?

Describe sources, formats, volume, known quality issues and access status without sharing the data itself. Share samples only under your NDA and only with shortlisted vendors.

Questions we didn't answer? Email info@ryzlabs.com.