符合 GDPR 的 Chatbot：逐步指南 (2026)

符合 GDPR 的聊天機器人需要合法的部署方式，並非只取決於特定模型或主機位置。 應為每項個人資料用途定義目的與合法依據、盤點資料流向、確認各方角色和合約、提供資訊及權利行使程序，並落實符合風險的安全措施。供應商的合規標示無法證明每位客戶的使用方式都符合這些要求。

並非每次客服對話都必須取得同意、只使用歐盟主機，或為歐洲訪客另設模型。你需要的是證據，證明特定工作流程中的選擇符合適用規則。同樣的評估也涵蓋模型供應商、CRM、分析工具、渠道整合和營運日誌。

本指南於 2026 年 11 月 4 日對照官方來源檢查。內容提供評估架構及實作範例，不會認證某項部署，也不能取代針對具體法律情況的建議。

選用範例檢查

• 預覽中繼資料鍵。檢查提供的欄位名稱如何轉成變數鍵，包括重複名稱和保留鍵錯誤。這不會檢查欄位值或特定帳號的權限。
• 驗證測試資料集。檢查提供的小型資料集是否符合支援格式，不會執行你的 AI Agent。

這些檢查不會評估法律合規性。

聊天機器人隱私與安全的 10 步上線檢查表

為每一項指定負責人，並保留決策或測試的證據：

1. 定義工作流程。 區分公開資訊、特定帳號支援、交易、行銷和模型改進。
2. 盤點個人資料。 涵蓋提示、回覆、中繼資料、檔案、擷取的紀錄、日誌和串接系統。
3. 選擇合法依據。 處理前評估每項目的；需要同意時，加入有效的同意流程。
4. 確認角色與合約。 確定誰決定目的、誰依指示處理，並審核適用的處理條款與傳輸。
5. 減少收集。 移除不必要欄位；有限結果足夠時，不要傳送完整客戶紀錄。
6. 定義保留與權利處理。 納入身分查核、存取、更正、刪除、適用時的可攜性，以及下游處理的追蹤。
7. 評估風險。 判斷是否需要資料保護影響評估（DPIA），並在相關處理開始前完成。
8. 保護存取與整合。 採取適當的加密、驗證、權限、監控及事件處理程序。
9. 告知使用者。 公開正確的隱私資訊、提供必要的 AI 揭露，並另外評估小工具儲存行為。
10. 測試並指定持續負責人。 演練失敗情境、訓練員工，並在目的、供應商或功能變更時重新評估。

GDPR 原則及其對聊天機器人設計的影響

GDPR 適用於歐洲經濟區（EEA）機構活動範圍內的相關處理。EEA 以外的組織若向當地人士提供商品或服務，或監控其在當地的行為，也可能受到規範。判斷依據是處理活動及其地域關聯，不只是個人的國籍。EDPB 說明了地域適用範圍和核心原則。

姓名、聯絡資料、線上識別碼，以及可識別個人的對話內容，都可能是個人資料。公開 FAQ 介面仍可能收集識別碼或含有個人資訊的自由文字。

對特定較高級別的違規，最高罰款可達 2,000 萬歐元；若屬企業，則可達上一會計年度全球年營業額的 4%，以較高者為準。實際執法取決於個案情況，請見 EDPB 對監管權力的說明。

本指南使用的名詞

• 控制者： 決定處理目的與主要方式的組織。
• 處理者： 代表控制者處理個人資料的另一實體。角色取決於實際活動，不只取決於合約名稱。
• 假名化： 降低直接連結個人的能力，例如以識別碼取代姓名。這不會自動使資料匿名化。
• DPIA： 當處理可能對個人的權利與自由造成高風險時，必須進行的評估。相關因素包括規模、敏感資料、弱勢人士及重大自動化決策。使用 AI 本身不足以決定是否需要。請參閱 EDPB 的 DPIA 指引及適用監管機關的清單。

將 GDPR 要求轉化為營運流程

從訪客訊息到最終刪除的實際旅程著手。以下設計是說明性實作模式，並非 Quickchat AI 內建功能清單。

從設計落實資料最小化

為每項任務定義 required_fields 結構。預約詢問可能需要偏好時段和聯絡方式；查詢公開營業時間不應要求客戶個人檔案。

