---
id: 10
title: AI 資產確權：資料、模型與收益如何變成可執行規則
slug: ai-data-ownership
date: 2026/08/19
summary: 拆解 AI 產業裡資料、模型與算力貢獻難以自動分帳的原因，以及鏈上中繼資料索引、門限分片、可信執行稽核與智慧合約分帳各自解決什麼、不解決什麼；並說明確權層與結算層、可信運算的邊界。
keywords: AI資產確權,資料所有權,模型資產化,門限分片,Bitroot
heroImage: /images/community-bg.png
---

一段訓練資料、一組模型權重、一次推論呼叫，各自該分給誰？傳統平台用自己的帳本和一紙協議回答；貢獻者既難核實，也難強制執行。確權缺失首先是工程與制度缺口，不是道德口號的缺口。本文說明可執行的確權通常需要哪些機制，以及 Bitroot 的相關設計如何落在結算與可信運算之上。

## 三筆說不清的帳

**資料**：一旦交給平台，貢獻者往往無法證明「這份資料被哪些模型用過」，更難在模型產生收入後主張分成。資料被當成一次性的原材料，而不是可追蹤的資產。

**模型**：參數與結構是數位資產，卻缺少通用的確權、授權與呼叫計量。權重集中存放時，外部無法獨立核驗呼叫次數與收益；設計者只能接受平台的結算單。

**收益**：即便平台願意分錢，落地仍依賴人工稽核與線下協議，週期長、爭議多。資料方、模型方、算力方之間缺少一套按約定自動執行的分帳狀態機。

這些問題不會因為「上了鏈」就自動消失；鏈只提供可程式化、可稽核的執行環境。信任缺口總覽見 [《Web3 與 AI 融合》](/zh-Hant/blog/web3-ai-convergence)。

## 從平台記帳到可驗證鏈路

下圖對比「平台單方記帳」與「索引 + 密碼學 + 合約」兩種價值流的直覺（示意，非財務承諾）：

![傳統模式與鏈上可執行分帳的價值流對比](/images/articles/ai-data-ownership/value-flow-zh.svg)

### 鏈上中繼資料，而不是整庫上鏈

合理的做法是把檔案雜湊、版本、大小、差分摘要寫入鏈上索引；資料本體放在去中心化或物件儲存，用分片分發與 Merkle 校驗保證下載的完整性。任何人都可以核對「拿到的分片是否與登記相符」，鏈不必承載原始語料。這與「把資料集鑄成一張圖」不是同一件事。

### 存取控制：門限金鑰 + 可選 TEE 稽核

商業資料與模型需要存取控制。門限加密 / MPC 把金鑰拆成多份，湊夠門限才能解密或簽章，降低單節點竊取的風險面。存取與授權變更應留下鏈上記錄；敏感切片可放入 TEE 做硬體邊界內的使用稽核，並接受側通道與供應鏈風險——分工見 [《可信運算框架》](/zh-Hant/blog/trusted-computing-framework)。

### 模型權重：能用，不等於能拿走

模型資產化的難點之一，是讓節點參與推論的同時，避免完整權重落在單一對手方手上。一種工程路徑是 (t, n) 門限分片：任意 t 份可參與聚合成推論結果，少於 t 份得不到可用的權重；節點只計算本地分片，經 MPC 聚合，並可附帶 ZK 約束來驗收輸出的完整性。

![模型權重門限分片與多方聚合示意](/images/articles/ai-data-ownership/threshold-sharding-zh.svg)

使用權與完整所有權在技術上可以被拆開；法律意義上的著作權與授權仍需合約與司法管轄，鏈上規則不能替代所有法域的著作權法。

### 智慧合約分帳：把份額寫成狀態機

呼叫產生收入時，合約按預先登記的份額觸發分帳：資料貢獻者、模型設計者、算力提供者各自的比率寫在鏈上，每次結算都可稽核。這解決的是「規則是否執行」，不是「比率是否公平」——後者仍是治理與談判問題。

社群登入 / 門限工作階段金鑰等體驗層設計，降低了普通使用者管理私鑰的門檻，但也把金鑰託管與恢復策略暴露給 MPC 參與方集合；威脅模型要單獨寫清楚。

## 和結算層、算力層怎麼接

