Choosing an AI expert: assess value, delivery and quality

You are looking for an AI expert for your business. The useful question is not who can name the most tools. It is who can understand a specific workflow, design a testable improvement and hand over something your team can operate. This guide provides a practical evaluation framework, a worked example and questions for the first project discussion.

1. Define the problem before choosing an AI solution

“We want to use AI” is not yet a project brief. Describe an observable bottleneck instead: enquiries are entered twice, quotations receive no follow-up, documents need repeated checking or information is scattered across systems. Identify where the process begins and ends, who owns it and which exceptions occur.

A useful starting point might be: “Every incoming enquiry should appear in the CRM with complete information, an assigned owner and a visible response deadline.” Whether a language model is necessary remains an open question. A well-defined integration or rule may be more appropriate for parts of the task.

2. Separate fixed rules from language-model tasks

Matching identifiers, checking required fields and calculating deadlines can be expressed as fixed rules. Summarising an unstructured message or preparing a readable draft is a different type of task. A thoughtfully designed workflow may combine both approaches. Tests using your data and requirements should determine which solution actually fits.

Define which actions the system may take independently. Preparing a reply is different from sending it without approval. An internal classification is different from posting a financial entry or making a binding commitment. Consequential actions deserve explicit boundaries, review and a way to reverse or stop the workflow.

3. Examine six areas, not just an impressive demonstration

This is an original working aid, not a scientifically validated scoring model. Mark each answer as “supported”, “unresolved” or “unsuitable”. A critical unresolved question about permissions or responsibility should not be hidden behind stronger answers elsewhere.

4. Estimate usable capacity, not promised profit

Hypothetical example, not a customer result: Assume your team handles 200 cases a month, taking twelve minutes each. That is 40 hours. A tested replacement workflow takes an average of five minutes per case, including human review: about 16.7 hours. Allow another two hours for system checks and upkeep. The model therefore releases approximately 21.3 hours of capacity.

The calculation is 200 × (12 − 5) ÷ 60 − 2 = 21.33 hours. Released capacity is not automatically cash savings or additional revenue. Its economic value depends on whether it reduces overtime, enables more work or prevents quality problems. Implementation, ongoing software charges, training and failure risks need separate consideration.

Before starting, measure follow-up questions, rework and unresolved cases as well as average handling time. Otherwise, a faster first step may merely transfer work to someone further down the process.

5. Agree on a bounded pilot

Begin with one workflow and a defined dataset rather than transforming the entire organisation. Include ordinary cases, incomplete inputs and difficult exceptions. Specify the expected treatment of each case before seeing the new system's answer. Keep a separate set of cases for final acceptance.

Test failure paths too. What happens when an integration is unavailable, an enquiry arrives twice or a required field is missing? Can a person take over? Is confidential information retained unnecessarily? Can you identify which workflow version produced an output? Only use data you are authorised to process; legal questions must be assessed for the actual application.

NIST's voluntary AI RMF Playbook provides a broader starting point for examining AI risks. It is not a replacement for project-specific evaluation or proof that a particular system is suitable.

6. Put handover, costs and boundaries in writing

Record the included functions, explicit exclusions and acceptance criteria. Clarify account access, operating documentation, export options and how changes will be handled. Recurring licences and support costs should appear alongside the implementation price rather than emerging only after the contract is signed.

Ask for relevant work samples that the provider is authorised to share, and establish their actual role in each project. A certificate may contribute to the evidence, but it does not replace task-specific competence. Equally, confidential customer material should not be disclosed without permission merely to make a sale.

Checklist for the first conversation

• Which single workflow are we improving, and who owns it?
• Which baseline measurements and failure cases can we document?
• Which data, integrations and approvals does the pilot require?
• Which quality threshold must always be met?
• How can we stop the workflow or hand it to a person?
• Which costs, maintenance duties and dependencies remain after launch?

From understanding to implementation

AI Expert: AI and automation for revenue optimization introduces the relationship between technology and business workflows. This article adds an independent decision aid to the book presentation; it is not a reproduced chapter.

For a specific project, review the scope of AI consulting and IT consulting for businesses and the software projects presented on this website. Compare these with your requirements. The useful next step is a clear process brief, not a premature commitment to a particular tool.