8 Min. Reading time<\/p>\n
One third of DACH companies say, according to the Bitkom study of April 2026, that AI has become more expensive than planned. This is not a question of mis\u2011estimated volumes, but an architecture and procurement issue. CFOs in the mid\u2011market who don\u2019t look at cost models now will cut staff in twelve months instead of cutting the vendor.<\/strong><\/p>\n The Bitkom study from April 2026 measures two realities at once. 41\u202f% of companies in the DACH region actively use AI \u2013 in 2024 it was 17\u202f%. Adoption is therefore not the problem. The second figure shows the problem: 33\u202f% report cost overruns. 19\u202f% have cut jobs as a result. That is a stark number in a study that otherwise mainly gathers sentiment.<\/p>\n CFOs who only read the adoption rate miss the expensive side. Cost overruns are not evenly distributed. Industry observations show they cluster in two groups. First, mid\u2011size firms that entered a hyperscaler contract without an architecture review. Second, companies that have scaled a generative\u2011AI use case into core business without calculating inference cost per transaction.<\/p>\n For finance, this means: the AI line item is no longer a software line item. It behaves like a variable energy cost \u2013 with the difference that most ERP systems don\u2019t model it that way. Writing it into the forecast as a fixed license cost means you\u2019ve already lost.<\/p>\n The 19\u202f% figure is the real alarm signal. It says: the mid\u2011market started adopting AI without defining a financial safety margin. As soon as cash flow tightens, the cuts hit the personnel side, not the vendor. That is the opposite of what the AI investment thesis promises \u2013 and it almost always stems from nobody having done an honest total\u2011cost\u2011of\u2011inference calculation before launch.<\/p>\n Cost overruns rarely stem from the license fee. They arise from the architecture that sits beneath that fee. Four patterns show up especially often in DACH pilot projects \u2013 and all of them are avoidable if the CFO asks the right questions before the architecture sign\u2011off.<\/p>\n What drives costs<\/p>\n What bears the cost<\/p>\n The most expensive of the four points is usually the RAG pipeline. A poorly built retrieval architecture loads 8,000 to 16,000 tokens of context for each request, even though 1,500 would suffice. When tokens are billed per million, that factor translates directly into the monthly bill. CFOs should therefore, at the first sign\u2011off, ask not for the model price but for the average token consumption per transaction \u2013 and for the worst\u2011case scenario during load spikes.<\/p>\n Hyperscaler lock\u2011in is the second major lever. Whoever builds a use case entirely on a single cloud without integrating a second inference provider has no negotiation anchor. In the DACH mid\u2011market this often results from a historically grown cloud dependency combined with sales pressure from the hyperscaler, which pitches the AI stack as a bundled offering. The consequence: price hikes cannot be absorbed because a replacement project costs six to nine months.<\/p>\n Traditional software business cases check license price, implementation effort, and maintenance. With AI, the two most important items are missing: inference costs and scaling path. These five steps augment the business case so the real drivers become visible before the contract is signed.<\/p>\n The five steps are not a framework. They are the minimum discipline needed to prevent a \u20ac50,000 pilot from turning into a \u20ac380,000 cost block without anyone being able to say stop. In industry observations this is exactly what happens in most cost\u2011overrun cases: no one was tasked with spotting the drift.<\/p>\n Traditional software procurement in the mid\u2011market buys a license per user, perhaps plus maintenance. With AI this only works in pilot phases. As soon as a use case goes into production, the token model blows past the license model. If procurement isn\u2019t reshaped, the same cost overrun will reappear each quarter \u2013 just on a larger scale.<\/p>\n The first step in the overhaul is moving from per\u2011seat to per\u2011outcome contracts, which the vendor must be willing to accept. In the DACH mid\u2011market this is rarely negotiable outright, but a hybrid model works: a base fee covers a defined token amount; any usage beyond that is listed transparently. What must never happen is token consumption without a contractual cap. That is the default path in the 33\u2011percent cluster.<\/p>\n The second lever is vendor consolidation, which runs counter to the usual pattern. Where the rule of thumb has been \u201cprefer three specialised suppliers to one\u2011stop\u2011shop,\u201d AI inference flips that. Running three inference providers in parallel is expensive in setup and monitoring. Most often the sensible approach is: one primary provider for about 70\u202f% of the volume plus a second for routing and negotiating leverage. Running three models simultaneously only pays off at scale levels that the typical mid\u2011market company won\u2019t reach by 2026.<\/p>\n The third point concerns data clauses. The more use cases tap internal data, the more important restrictions on training use, data residency and audit rights become. These clauses are no longer just a GDPR issue; they are a cost driver: a vendor that excludes training use can offer better terms because its business model is calculated differently. CFOs should ask procurement to negotiate these actively rather than swallowing them as a standard clause.<\/p>\n The 33\u2011percent figure won\u2019t correct itself. Any mid\u2011market firm that has AI in production by 2026 but lacks a clear cost\u2011tracking mechanism is a candidate for the next round. Three concrete actions can be realistically implemented over the next twelve months without killing adoption.<\/p>\n The roadmap may look unglamorous \u2013 that\u2019s intentional. AI cost control in the mid\u2011market doesn\u2019t need new frameworks. It needs the willingness to treat the line item seriously before it eats into the personnel budget. The 19\u2011percent figure from the Bitkom study shows what happens when that willingness is missing.<\/p>\n The Bitkom figures for 2026 are not an adoption problem but an architecture and procurement problem. CFOs in the mid\u2011market can cushion the cost\u2011overrun wave if they treat AI costs as a variable line item, demand token profiles before signing contracts, and keep at least a second inference provider on standby. Those who don\u2019t will face the same choice as the 19\u202fpercent after twelve months: cut staff or scale back the use case. Both paths cost more than building a clean procurement framework now.<\/p>\n Because AI inference is billed variably, whereas traditional software is fixed\u2011price. CFOs often calculate with a license model (fixed price per user) and overlook that token pricing scales per transaction. A use case that gains traction drives costs disproportionately \u2013 the exact opposite of classic software scaling.<\/p>\n<\/details>\n Total Cost of Inference adds up all expenses incurred per AI request: input tokens, output tokens, routing overhead, caching share, monitoring. Calculation for the mid\u2011market: average tokens per transaction\u202f\u00d7\u202fnumber of transactions per month\u202f\u00d7\u202ftoken price, plus a 10\u201115\u202fpercent surcharge for peak loads. That yields an honest monthly estimate for your forecast.<\/p>\n<\/details>\n For pilot projects the IT lead is sufficient. Once a use case moves into production and inference costs exceed roughly\u202f5\u202f000\u202fEuro per month, the finance function must be part of the architecture sign\u2011off. Hyperscaler lock\u2011in and missing model routing are no longer mere technical details but contract commitments with multi\u2011year cost impact.<\/p>\n<\/details>\n Without an alternative, negotiating power is limited. Realistically you have three levers: first, volume commitments in exchange for price reductions (typically 5\u201110\u202fpercent); second, multi\u2011year contracts for cost caps; third, inclusion of a routing right in the agreement. More important is building a parallel second provider \u2013 without it future negotiations remain one\u2011sided.<\/p>\n<\/details>\n Industry observations show a factor of three to five at medium volume. A bad pipeline loads 8\u202f000\u201116\u202f000 tokens of context per request, an optimized one 1\u202f500\u20113\u202f000. At 50\u202f000 requests per month that adds up to four\u2011 to five\u2011digit amounts \u2013 in the differential, not the total price. Caching layers and better chunking are often small technical tweaks with a large lever effect.<\/p>\n<\/details>\n Source cover image: Pexels \/ Kampus Production (px:8353840)<\/em><\/p>\n 80 Percent AI Failure Rate 2026: How RAND and Gartner Assess the AI Productivity Gap<\/a><\/p>\n AI Data Maturity in SMEs 2026: Five Homework Tasks Before the First Productive Agent<\/a><\/p>\nKey Takeaways<\/h2>\n
\n
What the Bitkom figures mean for CFOs<\/h2>\n
Four architectural anti\u2011patterns that generate cost overruns<\/h2>\n
\n
\n
How a CFO Validates an AI Business Case (5 Steps)<\/h2>\n
Rethinking procurement: from license purchase to inference contracts<\/h2>\n
The next twelve months: what CFOs should put in place<\/h2>\n
Conclusion<\/h2>\n
Frequently Asked Questions<\/h2>\n
Why are 33\u202fpercent cost overruns in AI projects so high compared with classic IT projects?<\/strong><\/summary>\n
What is Total Cost of Inference and how do I calculate it?<\/strong><\/summary>\n
Is it enough for our IT manager to make the architecture decision, or must the CFO sit at the table?<\/strong><\/summary>\n
How do I negotiate AI costs with a hyperscaler if I don\u2019t have a second provider?<\/strong><\/summary>\n
How much more does a poorly built RAG pipeline typically cost in the mid\u2011market compared with an optimized one?<\/strong><\/summary>\n
Reading Tips from the Editorial Team<\/h2>\n