Projects that previously met evaluation thresholds are now systematically being reclassified as technological innovation. What evaluators are looking for today, how to detect if your project is at risk, and when to accept that it's not R&D.
Until the first half of 2025, submitting a project that incorporated artificial intelligence, machine learning, or natural language processing was practically synonymous with having a solid argument for accessing public R&D funding, whether through national, regional, or European calls. Proposals describing predictive models, scoring systems based on machine learning, personalized recommendation engines, or multimodal analysis platforms regularly received positive evaluations. The favorable qualification rate for these types of projects was reasonable, and the argument "we are applying advanced AI" served as sufficient technical justification.
Starting in the second half of 2025, and fully consolidated during the first quarter of 2026, this pattern has profoundly changed. Projects substantially similar to those that would have been classified as R&D a year earlier are now systematically being reclassified as technological innovation. This transformation is not an administrative matter or a temporary tightening of criteria. It is a paradigm shift in how evaluation bodies define what constitutes research and development in the current technological context.
What qualified as R&D until mid-2025
To understand this shift, it's helpful to first characterize the type of project that was well-received in the previous phase. The proposals that succeeded then shared several characteristics.
- They described the development of predictive models based on supervised and unsupervised machine learning techniques, presenting them as technological innovation per se. The mere mention of recurrent neural networks, LSTM models, Transformer architectures, or natural language processing served as an argument for novelty, without needing to demonstrate that the specific proposed combination surpassed a concrete state of the art.
- They built the state of the art on comparisons with commercial competitors, not on scientific literature. A proposal could dedicate five pages to explaining why the resulting product would be superior to those of specific companies in the market, and this was accepted as sufficient justification for its technical positioning.
- They incorporated product-oriented work plans: preliminary research, architecture design, model development, integration, pilot validation, and deployment. The structure was more typical of a software development process than an experimental research project, but this was rarely penalized.
- They justified significant budgets by including commercial software licenses, cloud services, third-party SaaS tools, and, in some cases, costs for using AI APIs. These costs were accepted as legitimate R&D infrastructure and were incorporated into the funding calculation bases without further questioning.
- And, above all, they presented the integration of commercially available AI capabilities as central technological innovation, assuming that their incorporation into a specific sectoral domain (finance, health, education, retail, logistics) constituted a defensible act of R&D in itself.
This type of project typically received positive evaluations, with technical assessments sufficient to meet the applicable thresholds for each instrument, especially when the commercial or impact section was well-structured.
Why it has changed: The maturity of LLMs as a disruptive phenomenon
The underlying cause of the change is not regulatory but technological. The emergence and consolidation of commercial large language models (GPT-4, Claude, Gemini, DeepSeek, Qwen, and their open-source equivalents) have massively shifted the frontier of what requires research.
Capabilities that until 2024 were cutting-edge research (multilingual semantic understanding, entity extraction in specialized text, contextual classification, sentiment analysis, coherent summary generation, image and video comprehension, audio transcription, specialized translation, reasoning over structured data) are now commodities accessible via API for a few cents per query. The implicit reasoning applied by the evaluator is straightforward: if the technical capability proposed for development is commercially available, there is no technical uncertainty to justify. There is no novelty to demonstrate. And therefore, there is no R&D in the strict sense. There is advanced integration, technological innovation, sophisticated commercial development. But not research.
This change is not exclusive to a single organization nor specific to the Spanish framework. It reflects a general transformation in how public innovation agencies, regional programs, European frameworks, and the administrative interpretation of the Frascati Manual itself are recalibrating what they consider fundable as R&D in applied AI projects.
The new evaluation logic: What an evaluator sees today
Today, evaluators have technical analysis capabilities they didn't possess two years ago. They can verify in minutes whether a technique described in a report is truly novel or a standard application. They can check if the proposed combination of algorithms appears in recent literature. They can request a state-of-the-art analysis on any technical sub-domain. What previously required scarce specific expertise is now trivially verifiable.
The result is that the appearance of technical sophistication no longer works as an argument. Listing impressive technologies no longer generates credibility. Paradoxically, it generates suspicion. When a report mentions deep learning, neural networks, Transformers, advanced NLP, scalable cloud architectures, and automated decision engines, the evaluator asks where the proprietary development is. If all of that is commercially available, what exactly is being researched?
There are three elements that the evaluator actively looks for to confirm whether a project is truly R&D or advanced integration.
- First, look at the budget. If there are line items for OpenAI, Anthropic, Gemini services, AI APIs in general, token costs, inference costs, licenses for commercial platforms that already solve the problem (scoring engines, identity verification tools, pre-built AI platforms), the project reveals itself as integration. The arithmetic is brutal: if the intelligent core of the product runs on external infrastructure and is paid for by consumption, proprietary technical capability is not being built.
- Second, look at the technical description. If the proposal explicitly names commercial AI providers as technology to be integrated, if it describes multi-vendor architectures to orchestrate various commercial LLMs, or if it presents the combined use of external services as an innovation, the project automatically falls outside the R&D framework.
- Third, look at the objective formulation. If the objectives are along the lines of "develop a system that...", "implement a platform for...", "integrate capabilities of...", the project is product-oriented. Valid R&D objectives are framed as hypotheses: "validate whether combination X surpasses benchmark Y published in the literature, achieving a value Z in metric W under conditions C".
How to tell if a project is in a risk zone
Before investing effort in drafting an R&D proposal, whether for a competitive call, direct aid, a European program, or any other public incentive instrument, it's advisable to apply an internal four-question filter. If the honest answer to three or more of these is affirmative, the project will not succeed as R&D in the current context, and the strategy should be re-evaluated.
Is the technical core of the project executed by calling commercial AI APIs? If the system operates by sending data to OpenAI, Anthropic, Google, or any similar provider and receiving the processed result, the technical value is not built internally. It's rented. This is, by definition, applied innovation, not research.
Are the listed "innovative technologies" techniques accessible with public documentation? If a competent developer can implement what's described by reading tutorials and official documentation, there's no technical frontier to cross. Random forest, gradient boosting, pre-trained BERT, Kubernetes, Apache Kafka, standard convolutional neural networks: all of this is engineering, not research, in 2026.
Does the budget include significant line items for commercial software that, by itself, solves the stated technical problem? When licenses for platforms that already do what the proposal presents as a challenge appear, the project contradicts itself. If the proposal suggests researching credit scoring and simultaneously budgets for licenses from commercial credit scoring bureaus, the evaluator will immediately spot the inconsistency.
Is the difference between the project's outcome and what a competitor could achieve by purchasing the same services operational, not technical? If the answer is yes, that the difference lies in go-to-market strategy, user experience, integration with business flows, or customer acquisition, the project is legitimate but falls into the category of applied innovation. Competitive differentiation based on product and market is not the same as technical differentiation based on research.
How to reorient a project to make it viable for R&D
Reorienting a project from "commercial AI integration" to "research with a proprietary technical core" is not always possible. Sometimes, a project is simply applied innovation, and it's best to present it as such, accepting that financial conditions will be less advantageous but realistic. However, when there's a genuine technical core hidden beneath layers of product description, there are concrete ways to bring it to light.
- Identify the domain constraint that invalidates the commercial solution. Many projects that appear to be commercial LLM integration actually have a technical reason why that integration doesn't work or isn't legally viable. Healthcare regulations that prevent sending clinical data to third-party servers. Real-time latency requirements that APIs cannot support. Specialized domains where general models systematically fail due to a lack of training in specific vocabulary or structures. When such a constraint exists, the correct approach is to develop proprietary technical capabilities precisely because commercial ones are inadequate, and that indeed constitutes R&D.
- Focus the project on the proprietary dataset, not on the techniques. If the company possesses unique data (due to years of operation, physical integrations, privileged access, customer type, or proprietary sensors), the project should articulate as its central hypothesis whether this data contains sufficient predictive signal and how to extract it using specific methodology. The techniques themselves might be standard, but the novelty lies in the dataset-methodology-result combination, which no competitor can replicate by simply purchasing APIs.
- Build the state of the art based on scientific literature, not on competitors. Viable R&D reports cite papers from IEEE, ACM, specialized journals, and recent preprints on arXiv. They are not built upon market analyses of competing companies. This seemingly formal discipline conveys to the evaluator that the team has positioned its proposal relative to the actual technical frontier, not the commercial landscape.
- Eliminate budget items that indicate integration. Commercial AI APIs, licenses for SaaS platforms that solve the problem, token and inference costs: all of these must be removed from the R&D-related budget. If they are essential for the final product, they are operational costs incurred after the project, not research costs. Keeping them in the budget is essentially handing the evaluator proof that the project is merely integration.
- Make genuine technical risk explicit. A viable R&D project contains credible risks that could lead to technical development failure. "It's possible that the proposed variables may not provide significant incremental predictive capability once controlled for traditional variables." "It's unclear whether the proposed architecture can maintain latencies below the required threshold under real load conditions." "Model generalization across subpopulations may not be valid and could require specific retraining." These risks convey that there is real uncertainty that the research aims to reduce.
- Consider cooperation with research centers. A formal collaboration with a university, public research organization, or technology center adds credibility to the project as authentic R&D, especially when it provides methodological capabilities that the company alone does not possess. This type of cooperation scores favorably in almost all public funding instruments.
When to accept that a project is innovation, not R&D
There's a point that needs to be honestly acknowledged: most business projects incorporating AI in 2026 are not R&D, and that doesn't diminish their value or legitimacy. Instruments designed for technological innovation and applied innovation exist precisely for projects that integrate mature technologies into production processes or commercial products with moderate technical risk, such as CDTI's LIC line.
Insisting on presenting as R&D what the system has already classified as applied innovation leads to wasted resources in drafting proposals that won't succeed, delays in obtaining funding because each cycle of rejection and resubmission adds months, and a deterioration of credibility with evaluating bodies when downward reclassifications accumulate.
The Forward Trend
The tightening of R&D criteria for AI projects is neither temporary nor reversible. Commercial models will continue to improve, meaning the boundary of "what counts as research" will keep shifting upwards. Capabilities that are still cutting-edge today (specialized fine-tuning, autonomous agents in complex domains, reasoning over multimodal data) will become commodities within eighteen to twenty-four months.
The sustainable strategy for companies relying on public funding for AI projects involves building non-replicable technical assets beyond API consumption. This fundamentally means unique data, deep domain knowledge translated into specific methodologies, physical integrations with hardware or sensors, presence in regulated sectors with restrictions preventing the use of commercial models, or the ability to perform computational science that goes beyond prompt engineering. Everything else, no matter how sophisticated the final result may seem, will increasingly be classified as technological innovation and less and less as R&D.
If you have doubts about whether your project qualifies as R&D or technological innovation, or if you want to evaluate how to reorient your proposal before submitting it to a call, we can review it with you. At Intelectium, we have 21 years of experience managing these types of projects and know firsthand how organizations are evaluating them today. Write to us at dealflow@intelectium.com
