Business Finland
Is synthetic data generation an eligible R&D activity?
Generating synthetic data to train or evaluate a model can be genuine R&D or routine tooling, depending on what question it's answering.
Short answer: Yes, synthetic data generation can be a legitimate R&D activity — and often a strong one, because it directly addresses a data-scarcity uncertainty that’s a common reason AI projects qualify for funding in the first place. But it’s not automatically R&D just because “synthetic data” sounds technical. It qualifies when generating the data, or validating that it’s usable, is itself an open question — not when you’re running an established generation pipeline to produce more training examples of a kind that’s already well understood.
Why this question comes up so often
Data scarcity is one of the most legitimate forms of technical uncertainty in AI R&D — you genuinely don’t know whether a model can be trained to acceptable quality without enough real-world examples. Synthetic data generation is frequently the proposed solution. That makes it a natural fit for an R&D uncertainty section, but only if the generation work itself carries uncertainty, not just the model it feeds.
When synthetic data generation is R&D
The generation methodology itself is unproven for your domain. You’re testing whether a particular generation approach — simulation, procedural generation, model-based generation, a novel augmentation strategy — actually produces data that’s usable for your specific problem, and that’s not established in advance.
There’s an open question about fidelity or distribution match. It’s unclear whether synthetic examples are close enough to real-world distribution to train a model that generalizes, and part of the project is measuring and closing that gap.
You’re building a novel evaluation to test synthetic data quality. Since there’s often no ground truth for “is this synthetic example realistic enough,” building and validating that evaluation methodology can itself be the R&D.
The generation process needs new technical work to be feasible at all. For some domains, generating usable synthetic data requires solving its own hard technical problem — not just calling a generator, but developing the approach that makes generation viable.
When it’s not R&D
If the generation method is standard (e.g. calling an established augmentation library or a well-known synthetic-data technique for a well-understood data type) and you’re using it simply to produce volume, that’s routine tooling in service of a model-training pipeline — not R&D activity in its own right. The R&D, if there is any, would need to live elsewhere in the project.
How to frame it in an application
Separate the generation step from the uncertainty it’s meant to resolve. Don’t write “we will generate synthetic data to train the model.” Write what’s actually unknown: “it is unclear whether [generation approach] produces data with sufficient [fidelity/coverage/distribution match] to train a model that performs acceptably on [real-world task], and this project will test that through [specific validation approach].”
FAQ
Does synthetic data generated by an LLM count differently than procedurally generated data? No — the eligibility test is the same regardless of generation method: is there a genuine open question about whether the approach produces usable data for your problem.
Can the entire R&D uncertainty be “does synthetic data work for our use case”? Yes, if that’s honestly unresolved and the project is structured to test it with a defined validation methodology — this is one of the cleaner data-scarcity R&D framings available.
Does this overlap with data labeling as R&D? Related but distinct — see the companion piece on framing data collection and labeling as R&D, linked below, for the labeling-specific version of this question.
Are the compute costs of generation eligible? Generally yes, when generation is part of the funded R&D work — see the pieces on API and GPU cost eligibility for the underlying reasoning.
The one-sentence version
Synthetic data generation is R&D when the generation approach itself, or its fidelity to real-world data, is genuinely unproven for your problem — and routine tooling when you’re just using an established technique to produce more of something already well understood.
Related: How to frame data collection and labeling as R&D (not routine operations) · How to write the R&D uncertainty section of a Business Finland application · Is your AI idea R&D or just implementation? A decision framework