In Polish logistics, 0.8 percent of companies use artificial intelligence. That is the lowest result among all business areas surveyed by the national statistics office in 2025, against 5.0 percent in marketing and sales. If you run a transport or forwarding company, you operate in the least saturated industry in the country.
Before we go further, one distinction, without which half of this text will be about something other than what you came for. The phrase „AI software development” means two different things. The first is building software with the help of artificial intelligence, where a model writes code and an engineer answers for it. We covered that separately in our piece on AI-assisted engineering. The second is building a system that has a model inside and uses it in the daily work of a company. This text is about the second one.
Below is how such a project runs, in five stages, seen from the buyer’s side. Each stage comes with numbers from two systems we built for ourselves, because with our own projects we can also publish what went wrong.
Five stages, and where projects stall
A project that puts a model inside a working system goes through defining the problem, working with data, building and integrating, acceptance, and maintenance. The difficulty is distributed differently than intuition suggests: the longest stage tends to be the second, and the most expensive one over a span of years is the fifth.
We also know where projects stall. RAND Corporation, in a report from August 2024, lists five causes of failure, in order from the most common: a misunderstood or poorly communicated problem, a lack of adequate data, reaching for technology instead of solving a problem, missing infrastructure for deployment, and a problem too hard for current methods. The study is qualitative, based on 65 interviews across industry and academia, so it reads as a description of a mechanism rather than a measurement. The authors’ conclusion is unambiguous, though: the causes are organisational, not technical.
Stage 1: the problem, not the technology. And whether a model is needed at all
The first question of a project is not „which model do we use” but „is a model needed here at all”. Rules are cheaper, faster, predictable, and they can be explained to an auditor. A model earns its place when the patterns are complex or shifting and there is enough data.
Our two systems answered that question in opposite ways.
In our own finance system, transaction categorisation runs in three steps. Rules first, then the history of the user’s earlier decisions, and only at the end a language model. The model is asked only about the transactions the first two steps did not recognise, which is why it accounts for a fraction of the bill and a fraction of the risk.
In the invoice system it went the other way. Rules are enough when documents arrive in a predictable form, and there some invoices never arrive at all, while others hide inside messages that look like purchase confirmations. The core had to become a model that reads message content and infers what is missing.
The same company, two projects, two different answers. Nobody has calculated a numeric threshold at which a model starts to pay off, at least not in a form worth quoting. The pattern that keeps recurring in practice is hybrid: a model for recognition and prediction, rules as the safety layer and as the part of the logic you have to be able to explain.
What this means for you: ask the supplier for a process map that marks which decisions the rules make and which the model makes. If the model answers for everything, that question was never asked.
Stage 2: data. The longest stretch, and the one missing from proposals
Anaconda, in a 2021 survey of 2,030 respondents, found that preparing and cleaning data takes 39 percent of specialists’ time, more than model training, model selection and deployment combined. In the 2020 edition it came to roughly 45 percent. RAND lists inadequate data as the second cause of failure.
This stage rarely appears in proposals, because it is hard to price before the work starts and nobody enjoys opening a conversation with „first we need to sort out your data”.
In the invoice system, a separate project step was calibration against real data from recent months: recognising which supplier lands in which mailbox, filtering out terms of service and confirmations that are not invoices, pairing rail tickets with their invoices, and counting revenue by sale date. This is not technical work in the everyday sense; it is precisely the work that decides the quality of the result.
For a transport company with spreadsheets and a system inherited from the previous decade, this stretch will be the longest. Data protection enters here as well. In our finance system, before anything reaches the language model, personal identification numbers and phone numbers are stripped from the transfer title and counterparty data, and sensitive values are replaced with hashes. The model receives as much as it needs to recognise a category, and nothing beyond that.
Stage 3: the build. The model is the smallest part of the system
A Google research team described a phenomenon at NeurIPS in 2015 that has not aged: the code responsible for machine learning is a small fragment of the whole, and the rest is configuration, data collection and verification, serving infrastructure and monitoring. The authors write about widespread, substantial maintenance costs for learning systems in production. Moving from a demonstration to production is harder than building the demonstration.
Our two examples show the range that fits inside this stage.
The invoice system was built in two to three hours of actual work. It was, however, the second attempt. The first, made two to three months earlier, produced nothing that could be run. The difference was not a better model or newer tooling, but narrowing the problem and moving the variable part into a configuration file, a checklist that can be corrected without touching code.
The finance system took 20 to 30 hours of one person’s work, with a working system in production on day one, and the remaining time spent on further features and 34 corrections in two batches.
Stage 4: acceptance. How to check that it works before you sign
This is where a system with a model inside differs most from ordinary software. An accounting program either works correctly or has a bug. A system built on a model has accuracy, which means acceptance is a measurement rather than a viewing of a demonstration.
Automatic categorisation accuracy in our finance system is 94.7 percent, measured across 720 transactions from twelve months. Stating the number of cases matters as much as the result itself, because the same 94.7 percent measured on thirty transactions would mean nothing.
In the invoice system, acceptance looked different because the material was different. We ran a backward test on a month already closed, comparing the system’s output against the folder kept by the accounting office. The system collected 23 of 27 costs and 2 of 2 revenues automatically. The remaining four items were deliberately left to a human. A decision gate works separately: documents outside the list go to review, and in the month tested there were five of them, all rejected as offers, a duplicate, a private expense and a pro forma invoice.
What this means for you: a metric without a stated sample means little, ours included. Ask for the number of cases, the period they come from, and what the system does with what it failed to recognise. „Passes it to a human for a decision” means that path was designed; „guesses” means it was not.
Stage 5: maintenance, the bill that keeps running
Two things happen after deployment and both rarely make it into the conversation before a contract is signed.
A model loses quality over time. A team of researchers from Harvard Medical School, MIT and the Whitehead Institute described this in Scientific Reports in 2022, across 32 datasets from four industries, transport among them. The degradation is sometimes gradual, sometimes abrupt, and more importantly it cannot be explained by shifts in the input data alone. Monitoring accuracy and planned retraining are therefore part of the system, not an extra service.
The bill follows the number of queries, not the price of the model. Unit cost has fallen at a pace hard to compare with anything in computing: according to the AI Index report prepared by Stanford HAI in 2025, the price per million tokens at a quality level matching GPT-3.5 fell from 20 dollars in November 2022 to 7 cents in October 2024. „I will wait until it gets cheaper” is therefore an argument two years late. What does grow is how many times a day the system asks the model.
Our bills look like this. Maintaining the finance system costs 0.65 dollars a month, of which the infrastructure compliance audit takes 0.61, file storage 2 cents, and the model categorising every transaction another 2 cents. The invoice system costs about 0.42 dollars a month, of which 0.40 is storing secrets, meaning passwords and mailbox keys.
In both cases the model is the cheapest item on the bill, and what you pay for is infrastructure and compliance. The scale of these systems is small, since they serve one company, and at thousands of queries a day the proportions will shift. The direction stays the same: the question „what does the model cost” matters less than „how many times a day will we ask it, and what else has to run around it”.
How many such projects fail. Four numbers that are not comparable
Four statistics circulate and get used interchangeably, even though they measure different things on different samples.
95 percent of generative AI pilots deliver no measurable return in the profit and loss account. The number comes from the MIT Project NANDA report of 2025, based on 52 interviews with executives, 153 survey responses and a review of more than 300 public deployments. The report is preliminary and not peer reviewed, and its definition of success is narrow, since it concerns impact on the profit and loss account rather than whether the project succeeded.
More than 80 percent of AI projects fail, roughly twice as often as IT projects without AI. That comes from the RAND report of 2024, based on 65 interviews, a qualitative study.
42 percent of companies abandon most of their AI initiatives, against 17 percent a year earlier. The data comes from S&P Global Market Intelligence in 2025, covering more than a thousand companies in North America and Europe. On average 46 percent of pilots never reach production.
85 percent is the most frequently distorted of these. In January 2019 Gartner published a forecast that through 2022, 85 percent of AI projects would deliver erroneous outcomes because of bias in data, algorithms or the teams managing them. The forecast concerned the quality of outcomes rather than the collapse of projects, and it was a forecast rather than a measurement.
Averaging these numbers produces a value that describes nothing. The shared conclusion is consistent with the RAND report: projects fall over on the definition of the problem, on data and on organisational readiness, not on the quality of the model.
The contract and compliance: what to negotiate when there is no standard
An IT implementation contract is a mixed one, combining elements of a contract for a specific result with a contract of due care. With a system built on a model, the supplier will push for the due care model, which is more favourable to them, because a result in the form of a given accuracy is hard to guarantee. That leaves the buyer three things to negotiate: the definition of acceptance, measurable quality thresholds, and a commitment to retrain when accuracy falls below an agreed level.
Ready templates for such clauses do not exist in Polish commercial practice, and neither does case law on model accuracy. This is a gap in the market rather than negligence on the supplier’s side; still, a first project is better structured as stages with acceptance after each one than as a single final acceptance.
On the compliance side, three things from the European AI regulation concern the buyer. The obligation to ensure AI literacy among people operating such systems has applied since 2 February 2025 and covers every risk level, including the simplest uses. Article 25 describes the situation in which a company using someone else’s system becomes its provider, along with the full list of obligations, for instance when it substantially modifies the system or puts its own brand on it. Obligations for high-risk systems start on 2 December 2027, after the deadline was moved by the Digital Omnibus package. A typical operational system, meaning transport order handling, invoice circulation or a production panel, is not a high-risk system. Classification depends on the use rather than the technology, so a tool supporting driver recruitment would be treated differently.
Where the Polish market actually is
Artificial intelligence is used by 8.7 percent of Polish companies, against 5.9 percent a year earlier. The most common way of acquiring it is buying a ready commercial solution, declared by 6.4 percent of companies. Commissioning a build externally remains the rarest route and covers 2.1 percent. The Polish Economic Institute adds that 77 percent of companies not using AI have no plans to adopt it until it becomes necessary.
In most cases buying a ready tool is a good decision. A subscription costs less than a project, deploys faster, and responsibility for maintenance stays with the producer.
Building your own system makes sense in two situations. The first is a process that is your advantage and that you do not want to make identical to a competitor’s running on the same subscription. The second is when a ready tool does not know your data, because you work with your own arrangement of orders, routes or documents, and forcing it into a standard costs more than building something to fit. We set out the four kinds of AI software in a separate piece on AI software categories, and the choice of supplier on the page about an AI software house.
Frequently asked questions
What is AI software development? Building software that uses a learning model in its daily work: to recognise documents, classify, predict or generate content. The phrase is also used in a second sense, the making of software with the help of AI, and then it describes a team’s working method rather than a product.
What does such a project include? Defining the problem along with the decision on whether a model is needed, working with data, building and integrating with systems you already run, acceptance with a measurement of accuracy, and maintenance covering monitoring and retraining.
Do I need my own model? In most business applications, no. Systems built today use models available through an interface, and the project work sits in what happens around the model: data, rules, safeguards and integration.
What does maintenance cost? It depends on the number of queries and on what runs around the model. In our two systems, each serving a single company, the bill comes to 0.65 and 0.42 dollars a month, with the model accounting for about 2 cents. At larger scale the proportions change, but the question stays the same: how many times a day does the system ask the model.
What happens to my data? That is settled during the project and written into the contract. In our finance system, sensitive data is removed or replaced with hashes before anything reaches the model, so the model sees only what it needs to recognise a category.
How do I know the system works? From a measurement on your data, taken before acceptance, with the number of cases stated and with a description of what the system does with the situations it failed to recognise.
Where to start
With one process that takes time every month and that you can describe in three sentences. If describing it shows that rules are enough, that is a good outcome of the conversation rather than its failure.
Find out whether your process needs a model at all
A free digital audit takes one to two days and ends with a diagnosis, not a quote. You will also hear it when rules are enough and no model is needed.
Book a free audit →
