Un modelo de cotización dinámica para el acceso tokenizado a conjuntos de datos en espacios de datos

1. Introducción

La Estrategia Europea de Datos [1] y el marco regulatorio que la desarrolla —el Reglamento de Gobernanza de Datos [2] y el Reglamento de Datos [3]— promueven la creación de un mercado único de datos sustentado en espacios de datos: infraestructuras que permiten compartir e intercambiar datos entre organizaciones preservando la soberanía del dato, la confianza y la interoperabilidad. Las arquitecturas de referencia del sector, como IDS-RAM [4] y Gaia-X [5], junto con el Dataspace Protocol [6], han consolidado los componentes de conexión, identidad y gobernanza necesarios para el intercambio soberano. Sobre esa base técnica surgen los marketplaces de espacios de datos, que facilitan el descubrimiento, la contratación y el consumo de conjuntos de datos.

Sin embargo, la capa económica de estos marketplaces permanece poco desarrollada. El patrón habitual es el de un catálogo con precios estáticos, fijados a priori por el proveedor, que no se ajustan a la escasez del recurso ofertado ni a la intensidad de la demanda. Este enfoque desaprovecha el descubrimiento de valor que caracteriza a un mercado y limita los modelos de negocio basados en la compartición de datos: un conjunto de datos escaso y muy demandado se cotiza igual que uno abundante y poco solicitado.

Este trabajo aborda esa carencia con las siguientes contribuciones:

• un modelo de acceso tokenizado en el que el derecho de consumo se materializa en tokens con un doble límite —peticiones y volumen de transferencia— bajo control del propietario sobre el suministro;
• una función de cotización dinámica que combina escasez y demanda sobre un precio base, acotada entre un suelo y un techo, con congelación del precio en el instante de compra;
• la demostración de sus propiedades (acotación, monotonía en escasez, reversión de la demanda, neutralidad en abundancia y determinismo transaccional);
• una validación mediante escenarios numéricos y una simulación de la trayectoria de la cotización; y
• su realización sobre estándares abiertos (TM Forum, FIWARE, IDS-RAM), que evita un mecanismo propietario no interoperable.

El resto del artículo se organiza así: la Sección 2 revisa el contexto y el trabajo relacionado; la Sección 3 describe el modelo de acceso tokenizado; la Sección 4 formaliza la cotización dinámica; la Sección 5 demuestra sus propiedades; la Sección 6 la valida; la Sección 7 detalla su realización sobre TM Forum; y las Secciones 8 y 9 discuten limitaciones y conclusiones.

2. Contexto y trabajo relacionado

Espacios de datos y arquitecturas de referencia. Un espacio de datos articula a productores y consumidores en torno a conectores que garantizan un intercambio soberano, descrito por el Dataspace Protocol [6] y las arquitecturas IDS-RAM [4] y Gaia-X [5]. En estas arquitecturas, un componente de clearing house registra las transacciones de forma trazable e inmutable, aportando confianza a la contabilidad del intercambio. La identidad se apoya crecientemente en credenciales verificables y en la identidad digital europea conforme a eIDAS 2.0 [9].

Conector FIWARE y Open APIs de TM Forum. El FIWARE Data Space Connector [7] implementa estos componentes y expone, a través de su módulo tmforum-api, las Open APIs de TM Forum [8] para la gestión de catálogo, pedidos, inventario, uso y cotización. La aplicación de políticas de acceso se delega en un punto de aplicación (PEP) que contabiliza el consumo en cada acceso al dato. Este sustrato estándar es el que habilita una capa económica interoperable.

Precios dinámicos. El ajuste del precio en función de la escasez y de la demanda es un principio clásico de la gestión de ingresos y de los mercados con capacidad limitada. Su traslación a los espacios de datos presenta particularidades: el bien es no rival (puede servirse muchas veces) pero su acceso puede acotarse mediante límites de consumo, y la unidad negociable natural es el token de acceso. La novedad de este trabajo reside en formular un mecanismo de cotización dinámica específico para tokens de acceso a datos y en materializarlo sobre los estándares de espacios de datos, en lugar de un motor de precios propietario. Un punto de partida favorable es que el concepto de cotización se corresponde de forma natural con el recurso Quote (TMF648) de TM Forum.

3. Modelo de acceso tokenizado

La plataforma concede el acceso a un conjunto de datos mediante un token de acceso que delimita el volumen que el consumidor podrá consumir por un precio: un número máximo de peticiones y un volumen máximo de transferencia medido en terabytes (TB). Cada token lleva asociado un precio; al alcanzar cualquiera de sus límites, el token se agota y, para seguir accediendo, el consumidor deberá adquirir otro.