網站聊天機器人潛在客戶資料收集指南提供可供評估的具體設定：先回答一般問題，再為訪客要求的後續聯繫收集聯絡資料。用於客戶之前，請依照自身的處理目的檢查欄位及資料接收者。

不只檢查可見表單。即使回答只需要訂單狀態，CRM 查詢也可能取得整份紀錄。限制傳回欄位及送入模型的資料，並避免在提示中放入憑證和無關客戶資訊。

輸入遮罩可避免旁人看到內容，但不能證明原始值未被收集、記錄或傳輸。遮蔽資料可降低意外揭露，但要測試遺漏情形，包括一般句子內的識別資訊。

同意與其他合法依據

歐盟執委會的合法依據指引列出多種可能依據。履行合約所必需的處理、經必要評估的正當利益，以及同意，各自有不同條件。應在處理前選擇依據，而不是為每項任務加上同意勾選框。

依賴同意時，應使目的具體，並確保選擇出於自由意願、充分知情且明確。撤回同意應與給予同意同樣容易。將選擇性行銷與客戶需要的支援分開。確認讀過隱私聲明，本身不等於同意其中描述的每一種用途。

雙重確認可在某些情況下協助建立證據，但不是普遍適用的 GDPR 要求。EDPB 同意指引區分一般同意和明示同意，並將兩階段驗證列為可能方法之一。

如果以同意為依據，應記錄目的、聲明版本、肯定行為、時間和相關識別碼。保護這些證據，並採取有理由支持的保留政策。健康資訊等特殊類別資料，除了第 6 條依據，還需要符合適用的第 9 條條件。

處理存取、刪除與可攜性申請

提供容易使用的申請管道，並指定負責完成申請的人員或團隊。自訂 /my_data 或 /delete_my_data 指令可用來開啟申請，但這兩個指令都不是已驗證的 Quickchat AI 內建功能。對話中表示收到，不代表申請已完成。

可行的程序是以合乎比例的方式驗證身分、找出相關紀錄、評估所行使的權利及例外、協調處理者、完成操作並記錄回覆。匯出資料應透過經驗證的途徑交付，並防止訪客索取其他人的資料。

控制者必須不無故延遲地處理，通常應在一個曆月內完成。若符合延長最多另外兩個月的條件，必須在第一個月內告知本人及理由。刪除有適用理由和例外，包括某些法定保留義務。存取和可攜性也不同：第 20 條可攜權在特定條件下，適用於以同意或合約為依據、自動處理由本人提供的資料。請見 EDPB 權利指南。

Quickchat AI 的不同刪除途徑效果不同。 刪除 AI Agent會讓其對話無法存取，但不會抹除對話。刪除帳號會在背景程序中刪除目前所屬 agents 的對話；文件列出例外，包括先前已刪除 agents 的對話、附件、匯出檔、搜尋索引和外部紀錄。適用的資料刪除程序請聯絡支援。中斷 Meta 渠道連線會停止後續已授權處理，但不會自動刪除歷史對話。

更完整的客服工作流程可參閱客戶服務助理設定指南，那與此處的權利申請程序是不同事項。

儲存限制與保留排程

GDPR 並未為聊天逐字稿設定通用的 30 天或 90 天期限。應依目的與資料類別定義保留規則，並考慮適用法律義務。區分使用中的對話、匯出檔、同意證據、安全日誌和備份。

以下概念性虛擬碼示範排程與驗證，並不是完整刪除實作或既有產品設定：

function scheduleRetention(record, policy) {
  return {
    recordId: record.id,
    purpose: record.purpose,
    reviewOrDeleteAt: policy.dateFor(record),
  };
}

function processDueRecord(item) {
  if (requiresRetentionReview(item)) {
    return queueManualReview(item);
  }
  queueErasureAcrossRecordedSystems(item);
  recordVerificationPending(item.recordId);
}

記錄政策負責人、保留準則、允許的例外、刪除方法和完成證據。監控失敗情況，不要假設排程工作已處理每個系統。

備份必須明確納入考量。EDPB 於 2026 年 2 月發布的刪除權報告指出實務困難，以及系統還原時仍需處理刪除要求。報告並未認定立即從每份備份移除，或等待任何正常到期時間，就一定符合法律。應說明實際限制、刪除排程與還原程序，不要承諾所有資料都能在一個月內刪除。

