Business Finland

Is your AI idea R&D or just implementation? A decision framework

A decision framework for the most misunderstood question in AI funding: whether your project is genuine R&D with real uncertainty, or implementation dressed up as research.

This is the concept that decides most AI funding applications, and it is the one applicants understand least. The line between R&D and implementation is not about effort, cost, or how advanced the technology sounds. A project can take a year, cost half a million euros, and use the newest models available — and still be implementation. Another can be modest and unglamorous and still be genuine R&D.

The difference is uncertainty of a specific kind. This is a framework for locating it.

The core test

Ask one question: at the start of the project, does a competent team already know how to achieve the outcome reliably?

If yes — even if the work is large, skilled, and expensive — it is implementation. You are applying known methods to a known problem.
If no, because there is a real chance the approach will not reach the required performance and you cannot know in advance without doing the work — it is R&D.

R&D lives in the gap between “we intend to build this” and “we know this will work.” Implementation is what happens once that gap is closed.

Where AI teams get it wrong

The trap is that AI feels uncertain because it is complex, probabilistic, and unfamiliar to the business. But complexity is not the same as R&D uncertainty. Integrating a capable off-the-shelf model into your product is difficult engineering, but the outcome is not genuinely in doubt — it is a matter of doing the work well. Evaluators see through “AI is hard” immediately.

The uncertainty that qualifies is at the level of whether the method can work at all under your constraints:

Can we reach the accuracy or reliability the use case demands, on data this messy?
Can we make the system explainable, safe, or controllable enough to deploy in this domain?
Can we get acceptable performance within the latency, cost, or resource limits the product requires?
Can we build a method that generalises beyond a hand-tuned demo to real, varied conditions?

If the honest answer to your central question is “we genuinely don’t know yet, and we can’t know without trying,” you have R&D.

The four quadrants

Plot your project on two axes — is the problem novel, and is the solution path uncertain:

Known problem, known solution — pure implementation. Not fundable as R&D. (Wire an existing model into an existing workflow.)
Known problem, uncertain solution — the sweet spot for a lot of applied AI R&D. (Everyone wants this outcome; nobody has made the method reliable under these conditions.)
Novel problem, known solution — sometimes R&D, sometimes just a new application. Depends on whether adapting the method carries real uncertainty.
Novel problem, uncertain solution — clearly R&D, often the strongest and riskiest projects.

Most credible AI applications sit in the second quadrant. You do not need a novel problem. You need a solution path that is genuinely uncertain.

Reframing implementation into R&D — honestly

There is a legitimate move and an illegitimate one, and they look similar on paper.

The illegitimate move is rhetorical: taking an implementation project and describing it in research language to make it sound uncertain. Evaluators are trained to strip this back to what is actually being done. It fails.

The legitimate move is to find the real uncertainty that was always in the project and was being glossed over. Many teams describe an ambitious project in flat, delivery-flavoured language and bury the hard, genuinely uncertain part. The work is not to inflate an easy project — it is to surface the difficult question that makes the project fundable, and to be honest if there isn’t one.

A worked contrast

Implementation: “We will use AI to automate document classification across our operations.”

The outcome is not in doubt. Document classification with existing models is a solved problem in the relevant sense.

R&D: “We will develop a classification method that stays reliable on our domain’s highly inconsistent, low-volume documents, where standard models degrade below usable accuracy. The uncertainty is whether we can reach acceptable reliability without large labelled datasets we do not have.”

Same technology, same domain — but the second has a real question that could genuinely fail.

What to do with the answer

If the framework tells you the project is implementation, that is useful, not disappointing — it means you should not spend weeks on an application that will not clear the uncertainty bar. If it tells you there is real R&D but it is buried, the job is to bring it to the surface and build the application around it. And if you are not sure, that ambiguity is exactly the thing to resolve before writing, because the whole application stands or falls on it.