Digital Link

El pasaporte digital de producto legible por máquina: qué exige el ESPR y por qué lo leerán los agentes de IA

Mia

Por Mia

Redactora especializada en estándares GS1 y normativa europea de etiquetado.

Un hombre en el banco de trabajo de un café de reparación sostiene una tostadora abierta con una etiqueta de código QR mientras su móvil muestra una vista despiezada de sus piezas

TL;DR

  • Un pasaporte digital de producto legible por máquina es una obligación legal: el ESPR dice que los datos del pasaporte deben basarse en normas abiertas, ser interoperables y, según proceda, legibles por máquina, estructurados, consultables y transferibles sin dependencia de un proveedor.
  • Una página web que una persona puede leer no basta por sí sola. El software tiene que poder pedir esos mismos datos en un formato estructurado, con cada campo etiquetado y cada producto designado por un identificador persistente.
  • Los datos que la ley exige que sean exactos, completos y estén actualizados son los mismos que necesita un agente de IA para saber exactamente qué producto tiene delante, siempre que respete los derechos de acceso que fija el pasaporte.

Un pasaporte digital de producto legible por máquina es aquel que el software puede leer con la misma fiabilidad que una persona. No es un extra. El ESPR, el Reglamento (UE) 2024/1781, lo incluye entre los requisitos esenciales que todo pasaporte debe cumplir, y las normas europeas citadas en julio de 2026 convierten esos requisitos en algo que se puede construir.

Esta guía explica qué dice el Reglamento, en qué se diferencia una página de pasaporte legible por personas de un pasaporte legible por máquina, qué piezas se usan habitualmente y por qué esos mismos datos se están convirtiendo en una fuente fiable para los agentes de IA. La lista de datos que debe llevar un pasaporte se trata aparte en Requisitos de datos del Pasaporte Digital de Producto. Todo lo que sigue se expone a fecha de octubre de 2026.

¿Qué dice el ESPR sobre la legibilidad por máquina?

El artículo 10, apartado 1, letra d), fija las reglas para los datos en sí. Todos los datos del pasaporte deben:

  • basarse en normas abiertas
  • desarrollarse en un formato interoperable
  • ser, según proceda, legibles por máquina, estructurados y consultables
  • ser transferibles a través de una red abierta e interoperable de intercambio de datos sin dependencia de un proveedor

Cada una de esas palabras tiene una consecuencia práctica.

Redacción del ESPRQué admiteQué excluye
Normas abiertasFormatos e identificadores que cualquiera puede implementar, como los identificadores ISO/IEC 15459 y los estándares web del W3CUn formato propietario que solo un proveedor puede leer
Formato interoperableDatos que otro sistema de pasaportes puede importar y entenderDatos que solo tienen sentido dentro de la plataforma que los creó
Legibles por máquinaDatos que el software puede procesar sin que una persona los interpreteUn PDF escaneado o una imagen de una etiqueta
EstructuradosCampos con nombre, con significados y unidades definidosTexto libre en el que el contenido reciclado queda enterrado en un párrafo
ConsultablesDatos que se pueden consultar por identificador o por atributoUn documento que hay que descargar y leer entero
Transferibles sin dependencia de un proveedorDatos que pueden pasar a otro proveedor o a otra redUn pasaporte que desaparece o hay que rehacer cuando cambias de proveedor

La expresión «según proceda» deja margen para que el acto delegado de cada grupo de productos decida hasta dónde llega cada requisito. No convierte la legibilidad por máquina en algo opcional.

El artículo 11 añade las reglas a nivel de sistema. Su letra a) exige que cada pasaporte sea plenamente interoperable con los demás pasaportes exigidos en virtud del ESPR «por lo que respecta a los aspectos técnicos, semánticos y organizativos de la comunicación de extremo a extremo y la transferencia de datos». La interoperabilidad técnica significa que los sistemas pueden intercambiar datos. La interoperabilidad semántica significa que coinciden en lo que significan esos datos: que el «contenido reciclado» de un pasaporte es lo mismo, medido de la misma manera, que en otro.

