If your GenAI business case doesn’t contain these items, you’re cooked.

I can only speak from personal experience, but I’ve severely underestimated some of the figures presented here in the past. The optimism I have for GenAI, and the optimism that’s part of my personality, made me learn some hard lessons.

Let me show you how gross savings don’t always translate into great ROI figures when implementing GenAI.

Supervision costs

Starting with supervision costs. Even when you’re able to displace significant volume with AI, you’d still need combined business and tech effort to keep track of what the LLMs actually do. As in: the LLM will run, but almost certainly is going to make mistakes. People need to find these and make edits to the software to make sure it keeps performing well.

The ratio depends on the deployment in my experience. Simpler work carries proportionally more supervision overhead, as you still need an eval function, and that fixed cost eats a bigger share of smaller savings. Factor in 15-25% of gross savings. Sometimes more.

People consistently read this as a temporary cost that fades once the system settles. In my experience it drops after the first months and then flattens out, because the inputs keep changing even when the system does not.

Run costs

Second, LLM calls, platform costs, integrations all need to be accounted for. Simple customer service queries like password resets require simpler models. Detailed replacement order flows with customized logic require more advanced ones. Expect 5-15% of your gross savings, depending on model complexity.

This is the line that moves after go-live, usually upward, because volume grows once people start trusting the thing. Worth setting the expectation that your first month is not your steady state.

Error handling

In the same vein, catching those errors is something different than solving for the moment when the LLM gets it wrong. When it handles a replacement order wrongly, someone needs to correct this in the system, contact the customer, make amends. Depending on the complexity, expect another 10-25%.

The cost here follows the consequence rather than the error rate. A wrong draft that someone deletes costs you nothing. A wrong action that reached a customer costs you the correction, the contact and sometimes the goodwill.

The build, spread over time

Finally, the build itself. You spend a chunk up front, say €40K. You don’t put that against year one’s savings, you spread it across the years you’ll use the tool. Three years is the accounting default, but for AI it’s closer to two because models change so fast.

And build cost isn’t just developer time. It’s discovery, vendor selection, integration, security review, training, and the annoying first months after go-live.

Two years rather than three is a meaningful difference in the model. It raises the annual charge by half, and it is the assumption most likely to be challenged in a steering committee, so it is worth saying out loud why you picked it.

What the range looks like end to end

A deployment running cheap models on simple work with a mature eval setup lands near the 20% net floor of erosion. A year-one deployment running premium models on transactional work without proper supervision lands near 65%. While they follow the same framework, they lead to very different outcomes.

Which is why a single blended percentage borrowed from someone else’s deck is not much use. The spread between those two cases is wider than most of the savings being argued over.

As such, I advise executives to pressure-test each line against the deployment they’re actually building. If you can’t defend a percentage on each, you don’t have a business case yet.

Originally posted on LinkedIn