「AI浮水印」到底是什麼意思——為什麼它比聽起來難得多
歐盟人工智慧法(EU AI Act)要求提供者以「機器可讀……可辨識為人工生成」的格式標記生成內容,但法條刻意不規定該用什麼方法。法律定義的是一項要求,而非一種技術。實務上,這項要求由少數幾套已研發多年、真正落地的技術系統來滿足,每一套都有實際能力,也都有一套有完整文件記載、特有的失效方式。目前主流的做法有兩種:一種是像C2PA的Content Credentials這樣以密碼學簽章的中繼資料標準,另一種是像Google DeepMind的SynthID那樣直接嵌入像素或文字中、肉眼看不見的訊號。了解這兩種方法實際如何運作——更重要的是,它們各自會如何失效——才能分辨「已加浮水印」這個標籤究竟只是聽起來持久,還是真的知道它能承諾什麼、不能承諾什麼。
被稱為「浮水印」的兩種截然不同的東西
這個詞被用得很鬆散,但兩種主流做法解決問題的方式幾乎是相反的。C2PA的Content Credentials會附上一份簽章紀錄——誰製作了這則內容、用了什麼工具、之後又經過哪些編輯——以獨立資料包的形式隨檔案一起傳遞。像SynthID這類統計式浮水印則完全不附加任何獨立的東西;它們在生成的當下直接擾動實際的像素值,或是文字生成時token選擇的機率分布,使得這個「標記」與內容本身無法分離。前者比較接近釘在文件上的公證證書,後者則更像織進紙張纖維裡的簽名。兩者都被稱為浮水印,但除此之外幾乎沒有共同點,連失效的方式都截然不同。
Content Credential實際上是怎麼附加上去的
C2PA(Coalition for Content Provenance and Authenticity,由超過6,000個會員組織支持,包括Adobe、Google、Microsoft、Amazon、Meta、Sony、BBC、OpenAI與Truepic)定義了一套三階段的流程。「聲明產生器(claim generator)」——可能是軟體也可能是硬體——會彙整一組關於內容的斷言(assertion):拍攝裝置、使用過的編輯工具,以及它所承襲的先前資訊清單(manifest)。這些斷言組成一份「聲明(claim)」,以COSE格式用建立者的私鑰簽署,並由受信任憑證機構核發的X.509數位憑證背書。簽署後的整個包——資訊清單——會被封裝進JUMBF容器並嵌入檔案中,成為消費者品牌所稱的Content Credential:也就是你可能在圖片角落見過的小型「cr」圖示,點開後會顯示一個面板,告訴你內容何時製作、經過哪些編輯、由誰簽署。關鍵在於,這條鏈的設計目的是要撐過合法的編輯——如果一套相容工具開啟一張已附有Content Credential的圖片、加以編輯後再重新簽署,新的資訊清單可以參照先前那一份,建立起一段可稽核的歷史,而不是把它抹除。
問題所在:資訊清單活在檔案裡,而不是照片裡
C2PA提供兩種方式將資訊清單綁定到內容資產上,而較強的那一種也恰好比較脆弱。「硬綁定(hard binding)」是對檔案確切位元組序列做的密碼學雜湊;只要有一個位元組改變——重新壓縮、調整尺寸、以不同格式另存——雜湊值就不再相符,驗證就會失敗。這是刻意的設計,目的是標記出遭到竄改的跡象。但這也意味著,平台為了節省頻寬而重新編碼上傳檔案、應用程式以較低品質另存新檔,這類完全無害、再平常不過的檔案處理,一樣能像惡意編輯那樣破壞這個綁定。「軟綁定(soft binding)」不是根據原始位元組,而是根據內容的感知指紋(perceptual fingerprint)推導而來,因此更耐用,即使嵌入的副本被移除,也能透過查詢服務重新找回資訊清單——但這種保證比較弱,而且仰賴這套查詢基礎設施確實存在、也確實被查詢。此外還有一種完全不需要任何編輯工具的失效方式:截圖。截圖不會複製檔案的位元組,也不會複製其中嵌入的JUMBF容器——它是透過作業系統的圖形堆疊重新算繪像素,產生一張全新的圖片,對原始檔案的中繼資料毫無記憶可言。再加上各大平台早已行之有年的慣例,基於隱私與頻寬考量(這些理由遠早於這整套技術而存在),預設會在上傳時剝除EXIF與XMP中繼資料——這樣一來,以容器為基礎的憑證有好幾種完全尋常的方式會憑空消失,根本不需要任何人刻意隱藏什麼。
把訊號直接烙進內容本身
第二種做法之所以存在,正是為了撐過讓第一種做法失效的那些情況。SynthID與同類系統會在圖片或影片生成過程中,把人眼無法察覺的統計訊號直接嵌入像素值裡;或是在文字生成過程中,嵌入token選擇的機率分布——不是附掛在內容旁邊,而是分散滲透到內容本身之中。因為這個訊號搭載在真正的視覺或文字資訊裡,而不是另外的容器,所以它的設計目標就是要撐過裁切、縮放、重新壓縮、格式轉換,以及——和中繼資料式的資訊清單不同——連截圖都撐得過,因為被擷取下來的像素本身仍然帶著那份擾動。截至2026年年中,這項技術的部署規模已相當可觀:Google表示SynthID已為超過100億則內容加上浮水印,如今已在Gemini、Imagen、Veo與Lyria中預設開啟;2026年5月起,OpenAI與Google合作,將SynthID嵌入ChatGPT、DALL·E、Codex與OpenAI API所產生的圖片中,Kakao與ElevenLabs也已加入,部署範圍還在持續擴大到Search與Chrome。
「強韌」不等於「破不了」
這種做法的代價在於,驗證統計式浮水印並不是任何人都能獨立重現的是非題式密碼學檢查——它需要把內容送進一個偵測器,通常是廠商掌控的專屬偵測器,得到的結果是一個信心水準而非確定性:存在、不存在,或不確定。依賴這種黑箱偵測器是第一個弱點。第二個弱點是,訊號本身也可能被直接攻擊。像SynthID-Text這類文字浮水印已被證實可以透過改寫(paraphrasing)來破解,據報導,較精密的攻擊手法能把偵測準確率壓低到接近隨機猜測的水準。至於圖片,「擴散再生成攻擊(diffusion regeneration attack)」——把圖片編碼進潛在空間、注入雜訊,再透過逆向擴散(reverse-diffusion)重建——能產生一張在人眼看來與原圖視覺上一模一樣、卻已不再帶有原始統計訊號的輸出。這並非紙上談兵:目前已經有公開維護、專門用來從圖片中移除SynthID、C2PA憑證,以及EXIF/XMP「AI製作」標籤的開源工具存在。而在這一切之下,還有一項無法迴避的工程取捨:把浮水印做得更能抵抗攻擊,往往會明顯拉低輸出品質,目前沒有任何一套方案能完全化解這個矛盾——因此廠商調校的目標,是對一般日常處理有合理的韌性,而不是對存心破解的攻擊者有最大限度的抵抗力。
兩種做法都無法補上的缺口
這兩套系統共有一個限制,跟裁切或改寫都無關:浮水印在軟體層面是選擇性加入的,它只能標記出那些選擇實作這項機制的系統所輸出的內容。一個本機執行、開放權重的生成工具,大可以直接不加入浮水印程式碼,而檔案格式、法律,或這個世界的物理定律,都無法讓一個生成器一開始就沒有寫入的標記憑空出現在內容裡。對任何想把這些標記當成信任訊號來用的人來說,這一點是雙向的:沒有憑證、或偵測不到浮水印,並不能證明內容不是AI生成的;反過來,存在一個有效的標記,也不能證明內容是準確的、經過授權的,或是在原始脈絡下呈現的——一張真實拍攝、每一步都確實經過編輯並正確簽署的照片,依然可能誤導人。憑證證明的是一條監管鏈(chain of custody),而不是誠實。歐盟AI辦公室自己的實踐準則(Code of Practice)其實也間接承認了這一點:它規定的是中繼資料、隱形浮水印與紀錄留存三者並用的多層做法,而不是背書任何單一機制——因為起草這份技術指引的監理機關自己也清楚,沒有任何單一層能獨自覆蓋所有的失效情境。
那麼,標記義務究竟能不能真正落實執行?
這正是技術面與法律面接軌的地方。歐盟AI法第50條第2項所規定的機器可讀標記義務,在源頭確實是可以查核的:監理機關或稽核人員可以檢查一套生成系統,在內容產出的當下,是否附上了資訊清單、隱形訊號,或兩者兼具,提供者要麼達標、要麼不達標——這部分的法律確實有實質的技術約束力。但法律做不到的,是保證那個標記在歷經三次轉貼、兩次截圖、一次重新壓縮之後,最終抵達某位觀看者手上的那份拷貝上,依然清晰可辨。法規之所以無法延伸到那麼遠,是因為底層的技術本身就到不了那麼遠,這不是立法上的疏漏,而是誠實反映了這些系統能做到什麼、做不到什麼。但這不代表這項要求毫無意義:一個大多數AI內容在發布的當下就帶有可偵測訊號的世界,即使這個訊號並不完美,對於正在建構偵測系統的平台與研究者來說,也遠比幾年前近乎完全沒有任何標記的狀態,是更有意義的起點。只是,對「已加浮水印」或「已標記」這類說法比較合理的解讀,不是「這保證可以被追蹤」,而是「這在製作當下被標記過,至於它是否撐到你眼前,是另一個問題——而這項技術從一開始就不是為了確定地回答這個問題而設計的」。
以上規範與技術細節反映的是截至2026年7月中旬公開可得的資訊——在依此做出任何相關決策之前,請確認最新的規格與要求。本文僅提供一般性資訊,不構成法律或技術合規建議。