EPCIS 2.0 y GS1 Digital Link para pymes: eventos, ejemplo JSON-LD y anclaje en blockchain

EPCIS 2.0 es el estándar de GS1, publicado también como ISO/IEC 19987, para registrar y compartir eventos de trazabilidad: qué objetos, cuándo, dónde y por qué han pasado por un punto de la cadena. La versión 2.0 añade JSON-LD, una interfaz REST y datos de sensores. GS1 Digital Link es la sintaxis que convierte un GTIN, un lote o un número de serie en una URL. Juntos permiten que dos empresas describan el mismo movimiento con las mismas palabras.

Este artículo es la guía técnica del clúster de trazabilidad. Si buscas el contexto normativo (Reglamento 178/2002, EUDR), empieza por Trazabilidad alimentaria: Reglamento 178/2002, EUDR y cómo hacerla verificable; la definición corta y la comparación con un repositorio clásico están en la página Trazabilidad EPCIS 2.0.

Por qué una pyme debería hablar EPCIS

Una cooperativa, un tostador o un pequeño laboratorio no necesitan EPCIS para saber lo que hacen: lo necesitan para que su cliente grande, su certificadora o la autoridad entiendan sus registros sin una hoja de cálculo hecha a medida. EPCIS fija el vocabulario; lo que tú pones dentro sigue siendo tu información.

• El comprador exige cada vez más un intercambio de eventos, no un PDF.
• Las normas con plazo (EUDR, pasaporte de baterías, serialización farmacéutica) piden datos estructurados por lote e instalación; EPCIS ya tiene un sitio para cada uno.
• Un evento EPCIS es un documento JSON pequeño: se puede generar desde un ERP modesto, una hoja de cálculo exportada o un formulario web.

Las cuatro dimensiones y los cinco tipos de evento

Cada evento EPCIS responde a cuatro preguntas: qué (identificadores de los objetos), cuándo (eventTime con su desplazamiento horario), dónde (readPoint, el punto donde se leyó, y bizLocation, dónde queda el objeto después) y por qué (bizStep, el paso de negocio, y disposition, el estado resultante). EPCIS 2.0 añade una quinta dimensión opcional, cómo, con datos de sensores.

Las acciones son solo tres: ADD, OBSERVE y DELETE. TransformationEvent no lleva acción porque las entradas se consumen y las salidas aparecen. No existen "tipos" como agregar o desagregar: son el mismo AggregationEvent con acciones distintas.

El vocabulario: CBV 2.0

El Core Business Vocabulary es la lista cerrada de valores para bizStep y disposition. Un bizStep es siempre uno de los definidos por GS1 (commissioning, receiving, shipping, packing, inspecting, transporting, retail_selling...) y una disposition también (active, in_transit, in_progress, sellable_accessible, recalled, destroyed...). Si necesitas un paso que no encaja, CBV tiene "other" y EPCIS admite extensiones con un prefijo propio, pero un valor inventado fuera del vocabulario no valida y no lo entenderá nadie más.

Identificadores: GS1 Digital Link

Un GTIN de trece dígitos impreso en un código de barras identifica una clase de producto. Para seguir un lote o una unidad concreta hace falta más: el lote (AI 10) y, si procede, el número de serie (AI 21). GS1 Digital Link escribe todo eso como una URL:

• https://id.gs1.org/01/09506000134352 identifica el producto (GTIN-14 con cero a la izquierda).
• https://id.gs1.org/01/09506000134352/10/L-2026-09 identifica un lote.
• https://id.gs1.org/01/09506000134352/10/L-2026-09/21/00042 identifica una unidad de ese lote.
• https://id.gs1.org/414/8412345000010 identifica una instalación (GLN).

La misma URL sirve como identificador en el evento EPCIS, como enlace en un QR y como clave de búsqueda. GS1 impulsa la migración de los códigos lineales a códigos 2D en el punto de venta con la iniciativa Sunrise 2027; un QR con Digital Link cumple los dos papeles. Un detalle que se olvida a menudo: el dígito de control. Un GTIN o un GLN con el último dígito mal calculado es inválido, y un sistema serio debe rechazarlo en vez de guardarlo.

Un evento EPCIS 2.0 completo

Este documento contiene un ObjectEvent que da de alta un lote de aceite en una almazara. Es JSON-LD válido contra el esquema de GS1: el contexto es el normativo de EPCIS 2.0, el GTIN y el GLN tienen dígito de control correcto y bizStep y disposition son tokens del CBV.

{
  "@context": ["https://ref.gs1.org/standards/epcis/epcis-context.jsonld"],
  "type": "EPCISDocument",
  "schemaVersion": "2.0",
  "creationDate": "2026-09-15T08:30:00.000+02:00",
  "epcisBody": {
    "eventList": [
      {
        "type": "ObjectEvent",
        "eventTime": "2026-09-15T08:12:45.000+02:00",
        "eventTimeZoneOffset": "+02:00",
        "epcList": ["https://id.gs1.org/01/09506000134352/10/L-2026-09"],
        "action": "ADD",
        "bizStep": "commissioning",
        "disposition": "active",
        "readPoint": {"id": "https://id.gs1.org/414/8412345000010"},
        "bizLocation": {"id": "https://id.gs1.org/414/8412345000010"},
        "ilmd": {"cbvmda:lotNumber": "L-2026-09", "cbvmda:itemExpirationDate": "2028-03-31"}
      }
    ]
  }
}

