一家唱片公司為歐盟《AI 法案》用 C2PA 替目錄打標。我看著一次轉碼把它全部剝光。

第一次我把自家測試曲目推過一次普通的社群轉碼時，眼看著唱片公司原本會花錢加上的 C2PA 來源證明，在單次處理中消失了。畫面上沒有任何戲劇性的事發生。檔案帶著已簽署的來源證明標頭進去，編碼器做完它平常的工作，檔案出來時乾淨、更輕、也被剝光了。來源證明就這樣沒了——就像任何真實曲目一碰到 TikTok 或 Instagram 就會發生的那樣。我坐在那裡覺得有點反胃，因為我把整套示範建立在「加上 C2PA 就是答案」的假設上，而我剛看著那個答案蒸發了。

這篇短文要談的就是這件事。我著手打造一套歐盟《AI 法案》第 50 條的 AI 生成音訊匯入閘道，這個應用程式稱之為 Tessera，而這次打造悄悄拆解了音樂權利圈幾乎人人帶著進來的那個假設。那個假設是：第 50 條是一個浮水印問題，靠替目錄打標就能解決。並不是。它是一個 存活問題，而產業正忙著加上去的多數東西根本撐不住。若你想親眼看閘道自行裁決，它在這裡： veriprajna.com/zh-Hant/demos/ai-audio-licensing-provenance。

我一開始的反射動作是「直接加 C2PA」

我開始這次打造時，信的是我讀過的每一份權利科技簡報都相信的同一件事：第 50 條合規是一場標籤作業。

法規是真的，時鐘也是真的。歐盟《AI 法案》第 50 條於 2026 年 8 月 2 日生效，要求生成式音訊產出必須以機器可讀格式標記，並在執委會 2026 年 1 月《行為準則》草案的用語中，於「常見修改之後」仍可被偵測。第 99 條給出牙齒，罰則最高可達 1,500 萬歐元或全球營業額的 3%。其下的規模也不小。Deezer 每日上傳中約有 28% 如今已是完全由 AI 生成（Beatdapp/Beatport，引自 Veriprajna WP31 研究，2026）。所以自然的一步——也是我第一版管線草圖裡採取的一步——就是替每一首 AI 曲目掛上 C2PA 資訊清單，然後宣稱目錄已涵蓋。

以下是我直到親眼看見才真正內化的失敗。C2PA，就多數人部署它的方式而言，是 硬綁定。來源證明住在檔案的中繼資料裡。而硬綁定幾乎會被每一次社群平台上傳時的轉碼剝除，Veriprajna WP31 解決方案研究（2026）稱之為當今 C2PA 生態系最大的單一營運弱點。所以一家勤奮替整個目錄打標的唱片公司，在營運上，曲目一離開乾淨交接、進入野外的瞬間，就變成未涵蓋。

唱片公司做了指引所說的一切。它加了 C2PA。而第一首曲目一碰到社群，它就變成未涵蓋——因為它加上去的那一部分，正是會被剝除的那一部分。

真正能存活的是 軟綁定。難以察覺的浮水印攜帶一個微小識別碼，中繼資料消失之後，你用那個識別碼從帳本重新解析資訊清單。這是不起眼的整合工程。就我所見，這也是整場比賽的全部。

那個晚上，我自己的浮水印回來時成了垃圾

在一個週二的晚上，當我自己的浮水印解碼器開始回傳雜訊時，我幾乎要放棄軟綁定。

我當時已經把管線從頭到尾跑起來了。一首曲目走過交付通道，擴頻解碼器從交付後的波形讀回標記，還原出的金鑰查詢資訊清單。接著我重跑了一批前一天已通過的批次，還原出的金鑰卻回來成了垃圾。浮水印上的位元錯誤率約在 0.5，那是擲硬幣的水準，是解碼器在告訴你它讀到的是靜電。我第一個想法是軟綁定其實行不通，標記撐不過真實編解碼器，而整套示範的前提都錯了。

我花了幾個小時確信這條路已經死了。死的不是方法。是 過期的磁碟語料庫。較早的快取已與曲目生成所用的確定性種子失同步，所以解碼器讀到的標記不再匹配音訊。我從種子重建語料庫，用真實的 ffmpeg 轉碼重跑一切，金鑰又乾淨回來了。那場失敗對我比任何一次乾淨跑通都更有價值，因為它教會我不信任一個漂亮的數字，直到我確切知道它是怎麼產出的。這個示範裡的每一項基準，都是在那次重建之後才記錄的。

