Before hiring an AI consultancy, ask seven questions: what is running in production two quarters after launch and can I call the client; who owns what we pay you to build; who exactly does the work; how do you price and why; what do you decline; how do we measure success; and how do we part ways. The answers separate firms that build systems from firms that sell engagements — and so does the speed and comfort with which each question is answered. This article gives each question its reasoning, and describes what a good answer and a bad answer actually sound like, so the conversation tells you something before the contract does.
"What is in production two quarters after launch — and can I call them?"
Why it matters: the AI consulting industry's central defect is that pilots are billable whether or not anything survives. The only evidence that discriminates is a system still running, still measured, months after the consultants left. Two quarters is the honest window — long enough for accuracy drift, staff turnover, and the exception queue to have tested the build.
A good answer names clients and offers calls within days: "Speak to their operations head — the system has processed documents since last year, here is what it saves against the baseline, and here is what broke in month three and how it was fixed." The willingness to include what broke is itself a signal; production systems always break somewhere.
A bad answer is anonymised case studies, NDAs invoked as a wall rather than a process, or references only from projects still in pilot. A firm with happy production clients has no difficulty producing them; reference-dodging almost always means the pilots quietly died.
"Who owns the IP — the code, the models, the prompts?"
Why it matters: AI engagements produce assets — pipelines, fine-tuned or configured models, prompt libraries, evaluation sets, integration code — and if the contract is silent or vague, you may discover you have rented your own system. Worse, models improved on your data can end up as the firm's reusable asset, sold onward to your competitors.
A good answer is boringly specific: work product is yours on payment; anything trained or tuned on your data is yours; the firm retains only its pre-existing tooling, which is listed by name in the contract; and nothing in the running system requires a licence from them to keep operating.
A bad answer waves at "standard terms," bundles ownership into an ongoing subscription to the firm's platform, or distinguishes lawyer-carefully between your "use" of the system and their "ownership" of it. If a proprietary platform is genuinely part of the value, that can be a legitimate trade — but it must be priced and chosen consciously, with the dependency understood, as part of a deliberate build-versus-buy decision.
"Who exactly will do the work — and can I meet them before signing?"
Why it matters: the oldest consulting trick is the bait-and-switch bench — partners and principal engineers sell the engagement, then delivery arrives with people you have never met. In AI work the variance between a strong and a mediocre engineer is enormous, so who is not a staffing detail; it is most of what you are buying.
A good answer: named individuals, their roles, their allocation, and a working session with them before the contract — where you ask them, not the partner, how they would approach your problem. Add a substitution clause: key names replaced only with your approval, with equivalents.
A bad answer: "we will assemble the right team after kick-off," or a rate card of anonymous grades. That is a firm selling capacity, not capability.
"How do you price — and why that model?"
Why it matters: the pricing model shapes the firm's incentives for the entire engagement. Open-ended time-and-materials rewards duration; fixed-scope rewards finishing; outcome-linked pricing rewards results but requires a measurable baseline both sides trust. None is inherently wrong — what matters is that the firm can explain why its model fits your project's uncertainty, and what happens when scope shifts.
A good answer offers a fixed-scope entry — often an assessment or first phase — with priced options beyond it, and can decompose any figure into its drivers. A bad answer resists all fixed pricing, or quotes a number that cannot survive the question "what makes it that much?" — the model should be an argument, not a habit.
"What work do you decline?"
Why it matters: expertise has edges. A firm that knows its edges will name sectors it does not serve, problems where AI is the wrong instrument, and projects it has walked away from because the data or the sponsorship made success impossible. That discernment is exactly what you are hiring — a firm that cannot say no to a bad project cannot be trusted to say no to a bad idea inside yours.
A good answer includes a story of declined revenue and a recommendation of something other than AI: "they needed process redesign first" or "a product already does this — buy it." A bad answer is "we can do anything in AI," delivered as a selling point.
"How will we measure success — against what baseline?"
Why it matters: without a pre-agreed baseline, every project succeeds in the retelling. The measure must be operational — hours removed, error rates cut, cycle time shortened, against the workflow's measured current cost — not activity metrics like models deployed or workshops delivered.
A good answer insists on establishing the baseline before building, and welcomes the number being in the contract. Firms comfortable with measurement often propose a diagnostic phase to produce exactly that denominator — the shape of which is described in what an AI audit should include. A bad answer defers measurement to "once we see how it goes," which means never. If a firm resists baselines, note that this is the strategy-deck business model in disguise; the difference between firms that advise and firms that are accountable is the subject of AI strategy versus implementation.
"What does handover look like when we part ways?"
Why it matters: every engagement ends. The question is whether it ends with your team running the system or with a dependency that renews itself annually by default. Exit terms negotiated at the start cost nothing; negotiated at the end, they cost whatever the firm decides.
A good answer treats handover as a deliverable: documentation a new team could operate from, training for your people, credentials and infrastructure in your name from day one, and a defined transition period. A bad answer keeps infrastructure in the firm's accounts, documentation "available on request," and offers a support contract as the answer to every continuity question.
Using the questions
Put all seven to every shortlisted firm in the same meeting, with the delivery team present, and compare answers side by side — the exercise pairs naturally with the market segmentation in AI consulting firms in India. Score reactions as well as content: the firms worth hiring find these questions easy, because the answers are simply descriptions of how they already work. The firms to avoid find them adversarial, because the answers would be admissions. One question answered badly is a negotiation point. Three answered badly is your answer.