¿Tengo que documentar cuánto tiempo un aparato recibe actualizaciones de software?

El soporte de software aún no es una obligación fija

Un plazo obligatorio para las actualizaciones de software aún no está establecido. El Reglamento marco ESPR (Reglamento (UE) 2024/1781) sí proporciona la base legal para hacerlo obligatorio por categoría de producto, pero el requisito real —cuánto tiempo debe un fabricante seguir suministrando actualizaciones, y si ese plazo debe figurar en el digital product passport— se establecerá únicamente en un acto delegado para el grupo de productos específico. Para la electrónica y los equipos TIC aún no existe tal acto. Hasta que lo haya, no existe una obligación general y exigible de establecer un plazo de actualización en el pasaporte, aunque la obsolescencia del software es precisamente el tipo de tema de sostenibilidad al que se dirige el ESPR.

Relevante para productos con software, no para todos

Este tema se aplica a dispositivos cuya funcionalidad depende del software: electrodomésticos inteligentes, equipos TIC, y electrónica más amplia con firmware o software de control. Para productos puramente mecánicos sin software, la cuestión simplemente no se plantea. También dentro del sector de la electrónica se aplica: el ESPR funciona con actos delegados por subcategoría, por lo que un requisito que se aplique a los smartphones no se aplica automáticamente a una lavadora o un router. El Reglamento marco en sí (artículos 5 a 7) enumera el tipo de requisitos que pueden establecerse —incluida la durabilidad, la fiabilidad y la aptitud para la reparación y la actualización— pero aún no los traduce en un número concreto de años para un producto concreto. Quien ahora busque un plazo fijo para un dispositivo específico no lo encontrará en ninguna parte del texto actual del ESPR.

Aún sin fecha: actos delegados por categoría

No hay una fecha fija para cuándo esto se aplicará a la electrónica y los equipos TIC. Según el Plan de trabajo ESPR 2025-2030, se elaborarán actos delegados por subcategoría, con la expectativa de que los primeros aparezcan a partir de 2027. Esto es una indicación del plan de trabajo, no un compromiso ni una ley. Hasta que se publique un acto delegado para un grupo de productos específico, ese grupo se rige por las disposiciones generales del ESPR (artículos 5 a 7 para los requisitos sustantivos, artículo 10 para lo que debe figurar en el digital product passport) sin que de ello se derive aún un plazo de actualización concreto. Tan pronto como se publique un acto delegado para equipos electrónicos o TIC, aquí figurarán la fecha y el contenido de ese requisito.

Lo que significa: orden de actuación

Quien desee prepararse para esto debe consultar primero su categoría de producto en el Plan de trabajo ESPR y, a partir de ahí, seguir la publicación del acto delegado correspondiente —ese es el momento en que quedará claro si, y durante cuánto tiempo, se exige un plazo de actualización y si debe figurar en el digital product passport. Hasta esa publicación no existe obligación legal de incluir esta información en un pasaporte, pero nada impide a un fabricante registrar internamente desde ahora cuánto tiempo se garantiza el soporte de software por línea de productos —esa es entonces una garantía propia y voluntaria, no una obligación del ESPR. Para quien encargue la elaboración de un digital product passport, esto significa en concreto: la estructura actual del pasaporte aún no necesita contener este campo, pero una vez que el acto delegado de la subcategoría correspondiente lo prescriba, ese campo se añadirá al pasaporte y se rellenará con los datos que el fabricante o importador suministre en ese momento. Quien desde ahora registre datos sobre soporte de software —qué modelos, qué plazos, qué políticas de actualización— tendrá una ventaja cuando el requisito se haga concreto, porque esos datos ya estarán disponibles para incluirlos en el pasaporte.

La base: artículos 5 a 7 y artículo 10