當它奏效時，那個對比是我放上螢幕過最清楚的東西。以 Neon Tide 為例——一首經由社群通道交付的內部合成 AI 發行（這批語料中的每一首都是程序生成的音調，沒有真實音樂或藝人，名稱都是固定夾具）。它的硬綁定被轉碼剝除。它的軟綁定浮水印以信心值 0.989 還原，C2PA 資訊清單從帳本重新解析。 硬綁定死了。軟綁定把來源證明帶過關了。 並排、同一首曲目、同一趟處理。那一塊面板就是論點。

那麼我只是做出了更好的浮水印嗎？

幾乎每次對話我都會聽到某種版本的這個問題，而答案是否定的——這往往讓人意外。

我並沒有打造一個意在擊敗任何人的浮水印，我也小心這樣說，因為暗示相反意思的誘惑很強。市場領先的偵測器——Google 的 SynthID-Audio、Meta 的 AudioSeal、Digimarc——在這個示範裡以 樁適配器 的形式坐在已文件化的可換成 SDK 介面背後。SynthID 的偵測器由 Google 封閉，AudioSeal 需要 GPU，所以在示範裡它們只以固定信心值回報是否存在，僅此而已。我確實寫下的擴頻標記只為一個工作存在：攜帶 32 位元資產金鑰與 CRC，好讓資訊清單能被重新解析。它沒有參加任何穩健性競賽，我也沒有聲稱它擊敗任何供應商。

我打造的是圍繞演算法的那一層。Google 與 Meta 可以擁有浮水印。沒有人當成單一產品出貨的部分是整合：多標準偵測器、軟綁定架構、DDEX 中介軟體，以及監管就緒的卷宗。 真正解決存活問題的地方，就是那一層，而那正是沒有任何單一供應商急著交到你手上的部分。

我想精確說明那張存活矩陣意味著什麼，因為誠實的範圍正是以 Veriprajna（意為真智慧）為名的公司打造東西的全部重點。在固定的 12 首合成發行語料上，我的標記經 mp3-128、aac-128 與 opus-96 重新編碼後，以位元錯誤率 0.0 重新解碼，而硬綁定在那些社群通道中一個也撐不住。那是用真實 ffmpeg 做出的真實量測。它不是一個放諸四海皆準的「什麼都撐得住」主張，而示範本身就包含一首標記完全撐不住的曲目——那正是我最自豪的部分。

我並沒有打造更好的浮水印。我打造的是那一層：它決定你仍握有的來源證明是否足以認證，並在不足時拒絕。

我很想放行的那首曲目

我記得盯著 Radio Imaging Sweep 7，很想讓它通過——而那就是整套示範贏得其名字的瞬間。

那是一段廣播剪輯，經由我建模為 類比缺口 的路徑抵達——從 FM 監聽器做喇叭到麥克風的再擷取。它的標記沒有撐過那條路徑。解碼器以信心值 0.699 讀回，CRC 失敗，沒有可還原的識別碼可用來解析資訊清單。誘惑就坐在螢幕上。存活矩陣在乾淨母帶上跑過社群編解碼器時顯示，標記會撐過正常轉碼。所以我能看見一種邏輯版本說：標記基本上沒問題，這只是壞通道，放行吧。第 99 條殺了那個本能。在最高 1,500 萬歐元或 3% 罰則體制下，一個虛假的「合規」是昂貴的那種錯。

所以閘道做了更難的事。當標記確實沒有撐過曲目實際走過的通道時，它回傳 NEEDS PROOF，並把曲目導向人工，附上類比缺口失敗與具名負責人。它不認證。我把這寫成單元測試不變式——測試名稱字面就是浮水印死在類比缺口——因為我希望棄權成為系統的屬性，而不是一種心情。 棄權不是閘道失敗。棄權是閘道拒絕虛張聲勢，而拒絕虛張聲勢，才是信任與安全主管真正買下的東西。

在第 99 條罰則下，一個虛假的「合規」不是小錯。它是昂貴的那種錯——這正是閘道被建造成寧可棄權也不虛張聲勢的原因。

