# What generative AI actually costs a company > The five real budget lines, why model usage is the smallest of them, and a method for working out the return in hours freed rather than percentages. Author: Anthony Crowther-Alwyn · Published 2026-09-06 · https://www.praedic.com/en/guides/what-generative-ai-actually-costs-a-company The price question always comes up, and it rarely gets a useful answer. Either you are quoted a monthly subscription, which accounts for almost none of the real budget, or you are promised a productivity percentage nobody can verify. Here is the honest breakdown, line by line. ## Five lines, not one A generative artificial intelligence project in production costs money on five distinct lines: model usage, hosting, building, maintenance, and indecision. The last one is the most expensive, and the only one nobody mentions. Before the detail, a warning about the numbers that follow. Every amount quoted is an order of magnitude observed in the market, meant to give you a sense of scale. They are not our rates, they are not quotes, and they are not measurements taken at our clients. Prices in this industry move too fast for a figure written today to hold its value in a year. ## Line 1, model usage This is the line everyone looks at first, and it is almost always the smallest. A model is billed by usage, according to how much text goes in and comes out. For typical business use in a company of this size, processing a document, a meeting note or a customer request costs between a fraction of a cent and a few cents. A system handling a few hundred operations a day stays, in the overwhelming majority of cases, under a hundred euros a month. Per-user licences commonly sit between twenty and fifty euros per person per month. More importantly, this line is falling. At constant quality, the cost of a given piece of processing has come down by substantial factors in two years, under the double effect of competition between suppliers and the improvement of small, economical models. A task that yesterday demanded the most powerful model is handled today by a mid-range one, for a fraction of the price. Two practical consequences. Do not size a project around the cost of the calls: you would be optimising the smallest line. And do not abandon a use because it looks expensive at scale, because it will cost less next year than it does now. ## Line 2, hosting A system that runs has to run somewhere. That means a server or an execution service, a database, something to trigger the processing, and storage. For the kind of projects discussed here, the order of magnitude runs from a few tens to a few hundred euros a month. Modern execution platforms bill by consumption, which means a job triggered ten times a day costs a trivial amount. This line changes character in one case only: when the sensitivity of your data requires running an open model on a machine you control. You then swap a variable cost per use for a fixed infrastructure cost that is markedly higher. It is a legitimate trade-off for certain data, and we have set it out in our guide on [confidential data](/en/guides/using-generative-ai-without-exposing-company-data). ## Line 3, building This is where most of the budget sits, and where the gap between suppliers is widest. Building is not making a demonstration. It means understanding the existing process, defining precisely what the system has to produce, connecting it to your real tools, handling the edge cases that often account for half the work, testing on genuine data, and putting it into service with people who have other things to do. In the market, a first useful system in production on a well-defined scope commonly lands somewhere between a few thousand and a few tens of thousands of euros, depending on how many systems have to be connected and how complicated the business rules are. A project touching several areas at once leaves that range, which is precisely why we recommend starting with one area. One point is worth stressing, because it has changed recently. The cost of manufacturing the software itself has fallen sharply, because writing code is now assisted. What has not fallen is the cost of understanding the business and the cost of putting the thing into service. Be wary of a proposal whose price is explained entirely by development time: that is the least decisive part. ## Line 4, maintenance A system in production is not a deliverable, it is a living organism. The interfaces of your software change. Models evolve and get withdrawn from their supplier's catalogue. Your processes move. An unforeseen case shows up after three months. A source file changes format without warning. As a market order of magnitude, allow between fifteen and twenty-five per cent of the build cost per year to keep a system in good working order. This is not a supplier's annuity, it is the condition for the gain still being there in two years. This line includes something many people leave out: monitoring. An automated process that fails silently is worse than no process at all, because the company carries on relying on it. At one of our clients, the pipelines that import large public reference datasets are checked every month, with an alert raised on any anomaly. There is nothing spectacular about that monitoring and it costs little, but it is what separates a system that lasts three years from one that dies without anybody noticing. ## Line 5, indecision This line appears on no invoice, and it often exceeds the other four put together. Do the arithmetic. A repetitive task occupies one person for four hours a week. That is roughly a hundred and eighty hours a year. At the fully loaded cost of an employee, you are somewhere around seven to nine thousand euros a year for that task alone. Six further months of deliberation before deciding therefore cost about four thousand euros, before any indirect effects. Those indirect effects are real. Enquiries answered too slowly, proposals sent a week after the meeting, decisions taken without data because extracting it takes too long. They cannot be costed to the cent, but they exist, and they run for as long as nothing is decided. ## Work out the return in hours, not percentages Forget productivity percentages. They cannot be verified, they compare to nothing, and nobody can tell you what a thirty per cent gain means in a given trade. Reason in hours freed. The method has five steps. - Choose a precise task, not a whole department. - Count the hours it consumes each week, by asking the people who do it. - Estimate the share genuinely automatable, staying conservative, often between half and three quarters. - Multiply the hours freed by the fully loaded hourly cost, contributions included. - Compare that annual gain against the sum of the first four lines over the same year. Here is the reasoning with deliberately generic numbers. A task consumes six hours a week, so roughly two hundred and seventy hours a year. You reckon you can automate two thirds of it, or a hundred and eighty hours. At forty euros of fully loaded hourly cost, that is about seven thousand two hundred euros a year. Against that, a build at the low end of the market range, plus its hosting and maintenance, pays for itself in one to two years. Adapt every number to your own reality: the method matters more than the example. One last point, which saves a good deal of disappointment. Hours freed do not turn mechanically into payroll savings. In a company of this size they turn, more often than not, into capacity: more meetings, more studies produced, shorter response times. That is a better result, but it has to be presented as such to a board, rather than promising a headcount reduction that will not happen. The surest way out of orders of magnitude and into a figure that concerns you is to measure, on one area, where the time actually goes. That is the first thing we do in a [diagnostic](/en/diagnostic), and its output is exactly that: a list of projects costed in hours and in euros. Our [full method](/en/method) sets out how it runs.