El nuevo cuello de botella práctico: ¿quién puede registrar un pasaporte?
El DPP-Registro de la UE está operativo desde el 20 de julio de 2026. Para muchos equipos, la cuestión técnica ocupó inicialmente el primer plano: ¿se puede registrar un identificador de producto y el soporte resuelve correctamente? Es necesario, pero incompleto. Con el Reglamento de Ejecución (UE) 2026/1778, de 16 de julio de 2026, la identidad previa adquiere su propio significado normativo: deben registrar operadores económicos verificados, y el acceso a las funciones del Registro no equivale al acceso público a la información del producto.
Esto no es motivo para hacer más complejos los códigos QR. Es motivo para modelar correctamente las responsabilidades, las pruebas y las autorizaciones antes del primer proceso de registro productivo. La siguiente guía separa estos niveles y muestra qué pueden preparar ahora los fabricantes.
Tres identidades que no deben mezclarse
En un proyecto de DPP intervienen al menos tres identidades diferentes.
En primer lugar, está el operador económico: la empresa o el empresario individual que comercializa un producto o actúa en el Registro. El artículo 4 del Reglamento 2026/1778 vincula la clasificación como «operador económico verificado» a una prueba de identidad. Para los empresarios individuales establecidos en la UE, el acto jurídico menciona, por ejemplo, una firma electrónica cualificada o un medio de identificación electrónica conforme a eIDAS con un nivel de confianza alto. Las personas jurídicas también deben verificarse mediante pruebas definidas.
En segundo lugar, está el usuario humano. Compras, gestión de datos maestros, cumplimiento, proveedores de servicios externos y un proveedor de servicios DPP no actúan automáticamente con la misma autorización. Por ello, una cuenta de usuario no sustituye al contexto empresarial verificado. Se necesita una asignación trazable: ¿quién actúa en nombre de qué operador económico, con qué función y hasta cuándo?
En tercer lugar, está la identidad del producto. Un GTIN, un número de serie u otro identificador describe el producto o la granularidad requerida; no demuestra que la persona frente a la pantalla esté autorizada para registrarlo. El ESPR separa expresamente estas esferas: el soporte vincula el producto con el pasaporte, mientras que el Registro conserva los identificadores inequívocos y los datos de registro. La visión general de la Comisión sobre el DPP describe el proceso en consecuencia: se crea y registra la información del producto y, a continuación, el Registro genera un identificador de registro inequívoco.
Quien reúna estas tres identidades en una tabla, un token de API o un buzón de correo electrónico compartido crea posteriormente un riesgo operativo y de auditoría. La pregunta correcta no es «¿Quién conoce el enlace?», sino «¿Quién puede iniciar una operación en el Registro en nombre de este operador económico?».
El acceso público mediante QR no es una autorización del Registro
Un código QR en el producto sigue siendo una vía de acceso al pasaporte. No es un mecanismo de inicio de sesión para el Registro ni debería convertirse en uno. Los consumidores, los talleres de reparación, los recicladores y las autoridades necesitan información diferente. La guía actual de la Comisión sobre el DPP indica expresamente que la información es accesible según las funciones de los usuarios.
En la práctica, por tanto, conviene separar claramente las capas:
- El escaneo público ofrece una vista del pasaporte estable y accesible gratuitamente, con la información prescrita para el grupo de productos correspondiente.
- Una interfaz con acceso restringido por función gestiona las pruebas, los datos de proveedores, los historiales de cambios y las aprobaciones internas.
- El conector del Registro solo debe transmitir los datos de registro necesarios y asignar la respuesta del Registro a un conjunto de datos de producto concreto.
Esto evita dos suposiciones extendidas. Primero: un enlace QR «secreto» no sustituye al control de acceso; puede compartirse y no constituye una prueba sólida de autorización. Segundo: el Registro no es el lugar de almacenamiento de toda la documentación del producto. La Comisión explica que la información completa del producto puede estar en poder del operador económico o de un proveedor de servicios DPP; se registran los metadatos y los identificadores necesarios.
Lo que la normativa sugiere técnicamente
El Reglamento 2026/1778 no describe el Registro como una simple base de datos de consulta. Menciona, entre otros elementos, una API para el registro y la recepción de datos, una plataforma para confirmar la existencia y la integridad, un esquema de identificadores de registro inequívocos, un directorio de proveedores de servicios DPP verificados, un sistema de registros y esquemas de identificación y autorización. Además, los modelos de datos deben estar versionados.
Estas disposiciones no determinan una arquitectura de producto terminada. Sin embargo, proporcionan directrices sólidas:
Perfil empresarial antes de importar productos
Antes de una importación masiva, cree un registro empresarial controlado. Debe incluir la entidad jurídica, su condición de operador económico, la prueba de identidad elegida, la fecha de la comprobación y la unidad responsable. Un sistema DPP solo debería almacenar la prueba en sí cuando sea necesario y esté permitido; a menudo basta con un estado de verificación con referencia y una lógica de caducidad o reevaluación.
La delegación es un registro independiente
Si actúa un proveedor de servicios o una agencia, la delegación necesita un alcance definido. Como mínimo, conviene especificar el operador económico, las acciones permitidas, los grupos de productos o las marcas, el inicio, el fin y la revocación. Una clave de API general sin límites de mandato es demasiado amplia para una operación relevante para el registro.
El registro como operación demostrable
Para cada registro, los equipos deberían conservar como mínimo la versión local del producto, el identificador transmitido, la respuesta con el identificador de registro, la marca de tiempo, la función que actuó y la categoría del error. Esto permite distinguir posteriormente si un pasaporte estaba incompleto desde el punto de vista técnico, si un identificador colisionaba o si faltaba la autorización. El registro no debe convertirse en una recopilación de datos personales innecesarios; debe crear una cadena de actuaciones responsable y verificable.
Probar las autorizaciones como reglas de negocio
Los casos de prueba no deberían terminar con «la API responde 200». Compruebe al menos lo siguiente: un usuario no autorizado no puede iniciar un registro; un proveedor delegado solo puede gestionar el mandato acordado; se rechaza una delegación caducada; la vista pública del pasaporte no revela datos internos del Registro ni de las pruebas; y una operación reenviada se trata de forma trazable como una repetición.
Un plan de inicio sencillo para las próximas semanas
No empiece con una migración completa. Elija un conjunto pequeño y representativo de productos y una cadena real de responsabilidades.
- Asigne para cada producto piloto el fabricante, el comercializador, los responsables de los datos y, si procede, el proveedor de servicios.
- Documente el procedimiento mediante el que se verifica al operador económico y quién aprueba la comprobación.
- Defina funciones para el borrador, la aprobación técnica, el registro y los permisos exclusivamente de lectura.
- Registre un conjunto de datos de prueba con datos de producto versionados y documente el registro, la respuesta y el proceso de corrección.
- Pruebe el acceso público mediante QR por separado de las funciones internas y del conector del Registro.
- Practique la revocación y el cambio: ¿qué ocurre al cambiar de proveedor de servicios, modificar la denominación de la empresa o detectar un identificador erróneo?
Este procedimiento también coincide con la recomendación ya publicada de probar por separado el Registro, el resolutor y la fuente de datos. La novedad es el énfasis: antes de una integración sólida de la API debe estar claro qué organización verificada y qué función asumen la responsabilidad de la operación.
Lo que aún no debería afirmarse
El Reglamento del Registro establece el marco técnico y organizativo. No hace que todos los grupos de productos estén sujetos de inmediato a DPP ni sustituye a los actos delegados específicos de cada sector. La Comisión sigue organizando la implantación por grupos de productos; tras los actos delegados ESPR, se prevé por principio un periodo transitorio de al menos 18 meses. Del mismo modo, la condición empresarial verificada no autoriza a proporcionar datos de producto incompletos o incorrectos.
No obstante, la consecuencia para los equipos es concreta: la identidad, el mandato, las funciones y el registro deben incluirse en el DPP-backlog antes de ampliar los registros. Así, el código QR sigue siendo la sencilla entrada pública, mientras que la operación en el Registro se convierte en lo que es desde el punto de vista normativo: una acción responsable y trazable de un operador económico verificado.