El artículo 11 exige además la autenticación, la fiabilidad y la integridad de los datos (letra g), y el artículo 9, apartado 1, exige que los datos del pasaporte sean exactos, completos y estén actualizados.

Los hitos hasta ahora

FechaQué ocurrió
28 de junio de 2024Se publica el ESPR en el Diario Oficial, con los requisitos del pasaporte en los artículos 9 a 11
31 de julio de 2024La Comisión pide a CEN, CENELEC y ETSI que elaboren normas armonizadas que respalden los artículos 10 y 11
28 de noviembre de 2025La Comisión modifica esa petición, incluidos sus plazos
27 de mayo de 2026CEN y CENELEC publican seis normas básicas del DPP, de la EN 18216 a la EN 18223
15 de julio de 2026La Decisión de Ejecución (UE) 2026/1736 cita las seis normas en el Diario Oficial, lo que otorga una presunción de conformidad con los artículos 10 y 11
16 de septiembre de 2026Se publican la EN 18239 (derechos de acceso y seguridad) y la EN 18246 (autenticación e integridad de los datos); a fecha de octubre de 2026 todavía no están citadas en el Diario Oficial

Legible por personas frente a legible por máquina: ¿cuál es la diferencia?

Una mujer sostiene un móvil que muestra la página de producto de un hervidor junto al hervidor con su código QR, mientras su portátil muestra los mismos datos como código estructurado

Imagina el pasaporte de un mismo hervidor entregado de dos maneras.

La versión legible por personas es una página web. Un consumidor escanea el código QR de la caja y ve los materiales, las instrucciones de reparación, las piezas de recambio y las indicaciones de reciclaje, maquetados para el móvil. Es la experiencia adecuada para una persona. Un programa que lea esa página tiene que adivinar qué número es la potencia y cuál es la longitud del cable, y esa suposición falla cada vez que cambia el diseño.

La versión legible por máquina son los mismos hechos expresados como datos. Cada valor tiene un nombre, un significado definido y, cuando corresponde, una unidad, y el producto se designa con un identificador persistente. El sistema de un reciclador o un marketplace obtiene la misma respuesta siempre, tenga la página el aspecto que tenga.

Página de pasaporte legible por personasPasaporte legible por máquina
Lector principalUna persona con un móvilSoftware: sistemas de las autoridades, recicladores, marketplaces, agentes de IA
FormatoHTML pensado para mostrarse en pantallaDatos estructurados como JSON o JSON-LD, servidos mediante una API o junto a la página
Cómo se identifican los camposTítulos y maquetaciónPropiedades con nombre de un vocabulario compartido
Identidad del productoNombre del producto y fotoUn identificador único persistente, como un GTIN expresado como URI GS1 Digital Link
Cambia cuando cambia el diseñoSíNo
Cumple por sí solo el artículo 10, apartado 1, letra d)NoSí, si el formato y el vocabulario son abiertos

Un pasaporte bien construido hace ambas cosas a partir de un único registro, de modo que la página y los datos no pueden desalinearse.

Qué aspecto puede tener un registro legible por máquina

Aquí tienes un ejemplo ilustrativo deliberadamente pequeño en JSON-LD, el formato del W3C para datos enlazados en JSON. No procede de ninguna norma ni de ningún acto delegado, y un pasaporte real llevaría muchos más datos. Usa términos del GS1 Web Vocabulary y el GTIN de ejemplo de la propia GS1.

{
  "@context": { "gs1": "https://ref.gs1.org/voc/" },
  "@id": "https://example.com/01/09520123456788",
  "@type": "gs1:Product",
  "gs1:gtin": "09520123456788",
  "gs1:productName": { "@value": "Example kettle 1.7 l", "@language": "en" },
  "gs1:dpp": { "@id": "https://example.com/passport/01/09520123456788" }
}