Los tokens solo pueden ser creados por el propietario del conjunto de datos, que decide el suministro: abundante (emisión ilimitada), si desea que muchos consumidores accedan, o escaso (emisión limitada de N tokens), si desea reservar el acceso a unos pocos. Sobre esa base, el sistema habilita una cotización dinámica: el precio del token varía en función de la oferta (escasez del suministro) y la demanda. El precio del token en un instante dado es su cotización.

3.1. Conceptos

Una oferta tokenizada es la configuración, asociada a un dataset, que define los límites por token, el precio base, el modo de precio, el suministro y los parámetros de cotización. Un token de acceso es la instancia adquirida por un consumidor. El modo de precio puede ser fijo (precio constante igual al precio base) o dinámico (cotización variable acotada por un suelo y un techo).

3.2. Invariantes

El modelo se rige por las siguientes restricciones, que gobiernan su corrección funcional:

• solo el propietario crea, edita, pausa o retira ofertas de su dataset;
• un token concede un límite de peticiones y un límite de transferencia; se considera agotado al alcanzar cualquiera de los dos, lo que ocurra antes;
• en emisión escasa, cuando el número de tokens vendidos alcanza N, la oferta pasa a Agotada y no admite nuevas compras;
• el precio efectivo de una compra es la cotización evaluada en el instante de confirmación; ese valor se congela en el token y no se altera por cotizaciones posteriores;
• toda compra se registra de forma inmutable —incluida la cotización aplicada— en la capa de clearing house, y activa automáticamente los derechos de acceso del consumidor;
• un consumidor puede poseer varios tokens sobre un mismo dataset; el consumo se contabiliza sobre el token activo;
• la aplicación efectiva de los límites se realiza en el PEP en cada acceso; y
• la cotización mostrada antes de confirmar la compra coincide con la que se aplicará (transparencia de precio).

3.3. Ciclos de vida

La funcionalidad gestiona dos ciclos de vida independientes, representados en la Figura 1. La oferta tokenizada transita entre Borrador, Publicada, Pausada, Agotada y Retirada; la publicación la hace visible y contratable, el agotamiento ocurre cuando se vende todo el suministro escaso, y la retirada no invalida los tokens ya vendidos. El token de acceso transita entre Disponible, Activo, Agotado y Caducado/Revocado; la compra lo activa y congela su precio, y alcanzar un límite lo agota, momento en el que el consumidor puede adquirir otro.

3.4. Modelo de datos

El modelo extiende las entidades del catálogo de la plataforma. La oferta tokenizada especializa la entidad genérica Oferta (añadiendo límites, precio base, modo, suministro, parámetros y el contador de vendidos v). Se incorporan el token de acceso (con sus límites concedidos, contadores de consumo, precio pagado y estado), la cotización (serie histórica del precio, con instante, índice de demanda y vendidos) y el registro de consumo (evento de uso: peticiones y bytes transferidos, fuente de la contabilización de límites). La compra se refleja en la entidad Transacción, que incorpora la cotización aplicada y el hash de su registro inmutable.

4. Cotización dinámica

En modo dinámico, la cotización combina dos presiones —escasez (oferta) y demanda— sobre un precio base P₀, y queda acotada entre un suelo P_min y un techo P_max.

4.1. Formulación

Sea v el número de tokens vendidos de una emisión de suministro N, y D(t) el índice de demanda en el instante t. La cotización se define como

con las componentes de escasez y demanda

donde clamp(x, a, b) = min(max(x, a), b) acota x al intervalo [a, b]. Si el suministro es ilimitado (abundante), la componente de escasez es neutra: M_e = 1.

4.2. Componente de escasez

El multiplicador M_e(v) de la ecuación (2) crece con la fracción vendida v/N. El exponente γ define la forma de la curva: lineal (γ = 1) o convexa (γ > 1), en la que los últimos tokens del suministro se encarecen de forma más acusada —el «acceso de privilegio»—. El coeficiente k_e fija la intensidad del encarecimiento por escasez.

4.3. Componente de demanda

El multiplicador M_d(t) de la ecuación (3) depende de un índice de demanda D(t) que refleja la presión de compra reciente. Cada compra aporta un impulso β y, entre eventos, el índice revierte exponencialmente hacia una línea base D₀:

Así, las ráfagas de compras elevan la cotización y los periodos de baja demanda la reducen (D puede tomar valores negativos), siempre dentro de [P_min, P_max]. La tasa λ fija la velocidad de reversión, con semivida t_1/2 = ln 2 / λ.

