客製化系統「源碼託管」(Source Code Escrow) 完整指南：4 種託管模式、5 條合約紅線、3 個觸發釋出條件——中小企業老闆給外包工程廠商開發前必須先簽掉的最後一道保險

在我們最近的客製化系統諮詢經驗中，被中小企業老闆問到最多次的一句話是這個——「如果開發完之後，那家外包廠商倒了怎麼辦？」。第一次聽到大概是 2021 年，那時客戶花了快 200 萬蓋了一套訂單流程系統，三年後接到廠商寄來的最後一封信：原團隊解散，伺服器一個月後關閉，請自行備份。客戶當下整個人僵在那邊——他連 source code 在哪都不知道。

這不是個案。過去兩年我們陪客戶做客製化系統的合約評估時，最常看到的合約漏洞就是這一條：「智慧財產權歸甲方所有」寫得很漂亮，但下面沒有任何條款規定廠商「什麼時候、用什麼方式、把 source code 跟部署文檔交給客戶」。智財權歸屬是法律宣告，源碼託管（Source Code Escrow）才是真正讓那份宣告變成可執行保險的機制。沒有 escrow，你的 IP 條款只是一張支票，但發票銀行已經倒了。

這篇要把 Source Code Escrow 這件事講清楚——它是什麼、4 種主流託管模式怎麼選、5 條合約紅線要寫進哪裡、3 個能觸發釋出的條件怎麼設計、台灣本地實務上有哪些路可走、預算大約怎麼抓。寫給的對象很明確：中小企業老闆、採購主管、法務同仁——你們才是合約簽下去要承擔的人。工程廠商通常不會主動提這件事，所以這道保險要你開發前就主動鋪。

先給結論：根據 Iron Mountain (Escode) 公開白皮書，全球高達 70% 的企業軟體授權合約沒有 escrow 條款，但這些合約所對應的系統，若供應商停業，平均「業務中斷成本」是合約原值的 3 至 5 倍。換句話說，省下幾萬塊 escrow 年費沒簽，倒下去就賠 100 萬以上——這個算術連保險業務員都不用算。

Source Code Escrow 到底在保什麼，怎麼運作

源碼託管講白就是一個「三方信任機制」——軟體廠商（depositor，存放方）把客製化系統的 source code、build script、部署文檔、資料庫 schema、第三方授權清單，定期存進中立第三方（escrow agent，託管方）的安全保管設施；客戶（beneficiary，受益方）跟廠商在合約裡約定，當「特定觸發事件」發生時，escrow agent 必須把這份存檔釋出給客戶。

它跟一般 GitHub 備份的差別有兩個關鍵：第一是法律可執行性——escrow agent 是合約第三方，受託契約有明確法律效力，廠商沒辦法在倒閉前把 repo 砍掉；第二是完整性驗證——進階託管模式會做 build verification（拿託管的源碼重新編譯、驗證能跑），確保你拿到的不是一坨缺東缺西的廢檔。Codekeeper 的服務白皮書提到，產業裡有大約 30% 的 escrow 案例在第一次驗證時就發現「源碼編不出來」——這代表如果沒有驗證機制，等到廠商倒閉那天才拿出來看，多半已經來不及補。

這個流程裡 escrow agent 不是只當「網路硬碟」——他承擔三個責任：保管安全（通常會用加密 + 異地多副本 + 物理保險庫）、定期驗證（按合約週期 audit 存放內容）、事件觸發後的法律判定（接到客戶釋出申請後，必須先依合約定義審查觸發條件是否成立）。這也是為什麼 escrow 不能用「客戶自己抓一份 source code 放雲端」取代——客戶自己保管的東西沒有第三方背書，廠商隨時可以主張「那是舊版、那不算數」。

4 種主流託管模式：從基本備份到 SaaS 完整環境快照

市場上 escrow 服務分四個層級，差別在「託管什麼」與「驗證到什麼程度」。從便宜到昂貴排下去，年費可以從台幣 3 萬到 30 萬不等，重點在於「貴的適合什麼專案」，而非單純「越貴越好」。中小企業老闆挑錯層級會出兩種錯：花錢買了用不到的進階服務、或省錢買了關鍵時刻派不上用場的陽春版。

選法很簡單，看你「廠商倒了之後要多快能自己接手」。簡易託管適合那種「真倒了我們直接找另一家重寫也 OK」的小案；標準託管是大多數中小企業客製化系統的甜蜜點——花 10 萬左右買一個 200-300 萬專案的 backup 路徑，CP 值最高；進階託管的價值在「驗證」——它每季會用你存進去的東西實際 build 一次，確保你真倒下去的那天，拿到的是能跑的東西而非一坨垃圾；SaaS 託管則是當你客戶要求「資料不能丟」（醫療、金融、法務）的時候才會用到。

