AI 系統採購合約：IP 歸屬與授權完整指南——6 個必看條款、5 條 IP 歸屬紅線、4 種替代方案

大部分中小企業老闆採購 AI 系統時只看功能報價——但 3 年後撞牆的都是合約沒寫清楚 IP 歸屬。

最近我們在替一家 80 人規模的製造業客戶做 AI 客服系統採購顧問，老闆一開始只想比對三家廠商的月費差多少。等我們拿合約草案逐條看下去，才發現三份合約在「AI 生成的對話 log 歸誰」「訓練用的公司產品資料能不能拿回去 fine-tune 廠商基礎模型」「合約到期後客戶資料多久內刪除」這三條上，寫法完全不一樣。最貴的那家甚至在小字寫著「乙方保留使用甲方對話資料改善產品的權利」——翻成白話就是「你付錢請我做，但你的客戶資料同時變成我的資產」。老闆看完當場臉綠。

這不是廠商特別壞，是 2026 年 AI 系統採購合約還沒進入成熟期的普遍狀態。從 OpenAI Enterprise 到 Anthropic Business、再到台灣本地做 AI 導入的中小型 SI 廠商，合約條款差異之大遠超一般軟體外包。我們陪過 30+ 家中小企業做客製化系統落地，其中至少一半在最後簽約階段卡在 IP 條款——不是廠商刁難，是雙方對「AI 系統的 IP 到底該歸誰」根本沒共識。這篇文章把我們在真實案子裡整理出來的 6 個必看條款、5 條 IP 歸屬紅線、4 種替代方案完整攤開，寫給正在做 AI 系統採購評估的中小企業老闆、法遵主管、IT 主管。

先給一個框架。根據 WIPO (世界智慧財產權組織) 對 AI 與 IP 的官方立場，AI 生成物的著作權歸屬在全球主要法域仍未統一，但共識是「人類的創作投入程度」決定歸屬走向。這對中小企業老闆的含義很直接：合約簽的時候不能只寫「AI 生成」四個字，必須寫清楚「什麼是人類投入、什麼是機器產出、雙方各自對哪部分主張權利」。台灣著作權法第 11 條 (受雇人職務上完成之著作) 與第 12 條 (出資聘人完成之著作) 是判斷這道題的第一層框架，但 AI 生成物讓第三層新問題浮出來——訓練資料、輸出資料、微調模型三者的歸屬要分開談。

六個必看條款：AI 系統採購合約簽字前一定要確認

AI 系統採購合約跟傳統軟體外包合約最大的差別，是「資料生命週期」變成獨立議題。傳統合約重點在功能規格、驗收條件、維運責任；AI 合約還要加上：訓練資料流向、生成物歸屬、模型使用權、資料留存期限四個維度。下面六個條款是我們從 30+ 案子整理出來、每一條都有實際踩過的坑。

條款一：AI 生成物歸屬 (Output Ownership)

這是最容易被跳過、但事後爭議金額最大的一條。要問廠商三個具體問題：① AI 系統跑出來的內容 (回應文字、生成圖片、程式碼、報表分析) 歸誰？② 如果甲方 (你) 用這些生成物再產出新的商品，權利義務怎麼算？③ 廠商能不能主張「因為是我的 AI 生成的，所以我有共有著作權」？合約要寫死一句話：「凡使用本系統由甲方輸入 prompt 所產生之所有輸出結果，其著作權、專利權、商業使用權完全歸屬甲方所有，乙方不得主張任何權利。」

美國 U.S. Copyright Office 在 2023 年 Zarya of the Dawn 案裁定「純 AI 生成的圖片不受著作權保護、必須有人類創作投入才行」，這個判決對台灣廠商很多還沒 update 認知。實務上如果你採購的是 AI 內容生成系統，合約要區分「AI 產出的原始素材」和「人類編輯過的最終版」歸屬邏輯不同——前者可能不受著作權保護，但你付錢請廠商做的系統本身 (前端 UI、後端 workflow、prompt engineering) 一定要寫進甲方所有。

條款二：訓練資料使用授權 (Training Data License)

廠商要不要拿你公司的資料去訓練他們的基礎模型？這條至少寫成三種其中一種，選最嚴的：① 完全禁止 (default deny)：乙方不得將甲方任何資料用於訓練、微調、改善任何模型；② 匿名化允許：乙方僅可將經去識別化處理之資料用於系統改善，且不得用於商業產品；③ 明確授權 + 對價：若乙方需使用甲方資料訓練，須另立補充協議並支付授權金。默認選①，除非廠商能證明②或③對甲方有明確好處。

