台灣新創外包工程師合約必備條款 2026 全解析

外包工程師合約在台灣的四大核心是：IP 歸屬（著作權法第 12 條的預設不利於發案方，必須以約定推翻）、NDA（含營業秘密與 AI 工具使用限制）、個資與跨境傳輸條款，以及可量測的 SLA。缺少任一項，交付物你可能拿不到完整權利。

為什麼 2026 年不能沿用 2019 年的合約範本

過去三年有三件事改變了外包合約的風險結構。

第一，AI 輔助開發成為常態。根據 Stack Overflow 2024 年開發者調查（Stack Overflow Developer Survey），超過七成受訪開發者表示正在使用或計畫使用 AI 開發工具。這意味著你付費取得的程式碼，有相當比例是由 LLM 產出、由承攬方審閱後提交。誰擁有它？訓練資料授權有沒有污染？舊版合約完全沒有處理。

第二，跨境團隊變成主流配置。台灣新創現在常見的組合是：台北的產品負責人、越南或菲律賓的前後端工程師、新加坡的資料合規顧問。單一司法管轄區的合約條文，撐不住三地交付。

第三，個資與資安要求收緊。歐盟 GDPR 第 28 條對「資料處理者」的合約義務有明列清單（European Data Protection Board），而台灣《個人資料保護法》第 4 條也規定受委託處理個資者視同委託機關，責任會回頭找你。若你的用戶包含歐盟或英國居民，外包合約就必須夾帶資料處理附錄（DPA）。

實務上我們看到最多的失誤，不是條文寫得不好，而是根本沒寫。用一頁的報價單當合約，交付完成才發現 repository 在對方的個人帳號下。

IP 歸屬條款怎麼寫才在台灣站得住腳？

這是最常被誤解的一段。很多創辦人以為「我付錢，所以程式是我的」——在台灣法制下不完全成立。

依《著作權法》第 12 條（全國法規資料庫），出資聘請他人完成之著作，若未約定著作權歸屬，著作人為受聘人（承攬方），出資人僅取得利用權。也就是說：沒有明確約定，你只能用，不能主張所有權，也難以主張改作或再授權給第三方。

若你雇用的是正式員工（僱傭關係），《著作權法》第 11 條的預設對雇主較有利；但外包工程師通常屬《民法》第 490 條的承攬關係，適用第 12 條。這個差別，決定了你未來募資實地查核（due diligence）時能不能通過。

三個一定要寫進去的子條款

1. 著作人身分與著作財產權讓與：明定甲方（發案方）為著作人，或至少約定著作財產權自完成時無償讓與甲方，並包含後續改作、重製、公開傳輸、再授權之全部權利。
2. 著作人格權不行使：著作人格權在台灣不得讓與，但可約定不行使。缺這一句，對方理論上可主張姓名表示權干擾你的產品。
3. 職務發明與專利：若交付物含可專利化的技術方法，需一併約定專利申請權與專利權歸屬，並要求承攬方協助辦理讓與登記。世界知識產權組織（WIPO）在其專利申請指引中亦指出，發明人與申請權人分離時需有明確書面依據。

可直接改寫的條文骨架：

1第 X 條（智慧財產權歸屬）
21. 乙方依本契約完成之全部工作成果（包含但不限於原始碼、
3   設計檔、資料庫結構、腳本、文件、測試案例，下稱「工作成果」），
4   雙方合意以甲方為著作人；如依法不能，乙方同意於各階段
5   工作成果完成時，將著作財產權全部無償讓與甲方，且不另行請求報酬。
62. 乙方同意對甲方及甲方之受讓人、授權人不行使著作人格權。
73. 工作成果中如含可申請專利之技術，其專利申請權及專利權歸甲方所有，
8   乙方應無償提供必要文件與簽署協助。
94. 乙方保證工作成果未侵害任何第三人智慧財產權；
10   如有第三人主張權利，乙方應負責處理並賠償甲方因此所生損害。

AI 生成程式碼的歸屬灰區怎麼處理

多數司法管轄區目前對純 AI 生成內容的著作權保護態度保守——美國著作權局（U.S. Copyright Office）在其 AI 相關登記指引中要求申請人揭露並排除非人類創作部分。台灣智慧財產局（TIPO）在著作權相關函釋中同樣以「人類創作」為保護前提。