這四種模式的另一個關鍵差異在「更新頻率」。簡易託管通常只在「合約簽訂時」存一次，之後就放著——這代表如果系統迭代很快，三年後你拿到的可能是初始版本，跟現在 production 跑的版本差了 80%。標準託管的「季度更新」是合理底線；如果你的系統每月都在大改，最好直接走 SaaS 託管的月度更新。

簽約必抓的 5 條合約紅線（給法務同仁的 checklist）

我們陪客戶看過幾十份外包客製化合約裡的 escrow 條款，最常踩雷的就是「條款寫得很漂亮但完全不能執行」。下面這 5 條是過去經驗裡發現最關鍵的合約紅線，每一條都對應一個「沒寫清楚就會在出事那天吃虧」的場景。

第一條的智財權跟 source code 歸屬陷阱，我們在另一篇 軟體著作權與 source code 歸屬陷阱：找外包老闆必看的合約防雷指南 寫得更深入，建議搭配看；這條是 escrow 的前置——智財權沒先談清楚，後面的 escrow 條款是建在沙上的城堡。

第二條「觸發條件可量化」是最容易被廠商擋下來的——廠商談判時會說「破產這種事誰能預料」，但真正的爭議多半發生在「廠商還活著但已經不維護」的灰色地帶。我們的取捨是：把 SLA 違約寫進觸發條件比把破產寫進去重要——因為破產是公開的（去經濟部商工登記查就有），但 SLA 違約是私下的，需要白紙黑字才能拿出來談。具體 SLA 寫法可以參考 軟體維護合約模型與條款設計：年費 vs 工時包 vs 免維護的取捨。

第五條的「主動觸發演練」是很多合約沒想到的——它讓客戶平時就能驗證「我真的拿得到、拿到的真的能用」。沒有這條，client 永遠是被動方，escrow agent 跟廠商可以串通做假帳。每年付一次小額費用換一次「演習」，是中小企業老闆唯一能在 escrow 機制裡保持主動的設計。

3 個能觸發釋出的條件：流程、時程、法律可執行性

觸發條件講白就是「在什麼情況下，escrow agent 會把存檔交給你」。市場上 escrow 合約最常見的有三類觸發條件，每一條的證明難度、釋出時程、後續法律風險都不一樣——條款寫得對不對，決定真出事那天客戶能不能在 30 天內接手系統，還是要等 180 天打官司打到天荒地老。

最簡單的是廠商「依法登記破產」——這個有公開資料佐證，escrow agent 拿到資料就會啟動釋出，時程通常 7-14 日。但這也是最少發生的——根據 經濟部商業司 2025 年公司退場統計，中小型軟體服務商（資本額 500 萬以下）的年度退場率約 8-12%，但「正式破產登記」只佔退場家數的不到 15%——大部分廠商是「自然消失」，沒登記、沒公告、就是沒人接電話。所以光靠破產這條觸發條件，多半保不到你。

第二條「SLA 違約 / 停止維護」是真正的主戰場——「廠商還活著但不修了」的灰色地帶。這條的證明難度中等，但有個關鍵設計：催告紀錄必須是「正式書面 + 有送達回證」，不能只用 email。我們的建議是合約裡明訂「兩次存證信函未獲回覆」視同違約——存證信函在台灣有明確法律效力，廠商收到後沒回應，escrow agent 啟動釋出的法律基礎就很穩。

第三條「被併購」最棘手——新東家可能繼續服務但漲價 3 倍、或勉強做但服務品質掉一截。合約裡要把「拒絕續約」寫得很精準：「拒絕續約」應包含『要求漲價超過原合約 50%』、『縮減服務範圍超過 30%』、『變更主要工程聯絡窗口逾 3 次』——這些都算「實質性拒絕續約」。沒有這些細節，新東家可以一直用「我們有提供服務啊」當擋箭牌。

我們對「50 萬以下的客製案不用簽 escrow」這種說法的看法

業界有個流行的說法：「合約金額 50 萬以下的小案，不用搞 escrow，太麻煩了」。我們不認同這種講法。客製化系統諮詢經驗裡，最常死在廠商倒閉、最沒能力應對的，恰恰就是這種小案的甲方——通常是 10-50 人的小公司，沒有專職 IT，沒有法務團隊，當初付 30 萬找了一個工作室或 freelancer 做了個訂單系統，三年後那個 freelancer 出國移民，整套系統的密碼、source code、第三方 API key 全部跟著消失。

