Un código QR puede conducir a la página de producto correcta y, aun así, mostrar la imagen de producto equivocada. La causa más frecuente no es el escaneo, sino una cadena de suministro de activos deficiente: se confunde un nombre de archivo con la identidad de un producto, un gráfico de campaña sustituye al packshot neutro o una variante antigua del envase sigue disponible mediante la misma URL.
GS1 ratificó en julio de 2026 el Product Image Standard 5.0. La nueva versión principal integra en el estándar la directriz de Sharing/Delivery, que hasta entonces era independiente. De este modo, la captura, el almacenamiento, la denominación, los metadatos, los derechos de uso y la entrega técnica ya no se encuentran en documentos separados. Para fabricantes, distribuidores y operadores de destinos QR, es una buena ocasión para tratar las imágenes de producto como datos maestros versionados, en lugar de como archivos decorativos.
Qué cambia realmente en la versión 5.0
El estándar no es una nueva normativa de producto ni obliga a utilizar un sistema de imágenes concreto. Es un conjunto de reglas de GS1 para imágenes digitales vinculadas a productos y compartidas entre organizaciones. Según el registro de cambios, en la versión 5.0 se incorporaron al estándar ampliado los contenidos exclusivos de la «GS1 Product Image Sharing/Delivery Guideline». Además, se depuraron la denominación, la estructura y la redacción. El directorio de referencia de GS1 registra la versión 5.0 con fecha de cambio del 17 de julio de 2026.
Por eso, el cambio decisivo reside menos en un nuevo formato de archivo que en el modelo general. Una imagen no se crea únicamente para una tienda online concreta. Un proveedor de imágenes la pone a disposición, varios receptores la procesan y puede distribuirse a través de distribuidores, conjuntos de datos, páginas de producto, aplicaciones o puntos de entrada QR. El estándar vincula la calidad del activo con la cuestión de cómo llegan los receptores de forma fiable al archivo correcto.
Separar el activo maestro del derivado web
GS1 recomienda almacenar las imágenes de producto como archivos maestros de alta calidad y ricos en información. A partir de estos maestros pueden derivarse los formatos y tamaños destinados a distintos canales. Así se evita que cada receptor vuelva a escalar o editar un archivo web ya comprimido.
En la práctica, esto implica dos capas. En el repositorio interno de activos se conserva un activo maestro aprobado, por ejemplo, un TIFF de alta calidad u otro formato de origen adecuado. La capa de entrega genera a partir de él derivados JPEG o PNG para la web, las aplicaciones móviles y los feeds de datos de producto. Un derivado puede volver a generarse; su asignación funcional, validez y origen no deben cambiar por ello.
El modelo también reduce las variantes contradictorias. Cuando se rediseña un envase, la nueva imagen recibe su propio estado de aprobación. Los lotes o mercados antiguos pueden seguir apuntando a la versión anterior mientras esta siga siendo válida allí. Sobrescribir automáticamente el archivo bajo una URL sin cambios sería técnicamente cómodo, pero destruiría la trazabilidad.
El nombre de archivo, el producto y el activo son tres identidades
El estándar de GS1 utiliza nombres de archivo estructurados que pueden incluir, entre otros elementos, la GTIN del producto representado, así como el tipo y la finalidad de la imagen. Al mismo tiempo, aclara que este nombre de archivo no es un identificador de GS1 para el propio archivo de imagen. La GTIN identifica el producto comercial, no el activo digital. Si se debe identificar de forma inequívoca un archivo de imagen no comercializado como documento digital, el estándar menciona para ello el Global Document Type Identifier, abreviado GDTI.
Esta separación es importante para los modelos de datos. Un producto puede tener muchas imágenes: vista frontal, vista lateral, envase, detalle, aplicación, representación de sostenibilidad o una imagen del código 2D impreso. A la inversa, un motivo de campaña puede mostrar varios productos. Por tanto, a largo plazo no basta con una relación de base de datos del tipo «el producto tiene una URL de imagen».
Un objeto de activo sólido necesita como mínimo un ID interno propio, la GTIN o ID de producto correspondiente, el tipo de imagen, el estado de aprobación y una versión. Si es necesario, se añaden el GDTI, el idioma, la variante de producto para el consumidor, el ángulo de visión y el estado del envase. El nombre de archivo sigue siendo útil para el intercambio y la resolución de problemas, pero no es la única fuente de verdad.
Un archivo de imagen necesita una URL directa y estable
En la lógica de la Global Data Synchronisation Network, las imágenes de producto no se distribuyen como archivos binarios dentro del registro de datos. En su lugar, se transmiten enlaces a las imágenes accesibles. La versión 5.0 describe para ello la entrega mediante una URL compartida. Cada archivo debe ser accesible directamente; entre los errores conocidos se encuentran los enlaces rotos, los formatos dañados o inadecuados, la protección mediante contraseña y las páginas en las que los usuarios deben navegar manualmente hasta llegar a la imagen correcta.
Esta accesibilidad directa es igualmente relevante para los destinos QR y las API de datos de producto. Una URL debería proporcionar exactamente un activo en un formato definido, no una galería ni un inicio de sesión. El servidor debería devolver un tipo de medio correcto, mantener las redirecciones bajo control y entregar de forma fiable el mismo recurso en solicitudes repetidas.
Esto no significa que cada URL de producto solo pueda ofrecer una imagen. Un resolvedor de GS1-Digital-Link puede hacer localizables varias fuentes tipificadas asociadas a una identidad de producto. No obstante, las propias fuentes de imágenes necesitan destinos inequívocos. El resolvedor se encarga de la selección y la vinculación; el sistema de activos sigue siendo responsable del archivo, la versión y los permisos.
Los metadatos determinan qué imagen es correcta hoy
La versión 5.0 incorpora una lista extensa de metadatos. Entre ellos se incluyen GTIN, el nombre del producto y de la marca, el tipo de imagen, el nombre de archivo, la fecha de creación, el inicio de validez, la fecha de caducidad, el número de versión, el titular legal, los derechos de uso, el idioma y la fecha de aseguramiento de la calidad. También se contempla el texto alternativo como metadato opcional.
No todas las empresas tienen que completar de inmediato todos los campos. Sin embargo, cinco decisiones nunca deberían quedar únicamente en el nombre de archivo: ¿qué producto aparece representado? ¿Qué función cumple la imagen? ¿En qué mercados e idiomas puede mostrarse? ¿Desde cuándo y hasta cuándo es válida? ¿Quién puede modificarla o compartirla?
En particular, las fechas de inicio y fin evitan mostrar packshots incorrectos durante una transición. Puede distribuirse un motivo futuro sin que sea visible antes de su fecha de aprobación. Una vez vencido, puede retirarse automáticamente de las vistas de clientes sin eliminar el registro histórico. Es más preciso que sustituirlo manualmente en una fecha determinada.
Los derechos de uso forman parte del proceso de entrega
Una imagen técnicamente accesible no puede utilizarse automáticamente sin restricciones. El estándar describe límites habituales: los receptores suelen poder escalar las imágenes proporcionalmente o convertirlas a otro formato. En cambio, modificar el texto y el idioma, utilizarla en un territorio incorrecto o mostrarla antes o después del periodo acordado puede no estar permitido.
Por eso, la API de imágenes no debería limitarse a entregar un archivo. Como mínimo, debería apuntar a un registro con el titular, el perfil de derechos, la validez y el contexto permitido. Así, un distribuidor puede comprobar antes de publicar si el activo está aprobado para el país, el idioma, el canal y el periodo correspondientes. Si faltan datos sobre los derechos, la organización necesita una regla predeterminada definida conscientemente, no una suposición tácita.
La multilingüidad no es un sufijo de archivo añadido después
El estándar contempla identificadores de idioma en el nombre de archivo cuando un conjunto de imágenes depende del idioma. Esto es especialmente importante para packshots, imágenes de instrucciones y declaraciones que contienen texto visible. Una nueva versión lingüística es funcionalmente un activo propio; no debería crearse mediante edición automática de imágenes a partir de otro idioma si con ello se modifican las indicaciones del envase o las aprobaciones.
Los textos alternativos también necesitan contexto. El estándar de GS1 los incluye como metadato, mientras que el árbol de decisión del W3C para textos alternativos distingue si una imagen es informativa, funcional, redundante o puramente decorativa. Por ello, un packshot neutro en una página de detalle de producto necesita una descripción distinta de la misma imagen dentro de un enlace o junto a información textual completamente idéntica.
En una página QR multilingüe, el texto alternativo debería proceder del contexto de contenido del idioma correspondiente. Un texto descriptivo almacenado de forma centralizada puede servir como punto de partida, pero no debe copiarse a ciegas en todos los canales.
La imagen de un código 2D también necesita control de versiones
El estándar define un tipo de imagen técnico propio para códigos de barras 2D, incluidos los códigos QR con URI de GS1-Digital-Link y GS1 DataMatrix. Para estas imágenes establece un tamaño mínimo de 600 por 600 píxeles y un esquema de denominación estructurado. Al mismo tiempo, GS1 advierte que los socios o consumidores pueden escanear en cualquier momento las imágenes de códigos 2D y que deben mantenerse actualizadas cuando cambie el contenido vinculado.
Esto debe distinguirse de la verificación de la calidad de impresión de un código. Una imagen de alta resolución no garantiza que el código realmente impreso en un envase curvado, brillante o dañado sea escaneable. Por ello, el proceso de activos debe dejar claro si un archivo es un original de producción, una fotografía de documentación o una representación ilustrativa del código.
Una prueba práctica de aceptación para las URL de imágenes
Antes de la aprobación, la organización no debería controlar únicamente el aspecto visual. Una prueba automatizada puede comprobar si la URL es accesible sin iniciar sesión, devuelve el tipo de medio de imagen esperado, cumple las dimensiones mínimas y no redirige a una galería HTML. Un hash o un ID de versión muestra si el archivo entregado ha cambiado sin una nueva aprobación.
La prueba funcional complementa esta técnica: GTIN y la variante de producto deben coincidir, el tipo de imagen y el idioma deben ser correctos, el periodo de validez debe cubrir el momento de publicación y los derechos deben permitir el canal de destino. Para las imágenes informativas también se comprueba la adecuación del texto alternativo. En el caso de un código 2D, debe realizarse además un escaneo real del patrón de producción.
Así se crea una cadena de suministro pequeña, pero completa: activo maestro aprobado, derivado reproducible, asignación inequívoca del activo, URL directa, metadatos legibles por máquina y validez supervisada.
La consecuencia para los proyectos QR y de datos de producto
El GS1 Product Image Standard 5.0 deja claro que las imágenes de producto no son anexos al final de un proyecto de datos. Poseen identidad, ciclo de vida, derechos y características de calidad propios. Quien solo almacena una ruta de archivo junto a la GTIN pierde estas relaciones como muy tarde con el primer cambio de envase, idioma o campaña.
Por ello, para destinos QR, feeds de datos de producto y futuros pasaportes de producto, resulta recomendable un registro de activos que publique las imágenes bajo control, igual que el resto de la información del producto. El código QR sigue siendo el punto de entrada. Que detrás aparezca la imagen correcta, válida y utilizable depende de una cadena de suministro de activos gestionada correctamente.
Fuentes
GS1 Product Image Standard, Release 5.0, julio de 2026
