The problem is not training a model. It is keeping it in production.
Most artificial intelligence projects do not fail during testing. They fail afterwards.
The demo works, the results look promising, and then the project stalls. Not because the technology did not work, but because no one had planned for what it takes to keep it working every day: who checks that it continues to provide accurate answers, what happens when the data changes, how much it costs per month, and who steps in when something breaks.
Our work focuses primarily on this second part. A model that works in testing but has not been set up to operate in production is a cost, not an investment.
What this means in practice
- Predictions and automated responses do not live in a file on someone's computer: they are a service that processes can query at any time.
- Quality is measured over time, not just on the day of acceptance testing. If the model degrades, you know before your customers do.
- Monthly costs are known and predictable: this is the aspect that most often gets out of control in AI projects, so for us it is a project parameter from the start.
Three levels of continuous monitoring
- The service responds: an unreachable model means a halted process. Continuous monitoring.
- Input data resembles what was expected: if the population changes, the model can start making mistakes without signaling it. Daily monitoring.
- Predictions prove to be accurate: this is the only measure that truly matters, but it always comes later — the outcome of a thirty-day prediction is only known after thirty days.
It is precisely because the third check comes late that the second is essential: it is the early indicator that allows action before the damage occurs.
Versioning and controlled deployment
Every model in production has a version linked to the data it was trained on and the parameters used. When a rollback is needed, it can be done in a single operation.
New models are deployed alongside the active model: they receive real traffic without their responses being used until they demonstrate that they perform better than the current model. It is the least costly way to validate performance on real-world data.
AI that answers based on your company knowledge
For applications that need to answer questions based on company documents and procedures, the system retrieves the relevant passages from the knowledge base and generates a response citing the source. Quality almost always depends on the retrieval stage, not the generation: if the right passage is not found, no model can compensate for it.
That is why we work on how documents are segmented and indexed, and evaluate the system using real questions from your company, not generic tests. The system is designed to answer “I don't have enough information to answer” when appropriate: in a business context, that is more useful than a system that always provides an answer.
Costs and confidentiality
Latency and cost per invocation are project constraints, not subsequent optimizations: they determine model size, response-reuse strategies, and the use of smaller specialized models for high-volume tasks. A model trained for a narrow task is often more cost-effective and more stable than a general-purpose model, and this is the approach we apply where volumes justify it.
Company data used for retrieval or model adaptation remains within the European perimeter and is not used to train third-party models.