A practical method for scoring AI use cases on value, feasibility and risk, so your portfolio decisions hold up before the board, audit and regulators.
ai-embed Insights · 29 October 2026
Most enterprises do not suffer from a shortage of AI ideas. They suffer from a surplus of them, each championed by a senior sponsor, each described as strategic, and each competing for the same scarce data engineers, risk reviewers and change capacity. In that environment, prioritisation is where strategy becomes real. It is also where it most often fails, because the scoring model is built to produce consensus rather than a defensible decision.
A scoring approach survives scrutiny when a sceptical finance director, an internal auditor or a regulator can read it, challenge any number, and trace that number to evidence. That is a higher bar than a workshop with sticky notes and a weighted spreadsheet. It is achievable, and it does not require a complicated model. It requires discipline about what is being measured, who is allowed to score it, and what happens when the evidence changes.
The most common weakness in use case scoring is a value dimension that rewards enthusiasm. "High impact" means little unless it is tied to a named metric owned by a named function: cost per case handled, days sales outstanding, loss ratio, forecast error, time to onboard. Begin each use case by stating the baseline, the expected movement, and the mechanism by which the AI system causes that movement. If the mechanism depends on people changing how they work, say so, because adoption is part of the value case and not an afterthought.
Ask the business owner, not the technology team, to sign the value estimate, and ask finance to challenge it. Express value as a range with a stated confidence rather than a single figure. A use case promising a modest, well-evidenced gain in a process that runs at scale will usually outrank a spectacular claim resting on three untested assumptions. Include the cost side honestly: integration, data remediation, model operation, monitoring, human review and ongoing support often exceed the build cost over the life of a system. Score on net value over a fixed horizon, typically two to three years, so that quick wins and slow-burn platforms are compared on the same footing.
Feasibility is where enthusiasm meets the estate. Score it across four questions that can each be answered with something tangible. Is the data available, accessible and of sufficient quality for this task, and has anyone actually sampled it? Can the solution integrate with the systems where the work happens, or will it sit beside the workflow and be ignored? Does the organisation have, or can it realistically acquire, the skills to build and run it? And is the process stable enough that the system will not be obsolete on arrival?
The strongest practice is to convert unknowns into cheap tests before committing. A two-week data profiling exercise or a small evaluation against real historical cases tells you more than any amount of discussion. Where a use case scores poorly on feasibility only because nobody has looked, mark the score as low-confidence and fund the investigation, not the build. This keeps promising ideas alive without allowing them to consume delivery capacity on faith. Also be candid about reuse: a use case that relies on a shared data product or platform capability that other initiatives will need should receive credit for that, since the second and third deployments are far cheaper than the first.
Averaging risk into a composite score hides exactly what a board needs to see. A use case with excellent value and feasibility but an unacceptable exposure should not creep up the ranking because it offsets a high risk with a high return. Use risk in two ways. First, apply a small set of hard gates: legal basis for the data used, regulatory classification, security posture, and whether the organisation can explain and evidence decisions to those affected. Anything failing a gate is paused until it is resolved, regardless of its score.
Second, use risk as a modifier on use cases that pass. For organisations operating in the EU, classification under the EU AI Act should be an early step, since prohibited practices and high-risk categories carry obligations that materially change cost and timeline. Where personal data is involved, GDPR considerations, including data protection impact assessments where required, belong in the scoring conversation from the outset, not at launch. Sector rules matter too, particularly in financial services and healthcare. Record the risk rationale alongside the score, and involve risk, legal and security colleagues as scorers with real authority, not as reviewers at the end. Late involvement is the single most reliable source of expensive rework.
A scoring model is only as credible as its process. Fix the criteria and weights before you see the candidate list, so that nobody tunes them to favour a preferred project. Have scorers rate independently first and discuss afterwards, and record where they diverge, because disagreement is information. Keep an evidence log for each score, and review the portfolio on a regular cadence, since feasibility and risk change as data improves, vendors evolve and regulation matures.
Finally, make the output a decision, not a league table. Sort use cases into those to scale, those to test, those to park with a stated trigger for revisiting, and those to stop. Be willing to stop things; a portfolio with no exits is a wish list.
A prioritisation model earns its place when it lets you say no, clearly and with evidence, to a project someone senior wanted. Score value against a metric someone owns, feasibility against tests you have actually run, and risk as a gate you will honour. If the numbers can be challenged and still stand, you have a portfolio. If not, you have a preference with a spreadsheet attached.