How do you choose a good AI consultant?

Questions to ask before signing

A useful selection conversation should make the project clearer even before it starts. Ask for concrete examples and listen for trade-offs rather than certainty.

• Which process would you not automate, and why?
• What must be true before this can go to production?
• How will users review errors and exceptions?
• What will our team own when the engagement ends?
• How do you measure value beyond model accuracy?

Warning signs

Be careful with tool-first pitches, guaranteed savings without a baseline, hidden subcontracting, unclear data handling, and pilots that exclude maintenance, monitoring, or user adoption.

Select for delivery method, not model names

A strong consultant can explain how a business problem is investigated, tested and taken safely into operation. Familiarity with current models is not enough. Look for someone who connects process, data, technology, security and adoption and who can say when established software is a better choice than custom development.

• Ask for related problem types and concrete lessons learned.
• Invite the consultant to identify assumptions, risks and missing information.
• Confirm who will build and who remains available after launch.
• Discuss data, source code, documentation and supplier dependency.

What a good first conversation reveals

For an AI chatbot request, a capable consultant asks where answers come from, who maintains knowledge, which questions must not be automated and how escalation works. They also test whether chat is the highest-value intervention. Better documentation or email automation may come first. That willingness to challenge the original request is a useful selection signal.

Use a short paid selection stage

For serious implementation, a compact discovery is more informative than a long free pitch. It shows how the consultant collaborates, analyses and communicates.

• Shortlist relevant experience and genuine solution independence.
• Give candidates the same case and context.
• Request method, deliverables, team, timeline and risk view.
• Ask the preferred candidate to run a bounded discovery or technical spike.
• Review quality, collaboration and handover before the larger commitment.

Apply a simple evaluation framework

Do not choose on personal rapport alone. Let business and technical stakeholders score candidates against the same criteria.

• Understanding of the process and business outcome.
• Technical depth, security awareness and realistic assumptions.
• Communication, documentation and capability transfer.
• Total cost, independence and clarity of support.

Recognise warning signs

Be cautious about guaranteed savings without a baseline, a solution fixed before discovery, unclear subcontracting or reluctance to discuss limitations. A polished demo using fictional data says little about integration and daily operations. Ask how failures are identified, who is accountable and what happens when the underlying model changes.

Use a weighted selection scorecard

Good chemistry matters, but it is not enough for an investment involving data and core processes. Agree criteria and weights with business, technology and management before meeting suppliers. Score problem understanding, technical delivery, security, adoption and independence. Have evaluators score separately before discussing the results. This reduces the influence of a polished pitch and makes the trade-offs between candidates explicit.

• Business understanding and measurable outcome: 25 percent.
• Engineering, data, integrations and security: 30 percent.
• Delivery method, collaboration and adoption: 25 percent.
• Ownership, handover, total cost and continuity: 20 percent.

Verify the evidence behind cases and demos

Ask what the consultant personally delivered, which constraints applied and what happened after launch. A relevant case need not come from the same industry, but its process risk and integration complexity should be comparable. For technical work, discuss code quality, testing, logging and documentation. A mature delivery approach can be demonstrated without exposing confidential client information or making unsupported performance claims.

• Ask about a failure or surprise and which decision changed as a result.
• Confirm who in the proposed team is genuinely available and accountable.
• Discuss continuity when a model, supplier or key team member changes.

Use discovery as a mutual working test

A paid, bounded discovery reveals more than another proposal. Give the preferred candidate a real process question, limited access and explicit acceptance criteria. Evaluate the output and also the quality of questions, user engagement, learning speed and openness about uncertainty. Ensure all findings belong to the client so the phase retains value even if another party completes the implementation.

• Expect a process model, risk log, options and a justified recommendation.
• Test at least one critical assumption with data or a technical experiment.
• Finish with scope, budget, acceptance criteria and transferable documentation.

Agree the essentials before granting access

The contract should cover confidentiality, permitted data use, intellectual property, subcontractors and deletion of test data as well as price and timing. Define which accounts are owned by the client and how documentation is maintained. These details prevent a productive working relationship from becoming a continuity or ownership problem later.

• Use client-controlled accounts for cloud services, repositories, APIs and domains.
• Specify which code, prompts, datasets and configurations will be transferred.
• Include a practical exit and handover period in the engagement.