Software embebido como I+D+i: cuándo encaja y cómo defenderlo técnicamente

El problema específico del software

El software es uno de los sectores más recalificados por Hacienda en inspecciones de deducciones I+D+i. La razón es estructural: la frontera entre “desarrollar software nuevo” y “resolver una incertidumbre tecnológica que el estado del arte público no resuelve” es difícil de trazar — y muchas empresas la cruzan sin justificación documental suficiente.

El software embebido — el que va incorporado en producto industrial, vehículo, equipo médico, sistema de automatización, dispositivo IoT o similar — añade una capa adicional de complejidad: el software interactúa con hardware específico, restricciones de tiempo real, requisitos de fiabilidad, eficiencia energética. Esto puede generar genuinas incertidumbres tecnológicas que califican como I+D, pero también puede ser adaptación o configuración que no califica.

Este recurso aborda los criterios de encaje, las evidencias necesarias y los errores típicos.

La frontera I+D / IT / no elegible

El art. 35 LIS distingue dos categorías de actividad elegible y deja fuera el resto:

I+D (art. 35.1) — 25 % base + 42 % excedente + 17 % personal + 8 % inmovilizado

Requiere novedad objetiva y resolución de incertidumbre tecnológica que el estado del arte público no resuelve.

Ejemplos en software embebido:

• Nuevo algoritmo de control para sistema mecatrónico con garantías de estabilidad formalmente demostrables, donde literatura previa no aporta solución
• Arquitectura de software de tiempo real con propiedades de latencia inéditas en el sector
• Modelo de fusión sensorial novedoso para entorno industrial específico, validado experimentalmente
• Algoritmo de aprendizaje automático en el edge con restricciones de cómputo y consumo no resueltas en el estado del arte

IT (art. 35.2) — 12 % base, sin adicionales

Supone mejora sustancial sobre solución existente, pero sin la novedad objetiva propia de I+D. La incertidumbre tecnológica está parcialmente resuelta — el riesgo es de implementación, integración o adaptación específica.

Ejemplos en software embebido:

• Implementación industrial de un protocolo de comunicación recientemente publicado
• Optimización de un algoritmo conocido para hardware específico con restricciones de recursos no triviales
• Integración avanzada de software comercial con sistema legacy mediante middleware específico
• Desarrollo de plataforma propia que combina componentes existentes en arquitectura novedosa con valor diferencial demostrable

No elegible

Tres categorías que se excluyen sistemáticamente:

• Adaptación o configuración del software para un cliente o un caso de uso específico, sin componente técnico inédito
• Mantenimiento, actualización rutinaria, refactoring sin objetivo de mejora sustancial
• Integración de librerías o componentes comerciales sin desarrollo técnico propietario significativo

El criterio del estado del arte público

La piedra angular de la defensa técnica es demostrar la diferencia frente al estado del arte público. Esto significa:

• Búsqueda bibliográfica documentada: papers, conferencias, productos comerciales, soluciones open source que existen en el dominio del proyecto
• Análisis comparativo explícito: qué hacen las soluciones existentes, qué no pueden hacer, qué problemas dejan abiertos
• Identificación de la incertidumbre técnica concreta que el proyecto aborda y que el estado del arte no resuelve
• Resultados experimentales propios que demuestran haber resuelto la incertidumbre

Sin este análisis comparativo, la defensa técnica frente a la entidad certificadora y frente a Hacienda es muy débil. La consultora que prepara el expediente debe construir esta sección con rigor — no copiar plantillas genéricas.

Evidencias clave en proyectos de software embebido

1. Control de versiones del código

Sistema (Git, SVN, similar) que documente:

• Quién hizo qué cambio y cuándo
• Vinculación de commits a hitos del proyecto y a desarrolladores
• Branches y tags asociados a fases o entregables específicos
• Historial completo desde inicio hasta cierre del proyecto

Para una entidad certificadora, el control de versiones es prueba primaria de la ejecución técnica real del proyecto. Sin él, la defensa se debilita significativamente.

2. ADRs (Architecture Decision Records)

Documentos breves y estructurados que registran cada decisión arquitectónica significativa:

• Contexto del problema
• Alternativas consideradas
• Decisión tomada y razón
• Consecuencias previsibles

Los ADRs son particularmente valiosos en proyectos I+D porque documentan las incertidumbres que se evaluaron y resolvieron — exactamente lo que la entidad certificadora busca acreditar.

3. Benchmarks comparativos

Mediciones cuantitativas frente a:

• Soluciones comerciales del mercado (cuando son comparables)
• Implementaciones académicas publicadas (papers con código abierto)
• Proyectos open source relevantes
• Líneas base internas (versiones anteriores del propio software)

El benchmark debe medir métricas específicas y relevantes del dominio: latencia, throughput, consumo, error medio, robustez frente a ruido, escalabilidad, etc. Los benchmarks débiles (“nuestro código es más rápido”) sin metodología clara no convencen.

4. Tests automatizados

