technology

Requisitos para proveedores DPP: normas UE para plataformas

Qué significa el proceso de acto delegado de la UE para las plataformas DPP: gobernanza, portabilidad, respaldo, control de acceso y certificación.

29/3/2026 · 12 min de lectura · InfoDPP

Actualización editorial, 22 de julio de 2026: el Registro en producción, el entorno de pruebas, el acceso a la API y los primeros recursos de aplicación ya están disponibles, pero la guía publicada solo abarca a los operadores económicos. No ofrece una vía de integración para proveedores de servicios, un proceso de certificación ni una lista pública de certificación. El Reglamento (UE) 2026/1778 exige que el Registro incluya una lista de proveedores de servicios DPP verificados, pero se trata de la verificación de identidad y acceso a las funciones del Registro, no de certificación, acreditación ni transferencia de responsabilidad conforme al Derecho de productos.

Por qué la capa de proveedores es importante

Muchas empresas siguen pensando en el Pasaporte Digital de Productos a nivel visible: datos de producto, códigos QR, páginas para el consumidor y declaraciones de conformidad.

Pero para la UE, eso es solo una parte. También existe una capa de infraestructura: los sistemas y proveedores que almacenan, gestionan, exponen, respaldan y gobiernan los registros DPP a lo largo del tiempo.

Por eso la Comisión Europea prepara un acto delegado específicamente dirigido a los proveedores de servicios DPP.

Para las plataformas de software, esto tiene implicaciones directas. Los proveedores DPP podrían convertirse en algo más que proveedores SaaS convencionales: podrían ser actores regulados o parcialmente regulados del ecosistema DPP, de los que se espera portabilidad, gobernanza, continuidad y acceso fiable a los datos de producto.

Qué quiere regular la Comisión

La iniciativa sobre proveedores DPP indica que la Comisión busca retroalimentación sobre cómo deben almacenar y gestionar los datos los proveedores y sobre la necesidad de un sistema de certificación.

Las preguntas reales son arquitectónicas:

¿quién controla los datos?
¿cómo se almacenan?
¿quién tiene acceso?
¿cómo se mantiene la disponibilidad a lo largo del tiempo?
¿necesitan los proveedores cualificación o certificación formal?

El acto definitivo aún no se ha adoptado, pero las cuestiones de gobernanza ya están claramente definidas.

El marco jurídico es más estrecho que el debate político

El artículo 11, apartado 2, del ESPR faculta expresamente a la Comisión para fijar tres aspectos en el acto delegado:

los requisitos que deben cumplir las entidades para convertirse en proveedores de servicios DPP;
cuando proceda, un sistema de certificación para verificar el cumplimiento de esos requisitos de acceso; y
los requisitos que deben cumplir al prestar servicios DPP.

Este es el único alcance que puede describirse con seguridad como garantizado. El considerando 40 aporta una pista no operativa pero relevante: prevé aclarar las funciones y responsabilidades de los organismos emisores y proveedores en la creación, autenticación, tratamiento y almacenamiento de datos DPP y, posiblemente, en la retirada de elementos importantes del DPP, como identificadores y soportes de datos. No impone por sí mismo esas obligaciones detalladas ni garantiza que todas aparezcan en el acto final.

No se han publicado los criterios exactos de elegibilidad, las obligaciones de servicio ni la mecánica de una eventual certificación. La portabilidad, la continuidad, la ciberseguridad, la interoperabilidad y la separación de funciones son temas de aplicación bien fundamentados, pero el expediente de consulta refleja opciones de política pública, no la norma definitiva.

El ESPR ya establece parte de la base: un DPP puede ser almacenado por el operador económico o por un proveedor; el diseño debe ofrecer un alto nivel de seguridad y privacidad; el proveedor no puede vender, reutilizar ni tratar los datos DPP más allá de lo necesario para el servicio salvo acuerdo específico con el operador económico; y el artículo 10, apartado 4, exige una copia de seguridad a través de un proveedor de servicios DPP. El considerando 38 describe a ese proveedor de respaldo como un tercero independiente. El acto delegado deberá hacer más operativa la gobernanza de los proveedores, no inventar estas obligaciones desde cero.

El portal DPP más reciente de la Comisión sitúa el acto sobre proveedores en 2027, pero actualmente lo enumera dos veces, una en el segundo y otra en el tercer trimestre. Hasta que la Comisión resuelva esta incoherencia o publique el proyecto, el año es una señal útil para planificar, pero el trimestre no.

Qué añade ahora el Reglamento del Registro

El Reglamento del Registro adoptado no resuelve el futuro régimen de proveedores, pero elimina una ambigüedad importante.