很多廠商標榜「我們絕不會拿客戶資料去 train model」，但翻合約細看，會發現裡面寫「乙方可基於服務品質改善目的處理甲方資料」——這個「處理」的定義在合約沒寫死之前，就是灰色地帶。我們的建議是逼廠商在合約條款寫死「不用於任何形式的 model training / fine-tuning / RLHF / embedding 建立」，把每一個技術動詞都列出來，才不會留下解釋空間。

條款三：資料留存與刪除期限 (Data Retention & Deletion)

合約結束後，你的資料在廠商那邊還會存多久？OpenAI Enterprise 標準是 30 天內刪除，但很多中小型廠商合約沒寫，等於「永久保留」。要寫清楚：① 正常情況資料留存最長期限 (建議 90 天以內)；② 合約終止或解除後幾日內完全刪除 (建議 30 天以內)；③ 是否包含備份、log、快取等衍生資料 (必須包含)；④ 甲方是否有權要求廠商出具刪除證明 (必須有)。

條款四：模型 IP 與微調成果歸屬 (Model & Fine-tuning IP)

如果採購案裡有「針對甲方資料 fine-tune 專屬模型」的需求，這條特別重要。fine-tune 過後的 model weights 歸誰？大部分廠商合約會寫「基礎模型 + fine-tuning framework 屬於乙方，fine-tune 後的 weights 屬於甲方使用權限」——請注意「使用權」跟「所有權」是兩件事。使用權意味著合約結束後你不能帶走那份 weights；所有權才能。中小企業如果日後可能換廠商，這條必須爭取「甲方對 fine-tune 後之模型 weights 享有所有權，並得於合約終止後帶走使用」。

條款五：第三方 API 授權責任分擔 (Third-party API Liability)

AI 系統絕大部分會串接 OpenAI / Anthropic / Google Gemini 等第三方 API。這些 API 廠商的商業條款自己就有一堆限制 (例如 OpenAI Enterprise Business Terms 規定禁止用於某些用途、Anthropic 有 Usage Policy 禁止某些內容)。合約要寫死：① 廠商必須揭露所有串接的第三方 API 清單；② 若因第三方 API 條款變更導致服務中斷或費率調整，責任分擔比例；③ 若甲方使用某類內容觸犯第三方 Usage Policy 導致 API 被停權，切換替代供應商的時程與費用。

條款六：SLA、資安、稽核權 (SLA / Security / Audit Rights)

AI 系統的 SLA 不能照抄傳統 SaaS。要多寫三件事：① Uptime 定義要包含「模型可用性」而不只是「服務端點可用性」——OpenAI outage 時，端點還在但 model 不回應，這是 outage；② 資安事件通報時限 (建議 24 小時內書面通報)；③ 甲方稽核權 (至少每年一次現場或遠端稽核廠商的資料處理流程)。SOC 2 Type II 報告是很好的替代方案，如果廠商能提供、可以取代稽核權，但仍要保留書面通報條款。

關於 SOC 2 Type II 稽核在 AI 供應商採購上的具體 12 項檢查點，可以延伸看 SOC 2 Type II AI 供應商採購稽核完整指南 那篇，我們把每一項稽核證據該問到什麼細節都整理進去了。

五條 IP 歸屬紅線：踩到任何一條就退回重談

上面六個條款是「必看」，但看完不代表能簽。下面五條是我們的紅線判斷 (bright-line rules)——只要合約踩到其中任何一條，我們會建議甲方直接退回廠商，要求重談，退不了就換廠商。這五條紅線不是我們自己發明的，是採購委員會、法遵、IT 三邊對齊之後歸納出來的最低共識。

這五條紅線之中，紅線 1 和紅線 5 是最容易被中小企業老闆忽略的。紅線 1 因為條款寫在合約深處、常用「服務品質改善」這種柔性語言包裝；紅線 5 因為多數老闆看到「本公司保留修改條款之權利」會直覺覺得「大家合約都這樣寫」，其實那是 to-C 消費者條款的慣用寫法，B2B 專業合約應該要有明確的修改通知期 (30 天) + 甲方拒絕權 (若不同意可終止合約且免違約金)。

