You hired an AI consulting firm. They ran workshops. They interviewed your team. They produced a comprehensive AI strategy presentation with a technology roadmap, a list of recommended vendors, and a prioritised list of use cases. The engagement closed. You have a deck.
Six months later, nothing has been built.
This is the most common outcome of AI consulting engagements. Not because the consultants were dishonest. Because the engagement was structured to produce documents rather than outcomes. The deliverable was information transfer, not capability building. And you paid for information you could have found by reading the right articles.
Good AI consulting looks completely different. This article tells you what it should deliver, what red flags to watch for, and how to evaluate a consulting partner before you sign anything.
Why most AI consulting fails to deliver lasting value
The failure mode is structural. Most AI consulting firms are organised around the sale of expertise, not the delivery of working systems. Their incentive is to produce comprehensive, impressive-looking outputs that justify the engagement fee and position them for the next engagement. A 40-page strategy deck is easy to produce, difficult to dispute, and creates a natural opening for a follow-on engagement to implement the strategy.
The problem is that a strategy without implementation is not valuable. A technology roadmap without a working system is not valuable. A vendor comparison without a deployment is not valuable.
According to McKinsey’s 2024 research on AI consulting effectiveness, which surveyed enterprise leaders on what drove measurable returns from external AI advisory engagements, the highest-value AI consulting engagements are consistently characterised by concrete, scoped deliverables tied to business outcomes, not by breadth of strategic analysis. The length of the strategy deck is inversely correlated with the likelihood of implementation.
Good AI consulting produces artefacts your team can use, systems your engineers can own, and a capability that exists inside your organisation after the consultant leaves.
What good AI consulting must deliver
These six deliverables are what a good AI consulting engagement should produce. Measured against a proposal or a completed engagement, any missing items represent a gap that will cost you time or money later.
A specific, measurable use case. The engagement begins with a problem definition session and ends with one sentence – what the model is predicting, in what time window, to what performance standard, and what the business does with the output. Not “AI strategy.” One specific use case with a numeric success threshold. If the consulting engagement cannot produce this in the first session, it cannot produce a working model.
An honest readiness assessment. A good AI consultant tells you what is actually missing from your organisation, not what you want to hear. The gaps in your data, your infrastructure, and your team are named explicitly, with a plan for closing each one before the build begins. A consulting firm that tells you everything is in place before looking at your actual data has not done an honest assessment.
A working baseline model. The first engagement should end with a deployable model – not a proof of concept, not a demo, not a notebook with results on a public dataset. A model trained on your actual data, evaluated against your actual baseline, versioned in a registry, and ready for production review. If the first deliverable is not a model, the engagement has not built you closer to production.
Infrastructure that supports the model long-term. Good consulting delivers not just the model but the prediction logging, drift monitoring, and retraining trigger that keep the model working after the consultant leaves. A model without this infrastructure is a liability that will degrade silently until it causes a problem nobody can diagnose. The infrastructure is not optional.
Knowledge transfer to your team. Your engineers should understand what was built, why it was built that way, and how to change it. A good engagement ends with documented architecture, runbooks, and at least one internal session where the consulting team walks your engineers through the system. If your team cannot own the system independently after the engagement, you have not received what you paid for.
A defined next step, not a retainer pitch. The engagement ends with a clear, scoped next action – a specific piece of work, a timeline, and an outcome. Not an open-ended proposal for continued involvement. Good consultants build you toward independence, not dependency. If the exit of every engagement is a proposal for more engagement, that firm is optimising for their revenue, not your outcome.
The 7 red flags in AI consulting
Any of these signals in a first meeting or a proposal is enough to walk away.
They propose a strategy deck before understanding your data. Strategy without data analysis is opinion. A consultant who can produce a technology roadmap in the first week of an engagement has not looked at your actual situation. The roadmap is a template with your name on it.
They cannot define what success looks like in numbers. “We will help you become more AI-ready” is not a success metric. If a consultant cannot tell you what specific metric improves and by how much, they are not accountable for the outcome. The vagueness is not accidental it protects them from evaluation.
They recommend the most expensive tools by default. The right tool is the one that fits the problem. A consultant who leads with the largest LLM or the most comprehensive platform without asking what your actual data looks like is either not experienced enough to know the alternative options or has an incentive to recommend the expensive path.
They have no experience shipping production ML systems. Consulting that has never deployed a model to production cannot tell you what breaks in production. The difference between a model that works in a notebook and a model that works in a production environment is substantial and learnable only through direct experience. Presentations do not substitute for this.
The engagement has no defined end state. An open-ended engagement with vague deliverables and rolling retainer fees is structured for the consulting firm’s benefit. Every engagement should have a defined scope – these are the deliverables, this is the timeline, this is how we know it is done. If the proposal does not include these, the engagement does not have them.
They do not ask about your team’s ability to own the output. A model your team cannot maintain is a liability. A consultant who does not ask about your internal engineering capability before proposing a technical solution has not thought about what happens after the engagement. This question should come up in the first conversation.
They cannot explain trade-offs between approaches. Every AI approach has trade-offs – cost, explainability, accuracy, latency, maintenance burden. A consultant who cannot articulate these for your specific use case is presenting options without advising on them. The ability to explain why one approach is wrong for your situation is a better signal of capability than the ability to explain why an approach could work.
Questions to ask before the engagement starts
These six questions should be asked in the first meeting. The answers tell you more about the consulting firm’s actual capability than their proposal does.
Can you show me a production ML system you have shipped for a company at our stage? The answer should include a specific use case, the model type, the infrastructure used, and a measurable outcome. A firm that has deployed models for companies at a similar scale to yours knows what breaks at that scale. A firm that has not does not know yet.
What will the deliverable at the end of this engagement look like specifically? The answer should describe a physical artefact – a model file, an evaluation report, a deployed endpoint, infrastructure documentation, a gap closure plan. If the answer includes phrases like “strategic clarity” or “alignment on the AI roadmap,” the deliverable is a document.
How do you define success for this engagement? The answer should be a specific numeric metric tied to a business outcome, agreed before the work begins, evaluated against a baseline. If the consultant cannot answer this question in the first meeting, the engagement does not have a success criterion.
What do you need from us to start? A good consultant needs access to data, a named internal owner, and a problem definition session. They need specific things from you. If the answer is “we will figure that out as we go,” the engagement is not scoped.
What happens after the engagement ends? The answer should include a handoff plan, documented architecture, a runbook, and a clear answer on what your team needs to maintain the system. If the answer leads toward another engagement rather than internal ownership, that is a signal about how the firm makes money.
What approach would you NOT recommend for this problem and why? This is the most revealing question. A consultant who cannot name a specific tool or approach that does not fit your situation, with a clear explanation of why, is not advising you. They are presenting options. The ability to say “I would not recommend X because of Y” is a demonstration of actual expertise.
What those deliverables should actually look like
The table above shows the gap between what consulting firms call their deliverables and what those deliverables should actually be. The naming is not dishonest, an “AI Strategy” is a real engagement type. The question is what it produces.
A working proof of concept on your actual data is worth more than a comprehensive AI strategy on paper. A 60-day plan with specific milestones is more useful than a 12-month technology roadmap. A problem definition session that ends with a written use case produces something you can act on today. A workshop that ends with a summary presentation does not.
The test for any deliverable is simple – can your team use this to build something tomorrow? If the answer is no, the deliverable is information, not capability.
How to evaluate an AI consulting partner mid-engagement
If you are already in an engagement and questioning whether you are getting what you should be, these are the signals to evaluate.
By the end of week two, the consulting team should have reviewed your actual data and produced a written assessment of what is in it, what is missing, and what it can be used for. If week two ends with a presentation of the AI landscape and use case possibilities, the engagement has not started on your problem yet.
By the end of week four, there should be a working baseline model or clear evidence that the data preparation required to build one is underway. If week four ends with a strategy document, the engagement is on the wrong track.
By the end of the engagement, your engineers should be able to explain what was built and how to change it. If the knowledge lives entirely with the consulting team and your engineers are spectators, the engagement has not transferred capability.
According to the IEEE’s standards on responsible AI deployment and software engineering ethics, which define the accountability requirements for AI system deliverables in professional practice, a professional AI engagement that leaves a client with a system they cannot understand, maintain, or modify does not meet the standard of responsible practice. The consulting firm that builds dependency is building a client relationship, not delivering a service.
The standard for a good AI consulting engagement is that you are in a better position at the end of it than you were at the start, not just more informed, but more capable. A working model, a team that understands it, and a clear next step you can execute yourself.
If that is not what your current or prospective AI consulting partner is delivering, Mallow’s team works differently. Start with a conversation about what you actually need.
Your queries, our answers
A well-scoped AI consulting engagement has three components - a defined problem statement (one sentence, with a numeric success metric), a specific set of deliverables (model artefact, infrastructure design, gap closure plan, knowledge transfer session), and a defined timeline (typically four to eight weeks for a first engagement). Any proposal that lacks these three components is not sufficiently scoped.
The cost varies significantly by scope and team size. What matters more than the absolute number is what the fee buys. A four to six week engagement that produces a working baseline model, a production-ready infrastructure design, and knowledge transfer to your team is a different purchase than a four to six week engagement that produces a strategy deck. Evaluate the deliverables, not just the number.
AI consulting typically refers to advisory work - assessment, strategy, problem definition, and recommendation. AI implementation refers to the hands-on engineering work of building, deploying, and maintaining the system. The most effective engagements combine both consultants who can advise and build, rather than advise and hand off to a different team for implementation.
Ask for specific examples of production ML systems they have deployed, with enough detail to evaluate the technical complexity - the model type, the data pipeline, the serving infrastructure, the monitoring setup, and the measurable outcome. A firm that cannot provide this level of specificity has not shipped production systems at the level they are describing.
Address it directly, early, and in writing. Identify the specific deliverable that is missing or delayed, the agreed timeline for it, and the impact of the gap. A good consulting firm will respond with a concrete remediation plan. If the response is defensive or vague, you have the information you need to make a decision about the engagement.
What happens after you fill-up the form?
Request a consultation
By completely filling out the form, you'll be able to book a meeting at a time that suits you. After booking the meeting, you'll receive two emails - a booking confirmation email and an email from the member of our team you'll be meeting that will help you prepare for the call.
Speak with our experts
During the consultation, we will listen to your questions and challenges, and provide personalised guidance and actionable recommendations to address your specific needs.
Author
SathishPrabhu
Sathish is an accomplished Project Manager at Mallow, leveraging his exceptional business analysis skills to drive success. With over 8 years of experience in the field, he brings a wealth of expertise to his role, consistently delivering outstanding results. Known for his meticulous attention to detail and strategic thinking, Sathish has successfully spearheaded numerous projects, ensuring timely completion and exceeding client expectations. Outside of work, he cherishes his time with family, often seen embarking on exciting travels together.

