Wrong approach can get expensive

The first question in an AI project is often framed incorrectly. The comparison starts from models and prices, when the first thing to define is what the business needs to achieve: how good result is good enough, what kind of error is acceptable, what data may be processed, and how the service must behave when something goes wrong.

This is no marginal question. According to Statistics Finland, in spring 2025, 38 percent of Finnish companies and 68 percent of companies with at least 100 employees were already using AI technologies. In Eurostat’s comparison from the same survey round, Finland ranked second in the entire EU for AI adoption, while the Union average stood at 20 percent. Yet only 15 percent of Finnish companies had documented guidelines or practices for their AI systems. Finland is at the top of Europe in terms of adoption, but not in terms of justification. Use has spread faster than the ability to justify it.

AI unit prices have dropped to a fraction of their level within a couple of years, and the decline continues. Still, companies’ total costs are rising, because there is a steady stream of new users and new material to process, and AI agents multiply the number of model calls used. In August 2026, Gartner estimated that the cost of agentic workflows will more than quintuple by 2028. Routing a task to a reasoning model costs at least five times more than handling the same thing as an ordinary conversation, and the gap widens as the task grows more complex. A cheaper unit price does not shrink the AI bill. It grows usage.

Therefore, the decisive factor is the cost of an approved production result, once integrations, quality assurance, failed runs, monitoring and maintenance are taken into account. When this is not taken into account, the bill comes later: Gartner estimates that more than 40 percent of agent-based AI projects will be canceled by the end of 2027, due to costs and unclear business value.

Cloud and local deployment solve different problems

A managed cloud service is often the best solution when you want to get up and running quickly, need the newest capabilities, or face fluctuating load. The provider handles a large part of the infrastructure. Depending on the service, strong controls can be built into the cloud through encryption, network segmentation, and access rights.

A model run in your own environment and released with open model weights can suit a stable operating environment and recurring tasks where volumes are predictable, or when you do not want to move data to an external service. Open model weights mean the model can be downloaded into your own environment, they do not automatically make the whole model open source.

Some client engagements are carried out in high-security-classification environments where public cloud is out of the question. In these cases, a carefully selected, locally run model is the only sustainable solution.

However, local deployment is not self-evidently cheap or secure. Hardware, capacity, updates, information security, and quality monitoring all remain the organization’s own responsibility. The choice holds up only if these capabilities and costs are part of the comparison.

A combination of cloud and local deployment can be justified when high volume is processed in-house and the most demanding tasks are handled by a cloud model. But a hybrid is not automatically the ideal solution: interfaces and parallel ways of working add to the totality that must be maintained. The benefit has to be demonstrated through measurement.

Sometimes the best solution is not a generative model at all. A traditional machine learning model, a rule-based system, or robotic process automation can solve a bounded task more cheaply and more predictably.

Trust has to be proved

Trust in AI is not a single security setting. It is the ability to show that a solution works for the agreed task, handles data securely, keeps its costs under control, and withstands change. Before choosing a model, a decision-maker should demand answers to four questions:

1. What metric is used to approve the quality of the output, and at what point is a human needed in the decision-making?
2. What data does the solution use, where is that data stored, and how long is it retained?
3. What is the total cost at real usage volumes, including integrations, monitoring, and maintenance?
4. What happens during a service outage, or when the vendor, price, or model changes — can the solution be changed without rebuilding the entire service?

These questions turn the technology discussion into business requirements, and reveal whether speed, data control, or continuity weighs most in the situation at hand.

The EU AI Act supports the same reasoning: obligations are determined by risk and role. In the Digital Omnibus amendment that took effect in July 2026, obligations for high-risk systems (Annex III) were postponed to December 2027, and for systems embedded in products (Annex I) to August 2028. Obligations for general-purpose models, however, have been in force since August 2025, and transparency obligations since August 2026.

Postponement gives extra time, not exemption: data flows, roles, and responsibilities should be documented as part of the selection from the beginning.

A durable solution can also be replaced

Small models and those released with open model weights are advancing rapidly: in Stanford’s AI Index, the smallest model to reach a score above 60 percent on a broad knowledge test (MMLU) was 540 billion parameters in 2022 — by 2024, a model 142 times smaller was enough for the same result. At the same time, cloud services gain new features and pricing models keep shifting. Today’s good choice must not become tomorrow’s lock-in.

Replaceability does not mean a model can be swapped at the push of a button. A new model must always be tested with the company’s own data, quality criteria, and risk limits. A well-built solution, however, separates the business logic from the model, preserves the evaluation dataset, and makes retesting a controlled process.

Reliable AI does not come from the best-known model, the biggest cloud, or local deployment. It comes from the ability to justify the choice, measure how well it works, and change the solution. HiQ’s role as a partner is not to steer the client onto a single platform, but to help find and validate the right combination for the use case.

The author is Jukka Salmenkylä, AI Architect at HiQ, who helps clients select and validate AI solutions suited to their business.