第 22 條與有實質意義的人工審查

第 22 條涉及完全基於自動化處理、且產生法律效果或類似重大影響的決策。一般 FAQ 回答不會自動屬於此類決策。信貸資格、入學或基本服務的使用資格需要更仔細評估。

建立工作流程前，先找出這些決策點。條文適用時，評估適用例外及保障措施。履約必要性或明示同意例外的保障，包括獲得人工介入、表達意見及對決策提出異議的機會。特殊類別資料另有額外限制。

審查者必須具備重新考慮結果所需的資訊和權限。如果結果實際上仍固定不變，只增加轉交按鈕並不足夠。應以合乎比例的方式記錄實際決策準則、輸入和審查結果；模型產生的說明無法證明重大決策實際如何作成。

符合聊天機器人風險的安全措施

第 32 條要求適當的技術與組織措施，並未指定通用的加密演算法或驗證產品。使用 EDPB 安全指引，將保障措施與可能損害、處理情境和可用技術連結起來。

傳輸中與靜態資料加密

使用適當的加密和金鑰管理，保護網路連線與儲存紀錄。逐一檢查訪客與小工具之間的連線、整合、管理存取、資料庫、匯出檔和備份。

TLS 保護傳輸連線，靜態加密保護儲存資料。這些措施本身不能證明端對端加密，也就是中介者無法讀取內容的加密方式。處理訊息內容的服務可能需要解密。不要把 TLS 1.3 或 AES-256 描述成 GDPR 強制規格或合規證明。

驗證、存取角色與身分整合

管理存取應採用強式驗證，適當時包含 MFA。針對特定帳號的要求，應優先使用現有、經驗證的客戶工作階段，而不是在公開聊天中要求輸入帳號識別碼。

另外審查授權：有效登入不應暴露其他客戶的紀錄。依員工職責提供存取權，並在不再需要時撤除。Quickchat AI 記錄了其團隊角色，請確認可用角色符合你的要求。

有需要時評估企業 SSO，但不要從一般 Google 登入推論具有 SAML 支援。生物辨識可能產生額外資料保護義務，並不是普遍最安全的選項。

API 安全與有限的整合權限

使用範圍受限的憑證，並在串接應用程式中執行授權。要求模型只存取特定客戶資料的指令，不構成存取控制邊界。

採用適當速率限制、驗證結構化參數與輸出，並檢查各項 Action 或整合可讀取或變更什麼。測試跨客戶存取和憑證撤銷情境。記錄接收個人資料的第三方，包括錯誤回報和分析服務。

監控、日誌與事件回應

記錄足以調查存取和失敗情況的資料，不要自動把每段完整對話複製到所有監控系統。為營運日誌另行定義存取、保留和遮蔽規則。

事件程序應涵蓋控制影響、調查、復原、記錄和通報判斷。依 GDPR，控制者在知悉應通報的個人資料外洩後，應不無故延遲，且可行時於 72 小時內通知主管機關；若不太可能對個人權利與自由造成風險，則有例外。可能造成高風險時，可能還需不無故延遲地通知受影響者，但受第 34 條例外約束。處理者應不無故延遲地通知控制者。

這些是不同的義務和門檻；愛爾蘭 DPC 的外洩指引說明了差異。GDPR Digital Omnibus 的提案變更，不是現在改用其他通報期限的理由。

安全評估檢查表

管理聊天機器人特有的 AI 風險

AI 評估應涵蓋模型接收的資訊，以及輸出可能觸發的操作。一般軟體安全控制仍然必要。

提示注入與對抗測試

提示注入可能來自訪客訊息或擷取內容，試圖改變模型的行為。例如，文件可能指示模型揭露私人紀錄或呼叫無關 Action。

區分可信任指示與不可信任內容、限制可用權限、驗證操作參數，並測試未授權存取嘗試。篩選和指示有幫助，但不能保證防止攻擊。OWASP 提示注入指引明確指出，RAG 和微調不能完全減輕這項弱點。

使用合成或經適當準備的測試資料。記錄系統是否拒絕、揭露資訊、呼叫工具或轉交處理；僅有令人安心的最後一句話，不能證明行為安全。