我們的判斷是反過來的：專案金額越小、廠商越是個體戶或工作室，escrow 越值得做。理由有三個。第一，小廠商的「人去樓空」風險本來就比上市軟體公司高 5-10 倍——個人健康、家庭因素、移民、轉行，任何一個都能讓服務瞬間斷檔；第二，escrow 成本可以分攤——簡易託管年費 3-5 萬，3 年合約攤下來大約是專案金額的 5-15%，買的是 100% 的「不會變黑箱」保險，CP 值比保火險高；第三，小廠商不一定願意走正式 escrow agent，但「律師事務所代管 source code zip」這種低成本變體，連 freelancer 都能配合，不需要走國際 escrow agent。

常見的反駁是「小案直接拿 source code 給客戶就好啊」——這個邏輯有兩個漏洞：第一是廠商通常不願意給最新版的 source code（怕客戶找別家改），實際上你拿到的多半是「合約簽約那一刻的版本」，跟現在 production 跑的差很多；第二是沒有第三方背書，廠商可以事後主張「你拿到的不是完整版」、「那個 zip 是 staging branch」，客戶根本沒法反駁。escrow 之所以叫 escrow，就是因為「第三方背書」這層信任本身就是商品——不能用「客戶自己存一份」取代。

我們公司自己怎麼處理：30+ 企業客製案落地的內部源碼版控

我們講的這些不是紙上談兵——恆遠數位行銷自己累積了 30+ 企業客製案落地，每一個正式上線專案都跑同一套「內部 escrow-grade」工作流。具體做法是：所有客戶專案的 source code 強制存在三個地點——主 GitHub Organization（含完整 git history）、Cloudflare R2 加密備份（每週自動快照）、客戶自己的 GitHub team（透過自動 mirror push）。這套機制本來是給內部團隊用的，但跟客戶聊 escrow 議題的時候才發現——原來這就是一個「DIY 版的標準託管」。

為什麼我們會用三點備份？因為我們自己也踩過坑。2023 年有一次 GitHub 區域性故障，剛好遇到客戶要緊急 hotfix，我們花了 30 分鐘從 R2 備份還原才接得上——如果只有 GitHub 一個來源，那 30 分鐘可能變成 4 小時。從那次之後，「source code 不能只放一個地方」變成內部硬規定，這條規矩後來也被我們直接寫進客戶合約模板裡。客戶不一定要走正式 escrow agent，但「客戶自己的 GitHub team 鏡像 + 雲端加密快照」這套組合，是中小企業預算內最務實的「準 escrow」方案。

我們也在自己內部的 20+ AI 工作流裡跑同一套——每個 n8n workflow、每個 Claude Code agent 的 prompt template、每個內部小工具，都同步推到 GitHub + R2 雙備份。這算是上次踩過坑之後的免疫反應，跟潔癖無關。對中小企業老闆來說，這個經驗的意義是：escrow 是任何認真做客製化系統的人都該有的基礎工程紀律，並非「有錢人的玩具」——真正要花的是「設定一次永遠受惠」的時間，金錢成本反而是最小的一塊。

台灣本地實務：律師事務所 vs 國際 escrow agent vs DIY 三條路選型

台灣沒有像英國 Escode、荷蘭 Codekeeper 這種專做 escrow 的本地大型服務商，所以中小企業實務上會走三條路——找律師事務所做合約代管、找國際 escrow agent 跨境服務、或自己 DIY 一套準 escrow 機制。每條路的成本、法律強度、運維負擔都不一樣，選錯會多花一倍錢或關鍵時刻拿不到東西。

我們的選型建議是分三層：合約金額 < 50 萬走 DIY 準 escrow（成本 < 3 萬就可以建立完整三點備份）；50-500 萬走律師事務所代管（10 萬左右買到本地法律強度，律師會幫你寫好觸發條件 + 處理釋出爭議）；500 萬以上 + 跨國 / 上市櫃預定 / 有監管要求的案子才走國際 escrow agent（這個價位你需要的是 build verification 跟跨國法律可執行性的雙保險）。

律師事務所代管這條路在台灣最被低估——大部分中小企業老闆以為「律師只能寫合約」，事實上前面提的常春藤、理律這類大型事務所早就有「智財代管」服務，會替客戶設立託管帳戶、定期 audit 廠商提交的內容、發生爭議時直接接手代理訴訟。理律法律事務所智財管理服務介紹 跟 常在國際法律事務所企業法律顧問服務 都有相關專業組別。對台灣本土中小企業，這條路通常 CP 值最高——因為合約是中文、訴訟在台灣、escrow agent 直接是律師可以代理你打官司，少了「跨國協調」這層摩擦。

