--- id: 10 title: "Derechos sobre activos de IA: convertir datos, modelos e ingresos en reglas ejecutables" slug: ai-data-ownership date: 2026/08/19 summary: Por qué los aportantes de datos, modelos y cómputo rara vez reciben pagos automáticos en la IA —y qué resuelven y qué no resuelven los índices de metadatos en cadena, el particionado por umbral, la auditoría asistida por TEE y los repartos por contrato inteligente—, además de cómo los derechos se apoyan en la liquidación y la computación confiable. keywords: derechos sobre activos de IA,propiedad de datos,activos de modelo,particionado por umbral,Bitroot heroImage: /images/community-bg.png --- Una muestra de entrenamiento, un archivo de pesos, una llamada de inferencia: ¿a quién le corresponde el pago? Las plataformas tradicionales responden con su propio libro contable y un acuerdo en papel; los aportantes no pueden verificar ni hacer cumplir esas condiciones con facilidad. La ausencia de derechos es, antes que nada, una brecha de ingeniería e institucional, no una brecha de eslóganes. Este artículo describe mecanismos que vuelven ejecutables los derechos y cómo los diseños asociados a Bitroot se apoyan en la liquidación y la computación confiable. ## Tres libros contables poco transparentes **Datos**: una vez entregados a una plataforma, los aportantes a menudo no pueden probar qué modelos usaron sus muestras, y menos aún reclamar una parte cuando esos modelos generan ingresos. Los datos se vuelven materia prima desechable en lugar de un activo rastreable. **Modelos**: los parámetros y la estructura son activos digitales sin derechos, licencias y medición de llamadas en común. Cuando los pesos viven en un solo lugar, los terceros no pueden comprobar de forma independiente los recuentos de llamadas ni los ingresos; los diseñadores aceptan la hoja de liquidación de la plataforma. **Ingresos**: incluso las plataformas dispuestas a pagar siguen dependiendo de auditorías manuales y contratos fuera de línea, lentos y propensos a disputas. Las partes de datos, modelos y cómputo carecen de una máquina de estados de pago compartida que se ejecute tal como se escribió. Pasar “a la cadena” no borra estas brechas por sí solo; la cadena únicamente aporta un entorno de ejecución programable y auditable. Para el mapa de brechas de confianza, véase [Convergencia de Web3 y la IA](/es/blog/web3-ai-convergence). ## De los libros de la plataforma a un flujo verificable El diagrama contrasta la contabilidad unilateral de la plataforma con la intuición de un flujo de valor basado en índice + criptografía + contrato (ilustrativo, no una promesa financiera): ![Comparación de flujo de valor: contabilidad de plataforma frente a repartos ejecutables en cadena](/images/articles/ai-data-ownership/value-flow-en.svg) ### Metadatos en cadena, no todo el corpus Un enfoque sensato registra en cadena los hashes de archivo, las versiones, los tamaños y los resúmenes de diferencias; las cargas útiles permanecen en almacenamiento descentralizado o de objetos, con entrega por fragmentos y verificaciones de Merkle para la integridad de la descarga. Cualquiera puede verificar que los fragmentos recuperados coinciden con el registro; la cadena no necesita alojar los corpus sin procesar. Eso no es lo mismo que “acuñar el conjunto de datos como una imagen”. ### Control de acceso: claves por umbral + auditoría opcional con TEE Los datos y modelos comerciales necesitan control de acceso. El cifrado por umbral y el MPC dividen las claves de modo que descifrar o firmar exige un quórum, lo que reduce el riesgo de robo en un solo nodo. Los cambios de acceso y autorización deberían dejar registros en cadena; los fragmentos sensibles pueden ejecutarse dentro de TEE para una auditoría de uso acotada por hardware, aceptando el riesgo de canales laterales y de cadena de suministro. División del trabajo: [Marco de computación confiable](/es/blog/trusted-computing-framework). ### Pesos del modelo: utilizables sin ser apropiables Un problema difícil de los activos de modelo es permitir que los nodos sirvan inferencias sin entregar los pesos completos a una sola contraparte. Una vía de ingeniería es el particionado por umbral (t, n): cualesquiera t fragmentos pueden contribuir a agregar un resultado de inferencia; con menos de t no se obtienen pesos utilizables. Los nodos calculan sobre sus fragmentos locales, agregan mediante MPC y pueden adjuntar restricciones ZK para comprobar la integridad de la salida. ![Particionado por umbral de los pesos del modelo con agregación multiparte](/images/articles/ai-data-ownership/threshold-sharding-en.svg) Los derechos de uso y la propiedad plena pueden separarse técnicamente; el derecho de autor y las licencias legales siguen necesitando contratos y jurisdicciones: las reglas en cadena no reemplazan todos los estatutos de propiedad intelectual. ### Repartos por contrato inteligente: participaciones como máquina de estados Cuando las llamadas generan ingresos, los contratos disparan pagos a partir de participaciones registradas de antemano: aportantes de datos, diseñadores de modelos y proveedores de cómputo tienen cada uno sus proporciones en cadena; toda liquidación es auditable. Eso responde si las reglas se ejecutan, no si las proporciones son justas (eso sigue siendo gobernanza y negociación). El inicio de sesión social y las claves de sesión por umbral bajan la barrera de experiencia con claves privadas, pero exponen la custodia y la recuperación al conjunto de participantes de MPC; conviene explicitar ese modelo de amenazas. ## Cómo se articula con la liquidación y el cómputo Los derechos y las máquinas de pago necesitan confirmación predecible y suficiente rendimiento, sobre todo para la facturación de inferencias de alta frecuencia y los repartos entre varios contratos. Cuando el sustrato de liquidación es una EVM paralela optimista, conviene leer las cifras de rendimiento como objetivos de testnet o de ingeniería y observar si los hotspots de conflicto hacen colapsar el paralelismo: véanse [Panorama de la arquitectura de EVM paralela](/es/blog/bitrootevm) y [Glosario de métricas de rendimiento](/es/blog/performance-metrics-glossary). Interfaces de aceptación de trabajos y pago: [Cómputo distribuido con GPU y en el borde](/es/blog/gpuai). Límites de capacidad: [Cadena de bloques nativa de IA](/es/blog/ai-native-blockchain). Este artículo no analiza ni implica ningún rendimiento ni retorno de inversión. ## Tres trampas de diseño frecuentes La propiedad meramente exhibida, sin transiciones de revocación o reparto; la medición no impugnable que recentraliza la facturación; ignorar la herencia de versión o licencia en los ajustes finos y la destilación. Un MVP más estable: registro de hashes + repartos simples por llamada + licencias revocables, con disputas que funcionen antes de esquemas de umbral complejos. Conviene mantener la conversación sobre mecanismos separada de la imaginación sobre rendimientos. Si la liquidación resiste repartos de micropagos: [Diseño de ejecución paralela multi-motor](/es/blog/bitroot-evm). Entre jurisdicciones, las reglas en cadena ofrecen, en el mejor de los casos, “programas de ejecución automática que las partes acordaron”; no eliminan la copia fuera de la plataforma ni deciden si un corpus de entrenamiento infringe derechos. La documentación debería indicar qué garantiza el sistema (hashes, eventos de licencia, ejecución de repartos) y qué no (titularidad global de derechos de autor, niveles de rendimiento). Protección de acceso: [Marco de computación confiable](/es/blog/trusted-computing-framework); brechas de confianza: [Convergencia Web3–IA](/es/blog/web3-ai-convergence). Si los repartos implican muchos pagos diminutos de alta frecuencia, conviene evaluar también la abstracción de cuentas, la liquidación por lotes o los canales fuera de cadena, para que el gas y la variabilidad de confirmación no se coman el reparto mismo. Son decisiones de arquitectura de aplicación sobre la capacidad de liquidación, no razones para que un L1 subsidie cada reparto. Esto no es asesoramiento de inversión ni de rendimiento. ## Medición, revocación y disputas: la otra mitad de los derechos El registro de hashes es solo el comienzo. Los derechos ejecutables también necesitan medición a prueba de doble conteo, detención de la facturación cuando la licencia vence o se incumple, multifirma o gobernanza para cambiar participaciones, y la capacidad de congelar flujos durante disputas de derechos de autor sin destruir las pistas de auditoría. Sin esas máquinas de estados, los índices en cadena son claves primarias caras. Al conectarse con redes de cómputo, la aceptación no debe equivaler automáticamente a “pagable”: quien llama sigue necesitando una licencia válida. Los micropagos divididos de alta frecuencia sobre una capa de liquidación paralela amplifican el gas y la superficie de conflicto; puede ser necesaria una agregación fuera de cadena con compromisos de detalle impugnables. Conflictos: [Hotspots de conflicto y cargas de trabajo](/es/blog/parallel-evm-workload-hotspots). Lugar en la pila: [La pila de IA descentralizada](/es/blog/aibitrootweb3ai). ## Tensión entre privacidad y auditoría pública Los derechos quieren auditabilidad; los datos comerciales quieren confidencialidad. El particionado por umbral y los TEE ayudan, pero no pueden ofrecer al mismo tiempo “que cualquiera verifique cada inferencia” y “que los pesos nunca salgan de un conjunto confiable” a un costo cercano a cero. Los productos deben elegir un público principal: auditoría regulatoria, verificación de pagos a aportantes o inferencia verificable públicamente, cada uno con una curva de costos distinta. Conviene evitar sugerir a la vez privacidad total, verificabilidad pública total y costo cercano a cero. Una estratificación honesta: medición y repartos en cadena; detalles autorizados fuera de cadena; evidencia mínima en caso de disputa. Roles de la computación confiable: [Marco de computación confiable](/es/blog/trusted-computing-framework). ## Conclusiones Los derechos ejecutables necesitan metadatos verificables, claves y pesos por umbral, acceso auditable y contratos de pago automático, todo ello estratificado con computación confiable y liquidación. Trasladan la pregunta “quién aportó qué y bajo qué regla” de la caja negra de una plataforma a una máquina de estados verificable. No resuelven automáticamente las disputas de derechos de autor ni convierten las redes de cómputo en productos de rendimiento. Al leer materiales relacionados, conviene priorizar los modelos de amenazas y los flujos de aceptación. ## Lecturas relacionadas - [Convergencia de Web3 y la IA](/es/blog/web3-ai-convergence) - [Marco de computación confiable](/es/blog/trusted-computing-framework) - [La pila de IA descentralizada](/es/blog/aibitrootweb3ai)