IA y blockchain, cómo se combinan y qué funciona en 2026

La inteligencia artificial puede intervenir en procesos donde varias organizaciones comparten datos o autorizan operaciones. En esos entornos, además de obtener un resultado, importa conservar información sobre cómo se produjo: qué datos recibió el sistema, qué versión utilizó y quién autorizó su actuación. Blockchain puede servir como registro compartido de determinadas evidencias de ese proceso.

La combinación resulta pertinente cuando otros participantes necesitan comprobar esas evidencias sin depender únicamente del registro de una organización. Su aportación está en la trazabilidad y la coordinación; no demuestra por sí sola que el modelo razone correctamente o que su respuesta sea verdadera.

Cómo repartir el trabajo entre IA y blockchain

En una arquitectura habitual de integración, el modelo y sus datos permanecen fuera de la cadena. La aplicación registra versiones, autorizaciones y referencias a ciertos resultados. Un tercero puede comparar documentos conservados con las referencias publicadas y detectar cambios posteriores.

Ese es un patrón posible, no una regla universal ni una demostración de ejecución correcta. Si un operador registra que utilizó el modelo A cuando utilizó B, el hash de su declaración no descubre la mentira. Para verificar el cálculo hacen falta controles adicionales, como ejecución reproducible, atestaciones o pruebas criptográficas diseñadas para esa propiedad.

También conviene separar red y aplicación. Una red blockchain puede resistir cambios en el historial aceptado, mientras la aplicación conserva permisos para modificar reglas o administradores. La fiabilidad del producto depende de esas facultades y de sus operadores, además del consenso.

Si la salida del modelo debe llegar a un contrato, un oráculo puede transmitirla. El contrato comprueba la fuente autorizada y las condiciones programadas, pero recibir una respuesta firmada no acredita la corrección de la inferencia. Esa frontera debe quedar explícita en los permisos de ejecución.

Qué registrar y qué conservar fuera de la cadena

El expediente de un evento puede incluir identificador, versión del modelo, configuración, fuentes consultadas, autorización, resultado y referencias a documentos. Publicar todo ese expediente en una red abierta no suele ser necesario. Se debe elegir la evidencia mínima que necesita el verificador.

Un hash permite comprobar que un archivo coincide con la versión referenciada, siempre que el archivo siga disponible. No acredita su autor, exactitud ni momento original de creación. El tiempo del bloque proporciona una referencia de inclusión bajo las reglas de la red; no equivale por sí solo al instante exacto de la inferencia.

Direcciones, identificadores y hashes pueden seguir siendo datos personales si permiten vincular información con alguien. Mantener el contenido fuera de la cadena no garantiza anonimato. Las directrices del EDPB sobre blockchain exigen analizar el tratamiento concreto, su finalidad y los derechos de las personas.

Ejemplo: revisión documental entre proveedor y comprador

Imaginemos un sistema que utiliza IA para detectar discrepancias entre un pedido y una entrega. Es un ejemplo hipotético. El modelo señala que faltan unidades; una persona revisa los documentos y autoriza una reclamación. El registro compartido conserva referencias a la documentación, al resultado y a esa autorización.

Si el proveedor discrepa, puede verificar qué versión de los documentos se presentó y quién aprobó la acción. Para comprobar el razonamiento necesitará además el contexto conservado fuera de la cadena. Reproducir una salida puede requerir versión exacta, parámetros y componentes externos; algunos modelos o servicios no ofrecen reproducibilidad determinista.

El diseño debe contemplar documentos corregidos y decisiones revocadas. Se registra un nuevo estado que enlaza con el anterior y explica quién autorizó el cambio. Conservar trazabilidad no significa ejecutar para siempre una decisión que se ha demostrado incorrecta.

Procedencia de contenidos y datos de entrenamiento

Las credenciales de contenido de C2PA permiten asociar declaraciones firmadas sobre la procedencia y edición de una pieza. No necesitan una red blockchain para existir y no certifican la verdad de lo que muestra la imagen o afirma el texto. Su utilidad depende de las declaraciones y de la confianza en sus firmantes.

Para modelos de propósito general, el artículo 53 del Reglamento europeo de IA establece, entre otras obligaciones, publicar un resumen suficientemente detallado del contenido utilizado en el entrenamiento. La Comisión ofrece una plantilla específica. Esta obligación no exige usar blockchain ni convierte un registro de hashes en cumplimiento automático.

Un catálogo versionado de conjuntos de datos y licencias puede apoyar la documentación. Acreditar que un conjunto fue realmente utilizado, o que existía autorización suficiente, exige evidencia adicional. Una prueba de conocimiento cero solo demuestra la propiedad definida por su circuito y sus entradas; no resuelve de forma general la procedencia jurídica de todos los datos.

Agentes de IA que realizan pagos

x402 propone integrar solicitudes y pruebas de pago en un intercambio HTTP. Puede utilizarse para que software, incluidos agentes, pague por un recurso. No es necesario que el pagador sea una IA y el protocolo de pago no determina si la compra era útil o estaba autorizada por su propietario.

El control se diseña alrededor del agente: presupuesto, activos permitidos, destinatarios, límites por operación y revisión de acciones sensibles. Una dirección de wallet no aporta por sí sola identidad jurídica ni límites de gasto. Los permisos que impone el sistema deben comprobarse antes de que una salida del modelo pueda mover fondos.

Un ejemplo de fallo sería repetir un pago porque la respuesta del proveedor se perdió. El sistema necesita identificadores, consulta del estado y una política de reintentos que evite duplicados. La confirmación del pago y la entrega del recurso son estados distintos.

Coste, latencia y criterio de adopción

Separa coste de inferencia, almacenamiento de evidencia, operaciones en cadena e integración. Agrupar registros puede reducir transacciones, pero introduce una ventana entre el evento y su anclaje. Esa demora debe ser compatible con lo que se pretende demostrar.

Si una acción debe comprobar permisos antes de ejecutarse, registrar su evidencia después no sustituye ese control previo. Si solo se necesita conservar un rastro para revisión posterior, un anclaje por lotes puede ser suficiente. El diseño depende del objetivo de verificación.

Compara el resultado con logs firmados, sellado temporal y repositorios con control de acceso. En consultoría blockchain la decisión útil es identificar quién verifica qué, qué confianza acepta y cómo se recupera de un fallo. Solo después conviene elegir la infraestructura.