Proyectos que antes superaban los umbrales evaluativos están siendo sistemáticamente reclasificados como innovación tecnológica. Qué busca hoy un evaluador, cómo detectar si tu proyecto está en zona de riesgo y cuándo aceptar que no es I+D.
Hasta la primera mitad de 2025, presentar un proyecto que incorporara inteligencia artificial, machine learning o procesamiento de lenguaje natural era prácticamente sinónimo de tener un argumento sólido para acceder a ayudas públicas a la I+D, tanto en convocatorias estatales como autonómicas o europeas. Las memorias que describían modelos predictivos, sistemas de scoring basados en aprendizaje automático, motores de recomendación personalizada o plataformas de análisis multimodal recibían valoraciones positivas con cierta regularidad. La tasa de calificación favorable en este tipo de proyectos era razonable, y el argumento de "estamos aplicando IA avanzada" funcionaba como anclaje técnico suficiente.
A partir del segundo semestre de 2025, y con plena consolidación durante el primer trimestre de 2026, este patrón ha cambiado de forma profunda. Proyectos sustancialmente similares a los que un año antes habrían sido calificados como I+D están siendo sistemáticamente reclasificados como innovación tecnológica. La transformación no es una cuestión administrativa ni un endurecimiento coyuntural de criterios. Es un cambio de paradigma en cómo los organismos evaluadores definen qué constituye investigación y desarrollo en el contexto tecnológico actual.
Qué se calificaba como I+D hasta mediados de 2025
Para entender el cambio, conviene caracterizar primero el tipo de proyecto que tenía buena recepción en la fase anterior. Las memorias que prosperaban entonces compartían varias características.
- Describían el desarrollo de modelos predictivos basados en técnicas de machine learning supervisado y no supervisado, presentándolos como innovación tecnológica per se. La sola mención de redes neuronales recurrentes, modelos LSTM, arquitecturas Transformer o procesamiento de lenguaje natural funcionaba como argumento de novedad, sin necesidad de demostrar que la combinación específica propuesta superase un estado del arte concreto.
- Construían el estado del arte sobre comparativas con competidores comerciales, no sobre literatura científica. Una memoria podía dedicar cinco páginas a explicar por qué el producto resultante sería superior al de empresas concretas del mercado, y eso se aceptaba como justificación suficiente del posicionamiento técnico.
- Incorporaban planes de trabajo orientados a producto: investigación previa, diseño de arquitectura, desarrollo de modelos, integración, validación con piloto y despliegue. La estructura era más propia de un proceso de desarrollo de software que de un proyecto de investigación experimental, pero esto rara vez se penalizaba.
- Justificaban presupuestos relevantes incluyendo licencias de software comercial, servicios cloud, herramientas SaaS de terceros y, en algunos casos, costes de uso de APIs de IA. Estos costes se asumían como infraestructura legítima de I+D y se incorporaban a las bases de cálculo de las ayudas sin mayor cuestionamiento.
- Y, sobre todo, presentaban como innovación tecnológica central la integración de capacidades de IA disponibles en el mercado, asumiendo que su incorporación a un dominio sectorial específico (finanzas, salud, educación, retail, logística) constituía por sí misma un acto de I+D defendible.
Este tipo de proyecto recibía habitualmente calificaciones positivas, con valoraciones técnicas suficientes para superar los umbrales aplicables en cada instrumento, especialmente cuando el bloque comercial o de impacto estaba bien construido.
Por qué ha cambiado: la madurez de los LLMs como fenómeno disruptivo
La causa subyacente del cambio no es regulatoria sino tecnológica. La irrupción y consolidación de los modelos de lenguaje grandes comerciales (GPT-4, Claude, Gemini, DeepSeek, Qwen y sus equivalentes de código abierto) ha desplazado masivamente la frontera de lo que requiere investigación.
Capacidades que hasta 2024 eran investigación de vanguardia (comprensión semántica multilingüe, extracción de entidades en texto especializado, clasificación contextual, análisis de sentimiento, generación de resúmenes coherentes, comprensión de imágenes y vídeo, transcripción de audio, traducción especializada, razonamiento sobre datos estructurados) son hoy commodities accesibles vía API por unos céntimos por consulta. El razonamiento implícito que aplica el evaluador es directo: si la capacidad técnica que se propone construir está disponible comercialmente, no hay incertidumbre técnica que justificar. No hay novedad que demostrar. Y por tanto no hay I+D en sentido estricto. Hay integración avanzada, hay innovación tecnológica, hay desarrollo comercial sofisticado. Pero no investigación.
Este cambio no es exclusivo de un único organismo ni propio del marco español. Refleja una transformación general en cómo las agencias públicas de innovación, los programas autonómicos, los marcos europeos y la propia interpretación administrativa del Manual de Frascati están recalibrando qué consideran financiable como I+D en proyectos de IA aplicada.
La nueva lógica de evaluación: qué ve hoy un evaluador
El evaluador dispone hoy de capacidades de análisis técnico que hace dos años no tenía. Puede contrastar en minutos si una técnica descrita en una memoria es realmente novedosa o aplicación estándar. Puede verificar si la combinación de algoritmos propuesta aparece en la literatura reciente. Puede pedir un análisis del estado del arte sobre cualquier subdominio técnico. Lo que antes requería expertise específico escaso es ahora trivialmente verificable.
El resultado es que la apariencia de sofisticación técnica ha dejado de funcionar como argumento. Listar tecnologías impresionantes ya no genera credibilidad. Genera, paradójicamente, sospecha. Cuando una memoria menciona deep learning, redes neuronales, Transformers, NLP avanzado, arquitecturas cloud escalables y motores de decisión automatizados, el evaluador se pregunta dónde está el desarrollo propio. Si todo eso está disponible comercialmente, ¿qué se está investigando exactamente?
Hay tres elementos que el evaluador busca activamente para confirmar si un proyecto es realmente I+D o integración avanzada.
- Primero, mira el presupuesto. Si aparecen partidas para servicios de OpenAI, Anthropic, Gemini, APIs de IA en general, costes de tokens, costes de inferencia, licencias de plataformas comerciales que ya resuelven el problema (motores de scoring, herramientas de verificación de identidad, plataformas de IA preconstruidas), el proyecto se delata a sí mismo como integración. La aritmética es brutal: si el corazón inteligente del producto se ejecuta en infraestructura ajena y se paga por consumo, no se está construyendo capacidad técnica propia.
- Segundo, mira la descripción técnica. Si la memoria nombra explícitamente proveedores de IA comerciales como tecnología a integrar, si describe arquitecturas multi-proveedor para orquestar varios LLMs comerciales, si plantea como innovación el uso combinado de servicios externos, el proyecto se sitúa automáticamente fuera del marco de I+D.
- Tercero, mira la formulación de objetivos. Si los objetivos son del tipo "desarrollar un sistema que...", "implementar una plataforma para...", "integrar capacidades de...", el proyecto es de producto. Los objetivos válidos como I+D tienen forma de hipótesis: "validar si la combinación X supera el benchmark Y publicado en la literatura, alcanzando un valor Z en la métrica W bajo las condiciones C".
Cómo detectar si un proyecto está en zona de riesgo
Antes de invertir esfuerzo en redactar una memoria de I+D, sea para una convocatoria competitiva, una ayuda directa, un programa europeo o cualquier otro instrumento de incentivación pública, conviene aplicar un filtro interno de cuatro preguntas. Si la respuesta honesta a tres o más de ellas es afirmativa, el proyecto no va a prosperar como I+D en el contexto actual y conviene replantear la estrategia.
¿El núcleo técnico del proyecto se ejecuta llamando a APIs de IA comerciales? Si el sistema funciona enviando datos a OpenAI, Anthropic, Google o cualquier proveedor similar y recibiendo el resultado procesado, el valor técnico no se construye internamente. Se alquila. Esto es definicionalmente innovación aplicada, no investigación.
¿Las "tecnologías innovadoras" que se listan son técnicas accesibles con documentación pública? Si un desarrollador competente puede implementar lo descrito leyendo tutoriales y documentación oficial, no hay frontera técnica que cruzar. Random forest, gradient boosting, BERT preentrenado, Kubernetes, Apache Kafka, redes neuronales convolucionales estándar: todo esto es ingeniería, no investigación, en 2026.
¿El presupuesto incluye partidas significativas de software comercial que resuelve por sí mismo el problema técnico planteado? Cuando aparecen licencias de plataformas que ya hacen lo que la memoria presenta como reto, el proyecto se contradice a sí mismo. Si la memoria propone investigar scoring crediticio y simultáneamente presupuesta licencias de bureaus de scoring comercial, el evaluador detecta la inconsistencia inmediatamente.
¿La diferencia entre el resultado del proyecto y lo que un competidor podría hacer comprando los mismos servicios es operativa, no técnica? Si la respuesta es que sí, que la diferencia está en el go-to-market, en la experiencia de usuario, en la integración con flujos de negocio o en la captación de clientes, el proyecto es legítimo pero pertenece a la categoría de innovación aplicada. La diferenciación competitiva basada en producto y mercado no es lo mismo que la diferenciación técnica basada en investigación.
Cómo reorientar un proyecto para que sea I+D viable
Reorientar un proyecto desde "integración de IA comercial" hacia "investigación con núcleo técnico propio" no siempre es posible. A veces el proyecto, simplemente, es de innovación aplicada y conviene presentarlo como tal, asumiendo que las condiciones financieras serán menos ventajosas pero realistas. Pero cuando hay un núcleo técnico genuino oculto bajo capas de descripción de producto, hay vías concretas para hacerlo aflorar.
- Identificar la restricción de dominio que invalida la solución comercial. Muchos proyectos que parecen integración de LLMs comerciales tienen, en realidad, una razón técnica por la que esa integración no funciona o no es legalmente viable. La regulación sanitaria que impide enviar datos clínicos a servidores de terceros. El requisito de latencia en tiempo real que las APIs no soportan. El dominio especializado donde los modelos generales fallan sistemáticamente por falta de entrenamiento en ese vocabulario o esas estructuras. Cuando esa restricción existe, la propuesta correcta es desarrollar capacidades técnicas propias precisamente porque las comerciales no sirven, y eso sí constituye I+D.
- Centrar el proyecto en el dataset propietario, no en las técnicas. Si la empresa dispone de datos únicos (por años de operación, por integraciones físicas, por acceso privilegiado, por tipo de cliente, por sensores propios), el proyecto debe articular como hipótesis central si esos datos contienen señal predictiva suficiente y cómo extraerla mediante metodología específica. Las técnicas pueden ser estándar, pero la novedad reside en la combinación dataset-metodología-resultado, que ningún competidor puede replicar comprando APIs.
- Construir el estado del arte sobre literatura científica, no sobre competidores. Las memorias de I+D viables citan papers de IEEE, ACM, journals especializados, preprints recientes en arXiv. No se construyen sobre análisis de mercado de empresas competidoras. Esta disciplina, aparentemente formal, transmite al evaluador que el equipo ha situado su propuesta respecto a la frontera técnica real, no respecto al panorama comercial.
- Eliminar las partidas presupuestarias que delatan integración. Las APIs de IA comerciales, las licencias de plataformas SaaS que resuelven el problema, los costes de tokens y de inferencia: todo esto debe salir del presupuesto vinculado a I+D. Si son imprescindibles para el producto final, son costes operativos posteriores al proyecto, no costes de investigación. Mantenerlos en el presupuesto es regalar al evaluador la prueba de que el proyecto es integración.
- Hacer explícito el riesgo técnico genuino. Un proyecto de I+D viable contiene riesgos creíbles que pueden hacer fracasar técnicamente el desarrollo. "Es posible que las variables propuestas no aporten capacidad predictiva incremental significativa una vez controladas por las variables tradicionales". "No está claro si la arquitectura propuesta puede mantener latencias por debajo del umbral requerido en condiciones de carga real". "La generalización del modelo entre subpoblaciones puede no ser válida y requerir reentrenamiento específico". Estos riesgos transmiten que hay incertidumbre real que la investigación pretende reducir.
- Considerar la cooperación con centros de investigación. Una colaboración formal con una universidad, organismo público de investigación o centro tecnológico añade credibilidad al proyecto como I+D auténtico, especialmente cuando aporta capacidad metodológica que la empresa por sí sola no tiene. Este tipo de cooperación puntúa favorablemente en prácticamente todos los instrumentos públicos.
Cuándo aceptar que el proyecto es innovación, no I+D
Hay un punto que conviene asumir con honestidad: la mayoría de los proyectos empresariales que incorporan IA en 2026 no son I+D, y eso no resta valor ni legitimidad. Los instrumentos diseñados para innovación tecnológica e innovación aplicada existen precisamente para proyectos que incorporan tecnologías maduras a procesos productivos o productos comerciales con riesgo técnico moderado, como por ejemplo la línea LIC de CDTI.
Insistir en presentar como I+D lo que el sistema ya ha decidido que es innovación aplicada produce desgaste de recursos en la redacción de memorias que no van a prosperar, retraso en la obtención de financiación, porque cada ciclo de rechazo y nueva presentación añade meses; y deterioro de la credibilidad ante organismos evaluadores cuando se acumulan reclasificaciones a la baja.
La tendencia hacia adelante
El endurecimiento del criterio de I+D en proyectos de IA no es coyuntural ni reversible. Los modelos comerciales seguirán mejorando, lo que significa que la frontera de "lo que cuenta como investigación" continuará desplazándose hacia arriba. Capacidades que hoy todavía son frontera (fine-tuning especializado, agentes autónomos en dominios complejos, razonamiento sobre datos multimodales) se convertirán en commodities en dieciocho a veinticuatro meses.
La estrategia sostenible para empresas que dependen de financiación pública en proyectos de IA pasa por construir activos técnicos no replicables mediante consumo de APIs. Esto significa fundamentalmente datos únicos, conocimiento de dominio profundo que se traduce en metodología específica, integraciones físicas con hardware o sensores, presencia en sectores regulados con restricciones que impiden el uso de modelos comerciales, o capacidad de hacer ciencia computacional que vaya más allá del prompt engineering. Lo demás, por sofisticado que parezca el resultado final, va a ser cada vez más calificado como innovación tecnológica y cada vez menos como I+D.
Si tienes dudas sobre si tu proyecto encaja como I+D o innovación tecnológica, o quieres evaluar cómo reorientar la memoria antes de presentarte a una convocatoria, podemos revisarlo contigo. En Intelectium llevamos 21 años gestionando este tipo de proyectos y conocemos de primera mano cómo están evaluando los organismos hoy. Escríbenos a dealflow@intelectium.com
