— 6 reading minutes
When someone tells us they want to add AI to their product, the price question usually comes up in the first meeting.
Integrating AI into an application today almost always means using an existing model (Gemini, GPT, Claude or another) and connecting it properly to your data and processes. Training your own model is the exception, and that changes the order of magnitude of the price.
The price has two parts: development, paid once and depending on what gets built, and usage, paid every month and growing with the number of people using it and how much each of them asks.
Development and usage prices
Development
| Type of integration | Development | What it depends on |
|---|---|---|
| A model call with a structured response (classifying, summarising, a basic recommender) | €2,000-3,000 | How much data goes to the model and how the response fits into your application |
| An assistant over your company's documents (RAG) | From around €10,000 | Volume and state of the documents, permissions, keeping them up to date |
| Recommender with embeddings and semantic search | From around €10,000 | Catalogue size, available user signals, measurement |
| Turning documents into structured data | Worked out case by case | Variety of formats, scan quality, human validation |
| Cataloguing and describing content automatically | Worked out case by case | Collection size, review workflow, search |
| Training your own model | Rarely worth it | Labelled data, compute, specialised team |
These are ranges by type of project, based on our own work, with no figures from any specific client.
Monthly usage
| Assistant over documents | Queries per person per day | Model cost per person per month |
|---|---|---|
| Light use | 5 | Around $2 |
| Regular use | 20 | Around $7 |
| Heavy use | 50 | Around $18 |
Integrations that work per request (a recommender, classifying tickets, extracting data from a document) come to around $9 per thousand requests.
Before you ask for a quote
Before talking money with anyone, I'd be clear on what decision or task you want to make easier, in as much detail as you can; who makes the final call, since it's almost always worth having a person review what the AI suggests; and how you'll know it works (less time per case, fewer errors, more sales of a certain product).
Sometimes, while working that out, it turns out better filters or a good old rule would solve the problem. It's cheaper and there's no model to maintain. More than once we've ended up recommending in the first meeting not to use AI.
Types of AI integration
A model call with a structured response
This is the simplest and most common integration. Your application sends a small amount of data to a language model through its API and gets back a response it can process: a category, a summary, a score, a ranked list. It works for classifying support tickets, summarising records, tagging emails or building a first recommender.
At La Psicóloga en Casa the recommender works like this: the patient describes their situation in their own words, Gemini compares it with each psychologist's speciality and availability, and the coordinator chooses from the suggestions. Our article on how to add a recommendation system to your product explains where the €2,000-3,000 figure comes from. [CONFIRMAR: only link if N003 is fully published]
An assistant over your company's documents (RAG)
RAG is the technique that lets a model answer using your documents: before replying, the system finds the relevant passages and passes them to the model along with the question. For that search to work, documents are turned into embeddings (numerical representations of meaning) stored in a vector database.
We built one for ourselves: an internal Google Chat bot that answers from our team's documentation. Costs go up here because there are more moving parts: preparing and splitting documents, keeping them current, respecting who can see what, and measuring whether answers are right. There's more detail in our article on corporate RAG.
A recommender with semantic search
When the catalogue is large or the relationships between items matter, a basic recommender falls short and you need the same pieces as a RAG system: embeddings for the catalogue and for user information, a vector database, search, and traceability to know why each item was recommended. That's why this tier starts at around €10,000.
Cataloguing and describing content automatically
For Carte, AI analyses an archive of more than 7,500 posters, suggests descriptions and tags, and lets people search by meaning. Everything it generates is stored as a suggestion until a person reviews it. Designing and building that review workflow is part of the budget.
Turning documents into structured data
Contracts, invoices or reports that arrive as PDFs and need to end up in a database. In Prisma, each company defines templates for its documents, the system extracts the data with AI, and users validate it. The price depends mostly on how many different formats you need to support and on the quality of what comes in.
Training your own model
It makes sense in very specific cases: a problem no existing model can solve, plenty of well-labelled data of your own, and enough volume to justify the investment. Labelling data, training and maintaining the model quickly reaches a different order of magnitude. In the projects we see, an existing model connected properly to your data solves the problem for a fraction of the cost.
What drives up the development price
The algorithm is usually the smallest line on the invoice. Most of the cost goes into:
- Data quality. If the information is scattered across spreadsheets, emails and messy folders, it has to be sorted first.
- Integrations. Connecting to your CRM, ERP or existing application costs more than the model call.
- Human review in the workflow. Designing screens where someone validates what the AI proposes takes time, and it almost always pays off.
- Sensitive data. Health data and other GDPR special categories mean minimising what goes to the model, deciding how long it's kept, and documenting it.
- Processing in Europe. Picking a European server is only part of it: every provider in the chain (model, database, logs, email) has to be checked for where it processes data. If you need AI development in Europe, that check belongs in the initial design.
- Measurement. A test set with real cases to know whether the system gets things right, and whether a change makes it better or worse.
- AI Act transparency. Since 2 August 2026, if a person talks to an AI or receives generated content, they must be told or it must be labelled. We cover it in our article on Article 50 of the AI Act.
What it costs to run each month
Language models are billed by the volume of text processed, measured in tokens. A token is roughly 4 characters, and the tokens you send to the model (input) are billed separately from the ones it generates (output). The monthly bill comes from multiplying 3 things: how many people use it, how many queries each of them makes, and how many tokens each query uses.
That's why we give usage per person. An assistant used by 5 people and one used by 500 can come from the same development work and have monthly bills 100 times apart. Using the table above, a team of 50 people with regular use would spend around $360 a month on the model.
Where the figures come from
We did the maths with Gemini 3.8 Flash on Google Cloud, at the price it will have from 1 January 2027: $1.50 per million input tokens and $7.50 per million output tokens. Until 31 December 2026 Google offers it at half price as a launch rate. Processing on European servers costs around 10% more. Prices change often, so check the official pricing page and keep the order of magnitude in mind. [CONFIRMAR: current price on publication day]
For the document assistant we assumed around 6,000 input tokens and 1,000 output tokens per query, which comes to about $0.017, and 22 working days a month. For per-request integrations, around 2,000 input tokens and 800 output tokens. If your case looks quite different, you can redo the maths with your own numbers.
What makes a query cost more
In a document assistant, the question is the lightest part. Each query sends the model the instructions, the document passages the search has found and, in a conversation, the history of earlier messages. A long conversation resends everything before it with every new message.
Models that reason before answering generate tokens you don't see, and they're billed as output. Switching to a more powerful model can multiply the price by 2 or 3. For many tasks a model from the fast range is good enough, and the test set we mentioned earlier is how you check.
Other monthly costs
Infrastructure: the vector database, document storage and logs of what the system does. It grows with the volume of documents and with how many people use it at the same time. An assistant for a team of 4 with a few hundred documents fits in a standard PostgreSQL database with the pgvector extension, and the infrastructure comes to between €30 and €100 a month. One for a large company, with millions of documents and thousands of users, needs a dedicated vector database, more storage and high-availability servers, and there we're talking thousands of euros a month or more.
Maintenance: providers retire model versions, and you have to migrate and check everything still works the same. If it's planned ahead, the migration can be done without rushing.
Periodic review of results: looking at a sample of what the system suggests every so often and adjusting whatever needs it.
We set up the infrastructure in each client's name, so they pay model usage and servers directly to the provider and see it on their own invoice.
Where these projects tend to go over budget
AI projects go over budget for the same reasons as any custom software, and on top of that it's easy to underestimate the time needed to prepare the data and tune the system in the first weeks. We go through the usual causes in why custom software development budgets overrun.
Sorting out processes before adding AI
When we wrote the first version of this article a few years ago, we already said the underlying reason to innovate in a project is rarely technological. It's often more worthwhile to sort out a process living in 4 spreadsheets than to add a layer of AI on top, and sometimes a classic decision tree solves the problem better and for less.
Where we would start
We'd start with a small, measurable use case, using data you already have, with a person reviewing what the system suggests. A first version of the simplest tier, used by a handful of people, gives you real information on whether it's worth going further and on what usage will cost once you open it up to the whole team.
If you're considering custom AI development for your application, tell us what you want to solve and we'll tell you which tier you'd be in, or whether something simpler would do.