什麼是 GDPR？為應用程式開發者而設的淺白指南

GDPR（《通用資料保護規例》，General Data Protection Regulation）是歐盟主要的資料保護法例。它為機構收集、使用、儲存及分享個人資料——即任何與某位在世可識別人士有關的資訊——的方式訂下規則，並賦予人們對自己資料的權利，例如查閱或要求刪除。該規例自 2018 年 5 月 25 日起適用，如果企業向歐盟境內人士提供服務，即使身處歐盟以外，也可能受其約束。

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

用 AI 做 App 時，為何重要

AI 生成工具令收集資料變得很容易。一個提示就能為你生成註冊表格、聯絡表格、分析工具、檔案上載，以及一個列出所有用戶的管理面板。每一項都會收集個人資料，而 GDPR 關注的正是所有這些資料。

好消息是，GDPR 的大部分要求，同時也是良好的產品做法：

• 只收集你真正需要的資料。
• 告知人們你會如何使用這些資料。
• 妥善保障資料安全。
• 不再需要時將其刪除。
• 讓人們可以查閱、更正或移除他們的資料。

這些在一開始就納入設計，遠比在推出後再補上容易。儘早向你的 AI 生成工具提出正確的問題，可以省卻日後的痛苦重建。

日常比喻

把個人資料想像成人們留在你這裡的物件，就像一個寄存衣物的地方，只是寄存的是資訊。GDPR 就是這個寄物處的守則：

• 只收下當事人同意寄存、並且他們明白用途的東西。
• 不要為其他用途翻查他們的口袋。
• 保持房間上鎖。
• 應要求或在不再需要時，歸還或丟棄物件。
• 如果有東西遺失，應及時通知相關人士。

即使你聘請了他人打理這個房間，只要物件仍在你的照管之下，你就要為它們負責。

核心概念

什麼算是個人資料

歐盟委員會把個人資料定義為與某位可識別或可辨識的在世人士有關的任何資訊。這個定義相當廣泛，包括姓名、電郵地址、住址、IP 位址、Cookie ID 及相片。經過「假名化」處理的資料——例如把姓名替換成代號——如果仍能追溯回某人，同樣屬於個人資料。

某些類別會受到額外保護，包括健康資料、生物辨識資料、種族或民族出身，以及政治意見。

適用對象

根據歐盟委員會的說法，GDPR 適用於在歐盟設立的機構，以及歐盟以外、向歐盟境內人士提供商品或服務（付費或免費），或監察其行為的機構。一間在美國或阿聯酋成立、擁有歐洲客戶的初創公司，很可能屬於適用範圍。英國有其本身的版本，即英國 GDPR，它大致以歐盟版本為基礎。

原則

GDPR 建基於一組簡短的原則。以淺白的說法：

合法基礎

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

人們的權利

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

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

資料外洩

如果個人資料外洩，而該外洩可能會危害人們的權利及自由，機構一般必須在不無故拖延的情況下通知其資料保護機關；在可行的情況下，並應在知悉外洩後 72 小時內通知。在某些情況下，受影響的人士也必須獲得通知。

實例：瑜伽室預約 App

假設你要為一間在德國有客戶的瑜伽室建立預約 App。以下是 GDPR 如何影響設計。

收集得少。 註冊表格要求姓名、電郵及可選填的電話號碼。初稿還要求出生日期及住址——但 App 中沒有任何地方使用它們，所以已把它們移除。

健康資料需要小心處理。 瑜伽室想詢問學員有否受傷。這屬於健康資料，是受較嚴格規定所限的特殊類別。瑜伽室決定改為親自處理，因此 App 不會收集這類資料。

保持透明。 私隱政策說明收集什麼、為何收集、保存多久、還有誰會處理這些資料（主機供應商、電郵服務、付款供應商），以及如何聯絡瑜伽室。

推廣資訊另外處理。 預約課堂並不會令任何人自動訂閱電子報。電子報另有一個獨立的、未預先勾選的選擇方格。

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

保存期限。 不活躍的帳戶會在設定的期限後被標記，如果客戶不回應，便會被移除。保存期限由瑜伽室決定。

Cookie。 登入 Cookie 是必需的。分析工具只在訪客接受後才會載入。參閱什麼是 Cookie。

安全。 密碼經過雜湊處理，管理區域須使用雙重驗證，而只有擁有人可以匯出客戶名單。

常見術語解釋

常見錯誤與誤解

• 「我們不在歐盟，所以不適用。」 它可以因你的用戶身處何地而適用。
• 「GDPR 就是任何情況都要取得同意。」 同意只是六項合法基礎之一，而且往往不是合適的基礎。
• 「放置 Cookie 橫額，我們就符合規定了。」 Cookie 只是一小部分。資料收集、安全、權利及保存期限更加重要。
• 「我們的主機符合 GDPR，所以我們也符合。」 供應商能提供協助，但你要決定自己的 App 收集什麼資料，以及如何處理。
• 「以防萬一」而收集資料。 每多一個欄位，就多一項需要保障、解釋及刪除的東西。
• 複製其他網站的私隱政策。 私隱政策必須描述你的 App 實際上做什麼。
• 令刪除變得不可能。 如果除了開發者之外沒有人能刪除用戶，那麼每一宗權利要求都會變成緊急事件。

可以要求你的 AI 生成工具做的事

• 「列出這個 App 收集的每一項個人資料、儲存位置，以及為何需要它。」
• 「移除我們不使用的任何表格欄位。」
• 「加入一個帳戶頁面，讓用戶可以查看、編輯及下載其資料，並可要求刪除。」
• 「建立一個管理員操作，可以徹底刪除用戶及其相關紀錄，或將我們必須保留的紀錄匿名化。」
• 「把推廣訊息的訂閱保留為獨立、未預先勾選的方格。」
• 「在取得同意之前，不要載入分析或推廣腳本。」
• 「列出所有接收用戶資料的第三方服務，以便我把它們加入私隱政策。」
• 「把管理員匯出功能限制為擁有人角色，並記錄誰匯出了什麼。」

然後閱讀如何撰寫服務條款及私隱政策，以及如何加入 Cookie 同意。

GDPR 與 Mythex

Mythex 為你提供的是建構資料的基礎，而不是合規證書。當你啟用時，App 的資料會存放在其專屬的專案資料庫及檔案儲存中；你擁有程式碼，如需搬遷，在 Pro 方案下可以匯出專案。你的 App 收集什麼、保存多久，以及人們如何行使權利，都是由你決定，並要求代理程式建構的功能。說明文件中的資料擁有權頁面解釋了 Mythex 代管的內容，而你所建構 App 的安全則提醒不要聲稱自己並未具備的合規性。如果你需要具體資料，例如資料存放位置或資料處理協議，請在正式推出前向 Mythex 支援查詢。

常見問題