Questions to ask before choosing an AI consultant

Choose an AI consultant by how clearly they connect a business problem to a deliverable you can assess. A persuasive demonstration is useful background, but it does not establish that the proposed system will work with your information, permissions and team.

Use the questions below in introductory calls and proposals. Compare the answers in writing so that experience, assumptions and exclusions remain visible.

Check who will do the work

Ask for a relevant project the supplier is allowed to discuss. Clarify what they personally delivered, what was tested and what the client actually measured. A named case study is stronger when its scope and limitations can be checked; an unapproved logo or anonymous claim is not a substitute.

Ask who will lead discovery, implementation, testing and handover. If subcontractors are involved, understand their role and access. A consultant may be a good strategist without being the right technical implementer, or vice versa.

Look for questions about the process

A useful discovery conversation covers the people doing the work, the current systems, the information required, common exceptions and the consequences of an error. Tool selection should follow those facts.

Ask whether a simpler process change or conventional automation could solve the problem. The supplier should be able to explain where AI adds value and where it would add unnecessary uncertainty.

Twelve questions for the first conversation

1. Which comparable work have you delivered, and what evidence can you share?
2. What parts of that work did your proposed team actually perform?
3. Can we speak to a reference client with their permission?
4. What would you need to learn about our process before recommending a tool?
5. What is included in discovery and what will we receive?
6. How will we define acceptable output and compare it with the current process?
7. What are the likely failure modes and how will they be tested?
8. What information will you and your suppliers need to access?
9. Who approves external actions and changes to important records?
10. What is included in the fee, and what costs can change?
11. Who owns the code, accounts, documentation and outputs?
12. What support, recovery and exit arrangements will we have after handover?

Compare the commercial terms fairly

A day rate, fixed fee and monthly retainer describe different charging structures. None tells you whether the scope is complete. Ask for deliverables, assumptions, exclusions, dependencies, payment stages, change control and applicable taxes in the written quote.

Separate supplier work from software subscriptions, API usage, hosting and maintenance. Where fees depend on an outcome, agree the baseline, calculation, attribution and review process before treating the arrangement as predictable.

See Blue Canvas pricing for our published starting points. Do not treat one supplier's price as a market-wide rate or assume a quoted build includes indefinite support.

Agree what the engagement should produce

Discovery should leave you with an understood problem and dependencies. Planning should identify the proposed workflow, options and measures. Implementation should produce tested work within the agreed boundary. Handover should explain how to operate, monitor, change and recover it.

The timetable depends on access, complexity, review and the people needed. Ask for milestones and acceptance criteria instead of accepting a standard promise that every project takes the same number of weeks.

Recognise weak proposals

• Specific returns promised before the supplier understands your baseline.
• Unclear responsibility for checking output or authorising changes.
• No explanation of data access, suppliers or retention.
• Demonstrations presented as measured client outcomes.
• Costs or lock-in arrangements that remain unclear after questions.
• No workable handover, support owner or way to stop the system.

A preferred platform or long-term contract is not automatically a problem. Ask why it fits the task, what alternatives were considered and what happens if the relationship ends.

When an internal trial may be enough

You may be able to run a small internal experiment when the task is understood, the information is approved and someone has time to check the output. External help is more useful when the team needs specialist implementation, independent challenge or a capability it does not currently have.

Our DIY-versus-consultancy guide explores that decision. If you want to discuss a defined process, see Blue Canvas AI consultancy.