AI implementation that ends the day it goes live is really just getting started. We see this in practice with our own products — Qkwit, Brokik, and Cheaperfordrug — from the first day a model starts reading real documents or answering real users. Our rule of thumb from that practice is simple: building the system is about 40% of the total work. The remaining 60% is keeping it in shape, month after month.
Where the 40/60 split comes from — our thesis, not a study
Before going further: 40/60 isn’t the result of any market research or a quote from an industry report. It’s an observation from our own product practice — from how much time and attention it actually takes to maintain AI systems we’ve launched ourselves and look after every day. We treat it as a starting point for a budget conversation, not a hard rule to plug into a spreadsheet.
Quality monitoring isn’t a “ship it and forget it” job
A model that handles documents or queries well on launch day doesn’t guarantee it will handle them just as well three months later. You need ongoing quality observation: is data extraction from documents still accurate, do generated answers still stick to the facts, is the number of cases needing manual correction going up or down. Without that observation layer, a company finds out about a quality drop only when a customer or the accounting team reports it — which is the latest possible moment to find out.
In practice that means a few concrete habits: regularly sampling outputs and comparing them against what a person would have done, tracking the rate of cases needing manual correction over time, and a simple alert when that rate starts climbing. None of this requires an elaborate dashboard — it just takes someone looking at those numbers regularly and treating a rising correction rate as a signal to check what changed, before the errors reach a customer.
Three signals are worth watching from day one: output quality against a human baseline, the escalation rate over time, and whether incoming documents and queries still look like they did on test day.
Data and format drift
The documents a system learns from and works on don’t stand still. Invoice issuers change their templates, government forms get updated, receipts from new point-of-sale systems look different from the ones a year ago. A system that read one format perfectly can start making mistakes the moment a variant it hasn’t seen before shows up. In Qkwit, where AI reads accounting documents and a deterministic engine calculates taxes and social security contributions from that reading, this kind of drift needs to be caught before it affects the numbers, not after.
In practice, drift rarely announces itself. An accounting software vendor changes an invoice layout, a public office updates a form, a retail chain rolls out a new receipt format — and a system that handled everything correctly before suddenly starts getting one specific document type wrong. Whoever maintains that system needs a way to catch it quickly, before the bad data makes it into someone’s books.
Model and prompt updates
The language models production AI relies on change on their own — new versions ship, older ones get deprecated, and a model’s behavior on the same prompts can shift subtly. That means regularly re-testing prompts, updating them for new model versions, and making sure a change under the hood doesn’t quietly break something that used to work well. That’s separate, ongoing work — not a one-time “we wrote the prompt, it’s done” task. We wrote more about splitting responsibilities between AI and code in AI proposes, code decides: why we separate the two — that separation is also what makes it safer to update the AI layer without putting the calculation layer at risk.
In practice, that means a repeatable release cycle for the AI layer: a new model version runs against a fixed set of test cases first, and only after reviewing the differences do we switch it into production.
Exception handling: where automation stops
Every production AI system sooner or later runs into a case nobody planned for: a document in an unusual format, a query outside its scope, a situation that calls for judgment rather than classification. Maintenance means building and maintaining an escalation path to a human for those cases — not just once, at launch, but as a permanent part of how the system runs. We covered this model in Decision automation with human escalation: the safer default: the more mature a process gets, the better it knows when it can’t handle something on its own.
Who you need on your side to keep it running
Maintenance can’t be solely the vendor’s job. The company needs a process owner who regularly reviews cases escalated to a human and treats them as feedback. It doesn’t need to be a dedicated role — often it’s whoever already knows the process, with a standing line to the team maintaining the AI layer.
What this means for budgeting and planning
The practical consequence of this split is straightforward: an AI implementation budget that ends on launch day is a budget for 40% of the project. The other 60% — monitoring, handling drift, updating models and prompts, escalation paths — needs to be planned and priced from the start, not discovered as a surprise a month into production. We wrote about the upfront cost itself in What AI implementation really costs in 2026 — worth reading alongside this one, since only the two together give you the full budget picture.
In practice, this also changes the rhythm of a team’s work: building a system has a clear start and end, but maintaining one is continuous and doesn’t stop when the project closes. Companies that plan for this in advance set aside a smaller, ongoing monthly budget for looking after the system, rather than reopening the budget conversation only once something stops working.
How this looks across our own products
In Qkwit, AI reads accounting documents and a deterministic engine calculates taxes and social security contributions from that reading — the AI layer needs constant quality monitoring and adjustment to new document formats. In Cheaperfordrug, Apteczkomat (basket recognition, chat, restock planning) needs similar care as packaging changes or as users phrase questions differently over time. In Brokik, AI supports document adaptation and pricing across 25 markets at once — and each market is its own surface where quality needs to be watched separately. You can read more about our approach to this kind of work on our AI implementation page and on the Qkwit page itself.
FAQ
Is the 40/60 split the result of market research? No. It’s our own observation from running AI products in production, not a quote from a study or industry report. We treat it as a starting point for a budget conversation, not a fixed rule.
What exactly counts as AI maintenance cost? Mainly ongoing quality monitoring, responding to drift in data and document formats, model and prompt updates, and maintaining escalation paths to a human for cases that fall outside automation.
Can you estimate maintenance cost before a project starts? Partly. A good process audit at the start helps estimate how variable the input data will be and how often you’ll need to revisit prompts and templates — but the full maintenance cost picture only shows up after a few months in production.
Does every process need the same amount of maintenance? No. A process built on data that rarely changes needs less attention than one where document formats or user queries change often. How variable your input data is is one of the better early indicators of future maintenance cost.
Does maintenance cost go down over time? Usually, yes, if the process is stable — the team learns the common exceptions and tunes prompts so fewer cases need manual correction. But it never drops to zero, because the input data and the models a system runs on keep changing too.
How does a collaboration on AI implementation that accounts for upkeep from day one usually start? We start by talking about the process itself and how variable its inputs are — not just the technology. Get in touch and we’ll work through it together.