El 29 de abril de 2026, la Comisión Europea publicó el proyecto de Reglamento de aplicación relativo al registro DPP y, al mismo tiempo, abrió un plazo de cuatro semanas para recibir comentarios. Hasta el 27 de mayo de 2026, cualquier persona u organización de la UE y de fuera de ella puede enviar sus comentarios a través del portal «Have Your Say». Las aportaciones son públicas, cada una de ellas va firmada con el nombre de la persona u organización, y se incorporarán oficialmente a la versión definitiva del reglamento.
Hemos analizado el borrador en detalle aquí, en el blog. Dedicamos esta entrada a explicar qué hemos respondido a la Comisión.
Por qué hemos presentado cuatro comentarios por separado
El portal admite 4 000 caracteres por comentario. Podríamos haber condensado todos los puntos en un único comentario extenso. Esto habría resultado más incómodo de leer y más difícil de citar para los empleados de la Comisión, que en mayo tendrán que revisar docenas de aportaciones. Cuatro aportaciones individuales se pueden localizar por separado en la lista pública, y cada una de ellas puede responderse - o rechazarse - de forma aislada, sin que ello afecte a los demás puntos.
Hemos presentado los cuatro temas siguientes:
1. Definir los requisitos mínimos para los proveedores de servicios DPP
El proyecto de reglamento establece correctamente el modelo descentralizado: Los datos del DPP se almacenan en las instalaciones del agente económico o de su proveedor de servicios del DPP; el registro de la Comisión solo almacena las referencias. Para los proveedores de servicios del DPP (art. 2, n.º 32 del ESPR) se prevé una lista oficial de proveedores autorizados.
Lo que falta es una definición de lo que un proveedor de servicios debe cumplir realmente para entrar en dicha lista y permanecer en ella. Es de suponer que las obligaciones sustanciales se establecerán en un acto delegado con arreglo al artículo 4 del Reglamento general del RGPD. Sin embargo, el registro entrará en funcionamiento antes de que se publique dicho acto.
Nuestra propuesta: o bien establecer directamente en este Reglamento de aplicación los criterios mínimos para los proveedores de servicios, o bien fijar un plazo vinculante para la presentación del acto delegado. Entre los requisitos mínimos propuestos se incluyen:
- Disponibilidad de la interfaz pública de lectura del DPP de al menos el 99,5 % al mes
- Un acuerdo de nivel de servicio que establezca la rapidez con la que debe llegar una nueva versión del DPP a la copia de seguridad (propuesta: 24 horas o en tiempo real, cuando sea técnicamente posible)
- Verificación criptográfica obligatoria de las versiones recibidas por parte del proveedor de servicios
- Publicación de las claves públicas del agente económico en una ruta estandarizada (RFC 8615, propuesta
/.well-known/dpp-keys/) - Proceso definido de cambio de proveedor e insolvencia, para que los datos del DPP se migren de forma ordenada a otro proveedor en caso de que uno de ellos deje de prestar servicio
Estas obligaciones no suponen ningún coste para un proveedor serio - que, de todos modos, ya las cumple - , pero evitan una «carrera a la baja» entre proveedores de bajo coste que, a la larga, acabaría socavando la lista.
2. Verificabilidad a largo plazo de los DPP registrados
El artículo 9, apartado 4, limita la disponibilidad del certificado de registro a 90 días naturales. Dentro de este plazo, el registro vuelve a generar el certificado previa solicitud. Esto está bien para el funcionamiento diario, pero no se ajusta al ciclo de vida de la obligación de los DPP subyacente: el artículo 10, apartado 3, establece un plazo de conservación estándar de 10 años a partir del registro, aunque la legislación sectorial puede exigir un plazo más largo.
Una autoridad de vigilancia del mercado, un funcionario de aduanas, una empresa de reciclaje o un investigador en el año 2032 debería poder comprobar que un DPP registrado en 2026 estaba realmente registrado, sin tener que depender de que el agente económico original siga existiendo y pueda solicitar un certificado nuevo.
Nuestras dos propuestas son fáciles de aplicar:
- Aclarar explícitamente que los bytes de prueba sellados de forma cualificada por la Comisión pueden ser almacenados temporalmente, archivados y redistribuidos por el agente económico o por el proveedor de servicios. El sello cualificado, según el artículo 35, apartado 2, del Reglamento eIDAS, conlleva la presunción de integridad y origen, independientemente de dónde se encuentren los bytes.
- Establecer un punto final de verificación público y no autenticado en el registro, que proporcione una respuesta firmada asociada a un identificador de registro. En la actualidad, cualquier verificación por parte de terceros requiere que el agente económico actúe de forma activa; esta no es la forma adecuada para un documento probatorio que debe sobrevivir al emisor.
Además, hemos propuesto establecer de forma determinista la generación del hash: SHA-256 como función hash, Esquema de canonización JSON (RFC 8785) como serialización, fuera del bloque de firma. En el ecosistema del W3C, esta familia se denomina «eddsa-jcs-2022»; Transpareo fija la variante estrechamente relacionada «eddsa-jcs-sha256» (SHA-256 a través de JCS). Sin esta especificación de fijación, dos proveedores de servicios serializarían el mismo DPP con hash diferentes, y el campo de hash en el certificado de registro no sería reproducible.
3. El artículo 17 no debe restringir el acceso a los datos públicos del DPP
El artículo 17 menciona la «descarga masiva de datos» como un posible uso indebido del registro. En el caso de los metadatos administrativos que se encuentran en el propio registro (identidades, registros, rastros de auditoría), esto es correcto: no deben ser objeto de descargas masivas.
Sin embargo, los datos públicos del DPP que obran en poder del fabricante o del proveedor de servicios son precisamente el ámbito al que el ESPR pretende dar un amplio acceso. Las empresas de reciclaje que recopilan datos sobre la composición de flotas de productos; la investigación que evalúa de forma transversal las declaraciones de sostenibilidad; la vigilancia del mercado, que realiza análisis comparativos: todas ellas son formas de «descarga masiva de datos» de la capa pública de DPP y todos son usos previstos para los que se redactó el Reglamento.
Nuestra propuesta es incluir una frase aclaratoria en el artículo 17 que limite el ámbito de aplicación a los datos de los registros y remita, en el caso de los datos DPP, a los actos delegados específicos de cada sector. De lo contrario, los proveedores de servicios se enfrentarán a una disyuntiva al inicio: o bien limitar de forma estricta el acceso público por motivos de seguridad - y arruinar así la experiencia del consumidor - , o bien dejarlo abierto y arriesgarse a que más adelante se clasifique como uso indebido en el sentido del artículo 17.
4. Publicar la especificación OpenAPI y el entorno de pruebas antes del lanzamiento
El artículo 3, letra b), exige una API para los registros. El artículo 8, apartado 5, la convierte en uno de los dos canales para el registro. Sin embargo, el Reglamento no dice nada sobre cuándo debe publicarse el contrato de la API.
Quien automatice los flujos de trabajo de registro - cualquier proveedor de servicios y cualquier agente económico con un catálogo extenso - necesita la especificación de la API con suficiente antelación al lanzamiento para poder implementarla y probarla con un punto final real. Encontrar una especificación en la semana previa a la entrada en vigor traslada el riesgo de integración a todos los proveedores del ecosistema.
Por ello, hemos propuesto lo siguiente:
- Publicar una especificación OpenAPI 3.1 al menos ocho semanas antes de la entrada en vigor; es decir, para una entrada en vigor el 19 de julio de 2026, a más tardar el 24 de mayo de 2026
- Un entorno de pruebas paralelo en el que los proveedores de servicios y los fabricantes puedan integrar sus sistemas y probar la autoverificación prevista en el artículo 8, apartado 6
- Una política de versionado con Semver y un plazo de preaviso de al menos 18 meses
Sugerencias de diseño adicionales: claves idempotentes en las llamadas de registro, registro por lotes para catálogos de gran tamaño, registro asíncrono con callback de webhook y códigos de error legibles por máquina para los casos de error en la verificación automática.
Por qué lo hacemos
Una consulta no es un juego para acumular puntos. Si cada aportación consigue que una sola frase de la versión final sea más precisa, habrá cumplido su propósito. La Comisión lee realmente estas aportaciones; la propia experiencia del proceso ESPR demuestra que las aportaciones con fundamento técnico suelen dejar huella en los textos finales.
De todos modos, solicitaremos nuestra inclusión en la lista de proveedores de servicios DPP tan pronto como se publique el procedimiento de admisión. Por lo tanto, nos interesa directamente que las normas bajo las que competimos sean precisas y definan unas condiciones equitativas. Las cuatro aportaciones son nuestra forma concreta de garantizar que la lista no se convierta en una mera etiqueta de marketing.
Quién puede participar
El plazo para enviar comentarios finaliza el 27 de mayo de 2026. Las aportaciones pueden realizarse en cualquiera de las lenguas oficiales de la UE, requieren registrarse en el portal y serán visibles públicamente. Quienes vayan a emitir o verificar los DPP - fabricantes, proveedores de servicios, empresas de reciclaje, autoridades - deberían informarse al menos una vez sobre la iniciativa en Have Your Say. Incluso una aportación breve y técnicamente precisa es útil.
Nuestra herramienta de verificación Transpareo Time Machine resuelve, por cierto, la necesidad de verificación esbozada en el punto 2 ya en la práctica de código abierto: quien desee verificar de forma independiente un DPP de Transpareo, puede hacerlo hoy mismo con esta herramienta, sin tener que esperar a que se establezca formalmente un punto de verificación en el registro de la Comisión.