外包開發合約中文範本 2026：逐條解析必備條款

委託東南亞或大中華團隊做開發，合約必須拆成四層：主約（MSA）、工作說明書（SOW）、服務水準協議（SLA）與資料處理附件（DPA）。本文逐條提供 2026 年適用的繁體中文範本條文，涵蓋智財歸屬、AI 生成程式碼、跨境個資、驗收與退出轉移。

開始之前：簽約前必須備齊的六份資料

很多合約爭議不是條文寫得差，而是簽約時根本沒有「可被引用的事實」。在動筆前，先把以下六項準備好，否則條文只會變成空殼：

1. 範圍基線文件：線框圖、API 規格（OpenAPI 3.1 YAML）、資料模型，任何可版本化的檔案。
2. 驗收標準清單：每個交付物對應可執行的測試（單元測試覆蓋率門檻、Lighthouse 分數、負載測試 p95 延遲）。
3. 資料流圖：標明個資會流經哪些司法管轄區（例：香港 → 越南開發環境 → AWS ap-southeast-1）。
4. 供應商法人資料：商業登記證副本、實際簽署人授權文件、銀行帳戶戶名是否與法人一致。
5. 既有智財清單：你方提供的品牌資產、第三方授權（字型、圖庫、SaaS API）。
6. AI 使用政策：你允不允許供應商用 GitHub Copilot、Claude Code 或自架 LLM 寫產品程式碼？2026 年這一條不能留白。

建議把合約本身放進 Git repo，以 Markdown 管理，main 分支為已簽版本，變更單（Change Order）走 Pull Request。這樣每一次範圍變動都有 diff 與審批紀錄，日後爭議時舉證成本極低。

1contracts/
2├── 01-MSA.md            # 主服務協議（長期不變）
3├── 02-SOW-001.md        # 第一期工作說明書
4├── 03-SLA.md            # 維運服務水準
5├── 04-DPA.md            # 資料處理附件
6├── annex/
7│   ├── A-acceptance.md  # 驗收標準
8│   ├── B-rate-card.md   # 費率表
9│   └── C-ai-policy.md   # AI 使用政策
10└── change-orders/
11    └── CO-2026-001.md

為什麼要把合約拆成四層，而不是一份長文件？

單一份 60 頁合約的問題在於：每次加一個小功能，都要重簽整份文件；而法務審閱週期通常比開發衝刺還長。四層結構讓變動落在最輕的那一層。

主服務協議（MSA）

放法律骨架：保密、智財、責任上限、爭議解決、終止。簽一次，用三年。

工作說明書（SOW）

放範圍、里程碑、價格、驗收。每個專案或每季簽一份，只由專案負責人與供應商 PM 審核。

服務水準協議（SLA）

放上線後的回應時間、修復時間、服務抵免（service credit）。這是唯一需要量化數字的文件。

資料處理附件（DPA）

放個資處理指示、次處理者清單、跨境傳輸機制。歐盟《一般資料保護規則》第 28 條明文要求資料控制者與處理者之間必須有書面合約，若你的客戶含歐盟居民，這份附件不是選配。

第 1 至 3 條：定義、服務範圍與交付驗收

第 1 條 定義條款

定義條款的唯一目的，是消滅「我以為」。至少要定義：交付物、驗收、重大缺陷（Severity 1）、工作天、你方資料、AI 工具。

11.3 「重大缺陷」指導致下列任一情況之缺陷：
2    (a) 生產環境核心交易流程（下單、付款、登入）無法完成；
3    (b) 個人資料外洩或未經授權存取；
4    (c) 資料遺失且無法由備份於四（4）小時內還原。
51.7 「工作天」指香港特別行政區及供應商主要交付地（越南胡志明市）
6    共同之營業日，不包括任一方之法定假期。

最後這一句在跨境合約特別重要。越南農曆新年（Tết）假期通常長於香港的春節，菲律賓一年的法定假日數量也與香港不同。不寫清楚，SLA 的「兩個工作天」就會各自解讀。

第 2 條 服務範圍與範圍外事項

範圍條款要同時寫「包含」與「明確不包含」。後者往往更能省錢。

12.2 下列事項不屬本 SOW 範圍，須另行簽署變更單：
2    (a) 與委託方現有 ERP 以外之第三方系統整合；
3    (b) 支援 Safari 15 以前版本或 IE；
4    (c) 內容輸入、圖片去背、產品文案撰寫；
5    (d) 上線後之功能新增（僅限缺陷修復，見第 8 條保固）。