Tres detalles que hacen que valide o no: eventTimeZoneOffset es obligatorio (no se puede deducir del servidor); action solo admite ADD, OBSERVE o DELETE; y el bloque ilmd (datos maestros a nivel de instancia o lote) solo tiene sentido en eventos con action ADD, que es donde nace el lote.

Qué añade anclar los eventos en una blockchain

EPCIS define cómo describir un evento, no cómo demostrar cuándo se escribió ni que nadie lo haya editado después. Un repositorio EPCIS guarda un recordTime, pero lo fija el propio sistema. Anclar añade dos cosas:

1. Integridad encadenada. Cada evento incorpora el hash del anterior. Modificar uno antiguo obliga a rehacer todos los siguientes.
2. Fecha con prueba de trabajo. El hash del evento se inscribe en una transacción de una red pública. La cabecera del bloque que la incluye lleva una marca temporal cubierta por la prueba de trabajo, y esa cabecera la puede verificar cualquiera.

El evento sigue siendo tuyo y sigue estando en tu repositorio. En la cadena solo va el hash: 32 bytes que no revelan producto, cliente ni cantidad. Si en el futuro cambias de proveedor o de repositorio, la prueba sigue valiendo, porque no depende de ninguno de los dos.

Cómo empezar en una pyme, en cinco pasos

1. Consigue tus claves GS1 (prefijo de empresa, GTIN por producto, GLN por instalación). Sin ellas puedes usar identificadores propios, pero nadie fuera de tu empresa los reconocerá.
2. Elige los eventos mínimos. Para la mayoría de cadenas bastan tres: alta del lote (commissioning), expedición (shipping) y recepción (receiving). Añade transformación si mezclas lotes.
3. Captura el huso horario en cada evento, aunque toda tu operación esté en el mismo sitio.
4. Valida contra el esquema antes de enviar. Un evento que no valida no se guarda; corregirlo después cuesta más.
5. Ancla y firma. Ancla el hash de cada evento (o el de cada lote) y firma con la clave de tu empresa, para que el evento diga quién lo declaró.

Qué dice la norma

EPCIS 2.0 (GS1, ratificado en 2022; ISO/IEC 19987): define los cinco tipos de evento, las tres acciones, la obligatoriedad de eventTimeZoneOffset y la sintaxis JSON-LD; el CBV 2.0 (ISO/IEC 19988) fija los valores de bizStep y disposition. Los esquemas JSON y el contexto JSON-LD están publicados por GS1 en su repositorio público.

GS1 Digital Link: estándar de GS1 que define cómo representar claves GS1 (GTIN, lote, serie, GLN, SSCC) como URI web, admitidas por EPCIS 2.0 como identificadores de objeto y de ubicación.

Reglamento (UE) 910/2014 (eIDAS), artículo 41.1: un sello de tiempo electrónico no puede ser privado de efectos jurídicos ni de admisibilidad como prueba solo por ser electrónico o por no ser cualificado. El anclaje en blockchain es un sello de tiempo electrónico no cualificado: sin la presunción de exactitud del artículo 41.2.

Normas sectoriales que piden datos estructurados: el Reglamento (UE) 2023/1115 (EUDR) con geolocalización por parcela y declaración de diligencia debida; el Reglamento (UE) 2023/1542 con el pasaporte de baterías desde el 18 de febrero de 2027; la Directiva 2011/62/UE y el Reglamento Delegado (UE) 2016/161 con el identificador único de cada envase de medicamento desde el 9 de febrero de 2019. Ninguna exige EPCIS ni blockchain; todas piden registros por lote que se puedan entregar y contrastar.

Cómo hacerlo con Proovik

La API de trazabilidad de Proovik acepta eventos con los cinco tipos de EPCIS 2.0, los valida contra el esquema de GS1 (incluido el dígito de control de GTIN, GLN y SSCC y el vocabulario cerrado del CBV), los encadena por hash, permite firmarlos por actor y ancla el hash en la red Kaspa, que produce unos diez bloques por segundo; el sello suele confirmarse en segundos. Cada lote se puede exportar como EPCISDocument JSON-LD, buscar por GTIN, lote o número de serie, y verificar desde una URL pública con QR. La prueba se comprueba sin Proovik con la especificación de la página verificar. El servicio se contrata desde la página de trazabilidad.

Lo que acredita: que el evento existía en la fecha del bloque y que no se ha alterado. Lo que no acredita: que los datos del evento sean ciertos, ni que registrarlos equivalga a cumplir el EUDR, el reglamento de baterías o la serialización farmacéutica. Esas normas exigen datos y trámites concretos; Proovik aporta la evidencia de fecha e integridad sobre los que tú registras.

Fuentes

• EPCIS 2.0, estándar de GS1: ref.gs1.org/standards/epcis
• CBV 2.0, Core Business Vocabulary: ref.gs1.org/standards/cbv
• GS1 Digital Link: ref.gs1.org/standards/digital-link
• Esquemas JSON y contextos JSON-LD de EPCIS 2.0 (GS1, GitHub): github.com/gs1/EPCIS
• Reglamento (UE) 2023/1115 (EUDR): eur-lex.europa.eu/eli/reg/2023/1115/oj
• Reglamento (UE) 2023/1542 (baterías): eur-lex.europa.eu/eli/reg/2023/1542/oj
• Reglamento Delegado (UE) 2016/161 (identificador único de medicamentos): eur-lex.europa.eu/eli/reg_del/2016/161/oj
• Reglamento (UE) 910/2014 (eIDAS): eur-lex.europa.eu/eli/reg/2014/910/oj

Equipo Proovik. Publicado el 15 de septiembre de 2026; última revisión el 6 de septiembre de 2026.