幻覺與回應驗證

模型可能產生看似合理、卻無現有證據支持的答案。從持續維護的 Knowledge Base 擷取內容有助於讓答案有所依據，但本身不能保證事實正確，也不能強制執行權限。

測試過期政策、矛盾來源、缺少紀錄和超出預定範圍的要求。提供回報錯誤的方法，並將未解決案例轉給人員。針對特定帳號的回答，應與獲授權的來源紀錄比對，不要依賴模型的信心程度。我們的 AI 幻覺說明討論其背後行為。

資料外洩、訓練與遮蔽

訓練用途、推論、應用程式狀態和日誌是不同的處理活動。不要假設每則訊息都會訓練模型，也不要把不訓練承諾理解成不傳輸或不保留資料。

Quickchat AI 的法律 FAQ說明，客戶資料不會用來訓練 LLM，並可依要求提供 PII 清理。這不代表每則訊息都經過清理，也不保證所有個人資料都能被偵測。請確認所選設定和供應商條款。

輸入遮蔽必須在欲防止的處理之前發生；輸出遮蔽則在生成之後。移除姓名仍可能留下可識別的上下文。EDPB 區分假名化與匿名化，其 AI 模型意見要求依個案評估是否匿名。

解釋與稽核軌跡的證據

保留合乎比例的擷取來源、操作、相關設定和人工審查證據。不要把生成的說明、內部信心分數或某種解釋技術，自動當成法律合規證明。

Quickchat AI Inbox 的 Why AI said that 可顯示擷取來源和執行證據。這有助於調查回覆，但不是模型內部因果的完整說明，也不能取代對重大決策流程之解釋義務的評估。

國際處理與伺服器位置

盤點儲存、模型處理、支援存取、整合及後續傳輸。資料庫所在地區只回答了位置問題的一部分。

EEA 主機與 EEA 以外的處理

GDPR 並未規定所有資料都必須託管於歐盟。傳輸至 EEA 以外地區，除了其他 GDPR 要求，還需要適用的第五章途徑。EDPB 傳輸指南說明適足性、適當保障和有限的例外。

Quickchat AI 的法律 FAQ 描述在比利時使用 GCP 儲存；其隱私政策另外討論美國傳輸和合約保障。因此，比利時儲存不能證明所有處理都只在歐盟進行。FAQ 也說明企業部署選項，包括私有雲、自行託管 LLM 和地端安排；架構、可用性及責任必須針對具體部署約定。

標準合約條款與歐盟美國資料隱私架構

執委會的現行適足性清單包含參與歐盟美國資料隱私架構的美國商業組織。應驗證接收者仍有效參與，且範圍涵蓋該傳輸。只有美國地址並不足夠。

使用標準合約條款或其他第 46 條工具時，應評估目的地國家的法律與實務是否削弱保障，以及是否需要補充措施。受適足性決定涵蓋的傳輸，不會自動需要相同的額外傳輸評估。兩條途徑都不會免除目的、合法依據、安全或處理者合約義務。

不要把雲端供應商的身分與聊天機器人供應商混為一談。Quickchat AI FAQ 描述的是持續朝 DPF 要求調整，不是已確認參與。

供應商範例：OpenAI API 資料控制

OpenAI 的 API 資料文件指出，除非客戶主動選擇加入，API 輸入和輸出預設不會用於訓練。文件另行說明濫用監控日誌和應用程式狀態。標準濫用監控日誌可能保留最多 30 天，並有法律或安全例外。

Zero Data Retention 和 Modified Abuse Monitoring 需要核准，而且有端點限制。請確認實際帳號、端點、合約和處理位置。消費者版 ChatGPT 的歷史紀錄設定不能證明 API 整合的設定。這些一般供應商條款也不能證明某個 Quickchat AI 帳號具有零保留。

處理者協議與供應商責任

供應商代表你處理個人資料時，第 28 條要求有約束力的合約或其他符合條件的法律文書。應另行評估供應商為自身目的處理資料等用途，不要假設每項活動都有相同角色。EDPB 控制者及處理者指引說明角色區別與合約要求。

必要處理條款及額外 AI 問題

檢查協議是否涵蓋：