El Registro contendrá una lista de proveedores de servicios DPP verificados. No debe describirse como una lista de certificación de la UE: la verificación se refiere al acceso a funciones del Registro, no a que el proveedor cumpla todos los futuros requisitos operativos.
Un proveedor elegible que actúe en la cadena de valor debe estar verificado para crear o modificar registros. El Registro también comprueba la referencia al proveedor de respaldo cuando sea pertinente para un registro.
El Reglamento crea un repositorio semántico legible por máquina, con API documentadas y formatos comunes. Esto favorece la interoperabilidad, mientras que las normas definitivas de gobernanza específicas para los proveedores quedan reservadas al acto delegado independiente.
El operador económico sigue siendo responsable de la exactitud de los datos DPP y de registro. Una plataforma verificada puede realizar el trabajo técnico sin asumir esa responsabilidad jurídica.

Esta distinción importa en la contratación: pregunte si el proveedor admite verificación, control de versiones, interoperabilidad semántica y exportación, pero no acepte la afirmación «proveedor DPP certificado por la UE» hasta que un futuro sistema legal de certificación la respalde realmente.

Qué es ya visible del proceso actual

1. El rol del proveedor se separa del rol del propietario del producto

Los fabricantes, importadores y otros operadores económicos siguen siendo responsables de la conformidad del producto. El rol del proveedor de servicios es distinto: concierne la infraestructura que permite que los registros DPP funcionen en la práctica.

Esa distinción importa porque sugiere que la UE quiere fronteras más claras entre:

la responsabilidad de conformidad
la propiedad de los datos
la operación técnica
la continuidad a largo plazo de los registros

Nota sobre el pasaporte de baterías: el Reglamento de baterías utiliza una figura distinta de la futura función de proveedor DPP a efectos del ESPR. La Comisión confirmó en mayo de 2026 que se refiere a operadores autorizados que actúan en nombre del operador económico responsable, por lo que esa denominación no debe trasladarse automáticamente a cada modelo de plataforma. En la práctica, el operador económico responsable sigue siendo responsable del pasaporte de baterías. Un operador autorizado puede prestar apoyo técnico u organizativo en su nombre, pero no asume esa responsabilidad ni equivale a un futuro proveedor DPP a efectos del ESPR.

2. La gobernanza se convierte en un requisito de primer orden

La iniciativa no pregunta si las plataformas deben ocuparse de la gobernanza. Asume que importa y pregunta qué modelo aplicar.

3. La portabilidad emerge como expectativa de diseño central

El registro de consulta sugiere con fuerza que los sistemas DPP no deben diseñarse en torno a una dependencia permanente de un solo proveedor.

4. Respaldo y continuidad no son cuestiones secundarias

La disponibilidad a largo plazo de los datos DPP es central en el debate. Las plataformas enfocadas solo en la presentación activa podrían no cumplir si la continuidad del respaldo se formaliza más.

Cuatro ámbitos de diseño para los que las plataformas deben prepararse

Incluso antes de que el acto delegado sea definitivo, ya se percibe un modelo útil de preparación.

1. Propiedad clara de datos y límites de gobernanza

La arquitectura más fácil de justificar es aquella en la que el operador económico conserva el control de los datos de producto y el proveedor aporta la capa de servicio técnico.

Una plataforma seria debe poder explicar:

a quién pertenecen los datos
quién puede editarlos
cómo se rastrean los cambios
cómo se exportan los registros
qué ocurre al terminar la relación de servicio

Si una plataforma no puede explicarlo con claridad, ya es débil desde una perspectiva de gobernanza.

2. Interoperabilidad y protección contra el bloqueo

Este es el punto de consenso más fuerte del registro de la consulta.

Para las plataformas, la interoperabilidad debe dar forma al modelo subyacente:

los identificadores deben seguir siendo transferibles
los registros deben ser exportables en formato estructurado utilizable
los sistemas deben evitar dependencias propietarias que dificulten la migración
cambiar de proveedor no debe obligar a reconstruir la base de datos de producto desde cero

Un diseño transferible es la opción preparatoria de menor riesgo, pero las obligaciones exactas al cambiar de proveedor quedan pendientes del acto delegado.

3. Lógica de respaldo y planificación de continuidad

El debate sobre proveedores DPP vuelve una y otra vez a las copias de respaldo, la continuidad y la pregunta de qué ocurre si desaparece el operador o proveedor original.

Las plataformas ya deben pensar en términos de:

alojamiento activo vs. servicio de solo respaldo
lógica de instantánea o copia de continuidad
condiciones de liberación de datos
conservación trazable del último registro de producto válido

