How to write an RFP for an AI implementation project

A request for proposal earns its cost when you need to compare several AI implementation partners on the same basis, for a project large enough that a bad match is expensive. It earns nothing when it becomes a formality: twenty pages of boilerplate questions that every vendor answers the same way, while the one thing that predicts whether the engagement works, whether the firm understands your workflow before naming a technology, never gets asked directly. This piece sets out what to put in an AI RFP, the questions worth asking every bidder, and how to score what comes back.

When does an RFP help, and when is something lighter better?

An RFP is the right tool when you are comparing three or more firms for a project above your normal procurement threshold, when more than one internal stakeholder has to sign off, or when your organization needs a documented, defensible process. It is the wrong tool when you already trust one or two firms and want to move quickly, when the workflow is narrow enough that a scoped conversation covers it, or when you do not yet know enough about your own process to write firm requirements.

That last case is common, and worth naming plainly. If you cannot describe the workflow's steps, the systems it touches and where it breaks down today, an RFP will not close that gap, it will distribute it to every bidder, who will each guess differently and hand back proposals that cannot be compared. Write a requirements brief first, or hold a paid discovery conversation with one or two candidates, then write the RFP once you know what you are actually asking for.

The same discipline shows up in federal guidance. The U.S. General Services Administration's resource guide for generative AI acquisition recommends testing a solution in a sandbox or a limited environment before committing to a large scale purchase, and lists questions contracting officers should ask before signing off (GSA). The same logic applies at a smaller scale: a short paid pilot with your top two bidders often tells you more than either written proposal does.

What must an AI implementation RFP contain?

Nine sections cover what a partner needs to quote responsibly. Use this as a starting outline and drop what does not apply to your project.

1. Background and the business problem. What is going wrong, for whom, how often, and what it costs today.
2. The workflow in scope. The process end to end, including the exceptions, not only the steps that go smoothly.
3. Systems and data. Every system the solution must read from or write to, such as your ERP, CRM or document store, and how current the data needs to be.
4. Constraints. Security and compliance obligations, systems that cannot change, a date driven by a real external event.
5. What you want back. The sections you expect in a response and the format, so proposals can be compared side by side rather than read as prose.
6. Evaluation criteria and weights. What matters most and how much, decided and written down before anyone reads a proposal.
7. Timeline. The real date behind the deadline, and how much time bidders get to ask questions.
8. Commercial format. Build cost, running and usage costs, and support, requested as three separate figures rather than one number.
9. Submission instructions. Where to send it, the question window, and who answers questions on your side.

Sections 1 through 4 cover close to the same ground as a software requirements brief, organized here for a competitive process rather than a single partner conversation. If a brief already exists for this project, most of the RFP is assembling decisions you have already made rather than writing new ones.

What questions should you ask vendors?

Group your questions so every vendor answers in a structure you can score, rather than repeating the same idea under five different headings.

Ask two or three specific questions inside each row rather than one broad one, so a vendor cannot answer in a sentence. These eight groups mirror the ten questions and the red flags set out in how to choose an AI implementation partner, which is worth reading before you finalize your list, because it also shows what a good answer to each one sounds like.

How do you score responses with weighted criteria?

Send every vendor the same questions in writing, with the same deadline, then score the answers as a group rather than deciding alone after the most persuasive call. A simple method: give each category a weight from 1 to 3 based on how much it matters for this project, rate each answer from 0, no evidence, to 3, strong and specific evidence, multiply weight by rating, and add up. The highest weighted total is not automatically the right choice, but the exercise forces the comparison onto evidence instead of memory of who presented best.

The AI implementation partner scorecard runs this method for up to three vendors against ten criteria drawn from the questions above. Set your own weights, rate each vendor as answers come in, and it ranks them, flags any high weight criterion where a vendor offered no evidence, and lists the follow up questions worth asking before you decide. Our AI vendor due diligence checklist covers similar ground as a set of statements to tick off against a specific proposal, useful for whoever on your team is not sitting in every vendor call.

What are the red flags in vendor responses?

• Every vendor answer arrives at the same platform, no matter what you actually asked.
• A fixed price offered before anyone has seen your data, your systems or a sample document.
• A case study with no year, no company size and no reference you can call.
• Data handling described in marketing language, such as bank level security, rather than the terms of a named provider.
• Silence on what happens after launch, or an assumption that hosting includes support and monitoring.
• A refusal to separate the build price from what the system will cost to run each month.
• Urgency created by the vendor rather than by anything in your business.

How do you run the process fairly?

Four habits keep an RFP honest. Send the same information to every bidder, in writing, at the same time. Open a defined question window, and publish every question and its answer to all bidders at once, so nobody works from a private advantage. Take the responses down to a short list of two or three, then hold a working session with each, using one real batch of documents or requests rather than a rehearsed demo. Only then take reference calls, prepared with specific questions about what went wrong on a past project and how it was handled.

Illustrative example: Consider a 120 person distributor sending an RFP to four firms for a document processing project. The procurement lead sends all four the same nine section RFP and a two week deadline, publishes every question and answer from the window to all four at once, and asks each of the two finalists to spend half a day working through a real batch of invoices with the operations team. One firm treats the session as a demo of its platform. The other asks to see the invoices with handwriting on them and asks what the current error rate is before touching a keyboard. That difference, more than anything in either written proposal, decides the shortlist.

Read the contract before you sign for the details that are awkward to raise later: ownership of code and data, what happens to accounts at the end, notice periods, and whether any part of the arrangement requires exclusive use of one provider.

How Kastling approaches an RFP for AI work

Kastling is an AI solutions and implementation partner, and a well structured RFP is a reasonable way to reach us. Sent a fixed brief, we would rather spend an hour on a call first understanding the workflow behind the document than return a proposal built only from what is written down, and we would say so in our response. Engagements otherwise start with a free discovery call, and for AI and operations work a separately scoped, paid audit is common next. The background, workflow, systems and constraints sections in this guide are close to what that audit would establish anyway, so a well written RFP tends to shorten the scoping conversation rather than replace it.

We expect to answer the same kind of questions as any other firm on your list: where a human stays in control, how the work would be tested against your own cases, and who owns the code and accounts once the engagement ends. Read more about AI Integration & Automation.