ISO/IEC JTC 5: preparar la arquitectura para la interoperabilidad de DPP

Por qué la arquitectura entra ahora en la agenda

El Pasaporte Digital de Producto se está introduciendo gradualmente en Europa mediante actos legislativos sectoriales. Para las empresas, esto puede generar fácilmente la impresión de que cada grupo de productos necesita su propio modelo de datos, su propio portador de datos y su propia lógica de integración. Precisamente en esta intersección comienza el trabajo de ISO/IEC JTC 5: el comité técnico conjunto se creó en 2026 y debe desarrollar las bases para la interoperabilidad de DPP entre sectores y sistemas. Su primera reunión anunciada tendrá lugar del 7 al 9 de septiembre de 2026 en Berlín. ISO/IEC JTC 5 describe expresamente su mandato como un marco para el sistema DPP y el ecosistema DPP; las normas específicas de cada sector siguen correspondiendo a los órganos técnicos competentes.

Esto no constituye una nueva obligación legal ni una norma ISO publicada. Sin embargo, es un motivo sólido para separar la arquitectura propia de los campos de datos a corto plazo. El primer punto de trabajo, ISO/AWI 25534-1, aún se encuentra en la fase de proyecto 10.99; el proyecto se aprobó el 12 de febrero de 2026. Según ISO, aborda términos, principios fundamentales, categorías de datos y mecanismos de gobernanza y confianza. La entrada pública del proyecto indica expresamente «under development». Quien deduzca de ello una obligación de certificación o un formato de intercambio terminado se está adelantando.

Qué separa el marco internacional de los requisitos de la UE

La UE ya establece directrices concretas. La Comisión explica que el DPP hace accesible la información relacionada con el producto en un modelo descentralizado: los datos completos permanecen en manos del operador económico o del proveedor de servicios DPP; el registro contiene identificadores únicos y datos de registro obligatorios. Un portador de datos, como un código QR, conecta el producto físico con su pasaporte. La página de la Comisión sobre DPP también menciona distintos accesos para los roles y calendarios sectoriales.

A ello se suman las normas europeas armonizadas. La Decisión de Ejecución (UE) 2026/1736, de 14 de julio de 2026 remite a seis normas DPP, entre otras, sobre identificadores, interoperabilidad, portadores de datos, API, intercambio de datos y almacenamiento de datos. Su función es concreta: para los requisitos que cubren, el cumplimiento puede respaldar la presunción de conformidad conforme a los artículos 10 y 11 del ESPR.

JTC 5 no sustituye estos niveles. Trabaja por encima de ellos: un marco neutral respecto del sector debe ayudar a explicar cómo se relacionan entre sí los términos, las categorías de datos, la confianza y la gobernanza entre sistemas. La consecuencia práctica es importante. Un fabricante no debería esperar a una futura edición ISO para proporcionar la información sobre sus baterías, textiles o acero. Pero sí debería evitar fijar los campos sectoriales actuales como núcleo inmutable de un modelo empresarial de DPP.

Tres decisiones de arquitectura que tienen sentido hoy

1. Separar la identidad estable de los perfiles técnicos

Un pasaporte necesita una identidad técnica duradera: producto, variante, lote o unidad individual; operador económico responsable; resolución mediante el portador de datos. La base jurídica determina después qué información técnica se requiere para ello. Esta información debe organizarse en perfiles versionados. Por eso, un módulo de batería para datos de CO₂ o del estado de salud no es un esquema base general. Del mismo modo, los datos sobre materiales, reparación o reciclaje no deben acabar únicamente como texto libre no estructurado en un pasaporte general.

En la práctica, esto significa que deben coexistir un ID central estable, un identificador de perfil documentado y una versión del perfil. Cada vista del pasaporte entregada debería permitir identificar qué perfil y qué versión determinan su contenido. Así, los equipos pueden incorporar un acto legislativo, una norma sectorial o, más adelante, una norma, sin reescribir datos históricos ni URL.

2. Modelar por separado el origen de los datos y el acceso

La interoperabilidad no es solo un formato JSON. Depende de que el receptor pueda evaluar el origen, la validez y el rol de una información. Por ello, almacene para cada elemento o paquete de datos, como mínimo, la fuente, el ámbito de aplicación, el momento de recopilación, la parte responsable y la versión técnica. Un valor interno de calidad es distinto de una declaración de conformidad jurídicamente vinculante; la información proporcionada por un proveedor es distinta de un valor medido.

La segunda parte es el acceso. La Comisión describe distintos accesos a la información para consumidores, empresas de reparación, recicladores y autoridades. Esto exige separar conscientemente la vista pública del pasaporte, el acceso técnico autorizado y el espacio de trabajo interno. Una URL no debe convertirse en una autorización. Los roles, los mandatos, las categorías de datos y las decisiones auditables deben verificarse en el servidor.

3. Probar los límites de intercambio como contratos

Un sistema DPP tiene varias transiciones: ERP o PLM proporcionan datos maestros, los proveedores aportan pruebas, un proveedor de servicios aloja los datos, un registro recibe metadatos y los usuarios externos consultan una vista pública o protegida. Para cada transición se necesita un contrato legible por máquinas: campos permitidos, identificadores, semántica, casos de error, versionado y compatibilidad con versiones anteriores.

Esto ya se puede probar. Entre los casos de prueba útiles se encuentran las versiones de perfil desconocidas, las pruebas caducadas, la falta de origen de los datos, los roles no autorizados, el registro duplicado y un portador de datos que apunta a un pasaporte que ya no está disponible. La prueba aún no demuestra la conformidad con una futura norma ISO. Pero sí crea la trazabilidad que faltará cuando llegue el cambio, si el modelo de datos y los derechos ya están mezclados de forma inseparable.

Un plan de trabajo de 90 días sin especulaciones

Durante los próximos 30 días conviene elaborar una fotografía del estado actual: qué identificadores de producto existen, qué perfiles de datos se utilizan realmente y qué datos solo están en documentos. Después debe tomarse una decisión de arquitectura: modelo central, registro de perfiles, modelo de origen y matriz de acceso. En un tercer paso, un producto real debería recorrer todas las transiciones, desde el sistema de origen hasta el pasaporte y el rol de la empresa de reparación o de la autoridad.

Los límites deben mantenerse claros. ISO/AWI 25534-1 no es una norma terminada; no existen cláusulas publicadas que los equipos puedan implementar. Tampoco el calendario de la Comisión es más que indicativo y no sustituye el examen del acto legislativo aplicable al grupo de productos correspondiente. Por eso, el valor de observar esta evolución no reside en marcar anticipadamente una casilla de una lista de cumplimiento, sino en contar con una arquitectura capaz de incorporar de forma ordenada nuevos perfiles, roles y reglas de intercambio.