La posibilidad de establecer requisitos sobre soporte de software se deriva de los artículos 5 a 7 del ESPR (Reglamento (UE) 2024/1781), que constituyen el marco para el diseño ecológico: requisitos de rendimiento como durabilidad, fiabilidad e idoneidad para la actualización, y requisitos de información al respecto. Estos artículos nombran las categorías de requisitos que pueden desarrollarse más específicamente mediante actos delegados por grupo de productos, pero no fijan por sí mismos ningún plazo concreto de actualización. El artículo 10 del mismo reglamento regula lo que debe incluirse en el pasaporte digital del producto; aquí también se aplica que los campos de datos precisos se determinarán por categoría de producto, sobre la base de los requisitos que se hayan establecido para esa categoría. Mientras no se publique un acto delegado que mencione específicamente el soporte de software para electrónica e ICT, este tema sigue siendo una posibilidad dentro del reglamento marco, no una obligación concreta.

Quien ya está trabajando en esta cuestión ahora, lo mejor es que esté atento a la publicación del acto delegado para su propia categoría de producto y que, mientras tanto, ponga en orden sus propios datos sobre soporte de software, de modo que estén listos cuando el pasaporte lo solicite.

Fundamento de esto

El reglamento en sí se encuentra en EUR-Lex. Hacemos referencia a cada afirmación; no tiene que creernos.

Lo que debe hacer concretamente

Lo que se espera de usted

La compatibilidad de software puede convertirse en un requisito de diseño ecológico

La ESPR permite incluir en los actos delegados requisitos sobre la sostenibilidad de un producto, incluyendo dentro de estos aspectos relativos al software: cuánto tiempo un dispositivo recibe actualizaciones funcionales y de seguridad, y qué sucede con la funcionalidad del dispositivo una vez que cesa esa compatibilidad. Los artículos 5 a 7 de la ESPR (Reglamento (UE) 2024/1781) lo mencionan como parte de los requisitos de rendimiento e información que pueden establecerse por grupo de productos. Para equipos electrónicos e informáticos, este es uno de los temas considerados relevantes, dada la función del software en la vida útil de un dispositivo — una lavadora u ordenador portátil que funciona técnicamente pero deja de recibir actualizaciones a menudo se reemplaza de todas formas en la práctica. Para una empresa de 10 a 100 empleados, esto significa que el departamento responsable de la información del producto (frecuentemente el mismo que ya elabora períodos de garantía y manuales de usuario) debe comenzar a registrar un nuevo dato: el período durante el cual se suministran actualizaciones, por modelo de producto o por versión de software.

La información debe estar disponible en el pasaporte del producto

El artículo 10 de la ESPR (Reglamento (UE) 2024/1781) describe qué información debe incluirse en el pasaporte digital del producto una vez que un acto delegado lo establezca para un grupo de productos. Una vez que la duración de la compatibilidad del software se convierte en un requisito para equipos electrónicos, esa información no solo va a un manual o un sitio web, sino también al pasaporte en sí — estructurada y vinculada al código QR en el producto. Para una empresa de tamaño mediano, esto significa que el período de actualización no puede ser establecido de forma independiente por el departamento de software y comunicado por separado por marketing: esa información debe estar finalmente en el mismo conjunto de datos que, por ejemplo, el consumo energético y la puntuación de reparabilidad. Lo que exactamente debe incluirse en el pasaporte varía según el grupo de productos; en ¿qué datos aparecen en el pasaporte digital de productos electrónicos? se encuentra un resumen de las categorías de datos que contiene.

El período especificado debe coincidir con la realidad

Establecer una duración de compatibilidad es un paso; cumplirla es otro. Si un fabricante garantiza un período de actualizaciones en el pasaporte, se espera que ese período se cumpla efectivamente — y que los cambios (una cesación anterior de la actualización, una adquisición en la que se reduce el equipo de software) se incorporen. Esto toca la cuestión de con qué frecuencia deben mantenerse actuales los datos del pasaporte; véase ¿con qué frecuencia deben estar actuales los datos? para saber lo que se conoce al respecto. Para una empresa de este tamaño, esto suele significar que el compromiso sobre la duración de la actualización no solo lo realiza el gestor de productos, sino que se coordina con la parte que mantiene realmente el software — equipo interno o proveedor externo.

