什麼是 GDPR？應用程式建構者的白話指南

GDPR（一般資料保護規則）是歐盟主要的資料保護法。它規範組織如何蒐集、使用、儲存與分享個人資料——也就是任何可辨識出在世自然人的資訊——並賦予當事人對自己資料的權利，例如查閱或要求刪除。此規則自 2018 年 5 月 25 日起適用，而且如果企業服務的是歐盟境內的人，即使位於歐盟之外也可能適用。

**非法律意見。**本指南是一份一般性的說明，協助你理解基本概念並提出更好的問題。它不能取代針對你個別情況的專業意見。如需權威的細節，請參閱歐盟執委會的資料保護頁面，以及歐洲資料保護委員會為中小企業撰寫的指南。

用 AI 開發時，為什麼它很重要

AI 建構工具讓蒐集資料變得非常容易。只要一個提示，就能得到註冊表單、聯絡表單、分析工具、檔案上傳，以及列出每位使用者的後台儀表板。它們每一項都會蒐集個人資料，而 GDPR 關心的正是這些資料。

好消息是，GDPR 的大部分要求，也正是良好的產品實務：

• 只蒐集你真正需要的資料。
• 告訴人們你會如何使用這些資料。
• 確保資料安全。
• 不再需要時就刪除。
• 讓人們可以查看、更正或移除自己的資料。

在一開始就把這些設計進去，遠比上線後再補救容易得多。及早向你的 AI 建構工具問對問題，能避免日後痛苦的重建。

日常生活的比喻

把個人資料想成人們寄放在你這裡的東西——像是寄物處，但寄放的是資訊。GDPR 就是這間寄物處的規則：

• 只接受當事人同意寄放的東西，而且要有當事人理解的理由。
• 不要為了其他用途翻找口袋。
• 把房間鎖好。
• 當對方要求，或你不再需要時，把東西歸還或丟棄。
• 如果有東西遺失，要及時通知相關人員。

即使你聘請別人來經營這個房間，寄放物品的安全責任依然在你身上。

核心概念

什麼算是個人資料

歐盟執委會將個人資料定義為與某位已識別或可識別之在世自然人相關的任何資訊。這個範圍很廣，包括姓名、電子郵件地址、住家地址、IP 位址、Cookie ID 與照片。經過「假名化」的資料——例如把姓名換成代碼——如果仍能連回某個人，就仍然是個人資料。

有些類別的資料會受到額外保護，包括健康資料、生物特徵資料、種族或民族出身，以及政治觀點。

適用對象

根據執委會的說明，GDPR 適用於在歐盟設立的組織，也適用於歐盟以外、向歐盟境內的人提供商品或服務（付費或免費）或監控其行為的組織。一家擁有歐洲客戶的美國或阿拉伯聯合大公國新創公司，很可能也在適用範圍內。英國則有自己的版本，即英國 GDPR，它與原版高度相似。

原則

GDPR 建立在一組簡短的原則之上。用白話來說：

合法基礎

你對每一種使用個人資料的方式，都需要一個法律上的理由——即「合法基礎」。GDPR 列出六種：同意、履行契約、法律義務、重大利益、公共任務，以及正當利益。同意只是其中之一。例如，處理訂單以便寄送，通常是基於契約，而不是同意。哪一種基礎適用，是需要對照官方指引來判斷的。

當事人的權利

執委會列出以下個人權利：

• 獲知其資料如何被使用
• 查閱其資料
• 更正其資料
• 要求刪除其資料
• 限制處理
• 資料可攜性（以可用的格式取得資料）
• 拒絕處理
• 與自動化決策及剖析相關的權利

資料外洩

如果個人資料外洩，而且此事件可能對人們的權利與自由造成風險，組織通常必須在不當延誤的情況下通知其資料保護主管機關，並在可行的情況下，於知悉後 72 小時內完成通知。在某些情況下，受影響的人也必須被告知。

實例：瑜伽工作室預約應用程式