實務上你不會禁用 AI（禁了成本會回升、交期會拉長），但要控制三件事：

1. 揭露義務：要求承攬方揭露使用的 AI 工具與版本（例如 GitHub Copilot、Cursor、Claude Code），以及是否啟用企業版的資料不用於訓練設定。
2. 來源過濾：要求啟用可疑相似度過濾（GitHub Copilot 提供 duplication detection filter，見 GitHub Docs），並保留設定截圖作為交付附件。
3. 保證與擔保不打折：不論程式碼由人或模型產出，第三人權利不侵害之保證條款一律適用。這是最關鍵的一句——把舉證與風險留在能控制生成過程的一方。

1乙方使用生成式 AI 工具協助開發者，應於交付時列明工具名稱、版本
2及是否啟用相似碼過濾功能；不論工作成果之產生方式，
3第 X 條第 4 項之不侵權保證均適用。

NDA 該保護什麼，又常漏掉什麼？

NDA 在台灣的實效，往往取決於它與《營業秘密法》三要件（秘密性、經濟價值、已採取合理保密措施）能否對接。合約本身就是「合理保密措施」的證據之一，但單靠一紙 NDA 不夠。

常見漏項：

• 未定義機密資訊的範圍與標示方式。寫成「所有資訊」在爭訟時反而難執行。
• 未涵蓋衍生資訊。工程師從你的資料庫觀察到的用戶行為模式、轉換漏斗數據，也要納入。
• 未限制 AI 工具輸入。這是 2026 年最實際的新風險：把客戶資料貼進公開 LLM 介面等於單方面解除保密。條文要明列「不得將機密資訊輸入未經甲方書面核可之第三方 AI 服務」。
• 未約定殘留義務期間。程式碼與架構資訊的價值週期比一般商業資訊長，建議 3–5 年並對營業秘密採無期限。
• 未約定人員範圍與再委任。承攬方轉包給第二層自由工作者是常態，NDA 必須要求下游簽署同等義務並由承攬方負連帶責任。

對跨境團隊還要加一層：管轄與救濟。若工程師在越南或菲律賓，台灣法院的定暫時狀態處分實際執行困難。務實做法是搭配技術控制（權限最小化、離職即撤 token）而非只靠合約嚇阻——OWASP 在其應用安全指引中長期強調最小權限原則（OWASP）。

個資與跨境傳輸：個資法與 GDPR 的交集

如果外包團隊會接觸生產環境資料，合約必須升級為含資料處理附錄的版本。

台灣端：《個人資料保護法》第 4 條規定受委託蒐集、處理或利用個人資料之法人，於本法適用範圍內視同委託機關；施行細則第 8 條列出委託方應為的監督事項，包括資料範圍、安全維護措施、再委託限制與稽核方式（全國法規資料庫）。台灣並已設立個人資料保護委員會籌備處推進主管機關統一化，代表未來稽核強度只會上升。

歐盟端：GDPR 第 28 條要求處理者合約明列處理目的、期間、類別、次處理者核准機制、協助資料主體權利行使與稽核權（European Data Protection Board）。若你的 SaaS 有任何歐盟用戶，這份附錄不是選配。

務實的降風險設計：不要讓外包團隊碰真實個資。

1# 以遮罩後的資料集提供給外部開發環境（PostgreSQL 範例）
2pg_dump --schema-only prod_db > schema.sql
3psql dev_db -f schema.sql
4psql dev_db -c "INSERT INTO users (id, email, phone)
5  SELECT id,
6         'user' || id || '@example.test',
7         '+8869' || lpad((random()*99999999)::int::text, 8, '0')
8  FROM generate_series(1, 5000) AS id;"

合約再補一句：「乙方不得於甲方生產環境以外之任何環境重製含真實個人資料之資料集」。這比事後追究有效得多。

SLA 逐條解析：把「盡力而為」換成可量測條件

開發外包的 SLA 與雲端服務 SLA 不同——你買的不只是「系統可用」，還有「有人會回應」。建議拆成三層。

第一層：交付 SLA（專案期間）

• 里程碑定義：每個里程碑要有可執行的驗收標準（例如「通過附件 B 之 42 條測試案例，且 P1 缺陷為 0」）。
• 缺陷分級與修復時限：P1（阻斷主要流程）4 小時內回應、24 小時內修復或提供繞行方案；P2 一個工作日回應、5 個工作日修復；P3 納入下個迭代。
• 溝通頻率：每週書面進度、每日非同步更新（Slack / Linear 留痕），避免口頭承諾。

