Polish AI agencies now publish ready-made price brackets: a few thousand złoty for a simple assistant, tens of thousands to automate a process, hundreds of thousands for an organisation-wide rollout. It is not that they are invented. The problem is that they almost never come with any statement of what sits inside them, how much is a one-off build against a standing running cost, or how many projects they are based on.
Why a price bracket tells you so little
A range of “15,000 to 50,000 złoty” is close to useless for a budgeting decision. The distance between its lower and upper ends is usually the distance between two entirely different projects — not between a cheaper and a dearer version of the same one. At the bottom of such a range there is typically one process, one integration, and a person approving every output. At the top: several systems, a data migration, and oversight requirements.
So if you are after a number to put in a budget, what you need is not somebody else’s bracket but an understanding of what moves the cost in your particular case. Below are the six factors that move it hardest, and at the end, a procedure you can work through yourself before speaking to anyone.
Six things that genuinely decide the price
1. The number and kind of integrations
This is the single strongest factor. A feature that reads from one system and writes nowhere is a different order of work from one that pulls data out of an ERP, writes the result into a CRM, and triggers an action in a warehouse system.
Every integration means its own authentication, data-model mapping, error handling, rate limits and — often the longest part — getting access from whoever owns that system. When you are counting cost, count integrations, not features.
2. The state of the data
AI will not fix a mess in your data. It will expose it.
If the information the system is meant to work on lives today in scanned PDFs, in email attachments and in three people’s heads, a substantial part of the budget goes on getting it into a machine-readable state before any AI enters the project at all. That is neither a hidden nor an unnecessary cost, but it does surprise people, because nobody calls it “implementing AI”.
The diagnostic question is a simple one: could you export the last hundred cases of this process as a table today? If you could, you are in a good position. If you could not, you already know what the first part of the budget is for.
3. The level of certainty required
This factor is the most frequently overlooked, and it can change the cost more than the choice of technology.
A system that makes suggestions to a person and may be wrong in a meaningful share of cases is cheap. A system that runs unsupervised and has to be dependable is incomparably dearer — because cost does not rise linearly with accuracy. Those last few percentage points are precisely the part of the project that contains quality evaluation, fallback paths, detection of unusual cases, and monitoring.
Before you ask about price, settle what error you can live with and what happens when it occurs. That is one decision, and it can move a quote by an order of magnitude.
4. The unit cost of running it
Models bill per operation, so the running cost follows volume rather than company size. It is worth working out directly: the cost of one operation multiplied by the number of operations per month.
Price differences between models can be several-fold, so at high volume a sensible strategy is the cheapest model that clears your quality bar — not the best model available. On top of that sit the fixed pieces: hosting, a vector database, monitoring.
5. Oversight, documentation and compliance
If the system processes personal data, the scope gains a lawful basis for that processing, data minimisation and security. If it also bears on decisions with material consequences for people, it gains things that have to be built rather than merely described: event logging that lets a decision be reconstructed, a genuine opportunity for a human to intervene, technical documentation.
That is a separate package of work, not a checklist item — and in some applications an obligation rather than a choice. We cover it in more depth on the AI Act readiness audit page, along with which duties already apply and which only arrive in 2027.
6. Change inside the organisation
A system nobody uses costs one hundred per cent and returns nothing.
An implementation that is going to pay for itself includes training the people who will use it, rethinking the process around it, and naming somebody who owns it once the project ends. This part rarely appears in a published bracket, and it is often the difference between a working system and a cost to be written off.
The build is not the whole bill
The commonest budgeting mistake is treating an implementation as a one-off expense. The running cost is made of at least four things: model and infrastructure charges that follow volume, quality monitoring, fixes prompted by changes in the systems it integrates with, and periodic retesting.
That last item catches people out. Model providers retire older versions, and a solution built and tested against a version that stops being available has to be tested again — and sometimes adjusted. It is an ordinary software maintenance cost, except that in this case the provider, not you, decides when it falls due.
How to estimate your own order of magnitude
Before you ask anyone for a quote, work through five steps. They take an hour and will tell you more about the price than any published bracket:
- Pick one process, not “AI for the business”. A specific one, with a name and an owner.
- Count its scale — how many times a month it happens, and how many minutes it takes each time.
- List the systems it touches: where the input data comes from and where the result must go.
- Settle what error is acceptable, and what happens when the system gets it wrong.
- Check the data — could you export the last hundred cases of this process today?
Points 3, 4 and 5 are what actually set the price range. Point 2 tells you whether it is worth doing at all: a process that runs five times a month rarely justifies an integration project, however well suited to automation it might be.
Questions worth asking before you sign
- What exactly does the quoted price include, and what falls outside it?
- What is the expected monthly cost after go-live, at our volume?
- What happens when the model provider retires the version this was built on — and who pays for the adjustment?
- Who owns the code, the prompts and the configuration once the project ends?
- How will we measure that it works? Which number, measurable today, is supposed to change?
- What happens when the system gets something wrong — who notices, and how?
The answers tend to be more diagnostic than the figure itself. A supplier who cannot estimate the monthly cost has probably not maintained what they built before.
When implementing AI is not worth it
The cheapest implementation is the one you do not do. It is worth holding off when:
- the process runs rarely — the cost of integration is largely fixed, and does not fall because you use the finished thing less often;
- the data does not exist in a usable form and nobody plans to change that;
- the process is not defined — if two people carry it out differently and both believe they are right, automation will entrench the ambiguity and speed up its consequences;
- the real problem is something else — sometimes the bottleneck is an unmade decision, or a form nobody fills in, rather than a lack of automation.
If you would like to see what a project like this looks like in terms of scope and stages, we set it out on the AI implementation page — including what is produced at each stage and what you are left with at the end.