• 處理的主題、期間、性質與目的、資料類型、個人類別，以及控制者的權利義務。
• 書面指示，包括傳輸，以及適用的歐盟或成員國法律例外。
• 符合第 32 條的保密與安全措施。
• 事先特定或一般書面次處理者授權；採一般授權時的變更通知與異議機會，以及向下傳遞的必要義務。
• 協助個人權利、安全、外洩處理與影響評估。
• 處理服務結束後，依控制者選擇刪除或歸還資料，並刪除既有副本，除非歐盟或成員國法律要求保留。
• 證明合規所需的資訊，以及稽核和檢查安排。

另外詢問模型訓練、回饋、保留與次要用途。GDPR 並非簡單要求一律禁止所有可能的訓練用途；每項用途都需要適當評估目的、角色與法律條件。

Quickchat AI 公開了資料處理協議。請檢查適用的已簽署條款和支持資訊。公開文件本身不能證明特定合約或部署符合上述所有要求。

與 AI 供應商協商的重點

要求對方具體回答處理位置、次處理者、營運保留、帳號控制、外洩通知和退場程序。區分文件記載的產品設定與特定合約承諾。

詢問停用功能、中斷渠道、刪除 agent 或終止合約後會發生什麼。確認匯出範圍、刪除證據、依法仍須保留的資料及備份處理。責任條款和服務水準既是商業問題，也屬供應商評估的一部分；不要把一般安全聲明當成完整技術附件。

個人化與資料最小化

從回答目前問題所需的最少資訊開始。持續保存的個人檔案需要獨立的目的與評估。

差分隱私與裝置端處理

差分隱私可在合適的統計或訓練應用中，協助限制揭露個人資訊。保護程度取決於實作與參數；提到這項技術，不代表已達匿名化或合法處理。

在訪客裝置上處理偏好，可減少伺服器端收集。應檢查仍會離開裝置的資訊，包括識別碼與遙測資料。即使資訊不是個人資料，裝置儲存或存取也可能涉及 ePrivacy 規範。

分群回答與個人剖析

依據使用者表明的產品類別調整回答，可能比維護長期行為檔案需要更少資料。然而，將已知客戶分配至某個群組，仍可能涉及個人資料處理。

評估實際目的、合法依據、告知、保留和存取控制。並非所有個人化形式都一律需要同意；具有重大影響的自動化決策仍需另外評估第 22 條。拒絕選用剖析時，仍應提供有用的基本服務。

受監管產業的聊天機器人

產業規則取決於實體、活動和司法管轄區。律師事務所 AI 聊天機器人和金融服務 AI 聊天機器人都需要明確區分一般資訊、帳號存取和專業建議。免責聲明本身不能確立這些界線。

醫療：敏感資料與適用的 HIPAA 義務

健康資料除了第 6 條依據，也需要符合適用的 GDPR 特殊類別條件。預約、行政、症狀評估和臨床決策帶來不同風險。牙醫診所 AI 聊天機器人應依預定角色，設置明確且適當的臨床轉介途徑。

在美國，HIPAA 適用於受規範實體及業務夥伴，不會自動涵蓋每一份美國健康資料。適用的業務夥伴關係需要所規定的協議。應與負責組織確認權限、保障及各類紀錄的保留。不要從 GDPR DPA、加密聲明或醫療登陸頁面推論 HIPAA 適用性。

金融：紀錄保存與決策控制

設定保留期限前，先確認適用於機構和紀錄類型的規則。例如，FINRA 第 4511 條針對會員機構，對沒有其他指定期限的 FINRA 紀錄採六年保存期間。這不是每份聊天逐字稿的通用保存規則。

區分公開產品資訊、個人化建議和影響資格的決策。評估授權、專業義務、紀錄保存，以及必要時有實質意義的審查。不要依賴全面禁止金融自動化的假設，也不要依賴允許一切的通用免責聲明。

公部門服務：評估與易於取得的資訊

公家機關通常需要 DPO，但有適用例外；特定 DPIA 是否必要則取決於處理風險。公開 FAQ 聊天機器人和影響福利資格的系統需要不同評估。

說明誰營運服務、如何使用資料，以及如何求助或行使權利。考慮弱勢使用者、無障礙替代途徑，以及錯誤回答或轉交失敗的後果。檢查適用的無障礙與產業要求，不要假設聊天介面已滿足要求。