4.4. Parámetros

La Tabla 1 resume los parámetros configurables, quién los fija y valores de ejemplo. El propietario controla los que determinan su política comercial (precio base, suministro, suelo/techo, convexidad y sensibilidad a la demanda); la plataforma fija los que gobiernan la dinámica interna del índice. La Figura 2 ilustra por separado ambas componentes.

5. Propiedades del modelo

De la formulación anterior se derivan las siguientes propiedades, que caracterizan el comportamiento del mecanismo y constituyen criterios verificables de su implementación.

Propiedad 1 (Acotación). Por construcción de (1), la cotización nunca sale del intervalo [P_min, P_max], con independencia de la escasez y la demanda.

Propiedad 2 (Monotonía en escasez). Con emisión finita y demanda constante, M_e(v) es no decreciente en v (pues γ > 0); por tanto la cotización no decrece al aumentar los tokens vendidos.

Propiedad 3 (Reversión de la demanda). En ausencia de nuevas compras, D(t) → D₀ según (5); la componente de demanda revierte hacia su línea base y la cotización «se enfría».

Propiedad 4 (Neutralidad en abundancia). Con suministro ilimitado, M_e = 1 y la cotización depende únicamente de la demanda, siempre dentro de [P_min, P_max].

Propiedad 5 (Determinismo transaccional). El precio se fija en el instante de compra y no se altera retroactivamente: la cotización congelada en un token es independiente de la evolución posterior de C(t).

6. Validación numérica

6.1. Escenarios

La Tabla 2 evalúa la cotización (1) en escenarios representativos con P₀ = 25 €, N = 20, k_e = 1,4, γ = 1,8, k_d = 0,6, P_min = 25 € y P_max = 75 €. Se observa cómo la escasez (v creciente) y la demanda (D) elevan la cotización de forma independiente y combinada, y cómo el techo la acota en el límite superior.

6.2. Trayectoria simulada

Para observar el comportamiento combinado, la Figura 3 simula la trayectoria de la cotización a lo largo de una secuencia de compras que agota el suministro (N = 20) con ráfagas de demanda, usando los mismos parámetros y β = 0,40, λ = ln 2 / 6, D₀ = 0.

La cotización parte del precio base, asciende con cada compra por el doble efecto de escasez y demanda, y se satura en el techo al aproximarse al agotamiento. Tras agotarse el suministro, al no admitirse nuevas compras, la componente de demanda revierte y la cotización desciende, pero se mantiene elevada porque la escasez permanece en su máximo (v = N), estabilizándose en torno a P₀ · M_e(1) = 60 €. La simulación ilustra conjuntamente las Propiedades 1 (acotación), 2 (monotonía en escasez) y 3 (reversión), y es ilustrativa del modelo, no una medición empírica.

7. Realización sobre estándares abiertos

El modelo se implementa sobre las Open APIs de TM Forum que expone el conector FIWARE (componente tmforum-api), reutilizando su modelo de información de catálogo, pedido, inventario, uso y cotización. Esta elección —frente a un motor de precios propietario— preserva la interoperabilidad del marketplace con el ecosistema de espacios de datos.

7.1. Correspondencia de entidades

La Tabla 3 establece la correspondencia entre los conceptos del modelo y los recursos de TM Forum. El algoritmo de la Sección 4 se declara como un pricingLogicAlgorithm (TMF620) asociado al ProductOfferingPrice de la oferta, con sus parámetros; el motor de precios lo evalúa para producir la cotización vigente, que se sirve al consumidor como una Quote (TMF648). La congelación del precio (Propiedad 5) se materializa al referenciar esa Quote desde el ProductOrder.

7.2. Flujo extremo a extremo

El ciclo completo sobre TM Forum se compone de cinco pasos:

1. el productor crea ProductSpecification (dataset), ProductOffering y ProductOfferingPrice con su pricingLogicAlgorithm [TMF620];
2. el consumidor solicita una Quote [TMF648] y obtiene la cotización actual;
3. el consumidor crea un ProductOrder [TMF622] referenciando la Quote, con lo que el precio queda congelado;
4. al completarse el pedido se crea el Product en inventario [TMF637], se registra la identidad del comprador, se genera la factura [TMF678] y el registro inmutable; y
5. en cada acceso, el PEP reporta el consumo como Usage [TMF635]; al superarse un límite, el Product pasa a «terminated» (Agotado).

7.3. Extensiones sobre el estándar

