The wrong approach can get expensive

The first question in an AI project is often framed incorrectly. The comparison starts with models and prices, when the first thing to define is what the business actually needs to achieve: how good a 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 previous level within just 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, while AI agents multiply the number of model calls.

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 task as an ordinary conversation, and the gap widens as the task becomes more complex. A lower unit price does not necessarily reduce the AI bill. It enables more usage.

The decisive factor is therefore the cost of an approved production result, once integrations, quality assurance, failed runs, monitoring and maintenance are taken into account. If these are left out of the equation, the bill arrives later. Gartner estimates that more than 40 percent of agent-based AI projects will be cancelled 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 latest capabilities, or face fluctuating demand. The provider handles a large part of the infrastructure. Depending on the service, strong controls can also be built into the cloud through encryption, network segmentation and access management.

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 and run in your own environment; they do not automatically make the entire model open source.

Some client engagements take place in highly security-classified environments where public cloud is not an option. In these cases, a carefully selected, locally run model may be the only sustainable solution.

However, local deployment is not automatically cheap or secure. Hardware, capacity, updates, information security and quality monitoring all remain the organisation’s own responsibility. The choice only holds up if these capabilities and costs are included in the comparison.

A combination of cloud and local deployment can be justified when high volumes are processed in-house and the most demanding tasks are handled by a cloud model. But a hybrid setup is not automatically the ideal solution. Interfaces and parallel ways of working add to the overall complexity that needs to 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 in AI 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 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 matters 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 under Annex III were postponed until December 2027, and for systems embedded in products under Annex I until August 2028. Obligations for general-purpose AI models, however, have been in force since August 2025, and transparency obligations since August 2026.

The postponement provides extra time, not an exemption. Data flows, roles and responsibilities should be documented as part of the selection process from the beginning.ör dokumenteras redan från början som en del av urvalsprocessen.

A durable solution must also be replaceable

Smaller models and models released with open model weights are advancing rapidly. According to Stanford’s AI Index, the smallest model to score above 60 percent on the broad MMLU knowledge benchmark had 540 billion parameters in 2022. By 2024, a model 142 times smaller was enough to achieve the same result.

At the same time, cloud services continue to gain new capabilities and pricing models keep changing. A good choice today must not become tomorrow’s lock-in.

Replaceability does not mean that a model can be swapped at the push of a button. A new model must always be tested against 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 choosing the best-known model, the biggest cloud provider or local deployment. It comes from the ability to justify the choice, measure how well it works and change the solution when needed.

HiQ’s role as a partner is not to steer the client towards a single platform, but to help identify 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.