評估聊天機器人供應商與技術

要求與預定工作流程直接相關的證據。AI 聊天機器人採購指南提供更廣泛的評估背景；隱私評估仍需涵蓋實際資料流。

ISO 27001、SOC 2 與 Cyber Essentials 能證明什麼

ISO/IEC 27001涉及資訊安全管理系統。應檢查證書涵蓋的組織、服務、地點和有效期，不要把標誌理解成涵蓋所有產品。

SOC 2是確信報告，不是認證。Type 2 報告檢查指定期間的運作有效性。應檢查實際報告中的系統、準則、例外及客戶責任。

Cyber Essentials是英國制度，涵蓋對抗常見網路威脅的基本技術控制。這些都不能單獨證明你的用途符合 GDPR。Quickchat AI 法律 FAQ 表示仍在推進 SOC 2，不要把這段文字當成已完成報告。

向候選供應商提出的 15 個問題

1. 提示、回覆、檔案、日誌和備份儲存及處理在哪裡？誰能遠端存取？
2. 擬議 DPA 涵蓋哪些角色和處理活動？
3. 如何隔離不同客戶的資料存取？
4. 哪些連線及儲存紀錄有加密？金鑰如何管理？
5. 各資料類別適用哪些保留和刪除規則？
6. 如何支援及驗證存取、更正、刪除和可攜性申請？
7. 涉及哪些次處理者？如何通知變更？
8. 是否將客戶資料用於訓練、評估或回饋？適用什麼條款？
9. 如何調查事件並通知相關外洩？
10. 哪些現行證書或確信報告涵蓋該服務？
11. 實際提供哪些驗證、角色和身分整合？
12. 有哪些關於提示注入、未授權操作及資料外洩的證據？
13. 哪些隱私與安全選項是預設值、可設定功能或企業安排？
14. 客戶可存取哪些日誌、來源及操作證據？其限制為何？
15. 如何檢查合規證據、匯出資料並驗證服務終止流程？

供應商比較評分表

在分數旁記錄證據和未解問題。未知的合約或營運事實應保留為未知，不要因行銷文字而加分。尚未符合的必要條件，不應被漂亮的總分掩蓋。

下載部署資料流程紀錄表

下載可編輯的資料流程紀錄表。共用的英文套件包含三份空白 CSV、獨立的虛構範例與操作說明。用它記錄擬議部署的元件、資料移動、證據與待解問題。套件並未描述經驗證的 Quickchat AI 架構。

1. 在 components.csv 中列出實際適用的瀏覽器、應用程式、知識儲存庫、模型供應商、連接服務、日誌與備份。分別記錄處理和儲存位置，以及訓練用途、保留規則、刪除範圍與存取責任。未知事實應維持未解狀態。
2. 在 data-flows.csv 中連接元件 ID，並說明每個流程的目的、資料類別與存取條件。記錄類別和文件參照，不要填入私密對話紀錄或認證資訊。
3. 在 evidence-register.csv 中將每項主張連結至註明日期的來源及其適用範圍。區分供應商聲明、契約、設定，以及測試計畫和已觀察測試的紀錄。計畫中的測試仍維持 not_run。為待解問題指定負責人。

將 UTF-8 CSV 匯入不同工作表，並保留原有識別碼。選用的離線檢查器只檢查格式與參照，無法驗證供應商主張或判定法律合規性。請搭配上方問題和評分表使用，並完成實際部署所需的審查。

小型團隊的實務路線圖

將初始流程限制在團隊能營運和驗證的範圍。從公開資訊開始可降低複雜度，但自由文字輸入和技術識別碼仍需評估。

自行託管軟體與 SaaS 的取捨

自行託管可提供對架構和資料處理更直接的控制，但也需要負責營運、修補、監控和保護系統。授權與基礎設施成本各有不同；開放原始碼不保證部署免費，也不會排除外部處理者。

SaaS 可提供代管基礎設施和支援，但客戶仍需確定目的、合法依據、設定與適當條款。比較團隊還需要負責哪些工作，而不只是訂閱價格。任何私有雲或自行託管方案都應視為特定安排來確認，不要假設每個方案都有。