四種替代方案：合約談不下來時的採購路徑選擇

如果廠商在紅線條款上不肯讓步，中小企業老闆有四種替代方案可以評估。每一種的成本、時程、控制權都不同，要看甲方對 IP 敏感度、對客製化需求、對長期擁有權的判斷來選。這四種也不是互斥的，我們有客戶最後採取「①+③ 混合」的策略。

方案 A：換廠商 (Vendor Switch)

AI 系統市場競爭很激烈，同一個功能通常有 3 到 5 家廠商可以做。用「合約踩紅線」當理由換廠商，成本最低、時程最快。實務上我們建議在採購初期就先鎖定 3 家做 RFP (Request for Proposal)，比較功能之外，也要求每一家附合約範本。合約條款差異在 RFP 階段就會浮出來，比較容易談。

方案 B：客製化開發 (Custom Build)

如果你的 AI 系統需求很特殊 (例如結合 ERP 內部資料、涉及行業 know-how、需要客製 UI/UX)，且長期使用預期超過 3 年，客製化開發是最能掌握 IP 的方法。前期投入高 (200-500 萬)，但每年只需維運費 50-100 萬，5 年 TCO 通常會比 SaaS 訂閱便宜。更重要的是 IP、原始碼、model weights 全部在甲方手上。

這條路我們自己走過很多次，30+ 客製化系統落地經驗都是這個模式。相關詳細比較可以看 客製化系統開發服務 頁面，或延伸閱讀 軟體著作權 & source code 歸屬完整指南 這篇——source code 歸屬的判斷邏輯跟 AI 生成物歸屬邏輯有共通處。

方案 C：混合式 (Hybrid Stack)

採購廠商純 API (例如直接跟 OpenAI / Anthropic / Google 買 API tokens)，業務邏輯和 workflow 由內部 IT 或請 SI 客製化。這種模式的優點是：API 廠商合約條款相對標準 (企業版都有明確的 no-training clause)，業務層 IP 完全在甲方手上。缺點是需要一定 IT 能力，且要面對多家廠商合約管理的複雜度。

方案 D：開源自架 (Open Source Self-host)

如果資安需求極高 (金融、醫療、國防、政府敏感業務)、或有明確政策不能出雲，可以評估開源模型自架。Meta Llama 3、Mistral、Qwen、DeepSeek 等模型都有商用授權版本，搭配 vLLM / SGLang 推理框架、Ollama / LM Studio 開發框架，理論上可以自架。但成本不低 (GPU 卡 A100/H100 一張 60-100 萬、加上部署維運人力)，適合有內部技術力的中大型企業。

台灣法規視角：著作權法第 11、12 條在 AI 合約的三個誤區

很多中小企業老闆以為「AI 系統採購 = 軟體外包」，直接套用著作權法第 12 條 (出資聘人完成之著作) 的邏輯——出資人 (甲方) 享有著作權、受聘人 (乙方) 享有著作人格權。但 AI 系統採購有三個地方會讓這個邏輯失效。

誤區一：AI 生成物可能根本不受著作權法保護。台灣智慧財產局在 2023 年後的解釋函令中已表明，純 AI 生成、無人類創作性投入的作品不受著作權保護。這代表你合約寫「AI 生成物著作權歸甲方」——如果法院最後認定該生成物根本不是著作，這條合約就變成沒有標的物的空條款。安全寫法是加上：「若因法規變動導致本合約標的物不受著作權保護，甲方仍享有排他性使用權及商業處分權。」

誤區二：訓練資料涉及第三方著作權時，合約不能只寫甲乙雙方。如果乙方用甲方提供的資料訓練模型，而這些資料裡有甲方從網路爬來的、或客戶提供的第三方著作，責任歸屬會很複雜。合約要加上「甲方保證所提供之訓練資料無侵害第三方著作權之虞」+「若因訓練資料侵權導致訴訟，責任分擔比例」兩條。

誤區三：著作人格權在 AI 合約沒意義、但要記得處理。傳統軟體外包會約定「乙方不行使著作人格權」，避免乙方日後跳出來要求署名。AI 生成物沒有「作者」概念，這條看起來無用，但如果你請的是「AI 顧問幫你設計 prompt library」或「AI 系統含有人類設計的核心 workflow」，這些人類創作部分仍需要處理著作人格權——不能因為外表是 AI 系統就整個省略。

