曼昆普法 | 模型可以是黑匣子 公司不能是黑匣子——從最高法涉人工智慧糾紛最新意見說起

2026年9月7日，最高人民法院發布《關於依法審理涉人工智慧糾紛案件的意見》。這份共24條的文件，涉及人格權益、模型訓練、知識產權、技術合約和訴訟證據等多個方面。

最近讀到這份文件，我最關注的是其中對創新的態度：《意見》明確提出，尊重科技創新規律和人工智慧行業發展實踐，以包容審慎的態度平衡權益保護與產業發展，營造「鼓勵探索、寬容失敗」的環境。

這對AI創業者是一個積極信號。技術尚在探索，產品不斷迭代，許多事情本來就無法在立項時保證成功。司法願意認真對待這種不確定性，有助於讓企業更有信心地嘗試。

不過，從商事爭議解決的角度看，我更關心這個信號怎樣在具體案件里提供指引。

項目沒有達到預期，企業怎樣證明自己盡到了合理努力？生成內容被指控侵權，開發者怎樣說明數據來源與訓練過程？雙方各執一詞時，法官依據什麼還原事實？這些問題的應對，在此次的意見里得到了指引——

司法為創新保留空間，也要求企業把能夠掌握的關鍵過程說清楚、證明出來。對創業公司而言，研發、數據和合規記錄，值得從一開始就作為重要的經營資產來管理。

一、允許技術失敗，但「合理努力」需要事實支撐

《意見》第15條要求，審理涉人工智慧技術開發、轉讓、許可、諮詢、服務合約糾紛時，應根據合約約定，充分考量研發特點、技術開發方是否盡到合理努力等情形，依法認定違約責任。

這句話里，「合理努力」值得關注，「根據合約約定」同樣不能忽略。

設想一家AI公司為工廠開發缺陷識別系統。投入數月後，識別效果仍未達到預期，客戶要求退款、賠償。開發團隊覺得委屈：「我們一直在改，確實遇到了技術難題。」

這樣的解釋有意義，但法院還需要知道：雙方約定的是共同探索一項尚待驗證的技術，還是交付滿足明確標準的系統？測試樣本、使用環境和驗收方法有沒有約定？技術風險如何分擔？

如果企業明確承諾了特定條件下的交付結果，不能僅憑「研發很難」「團隊很努力」，就當然免除違約責任。是否承擔責任、承擔多少，仍須結合約定、履行情況及法律規定判斷。

因此，保護應當從簽約時開始。哪些功能已經成熟，哪些指標需要進一步驗證，相對方應提供什麼數據和配合，需求改變後如何調整進度與費用，都應儘可能說清楚。

對不確定性較高的項目，還可以考慮先做小規模驗證，再決定是否進入下一階段；同時約定未達到階段目標時，費用如何結算、已有成果如何處理。把成本提前談清楚，往往更有利於合作真正開始。

合約劃出了責任邊界，過程記錄則幫助判斷企業實際做到了哪裡。

再如，客戶增加了新的缺陷類別，雙方有沒有確認調整？某輪測試表現不佳，團隊分析過什麼原因，嘗試了哪些改進？發現重大障礙後，是否及時告知客戶、討論替代方案？交付的具體版本，與當時的測試結果能不能對應起來？

Git等版本管理系統里的修改記錄、測試原始數據、問題清單、需求確認和階段性交付材料，都可能為這些問題提供依據。

但提交記錄多、加班時間長，並不能直接證明「合理努力」。更有說服力的是，這些投入確實圍繞約定目標展開，技術選擇有依據，發現問題後作出了與當時條件相適應的處理。此外，就我代理的一些複雜軟體開發合約糾紛案的經驗來看，除了最開始的約定外，中間可能涉及的需求更改，都應以約定的方式予以確認，避免後續可能的糾紛。

對創業者而言，爭取司法對技術失敗的理解，需要讓法官看見真實的研發過程。技術上的挫折能夠被解釋，合約中的風險安排才更有可能得到準確適用。

二、模型可以是黑匣子，公司不能是黑匣子

合約糾紛需要還原研發過程。在今年的多起侵權糾紛中，法院多次要求企業進一步說明：模型是怎樣形成的，爭議內容又是怎樣產生的。

《意見》第12條明確，在人工智慧生成內容被訴侵犯著作權的糾紛中，開發者提出不侵權抗辯的，應按法院要求提供訓練數據來源、訓練過程記錄、模型運行模式及科學理論依據等材料佐證。

最高法在答記者問中說明，權利人仍需就爭議內容由相關AI生成、與其作品構成實質相似等初步事實舉證。與此同時，掌握內部技術資料的開發者，也需要為自己的抗辯提供依據。