Dónde falla en la práctica

Una primera situación: un fabricante menciona un período de actualización en material de marketing ("cinco años de actualizaciones de seguridad"), pero este compromiso no consta en ningún documento interno con una fecha de inicio y fin. Una vez que esa información debe estar en el pasaporte, no hay una fuente inequívoca de la que extraerla.

Una segunda situación: el software de un dispositivo es suministrado por un proveedor (un fabricante de chips, un proveedor de plataforma), y el importador que compila el pasaporte del producto no sabe cuánto tiempo ese proveedor garantiza la compatibilidad. La responsabilidad de la precisión de los datos del pasaporte recae en la parte que ordena la compilación del pasaporte, incluso si la información subyacente procede de un tercero.

Una tercera situación: un dispositivo se vende en múltiples versiones (diferentes conjuntos de chips, diferentes versiones de software por región de mercado), pero el período de actualización se especifica para el número de modelo completo como una sola cifra. En una inspección posterior, resulta que algunas versiones reciben una compatibilidad más corta que otras.

Una cuarta situación: un aparato ya vendido deja de recibir actualizaciones más pronto de lo previsto debido a un cambio de estrategia, sin que este cambio se comunique a quien gestiona el pasaporte. Los datos del pasaporte siguen mostrando el período original, demasiado optimista.

Una quinta situación: una empresa asume que la "asistencia de software" se refiere únicamente a actualizaciones de seguridad, mientras que las actualizaciones funcionales (nuevas características, compatibilidad con nuevos accesorios) se tratan de forma separada — y la comunicación al cliente al respecto es inconsistente, sin claridad sobre cuál de las dos debe figurar en el pasaporte.

Lo que puede documentar

Un documento interno por modelo de producto con el período de asistencia que se promete para actualizaciones funcionales y actualizaciones de seguridad, cada uno con una fecha de inicio clara (por ejemplo, introducción en el mercado) y, si se conoce, fecha de fin.
Acuerdos con proveedores de software o proveedores de componentes sobre la duración mínima de asistencia que garantizan, incluido lo que ocurre en caso de adquisición, insolvencia o cese de una plataforma.
Un resumen de qué funcionalidad del aparato depende de actualizaciones de software, y qué ocurre con esa funcionalidad cuando cesa la asistencia (por ejemplo: el aparato sigue realizando funciones básicas, pero pierde la conexión con una aplicación).
Un proceso para comunicar cambios en la programación de actualizaciones (cese anticipado, extensión) al departamento que gestiona el pasaporte del producto, de modo que los datos no se queden atrás respecto a la realidad.
Distinción por variante o modelo de un producto, si la asistencia de software difiere según el chipset o la región de mercado.
Documentación de la fuente de la información: ¿es el período indicado un compromiso propio, o una garantía transmitida por un proveedor de componentes? Esto es relevante cuando alguien pregunta en qué se basa un dato del pasaporte — véase también He descubierto un error en el pasaporte del producto, ¿qué hago ahora? para saber cómo se pueden manejar datos incorrectos u obsoletos.

Cuando se publique el acto delegado para aparatos electrónicos e ICT, quedará claro qué datos exactamente son obligatorios y en qué forma. Hasta entonces, crear un dossier propio y verificable sobre períodos de actualizaciones es una forma de evitar tener que reconstruir posteriormente qué se prometió.

Esto no es asesoramiento jurídico. Esta página proporciona información general sobre la normativa de la que trata esta plataforma. No conocemos su situación. Si tiene dudas sobre su propio caso, consulte a un abogado o a la autoridad de vigilancia competente.

Escrito con IA basado en las fuentes anteriores, revisado por una persona el 2026-08-22. ¿Hay algo que no sea correcto? Háganoslo saber — las correcciones tienen prioridad.