(延伸閱讀：中小企業 AI 治理委員會啟動指南——AI 採購合約談完之後，內部要有 AI 治理委員會持續 review 廠商合約履行狀況；還可以看 中小企業 AI 員工政策手冊——把採購來的 AI 系統怎麼給員工用，也要一起規劃)

OpenAI / Anthropic / Google 三大 API 廠商 Business Terms 差異速查

如果你採購的 AI 系統是廠商幫你串接三大 API 廠商 (OpenAI / Anthropic / Google) 的服務，那三家的 Business Terms 差異你必須先摸清。廠商合約會提「將依 API 供應商條款提供服務」，但很少會把三家差異寫進中文合約附件。下表是我們每季重新查核一次的對照表。

上表在 2026-07 這一版是準的，但這三家 policy 每季會微調——特別是 zero data retention 的門檻和價格結構經常變。實務上我們建議在合約中要求廠商附上「所使用 API 供應商的最新 Business Terms 版本 + 承諾若供應商條款變動將於 14 天內通知甲方」，這樣不會被廠商用「API 廠商政策變動」當擋箭牌單方修改條款。

AI 系統採購合約談判 SOP：四階段十二個動作

把六個條款和五條紅線放到談判實務裡，實際流程分成四階段。這個 SOP 是我們陪 30+ 客戶跑過之後歸納出來的，適用於 100-300 人規模的中小企業採購 50-500 萬級 AI 系統。

階段一：RFP 前置 (2-3 週)

• 動作 1：內部先跑一次「AI 系統需求 + IP 敏感度」評估，列出哪些資料類別是絕不能被廠商拿去 train model 的
• 動作 2：法遵、IT、業務單位三邊對齊，寫出最低可接受條款清單 (Minimum Contract Requirements)
• 動作 3：至少邀請 3 家廠商進入 RFP，強制要求各家附合約範本

階段二：條款比對 (1-2 週)

• 動作 4：用六個必看條款做 checklist 比對三家合約
• 動作 5：踩紅線的條款標紅、灰色地帶標黃、明確合規標綠
• 動作 6：優先淘汰紅色數量最多的廠商，剩下兩家進入談判

階段三：談判與試點 (3-4 週)

• 動作 7：與剩下兩家分別跑 30 天付費 pilot，實測系統效能
• 動作 8：pilot 期間同步進行合約條款談判，用第二家當談判籌碼
• 動作 9：紅線條款不讓步的直接踢出，即使功能最好也不能簽

階段四：簽約前終審 (1 週)

• 動作 10：法遵最後 review，特別確認第三方 API 責任分擔條款
• 動作 11：IT 主管確認資安 SLA + 稽核權寫法
• 動作 12：財務確認費率、續約條件、合約終止時的資料撤出成本

這套 SOP 我們在 中小企業 AI 採購三道防線 60 天治理法 有更長版本的展開，包含 POC 設計、合約防線、退場 KPI 三個層次。這篇文章跟本文可以互補——本文聚焦在 IP / 合約條款細節，那篇聚焦在整體治理防線。

我們做過的中小企業 AI 採購合約審視類型

給採購評估者的最後叮嚀：AI 合約談判是新一代的採購核心能力

AI 系統採購合約談判在 2026 年還是新學問，多數中小企業採購委員會沒有現成 SOP、法遵團隊也還在追法規變動。這時候的做法不是等法規成熟才動、也不是照抄大廠合約範本，而是把「六個必看條款 + 五條紅線 + 四種替代方案 + 十二個談判動作」內化成自己的採購 SOP。

我們陪 30+ 中小企業客戶落地系統的經驗告訴我們：真正踩雷的合約，多數不是條款寫得太苛，而是雙方對 IP、資料、模型三者的邊界沒共識。合約寫得好不好，決定 3 年後 IP 是不是還在你手上；紅線劃得清不清楚，決定廠商換手時你的資產能不能帶走；替代方案想不想得到，決定談判桌上有沒有籌碼。三件事都要在採購階段就想清楚。

如果你正在做採購評估、或已經拿到合約草案不知道從哪看起，可以先看我們的 AI 顧問服務、或 客製化系統開發服務 頁面了解我們的介入方式，也歡迎直接 預約 30 分鐘免費諮詢。合約條款這種東西，多一雙眼睛看，就少一次踩雷。