An AI project usually starts with time saved: less manual work, faster handling, lower cost per task. Those are valid goals. Two questions rarely make it onto the table, though: what does it really cost, and if this implementation works, who profits?
The two belong together. The party that carries the cost does not have to be the party that gets the gain.
What does an AI implementation cost?
Count on four items: building, hosting, oversight, and maintenance. You pay for the build once; the other three keep running as long as the system does. The biggest item is rarely the build. The most expensive thing is keeping a system running that should never have reached production.
Three things drive the build price most: how much material there really is, how many exceptions the process has, and how many systems it has to talk to. An agency that quotes a price without having seen those three is pricing on assumptions. Running costs depend mostly on how often the system is used and who watches over it.
With me it starts with a Scan: about a week of work, from €1,995 ex VAT. For each pilot I cost out those four items and say which one is not worth the money. Building then takes four weeks at most, at a fixed price agreed on paper up front. The breakdown is on my AI consultancy page.
Where are the hidden costs?
Mostly in three items that quotes tend to leave out:
- A price based on assumptions. I have seen proposals assume less material and fewer exceptions than there turned out to be. Work that seemed out of scope came back during delivery anyway. That is why I look at the material first and only then name a price.
- Billing by the hour. Whoever bills by the hour earns from overruns. An analysis that used to take two days takes two hours with AI. On an hourly rate, an agency has little reason to get faster.
- The next model version. The model that works today may be replaced within six months. Someone then has to test again, and that time is rarely in the budget.
Skip these items and they come back later as cancelled projects. Gartner expects more than 40 percent of agentic AI projects to be cancelled by the end of 2027, due to rising costs, unclear business value, or inadequate risk controls. The lessons behind this list are worked out in my memo on 35+ implementations.
Who profits from the productivity gain?
Within a role, mostly the least experienced staff; across the economy, mostly the large technology companies. An NBER study at a Fortune 500 software company, with roughly 5,000 support staff, found an average productivity gain of 14%. For the least experienced and lowest-performing staff the effect was around 35%, for the top performers almost zero. AI lifts the floor.
At macro level the gain lands elsewhere. Amazon, Microsoft, and Google together hold about 70% of the European cloud market (Synergy Research Group, 2026), so much of what companies spend on AI infrastructure goes to three American firms and their shareholders. Meanwhile the broad middle of knowledge work carries the adjustment risk: processors, analysts, junior consultants. The OECD and the WEF both name rising inequality as a major AI risk.
The Netherlands adopts quickly: 74.4% of Dutch SMEs have built AI into their operations. How the gain is shared inside those companies is not something that survey measures. The figures and their sources are on my AI statistics page.
Ask the question before the scope is fixed
A good discovery therefore includes this question: if this implementation succeeds, what happens to the people whose work changes?
I treat that as project risk. A system that makes people faster while hollowing out their role without anyone naming it will meet resistance. When it is clear up front who gains, who gets different work, and who keeps ownership, the system is more likely to be used.
That matches what I kept seeing in projects: adoption starts at the problem analysis. People who helped define the problem use the solution sooner. A training session after delivery does not make up for that.
What does the client keep, and what does the vendor keep?
An AI system that only runs while the builder stays involved is lock-in with a project price: the client pays for speed and is left with dependency.
You recognise such a system by what is missing. There is no owner at the client, no evaluation set, no runbook and no handover, so every change goes back through the builder. The maintenance line then grows every year, and that gain lands with the vendor.
A better implementation makes the client more independent. That is why my handover is a fixed list of five: one named owner, an evaluation set running on the client’s machine, a one-page runbook, an agreement on who steps in when something breaks, and a path for the next model version. The list is younger than most of the projects I draw on. The first engagement where the client has ticked off all five is still running.
Four questions for every AI implementation
Ask one question per party that stands to win or lose:
- Staff: whose work changes, and has that been named before the scope is fixed?
- Customers: do they notice the time saved, for example in faster handling, or does it stay internal?
- Shareholders: which part of the saving is measured against a baseline, and which part is a feeling?
- Vendor: does the system still run when the builder leaves, and who changes it then?
The answers to those four questions set the scope, what you communicate, who you involve, and what you hand over.
Want to read on?
The memo collects the lessons from 35+ AI projects: where pilots got stuck and what I do differently because of it. A 14-minute read.
30 minutes · free, no obligation