Reportes de:

• Unit tests con cobertura de código
• Integration tests entre componentes
• Hardware-in-the-loop tests cuando el software interactúa con hardware
• System tests de extremo a extremo en condiciones representativas

La cobertura y la sistematicidad de los tests son indicativos de la madurez del proceso de desarrollo — y su existencia es prácticamente inevitable en proyectos genuinamente de I+D donde la incertidumbre tecnológica exige validación experimental.

5. Actas de revisión técnica

Registros documentales de:

• Reuniones del comité técnico interno
• Revisiones de código (code reviews) con autoría y fecha
• Validación con cliente o proveedor en hitos clave
• Ensayos en banco de pruebas o demostradores

Las actas demuestran el gobierno técnico del proyecto y la trazabilidad temporal de las decisiones. Un proyecto sin actas — con todo el conocimiento “en la cabeza del desarrollador” — es más difícil de defender.

Errores típicos

Confundir desarrollo a medida con I+D

Construir software a medida para un cliente, integrando componentes existentes en una arquitectura adaptada al caso, no es I+D ni IT. Es desarrollo evolutivo. La confusión es frecuente porque el equipo ha invertido tiempo, recursos y conocimiento técnico en el proyecto — pero la inversión en sí no determina la calificación; lo determina la novedad objetiva o la mejora sustancial demostrable.

Memoria sin estado del arte

Memorias que describen lo que se hizo en el proyecto pero no contrastan con la literatura, las soluciones comerciales o los proyectos open source. Sin contraste, no hay forma de evaluar si la actividad es I+D, IT o desarrollo evolutivo.

Evidencias retroactivas

Proyectos donde la documentación se prepara cuando ya se ha decidido aplicar la deducción, en vez de durante la ejecución. La trazabilidad temporal se pierde y la evaluación detecta la inconsistencia.

Confundir agile con falta de documentación

Algunos equipos asumen que metodología ágil = poca documentación = exenta de evidencias para I+D+i. Es un error: los principios ágiles no son incompatibles con ADRs, control de versiones disciplinado, tests automatizados y actas de retrospectivas. La forma puede ser más ligera, pero el rigor documental sigue siendo necesario.

Aplicar 17 % personal sin acreditación de dedicación exclusiva

El adicional del 17 % sobre gastos de personal investigador requiere que el personal esté dedicado en exclusiva a actividades de I+D. En equipos pequeños donde un desarrollador trabaja en varios proyectos simultáneamente — algunos I+D, otros mantenimiento — la dedicación no es exclusiva y el adicional no aplica. Acreditarlo mal es un riesgo de regularización.

Particularidades por dominio

Automoción

El software embebido en automoción está sujeto a normativa específica (ISO 26262 para safety, AUTOSAR para arquitectura) y a procesos de homologación OEM. La defensa técnica encaja con el código UNESCO 3317 (Tecnología de Vehículos a Motor) más que con 1203 puro. Más detalle en I+D+i en automoción y tipologías.

IoT y sensores conectados

Proyectos donde el software embebido en dispositivo se integra con backend cloud, protocolos de comunicación (MQTT, LoRa, NB-IoT) y procesamiento en edge. Aquí los componentes I+D pueden estar tanto en el firmware del dispositivo como en la arquitectura cloud-edge. Más en Soporte IoT y software.

Industria 4.0 y automatización

Software de control industrial, SCADA, MES, integración con PLCs. Hay genuino I+D posible en algoritmos de control avanzado, optimización en línea, mantenimiento predictivo basado en datos de planta. La frontera con “configuración avanzada” es delicada y requiere análisis caso a caso.

Cuándo conviene IM en proyectos de software

Por la alta tasa de recalificación que sufre el sector, el IM tipo a) tiene un valor especialmente alto en proyectos de software embebido respecto a otros dominios.

La regla práctica:

• Deducción esperada > 30.000 € en software embebido: IM tipo a) es casi inevitable
• Deducción 10.000–30.000 € con documentación sólida: certificación UNE 166.001 sin IM puede tener sentido como nivel intermedio
• Deducción < 10.000 € en software puro: posiblemente la operación no compense por sí sola — ver ¿Cuándo compensa la deducción I+D+i?

Conclusión

El software embebido puede ser I+D, IT o no elegible bajo el art. 35 LIS según la naturaleza concreta del trabajo. La frontera con desarrollo evolutivo es delicada y el sector tiene una proporción especialmente alta de recalificaciones por Hacienda.

La defensa técnica pasa por documentar contraste con el estado del arte público, mantener trazabilidad rigurosa en el control de versiones, ADRs, benchmarks comparativos, tests automatizados y actas de revisión. Para proyectos de cierto volumen, el IM tipo a) tiene valor reforzado en este dominio respecto a otros.

Una sesión de evaluación inicial puede mapear si el proyecto encaja como I+D, como IT, o si conviene replantear el alcance — y qué documentación adicional es razonable preparar antes de avanzar al expediente formal.