A simple model for scoring AI ideas on value, data readiness and risk, and choosing your first pilot.
In short
Prioritise AI use cases by starting from a concrete task, not a technology. Score each idea separately on business value, data readiness and risk, and treat a weak score in any one as a blocker. Then pick a small pilot with a measurable outcome, a fixed scope and a date on which you decide to continue, narrow or stop.
Most leadership teams can produce a long list of AI use cases in an afternoon. Choosing between them is harder. A sales assistant, a forecasting model and an invoice classifier solve different problems, need different data and create different responsibilities. Putting them on the same slide does not make them comparable.
This guide is written by Devies, a Gothenburg-based product and engineering consultancy that builds data platforms and AI solutions for Nordic companies. It describes a practical way to turn a list of ideas into a decision, which is the part of an AI strategy that is most often skipped. It works the same whether the build is done by an internal team, an AI consultant or a specialist AI company.
How should you collect AI ideas so they can be compared?
Collect every AI idea as a described business problem with a task, a user, an owner and a baseline, using the same template for each one.
"We need an AI agent" leaves too much open. Who will use it? Which task takes too long today? What happens after it answers? Rewrite the idea as a problem instead: "Our service desk spends time finding approved troubleshooting instructions across several systems." That statement can be investigated before anyone chooses a model or a vendor.
Use the same intake template for every idea:
- Task: which piece of work should get better, and how often it is done.
- Users: who does the work today, and a recent real example they can show you.
- Owner: one person in the business with the mandate to change the way of working and judge the result.
- Baseline: time, quality or cost today, so you have something to compare against.
- Simpler alternative: could the problem be solved with a rule, a shared definition or an automated data flow, without AI?
The last question matters. Many proposed AI solutions are really reporting or integration problems. AI is worth testing when the task contains variation that simple rules handle badly, and when there is a practical way to check the output. An idea without an owner needs a sponsor before it needs software.
How do you score AI use cases on value, data readiness and risk?
Score value, data readiness and risk as three separate gates, because a high score in one cannot compensate for a failing score in another.
The three measures answer different questions. Value: does it matter if this task gets better? Data readiness: is the right data available, with the right permissions, at sufficient quality? Risk: what happens if the answer is wrong, and will someone notice in time?
The example below is invented to show the model. It is not a client case and not a description of a Devies method. The scale is 1 to 5, and higher is better in every column (a high risk score means low risk).
Use case
Value
Data readiness
Risk (5 = low)
Biggest dependency
Decision
Find approved service instructions
Value
3
Data readiness
4
Risk (5 = low)
4
Biggest dependency
Outdated documents, permissions
Decision
Pilot with one service team
Suggest coding for supplier invoices
Value
4
Data readiness
3
Risk (5 = low)
3
Biggest dependency
Historical examples, finance review
Decision
Check the data first
Automated credit decision
Value
5
Data readiness
2
Risk (5 = low)
1
Biggest dependency
Regulation, explainability, cost of errors
Decision
Separate investigation, not a first pilot
Do not add up the columns and call the total objective. Let each column act as a gate instead. A serious permissions problem should stay visible even when the idea has an attractive savings estimate. Also ask which assumption would change the decision. For the service instructions, missing permissions or unreliable source documents could remove the whole benefit.
Risk is not only technical. The EU AI Act, Regulation (EU) 2024/1689, classifies AI systems by risk level, and its Annex III lists AI used to evaluate the creditworthiness of natural persons as high-risk. Ideas like that need their own legal assessment and rarely suit a first pilot. As of October 2026, the application dates for the Annex III high-risk obligations have been amended during 2026, so check the date that applies to your case on EUR-Lex before you plan around it. For a structured way to describe and measure AI risk, the NIST AI Risk Management Framework is a useful, freely available reference.
How do you assess data readiness for a specific use case?
Data readiness is a property of one task, not of the whole company, so assess it by tracing real questions back to their sources.
You may be ready for an internal document assistant and far from ready for automated forecasting. Take a typical question and follow it back to the source. Where does the answer live, who maintains it, and how does it reach the application? Then do the same for an exception. You will often find two "final" versions of the same document, free-text fields in the CRM, or an export that silently leaves out cancelled orders.
Check five things:
- Ownership: who decides which source is authoritative?
- Definitions: does "customer" mean the same thing in sales and finance?
- Freshness: how old may the information be when it is used?
- Permissions: does each user only see what they are allowed to see, including in answers and logs?
- Evaluation: do you have representative questions with known correct answers?
If any of these answers is unclear, it is usually cheaper to fix it first than to switch models later.
What makes a good first AI pilot?
A good first AI pilot is narrow, measured against today's baseline, and ends on a fixed date with an explicit decision.
Decide how the pilot will be judged before you build it. For a search assistant, that could be the share of answers that point to the correct approved source, the time per case, and how often a reviewer has to correct the answer. Include hard cases and questions that have no valid answer, and check that the system declines instead of making something up.
Set three limits:
- Scope: one user group, one document collection or one flow.
- Decision date: when you will decide to continue, narrow or stop.
- Stop condition: for example, if the benefit disappears once review and integration time are counted.
Keep the baseline as your reference. Otherwise you may celebrate fast answers and miss the extra review time needed to make them usable. A pilot that ends in "stop" with a clear reason is a good result: it cost little and it protects the budget for the next idea on the list.
How do you scale an AI pilot that works?
Scale a successful pilot only after testing it with more users, real permissions, exceptions and changing data, on a shared data foundation.
A successful pilot shows that certain tasks worked under tested conditions. Before you widen it, test more users, real permission structures, edge cases and data that changes over time.
This is where the data foundation becomes decisive. A controlled document collection or a single integration is often enough for a pilot. When several AI use cases need to share the same sources, definitions and data flows, it pays to build a common data platform instead of a new pipeline per idea. If you are at that point, our comparison of Microsoft Fabric, Databricks and Snowflake covers the platform choice. Document who will run the service when inputs or business rules change.
Close every prioritisation round with a short decision record: what you will test, what you are postponing and why, with an owner, dependencies and the next decision point for each idea.
Devies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
Should we pick the AI use case with the biggest savings?
Not automatically. Compare the savings estimate with the evidence behind it. A calculation that leaves out review time, integration work and ongoing maintenance is incomplete, and large-savings ideas often carry the highest risk or the weakest data. A smaller use case with a measurable outcome and a clear owner is usually a better first pilot, because it teaches you how AI performs on your own data.
Do we need a finished data platform before running an AI pilot?
No. A scoped, approved dataset or a controlled document collection is often enough for a first pilot. A data platform becomes relevant when the task needs several sources, recurring transformations or shared definitions, or when several AI use cases will depend on the same data. Building the platform first, before any use case is proven, risks investing in data nobody ends up using.
Should we hire an AI consultant or an AI company, or prioritise ourselves?
You can do much of the work yourselves with the intake template and scoring model above. External help is most useful when you lack experience assessing data readiness and risk, or when internal interests make neutral prioritisation difficult. If you bring in an AI consultant, ask for a written decision record with owners, dependencies and stop conditions, not just a longer list of ideas.
What is an AI use case?
An AI use case is a specific business task where an AI system produces an output, such as an answer, classification or forecast, that a named user acts on. A good use case statement names the task, the user, the data it depends on, how often it happens and how success is measured. "Use AI in customer service" is a theme; "find approved repair instructions for service agents" is a use case.
Sources
- Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act)
- NIST AI Risk Management Framework, Core
- Devies: Data and AI Use Case Discovery Workshop
- Devies: Data Hub
- Devies: Data Foundation Platform