第二層：維運 SLA（上線後）

• 可用性目標：以月為單位計算，排除已公告維護窗口。
• 值班覆蓋：這是跨境團隊的結構優勢。台北（UTC+8）、新加坡（UTC+8）、越南（UTC+7）與雪梨（UTC+10/11）組合起來，可在不付夜班加給的前提下覆蓋亞太交易時間；若再加上歐洲客戶的早上，實際上是 follow-the-sun 而非 on-call 疲勞。
• 罰則與上限：服務積分（service credit）機制務實可行，但要寫清上限與請求時效。

可用性計算要在合約裡定義公式，否則雙方會吵分母：

1月可用率 = (總分鐘數 − 排除時段 − 不可用分鐘數) / (總分鐘數 − 排除時段) × 100%
2
399.9% → 每月約 43.2 分鐘容許中斷
499.5% → 每月約 216 分鐘容許中斷
5
6「不可用」定義：連續 5 分鐘以上，合約附件 C 所列健康檢查端點
7回傳非 2xx，且經雙方監控工具（如 Grafana / Better Stack）任一確認。

第三層：AI 輔助交付的品質門檻

這是 2026 年新增的一節。當團隊用 LLM 加速產出，程式碼量會上升，審查負擔也會。GitHub 公布的 Copilot 研究指出使用者在特定任務上完成速度顯著提升（GitHub Docs / GitHub Research），但速度提升不等於品質提升。合約應要求：

• CI 必須通過：靜態分析、測試覆蓋率門檻（例如新增程式碼 ≥ 70%）、依賴弱點掃描。
• 每個 PR 必須有具名人類審查者，AI 生成段落不得自我核可。
• 依賴新增需經核可，避免 LLM 隨手引入冷門套件（供應鏈風險）。

1# .github/workflows/quality-gate.yml（節錄，可作為合約附件）
2jobs:
3  gate:
4    runs-on: ubuntu-latest
5    steps:
6      - uses: actions/checkout@v4
7      - run: npm ci && npm run lint && npm test -- --coverage
8      - run: npx license-checker --production --failOn 'GPL-3.0;AGPL-3.0'
9      - run: npm audit --audit-level=high

原始碼與交付物的控制權要寫進條文

這一段最便宜、最常被忽略、事後最貴。

1. Repository 歸屬：組織帳號必須在發案方名下，承攬方以成員身分加入。不要接受「先放我們這邊，結案再轉」。
2. 雲端帳號與網域：AWS / GCP / Cloudflare 的根帳號與網域註冊人為發案方；承攬方使用 IAM 子帳號。
3. 交付定義：原始碼 + 基礎設施設定（Terraform / Docker）+ 環境變數清單（不含實際密鑰）+ 部署手冊 + 資料庫遷移腳本。合約寫「交付原始碼」是不足的。
4. 審查責任落點：用 CODEOWNERS 把最終合併權留在發案方。

1# .github/CODEOWNERS
2*                     @yourstartup/tech-lead
3/infra/               @yourstartup/founder @yourstartup/tech-lead
4/src/payments/        @yourstartup/tech-lead

開源授權審查不要留到募資才做

第三方套件的授權相容性，是實地查核最常踩雷的項目。AGPL 或 GPL-3.0 出現在 SaaS 後端，可能觸發源碼揭露義務。Linux Foundation 主持的 SPDX 規格（SPDX）已成為軟體物料清單（SBOM）的通用格式，建議在合約中要求每次里程碑附上 SBOM：

1# 以 Syft 產生 SPDX 格式 SBOM，作為驗收附件
2syft dir:. -o spdx-json > sbom-milestone-2.spdx.json

並在條文中列出禁用授權清單與例外核准流程。這比事後律師逐個 review 成本低得多。

終止、過渡與知識移轉

合約分手的品質，決定你損失多少個月。必寫：

• 終止事由與通知期：一般終止 30 日書面通知；重大違約可立即終止。
• 過渡協助義務：終止後 15–30 個工作日內，承攬方須提供交接文件、參與交接會議、回答接手團隊問題（可約定按時計費，但不得拒絕）。
• 資料與存取撤除：所有本機副本刪除並出具書面確認，token / SSH key / 雲端權限即時撤銷。
• 未付款項與已完成部分的權利：明定即使有款項爭議，已付款對應之工作成果權利仍歸發案方，避免被以「留置」為由扣住原始碼。

