We had a client - a 200-person manufacturing company in the Midwest - who spent four months selecting an AI consultant. RFPs, demos, reference calls, a scoring matrix with seventeen criteria. At the end, they hired the firm that gave the most confident presentation. Eight months and $280,000 later, they had a system nobody on staff could operate, a vendor that had quietly installed a dependency on their proprietary platform, and a clause buried in the contract that assigned ownership of all custom model weights to the consultant.
The selection process itself was the failure. Not the engagement.
We’ve been through this enough times - both advising on it and cleaning up afterward - to know that the most expensive mistakes happen before the work starts. How you find consultants, how you evaluate proposals, what you put in the contract, who you include in the decision - these determine the outcome as much as anything the consultant actually does.
Where Most Companies Look (And Why It Fails)
The standard playbook: post on LinkedIn, reach out to a few firms you’ve heard of, get referrals from your network. The problem with this is selection bias so severe it borders on sabotage.
LinkedIn favors the loudest, not the best. The AI consultants with the most impressive presence - conference appearances, thought leadership posts, glossy case studies - are often the ones who’ve optimized for business development rather than delivery. Building a credible LinkedIn profile takes the same time as building a credible AI system, and the two skill sets don’t overlap much.
Referrals from your network sound better in theory than they work in practice. Your peer at a similar company recommends the firm they used. But they can only tell you what the experience felt like from the client side, not whether the system that got built actually held up, or whether their team could maintain it. The better version of this: ask your peers which firms they interviewed and rejected, and why. Companies that got burned are often more candid than companies that got what they paid for.
Tier-1 consultancies - the big names - solve a very specific problem: they give your board political cover for the decision. “We hired McKinsey Digital” reads well in a board meeting regardless of outcome. The teams they staff on mid-market AI engagements are typically recent graduates with six months of AI exposure, supervised from a distance by a senior partner who will show up for the kickoff dinner and the final presentation. If you’re paying for the brand as risk mitigation theater, at least know that’s what you’re buying.
The channel that produces the best results, in our experience: communities where practitioners talk to each other. Not polished communities run by vendors, but the unglamorous ones - specific Slack groups organized around a particular framework or tool, forums attached to open-source projects, technical Discord servers. When someone asks “who builds good RAG pipelines for document-heavy workflows?” in one of those spaces, the recommendations that come back are from people who’ve actually worked alongside the folks being recommended. The vetting is embedded in the source.
What to Do Before You Send a Single RFP
A request for proposal is only useful if you’ve done the upstream work to make it answerable. Most AI consulting RFPs fail at this step.
Before you approach anyone, you should be able to document: what data you have (format, volume, quality), what system or process the AI output will feed into, who on your team will own the system after the consultant leaves, and what specific outcome you’ll use to decide whether the engagement succeeded. Not a direction - an actual number or state change you can point to.
If you can’t answer those four questions in writing, you’re not ready to hire a consultant. You’re ready to hire someone to help you figure out what you need, which is a very different engagement. Both are legitimate, but conflating them is where the $280,000 disappears.
The scoping document you write before outreach serves a second function: it’s a filter. Send it to five firms. The ones who respond with a proposal that ignores your specific questions and substitutes their standard framework aren’t listening. The ones who come back with clarifying questions are.
One of our portfolio companies recently ran this experiment deliberately. They sent the same two-page problem brief to four AI consultancies. Two came back within 48 hours with boilerplate proposals and pricing. One came back after a week with a 12-question document requesting specifics about their data infrastructure. One asked for a 30-minute call before they’d say anything. That last firm got the engagement.
Reading the Proposal
A proposal tells you more about a consultant than any amount of conversation.
The warning signs are consistent. If the first section is a company overview and credentialing, they’re leading with the wrong thing. You need to see their understanding of your problem before you see their awards. If the timeline is described in phases - “Phase 1: Discovery, Phase 2: Design, Phase 3: Implementation” - without specific weeks attached to each, it’s a structure that can expand indefinitely without anyone being accountable for it.
Watch for deliverables described as documents rather than systems. “AI Strategy Roadmap,” “Technical Architecture Blueprint,” “Implementation Playbook” - these are outputs a consultant can produce without building anything. The first deliverable should be code that runs on your data.
The pricing structure matters as much as the price. Time-and-materials billing with a not-to-exceed cap sounds protective but gives the consultant every incentive to use the cap as a target. Fixed-fee engagements with milestone-based payment create shared accountability - the consultant only gets paid when they deliver something you’ve agreed is real.
Ask for a payment schedule that holds 15-20% until 30 days after handoff. Not after delivery - after handoff, when your team has confirmed they can actually operate the system. Most good consultants will agree to this. Consultants who push back hard on holdback structures are often less confident in their own handoff quality than they sound in the sales process.
The Contract Clauses That Protect You
This is where companies most consistently fail to protect themselves, and where the legal boilerplate the consultant sends first will almost always favor the consultant.
IP ownership: Unless you explicitly negotiate otherwise, you may not own the models, the training data pipelines, or the custom tooling the consultant builds on your time. The standard language in most consulting agreements assigns ownership of “pre-existing IP” to the consultant, which can be interpreted broadly enough to cover the architectural choices, the prompt templates, and even the fine-tuned model weights. Push for explicit language that assigns ownership of all custom work product, trained models, prompts, and configurations to you at the conclusion of the engagement.
Data confidentiality: Know what happens to your data. Some consultants use client data to improve their own internal models. Most won’t tell you this unless asked. The contract should explicitly prohibit use of your data for any purpose other than your engagement, including training or improving any system the consultant operates externally.
Subcontracting: Many boutique AI consultancies staff projects using offshore subcontractors who aren’t disclosed in the sales process. Your data may move to jurisdictions where your assumed legal protections don’t apply. Add a clause requiring written consent before any subcontracting, with disclosure of the subcontractor’s location.
Post-engagement restrictions: You need the consultant to be able to support you after the engagement ends without it becoming a re-engagement that generates new fees for routine questions. Include a 90-day support window for bug fixes and critical issues at no additional charge. Some consultants will push back; the ones who build things that work are usually willing to stand behind them for 90 days.
Termination for convenience: You should be able to end the engagement at any time, paying only for work actually delivered to date. If the contract requires payment of the remaining balance on termination, you have no practical ability to stop a failing engagement without severe financial penalty. Negotiate this clause out before you sign.
The Reference Check Nobody Does Correctly
References exist to be managed. A consultant who’s been around longer than two years has figured out which clients will give glowing recommendations regardless of outcome. The reference list you receive is not a random sample.
Ask for references by asking a specific question: “Can you give me contact information for a client where the engagement ended but the client’s team hit significant difficulty maintaining the system afterward?” Watch how the consultant responds. Most will say they don’t have engagements like that. Some will provide the reference anyway. Either reaction is informative.
When you reach the reference, skip the general satisfaction questions. Ask:
- Who specifically on your team maintains the system today?
- Have you made any changes to it since the consultant left?
- If something broke right now, could your team diagnose and fix it without calling the consultant?
The last question is the most useful. If the answer is no, the consultant didn’t actually transfer knowledge - they built a dependency. That’s not always the client’s fault, but it tells you something about how that consultant thinks about handoff.
Also ask: what did the system cost to run in the first three months, and what does it cost now? Poorly designed AI systems often have infrastructure costs that balloon once they’re running in production at full volume. The consultant is usually gone by the time this becomes visible.
Who Should Be in the Room
The selection committee for an AI consulting engagement needs one person who can evaluate technical claims. Not someone who took an AI overview course. Someone who can read a model card, ask coherent questions about training data, and call out a technical claim that doesn’t make sense.
If you don’t have that person internally, pay someone to serve that function for the evaluation process. Two hours of an independent technical reviewer’s time - reading the proposals, sitting in on the finalist interviews, evaluating the technical approach - costs $500 to $1,500 and catches more problems than any amount of business-side due diligence.
The manufacturing client we mentioned at the top didn’t have a technical evaluator in the process. Everyone who scored the finalists came from operations or finance. The consultant gave a visually compelling demo, used confident language about their approach, and nobody in the room could evaluate whether what they were describing was sensible. With a single qualified technical reviewer, the IP ownership structure in the contract and the platform dependency in the proposed architecture would have been visible before the ink dried.
The Paid Trial That Tells You Everything
Before committing to a full engagement, give your finalist a small, real problem.
Not a toy problem they can impress you with. An actual fragment of your actual work. Give them a sample of your real data, describe a real output you need, allocate a fixed time (usually two to four weeks), and pay them a fixed fee ($5,000 to $15,000 depending on scope) to produce something working.
You’re not trying to get cheap work done. You’re running a process that reveals how this consultant actually operates: how they communicate when things get complicated, what questions they ask, how they handle ambiguity, what the code looks like, whether they document their work as they go or dump documentation on you at the end.
A firm that does excellent work during this phase has almost no competition from firms that interviewed well but haven’t proven anything. You’re buying certainty at a fraction of the cost of a bad full engagement.
Most consultants will agree to a paid trial if you frame it correctly. If a firm refuses to do paid scoping work and insists on a full commitment upfront, treat that as diagnostic information.
After You’ve Chosen Someone
The selection process doesn’t end at contract signing. The first two weeks of the engagement are still part of how you protect yourself.
Establish a weekly rhythm immediately: a standing check-in where the consultant shows working code or a working system, not status updates. “We’re 60% done with the data pipeline” is not a checkpoint. “Here’s the pipeline running on your last 30 days of data, here’s the output, here’s what still breaks” is.
Assign an internal owner - one person who is responsible for knowing everything the consultant builds. Not a manager who gets briefed. Someone who sits in on technical sessions, reads the code, asks questions, and could explain the system to a new hire if they had to. If you can’t assign that person because your team is too busy, that’s a signal to renegotiate the engagement timeline, not skip the knowledge transfer.
The consultants who build good systems don’t mind this. They’d rather have an engaged client than one who’s surprised at handoff.
The manufacturing company eventually rebuilt. They hired a different firm - smaller, two people, no office in 12 cities - paid them $55,000 fixed fee, and got a system their operations team has maintained independently for the past 14 months. The contract was four pages. The payment schedule held 20% until 60 days after handoff.
The difference between that engagement and the previous one wasn’t the consultants’ technical competence. It was that the second time, the company knew what to ask for.