確權與分帳狀態機需要可預期的確認與足夠的吞吐量，尤其是高頻推論計費與多合約分成。樂觀平行 EVM 作為結算基板時，應把效能數字讀成測試網/工程目標，並關注衝突熱點是否擊穿平行度，見 [《平行 EVM 架構概覽》](/zh-Hant/blog/bitrootevm)、[《效能指標術語表》](/zh-Hant/blog/performance-metrics-glossary)。算力任務的驗收與支付介面見 [《分散式 GPU 與邊緣算力》](/zh-Hant/blog/gpuai)；AI 原生能力的邊界見 [《AI 原生區塊鏈》](/zh-Hant/blog/ai-native-blockchain)。

本文不討論、也不暗示任何收益率或投資報酬。

## 設計時常見的三個坑

一是把所有權做成展示層，沒有停權與分帳的遷移機制；二是計量事件不可挑戰，計費重新中心化；三是忽視微調/蒸餾等衍生作品的版本與授權繼承。更穩妥的 MVP：雜湊登記 + 簡單的按次分帳 + 可撤銷授權，先跑通爭議，再上複雜的門限方案。全程保持機制說明與收益想像的分離。執行層能否撐住小額高頻分帳，見 [《多引擎平行執行設計》](/zh-Hant/blog/bitroot-evm)。

跨法域時，鏈上規則最多提供「各方事先同意的自動執行程序」；它不能消滅平台外的複製，也不能自動裁決訓練語料是否侵權。技術團隊應在文件中寫清楚：本系統保證什麼（雜湊、授權事件、分帳執行），不保證什麼（全球著作權歸屬、收益水準）。可信運算如何保護存取路徑見 [《可信運算框架》](/zh-Hant/blog/trusted-computing-framework)；信任缺口總覽見 [《Web3 與 AI 融合》](/zh-Hant/blog/web3-ai-convergence)。

若分帳涉及多人小額高頻支付，還要評估帳戶抽象、批次結算或離線通道等體驗層方案，以免 gas 與確認的抖動吞噬分成本身。這些屬於應用架構的選擇，應建立在結算層能力之上，而不是反過來要求公鏈為每筆分帳做特殊補貼。本文不構成投資或收益建議。

## 計量、撤銷與爭議：確權的後半段

登記雜湊只是開始。可執行的確權還需要：按次/按量的計量如何防止重複計數；授權到期或違約時如何停止計費；分帳比率變更的多簽或治理流程；以及出現著作權爭議時，合約能否凍結流向而不銷毀稽核軌跡。缺少這些狀態機，鏈上索引只是更貴的資料庫主鍵。

與算力網路銜接時，驗收通過不應自動等於「可分帳」——還需核對呼叫方是否持有有效授權。與平行結算層銜接時，高頻小額分帳會放大 gas 與衝突面，可能需要鏈下聚合後再上鏈結算，同時保留可挑戰的明細承諾。效能與衝突見 [《平行 EVM 工作負載熱點》](/zh-Hant/blog/parallel-evm-workload-hotspots)；堆疊位置見 [《去中心化 AI 堆疊》](/zh-Hant/blog/aibitrootweb3ai)。

## 隱私與公開稽核的張力

確權要求可稽核，商業資料又要求機密。門限分片與 TEE 是常見的緩解方式，但無法同時滿足「全世界都能隨意驗證每一次推論」與「權重絕不離開受信集合」。產品必須選擇主要受眾：監管可稽核、貢獻者可核驗分成，或公開可驗證推論——三者的成本曲線不同。

公開資料應避免暗示「既完全隱私又完全公開可驗證，而且幾乎零成本」。更誠實的表述是分層披露：鏈上可見計量與分成，鏈下可見經授權的明細，爭議時提交最小必要的證據。可信運算分工見 [《可信運算框架》](/zh-Hant/blog/trusted-computing-framework)。

## 小結

可執行的確權，依賴可核對的中繼資料、可門限的金鑰與權重、可稽核的存取，以及自動分帳合約——再疊加上可信運算與結算層。它把「誰貢獻了什麼、按什麼規則分」從平台黑箱挪到可驗證的狀態機；它不會自動解決著作權爭議，也不會把算力網路變成理財產品。讀相關材料時，優先核對威脅模型與驗收流程。

## 延伸閱讀

- [《Web3 與 AI 融合：信任缺口》](/zh-Hant/blog/web3-ai-convergence)
- [《可信運算框架》](/zh-Hant/blog/trusted-computing-framework)
- [《去中心化 AI 堆疊》](/zh-Hant/blog/aibitrootweb3ai)