GDPR 與 AI 聊天機器人：企業必須知悉的事項

AI 聊天機器人會處理哪些個人資料？

一旦用戶與 AI 聊天機器人互動，就會產生數據。最明顯的是對話本身的內容：文字輸入、提問、投訴及預訂詳情。這些對話數據在許多情況下均屬《通用數據保護條例》（GDPR）所指的個人數據——無論是因為它們包含姓名或電郵地址等直接識別資料，還是因為它們與其他可取得的數據結合後可歸屬於特定人士。在網頁聊天時以技術方式傳輸的 IP 地址，同樣被視為個人數據。

在客戶帳戶流程中使用的聊天機器人會涉及額外資料類別：客戶編號、訂單歷史、付款資料（若聊天機器人整合於結帳流程）或健康資料（於醫療應用中）。根據《通用資料保護條例》第 9 條的這些特殊類別須受更高級別保護，並需要特別技術及法律安排。

數據最小化原則（GDPR 第 5 條第 1 款 c 項）要求只處理對相關目的實際必需嘅數據。對於一個冇身份驗證嘅純 FAQ 聊天機器人，即係話：對話內容唔應該永久儲存，IP 地址應該匿名化，而個人資料只應該喺服務流程絕對需要時先收集。所以，一個細心設定嘅聊天機器人，喺數據保護法方面嘅問題明顯少過一個規劃差嘅聊天機器人。

聊天機器人運作嘅 GDPR 要求

《通用資料保護條例》為每項資料處理活動訂定一系列基本要求。首先，每項資料處理均需有《通用資料保護條例》第 6 條規定的法律依據：即用戶同意、合約必要性、企業合法利益或法律列明的其他依據。法律依據必須在處理前釐清並記錄，且在存疑時須能向資料保護監督機構作出合理說明。

第二，須向受影響人士履行全面的資料披露責任。用戶必須清楚知悉其資料被處理的用途、儲存時限、可能接收資料的對象，以及他們擁有的權利——包括查閱、更正、刪除及限制處理資料的權利。這些資訊須以清晰易明的語言提供，通常載於私隱政策內，並透過聊天視窗中的提示予以說明。

第三，《通用資料保護條例》（GDPR）規定「設計即私隱及預設即私隱」原則（第 25 條）。這意味著：私隱友善的設定應自始為預設選項，而非事後補上。就 AI 聊天機器人而言，實際做法包括：採用較短的儲存期限作為標準、對日誌資料進行匿名化、實施嚴格的存取權限，以及讓用戶能透過簡單途徑刪除其資料。

雲端 AI 對比本地部署：對資料私隱有何影響？

基於雲端的 AI 聊天機器人會將對話資料及查詢發送至語言模型供應商的外部伺服器進行處理，並視乎設定，可能用於訓練目的。評估 GDPR 合規性的關鍵在於：伺服器位於哪個國家？對於美國供應商，自 Schrems II 判決以來，法律情況相當複雜。歐盟供應商或設有歐盟數據中心的供應商，在歐洲數據保護法下明顯較受青睞。此外，還須簽訂數據處理協議（AVV）。

「本地部署」（On-Premises）意指整個基礎設施——包括 AI 模型——均在企業自行控制的伺服器上運行。透過本地 AI 執行，對話資料不會離開企業自身的基礎設施。因此，完全無需與雲端 AI 供應商簽訂數據處理協議（AVV）；所有處理工作均於內部進行。對於受規管行業（如醫療、法律諮詢及金融服務）的企業而言，本地部署往往是唯一站得住腳的選擇。

混合方案亦屬可行：聊天機器人基礎設施及知識庫在歐盟境內的安全伺服器運行，而某些較不敏感的應用場景則採用雲端模型。Zentor App 支援兩種運作模式——透過外部 AI 供應商的雲端模式，以及完全本地運作——並讓企業自行決定哪種架構最切合其數據保護策略。理想情況下，這個決定應與數據保護主任及數據保護律師共同作出。

資料處理協議 (AVV)：何時需要及涵蓋哪些內容

根據 GDPR 第 28 條的數據處理協議（AVV），是在法律上規管企業（委託方）與代其處理個人數據的外部服務供應商（受託處理方）之間責任的核心工具。當透過 SaaS 平台運作 AI 聊天機器人時，通常必須簽訂 AVV：聊天機器人供應商會在其伺服器上處理對話數據——這屬於典型的受託數據處理。

資料處理協議（AVV）須以書面形式或同等電子格式訂立，並涵蓋一系列最低內容：處理的對象及期限、處理的類型及目的、個人資料類別及受影響人士類別，以及資料控制者的責任與權利。此外，資料處理者須保證實施適當的技術及組織措施（TOMs），且未經許可不得委任次級資料處理者。

