To evaluate an AI consulting proposal, check four things: who actually does the work, where the knowledge ends up when the engagement ends, what the pricing model rewards, and whether governance is built in from the first sprint or bolted on at the end. The clauses that predict dependency are visible in the SOW before any work begins. This checklist applies to every proposal — including ours.
By A2 Digital, an AI strategy and implementation firm. We publish our evaluation criteria because a client who can score any proposal — including ours — is the client we want to work with.
Why do bad AI proposals look rigorous?
Because rigor is easy to perform on paper. A proposal can have a detailed workplan, a methodology diagram, a governance section, and a wall of logos, and still be structured so that the firm’s knowledge, the firm’s platform, and the firm’s billable hours are what the engagement produces. The tell is never the polish. It’s the structure: who does the work, who holds what at the end, and what the money rewards.
The good news is that structure is legible. You don’t need to be an AI expert to evaluate an AI proposal — you need to know which clauses to read and what they usually mean.
What are the red flags in an AI consulting SOW?
| Clause you’ll see | What it usually means | What to ask for instead |
|---|---|---|
| “Client stakeholders will be engaged through regular status reviews” | Your team watches the work; it doesn’t do the work. The knowledge leaves when the firm does. | Named client staff in the working sessions as participants, written into the plan. |
| Kickoff goes straight to build; no discovery phase | The data foundation is being assumed. Most AI projects fail at the data layer, not the model layer. | A scoped discovery phase with its own deliverable, before any build commitment. |
| “Knowledge transfer and documentation” as the final phase | A binder, written by the firm, handed over at the end. Documentation written last is documentation written wrong. | Documentation co-written with your team throughout, in your language. |
| Delivery on the firm’s “platform,” “accelerator,” or proprietary components | You are renting your own system. Every future change routes through the firm. | Open standards on infrastructure you already own, stated in the SOW. |
| Hourly rates with an “estimated effort” | The estimate is a floor, not a price. Discovery that “finds something interesting” bills upward. | A flat fee for a defined scope, with milestone payments. |
| Governance / responsible AI as an optional workstream or add-on | Bias evaluation and audit trails get bolted on before the audit — which means they get added wrong. | Model cards, decision logs, and bias evaluation as build practices from sprint one. |
| The partners at the pitch, “delivery team to be assigned” | You’re buying the people in the room and getting different ones. | Meet the actual delivery lead before signing; the same people at kickoff and handoff. |
| No end state; success framed as “ongoing partnership” | Dependency is the product. The engagement is designed not to end. | A defined handoff with an on-call window that has a close date in the contract. |
One of these clauses is survivable; firms have templates and habits. Several together describe an engagement structured — not maliciously, just structurally — to leave you dependent on the firm that built it. The full anatomy of that failure pattern is in Why do AI consulting projects fail?
Should AI consulting be priced hourly or flat-fee?
For scoped work — a strategy phase, a discovery sprint, a defined build — flat-fee pricing is the structure that aligns the firm’s incentives with yours. The firm earns the same whether the work takes the estimated effort or more, so its interest lies in finishing well and transferring the capability. Hourly billing rewards the opposite: expanded discovery, upward scope clarification, and the post-handoff callback from a client who can’t modify the system.
Hourly isn’t dishonest, and for genuinely open-ended advisory work it can be reasonable. But for scoped work, a firm that won’t commit to a fixed price is telling you one of two things: it can’t define the scope, or it doesn’t want to. Either is worth knowing before you sign. Payment structure matters too — milestone payments tied to kickoff, a mid-engagement deliverable, and handoff keep both parties honest about progress. A large payment up front with vague milestones behind it is a softer version of the hourly problem.
Who will actually do the work?
The most reliable single question in proposal evaluation. Large-firm economics run on leverage: senior people sell the engagement, junior people staff it. Nothing in the pitch meeting tells you this; the SOW’s staffing language does. “Delivery team to be assigned,” unnamed “resources,” or a staffing pyramid with one partner over many “consultants” all mean the people you met are not the people you’ll get.
Ask to meet the actual delivery lead — the person who will run your working sessions — before signing, and ask whether that person stays from kickoff to handoff. A firm confident in its delivery team introduces them early. A firm that resists is answering the question by resisting it.
What should the deliverable actually be?
Not the system. The capability to run, extend, and govern the system after the firm leaves. A working model with no one internal who can modify it isn’t an asset; it’s a liability with a demo. Read the proposal’s deliverables list with one question: a year after handoff, when you need to add a data source or answer a regulator, what does this SOW guarantee you’ll have in the building?
Concretely, the deliverable should include: documentation your team wrote, an architecture on infrastructure you own, an audit trail a regulator can follow (decision logs, model cards, bias evaluations), runbooks your operations people have already used, and a team that participated in every consequential decision. If the deliverables list is a system plus a binder, the deliverable is dependency.
What questions expose a weak proposal?
Six questions, in the first meeting. A strong firm answers all of them specifically; a weak proposal survives none of them.
- Who exactly will do the work, and will we meet them before signing? Tests the staffing pyramid.
- What role do our own staff play in working sessions? “We’ll keep them informed” is the stakeholder model; the right answer names your people as participants.
- Who writes the documentation, and when? “We deliver full documentation at handoff” is the binder. The right answer is: your team, throughout.
- What happens when we need to modify the system a year after you leave? The honest answer describes your team doing it. The revealing answer describes a support contract.
- What in the deliverable do you own versus what do we own? Surfaces proprietary components and license dependencies that the SOW’s IP clause buries.
- When would you tell us not to build? A firm with no answer has never said it. A firm that can’t lose the build contract can’t be trusted to advise on whether the build should happen.
How should you use this checklist?
Score every proposal against it — including any proposal from us. We publish these criteria precisely because our own engagements are structured to pass them: flat fees scoped before work begins, your staff as co-builders in every session, co-written documentation, no proprietary stack, governance from sprint one, and a handoff with an end date. If a proposal of ours ever fails this checklist, that’s a conversation we want to have before you sign, not after.
And if another firm’s proposal passes it cleanly — genuinely passes it, in the SOW language and not the pitch deck — then you’ve found a good firm, and you should feel fine hiring them. The point of the checklist is a good engagement, whoever runs it.