第 3 條 交付與驗收

驗收條款要把「主觀滿意」換成「可執行的測試」。最實用的寫法是把驗收腳本直接掛進附件 A，並在 CI 中可重跑。

13.1 供應商交付後，委託方應於七（7）個工作天內完成驗收測試（UAT）。
23.2 驗收之唯一標準為附件 A 所列之驗收案例全部通過。
33.3 委託方未於前述期限內以書面提出具體不符事項者，視為驗收通過。
43.4 委託方提出之不符事項，供應商應於五（5）個工作天內修復並重新交付，
5    重新驗收期間為三（3）個工作天。
63.5 同一交付物重新驗收逾三（3）次仍未通過者，委託方得依第 11 條終止本 SOW，
7    並就未驗收部分要求退還已付款項。

附件 A 可直接引用可執行指令，讓驗收變成一條 CLI：

1# 附件 A：交付物 D-03「結帳流程」驗收指令
2npm ci
3npm run test:unit -- --coverage --coverageThreshold='{"global":{"lines":80}}'
4npx playwright test tests/e2e/checkout.spec.ts --project=chromium
5npx lighthouse https://staging.example.com/checkout \
6  --only-categories=performance,accessibility \
7  --chrome-flags="--headless" --output=json --output-path=./lh.json
8node scripts/assert-lighthouse.js ./lh.json --perf 80 --a11y 90

預期輸出：三條指令全部 exit code 0。任何一條非 0，即為第 3.4 條的「不符事項」，不需要爭論「感覺有點慢」。

第 4 條：智慧財產權歸屬要怎麼寫才不會踩雷？

這是外包合約中最常寫錯的一條。多數範本只寫「所有成果歸委託方所有」，但實務上一個系統至少有四類程式碼，歸屬完全不同。

14.1 客製成果：供應商依本合約專為委託方開發之原始碼、設計稿、文件，
2    其全部智慧財產權自付款時起歸委託方所有；供應商並放棄相關精神權利。
34.2 供應商既有元件：供應商於本合約前已擁有或獨立開發之框架、函式庫、
4    內部工具（列於附件 D），其所有權仍屬供應商；供應商授予委託方
5    永久、全球、不可撤銷、免權利金、可轉讓之非專屬授權，用於使用、
6    修改及散布客製成果。
74.3 第三方與開源元件：供應商應於每次交付時提供 SBOM（CycloneDX 格式），
8    列明所有第三方元件及其授權條款。未經書面同意，不得引入
9    GPL-3.0、AGPL-3.0 或其他具傳染性 copyleft 條款之元件於
10    委託方散布之產品中。
114.4 供應商保證客製成果不侵害任何第三方智慧財產權，並就第三方主張
12    之侵權請求向委託方為抗辯及賠償（見第 10 條）。

第 4.2 條的「既有元件授權」是實務關鍵。強行要求供應商交出自家框架的所有權，多數有能力的團隊會直接拒簽，或把框架改寫成一次性程式碼，反而降低品質。授權條款是更務實的交換。

第 4.3 條的 SBOM 可以自動化產生，寫進交付流程：

1# 交付時自動產生 SBOM，附件於每次里程碑交付
2npx @cyclonedx/cyclonedx-npm --output-format json --output-file sbom.json
3# 檢查是否引入 copyleft 授權
4npx license-checker --production --failOn "GPL-3.0;AGPL-3.0;SSPL-1.0"

第 5 條：AI 生成程式碼條款（2026 年新增必備）

2026 年的外包合約若不處理 AI，等於把一個未知的智財與資安風險留在體內。美國著作權局（U.S. Copyright Office）在其人工智慧與著作權系列報告中已闡明，純由 AI 生成而無足夠人類創作投入的產出，不具可註冊之著作權。這代表第 4.1 條「歸委託方所有」的東西，可能根本沒有「所有權」可以轉讓。

合約要做的不是禁用 AI，而是分級管理。