跨境發案時，合約還要多加什麼？

台灣新創的外包團隊很少全在台灣。不同市場的實務差異：

新加坡

個資適用 PDPA，資料保護條款成熟，常作為區域合規與合約主體所在地。適合放需要對歐美客戶出面的資料處理者角色。

越南 / 菲律賓

工程人力深、時區與台灣相差 0–1 小時，適合長期迭代開發。合約需特別強化：再委任限制、設備與網路環境要求（VPN、公司管理裝置）、以及智財讓與的當地形式要件（部分司法管轄要求書面且具名簽署，不接受純電子勾選）。

澳洲 / 紐西蘭

時區覆蓋亞太尾端與美西早晨，適合放值班與客戶溝通角色。合約多為英美法系語彙，注意 indemnity 與 limitation of liability 的上限寫法要與台灣主約一致，避免兩份文件互相矛盾。

統一治理的做法

用「主服務協議（MSA）+ 各地工作說明書（SOW）+ 資料處理附錄（DPA）」三層結構。IP、保密、責任上限寫在 MSA；範圍、里程碑、SLA 寫在 SOW；個資寫在 DPA。這樣新增一個市場只需簽 SOW，不必重談主約。

我們曾協助一家台灣的 B2B 訂閱制軟體新創，把原本散在四份報價單裡的外包關係，重整為 MSA + SOW 結構，並把 repository 與雲端根帳號收回發案方名下、以 CODEOWNERS 固定合併權限。過程中最花時間的不是條文，而是把既有帳號與密鑰盤點乾淨——這件事永遠比預期久。

簽約前的實務檢核清單

1. 著作財產權讓與 + 著作人格權不行使，兩句都在嗎？
2. 專利申請權有一併約定嗎？
3. AI 工具揭露與相似碼過濾要求寫了嗎？不侵權保證有涵蓋 AI 產出嗎？
4. NDA 有禁止將機密資訊輸入未核可的 LLM 嗎？
5. 下游自由工作者有簽同等保密義務、承攬方負連帶責任嗎？
6. 有 DPA 嗎？外包團隊能不能碰到真實個資？
7. SLA 有可用性公式、缺陷分級、回應與修復時限嗎？
8. Repository、雲端根帳號、網域在你名下嗎？
9. 交付定義包含 IaC、遷移腳本與部署文件嗎？
10. SBOM 與禁用授權清單寫進驗收條件了嗎？
11. 終止後的過渡協助義務與存取撤除時限明確嗎？
12. 責任上限與 indemnity 在 MSA 與各地 SOW 之間一致嗎？

這 12 題全部答「是」之前，不要匯第一筆款。

誠實的取捨

把條文寫緊有代價。要求 IP 全數讓與、SBOM 每期交付、CI 品質門檻、真實個資零接觸，會讓報價上升、談約時間拉長，也可能讓部分優秀的獨立工程師直接退出——他們不想承擔無上限的不侵權保證。

合理的平衡是：IP、保密、個資這三塊不讓；責任上限可談（常見做法是以合約總價或近 12 個月費用為上限，但智財侵害與故意違反保密另立較高上限）；SLA 罰則以服務積分而非違約金起步，等合作穩定再談升級。把談判籌碼花在真正決定公司價值的地方。

如果你正在建立跨越台灣、新加坡與東南亞的工程交付結構，Branch8 以香港為總部、在新加坡、台灣、越南、馬來西亞、印尼、菲律賓與澳洲設有交付團隊，熟悉 MSA / SOW / DPA 三層合約結構與跨境工程治理的實務落地。歡迎與我們談談你的合約與團隊配置該怎麼設計。

Sources

• 全國法規資料庫 — 中華民國法規查詢（著作權法、個人資料保護法、民法）
• 經濟部智慧財產局 — 著作權與專利權主題資訊
• European Data Protection Board — GDPR 指引與處理者義務
• U.S. Copyright Office — Copyright and Artificial Intelligence
• Stack Overflow — Annual Developer Survey
• GitHub Docs — GitHub Copilot documentation
• SPDX (Linux Foundation) — Software Bill of Materials specification
• OWASP Foundation — Application Security Guidance