La UE ya ha construido una arquitectura de referencia para el pasaporte

Mientras las empresas esperan los actos delegados, un trabajo financiado por la UE ha construido y probado cómo debería ser un sistema de pasaporte digital de producto (DPP). CIRPASS-2 publicó una arquitectura de referencia, versión 1.1, en junio de 2026, y los pilotos corren sobre las mismas categorías que afrontan primero reglas vinculantes: textil, electrónica, construcción y neumáticos.

Merece la pena conocerlo aunque nada de esto sea ley.

Qué es, y qué no es, una arquitectura de referencia

Es una descripción de los bloques de construcción que necesita un sistema de pasaporte, de los papeles que juegan los distintos actores, y de un conjunto de recomendaciones sobre cómo deberían interactuar. Los pone en relación con los requisitos del ESPR.

No es vinculante. Nada en ella obliga a nadie, y un sistema que se aparte de ella no es no conforme.

Lo que sí es, en la práctica, es la declaración pública más detallada de cómo se ve lo «bien hecho» desde la parte del ecosistema que influirá en las normas. Cuando llegue el momento de juzgar la interoperabilidad, se juzgará con ese vocabulario.

Por qué importa comercialmente más que técnicamente

El riesgo que los consejos de administración no ven con los pasaportes no es suspender un control. Es elegir un sistema incapaz de intercambiar datos con los sistemas que eligen tus clientes y tus proveedores.

Un pasaporte que solo responde dentro de la plataforma de un proveedor funciona bien hasta que el sistema de compras de un cliente quiere leerlo automáticamente, un marketplace quiere mostrarlo, o un reciclador quiere consultarlo una década después. En ese punto un sistema cerrado deja de ser una decisión de producto y pasa a ser algo que tu cadena de suministro tiene que sortear.

La arquitectura de referencia existe precisamente para evitar ese desenlace, y por eso alinearse con ella es una cobertura más que un ejercicio de cumplimiento.

Qué preguntar a un proveedor sobre esto

Tres preguntas que no te obligan a leer un documento de 97 páginas.

¿Conocéis la arquitectura de referencia CIRPASS-2, y en qué os apartáis de ella? La respuesta útil nombra una desviación y la explica. Un proveedor que declara alineamiento total con un documento que todavía es una recomendación en borrador está exagerando.

¿Qué categorías piloto habéis mirado? Los pilotos son públicos y sacan a la luz problemas reales de integración, en particular sobre el intercambio de datos con proveedores.

¿Cómo gestionáis las actualizaciones enviadas por terceros? Proveedores y reparadores metiendo datos en el pasaporte de otro es donde la arquitectura se vuelve concreta, y donde más divergen las implementaciones.

La laguna que conviene señalar

Una observación sobre el alcance de la arquitectura más que una crítica: no hay bloque de construcción para la verificación de autenticidad orientada al consumidor, y la falsificación no se trata como caso de uso. El escaneo se modela como una forma de llegar a datos, no como una forma de comprobar que un producto es auténtico.

Esa laguna es donde se sitúa nuestra propia app de consumidor, y es la razón por la que tratamos autenticidad y pasaporte como un solo código en lugar de dos sistemas. Es una observación sobre qué cubre el modelo de referencia, no la prueba de que nadie más lo aborde.

Fuentes

• CIRPASS-2, *D4.1 Reference Architecture*, versión 1.1, 9 de junio de 2026, incluidos los bloques de
• construcción del proveedor de servicios DPP y las recomendaciones de arquitectura.