15.1 供應商得於交付過程使用 AI 編碼輔助工具，惟須符合下列條件：
2    (a) 僅得使用附件 C 所列經委託方核准之工具及方案等級；
3    (b) 所用方案須為企業版且已關閉「以輸入內容訓練模型」之設定；
4    (c) 委託方之原始碼、資料庫結構、個人資料，不得輸入任何
5        未列於附件 C 之工具或公開服務。
65.2 供應商應確保所有 AI 輔助產出之程式碼，均經其具名工程師
7    實質審閱、修改與測試，並以該工程師之 commit 署名交付。
85.3 供應商保證 AI 輔助產出不包含逐字複製之第三方受保護程式碼。
9    供應商應啟用工具之來源比對／參考過濾功能（如有）。
105.4 供應商應於每月交付報告中揭露 AI 輔助之大致使用範圍
11    （如：測試撰寫、樣板生成、文件整理），惟不需逐行標註。

附件 C 建議用一份簡單清單管理，而非埋在條文裡：

1# annex/C-ai-policy.yml
2approved_tools:
3  - name: GitHub Copilot Business
4    training_optout: true
5    reference_filter: enabled
6    allowed_for: [boilerplate, unit_tests, refactor]
7  - name: Claude (Team/Enterprise via API)
8    zero_retention: true
9    allowed_for: [documentation, code_review, test_data_synthesis]
10prohibited:
11  - 任何免費或個人版 LLM 網頁介面
12  - 將生產環境資料庫匯出檔作為 prompt 輸入
13data_rules:
14  pii_in_prompt: forbidden
15  secrets_in_prompt: forbidden
16  customer_source_code: enterprise_tools_only

第 6 至 7 條：保密、個資與跨境傳輸

跨境外包最容易被忽略的合規缺口，是「開發團隊看得到生產資料」。一旦越南或菲律賓的工程師為了除錯下載了一份含客戶姓名電話的資料庫，你就同時觸發了多部法律。

各地基準線（供你在 DPA 中引用正確法源）：

• 香港：《個人資料（私隱）條例》（第 486 章）訂有六項保障資料原則，並於第 65 條規定委託代理人處理資料者，委託方仍須負責。
• 新加坡：《個人資料保護法》（PDPA）自 2020 年修訂後，嚴重違規之罰款上限可達機構本地年營業額的 10%（適用於營業額超過 1,000 萬新元者），以較高者為準。
• 越南：第 13/2022/NĐ-CP 號個人資料保護法令自 2023 年 7 月 1 日生效，要求進行資料處理影響評估並向公安部備案。
• 菲律賓：2012 年《資料私隱法》（共和國法令第 10173 號）要求個人資訊控制者與處理者間簽署書面協議。
• 歐盟：若涉歐盟居民資料，跨境傳輸須採用執委會 2021/914 號決定之標準契約條款（SCC），違規最高可罰 2,000 萬歐元或全球年營業額 4%。

16.2 供應商不得於非生產環境使用委託方之真實個人資料。
2    測試資料須經不可逆之假名化或以合成資料替代。
36.3 供應商人員存取生產環境，須經委託方逐次書面核准，
4    並透過委託方指定之堡壘主機進行，全程錄影留存九十（90）日。
57.1 供應商為委託方之資料處理者，僅得依委託方之書面指示處理個人資料。
67.2 供應商使用次處理者（含雲端供應商）須事前書面同意，
7    現行清單見附件 E；變更前三十（30）日通知，委託方得異議。
87.4 發生個人資料外洩事件，供應商應於知悉後二十四（24）小時內
9    以書面通知委託方，並提供已知之影響範圍、資料類別及緩解措施。
107.5 若涉歐盟居民資料，雙方同意簽署執委會 2021/914 號決定之
11    標準契約條款模組二（控制者至處理者），並以其為準。

二十四小時的通報窗口不是隨意設的——GDPR 要求控制者在知悉後 72 小時內通報監管機關，供應商若拖到第 60 小時才說，你已經沒有調查時間。

第 8 至 10 條：SLA、責任上限與賠償

第 8 條 保固與服務水準

18.1 供應商就每項驗收通過之交付物，提供九十（90）日缺陷保固，
2    期間內修復不另計費。
38.2 維運期間之回應與修復目標（辦公時間：香港時間 09:00–18:00）：
4    Severity 1（服務中斷）：回應 1 小時，緩解 4 小時
5    Severity 2（主要功能受損）：回應 4 小時，修復 2 個工作天
6    Severity 3（次要缺陷）：回應 1 個工作天，修復 10 個工作天
78.3 供應商連續兩個月未達 Severity 1 之緩解目標，委託方得就該月
8    月費請求百分之十（10%）之服務抵免，抵免總額以月費百分之三十（30%）為上限。

