Hiring AI consulting and AI integration services: what to ask before you sign
Advice, AI integration services and custom AI software development are sold under one name. These are the questions we would want a buyer to ask any firm, including us, and the scope lines that decide whether a first pilot can reach production.
What AI consulting covers, and which one you are buying
The phrase covers at least three purchases. They produce different things, carry different risk and are billed in different ways. Ask a firm which one they are proposing on the first call, and ask them to say it in one sentence.
| What you are buying | What you hold at the end | What to settle before you sign |
|---|---|---|
| Advice and assessment | A written opinion: candidate use cases, a ranking, a plan | Who would build the thing the plan recommends, and what that would take |
| AI integration services | A model connected to systems you already run, with scoped access and logging | Which systems, which permissions, who reviews the output |
| Custom AI software development | Software your company owns, built around one workflow | Who holds the code, the prompts and the evaluation data |
| Pilot and production support | A running system with maintenance terms in writing | Who upgrades it, who answers when it breaks, what it costs each month |
One firm can do several of these. Trouble starts when the contract describes one and the sponsor is expecting another. Write the sentence down and read it back to them.
Questions to ask an AI consulting firm before you hire
These are the questions we would want a buyer to ask us. Each one has an answer that tells you whether the firm has done this work before.
Which workflow would you start with, and why that one?
A good answer names one workflow, says who does it today, and gives a reason tied to your business: volume, a backlog, a cost, a known error, a person about to retire. A weak answer stays at the level of departments and opportunities.
What data access do you need, and how would it be scoped?
A good answer is specific about which systems, which records and which permissions, and it expects your IT or data partner to set the boundary. It includes a test where a permission is missing or revoked and the system stops. Be careful with an answer that leaves access as paperwork for later. In most projects the access review is the longest step, and starting it late is what pushes a date.
What happens when the system is wrong?
Every workflow produces a case the rules did not anticipate. A good answer describes where that case goes: who sees it, how it is logged, how a correction gets made and how it reaches the next run. If the answer is that the model is accurate, ask again about the tenth case in a thousand.
How will we know whether it worked?
A good answer starts with a baseline measured before anything is built, and a pass condition written and signed before the work starts. It names the reviewer and the date when someone decides. Our pilot acceptance checklist lists the six items we agree before a pilot begins. Take it to every firm on your list.
Who owns the code, the prompts and the evaluation data?
Ask where the code lives while the project runs and who holds it afterwards. Ask the same about prompts, test sets and the logs the system produces. Those assets are what make a second project cheaper than the first. Ask what you would hand to a different firm if you continued with someone else.
What is the evidence behind that number?
Sales material in this market quotes failure rates, payback figures and adoption shares. Ask which organization published the number, on what date, from what sample, and whether it is a forecast or a measurement. Several of the figures in wide circulation are forecasts, small samples or vendor-sponsored surveys, and the caveats fall away as they get repeated. We keep those numbers off our own pages for the same reason. A firm that can source its claims will do it on the call.
What would it take to run this in production?
Ask this while the pilot is still being scoped, because the answer changes the scope. A good answer covers hosting, monitoring, the access model at full volume, the operating cost for each case, and who is on call. A firm that can only describe the pilot is selling you the pilot.
What would make you tell us to stop?
A good answer exists. Ask which results would make them recommend stopping, then write those conditions into the acceptance criteria.
Who does the work, and what else are they working on?
Ask for the names of the people who will write the code and design the workflow, and ask whether they are on the call. Ask how many other projects they carry at the same time, and who reads the logs when something breaks at the end of a quarter. The answer matters more than the size of the firm.
How to scope a first pilot so it can reach production
Getting from an AI pilot to production is a scope decision taken at the start. Pilots stall when the production questions are saved for the week after the pilot passes, because by then the budget, the access review and the support terms all have to be found at once. Settle these lines before anyone builds.
| Scope line | What to write down |
|---|---|
| The workflow | One workflow, its weekly volume, and the people who do it today |
| The user group | The small group who will use it against real work, by name |
| Access | Which systems, which permissions, who grants them and who reviews them |
| Baseline | How the workflow performs today, measured before the build starts |
| Acceptance | The pass condition, the reviewer, and the date the sponsor decides |
| Exceptions | Where a wrong result goes, and who handles it that day |
| Rollback | How the workflow returns to its current process, tested once for real |
| Production terms | Hosting, maintenance, support and the monthly operating cost |
Two habits help as much as the list. Keep the first pilot small enough that stopping is a reasonable outcome, so the decision stays honest. And keep the systems it touches to the smallest set that still makes the result real, because every extra connection adds its own access review.
A pilot scoped this way can end three ways: stop, extend against a revised baseline, or move to production. All three are legitimate. What you are buying is the evidence to choose, and evidence that points at stopping has still earned its cost.
Questions buyers ask
What is the difference between AI consulting and AI integration services?
Consulting can end with a document. AI integration services end with a model connected to the systems you already run, with scoped access, logged actions and a person reviewing the exceptions. Ask which one the proposal covers, and ask what exists on the final day of the engagement.
How much do AI consulting services cost?
It depends on the workflow, the systems it touches and how long the access review takes. We publish no price list, because the scope decides the cost. Ask any firm for a fixed scope and a fixed quote on one mapped workflow, and compare those. A quote given before anyone has mapped the process is a guess.
When is custom AI software development the right purchase?
When the workflow is specific to how your business runs, when the actions have to land in systems you own, and when you need the rules and the audit trail to be inspectable by your own people. If a product you already license covers the workflow as it comes, start there and measure it. That measurement becomes the baseline for anything you build later.
Do we need our own AI or data team first?
It helps, and it is a lower bar than most people assume. You need someone who can grant and review data access, and a process owner who can say what a correct result looks like. Without those two people the project waits, whoever you hire.
Using this with us, or without us
Take these questions to every firm you are considering. The firm that answers the access question and the stopping question well is usually the one that has done this before.
If you want to talk about one workflow, tell us which one, who does it today, and what a passing result would look like.