Antes de firmar un contrato con un proveedor de DPP, hay ocho preguntas que debe hacerse. La mayoría de las marcas no las hacen hasta que es demasiado tarde. Cómo evitar la dependencia de un único proveedor de DPP: 8 preguntas que toda marca debe hacerse.
La convocatoria de ventas para una plataforma de pasaportes de productos digitales tiende a seguir un guion conocido. Alguien te muestra un panel de control. Hay un código QR. Los datos aparecen en la pantalla del teléfono. Parece limpio y fácil, y en algún momento, hacia el final, un gerente de cumplimiento pregunta por los plazos de la ESPR y un fundador pregunta por el precio.
Casi nadie pregunta: ¿qué pasa con mi pasaporte si cierras?
No es una pregunta injusta. El mercado de la DPP es joven, la regulación aún se está implementando y las empresas que crean infraestructuras de cumplimiento en la actualidad van desde plataformas bien capitalizadas hasta empresas emergentes de dos personas que funcionan con subvenciones. El riesgo de los proveedores es real. Y a diferencia de una suscripción de SaaS para la gestión de proyectos, un producto físico que puede estar en circulación durante diez, quince o veinte años va acompañado de un pasaporte digital de producto.
La buena noticia: la UE anticipó este problema. El Reglamento (UE) 2024/1781, el Reglamento sobre diseño ecológico para productos sostenibles (ESPR), se redactó teniendo en cuenta explícitamente la continuidad de los datos. La arquitectura que exige está diseñada para evitar el bloqueo. Sin embargo, las protecciones del reglamento solo funcionan si la plataforma que elija realmente las implementa.
Esto es lo que debe buscar.
Cada pasaporte digital de producto está anclado a un identificador de producto único, un código que conecta el producto físico con su registro digital. El origen de ese identificador es más importante de lo que la mayoría de las marcas creen.
La ESPR, y la metodología técnica del JRC que la sustenta, definen tres niveles de identificación que debe llevar cada DPP: un identificador único de producto (UPI) que vincula el artículo físico con su registro digital; un identificador único de operador (UOI) que identifica al operador económico responsable de comercializar el producto en el mercado de la UE; y un identificador único de instalación (UFI) que rastrea las ubicaciones físicas involucradas en la producción o el procesamiento al final de su vida útil. No se trata de SKU internos ni de códigos patentados; la normativa exige identificadores que se puedan descubrir, resolver y verificar en toda la cadena de suministro global. El Comité Técnico Conjunto CEN/CENELEC 24 del comité europeo de normalización está elaborando actualmente las normas que rigen su formato exacto.
Dentro de ese marco, los identificadores GS1 (GTIN para productos y GLN para operadores e instalaciones) son la implementación más implementada a nivel mundial. El GTIN está reconocido en 115 países, está integrado en la infraestructura aduanera, minorista y logística, y ya lo exigen los principales minoristas y organismos de vigilancia del mercado. El GS1 Digital Link, el estándar abierto que convierte un código QR en una URL estructurada y resoluble, es el mecanismo de resolución que utiliza Fluxy.One precisamente por este motivo: funciona en cualquier lugar, con cualquier resolución compatible y no está vinculado a una plataforma única.
El GTIN pertenece a la marca, no a la plataforma. Una empresa se registra directamente en GS1, a través de GS1 Belgilux, GS1 Germany, GS1 France o cualquier organización miembro nacional que opere en su mercado. Si la marca cambia de proveedor de DPP, el identificador viaja con ellos. El código QR del producto no cambia.
La primera pregunta que debe hacerse a cualquier proveedor de DPP es: ¿qué estándar de identificación implementa? ¿Puede resolverlo cualquier sistema compatible independientemente de su plataforma?
Según el artículo 9 del ESPR, el operador económico (el fabricante o importador que introduce el producto en el mercado de la UE) es legalmente responsable de la precisión e integridad del DPP. Esa responsabilidad no puede delegarse en una plataforma de software. Permanece en la marca.
Una plataforma DPP bien construida refleja esto en su arquitectura técnica. La marca controla el acceso por escrito a sus propios registros de pasaportes. El personal de la plataforma no debería tener la capacidad de modificar los datos de los clientes, no como un compromiso político, sino como una restricción técnica que se impone mediante controles de acceso basados en funciones, en los que todos los accesos se registran de forma inmutable.
La revocación merece una nota aparte. Revocar un DPP no significa eliminarlo. En el marco de la ESPR, la revocación escribe un hecho inmutable en el registro de cumplimiento, con una marca de tiempo, un motivo declarado y la identidad de la persona que actuó. El historial del pasaporte permanece intacto. Esto es importante para las autoridades de vigilancia del mercado, que necesitan poder reconstruir qué ocurrió y cuándo.
Pregúntele a cualquier proveedor: ¿la restricción del acceso de escritura es una política o se aplica a nivel de arquitectura? La respuesta dice mucho.
Una copia de seguridad no es lo mismo que un registro de trabajo. Esta distinción es más importante de lo que reconocen la mayoría de los debates sobre el DPP.
La retención significa que sus datos se almacenan en un lugar seguro. La continuidad significa que su pasaporte sigue siendo un registro activo, solucionable y actualizable, que puede recibir nuevos eventos del ciclo de vida, atribuciones de actores y transferencias de propiedad incluso después de que finalice la relación de plataforma original. El ESPR requiere el segundo. Una exportación obsoleta o una resolución defectuosa no logra localizar el pasaporte, independientemente de lo que contenga la copia de seguridad.
Lo que hace posible la continuidad entre los proveedores no es solo el mecanismo de respaldo. Es la combinación de tres elementos: un identificador que pueda redirigirse a cualquier dispositivo de resolución que cumpla con las normas; un registro de eventos en formato abierto que cualquier operador certificado pueda ingerir y seguir incorporando; y el registro central de la UE, obligatorio en virtud del artículo 13 de la ESPR para julio de 2026, que está diseñado para mantener el registro de referencia canónico y mantener la resolución independientemente de una sola plataforma.
Los derechos y obligaciones exactos (quién puede anexar a un registro, bajo qué autenticación y a través de qué límites de plataforma) se definirán en los actos delegados por categoría de producto. No se trata de una laguna en el marco actual; es la forma en que se diseñó el reglamento para que funcionara.
La mayoría de los proveedores de DPP alojan los datos ellos mismos. Está bien, es sensato desde el punto de vista operativo y la regulación no exige que las marcas se alojen por sí mismas. Lo que sí exige el reglamento es una red de seguridad.
El artículo 11 de la ESPR exige que un tercero independiente mantenga una copia de seguridad actualizada de cada DPP, separada de la plataforma principal. Este requisito se redactó específicamente para abordar la insolvencia. Si un proveedor de DPP cierra, el operador de respaldo conserva los datos y puede transferirlos a una nueva plataforma. El reglamento se diseñó para que su pasaporte no sea válido para el vendedor.
La Comisión Europea está finalizando actualmente el esquema de certificación para estos operadores de respaldo, por lo que la definición precisa de «independiente» y «certificado» aún está en desarrollo. Lo que ya existe en el reglamento es la obligación en sí misma: la copia de seguridad debe realizarse y debe ser realizada por una parte distinta.
Hay una segunda capa de protección que a menudo se pasa por alto. Según el artículo 13 del ESPR, la Comisión debe establecer un registro digital central antes del 19 de julio de 2026. Este registro contendrá el registro canónico de referencia de cada DPP, no una copia, sino un registro vivo y resoluble que persistirá independientemente de cualquier plataforma. Actualizaciones, atribución de actores, eventos del ciclo de vida: la arquitectura asume que estos eventos continúan en el registro incluso si finaliza la relación original con la plataforma.
Específicamente sobre la resolución: los identificadores basados en estándares abiertos se pueden reasignar a cualquier resolutor que cumpla con los requisitos. La migración del solucionador de un proveedor a otro es una operación técnica, no una pérdida de datos.
Escanear el código QR de un producto es un solo gesto. Lo que aparece en la pantalla depende completamente de quién esté escaneando.
El consumidor que compra una chaqueta ve la composición del material, las instrucciones de cuidado y la información sobre sostenibilidad. Un taller de reparación certificado ve los diagramas técnicos y las referencias de las piezas de repuesto. Una autoridad aduanera ve los certificados de cumplimiento y las declaraciones de conformidad. Un reciclador ve los datos sobre el contenido químico y las instrucciones de desmontaje. Una autoridad de vigilancia del mercado lo ve todo, incluido el registro de auditoría completo de cada cambio que se haya realizado en el pasaporte.
El mismo código QR. Cuatro puntos de vista completamente diferentes.
No se trata de una elección de diseño, sino de un requisito reglamentario. El artículo 10 de la ESPR exige el acceso por niveles: los diferentes actores ven diferentes capas del pasaporte en función de su función y nivel de autorización. Los actos delegados, que se publican categoría por categoría de productos, definirán exactamente qué actores pueden ver, introducir, modificar o actualizar qué campos de datos.
El reglamento ya establece un límite, independientemente de los actos delegados: los datos personales de los clientes no se pueden almacenar en el sistema DPP sin el consentimiento explícito. El pasaporte es un registro de producto. No es una base de datos de clientes y no puede convertirse en una.
Hasta que se establezcan los actos delegados para una categoría de producto determinada, la plataforma y la marca configuran los niveles de acceso de forma conjunta. Cualquier proveedor honesto le dirá que esta parte del marco aún se está desarrollando y le mostrará exactamente cómo migrará su arquitectura de acceso actual a los requisitos de los actos delegados cuando lleguen.
La pregunta que vale la pena hacerse es: ¿puede ver, ahora mismo, quién accedió a los datos de su pasaporte y cuándo? Un registro de acceso inmutable (que registre todas las vistas, el tipo de actor y a qué hora) no es una función opcional. Es la forma de demostrar a un regulador que su gobierno de datos funcionó.
Las marcas con formulaciones patentadas, acuerdos de abastecimiento de materiales o procesos de fabricación suelen preocuparse de que un DPP les obligue a publicar esa información públicamente. Esta preocupación es comprensible y, en la mayoría de los casos, está fuera de lugar.
El marco ESPR distingue entre los datos que deben ser de acceso público y los datos que están restringidos a los actores autorizados (reguladores, auditores, autoridades de vigilancia del mercado) en condiciones de confidencialidad. Una marca de cosméticos no necesita publicar su fórmula. Un fabricante textil no necesita divulgar su lista de proveedores a los consumidores. El reglamento exige transparencia en cuanto a los atributos de sostenibilidad, no la divulgación de secretos comerciales.
Los límites exactos se establecerán producto por producto en los actos delegados. En el caso de las categorías en las que los actos delegados aún no están en vigor, los niveles de acceso siguen siendo configurables. Una buena plataforma de DPP permite a la marca definir qué es público, qué está restringido a actores profesionales verificados y qué está disponible solo para las autoridades reguladoras.
La portabilidad no consiste solo en tener un botón de exportación. La cuestión es si los datos exportados pueden ser leídos por otro sistema sin la plataforma original en la sala.
La respuesta depende del formato. JSON-LD, estructurado según el vocabulario CIRPASS-2 —el marco de interoperabilidad abierto propio de la UE, desarrollado en colaboración con GS1— es el formato que puede utilizar cualquier operador de DPP certificado. Si los datos de su pasaporte se almacenan en un esquema propietario, técnicamente puede existir un archivo de exportación, pero prácticamente no se puede leer sin un trabajo de integración personalizado.
Más allá del formato de los datos, está la cuestión de las reglas de validación. CIRPASS-2 publica abiertamente los formatos SHACL (las definiciones formales de lo que debe contener un DPP que cumpla con las normas para una categoría de producto determinada) y se mantienen mediante el proceso de estandarización de la UE. Una plataforma de DPP que se base en estas formas abiertas no redacta las normas, sino que las implementa. Cuando las formas se actualizan para reflejar los nuevos actos delegados, la lógica de validación se actualiza. No es necesario mover los datos.
Ocho preguntas que vale la pena hacerle a cualquier proveedor de DPP antes de comprometerse:
¿Qué estándar de identificación implementa? ¿Puede resolverlo cualquier sistema compatible independientemente de su plataforma?
Técnicamente, ¿quién es el propietario del acceso por escrito a los registros de pasaportes? ¿Se aplica desde el punto de vista arquitectónico o mediante políticas?
¿Dónde se conserva la copia de seguridad obligatoria y qué operador independiente?
¿En qué formato se exportan los datos? ¿Puede demostrar que otra plataforma certificada puede incorporarlos sin necesidad de realizar trabajos personalizados?
¿Qué esquema de validación implementa la plataforma y cómo se actualizan esos esquemas cuando se publican nuevos actos delegados?
¿Puede mostrar el registro de eventos solo para adjuntar de un pasaporte de muestra y confirmar que no se puede modificar retroactivamente?
¿Puede mostrar el registro de acceso inmutable: todas las vistas, según el tipo de actor y a qué hora?
¿Cuál es su proceso de migración si decidimos mudarnos? ¿Cuánto tiempo lleva y a qué precio? Un proveedor que haya pensado seriamente en la interoperabilidad tendrá una respuesta específica, incluso antes de que lleguen los actos delegados.
Un proveedor con una infraestructura bien diseñada tendrá respuestas directas a las ocho. Vale la pena investigar las respuestas vagas sobre cualquiera de ellas.
La UE no diseñó el marco de DPP teniendo en cuenta la dependencia de los proveedores. Lo diseñó con la continuidad, la interoperabilidad y la responsabilidad como objetivos explícitos. Los estándares de identificación abiertos, la copia de seguridad obligatoria por parte de terceros, el registro central y los formularios de validación abiertos son opciones arquitectónicas incorporadas en el reglamento, no características opcionales.
Las marcas que afrontarán la transición a la DPP de manera más fluida son aquellas que tratan la selección de proveedores como una decisión de infraestructura, no como una compra de software. Las preguntas anteriores no son hostiles. Son las preguntas correctas para cualquier plataforma seria, y una plataforma seria las acogerá con satisfacción.
Si quiere entender cómo Fluxy.One aborda cada uno de ellos en la práctica, la conversación comienza aquí.
Fluxy.One: la infraestructura de transparencia para la economía global.
Reserve una demostración gratuita
Privacy is important to us, so you have the option of disabling certain types of storage that may not be necessary for the basic functioning of the website. Blocking categories may impact your experience on the website. More information
Privacy is important to us, so you have the option of disabling certain types of storage that may not be necessary for the basic functioning of the website. Blocking categories may impact your experience on the website. More information
.png)