對於企業，這意味著「我們沒有抄」需要有事實支撐。

數據由誰提供，通過什麼渠道取得，使用依據是什麼？取得的許可是否覆蓋實際用途？數據經過哪些處理，用於哪個訓練版本？針對可能出現的侵權內容，採取了什麼預防和處理措施？

這些問題未必能靠一份採購合約回答。供應商聲稱「數據合規」，還需要結合授權文件、實際交付內容和具體使用方式判斷。

這裡尤其需要注意一個邊界：最高法明確表示，對未經許可使用他人作品訓練大模型如何定性，《意見》暫未作出規定。企業不能據此推導出「訓練使用已經獲得普遍許可」；具體項目仍需結合現行法律和使用事實分析。

記錄的意義，就在於為這種分析保留事實基礎。

我願意把它比作飛機的黑匣子：它無法保證飛行永遠不出問題，但在問題發生後，能夠幫助人們知道當時發生了什麼。AI企業保存關鍵過程，也是為了讓爭議有可以核查的依據。

這裡不必把目標設成完整解釋每一次模型輸出。企業可以先把能夠控制的環節管好：數據如何進入，版本如何變化，風險如何評估，投訴如何處理。

使用外部模型接口開發應用的團隊，可以從供應商條款、模型版本、自行接入的知識庫來源和調用記錄做起；自行訓練、微調模型的團隊，則應保存相應的數據處理和訓練記錄。具體範圍應與企業角色、業務風險和實際控制能力相匹配。

技術雖複雜，企業對自身行為的說明應當儘可能清楚。

三、合規與證據工程

前面兩個問題，最終都會落到同一件事上：記錄存在，並不意味著它已經足以證明企業的主張。

《意見》第18條要求重點審查電子數據在生成、收集、儲存、傳輸過程中的真實性和完整性。對區塊鏈存證，還要審查上鏈前數據的真實性以及平台的可靠性。

因此，文件做了存證，不等於文件記載的事情就當然真實。

在司法實務中，面對項目糾紛，法院通常要求提供原始結果、測試條件，並與交付記錄相互印證，才更容易判斷它是否符合合約約定。因此，記錄也應如實呈現相關的失敗測試、異常和修正。它們能解釋問題怎樣被發現、方案為何調整，有時正是判斷企業是否盡到合理努力的重要依據。

從這個角度看，研發管理、數據合規和訴訟準備，其實可以在同一套日常工作中完成。研發記錄可以證明履約情況，數據來源材料可以支撐侵權抗辯，運行日誌也可能幫助查明異常原因和責任範圍。

這就是我所理解的「證據工程」：圍繞將來可能發生爭議的關鍵事實，讓日常記錄形成可以核查、相互印證的聯繫。

小團隊也可以從幾個節點做起。立項時，把技術目標和風險分擔落實到合約；接入數據時，保存來源、許可和處理依據；交付時，把需求、版本、測試和客戶反饋對應起來；發現異常或收到投訴後，及時記錄處置過程，固定相關材料。

同時，要明確由誰保存、存在哪裡、誰能修改，以及怎樣備份，避免人員離職或者系統更新後，關鍵資料無法找回。留存範圍、期限和訪問權限，也應兼顧個人資訊保護與商業秘密。

專家提前參與的價值，就在於與業務、技術團隊一起判斷：哪些事實會影響責任，合約怎樣表達這些事實，現有系統能否留下相應依據。企業不必等到收到起訴狀，才第一次把技術過程翻譯成法律能夠判斷的問題。

好的合規，應當幫助企業順暢地推進業務，也讓關鍵的經營行為在需要時有據可查。

這份《意見》體現了司法支持創新的態度，也圍繞合約履行、侵權責任和證據審查等具體問題，為企業依法維護自身權益提供了指引。

這種保護會惠及認真投入的創業者：項目遇到困難時，研發記錄能幫助澄清履行情況；遭遇侵權指控時，數據和技術資料能為抗辯提供基礎；開展新的合作時，清楚的責任安排也有助於雙方建立信任。

AI創業仍然值得大膽嘗試。企業可以在探索未來的同時，把已經走過的路記錄清楚，讓真實的投入、審慎的判斷和負責任的行動，成為繼續向前的底氣。

本文作者：趙暄律師

來源：金色財經

發佈者對本文章的內容承擔全部責任
在投資加密貨幣前，請務必深入研究，理解相關風險，並謹慎評估自己的風險承受能力。不要因為短期高回報的誘惑而忽視潛在的重大損失。