AI Consulting: What It Delivers and Where It Stops

"We paid external consultants and came away with nothing." I hear that sentence a lot. Usually it isn't quite true.

They received something. A document with 80 pages, a clean analysis, a maturity model, recommended actions, an 18-month roadmap. What they didn't get was anything that runs on a computer and does things.

That is not a rip-off, and it usually isn't bad work either. It is precisely what AI consulting delivers as a format. The problem starts when you expected something else.

What AI consulting is genuinely good at

There are situations where consulting is the right tool, and it is only fair to start there.

Getting your bearings in the market. Which providers exist for a given problem, what do they cost, who is credible? If you are doing this for the first time, outside market knowledge saves you real money.

Architecture and security questions. Where is which data allowed to sit, what does a system landscape that will hold up look like, what does that mean for your existing IT? That is specialist knowledge, and it is worth paying someone for it.

An uncomfortable outside view. Sometimes you need someone from outside to tell the management team that the pet project doesn't work technically or financially. Internally, nobody wants to be the one who says it.

Political cover. Not pretty, but real: if a decision needs backing in front of the shareholders, an external assessment carries a weight that an internal one never will.

For all of that, consulting is a sensible expense. None of it answers the question of whether AI actually works in your specific case.

Where AI consulting structurally stops

Consulting ends where responsibility for a running result begins. That isn't a matter of character, it is built into the business model.

A consulting project is successfully closed once the analysis is delivered and the recommendation is handed over. Whether the recommendation then gets implemented depends on your organisation, your IT capacity and your budget in the next financial year. That is exactly where most AI initiatives quietly run into the sand.

There is a second effect that gets discussed far less often: the knowledge walks out with the consultant. Whoever did the analysis learnt in the process how the company really ticks and what makes it different. That person leaves the building when the project closes.

So when the next use case comes along, you start from zero again. And you pick up the phone again.

The order is usually backwards

The standard sequence looks like this: strategy first, then a roadmap, then a pilot project at some point.

That sounds reasonable, but with AI it is often wrong. Writing an AI strategy before anyone in the company has ever built an AI prototype means you are planning on assumptions about what the technology can do in your context. Those assumptions are almost always off. Sometimes too optimistic, sometimes too pessimistic, rarely accidentally right.

After the first self-built prototype, a team's assesment of the situation looks completely different. Suddenly you know that one use case is trivial and another one falls apart on the data. A strategy built on that experience is worth considerably more than one written before it.

Which is why the cheaper route is usually: one small, real use case first, then the strategy. If you want to see how to carve out a use case like that from your own working week in half an hour, there is a free video with a template for exactly that.

Watch the free 30-minute video

How to spot a good provider

If you are buying AI consulting, a handful of questions in the first meeting will tell you more than any reference list.

1. What exactly am I holding in my hands on the last day? A document, or something that runs? Both are legitimate, but you should know which one you are buying.
2. Who builds it? My people or yours? If the answer is "ours", you are buying a dependency along with it. Fine short term; long term the knowledge has to be built up in-house.
3. What happens if the use case turns out to be unworkable mid-project? Good providers have a concrete answer and bury ideas early. Bad ones deliver something regardless.
4. How do we measure success? If the answer is "increased maturity" or "raised awareness", it can't be disproved, and that makes it worthless.
5. What will my people be able to do afterwards that they couldn't do before? Rarely asked, often answered with silence.

A good provider will tell you, on at least one of these questions, that their format isn't the right fit. That is a good sign, not a bad one.

Consulting, training, workshop

It helps to keep the three formats clearly apart, because they solve different problems.

Consulting answers "what should we do?". The output is a recommendation. Useful for market, architecture and investment questions.

Training answers "what even is this?". The output is a shared level of knowledge. Useful for the leadership team and strategists; the day-to-day work is better learnt on a live project.

A workshop answers "does this work here?". The output is a running prototype and a team that knows how it got there. Useful when a decision is due and nobody really knows the answer.

Most mid-sized companies buy formats one and two, then wonder why they didn't get the outcome of format three.

The fastest route to an answer you can rely on

If your real question is "does AI actually do anything for us in this process?", the fastest answer is not a report. It is an attempt.

The AI Hackathon is exactly that: a 2-day AI Innovation Workshop where your team takes a real process out of your own company and builds a running prototype for it in two days. No maturity model, no 18-month roadmap. What's left at the end is something you can put your hands on and demo, plus a team that can repeat the method.

You can still write a strategy afterwards. Just one based on experience instead of assumptions.

Check out the AI Hackathon

Back to overview