Direct answer: An RFP is not "copy the vendor's feature list". It turns the business problem, data/system boundaries, POC acceptance, pricing basis, contract and exit into a scorable, accountable document. Decide first whether to self-build, buy SaaS, go private/hybrid or use an outsourced POC; then issue the RFP. Do not accept a proposal without samples, a POC and exit terms. An RFP also cannot replace business decisions—if requirements and data are not mapped, run a diagnostic first.
This report is for AI project owners, product/business, procurement, legal, IT/security, data and vendor management. It covers RFPs for agents, RAG, AI customer service, document Q&A, quality inspection and predictive maintenance. Information is current to 30 October 2026. It is public standards, governance frameworks and project method, not certification or a promise about any vendor, product, price, accuracy or compliance; requirements, scoring, POC, contracts and procurement process are governed by business risk, the standards, company policy, tender rules and legal advice.
Write the business problem and acceptance before the feature list. Set scoring weights and evidence before receiving bids—not after the demo. Include POC, pricing/TCO, contract and exit together; otherwise you select the best demo, not the best vendor.
Decide self-build, buy or hybrid before issuing an RFP
Issue an RFP when requirements are clear, several vendors exist, and spend/risk is material. If requirements or data are not mapped, run a diagnostic first; an RFP cannot replace a business decision.
An RFP is a procurement process, not a requirements-discovery process. If the company cannot yet say who uses the system, what problem it solves, where the data sits and what failure means, the RFP will turn vague requirements into vendor narratives. Run a light diagnostic first and choose a path: self-build core capability, buy SaaS for standard scenarios, go private/hybrid for sensitive data, or use an outsourced POC for short validation. The path changes the scoring, contract and exit clauses.
| Path | Fits | Does not fit | RFP focus |
|---|---|---|---|
| Self-build | Core differentiation, controllable data/team, long-term iteration | No algorithm/engineering/ops team | Data, model, evaluation, operations and asset ownership |
| SaaS purchase | Standard scenarios, fast launch, limited customisation | Data cannot leave the company / multi-tenant is unacceptable | Data isolation, export, SLA, price increase/exit |
| Private/hybrid | Sensitive data, system integration, complex permissions | No GPU/ops/security capability | Deployment, compute, upgrades, monitoring, rollback |
| Outsourced POC | Requirements need validation, short-term capability | No business owner or acceptance samples | Scope, samples, timebox, stop conditions, IP |
Path selection is an editorial suggestion; the self-build/buy/hybrid decision depends on business, data, budget, compliance and the existing team.
How to write the requirements section
Write seven sections—business problem, users/scenarios, data, system boundaries, security/permissions, acceptance, and operations—not a vendor feature list. Each section needs an owner and a verifiable result.
The requirements section should put every vendor on the same exam, rather than letting each present its own product. Use seven fixed sections: business problem/goal, users and scenarios, data source and authorisation, system/interface boundaries, security/permissions/compliance, POC/acceptance, and launch/operations/exit. For each, state "must/prefer/do not", current state, constraints, owner and evidence. Avoid unscoreable phrases such as "supports AI" or "can integrate".
| Section | What to write | Evidence/notes | Owner |
|---|---|---|---|
| Business problem/goal | Current process, pain, baseline, success criteria, cost of failure | Process/baseline data | Business |
| Users/scenarios | Roles, tasks, channels, frequency, exceptions/escalation | User list, samples | Product |
| Data | Source, fields, authorisation, quality, labelling, retention/deletion | Data map, samples | Data/legal |
| Systems/interfaces | ERP/MES/OA/CRM, API, permissions, network, deployment | Interface list, architecture | IT |
| Security/compliance | Data classification, permissions, logs, audit, cross-border, vendor duties | Policy, assessment/contract | Security/legal |
| POC/acceptance | Samples, metrics, gates, human review, timebox, stop conditions | Acceptance plan | Business/QA |
| Launch/ops/exit | SLA, monitoring, change, rollback, data/model/account handover | SLA, exit list | Ops/procurement |
The seven-section structure is an editorial template; adjust to industry, systems, risk and procurement policy.
How to design the vendor scorecard
Score six groups—business fit, data/systems, POC, pricing/TCO, security/compliance, and delivery/exit. Set weights and evidence before bids; reject unverifiable items such as "strong AI capability".
Set the scorecard before receiving bids, not after the demo. Weight by project risk: raise business/data integration for integration-heavy projects; raise security/compliance for regulated or sensitive data; raise TCO when budget is tight, but never so high that exit cost is ignored. For each item, state what evidence is required—authorised case studies, interface documents, test reports, POC results, price breakdown, contract clauses—not "feels professional".
| Group | Example weight | What to score | Evidence |
|---|---|---|---|
| Business fit | 20% | Scenario understanding, user flow, exceptions/human takeover, deployed cases | Authorised cases, process demo, interviews |
| Data/systems | 20% | Data access, cleaning, labelling, interfaces, permissions, deployment | Interface docs, data-flow diagram, integration record |
| POC | 20% | Own golden set/scenario samples, metrics, human review, timebox | POC plan, test report |
| Pricing/TCO | 15% | Licence/subscription, implementation, data, integration, compute, ops, exit | Price breakdown, three-year TCO |
| Security/compliance | 15% | Data isolation, logs/audit, permissions, cross-border, incident response | Policy, assessment, contract/DPA |
| Delivery/exit | 10% | Team, SLA, change, training, handover, deletion | Org chart, SLA, exit list |
Weights are illustrative assumptions, not standards; set them before bids based on risk, budget and procurement policy, and keep the record.
How to put POC into the RFP
Specify sample source, scenario/risk strata, metric gates, human review, timebox and stop conditions. Do not let the vendor bring only its own demo set, and do not turn the POC into free custom work.
POC is the vaguest part of many RFPs. Specify whose samples, how many, which scenarios/risks, who labels/adjudicates, how long, in which environment, which metrics, who signs off, when to stop, and the POC fee/credit. Vendors can bring a demo, but acceptance must use the company's own/controlled samples. A POC should not become "half a free project"; define scope and a timebox.
| Clause | What to write | Evidence |
|---|---|---|
| Samples | Company-provided/masked, scenario/risk strata, negatives/safety, quantity | Sample list, labelling guide |
| Metrics | Task success, citations, refusal/safety, format, latency, takeover | Metric definitions, calculation |
| Gates | Hard gates 100%, soft gates/fallback, stratified results | Acceptance plan, sign-off |
| Environment | Test/pre-production, data isolation, accounts/permissions | Environment note, access record |
| Timebox | Start/end, review points, extension handling | Plan, meeting record |
| Stop/fee | Stop if gates fail, POC fee/credit, sample/output ownership | Contract, POC agreement |
POC clauses are editorial suggestions; specific samples, gates, fees and output ownership depend on the project/contract, with no fixed accuracy or launch-timeline promise.
How to break down pricing/TCO
Break pricing into licence/subscription, implementation, data, integration, compute, operations, training and exit. Compare three-year TCO, not just first-year licence or unit price.
AI proposals often look cheap in year one and expensive later: low licence + separate implementation + separate data/labelling + integration by person-day + compute/API overage + annual operations/upgrades + exit migration. Require one pricing template with unit price, quantity, assumptions and boundaries, plus a three-year TCO; if an item cannot be priced, mark "to be confirmed" rather than "as needed". The table is a TCO formula and cost categories, not a price list.
| Category | What it includes | Year 1/later | Evidence |
|---|---|---|---|
| Licence/subscription | Platform, seats, call volume, modules, minimum spend | Year 1 + renewal | Price list, contract |
| Implementation | Requirements, configuration, development, testing, project management | Mostly year 1 | Person-days/milestones |
| Data | Cleaning, labelling, evaluation set, knowledge-base preparation | Year 1 + ongoing | Sample volume, unit price |
| Integration | ERP/MES/OA/CRM, SSO, permissions, network | Year 1 + changes | Interface list, person-days |
| Compute/calls | GPU/cloud, API tokens, vector DB, storage | Usage-based | Usage assumptions, unit price |
| Operations | Monitoring, retraining, upgrades, alerts, on-call | Annual | SLA, staffing |
| Training/change | Training, process change, internal adoption | Year 1 + ongoing | Plan, hours |
| Exit/migration | Data export, model/prompt/knowledge-base handover, deletion | Contract end | Exit list |
TCO categories are an editorial template; prices/usage depend on vendor quotes, actual company data and contracts; this article provides no uniform price or price promise.
How to write contract clauses
Write acceptance/payment milestones, data/model/prompt ownership, no-training, SLA, change, exit/deletion and third-party evaluation. Without these, the RFP is just a questionnaire.
The vendor selected by the RFP must land in a contract. Beyond standard procurement terms, an AI contract should specify acceptance criteria and payment milestones; ownership of data, models/fine-tuned weights, prompts, knowledge bases and evaluation sets; no training on company data; SLA/support; change/price increase; subcontracting; security-incident notice; exit/deletion/handover; disputes/third-party evaluation. Do not accept "we will use our standard template" while skipping these.
| Clause | What to write | Acceptance evidence |
|---|---|---|
| Acceptance/payment | POC/launch/acceptance milestones, gates, retention, failure handling | Acceptance plan, sign-off |
| Data/model ownership | Company data, models/fine-tuned weights, prompts, knowledge base, evaluation set | Asset list, contract annex |
| No training | Company data not used for vendor training/reuse | Undertaking, isolation/audit |
| SLA/support | Availability, response, repair, upgrade, on-call | SLA, ticket record |
| Change/price | Versions, price, call volume, advance notice | Change process, price list |
| Subcontracting/security | Subprocessor list, data location, incident notice, audit rights | List, DPA, notice template |
| Exit/deletion | Data/log/config/account handover, deletion proof | Handover list, deletion proof |
Contract clauses are editorial suggestions, not a substitute for legal review; specific IP, data, SLA, acceptance and exit terms depend on the project/procurement policy.
How to sequence a 90-day RFP
Weeks 1–2 requirements/data/budget; weeks 3–4 write RFP/scorecard; weeks 5–6 Q&A/shortlist; weeks 7–8 POC/review; weeks 9–12 negotiate, contract, launch and handover.
An RFP does not end when it is issued. Sequence "requirements confirmation, RFP release, Q&A, shortlist, POC, review, negotiation, contract, launch" into 90 days, with an owner and decision point at each stage. Keep the POC timebox short and validate the key assumptions first; do not put every requirement into the POC.
| Phase | Actions | Outputs | Owner |
|---|---|---|---|
| Weeks 0–2 | Business diagnostic, data/system inventory, budget/path, RFP scope | Diagnostic report, path decision, budget frame | Business/procurement |
| Weeks 3–4 | Write requirements, scorecard, POC/contract clauses, approval | RFP, scorecard, approval record | Product/procurement/legal |
| Weeks 5–6 | Release/Q&A, vendor qualification, shortlist | Q&A log, shortlist | Procurement |
| Weeks 7–8 | POC/demo, scoring, review meeting | POC report, scorecard, review minutes | Business/QA |
| Weeks 9–10 | Commercial negotiation, contract, SLA/exit clauses | Contract, SLA, exit list | Procurement/legal |
| Weeks 11–12 | Kick-off, handover, baseline, next review | Kick-off record, baseline, plan | Project manager |
The 90-day sequence is an editorial suggestion; tender/procurement deadlines, approvals and contract process follow company policy/tender rules.
Pre-award acceptance checklist
Before award, check six evidence sets: requirements, scorecard, POC, pricing, contract and exit. If any is missing, do not fill the gap with "sign first and fix later".
Award is not "pick the highest score"; it is confirming that high scores have evidence, low scores have reasons, and the contract can be executed. The checklist can be shared by business, procurement, legal, IT/security, data and finance; every item needs a document/record, not a verbal promise.
| Check | Pass standard | Evidence | If failed |
|---|---|---|---|
| Requirements | Business/data/system/security/acceptance/ops sections complete | RFP, requirements sign-off | Add/defer |
| Scorecard | Weights/evidence/evaluators fixed before bids | Scorecard, review record | Re-score/record |
| POC | Company samples, metrics, gates, timebox, stop conditions | POC plan/report | Add POC/reject |
| Pricing/TCO | Eight categories, three-year TCO, assumptions/boundaries | Price breakdown, TCO | Add/recalculate |
| Contract | Acceptance/payment, IP, no-training, SLA, exit | Contract/annex | Negotiate/replace |
| Exit | Data/model/prompt/knowledge-base/account handover and deletion | Exit list, deletion proof | Add clause/do not sign |
The checklist is an editorial suggestion; award, approval and contract signing follow company policy, procurement/tender rules and legal advice.
Who should read this, who should not, and what decision does it support?
It fits companies selecting, tendering or procuring AI agents, RAG, customer service, quality inspection or document Q&A. It does not fit teams without requirements, a business owner or data inventory, or those only comparing low prices.
Who should read: AI project owners, product/business, procurement, legal, IT/security, data and vendor management; teams writing an AI RFP, shortlist, POC plan or contract clauses; companies needing to put "effectiveness" into scoring, acceptance and payment milestones. Who should not: teams without requirements, data/system inventory or a business owner; projects only comparing low prices and unwilling to run a POC or contract clauses; teams expecting one RFP to replace a business decision/technical assessment. Decisions supported: self-build/buy/hybrid/outsourced POC, requirements, scorecard, POC, pricing/TCO, contract and pre-award acceptance.
FAQ
What is the difference between an RFP and an RFI?
An RFI usually explores the market/vendor capabilities without a procurement commitment; an RFP states requirements, scoring and contract conditions to select a vendor. If requirements are unclear, run an RFI/diagnostic first, but do not treat an RFI as an RFP and award directly.
If there are only a few vendors, do we still need an RFP?
Fewer vendors does not remove the need for requirements, scoring and contract terms. Use a simplified RFP or targeted invitation, but still specify requirements, POC, pricing/TCO and exit. With only one vendor, the evidence matters more—do not let "only they can do it" become accepting terms passively.
Should a POC be paid?
It depends on scope and effort. A short, bounded POC can be paid/credited toward the contract; demanding extensive free custom work is unrealistic and bad for quality. Write down samples, timebox, output ownership, fee/credit and stop conditions.
How should scoring weights be set?
Set by project risk/goal, not a fixed template. Raise business/data weights for integration-heavy projects; raise security/compliance for regulated/sensitive data; raise TCO when budget is tight, but do not ignore exit cost. Fix weights and evidence before bids and keep the record.
Is the lowest price best?
No. AI proposals often have low licence plus separate implementation/data/integration/compute/operations/exit. Compare three-year TCO and boundaries, not first-year price; below-cost bids often mean reduced scope, later increases or lower service quality.
What if the contract has no exit clause?
Add it before signing: data/log/config/account/model/prompt/knowledge-base handover, deletion proof, transition support, fees and dispute handling. If already signed, add a supplementary agreement/operating manual and run an exit drill; a vendor without exit capability should not run a critical project.
Bottom line
An enterprise AI RFP starts with the path and business problem, then writes seven requirements sections, six scoring groups, POC samples/gates, eight TCO categories, contract/exit clauses and a 90-day sequence. Fix scoring evidence before bids, use company samples in the POC, write IP/no-training/acceptance/exit into the contract, and require all six evidence sets before award.
Method and limits
This article is public standards, governance frameworks and editorial method, not certification, a promise or legal advice for any vendor, product, price, accuracy, POC or contract. It uses no unpublished client RFP, pricing or contract. The path table, requirements, scorecard, POC/TCO/contract checklists, 90-day process and award checklist are editorial suggestions; specific requirements, weights, POC, pricing, contracts and procurement process are governed by business risk, the standards, company policy, tender rules and legal advice.
Sources
Information is current to 30 October 2026; each official/primary page governs its own scope and version.
- AI Safety Governance Framework 3.0 (TC260, 14 September 2026): tc260.org.cn. Risk governance/assessment framework for the security/risk sections.
- GB/T 45288.1-2025, Artificial intelligence—Large-scale model—Part 1: General requirements (effective 28 February 2025): National Standards Full-text Platform. General large-model requirements for capability/lifecycle baseline.
- GB/T 45654-2025, Cybersecurity technology—Basic security requirements for generative artificial intelligence service (effective 1 November 2025): National Standards Full-text Platform. Generative-AI service security requirements and assessment baseline.
- National AI Industry Comprehensive Standardization System Construction Guide (2024 edition) (four departments, July 2024): gov.cn. Policy context for AI standards/evaluation/service specifications.