還原出的浮水印還不夠嗎？

我早期假設，還原浮水印基本上就是終點線，而 Glasshouse 是糾正我的那首曲目。

Glasshouse 乾淨地還原了標記，信心值 0.992，三種編解碼器的位元錯誤率皆為 0.0。就狹義而言，來源證明完美。而閘道還是擋下了它。原因在鏈條的其餘部分。DDEX ERN 4.3 沒有 AI 揭露欄位，多數聚合商（CD Baby、DistroKid、Believe）也不傳遞細粒度揭露，依 Veriprajna WP31 研究（2026）。Glasshouse 經 DistroKid 抵達時，四個揭露欄位缺了三個：配器、混音與母帶。在第 50(4) 條下，原樣出貨會構成主動揭露違規，所以裁決是 BLOCKED，畫面上引用的正是該條款。

這就是為什麼閘道檢查的是 整條鏈，而不只是標記：機器可讀標記，加上交付通道後的軟綁定還原，加上完整的 DDEX 揭露，加上具名的下架負責人。缺任何一環就得不到綠燈。在完整的 12 首發行批次中，結果是 7 首認證為 COMPLIANT、2 首導向人工補救、3 首被擋下，而 12 首每一首都帶著引用條款的裁決。那種覆蓋正是我在意的部分，因為權利科技主管不會資助黑箱——他們資助的是能被交叉詰問的東西（「為什麼 Glasshouse 被擋？第 50(4) 條，三個 DDEX 欄位缺失」）。

而具有法律重量的決策刻意是確定性的。浮水印還原、存活量測、軟綁定查詢，以及第 50 條通過／失敗，都是坐在語言模型之外的普通程式碼。系統裡有代理——一個從自由文字抽取揭露欄位，一個對每次認證做對抗攻擊——但它們只建議。它們不做決定，整套以無金鑰的確定性備援運行，所以無論有沒有 LLM，閘道的數字都相同。 代理建議，程式碼決定。

我也該同樣清楚這不是什麼，因為品牌撐不住過度宣稱。資訊清單是 SQLite 帳本裡的 JSON C2PA 替身，不是密碼學簽署的 C2PA 2.0。DSP 與聚合商連接器是模擬。發行是合成音調，不是真實錄音，而工具支援一個第 50 條答案，它並不交給任何人法律認證。真實的是機制：還原、存活量測、全鏈閘道，以及它匯出的卷宗。

還原的浮水印告訴我來源證明完整。監管機關仍然在意揭露是否完整、以及誰擁有下架權。那些是不同的問題，閘道必須全部問到。

在我讓任何東西通過認證之前，我會問的問題

我發現打造這套東西在我身上改變的，是一件比宏大論點更小的事，而那件更小的事留得更久。

我不再問一首 AI 曲目是否擁有來源證明，因為我通常答得出來，而結果證明那還不夠。Neon Tide 有來源證明，Glasshouse 也有，一首通過認證，另一首被擋。我現在在任何東西以 COMPLIANT 離開閘道之前會問的是：我能否證明來源證明撐過了這首曲目實際走過的特定通道，鏈條上每一環是否都站得住，以及當站不住時，我是否寧願棄權也不願猜測。

那不是更好的浮水印能回答的問題。隨著 Google 與 Meta 的模型改進——它們會改進——價值並不會移到演算法上，因為它們已經擁有演算法。價值留在讓來源證明撐過真實世界的整合層，以及即使軟綁定失敗也說出 NEEDS PROOF 的紀律。這次打造中耐久的部分，不是下次 SynthID 變強就會過時的穩健性分數。它是存活量測、全鏈閘道，以及誠實不變式——這些都不會因為浮水印變好而變得更容易或更難。若你想看我落腳何處，閘道再一次在這裡： veriprajna.com/zh-Hant/demos/ai-audio-licensing-provenance。

而若你寧可看它運行，也不想讀我描述，這裡是整套閘道從頭到尾跑完。

所以我想留給你的問題，就是 8 月 2 日大限正靜靜問每一家唱片公司的那個問題。你加上了標記。你能證明它撐過了這趟旅程嗎？因為在單次社群轉碼的另一端，你指望的那個標籤已經沒了，而唯一能認證的，是你為了還原剩下的東西所打造的那一套。