法務評估AI供應商必看：隱私、DPA與認證清單

目錄

• 為什麼「把條款讀一遍」解決不了
• 檢查清單：簽署前的八個問題

  • 1. 有沒有可簽署的DPA（Data Processing Agreement／資料處理協議）？
  • 2. 資料在哪裡處理和儲存（資料駐留）？
  • 3. 資料保留窗口是多久？
  • 4. 有沒有真正的訓練退出選項（「不要用我的資料訓練」）？
  • 5. 有沒有子處理者名單？
  • 6. 帳號管理員能否存取稽核日誌？
  • 7. 持有哪些認證，從何時起？
  • 8. 供應商內部，合規問題該寫給誰？
• 評估會議用的彙總表
• 紅旗：有些回答本身已經是答案
• 這和員工不該再貼上的內容有何關係
• 常見問題

  • 簽了DPA，用客戶資料使用AI的風險就消失了嗎？
  • 公司用的每一種AI工具都需要單獨的DPA嗎？
  • 簽署之後，如何確認供應商政策仍是現行版本？
  • 這是否同樣適用於嵌在其他軟體裡的AI功能（例如自帶AI的CRM）？

為什麼「把條款讀一遍」解決不了

AI供應商的服務條款會改，有時一年改好幾次，而且往往依產品分層：消費級聊天、API、團隊方案和第三方整合，在同一品牌下可能受不同文件約束。今天把「這家供應商不用我們的資料訓練」當成固定事實來說，是那種很快就會過時的句子。

所以操作上的答案不是記住某一條政策，而是裝進一套流程：每評估一個新工具就跑一遍檢查清單；已經在用的供應商條款變更時，再跑一遍。

檢查清單：簽署前的八個問題

每個問題都要有供應商的書面回覆，不能只憑業務通話留下的印象。

1. 有沒有可簽署的DPA（Data Processing Agreement／資料處理協議）？

DPA界定誰是控制者、誰是處理者，供應商能對你送來的資料做什麼、依據哪些規則。如果供應商沒有涵蓋你正在評估的方案類型的DPA，或只從某一檔企業合約起才提供，這是買哪個方案之前就要掌握的資訊——不是之後。

具體問法：「能否把我正在評估的方案對應的現行DPA發給我？」如果回覆要等好幾週，或沒人知道該往上呈報給誰，這本身就說明了供應商合規團隊的真實體量。

2. 資料在哪裡處理和儲存（資料駐留）？

有的供應商允許選擇處理區域（例如歐盟或美國）；有的不行，或只在高階方案提供。如果你的公司受制於「某些資料不得離開某一地區」、或國際傳輸須通知的制度，這就不是技術細節，而是合規條件。

請查閱所評估供應商的現行政策，因為它經常變，有時依開立發票的國家變，而不只依方案類型變。

3. 資料保留窗口是多久？

「我們不用你的資料訓練」和「我們不保存你的資料」不是一回事。這是兩個不同的承諾。請明確問：

• 對話內容或處理過的文件會保留多久？
• 該期限客戶能否自行設定？
• 如果我們取消合約，資料會怎樣？

4. 有沒有真正的訓練退出選項（「不要用我的資料訓練」）？

許多供應商提供某種訓練 opt-out 機制，但範圍各異：可能只適用於聊天、不適用於API，只涵蓋某些方案，或要求每個使用者單獨開啟，而不是企業帳號級政策。請對方就你實際要用的那個產品書面確認，而不是籠統的「這個品牌」。

5. 有沒有子處理者名單？

子處理者是供應商為提供服務而使用的任何第三方（雲端基礎設施、支援工具、翻譯服務等）。認真的供應商會公布或應要求提供子處理者名單，並在變更時通知。如果你與自己客戶的合約要求告知「誰在處理他們的資料」，你需要這份名單來履行自己的責任鏈。

6. 帳號管理員能否存取稽核日誌？

