How to Write an AI RFP: Requirements, Security Questions and Evaluation Criteria
A useful AI RFP describes a business workflow, decision rights and acceptance evidence—not a shopping list of model features. Use this practical structure to compare suppliers fairly.
AI-drafted, machine-checked against our published editorial rules, and reviewed on publication. Corrections: [email protected] How we use AI
An AI request for proposal should make it easier to compare delivery approaches, not reward the supplier with the most model names in a slide deck. The strongest RFP starts with a business workflow, defines the decision rights around it and asks suppliers to show how they will prove the system is safe and useful.
The aim is not to prescribe an architecture before discovery. It is to make the intended outcome, constraints and acceptance evidence clear enough that each supplier is answering the same problem.
Start with one decision or workflow
Write the first page for the people who will use the system. Describe what happens today, what triggers the work, which teams and applications are involved, where the process fails or slows down and what should be different if the project succeeds.
Avoid “we need an AI chatbot” unless a conversational interface is genuinely the job. A better statement is: “Operations receives supplier documents in several formats, matches them to purchase orders, escalates exceptions above an agreed threshold and must retain evidence for each decision.” That description exposes the real questions: data quality, integrations, validation, approval and retention.
Specify outcomes and boundaries separately
An RFP should distinguish the desired outcome from the permissible means. Ask for a measurable process outcome—fewer manual hand-offs, faster evidence retrieval, a defined exception queue—then state the boundaries:
- What data the system may read and what it must never receive.
- Which systems are sources of record and which actions may be proposed or committed.
- Who may use, administer and approve the system.
- Which regions, retention rules and contractual requirements apply.
- What a human must review before an external or consequential action.
This prevents false certainty. A supplier may recommend a stable API and deterministic rule for one step, retrieval for another and a language model only for ambiguous cases. That can be more dependable than applying a general-purpose model to every part of the workflow.
Ask for an evaluation plan, not a promise of accuracy
“How accurate is your AI?” is too broad to compare proposals. Ask suppliers to define representative test cases, a baseline, acceptance thresholds, error categories, review routes and a plan for regression testing after model or connector changes.
Require difficult cases as well as ordinary ones: incomplete records, contradictory evidence, a request outside the approved scope, an unavailable downstream system and a legitimate case the system should escalate. A supplier should explain what the system does when it does not know, not only how it performs on a curated demonstration.
NIST’s AI Risk Management Framework and its Generative AI Profile are voluntary guidance, but both help frame these questions around context, measurement and management rather than a single headline metric. Reference the AI RMF and the Generative AI Profile when building your evaluation and governance sections.
Include security and operational evidence
Ask for practical answers, not policy PDFs alone. For each proposed system, request:
| Area | Questions worth asking |
|---|---|
| Identity and access | Which identities call each system, and how are permissions scoped and reviewed? |
| Data | Where is data processed, retained and deleted? How are tenant boundaries enforced? |
| Tools and actions | How are tool calls validated before they change a system of record? |
| Logging | What structured evidence is retained for a decision, action and failure? |
| Resilience | What happens after a timeout, partial success or duplicate request? |
| Change control | How are model, prompt, connector and policy changes tested and approved? |
For EU-based teams, legal requirements vary by use case and contract, so an RFP should ask for factual hosting, subprocessor and data-use answers rather than a blanket claim of compliance. The European Commission notes ongoing work on model contractual terms and guidance for AI contracting; see its overview of innovative technologies and data in contracts. Treat legal review as a separate workstream where it is needed.
Make commercial comparison fair
Ask suppliers to separate discovery, build, integration, evaluation, security review, deployment and ongoing operation. Ask which assumptions would change the estimate: data cleanup, unavailable APIs, user-volume growth, human review requirements or specialised infrastructure.
The lowest implementation price can be misleading if it excludes the work required to run the system safely. Conversely, a bespoke proposal should explain why each custom component is necessary and where a managed service is preferable. Require an exit plan: access to code, configurations, data exports, documentation and evaluation cases if the relationship ends.
A compact RFP structure
- Business context and workflow.
- Scope, users and systems of record.
- Required outcomes and non-negotiable constraints.
- Data, security, privacy and operational requirements.
- Pilot design and acceptance criteria.
- Delivery plan, ownership model and commercial assumptions.
- Scoring method and decision timetable.
This structure gives a good supplier room to improve the architecture while ensuring proposals can be compared. QQuantum.ai’s procurement and security review explains the evidence we prepare for architecture review, DPAs and security questionnaires. If you have a workflow in mind, start with an AI readiness assessment before issuing a broad tender.