El @id es una dirección web construida a partir del identificador del producto, así que el registro designa un producto exacto. Cada propiedad remite a una definición publicada que cualquiera puede consultar. Y el enlace al pasaporte tiene tipo: gs1:dpp indica al software que lleva al Pasaporte Digital de Producto.

¿Qué cubren las normas de CEN y CENELEC?

El ESPR fija los requisitos. Las normas europeas dicen cómo cumplirlos. Seis normas básicas, desarrolladas por el comité conjunto CEN/CLC/JTC 24 a petición de la Comisión, quedaron citadas como normas armonizadas por la Decisión de Ejecución (UE) 2026/1736, publicada el 15 de julio de 2026. Según el artículo 41, apartado 2, del ESPR, se presume que un pasaporte conforme a ellas cumple los requisitos de los artículos 10 y 11 que cubren.

NormaTítulo tal como se cita en el Diario OficialPor qué importa para la legibilidad por máquina
EN 18216:2026Data exchange protocolsCómo circulan los datos del pasaporte entre sistemas
EN 18219:2026Unique identifiersCómo se designan de forma persistente el producto y su pasaporte
EN 18220:2026Data carriersEl vínculo físico en el producto, como un código QR
EN 18221:2026Data storage, archiving, and persistenceMantener los datos disponibles durante toda la vida del producto
EN 18222:2026APIs for product passport lifecycle management and searchabilityCómo crea, actualiza y busca pasaportes el software
EN 18223:2026System interoperabilityCómo funcionan juntos distintos sistemas de pasaportes

La EN 18222 es la norma cuyo título menciona la consultabilidad (searchability), y la EN 18223 aborda la interoperabilidad que exige el artículo 11, letra a). CEN y CENELEC describen la serie como un conjunto de ocho normas. Las dos restantes, la EN 18239, sobre gestión de derechos de acceso, seguridad y confidencialidad empresarial, y la EN 18246, sobre autenticación, fiabilidad e integridad de los datos, se publicaron el 16 de septiembre de 2026 y, a fecha de octubre de 2026, todavía no se han citado en el Diario Oficial.

Las normas definen cómo funciona un pasaporte, no qué datos tiene que llevar un grupo de productos. Explicamos cada una en las seis normas CEN del DPP, explicadas; los textos se venden a través de los organismos nacionales de normalización, así que no reproducimos su contenido técnico.

¿Cuáles son las piezas técnicas habituales?

Un pasaporte legible por máquina se monta con unas pocas piezas abiertas. Las decisiones concretas seguirán a las normas armonizadas y a cada acto delegado; lo que sigue es el conjunto de herramientas web habitual del que parten.

Un identificador persistente, expresado como dirección web

El artículo 10, apartado 1, letra a), exige que el pasaporte esté conectado, a través de un portador de datos, a un identificador único de producto persistente, y el anexo III cita la serie ISO/IEC 15459 para el portador y los identificadores. El GTIN se basa en esa familia. GS1 Digital Link, cuya norma URI Syntax alcanzó la versión 1.7.0 en agosto de 2026, convierte el GTIN en una dirección web, con número de lote o de serie opcional para pasaportes a nivel de lote y de artículo. La misma dirección sirve como código QR en el envase y como @id del producto en los datos estructurados, y por eso un solo código puede servir tanto al comprador como al software.

JSON y JSON-LD

JSON es el formato cotidiano de las API web. JSON-LD, una Recomendación del W3C, añade un @context que asigna cada campo a un vocabulario publicado, como el GS1 Web Vocabulary o schema.org, que usan los buscadores y que también tiene una propiedad gtin. Dos sistemas que usan el mismo vocabulario se entienden sin un acuerdo bilateral, que es la interoperabilidad semántica en su forma web más habitual.

Un resolver y enlaces con tipo

