RFID y blockchain suelen presentarse como pareja porque se dice que ambos eliminan la confianza de un proceso. Eliminan confianzas distintas, y el valor de la combinación depende por completo de cómo se unan. RFID hace observable un evento físico. Una cadena encarece la reescritura de una secuencia de registros. Ninguno de los dos, por separado, prueba que el palé correcto estuviera en el camión correcto.

Eso no es motivo para descartar la combinación. Es motivo para precisar la pregunta que responde: no qué es verdad, sino qué se afirmó, por quién y en qué orden. Esas preguntas importan sobre todo cuando las partes no comparten un ERP y la discrepancia la resolverá un tercero.

Dos libros y dos modelos de confianza

El libro físico es ruidoso, local y efímero. El libro digital es disperso, global y permanente. Tratarlos como el mismo objeto es donde fallan la mayoría de los proyectos.

El libro RFID registra observaciones: etiqueta, antena, hora, señal y calidad de la lectura.
La cadena registra afirmaciones: una parte sostiene que este número de serie salió de esta sede, en este envío, a esta hora.
La confianza del RFID descansa en la instalación: colocación de antenas, tasa de lectura, resistencia a la manipulación de la etiqueta.
La confianza de la cadena descansa en la gobernanza: quién puede escribir, cómo se identifica a los escritores y qué ocurre cuando discrepan.
Un registro inmutable de una observación errónea sigue siendo erróneo. La inmutabilidad multiplica la confianza; no la crea.

Qué puede y qué no puede probar una lectura RFID

Ser explícito sobre la fuerza probatoria es la base de un diseño creíble.

Puede probar que una etiqueta con una identidad dada fue energizada en una antena concreta dentro de una ventana temporal conocida, con una confianza registrada.
No puede probar que la etiqueta estuviera adherida al artículo correcto, que la caja contuviera lo que dice el manifiesto, ni que una persona no cambiara las etiquetas.
No puede probar ausencia. Una lectura perdida es una lectura perdida; el artículo puede seguir en el palé.
La clonación es real. Los valores EPC se copian sin dificultad; use etiquetas con TID único, autenticación criptográfica o ambas cuando el valor en juego lo justifique.
Documente el nivel de confianza junto al evento. Un auditor que entiende los límites confía más, no menos.

Dónde se amortiza una cadena

Un libro distribuido cuesta más que una base de datos en operación, integración y gobernanza. Solo se amortiza bajo condiciones concretas.

Varias partes que no comparten un sistema de registro y no aceptarán la base de datos de una de ellas como neutral.
Consecuencias altas de una disputa: farmacéutica bajo reglas de serialización, trazabilidad alimentaria, bienes de lujo, piezas de automoción críticas para la seguridad.
Preguntas de auditoría sobre la historia y no sobre el presente: qué decía el registro el día del envío, antes de la retirada.
Un regulador o una aduana que necesitan acceso de lectura sin recibir permiso de escritura.
Encaja mal en la preparación interna de pedidos. Una base de datos normal con un log de auditoría de solo anexado es más barata, más rápida e igual de auditable.

Anclaje: unir el evento físico al registro

El vínculo es un hash, y la ingeniería está en qué entra en él y cuándo se escribe.

Serialice el evento en una carga canónica: campos EPCIS 2.0, TID de la etiqueta, identificadores de lector y sede, hora del evento con su fuente y los identificadores de lectura que lo sustentan.
Calcule el hash de la carga canónica con un algoritmo estable y no dependa nunca del orden de las claves JSON en la entrada del hash.
Agrupe eventos por envío o por ventana temporal y escriba una única raíz de Merkle en lugar de una transacción por etiqueta.
Mantenga la carga completa fuera de la cadena; la cadena guarda la raíz, el puntero y la identidad del escritor.
No bloquee el muelle esperando confirmación. Confirme en local primero, ancle de forma asíncrona y concilie dentro de un nivel de servicio definido.

El modelo de datos en cadena debe ser aburrido

Los proyectos con más éxito ponen casi nada en el contrato. El libro es un almacén de evidencias, no un servidor de aplicaciones.

Registre activos por GTIN y número de serie, con un árbol de agregación para palé, caja y artículo.
Modele un conjunto pequeño de clases de evento: alta, agregación, envío, recepción, baja.
Valide las transiciones de estado en el contrato y deje precios, rutas y optimización fuera de él.
Asigne permisos de escritura por clase de evento y por parte, de modo que un transportista no pueda dar de alta series ni un minorista alterar registros de expedición.
Versione el esquema en cadena. Un almacén de evidencias que no puede evolucionar se abandona en dos años.

Privacidad y confidencialidad comercial

Un libro compartido es una superficie compartida. Todo lo escrito es visible para todos en el canal, salvo que se diseñe lo contrario.

Use una plataforma permisionada con canales cuando los socios sean competidores y revele solo los eventos que cada parte necesita.
Mantenga los datos personales fuera de la cadena. Referencias hash, no nombres; si un hash puede revertirse por fuerza bruta, añada sal.
El derecho al olvido no puede borrar un registro inmutable. Diseñe para que los datos personales nunca lleguen a la cadena.
Trate volúmenes, precios y rutas como secretos comerciales. Comprometa el hash y revele la carga a un auditor bajo contrato.
La gestión de claves es el punto débil operativo: rote claves, separe roles y prepare un plan para un nodo de socio comprometido.

Las excepciones son donde se demuestra el valor

Una cadena que solo registra éxitos es una nota de prensa cara. Las disputas están en las excepciones.

Lectura ausente en recepción: genere un evento de excepción y haga que ambas partes firmen el mismo registro.
Huecos en la cadena de custodia: un transportista sin escaneo entre dos sedes crea una ventana que debe marcarse, no ocultarse.
Los contratos inteligentes no pueden juzgar daños físicos, entregas parciales o una caja mal etiquetada. Mantenga el arbitraje en manos humanas y contractuales.
Reúna un paquete de evidencias: hashes de eventos, lecturas en bruto, fotos y la configuración del lector en ese momento.
Fije un nivel de servicio para el anclaje, normalmente quince minutos, y escale cuando se incumpla.

Una ruta de adopción por etapas

La mayoría de los fracasos vienen de empezar en la etapa cuatro. Empiece donde el dolor de auditoría ya existe.

Etapa uno: un log interno de solo anexado con el esquema EPCIS que después llevaría a la cadena. Por sí solo resuelve la mayoría de las preguntas de trazabilidad.
Etapa dos: anclar hashes a un libro permisionado con dos o tres socios, en una línea de producto.
Etapa tres: extender a transportistas y clientes con revelación selectiva y medir el tiempo de resolución de disputas.
Etapa cuatro: dar a auditores y reguladores un nodo de solo lectura e integrar los flujos de retirada.
Siga tres cifras: disputas resueltas al mes, tiempo para completar una retirada y coste por evento anclado. Si la tercera sube y la primera no baja, deténgase.

La combinación funciona cuando el evento físico es lo bastante fiable como para merecer anclaje y el libro se usa para el conjunto estrecho de afirmaciones que ninguna parte debería poseer. Todo lo demás es una base de datos, y llamarla cadena no la convierte en una.