How to choose an AI automation consultant: what to check before you sign

By Edward Pinela · Founder, Lightray AI · 13 September 2026

Most advice on how to choose an AI automation consultant stops at "check their references". The commercial terms decide far more: who owns the accounts, whether the running cost was ever quoted, what handover actually includes, and what happens when the scope moves. We are one of the firms you would be evaluating, so weigh this accordingly.

What evidence can you actually check?

Ask for something verifiable rather than something claimed: a walkthrough of a system they built, screen-shared and running; the runbook they handed over with it; and two clients you may call without a chaperone. A firm that has delivered will have these to hand. One that cannot produce them is asking you to buy a description.

The walkthrough is the most informative of the three, because it is the hardest to stage. Watch what happens when they open the error queue, the logs, or the monitoring. Someone who runs production systems moves through those screens without hesitation and tends to volunteer the case that broke last month. Someone who has only built demonstrations will steer you back to the happy path.

Treat the claims in a proposal the way you would treat any other marketing claim: as something that ought to be substantiated before you rely on it. The FTC's guidance on keeping AI claims in check (opens in new window) is a reasonable lens on any proposal you receive, ours included. If a capability cannot be demonstrated, it is a roadmap item, and roadmap items belong outside the fixed scope.

Who ends up owning the accounts and the API keys?

The answer you want is that everything is built inside accounts you already control, on API keys issued from your own tenant, billed to your own card. An API key is simply the credential a system uses to call another system on your behalf. Whoever holds those keys holds the automation.

Two arrangements are worth separating. A consultant who works inside your accounts and hands the credentials back at the end is normal practice. A consultant whose deliverable only runs on their platform, their automation tenant, or their model account is selling a subscription with a build attached. That can still be a reasonable purchase, but you should know which one you are making before you sign rather than when you try to leave.

Put the exit in writing while everyone is still friendly. Name the accounts the work will live in, who holds the administrator role, and what happens to credentials, exported workflows and documentation if either side walks away. The question to ask out loud is short: if we ended this tomorrow, what would stop working?

Is the build cost quoted separately from the running cost?

Insist on two numbers rather than one. The build is what it costs to get the thing working. The run is what it costs every month afterwards: platform subscriptions, model usage, and the maintenance hours an upstream change will eventually demand. A quote showing only the first is not dishonest so much as incomplete.

The failure this prevents is the project that lands on budget and then accrues a running cost nobody sponsored. What drives each number, and why the AI itself is rarely the expensive line, is covered in our guide to what AI automation actually costs. For whether the pair of numbers is worth paying at all, how to measure automation ROI sets out the baseline to take before anybody starts building.

What does handover include, and how long is the defect window?

Handover should be a deliverable with a definition, not a final email. Ask what you receive: documentation another person could follow, a working session with whoever will operate it, monitoring that alerts a named owner, and a stated period during which defects are fixed at no charge.

That last item is the defect window, and vagueness there is expensive, because it is the boundary between a fault and a change. A workable version reads: for a defined number of weeks after go-live, anything not behaving as the agreed scope describes is fixed without further charge, while anything behaving exactly as scoped but no longer wanted is quoted as new work. Both sides can live with that. What nobody should accept is a boundary decided after the first disagreement.

Ask who supports the system in month seven, and what that costs. Honest answers range from a retainer to "you do, and here is the documentation that makes it possible". Either is fine. No answer at all is not.

How do they behave when the scope moves?

Scope always moves. What separates firms is whether the movement is visible. The behaviour to look for is a re-quote: the new work is described, priced and approved before it is done. The behaviours to avoid are silent absorption, which ends in a rushed build, and a surprise line on the final invoice.

You can test this before signing. Describe a plausible mid-project change — a second document type, an extra approval step — and ask what would happen. A firm with scope discipline answers procedurally and without irritation, because the procedure already exists. A firm without it answers with reassurance, and reassurance is what you will get again in week five.

The related signal is a willingness to say no. A consultant who agrees that every process you mention is a strong candidate has evaluated none of them. Ask which of your ideas they would drop and why. The answer tells you whether you are buying judgement or capacity.

Where does security due diligence fit?

Alongside the commercial checks, not inside them. The terms above decide what you own and what you pay. A separate set of questions decides what happens to your data, what the system is permitted to write to, and how anyone finds out when a step fails. Run both before you sign anything.

We keep that second set in its own guide — security questions to ask an AI automation vendor — precisely so neither list gets skimmed. For shared vocabulary in those conversations that does not come out of anyone's marketing, the NIST AI Risk Management Framework (opens in new window) gives both sides the same terms for data handling, human oversight and failure detection.

What does a workable engagement structure look like?

Staged, with a real decision point between assessment and build, and a fixed price agreed against a written scope before each stage starts. That shape protects you specifically because it lets you stop: an assessment can conclude the work is not worth doing, and you have then lost a stage rather than a project.

Our own engagement model is the worked example — the stages, what each delivers, and why the price follows the consultation rather than preceding it. Compare it against whatever you are offered. The useful question is not whether the stages carry the same names, but whether there is a point at which you can walk away having lost only the last one.

Do the preparation before you shortlist anyone, too. A documented process, accessible data and a named internal owner change what a consultant can quote and how fast; our AI readiness checklist covers what is worth having in place first.

Which answers should end the call?

Four of them. Refusing to let you speak to a client unsupervised. Declining to put the accounts and credentials arrangement in writing. Quoting a build with no running cost at all. And pricing a fixed scope before asking which systems are involved, which means the number is a guess you will end up paying for.

None of these are difficult questions for a firm that has delivered this work before, which is exactly why an inability to answer them is informative. If the answers do hold up, the next step costs nothing: describe the process on a free consultation and make the same firm prove it against your own systems.

Common questions about hiring an automation partner