假設你要為一間在德國有客戶的瑜伽工作室建立預約應用程式。以下是 GDPR 如何影響它的設計。

**少收集。**註冊表單要求姓名、電子郵件與選填的電話號碼。初版草稿還要求出生日期與住家地址——但應用程式中沒有任何地方會用到它們，所以把它們移除了。

**健康資料需要謹慎處理。**工作室想詢問學員的傷病狀況。這屬於健康資料，是一種有更嚴格規定的特殊類別。工作室決定改為親自面談處理，因此應用程式不蒐集這類資料。

**保持透明。**隱私權政策說明蒐集了什麼、為什麼蒐集、保存多久、還有哪些其他單位會處理這些資料（主機服務商、電子郵件服務、付款服務），以及如何聯絡工作室。

**行銷要分開。**預約課程並不會讓任何人自動訂閱電子報。電子報另有一個獨立、未預先勾選的核取方塊。

**產品內的權利。**學員可以查看並編輯個人資料、下載預約紀錄，並可在帳號頁面要求刪除。

**保存期限。**長期未使用的帳號會在設定的期間後被標記，若學員沒有回應就會被移除。保存期限由工作室決定。

**Cookie。**登入用的 Cookie 是必要的。分析工具只有在訪客同意後才會載入。請參閱什麼是 Cookie。

**安全性。**密碼經過雜湊處理，管理區需要雙重驗證，而且只有擁有者可以匯出客戶名單。

常見名詞解釋

常見錯誤與誤解

• 「我們不在歐盟，所以不適用。」 適用與否可能取決於你的使用者在哪裡。
• 「GDPR 代表所有事情都要同意。」 同意只是六種合法基礎之一，而且通常不是最適合的那一種。
• 「放了 Cookie 同意橫幅，就算合規了。」 Cookie 只是其中很小的一部分。資料蒐集、安全性、權利與保存期限更加重要。
• 「我們的主機符合 GDPR，所以我們也符合。」 服務商能提供協助，但你要決定應用程式蒐集什麼、做什麼。
• 「以防萬一」而多蒐集資料。 每多一個欄位，就多一項需要保護、說明與刪除的東西。
• 照抄其他網站的隱私權政策。 政策必須描述你的應用程式實際做什麼。
• 讓刪除變得不可能。 如果沒有開發者介入，就無法刪除使用者，那麼每一次權利請求都會變成緊急事件。

該向你的 AI 建構工具要求什麼

• 「列出這個應用程式蒐集的每一項個人資料、儲存位置，以及為何需要它。」
• 「移除我們沒有使用的表單欄位。」
• 「新增一個帳號頁面，讓使用者可以查看、編輯與下載自己的資料，並要求刪除。」
• 「建立一個管理動作，可以完整刪除使用者及其相關紀錄，或對我們必須保留的紀錄進行匿名化。」
• 「把電子報訂閱保留為獨立、未預先勾選的核取方塊。」
• 「在取得同意之前，不要載入分析或行銷腳本。」
• 「列出所有接收使用者資料的第三方服務，讓我可以加入隱私權政策中。」
• 「把管理匯出功能限制在擁有者角色，並記錄是誰匯出了什麼。」

接著請閱讀如何撰寫服務條款與隱私權政策，以及如何加入 Cookie 同意。

GDPR 與 Mythex

Mythex 提供的是建構的基礎模組，而不是合規證書。當你啟用時，你的應用程式資料會存放在它自己的專案資料庫與檔案儲存空間中；你擁有程式碼；在 Pro 方案中，如果你需要搬移專案，也可以匯出。你的應用程式蒐集什麼、保存多久，以及人們如何行使權利，都是由你決定、並請代理程式建構的事項。資料擁有權文件頁面說明了 Mythex 代管的內容，而你所建構應用程式的安全性則提醒不要宣稱你並不具備的合規性。如果你需要具體資訊，例如資料存放的地點或資料處理協議，請在上線前先聯絡 Mythex 支援。

常見問題