Tres elementos del modelo no son campos nativos de TM Forum y se modelan, sin romper el estándar, mediante características (characteristics) y parámetros: el suministro/escasez (N y su control), el índice de demanda (parámetro dinámico del algoritmo) y el hash de registro inmutable, que se adjunta como característica o nota al ProductOrder/CustomerBill.

8. Discusión y limitaciones

Transparencia y confianza. El carácter dinámico del precio podría generar desconfianza si el consumidor percibiera opacidad. El modelo lo mitiga por diseño: la cotización mostrada coincide con la aplicada, se congela en la compra (Propiedad 5) y se registra de forma inmutable en la clearing house. Esta trazabilidad es condición de aceptación del mecanismo.

Interoperabilidad. Apoyar la monetización en estándares abiertos (TM Forum sobre FIWARE) en lugar de un motor propietario favorece la portabilidad de las ofertas y su integración con otros participantes del espacio de datos, a costa de modelar tres elementos como extensiones controladas del estándar.

Limitaciones. Los parámetros del modelo (k_e, k_d, γ, β, λ) requieren calibración con datos reales de uso, de la que este trabajo no dispone; la validación presentada es analítica y de simulación, no empírica. El mecanismo podría inducir comportamientos estratégicos (p. ej., compras coordinadas para alterar la cotización), cuyo estudio queda pendiente. Finalmente, el modelo no aborda explícitamente objetivos de equidad en el acceso, que podrían entrar en tensión con la señal de escasez.

Trabajo futuro. Se contempla la calibración empírica de los parámetros con tráfico real, el diseño de salvaguardas frente al comportamiento estratégico, la exploración de esquemas de subasta como alternativa a la cotización continua y el análisis de bienestar del mecanismo.

9. Conclusiones

Se ha presentado un modelo de acceso tokenizado con cotización dinámica para marketplaces de espacios de datos que supera el patrón de catálogo estático dotando al precio de una señal de escasez y de demanda, acotada y transparente. El modelo se ha formalizado, se han demostrado sus propiedades y se ha validado mediante escenarios numéricos y una simulación de su trayectoria. Su realización sobre las Open APIs de TM Forum dentro del conector FIWARE y la arquitectura IDS-RAM garantiza la interoperabilidad frente a un mecanismo propietario, situando la capa económica del marketplace al mismo nivel de estandarización que las capas de conexión e identidad. El modelo se ha desarrollado en el marco del proyecto dataspace.es.

Financiación

Este trabajo forma parte del proyecto «Plataforma dataspace.es» (expediente TSI-100130-2024-31), financiado por la Secretaría de Estado de Digitalización e Inteligencia Artificial del Ministerio para la Transformación Digital y de la Función Pública, en el marco del Programa de Productos y Servicios Tecnológicos para Espacios de Datos, y financiado por la Unión Europea – NextGenerationEU a través del Plan de Recuperación, Transformación y Resiliencia.

Financiado por la Unión Europea – NextGenerationEU. Sin embargo, los puntos de vista y las opiniones expresadas son únicamente los del autor o autores y no reflejan necesariamente los de la Unión Europea o la Comisión Europea. Ni la Unión Europea ni la Comisión Europea pueden ser consideradas responsables de las mismas.

Publicidad de la financiación:

Referencias

1. Comisión Europea, Una Estrategia Europea de Datos, COM(2020) 66 final, 2020.
2. Reglamento (UE) 2022/868 relativo a la gobernanza europea de datos (Data Governance Act), 2022.
3. Reglamento (UE) 2023/2854 sobre normas armonizadas para un acceso justo a los datos y su utilización (Data Act), 2023.
4. International Data Spaces Association, IDS Reference Architecture Model (IDS-RAM), versión 4, 2023.
5. Gaia-X European Association for Data and Cloud AISBL, Gaia-X Architecture Document, 2023.
6. International Data Spaces Association, Dataspace Protocol, especificación técnica, 2024.
7. FIWARE Foundation, FIWARE Data Space Connector, documentación técnica, 2024.
8. TM Forum, Open API Suite (TMF620 Product Catalog, TMF622 Product Ordering, TMF637 Product Inventory, TMF635 Usage Management, TMF648 Quote, TMF651 Agreement, TMF666 Account, TMF632 Party, TMF678 Customer Bill), 2023.
9. Reglamento (UE) 2024/1183 por el que se establece el Marco Europeo de Identidad Digital (eIDAS 2.0), 2024.
10. UNE 0081:2023, Evaluación de la calidad del dato, AENOR, 2023.