Writing RFPs for Enterprise AI Projects: Requirements Checklist, Scoring Weights, and Downloadable Template
Most enterprise AI projects don't fail on technology. They fail on an RFP that only says "here's what I want" without saying "here's how we know it worked." Here's a requirements checklist and scoring matrix covering data, security, acceptance, SLA, and operations, plus a downloadable template and eight critical clauses. Skip any of them and problems follow.
By
Tenten AI FDE 團隊
導入方法論
Published
October 1, 2025
Read time
6 分鐘
The problem is rarely the vendor.
A manufacturing client asked us to help re-tender an AI visual inspection system last year. Their RFP contained three lines: "Deploy AI visual recognition, improve yield rate, support Chinese interface." Each vendor interpreted it differently. Bids ranged from $800,000 to $4 million. They chose the cheapest option. Three months after launch, yield hadn't improved. Both sides blamed each other.
The problem wasn't the vendor. It was the RFP. It said "here's what I want," not "here's how we know it worked."
Buying an AI system isn't like buying an ERP system. With ERP, features work the same regardless of your data. With AI, outcomes depend entirely on data quality. An effective RFP names the variables: who owns the data, how security works, what counts as acceptable performance, what penalties apply if SLAs fail, and who maintains the system after launch. Leave any of these five out and everything downstream becomes contested.
Requirements checklist: five dimensions, none optional
The checklist breaks requirements into five categories. Each must be verifiable, no adjectives allowed.
Business goals: Write measurable metrics, not "improve efficiency." Write "first-response time drops from 8 hours to under 30 minutes, covering 80% of common requests." Without a baseline and a target, you have no acceptance criteria.
Data: What you have, format, volume, refresh frequency, and who owns it. Explicitly call out who's responsible for data cleanup, that's where pricing variance gets buried.
Features and integrations: Which existing systems get connected (CRM, ERP, internal APIs), how they connect, single sign-on requirements, permission model.
Security and compliance: Data residency, whether external LLMs can be used, PII de-identification requirements, audit log retention periods.
Operations and handoff: Who monitors model drift after launch, who maintains the knowledge base, SLA and penalties for failures.
Scoring weights: don't let price take half
| Scoring Dimension | Suggested Weight | What to Look For |
|---|---|---|
| Solution understanding and business alignment | 20% | Does the vendor actually understand your scenario, or just apply a template? |
| Technical approach and data handling | 20% | RAG/Agent architecture, data cleanup plan, hallucination handling |
| Security and compliance | 15% | Data residency, access controls, audit trails, de-identification |
| Delivery and adoption | 15% | Onboarding plan, adoption rate commitments |
| Operations and SLA | 10% | Monitoring, update cadence, failure penalties |
| Team and track record | 10% | Same-industry references, field engineer experience |
| Price | 10% | Total cost of ownership, not just licensing |
Price gets 10% deliberately. Teams that optimized for the lowest bid often paid more overall. Delivery and adoption deserve their own line because failures rarely stem from technology. The real problem is that the system launches and nobody uses it.
Downloadable template
A downloadable RFP template (Word/Google Docs) includes the checklist, scoring sheet, timeline, payment milestones, and critical clauses. Find it at tenten.co in the resources section by searching "AI Project RFP Template." Edit as needed, but keep the eight clauses listed below.
The 8 most commonly missed clauses
These eight clauses address real problems from actual projects. Missing even one creates complications.
-
Data ownership and exit clause: When the contract ends, who owns your data, the fine-tuned model weights, the vector indexes. How will you get them back? How quickly does the vendor destroy theirs? Without this, switching vendors becomes impractical.
-
Model and version change notification: If the vendor updates the underlying LLM (upgrading to a newer version), they must notify you first. Output behavior changes. It can break workflows you've already validated.
-
Hallucinations and fault boundaries: When the AI gives a wrong answer that costs money, who's responsible? At a minimum, establish human review checkpoints for high-risk scenarios.
-
Acceptance criteria and acceptance window: Specify the test data, pass thresholds (accuracy, coverage, etc.), what happens if performance fails, and exit terms. Don't treat a passing demo as automatic acceptance.
-
Adoption rate and ramp-up clause: For a set number of months after launch, the vendor stays involved helping you reach adoption targets, rather than simply handing the system over. This clause eliminates vendors who license and disappear.
-
Data residency and cross-border data flow: Where data physically lives, whether it goes through external APIs, whether it meets your industry's compliance requirements.
-
SLA and penalties: Uptime, response time, mean time to recovery, and specific compensation if targets aren't met (service credits or liquidated damages). "Best effort" isn't specific enough.
-
Knowledge base maintenance: After RAG goes live, knowledge decays. Specify whether the vendor maintains it or hands it to your team, and if so, what documentation and training they provide.
An RFP exists to make you define what "done" actually means. Before code starts, nail down acceptance criteria, data inventory, and adoption targets with the client, one item at a time. Everyone nodding in the demo room doesn't guarantee anything. What matters is whether people in the field use the system daily, three months later.
One stuck workflow
is enough to begin
Tell us what the team does today, where it breaks down, and what a better working day should look like.