AI and ML
Where AI and ML Actually Pay Off in a Business, and Where They Are Expensive Hype
Machine learning pays off where there is a repeated decision, a lot of similar data and tolerance for error. Missing any one of the three means do not. Here are the use cases that work, their realistic accuracy, the running costs and how to run a four to six week pilot.
In short
Machine learning is justified when three conditions hold at once: the decision repeats hundreds of times a month, similar data has accumulated (from about a thousand examples per class), and a 5% to 15% error rate is either acceptable or caught by review. If any one is missing, ordinary automation is cheaper. A single-process pilot takes four to six weeks, and AI/ML development at Veltos.Tech starts at 180,000 RUB.
The three-condition test
Almost any conversation about adopting AI compresses into three questions. First: does your process contain a decision a human makes repeatedly and in roughly the same way? Not a hard decision, a repeated one: assigning a ticket to a category, working out which product a description refers to, finding the right clause in a policy. One-off strategic decisions do not yield to machine learning, and trying to automate them is the most common source of disappointment.
Second: has data accumulated that shows how the decision was made before? A model learns from examples and needs many of them: for classification, roughly a thousand labelled cases per class; for extracting fields from documents, a few hundred documents per type; for demand forecasting, at least two full seasonal cycles. The data must reflect reality rather than an idealised picture: an archive containing only successful cases will not teach a model to recognise unsuccessful ones.
The third question is the uncomfortable one: is error acceptable? Every model is wrong sometimes, and what matters is how often and what happens afterwards. A realistic benchmark for a well-defined task is 85% to 95% correct, which means one result in ten to twenty is wrong. If that result can be corrected at the next step, or is simply slightly worse than a guess, adoption makes sense. If every error triggers an investigation and costs more than the automation saves, the answer is no.
The three conditions only work together. A repeated decision and error tolerance but no data means data first, a year of collection, and the model conversation afterwards. Data and tolerance but a decision taken three times a month means no saving at any level of accuracy. Data and volume but errors that cost as much as an incident means a process with mandatory human review, and then the saving is measured against a faster human rather than an absent one.
- Repetition: the decision is taken hundreds of times a month on comparable grounds.
- Data: from a thousand labelled examples per class, reflecting real rather than idealised cases.
- Error tolerance: a 5% to 15% error rate creates no unacceptable consequences.
- A process owner: somebody accountable for the outcome and willing to change the process around it.
Use cases that genuinely pay off
The most reliable category is triaging an inbound stream. Support tickets, mail to a shared inbox, enquiries from a website: they need classifying, prioritising and routing to the right person. The task fits all three conditions cleanly: the volume is large, the decision history already lives in the ticketing system, and a routing error is fixed by one drag. The typical effect is not headcount reduction but faster first response and fewer tickets that sat in the wrong queue.
The second reliable category is extracting fields from documents. Invoices, delivery notes, contracts, application forms: a person reads a document and copies a dozen values into a system. Payback is easy to compute here because you know how many minutes one document takes and how many arrive per month. Accuracy on structured fields such as amounts and dates is high, on free text lower, so the normal deployment is model fills, human confirms, which multiplies throughput even with review retained.
The third is searching an internal knowledge base. A company accumulates policies, instructions, correspondence and decks, and keyword search cannot find anything in them because people ask in their own words. Semantic search closes the gap between how the question was phrased and how the document was written. It is one of the few tasks where the effect is felt immediately without changing any process: the same person does the same job but stops spending half an hour hunting for an answer that already exists.
Demand forecasting and recommendations work but demand data discipline. A forecast without two full seasonal cycles of history is guesswork in mathematical clothing, and recommendations without sufficient traffic perform worse than sorting by popularity. Visual quality control is the most technical item on the list: it produces excellent results under stable photographic conditions and falls apart when lighting, angle and background change from shot to shot.
| Use case | Data required | Realistic accuracy | What it replaces or speeds up |
|---|---|---|---|
| Ticket classification and routing | 6-12 months of ticket history with categories | 85-93% | Manual queue triage, first response time |
| Product and listing classification | From 1,000 examples per category with titles and descriptions | 88-95% on stable categories | Manual categorisation of new items |
| Field extraction from documents | 200-500 labelled documents of each type | 90-97% on structured fields, lower on free text | Manual data entry into the accounting system |
| Internal knowledge base search | Documents in parseable formats, current and deduplicated | Answer in the top 3 sources for 80-90% of queries | Asking colleagues and digging through folders |
| Product and content recommendations | View and purchase history, from several thousand sessions a month | Measured by A/B lift rather than by accuracy | Manual merchandising and popularity sorting |
| Demand forecasting | 2+ seasonal cycles of sales, promotions and stock levels | Forecast error typically 10-25% depending on the item | Purchasing planned on last year figures |
| Visual quality control | From 500 images per defect type under stable capture conditions | 90-98% when capture conditions stay constant | Full manual visual inspection |
Where AI is the wrong tool
The first case is a task that rules solve. If the logic fits into a dozen conditions ("if the amount exceeds one hundred thousand and the client is new, send to manual review"), rules beat a model on every dimension: they are transparent, debuggable in an hour, need no data, do not degrade over time and can be edited by a business user without a developer. A substantial share of requests to "add AI" turn out on inspection to be exactly this, and the honest recommendation is ordinary automation.
The second case is too little data, or data about the wrong thing. Two hundred examples collected over three years will not train anything reliable, and if the knowledge lives in sales correspondence and in people heads it first has to become a structured dataset, which is a separate project measured in months. Here the correct order is the reverse of the usual one: set up data collection first, look at what accumulated after a year, and only then discuss a model.
The third case is a high cost of error where a human reviews everything anyway. Medical, legal and financial decisions with legal consequences land here almost always. That does not make AI useless there: it can speed up preparation and flag risk. But the promise of automation is false in such a task. You get an assistant rather than a replacement, and the economics have to be computed as a faster specialist rather than an absent one.
The fourth case deserves naming directly because it is the most common: AI gets adopted not to solve a problem but so that the company has AI. The project is initiated from above, the problem statement is missing, there are no success criteria and no process owner. Such deployments end technically successfully and organisationally without a trace: the system works and nobody uses it. The tell is simple. If nobody can answer which number should change, the project is not ready.
The data reality check behind "we have data"
The phrase "we have accumulated a large amount of data" turns out in practice to mean one of several things. Most often, exports from an accounting system where the fields you need are filled on half the records and the other half contain values like "clarify" and "see comment". Sometimes a folder of scans of varying quality with no naming convention. Sometimes chat correspondence where the knowledge exists but not in machine-readable form. None of these is a training dataset, though each can become one.
Labelling is the most underestimated budget line. A model learns from examples where the right answer is known in advance, and somebody has to supply those answers. For ticket classification that means a domain expert labelling several thousand examples, which is tens of hours of work. The good news is that part of the labelling frequently already exists inside your systems: ticket categories, accounting codes, catalogue tags are all labels nobody happened to call by that name.
Data ownership and the right to use it need a separate check. If the data contains personal information it falls under data protection law, which determines where training may happen and whether fragments can be sent to an external API at all. If the data came from counterparties, your agreement with them may not grant this kind of use. These questions are cheaper to ask in week one than at the stage where a model has been trained on something it should not have been.
- Volume: how many records are actually usable, not how many rows the export has.
- Completeness: the share of records with the key fields filled.
- Labels: which categories already exist in your systems and how much needs adding.
- Currency: whether the data reflects today processes or those of two years ago.
- Rights: personal data, residency restrictions, terms of counterparty agreements.
Build, buy or call an API
A ready SaaS product wins when your task is standard and matches what the service was built for: recognising documents in common formats, transcribing calls, basic sentiment analysis. Rollout takes days, cost is predictable, and support is somebody else problem. The limits are equally clear: you cannot change the logic to fit your specifics, you depend on the service being available and on its pricing policy, and your data leaves your perimeter.
Calling a large language model API is the middle path and in 2026 the fastest way to test a hypothesis. Nothing needs training: the task goes into a prompt, and quality is assessed in a day rather than a month. The price is per-request cost and full dependency on a supplier. For Russian projects there is the added question of where the data is physically processed, which pushes sensitive tasks towards domestic models or towards running open models inside your own perimeter.
Building your own is justified in three cases: the task is specific to your business and no product exists; the data cannot leave your perimeter; or request volume is high enough that monthly API spend exceeds the cost of owning a model. The third case is worth computing in advance because it arrives sooner than expected, which the next section covers. AI/ML development at Veltos.Tech starts at 180,000 RUB, and at that level it is a pilot on one process rather than a full platform.
The cost model: building versus running
The main budgeting error in AI projects is costing only the build. In ordinary software, running costs are trivial next to creation; with solutions built on external models it is different, because every request costs money and at meaningful volume the monthly bill over a couple of years easily exceeds the build. This is not an argument against external APIs, it is an argument for doing the arithmetic before you start rather than after the first invoice.
The calculation is simple. Take expected monthly requests, multiply by the average size of one request plus its response, convert to tokens and multiply by your model rate. Then add what people forget: retries after errors, calls made during debugging, and growth in volume if adoption succeeds. A practical rule is to double the result, because actual spend always exceeds the estimate and a successful rollout increases load.
The second forgotten line is quality maintenance. A model left unattended degrades: customer phrasing shifts, new product categories appear, document templates get updated. Normal operation includes regular human review of a sample of results, collection of failure cases and periodic retraining. That is continuous rather than one-off work, and it belongs as its own budget line, otherwise a year later the system performs noticeably worse than it did at acceptance and nobody understands why.
| Cost line | One-off | Recurring | What to watch |
|---|---|---|---|
| Data preparation and labelling | Typically 20-40% of the pilot budget | Labelling of new cases | Who labels and how many hours it takes |
| Development and integration | The bulk of the estimate | Changes driven by live operation | Integration into the working system, not a separate interface |
| External model requests | None | Requests times size times rate, doubled for safety | Spend growth if adoption succeeds |
| Infrastructure and storage | Environment and vector store setup | Servers, storage, backups | Domestic data residency requirements |
| Quality monitoring | Setting up metrics and logging | Regular human review of a sample | Accuracy drift over time |
| Support and retraining | None | A dedicated budget line rather than leftovers | Who owns quality after the project is delivered |
Running a pilot that gives you a real answer
A correct pilot has three properties: one process, four to six weeks, success criteria agreed before it starts. All three are mandatory. One process, because a pilot spanning three tasks never shows which one worked. Four to six weeks, because less does not produce enough operating data and more loses momentum and control. Criteria set in advance, because criteria set afterwards always adjust themselves to the result obtained, and that happens with no bad intent whatsoever.
Criteria come in two kinds. Technical, for example correct category share of at least 88% on a held-out sample the model never saw during training. And business, for example average handling time per ticket dropping from eight minutes to three, or the share of misrouted tickets halving. A technical criterion without a business one produces an excellent model nobody uses, which is the single most common outcome of corporate pilots.
The condition most often ignored: the pilot must be embedded in the real workflow rather than shown as a demonstration. A separate interface an employee has to open on purpose will not be used, however good it is. The opposite works: the suggestion appears where the person already works, inside their ticketing system or their form, requiring no extra action. That is the difference between adoption and a presentation, and it decides the fate of the project more than model accuracy does.
And last: a pilot needs a negative outcome defined in advance. What do we do if accuracy comes back at 70% instead of 88%? The answer "train for another month" is acceptable once, not indefinitely. Willingness to close a pilot with a negative result is a sign of a mature approach rather than a defeat: you spent several weeks and got an answer instead of spending a year and getting a working system that does not solve your problem.
Frequently asked questions
How much data is needed to start?
It depends on the task. For classification, plan on a thousand labelled examples per class, and the classes need comparable representation: a thousand examples of one category and forty of another produces a model that never sees the second. For document field extraction, 200 to 500 documents per type suffices. Forecasting needs at least two full seasonal cycles. With less than that, the sensible first step is not a model but setting up collection, and revisiting the question in six to twelve months.
Will AI replace employees?
In the overwhelming majority of business tasks, no, and promises to the contrary are worth treating as a warning sign. The realistic effect is different: the same team handles more volume, response times shorten, and the routine part of the job leaves the daily workload. At 85% to 95% accuracy you can remove the human entirely only where an error costs nothing. So the economics are correctly computed as throughput gain and reduced handling time rather than as payroll reduction.
How does machine learning differ from ordinary automation?
Automation executes rules you wrote; machine learning infers patterns from examples. If the logic fits into a dozen conditions, automation is the right answer: transparent, cheaper, debuggable in hours and needing no data. Machine learning is for cases where the rules are too numerous or cannot be put into words at all: understanding text, identifying an object in a photograph, weighing a hundred factors in a forecast. In practice the best result usually comes from combining them, with rules for the unambiguous cases and a model for the rest.
What does AI adoption cost in a small company?
A pilot on one process usually starts around 180,000 RUB and four to six weeks, assuming the data already exists in usable form. If it has to be prepared and labelled, add 20% to 40%. Running costs are separate: external model requests, infrastructure and quality monitoring. For a typical scenario of a few thousand requests a month those recurring costs usually sit in the tens of thousands of roubles, but they must be calculated before the start rather than discovered on the first invoice.
Where do I start if the problem is not defined yet?
With an inventory of repeated decisions. Walk your processes and list operations employees perform many times a month in roughly the same way, with an estimate of the time each takes. Multiply time by frequency and you have a candidate list sorted by potential saving. Then check each candidate for available data and error tolerance. After that inventory the top two or three places are usually occupied by tasks nobody had in mind at the outset.
Need a hand with this?
We do this work, not just write about it. Describe the task and we will scope it and send a staged estimate.
Related services
- AI and ML developmentWe build AI that solves a defined task and pays for itself, not demos for the sake of demos. Classifiers, recommendations, text and document processing, LLM assistants, and model integration into an existing product.
- AI strategy consultingMost companies have already run at least one AI pilot. A minority have taken even one pilot to stable, ongoing use. The gap usually is not the model, it is whether the process had a measurable payoff and whether the real running cost was worked out before starting. We help pick the right entry point so budget does not disappear into a demo that stays a demo.
- Web app and Telegram Mini App developmentFor when a site is no longer enough and you need a product: an account area, a dashboard, an internal tool or a Mini App inside Telegram. We design the architecture, write the backend and frontend, and take it to release.
Read next
- An AI Assistant on Your Own Knowledge Base: How RAG Works and What It CostsHow a RAG assistant differs from a button-tree bot and from an LLM with no data, where hallucinations come from and what actually reduces them, what SaaS costs against a custom build, and which month the project breaks even.
- How to Choose a Tech Stack: Criteria That Outlive the HypeA stack is a five-year commitment usually made in a single call. Here is the order the decisions should be taken in, the criteria that carry real weight, working stacks for six project archetypes and what a wrong choice costs.
- MVP in 2026: Real Timelines, Real Budgets and What to CutMVP no longer means cheap and rough. A weak prototype today produces a false negative and buries a workable idea. Here are four MVP tiers with prices and timelines, a framework for cutting scope, and the parts no budget justifies removing.