分佈在香港、台灣、越南與澳洲的交付團隊，在這裡有結構性優勢：跨時區輪值可以把「4 小時緩解」落在實際有人清醒的時段，而不是靠工程師半夜爬起來。SLA 的數字應該反映團隊的實際地理分佈，而不是抄來的模板。

第 9 條 責任上限

19.1 除第 9.2 條所列情形外，任一方於本合約項下之累計責任總額，
2    以委託方於請求發生前十二（12）個月內實際支付之服務費總額為上限。
39.2 下列情形不適用前項上限：
4    (a) 第 4 條之智慧財產權侵權賠償；
5    (b) 第 6、7 條之保密與個人資料義務違反；
6    (c) 故意不當行為或重大過失；
7    (d) 人身傷害或死亡。
89.3 任一方均不就間接損失、利潤損失、商譽損失負責。

第 9.2(b) 的例外是談判焦點。供應商通常希望個資責任也納入上限，委託方則希望完全不設限。折衷做法是為個資責任設一個較高的分項上限（例如合約總額的三倍或一個固定金額），而非無限責任——無限責任往往導致小型供應商無法投保，反而在真的出事時什麼都拿不到。

第 11 至 13 條：終止、退出轉移與爭議解決

第 11 條 終止與退出協助

退出條款是外包合約中被寫得最草率、但代價最高的一條。沒有它，你在關係破裂時拿不到 repo 存取權。

111.4 本合約因任何原因終止或屆滿時，供應商應於三十（30）日內：
2     (a) 移交全部原始碼至委託方指定之 Git 遠端，含完整 commit 歷史；
3     (b) 移交基礎設施即程式碼（Terraform／Docker 設定）與環境變數清單；
4     (c) 移交所有網域、憑證、第三方服務帳號之管理權限；
5     (d) 提供不少於二十（20）小時之知識轉移會議並錄影；
6     (e) 依委託方書面指示刪除或返還全部委託方資料，並出具刪除確認書。
711.5 前項退出協助依附件 B 之費率計費，委託方於終止通知時預付。
811.6 供應商不得以任何費用爭議為由，扣留原始碼、資料或帳號存取權。

第 11.6 條值得單獨強調。最常見的僵局是供應商以未付款為由鎖住生產環境，此時即使你法律上占優，實務上仍動彈不得。

第 12 條 準據法與爭議解決

跨境合約若不指定仲裁，你可能要到供應商所在國法院起訴，成本與時間都難以估計。香港與新加坡都是《紐約公約》締約地區，仲裁裁決在越南、菲律賓、印尼均可循公約程序申請承認與執行。

112.1 本合約之準據法為香港特別行政區法律。
212.2 因本合約所生之爭議，應提交香港國際仲裁中心（HKIAC），
3     依提交仲裁通知時有效之《HKIAC 機構仲裁規則》以仲裁方式解決。
412.3 仲裁地為香港，仲裁員一（1）名，仲裁語言為英文。
512.4 爭議金額低於（金額）者，雙方同意適用 HKIAC 簡易程序。
612.5 本條不妨礙任一方向任何有管轄權之法院申請臨時性或保全性救濟。

新加坡國際仲裁中心（SIAC）是同樣可行的替代選項，若供應商主體在新加坡或印尼，選 SIAC 有時更容易被對方接受。重點不是哪一家更好，而是要指定一家，並寫清楚仲裁員人數與語言——沒寫人數，預設可能是三名，成本直接翻倍。

第 13 條 語言版本

中英雙語合約必須指定一個以何者為準，否則翻譯歧異會變成新的爭點。

113.1 本合約以中文及英文作成。兩種版本如有歧異，以英文版本為準。

若對方團隊主要以越南文或印尼文作業，可另備譯本供內部理解，但在條文中明確寫明該譯本「僅供參考，不具法律效力」。

組裝流程：從範本到簽署的七個步驟