對合規來說，問題不只是「供應商留不留日誌」，而是「我作為本公司帳號的管理員，能否看到誰用了工具、何時用、細到什麼程度？」。沒有這一點，事件後的內部調查就只能向供應商要資料，並受制於對方的時程。

7. 持有哪些認證，從何時起？

SOC 2（Type I 或 Type II）、ISO 27001，以及特定產業認證（醫療、金融），是供應商證明控制措施經第三方核驗、而非自我聲明的標準方式。要報告或證書，不要只看價格頁上的標誌。沒有日期、沒有明確範圍的標誌不是證據。

8. 供應商內部，合規問題該寫給誰？

成熟的供應商有可識別的管道（信任中心、隱私信箱、安全入口網站），與一般支援分開。如果唯一路徑是業務聊天，將來要解決合約疑問、或應對政策變更，速度就會受限。

評估會議用的彙總表

把這張表當作與供應商會議的紀錄。若有任何一列留白，就是核准前還沒回答的問題。

待核實事項	供應商回覆	證據（文件 / 連結）
所評估方案是否有DPA
資料駐留 / 國際傳輸
資料保留窗口
訓練退出（確切範圍）
子處理者名單
帳號管理員的稽核日誌
現行認證（SOC 2、ISO 27001、其他）
合規聯絡人 / 信任中心

紅旗：有些回答本身已經是答案

• 「我們不用你的資料訓練，相信我們就好」，卻沒有任何文件支撐。面向消費者的通用隱私政策不是DPA。
• DPA只在「X個席次起」或「Enterprise 方案」才有，而且等你已經用最便宜的方案推進評估後，才有人告訴你。
• 沒有人能說清聊天產品和API在保留或訓練上的差別。 同一供應商內部，它們常常是不同產品、不同規則。
• 子處理者名單不存在或不更新。 連還有誰會碰到資料都不清楚，對那些資料也保證不了什麼。
• 認證被提起，但拿不出來。 要證書或報告摘要，不要標誌清單。
• 唯一的合規管道是業務團隊。 靠成交拿佣金的人回答合約問題，和專職合規管道不是同一種保障。

這和員工不該再貼上的內容有何關係

這份清單在簽署前篩選供應商。但即便簽了最好的DPA，日常仍有一層決策：每一段與AI的對話裡，具體放進什麼資訊。那一部分——什麼不該分享、個人方案和團隊方案的差別、如何寫出團隊能遵守的一頁政策——寫在企業使用AI時的安全與隱私。兩份清單互補：一份給採購前的法務，一份給每天的全員。

常見問題

簽了DPA，用客戶資料使用AI的風險就消失了嗎？

沒有。DPA界定責任和合約承諾，但不能替代「首先上傳什麼資訊」的操作判斷。它降低合約與合規風險；它不能替代內部使用政策。

公司用的每一種AI工具都需要單獨的DPA嗎？

原則上是，一家供應商一份，因為各自按自己的條款處理和保留資料。如果公司用多種AI工具（聊天、逐字稿、圖像生成、自動化），本文的清單應對每一家跑一遍，而不是只跑主力那一家。

簽署之後，如何確認供應商政策仍是現行版本？

在合規行事曆裡加上定期複查——按季度或半年——看供應商的信任中心或隱私頁面。保留、訓練和子處理者政策會變，公開政策變更時，已簽署的DPA並不總會自動更新。

這是否同樣適用於嵌在其他軟體裡的AI功能（例如自帶AI的CRM）？

適用，而且經常被忽略。如果你的CRM、辦公套件或客服系統加了AI功能，該功能背後可能有自己的語言模型子處理者，以及自己的保留政策。直接問那個供應商用的是什麼模型、依據哪些條款，不要假定它繼承了原軟體合約的保障。

---

沒有哪家AI供應商會主動把這份清單寄給你——它是給你帶到會上的。把「已準備好面對受監管情境」的供應商和「還沒有」的供應商分開的，不是「他們的AI好不好」，而是能不能拿著文件回答上面八個問題。如果不能，這已經足夠你做決定，哪怕還沒看示範。