資源有限時可實施的控制

使用持續維護的軟體、安全傳輸、適當驗證和受限存取。不要將憑證放入提示，也不要將不必要紀錄放進 Knowledge Base。設立有負責人的權利申請信箱，以及反映實際系統的保留登錄表。

可使用監管機關範本組織評估，但隱私資訊應依自己的資料流撰寫。一般政策產生器無法確定聊天機器人實際做什麼。除了備份，也測試還原、記錄事件並保留人工處理管道。若必要保障或法律評估尚未完成，應在上線前縮小範圍。

三個假設性實作範例

以下是設計範例，不是客戶案例、實測結果或獲得監管核准的證據。

• 零售銀行資訊助理。 將機器人限制於已批准的公開產品資訊，並把帳號交易導向經驗證的服務。評估處理依據、供應商和紀錄，測試訪客能否誘導揭露帳號資訊。此設計仍需依銀行適用規則審查。
• 大學招生助理。 區分一般招生指引、申請狀態和錄取決定。自訂權利入口可驗證身分，彙集相關紀錄供審查並安全交付。JSON 對適用的可攜性申請可能有用，但產生檔案本身不能證明已完整履行存取權或符合期限。
• 醫療行政助理。 定義允許的預約與資訊任務、減少要求的資料，並提供適當臨床轉介途徑。評估對意外出現健康資訊的遮蔽，同時承認可能漏判。免責聲明或遮蔽層不能證明剩餘逐字稿已匿名，或適合不受限制的訓練。

歐盟 AI 法與 GDPR 並行適用

AI 法於 2024 年 8 月生效，分階段適用，不會取代 GDPR。截至本指南審查日，執委會目前的實施時間表已反映通過的變更，而不只是原始時程。

目前的透明義務與高風險適用日期

第 50 條自 2026 年 8 月 2 日適用。它要求提供者確保直接與 AI 互動的人知道這一點，除非在當時情境中已很明顯。必要資訊必須在首次互動時清楚且易於取得。與生成內容或特定系統有關時，也應檢查第 50 條的其他義務。

已通過的 AI Omnibus 於 2026 年 7 月 27 日生效。相關高風險要求目前自 2027 年 12 月 2 日適用於附件 III 系統，自 2028 年 8 月 2 日適用於附件 I 的產品相關系統。分類取決於預定用途和法定準則；受監管產業的聊天機器人，不會只因產業別而自動成為高風險。

分別評估提供者和部署者責任，包括適用的文件、監督、日誌與符合性義務。修訂後的第 4 條仍要求採取支持員工 AI 素養的措施，但不要求保證每位個人的程度。

另一項 GDPR/ePrivacy Digital Omnibus 程序在 2026 年 11 月 4 日檢查時仍未完成。對這些規則的擬議變更，不應當成現行法律。

ISO/IEC 42001 與 AI 治理

ISO/IEC 42001:2023於 2023 年 12 月發布，規範 AI 管理系統架構。它可協助組織責任、風險評估和持續審查。符合標準或取得認證，不代表聊天機器人自動滿足 GDPR 或所有適用的 AI 法義務。

實作時程與責任矩陣

使用分階段計畫，在公開上線前找出缺少的證據。以下時程是範例，不是法定時間表，也不保證每個專案都能在 90 天內完成。

含審查節點的 90 天計畫

• 第 1-30 天：盤點。 定義任務、資料流、依據、角色和產業要求。篩查是否需要 DPIA、確認決策負責人並收集供應商證據。
• 第 31-60 天：實作。 約定適用的處理條款，設定告知、存取、整合和保留。建立必要的權利及事件流程，隨設計具體化完成評估工作。
• 第 61-90 天：驗證。 測試一般任務、未授權要求、錯誤回答、刪除範圍與復原。訓練團隊、完成必要保障，並在相關處理開始前審查所需 DPIA。有限試行仍需適當保護。

應依準備程度決定上線時機，而不只看日曆。對話式 AI 平台指南提供其他平台評估背景。

含獨立 DPO 建議的 RACI 範例

R 表示負責執行工作，A 表示組織內負最終責任的專案負責人，C 表示徵詢意見，I 表示告知。此營運範例不會把法定責任從控制者或處理者移轉出去。

