Choose the Work Before You Choose the AI
A Nordic energy-company case found 41 possible AI uses, but the useful work began by ranking business value, difficulty, data readiness, and fit with existing workflows.
Scope note: This essay covers how one Nordic energy company identified and ranked possible AI uses. The study reports needs and pilots, not production-scale returns from all 41 ideas.
There is no shortage of AI use cases. There is a shortage of reasons to choose one before the others.
Researchers spent four weeks with a Nordic energy company, interviewing 16 people across nine departments and reviewing internal material. They identified 41 possible uses for AI and grouped the recurring needs behind them.
The list included reporting, forecasting, data integration, maintenance, anomaly detection, compliance checks, and internal search. The more useful contribution was not the list. It was the attempt to connect each idea to business value, implementation difficulty, available data, and an existing workflow.
Start with friction people can name
Employees described repeated reporting, manual checks, scattered data, forecast preparation, and information trapped across systems. These were not speculative tasks invented to justify a model. They were known sources of delay and rework.
That grounding matters. “Use AI for forecasting” is still too broad. A workable use case names the decision, the data feeding it, the person responsible for review, and the failure that must remain visible.
Across departments, three priorities kept returning: reporting automation, predictive maintenance, and improved forecasting. Those areas mattered because they sat inside daily operations and long planning cycles. They also exposed the dependencies that a demo can avoid: old systems, inconsistent data, regulatory checks, and human approval.
The researchers found that employees mostly imagined AI as support for current work, not a replacement for the people doing it. That may sound cautious. In critical infrastructure, caution has a job.
Forty-one ideas require a queue
A large use-case inventory creates the appearance of strategy. Without sequence, it is a cabinet full of labeled bones.
The paper ranks opportunities through business importance, ease of implementation, and expected value. That basic discipline prevents a visible but difficult project from consuming the resources needed for smaller, proven gains.
The authors recommend a phased path. First improve access to data and connections between systems. Then add assistive tools for search, reporting, and checking, with human approval. Expand into forecasting, monitoring, and anomaly detection when the data and governance can support them.
I would add one hard gate: name the evidence that would cause the organization to stop. A pilot should have a failure condition before it has a launch date. If the result cannot beat the current method on a measure that matters, it has not earned the next phase.
Search becomes more useful when it returns the dataset too
The team built two small demonstrations. One drafted customer email responses. The other allowed employees to ask questions across internal documents.
The search pilot addressed a precise pain point: staff needed the answer and the data associated with it. Retrieving an explanation without the underlying dataset would have left the employee hunting through another system. Joining the two made the proposed workflow more complete.
That detail is easy to miss. Enterprise knowledge is not only prose. It includes tables, files, measurements, owners, dates, and systems of record. A useful agent must preserve those relations or it will create a clean answer with a dirty handoff.
The case is a map, not a return statement
This is one company. Senior staff and unit leads were deliberately favored in participant selection, which may understate the needs of junior and operational employees. Eight interviews were recorded and transcribed; the rest relied on structured notes. The pilots demonstrated feasibility but did not establish broad business results.
The study is therefore strongest as a discovery method. It shows how to begin with work, gather needs across departments, find repeated patterns, and rank them against the state of the organization.
Do not begin with the most advanced model. Begin with a stable problem, a responsible owner, usable data, and a result that can be checked. The tool comes after the choice. Otherwise the choice belongs to the tool.