AI Consulting RFP: A Template for Scope, Evidence, and Review

An AI consulting RFP (request for proposal) sets out what problem you need solved, what data the consultant may access, what they will deliver, and what you will accept as evidence the work succeeded. A clear RFP protects both sides: the client knows what it bought, and the consultant knows what done means.

Writing the RFP forces the project team to agree on scope and limits before anyone starts. A tool like fenbs keeps those agreed requirements and vendor decisions in one place every team member can read, so answers stay available once the engagement is underway.

What to settle before you write

An RFP written before the team agrees on the basics generates questions the client cannot answer. Resolve three things first: the problem statement, the decision owner, and the data limits.

• Problem statement. What decision, process or outcome does the AI need to improve? One specific sentence is better than a paragraph.
• Decision owner. Who approves the proposal, signs the contract and accepts the final work? Name one person.
• Data and access limits. Which systems, files or services may a consultant or their AI tool read, write or store? Write it down before the first vendor call.

If the team cannot agree on those three points, the RFP will use vagueness instead of clarity. Vendors will fill the gaps in their own favor. Write the constraints first, even if they narrow the field.

Template: sections to include

Use the section headings below as a starting structure. The questions in each section are prompts, not required answers. Use the ones that apply to your engagement.

1. Project overview
   What problem are we solving, and why now?
   Who is affected, and how will we measure improvement?

2. Scope of work
   What must the consultant deliver?
   What is explicitly out of scope?
   Which AI tools or models are permitted, and which are prohibited?

3. Data access and boundaries
   Which data sources may the consultant read?
   What data must not leave our systems?
   How must data be stored, transmitted, and deleted at project end?

4. Deliverables and milestones
   List each deliverable with a format and a due date.
   Which deliverables require sign-off before work continues?

5. Acceptance criteria
   What does success look like for each deliverable?
   Who reviews and signs off? What is the review period?
   What constitutes a failure that triggers a remedy?

6. Intellectual property and confidentiality
   Who owns the work product?
   What information must the consultant keep confidential?

7. Proposal requirements
   What must the proposal contain (team, approach, references)?
   Submission format, deadline, and evaluation criteria.

Keep the template in a shared location your project team can annotate. As decisions are made during the engagement, record them alongside the original requirements so you can compare what was agreed with what was delivered.

Writing clear outcomes

Outcomes describe the change you need, not the activity you are buying. "Deliver a report on AI use cases" is activity. "Reduce manual data-entry time by a measurable amount, tested over thirty days" is an outcome. Outcomes make acceptance checks possible.

Pair each outcome with a baseline: what is the current state you are improving? Without a baseline, both sides will argue over whether improvement happened. A baseline does not need to be exact, but it must be agreed before work begins.

If an outcome is hard to measure, describe what you will observe when the work succeeds. A legal team might say: "Staff can find the correct template for a given matter type in under two minutes, without asking a colleague." That is observable and testable.

Recording these outcomes as project tasks and decisions keeps them visible. See our AI risk assessment template for a related checklist to run before the engagement starts.

Setting data and access boundaries

Describe data access in concrete terms. "Read-only access to the claims database for ninety days" is concrete. "Access to relevant data" is not. Name the system, the access level and the duration.

Specify what happens to data at project end. The consultant's AI tool may have indexed or cached your data during the engagement. Require written confirmation of deletion and name the format. A line in the acceptance criteria makes this a condition of final payment.

If the engagement involves personal data, state the applicable rules. For US engagements, note which laws apply: HIPAA for health data, FERPA for education records, and applicable state privacy laws. Require the consultant to identify the relevant controls in their proposal.

Acceptance criteria that prevent disputes

Each deliverable needs its own acceptance criteria. Write them as statements you can check on the delivery date. "The model achieves the agreed accuracy score on the test set" is checkable. "The model performs well" is not.

Name the reviewer and the review period. A common gap is what happens when no one reviews the deliverable within the window. Spell out whether silence counts as acceptance or rejection.

Set a remedy for acceptance failure. Require the consultant to correct the defect and resubmit for review within a specified period. Limit the number of resubmission cycles and state what happens if the defect persists.

Evaluating proposals

State your evaluation criteria and their weights in the RFP. That forces you to decide what matters before you see the proposals, which reduces the pull toward the lowest price or the most confident presenter.

• Technical approach: how they will solve the problem, not just which tools they plan to use.
• Evidence of similar work: a reference engagement, a demonstrated method, or a case study.
• Data governance: how they will handle your data, including any AI tools they use during the engagement.
• Team: who will actually do the work, not just who is named on the proposal.
• Acceptance process: how they propose to handle review, rejection and correction.

Ask vendors to respond specifically to your data boundaries section. A consultant who does not address it has either not read the RFP carefully or is hoping you will not ask.

Common gaps in AI consulting RFPs

The most common gap is not the technical section but the handoff. What does the consultant deliver at the end? Code, documentation, a trained model, a report? Who trains the client team to maintain and correct the output? Require this in the deliverables section.

A second gap is model provenance. If the consultant builds a solution using a third-party model or API, who holds the relationship with that vendor? What happens to the solution if that vendor changes terms? Ask the question in the RFP so the proposal must address it.

See our product requirements document template for AI coding agents if the output of the engagement is software built with an AI coding tool. For a broader introduction to AI governance questions, visit the AI governance topic hub.

How to do this with fenbs

1. Create a free account. Start a project for the consulting engagement.
2. Add a task for each major deliverable from the RFP. Include the acceptance criteria in the task notes.
3. Record each agreed requirement and data boundary as a Decision. Name the person who decided it.
4. Connect your AI apps over MCP from Integrations. They will read the project decisions before answering questions about the engagement.
5. At each milestone, update tasks to reflect what was delivered and what was accepted. Record any scope changes as new decisions with the reason.

A personal board is free and a good place to draft the RFP structure. When multiple team members need access during the engagement, a team board gives each member a role with appropriate access.