Un resolver es el servicio que hay detrás de una URI GS1 Digital Link y que decide adónde va un escaneo o una solicitud. El GS1-Conformant Resolver Standard, versión 1.2.1 ratificada en agosto de 2026, permite que un identificador ofrezca muchos enlaces, cada uno etiquetado con un tipo de enlace del GS1 Web Vocabulary. GS1 ha definido un tipo de enlace específico para los pasaportes, gs1:dpp, descrito como «un enlace a un pasaporte digital de producto», junto a tipos relacionados como gs1:sustainabilityInfo, gs1:instructions, gs1:safetyInfo, gs1:certificationInfo y gs1:recallStatus.

Según la norma del resolver, el software puede pedir un tipo de enlace con un parámetro linkType, o el linkset completo (IETF RFC 9264) en JSON enviando Accept: application/linkset+json. Un móvil que escanea el código llega a la página para el consumidor, mientras que un programa que consulta la misma dirección descubre dónde están los datos del pasaporte. Nuestra guía sobre el resolver GS1 Digital Link explica el funcionamiento.

Donde el código QR ayuda de verdad es en el paso físico: lleva el identificador del producto al mundo digital. Por sí solo no hace que los datos sean legibles por máquina. Un código QR que lleva a un PDF cumple el requisito de portador de datos e incumple el artículo 10, apartado 1, letra d).

¿Por qué importa a los agentes de IA un pasaporte legible por máquina?

Los agentes de IA empiezan a buscar, comparar y comprar en nombre de personas y empresas. En el taller del W3C y GS1 en Zúrich, la CEO de Digital Link, Paula Rivero, describió el fallo que se produce cuando no pueden fijar la identidad: un agente puede completar todos los pasos de una compra y aun así comprar el producto equivocado, porque una descripción coincide con varios artículos y solo un identificador designa uno.

Lo que sigue es nuestra lectura de cómo encajan las piezas, no algo que diga ninguna ley ni ningún protocolo de agentes: el ESPR no menciona a los agentes de IA. Pero las cualidades que exige son las que necesita un agente.

  • Una identidad exacta. El pasaporte está anclado a un identificador persistente, así que un agente que compara dos productos casi idénticos puede distinguirlos por GTIN, número de lote o número de serie, no por el nombre.
  • Datos con significado definido. Los campos estructurados de un vocabulario compartido se pueden leer sin extraer el contenido de la página de un minorista ni deducir la especificación.
  • Un deber legal de exactitud. El artículo 9, apartado 1, exige que los datos del pasaporte sean exactos, completos y estén actualizados, y el artículo 11, letra g), exige autenticación, fiabilidad e integridad. Pocas fuentes de datos de producto tienen esas obligaciones.
  • Procedencia. Solo los agentes que nombra el acto delegado pueden crear o actualizar el pasaporte, así que un agente de IA sabe de quién es la declaración que está leyendo.
  • Alcance en la venta en línea. El artículo 9, apartado 2, letra e), permite que el acto delegado fije cómo ven los clientes el pasaporte antes de comprar, incluida la venta a distancia, y el artículo 10, apartado 3, obliga al agente económico a facilitar a los distribuidores y a los mercados en línea, si lo solicitan, una copia digital del portador de datos o del identificador.

Cuando un comprador pide a un agente «un hervidor con piezas reemplazables y al menos un 50 % de plástico reciclado», un pasaporte que expone esos hechos como datos estructurados y autorizados es mejor fuente que una suposición montada a partir de reseñas.

Los derechos de acceso siguen aplicándose

Nada de esto significa que un agente lo vea todo. El artículo 11, letra b), da a cada agente acceso según los derechos fijados en el acto delegado, y el artículo 11, letra f), restringe quién puede escribir. Un agente de compras que actúa para un consumidor lee, como máximo, lo que podría leer el consumidor: la parte pública. Los datos reservados a reparadores, recicladores o autoridades siguen reservados, y el sistema del pasaporte tiene que garantizarlo. Nuestra guía sobre los derechos de acceso al Pasaporte Digital de Producto explica quién ve qué y cómo sigue protegida la información empresarial confidencial.

El límite también funciona en sentido contrario: según el artículo 10, apartado 1, letra e), los datos personales de los clientes no pueden almacenarse en el pasaporte sin su consentimiento explícito.