No se conocen todos los detalles finales, pero la exigencia de pensar seriamente en la continuidad ya existe.

4. Control de acceso y gestión de datos restringidos

El DPP no es solo una página pública para consumidores.

Muchos registros DPP contendrán capas de datos con diferentes derechos de acceso:

información pública para consumidores
datos B2B restringidos
capas de acceso para autoridades
auditabilidad de accesos y modificaciones

Esta es una de las señales más claras de que las plataformas DPP están más cerca de una infraestructura regulada que de herramientas convencionales de gestión de contenidos.

Certificación: qué se sabe y qué no

La certificación es una de las mayores cuestiones abiertas en el debate sobre proveedores.

Lo que ya se sabe

La Comisión ha preguntado explícitamente si se necesita un sistema de certificación
Algunos actores apoyan firmemente una certificación independiente ex ante
Otros prefieren modelos más flexibles
La madurez en seguridad y gobernanza ya es una expectativa visible

Lo que aún no se sabe

Si la certificación será obligatoria para todos los proveedores
Qué organismo evaluaría a los proveedores
Si el modelo final distinguirá entre diferentes roles de proveedor
Cuán gravoso puede ser el proceso para empresas de software más pequeñas

Conclusión práctica: construya como si pudiera necesitar demostrar gobernanza estructurada, auditabilidad, fiabilidad y madurez en seguridad.

Por qué la arquitectura descentralizada sigue apareciendo

Las partes interesadas quieren evitar un modelo en el que un proveedor se convierta en el propietario inevitable y opaco de los datos de producto de una empresa.

Esto no significa que cada DPP deba autohospedarse o distribuirse plenamente en sentido técnico.

Para las plataformas, esto sugiere:

el cliente posee los datos de producto
el proveedor opera la capa de servicio
las exportaciones y la portabilidad son la norma
la continuidad del respaldo no implica dominio del proveedor

Esto se alinea bien con la preferencia más amplia de la UE por estándares abiertos e infraestructura digital interoperable.

Qué deberían construir las plataformas en 2026

Los pasos de preparación más útiles son aquellos que siguen siendo valiosos bajo múltiples escenarios legales finales posibles.

1. Exportaciones estructuradas

Si un cliente se marcha o necesita cumplir nuevos requisitos, el registro debe poder transferirse en la práctica.

2. Historial de auditoría trazable

Quién cambió qué, cuándo y bajo qué autoridad será cada vez más importante.

3. Lógica de acceso basada en roles

El acceso diferenciado ya es una expectativa base razonable.

4. Política de continuidad clara

Defina qué ocurre con los registros si el cliente cierra la cuenta o se activan obligaciones de continuidad.

5. Decisiones arquitectónicas abiertas

Los sistemas diseñados en torno a identificadores abiertos, registros estructurados y lógica de migración están mejor posicionados.

Qué deberían preguntar quienes compran acceso a una plataforma DPP

Este artículo no es solo para creadores de software. También es para fabricantes, importadores y propietarios de marcas que evalúan proveedores.

Preguntas útiles:

¿Cómo gestionan la propiedad de los datos?
¿Pueden exportarse los registros en formato estructurado?
¿Cuál es su enfoque de respaldo y continuidad?
¿Cómo separan datos públicos de datos de acceso restringido?
¿Cómo diseñan la interoperabilidad?
¿Qué ocurre si queremos cambiar de proveedor en el futuro?

Estas ya no son preguntas de adquisición de nicho; van al núcleo de la credibilidad de la arquitectura DPP de un proveedor.

Conclusión estratégica

El acto delegado definitivo para los proveedores de servicios DPP aún está por llegar, pero la dirección del diseño ya es lo suficientemente visible como para respaldar la toma de decisiones prácticas.

El modelo de plataforma DPP más resiliente probablemente no se basará en opacidad, barreras de salida propietarias y lógica de continuidad débil. El modelo más sólido se construye en torno a:

gobernanza clara
registros estructurados y exportables
interoperabilidad
acceso basado en roles
disciplina de respaldo y continuidad

Las empresas no necesitan esperar a que cada detalle técnico sea definitivo antes de utilizar estos criterios.

Leer a continuación

Fuentes oficiales

Si las plataformas DPP avanzan hacia requisitos más estrictos de gobernanza, portabilidad y continuidad, tiene sentido trabajar con un proveedor que siga estas cuestiones de cerca desde el principio. OriginPass trata los datos de producto como una infraestructura estructurada y transferible, no solo como páginas de consulta del pasaporte.

Seguir leyendo

Guías relacionadas