1. 建立 repo：依前述目錄結構建立 contracts/，把本文條文貼進對應檔案。
2. 填寫附件：附件 A（驗收）、B（費率）、C（AI 政策）、D（供應商既有元件）、E（次處理者）。附件比條文更常需要修改。
3. 內部法務審閱：只審 MSA 與 DPA，SOW 交由專案負責人。
4. 寄送 redline：以 PR 形式或 Word 追蹤修訂寄給供應商，要求標註每處修改理由。
5. 談判三個焦點：責任上限例外（9.2）、智財既有元件範圍（4.2）、退出費率（11.5）。其餘多半可接受。
6. 合規檢核：確認 DPA 的次處理者清單與實際雲端區域一致（例如供應商說在新加坡，但 staging 其實開在 ap-southeast-1 以外的區域）。
7. 電子簽署：DocuSign 或 Adobe Acrobat Sign。香港《電子交易條例》（第 553 章）承認電子紀錄與電子簽署之法律效力，惟部分文件（如不動產轉易）除外。

Branch8 在為一家大中華地區的上市珠寶零售集團與一家香港多品牌餐飲集團建置跨境交付安排時，採用的就是這種四層結構搭配 Git 管理的變更單流程；把驗收標準寫成可在 CI 重跑的 Playwright 與 Lighthouse 腳本，讓「交付是否合格」不再是每月例會的辯論題。

常見問題排解

供應商拒絕接受無限期的個資責任

這是合理的立場。改為分項上限（例如年費的三倍），並要求供應商提供專業責任險或網路責任險的保單證明。保險比無限責任更能實際賠到錢。

供應商堅持準據法為其所在國

折衷方案：準據法用中立第三地（香港或新加坡），仲裁地同樣中立。若對方仍拒絕，退一步改為「原告就被告」——誰提起仲裁，就到對方所在地的仲裁機構。這對雙方都構成提告成本，通常能促成談判解決。

驗收一直不通過，專案卡住

檢查附件 A 是否寫了不可測量的標準（「使用者體驗流暢」）。把每一條改寫成可以在 CI 跑出 pass/fail 的斷言。若標準本身就模糊，第 3.5 條的三次重驗機制也救不了你。

合約簽了，但實際工作的是另一家公司

這是東南亞外包的常見情況。第 6 條之外應加入轉包限制：

16.5 供應商未經委託方事前書面同意，不得將本合約之任何部分轉包。
2    經同意之轉包商，供應商仍須就其行為如同自身行為般負責，
3    並確保轉包商受不低於本合約之保密與個資義務拘束。

關鍵工程師離職，交付品質驟降

加入關鍵人員條款：指名兩到三位核心人員，更換須事前通知並提供同等資歷替代者，且新人交接期間的工時不計費。這條比任何品質保證條款都有效。

三個市場的實務差異，值得在附件中註明

越南

第 13/2022/NĐ-CP 號法令的備案義務落在資料處理者身上。若你的開發團隊在胡志明市或河內，DPA 應明確要求供應商自行完成當地備案，並提供證明。

菲律賓

共和國法令第 10173 號下，國家私隱委員會（NPC）要求個人資訊處理者與控制者間有書面協議，並對資料外洩有通報義務。時區上菲律賓與香港同為 UTC+8，SLA 的辦公時間定義相對單純。

台灣與澳洲

台灣《個人資料保護法》與香港 PDPO 概念接近，工程文化與繁體中文文件相容性高，適合放需要與香港總部密集溝通的角色。澳洲則能補上 UTC+10/+11 的時區，讓 Severity 1 的夜間覆蓋不靠 on-call 苦撐。這種多市場組合的價值不在成本，而在於你能把 SLA 的數字寫得比競爭對手更激進，而且真的做得到。

合約條文最終只是把這些安排寫下來的方式。先設計交付結構，再寫合約；順序反過來，就會得到一份法務滿意、但沒有人能執行的文件。

如果你正在規劃跨境開發外包，或想把現有的供應商合約重構成可執行、可驗收的四層結構，Branch8 的香港團隊與新加坡、台灣、越南、馬來西亞、菲律賓、澳洲的交付據點可以協助你檢視合約架構與交付流程的落差。歡迎聯絡我們討論你的專案。

Sources

• Hong Kong Privacy Commissioner for Personal Data — PCPD
• Hong Kong International Arbitration Centre — HKIAC
• Singapore Personal Data Protection Commission — PDPC
• European Commission — Standard Contractual Clauses for International Transfers
• National Privacy Commission of the Philippines
• U.S. Copyright Office — Copyright and Artificial Intelligence
• Singapore International Arbitration Centre — SIAC
• OWASP CycloneDX — SBOM Standard