Qué hacer ahora

  1. Pon en orden tus identificadores. Asegúrate de que cada producto tiene un GTIN o equivalente, y decide si tus productos pueden necesitar pasaportes a nivel de lote o de artículo.
  2. Usa un código QR GS1 Digital Link como portador de datos, para que el mismo código funcione para compradores, inspectores y software.
  3. Modela tus datos una sola vez, de forma estructurada. Asigna cada atributo que tienes a un término de un vocabulario publicado antes de diseñar ninguna página.
  4. Sirve las dos vistas desde el mismo registro: una página para las personas y datos estructurados para el software, con enlaces con tipo para que los programas encuentren el pasaporte.
  5. Planifica pronto los niveles de acceso. Decide qué datos son públicos y cuáles restringidos, y comprueba que tu plataforma lo aplica a cada tipo de solicitante.
  6. Pregunta a tu proveedor por las normas armonizadas. Comprueba cómo se relacionan sus funciones de intercambio, API e interoperabilidad con las normas EN 18216 a EN 18223, y cómo podrías llevarte tus datos.
  7. Trata los datos públicos del pasaporte como tu fuente de datos de producto más autorizada. Una vez estructurados y exactos, esos mismos datos pueden servir a marketplaces, buscadores y agentes de IA.

Digital Link es socio de soluciones de GS1, y nuestra plataforma crea pasaportes de producto basados en estándares sobre un identificador persistente por producto, con un código QR GS1 Digital Link como portador de datos y un resolver que sirve a personas y software desde el mismo registro, manteniendo separados los datos públicos y los restringidos. Si quieres comprobar si tus datos de producto están listos para que los lean las máquinas además de las personas, ponte en contacto con nosotros y nuestro equipo revisará tu caso.

Preguntas frecuentes

¿Exige el ESPR que el Pasaporte Digital de Producto sea legible por máquina?

Sí. El artículo 10, apartado 1, letra d), exige que todos los datos del pasaporte se basen en normas abiertas, estén en un formato interoperable y sean, según proceda, legibles por máquina, estructurados, consultables y transferibles sin dependencia de un proveedor.

¿Un PDF es un pasaporte digital de producto legible por máquina?

No. Un PDF, como una declaración de conformidad, puede enlazarse desde un pasaporte, pero los datos del pasaporte en sí tienen que estar estructurados para que el software pueda leerlos y consultarlos.

¿Exige el ESPR el uso de JSON-LD?

No. El Reglamento fija las cualidades que deben tener los datos y no nombra ningún formato. JSON-LD es un formato abierto del W3C muy utilizado que cumple bien esas cualidades, y los formatos que se usen en la práctica seguirán a las normas armonizadas y a los actos delegados.

¿Qué normas cubren el intercambio de datos y la interoperabilidad del DPP?

Las normas armonizadas citadas en julio de 2026 por la Decisión de Ejecución (UE) 2026/1736 incluyen la EN 18216 sobre protocolos de intercambio de datos, la EN 18222 sobre API para la gestión del ciclo de vida y la consultabilidad, y la EN 18223 sobre interoperabilidad de sistemas. Ajustarse a ellas otorga una presunción de conformidad con los requisitos del ESPR que cubren.

Sí. El GS1 Web Vocabulary define gs1:dpp, descrito como un enlace a un pasaporte digital de producto. Un resolver puede usarlo para etiquetar el enlace al pasaporte, de modo que el software pueda encontrar el pasaporte a partir del identificador del producto.

¿Pueden los agentes de IA leer los datos del Pasaporte Digital de Producto?

Pueden leer todo aquello que su usuario tenga derecho a leer, que en el caso de un consumidor es la parte pública del pasaporte. Los datos restringidos siguen restringidos según los derechos de acceso fijados en cada acto delegado. El ESPR no menciona a los agentes de IA; que los datos estructurados del pasaporte les resulten adecuados es nuestra lectura de los requisitos.

Sé líder en la transición de los códigos de barras a los códigos QR GS1