DPO 應獨立提供建議和監督。DPO 指引將合規與 DPIA 的責任歸於控制者，並提醒避免兼任決定處理目的和方式的衝突角色。並非每個組織都必須指定 DPO。

核准部署之前

一起檢查資料地圖、適用合約、保留規則和營運測試結果。確認誰接收權利申請或事件通報，以及供應商、整合或目的變更時會如何處理。

對 Quickchat AI，應區分已文件化的控制與需要特定協議的要求。帳號或 agent 刪除、隱私免責聲明、依要求提供的清理功能，以及所述儲存地區，都有有限範圍。依賴這些功能前，先確定實際部署的要求已獲解決。

聊天機器人隱私常見問題

以 GPT 為基礎的聊天機器人可以符合 GDPR 嗎？

它可以成為合法部署的一部分，但取決於目的、資料、角色、合約、安全、權利處理與傳輸。模型名稱、不訓練設定或歐盟伺服器本身都不足夠。假名化可以降低風險，但資料仍可能在 GDPR 範圍內。

如何依使用者要求刪除資料？

以合乎比例的方式驗證身分、找出相關紀錄、評估刪除理由與例外、協調處理者並驗證結果。應不無故延遲，通常在一個曆月內處理，任何允許的延期都須及時通知。評估應包括日誌、匯出檔和備份。刪除 Quickchat AI Agent 不等於刪除其對話。

聊天機器人應使用哪種驗證方式？

依任務選擇。公開 FAQ 可能不需要訪客驗證，但帳號資料或交易需要適當驗證和授權途徑。保護管理存取、考慮 MFA，並確認角色限制。SSO 和生物辨識都不是所有流程的通用答案。

GDPR 下可以保留聊天日誌多久？

僅能保留相關目的所能合理支持的時間，並遵守適用法律義務。依資料類別定義期間或準則，並在隱私資訊中說明。範例中的 30 天或 90 天不是 GDPR 預設期限；保留同意證據也需要理由。

自行託管模型仍需要 DPA 嗎？

評估是否有另一實體代表你處理個人資料。自行執行軟體不會自動與發行者形成處理者關係，但主機、支援、分析或其他服務可能會。處理者仍需適用的第 28 條條款，自行託管也不會消除你本身的義務。

聊天機器人可以作出第 22 條下的完全自動化決策嗎？

第 22 條限制的是完全自動化、具有法律或類似重大影響的決策。適用時，應評估可用例外與必要保障，包括需要時具實質意義的人工介入。一般客服回答不會自動受到該限制；重大資格或存取決策則需要更仔細審查。

聊天機器人的隱私告知應包括什麼？

說明控制者及聯絡資訊、目的與依據、相關接收者和傳輸、保留、適用權利與申訴管道。依實際收集方式，納入第 13 或 14 條要求的其他資訊，包括依賴同意時的撤回，以及相關自動化決策資訊。保持易於取得且正確，並將必要的 AI 互動揭露與取得同意分開處理。

如何降低提示注入風險？

將訪客訊息和擷取內容視為不可信任。限制權限、在模型外強制執行授權、驗證操作參數，並測試存取未授權資料或執行無關操作的嘗試。指示、篩選和 RAG 都不保證能防止攻擊。保留調查和人工接手的管道。

聊天小工具需要 Cookie 同意嗎？

依適用的 ePrivacy 實施規則，評估每項儲存或存取操作及其目的。EDPB 指引不只涵蓋 Cookie。對訪客明確要求之服務嚴格必要的操作，可能獲豁免；其他操作可能需要事先同意。Quickchat AI 小工具使用瀏覽器本機儲存維持對話連續性和偏好。不要假設所有小工具儲存都豁免，也不要假設每個小工具都必須在同意選擇前完全封鎖。

歐盟 AI 法會取代聊天機器人的 GDPR 嗎？

不會。GDPR 繼續規範相關個人資料處理，AI 法則依系統、角色和用途增加義務。第 50 條透明義務已自 2026 年 8 月 2 日適用。高風險要求應確認目前修訂後的時程，不要依賴原本的 2025/2026 年預期。

評估 Quickchat AI 平台時，先定義工作流程及其所需資料，再將文件記載的控制與適用條款和自己的要求比較。