DIY 路線的關鍵在「律師見證信」這一張紙——把客戶自己的 GitHub team backup 設定，請律師寫一封見證信「茲證明本人於 X 月 X 日見證 [客戶] 與 [廠商] 共同設定 GitHub 自動鏡像備份至 [客戶] 帳號，密碼及備份政策如附件」。這張紙的成本大約 5,000-10,000 TWD，但效力上等同「公證」，在後續爭議時可以證明「客戶持有的版本是合法取得的最新版」。沒有這張紙，你的 DIY 就只是「客戶私下抓的一份」，法律上沒有第三方背書效力。

60 天落地行動清單：從現在開始到簽約前要做的事

escrow 不是合約簽下去就結束的事——它是一個「持續運作的機制」。從跟廠商談 escrow 條款、選 escrow agent、設定託管內容、到第一次驗證演練完成，完整一輪通常要 60-90 天。下面這個時間表是我們幫客戶導入 escrow 機制時用的標準步調，中小企業老闆可以照著抓自己的進度。

• Week 1-2（評估期）：盤點現有客製化系統合約，列出三件事——合約金額、廠商規模（人數 + 資本額）、系統重要性分級（核心營運 / 輔助工具 / 一次性專案）。盤點完選出『要做 escrow 的優先名單』，通常是合約金額 > 100 萬 + 廠商規模 < 20 人 + 核心營運。
• Week 3-4（廠商溝通期）：把 escrow 議題正式提給廠商，「我們公司內部風控政策要求所有 100 萬以上的客製案必須有 escrow 機制」這種說法廠商最容易接受——把它定位成「我們的內規」而不是「對你們的不信任」，談判摩擦會小很多。預期 30% 廠商會推託，這時候要評估『這個廠商是不是已經有問題』。
• Week 5-6（escrow agent 選型 + 合約草擬）：依上方第七節的三條路選型結果，挑定 escrow agent；請法務或律師依本文第三節的 5 條合約紅線起草『escrow 三方契約』，重點是觸發條件的可量化定義。
• Week 7-8（首次託管 + 驗證演練）：廠商交出第一份託管內容（source code + build script + 文檔），escrow agent 做完整性驗證（標準託管以上）或 build verification（進階託管以上）；客戶側執行『模擬釋出演練』——假裝廠商倒了，看看你拿到的東西能不能 30 天內接手。第一次演練通常會發現至少 3-5 個漏洞需要補。
• Week 9-12（常態化）：把 escrow 更新納入季度合約 review，每季驗收一次廠商的更新內容；指定一位內部 owner（通常是 IT 主管或營運主管）負責跟 escrow agent 的窗口。

這個流程裡最常卡住的環節是 Week 7-8 的「驗證演練」——大部分客戶會發現「我拿到 source code，但不知道怎麼 build」，這時候要回頭找廠商補 build runbook 跟環境變數清單。建議客戶在合約裡明訂：第一次驗證演練未通過，廠商必須在 30 日內無償補正——這條沒寫，廠商會用「驗證演練是 escrow agent 的事，跟我們無關」當理由不修。

整體成本面，中小企業老闆可以這樣抓：escrow 年費 + 法律 review 費 + 內部投入時間，三項加起來大約是「保護專案金額」的 3-8%。換句話說，一個 200 萬的客製化系統，每年花 6-16 萬左右就能買到 escrow 保護——這個算式對齊上方第六節提到的「業務中斷成本是合約原值 3-5 倍」的事實，CP 值很清楚。系統選型階段就把 escrow 預算編進去，比上線後再回頭加要省 3-5 倍成本。完整的系統選型 + 採購評估流程可以參考 AI 軟體供應商盡職調查 SOP：12 項檢核、5 個紅旗、4 條退場條款 跟 AI 供應商議價指南：6 條籌碼、4 個訂價陷阱、5 條合約紅線。

看到這裡，如果你正在評估 escrow 條款怎麼寫

我們常陪中小企業老闆走完整套客製化系統的合約評估——包含 escrow 條款設計、廠商溝通策略、escrow agent 選型、首次驗證演練的協助。如果你公司有客製化系統正在規劃、或者既有系統合約還沒包含 escrow 條款，可以 把現在的合約跟系統情況丟過來，我們陪你看看哪一條路最適合你的規模跟預算——這個階段我們陪你想，後面真的要動手再談範圍跟費用。完整的客製化系統開發合約評估範圍，包含交付驗收、變更管理、escrow 三大塊，可以從 客製化系統開發交付驗收 SOP：8 項檢核、4 階段驗收、3 條換廠合約紅線 跟 客製化系統開發變更管理：3 階段流程、4 種計費模式、5 條合約紅線 看起。