重要：聊天機器人投入運作前，必須完成 AVV，不可事後補辦。即使存在受託處理卻欠缺 AVV，本身已屬違反 GDPR，並可被罰款。因此，請向每個聊天機器人供應商確認其是否提供 AVV 及以何種形式提供、會採用哪些次級受託處理者（例如雲端供應商或外部 AI 供應商），以及如何處理相關事宜。正規供應商如 Zentor App 會提供標準化 AVV 範本，並願意公開透明地披露其內容。

資料私隱主任與聊天機器人：需注意什麼？

設有內部或外部數據保護主任（DSB）的企業，在引入 AI 聊天機器人時，必須讓其參與。DSB 的職責是確保系統以符合數據保護的方式實施、評估風險並監督 GDPR 的遵從情況。這不僅涉及形式上的合規，更關乎具體的技術配置：儲存哪些資料？儲存多久？誰有存取權？如何處理受影響人士的查閱請求？

在聊天機器人情境下，數據保護官（DSB）最重要的任務之一是檢視是否根據《通用數據保護條例》（GDPR）第 35 條需要進行數據保護影響評估（DSFA）。當數據處理預計會對自然人的權利和自由構成高風險時，便須進行 DSFA。若聊天機器人系統性地處理敏感數據、進行用戶畫像，或用於對受影響人士有重大影響的決策，便可能出現此情況。

即使法律未規定必須設立數據保護官（DSB），在正式上線前進行數據保護檢視仍屬建議。特別是首次採用聊天機器人的中小型企業，常見陷阱包括：缺少或過時的隱私政策、遺漏數據處理協議（AVV）、數據存儲期限過長或缺乏刪除機制。在此情況下，尋求數據保護專家的外部諮詢可帶來長遠效益，並避免監管機構可能開出的高額罰款。

聊天機器人的技術及組織措施 (TOMs)

GDPR 第 32 條規定，須採取適當的技術及組織措施（TOMs），以確保與風險相稱的保護水平。對 AI 聊天機器人而言，具體即是：用戶瀏覽器與聊天機器人後端之間的所有數據傳輸均須加密（TLS/HTTPS）。已儲存的對話數據及知識庫內容亦應加密存放——無論是在數據庫內還是相關儲存媒體上。

在存取方面，GDPR 規定了數據存取限制原則：只有工作上確實需要的員工及系統，才可存取個人數據。Zentor App 以基於角色的存取控制（RBAC）系統落實此原則，該系統是 Individuell 方案中可自由選擇的模組：不同角色獲得不同存取權限，所有存取均記錄於審計追蹤中。如有疑問，便可據此證明誰在何時存取了哪些數據。

在組織層面，TOMs 包括清晰的內部流程：誰負責知識庫？如何處理受影響人士的刪除請求？如何確保對話數據不會儲存超過必要時間？若發生數據保護事故（例如聊天機器人意外洩露另一用戶的個人數據），企業如何應對？這些流程必須以書面記錄並定期覆核。

Zentor App 同 GDPR：歐盟託管同本地部署兩種選擇

Zentor App 從一開始就以實現符合 GDPR 的運作為目標而開發。平台可託管於歐盟伺服器——託管、數據庫及應用邏輯因此受歐洲數據保護法規管。如選用外部 AI 供應商，任何在歐盟境外的使用均只會基於歐盟標準合約條款（GDPR 第 46 條）——從而消除不受控第三國傳輸的法律不確定性。對考慮雲端方案的企業而言，歐盟託管是邁向 GDPR 合規的首要及最關鍵一步。

對於數據保護要求最高的企業，Zentor App 提供完整的本地部署安裝。在此運作模式下，整個平台——包括聊天機器人引擎、知識庫、全渠道收件箱及所有處理組件——均運行於企業自行控制的基礎設施上。透過本地 AI 執行，對話數據及個人資料都不會離開企業自身的 IT 環境。此方法特別適合醫院、律師行、稅務顧問公司，以及其他數據保護攸關存亡的行業。

Zentor App 為雲端運作提供數據處理協議（AVV），並在私隱政策第 13 條記錄所採用的次級受託處理者，包括公司名稱、國家、目的及傳輸依據。技術性數據保護功能——RBAC、審計追蹤、可設定的數據儲存期限及基於角色的存取控制——可作為 Individuell 方案中可自由選擇的模組進行設定。藉此，您可建立符合 GDPR 的聊天機器人運作所需的技術條件；至於具體個案的法律安排，始終由您的數據保護團隊及法律顧問負責。

常見問題