想象你开了一家生意红火的餐厅。每天,顾客的预约电话、会员卡信息、点单记录、过敏原说明,像食材一样涌进后厨——这些就是你的“个人数据库存”。突然有一天,城市颁布了一部严格的《餐饮卫生安全法》:每家餐厅必须说清后厨囤了什么食材、凭什么进货、保质期多久;顾客有权随时查看自己那份餐用了什么原料、要求撤单;想把食材运往海外分店,必须先办出口报关。违规者面临最高“全年营业额 4%”的巨额罚单。 这部《餐饮卫生安全法》,就是欧洲的《通用数据保护条例》(GDPR)。它管的不只是欧洲本地餐厅——任何向欧盟居民提供服务、或监控其行为的海外企业,都在管辖范围内。对正在规划 AI 产品出海或对接欧洲用户的产品团队来说,GDPR 合规不是“法务的事”,而是产品功能、技术架构、运营流程里必须内建的一环。这篇文章会用“餐厅后厨”的比喻,带你把 GDPR 落地的六大关键动作走一遍:数据映射盘点、合法基准确认、DPO 任命、数据主体权利响应、跨境传输机制、审计与问责。读完之后,你将拥有一张可以直接对照检查的合规地图。

岗位关联

学完本课,你将能快速读懂 GDPR 的落地框架,为 AI 产品对接欧盟用户时提供一份可执行的合规检查清单,规避最高达全球营收 4% 的罚款与数据伦理事故。

目录
  1. 可视化演示
  2. 数据映射盘点:先给后厨建一本台账
  3. 合法基准确认:办齐六种进货凭证
  4. DPO任命:请一位专职食品安全官
  5. 主体权利响应:顾客的退菜与知情权
  6. 跨境传输机制:食材出口需要“通关文牒”
  7. 审计与问责:卫生局的突击检查
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示GDPR合规落地的完整流程(数据映射→合法基准→DPO→权利响应→DPIA→跨境传输)、数据主体五项权利、以及违规罚款与合规成本的量化对比。

本节配有交互动效(进入视口后自动加载,约 3KB)。

'+captions.flow+'

数据映射盘点:先给后厨建一本台账

开餐厅最怕的事,是厨师长说不清后厨到底存了哪些食材。冰箱第三格的冻肉是什么时候进的?地下室那箱香料过期了吗?没有台账的餐厅,卫生局一来检查就露馅。GDPR 合规的第一步也同样朴素:你得先回答“我们到底在处理哪些个人数据”。

这个动作在合规领域叫数据映射(Data Mapping)。GDPR 第 30 条要求企业维护一份“处理活动记录”(RoPA),把每一类个人数据的处理目的、数据类别、接收方、保留期限都登记在册。它是一切合规工作的地基——没有这张地图,后面的合法依据、权利响应、跨境传输全都无从谈起。

用集合语言看,这本台账就是一个“四元组”的集合,每条记录回答四个问题:数据类别说明“是哪类食材”(身份信息、健康数据、位置数据),处理目的说明“要做什么菜”,接收方说明“谁尝过”(云服务商、物流商),保留期限说明“保质期到什么时候”。

台账建好,后厨终于“看得见”了。但卫生局马上会问第二个问题:这些食材,你凭什么拿到的?——这就引出合法依据。

Record={(Data Category, Purpose, Recipients, Retention)∣∀ Processing Activity}\displaystyle \text{Record} = \{ ( \text{Data Category},\ \text{Purpose},\ \text{Recipients},\ \text{Retention} ) \mid \forall \text{ Processing Activity} \}
花括号里每个元素是一条处理活动记录;竖线后的 ∀ 读作“任意”,要求覆盖企业全部处理活动,不允许存在账外数据。
  1. 集合与元组花括号定义了一个台账集合,圆括号内四条信息合在一起才构成一条完整记录,缺一条都不算数。
    (Data Category, Purpose, Recipients, Retention)\displaystyle ( \text{Data Category},\ \text{Purpose},\ \text{Recipients},\ \text{Retention} )
  2. 数据类别Data Category 说明食材品类,如姓名邮箱、健康数据、定位轨迹,类别决定后续安全等级与合规力度。
    Data Category\displaystyle \text{Data Category}
  3. 目的与接收方Purpose 是处理理由,Recipients 是数据流向的第三方,二者共同回答“为什么拿、给了谁”。
    Purpose, Recipients\displaystyle \text{Purpose},\ \text{Recipients}
  4. 保留期限Retention 是保质期标签,到期必须删除,避免“僵尸数据”长期占用后厨。
    Retention\displaystyle \text{Retention}
  5. 全程量化竖线后的 ∀ 是“任意/所有”,要求遍历全部处理活动;漏掉任何一条,就像冷藏室藏了一袋过期肉,风险不因你不知情而消失。
    ∀ Processing Activity\displaystyle \forall \text{ Processing Activity}

合法基准确认:办齐六种进货凭证

台账清晰之后,卫生局的第二句话是:这些食材有进货凭证吗?顾客的隐私数据不是凭空“捡来”就能用的,GDPR 第 6 条规定了六种“合法依据”,你可以把它们理解成六种不同的进货渠道。

最常见的是同意(Consent):顾客主动把联系方式交给你,像顾客在菜单上勾选“我同意接收短信”。但同意必须自由、具体、知情,且能被随时撤回——不是一锤子买卖。除同意外,还有合同履行(下单后必须用地址发货)、法定义务(税务要求保留账目)、合法利益(在必要性前提下做平衡测试)等。

选择合法依据不是抽盲盒,而是一个有优先级的判断树。用分段函数表达就是:

进货凭证办齐后,后厨还需要一位关键人物——专门盯着食品安全不放的人。这就是第三节的主角:数据保护官 DPO。

Legal Basis={Consentfreely given, specific, informedContractnecessary for performanceLegal Obligationrequired by lawLegitimate Interestnecessity∧balancing test\displaystyle \text{Legal Basis} = \begin{cases} \text{Consent} & \text{freely given, specific, informed} \\ \text{Contract} & \text{necessary for performance} \\ \text{Legal Obligation} & \text{required by law} \\ \text{Legitimate Interest} & \text{necessity} \land \text{balancing test} \end{cases}
四个分支分别对应四种主要进货凭证;选错依据,等同用假发票进货,一旦被查就是双倍处罚。
  1. 同意(Consent)三个条件缺一不可——自由给出、目的具体、内容知情;默认勾选与捆绑同意都不合格。
    Consent:freely given∧specific∧informed\displaystyle \text{Consent}: \text{freely given} \land \text{specific} \land \text{informed}
  2. 合同履行(Contract)只为履行与数据主体签订的合同所必需,不能借合同之名行营销之实。
    Contract:necessary for performance\displaystyle \text{Contract}: \text{necessary for performance}
  3. 法定义务(Legal Obligation)处理行为是欧盟或成员国法律强制要求,企业没有“选择空间”,就像餐厅必须保留食品安全检查记录。
    Legal Obligation:required by law\displaystyle \text{Legal Obligation}: \text{required by law}
  4. 合法利益(Legitimate Interest)控制者利益与个人权利之间做天平式权衡,必须能证明“必要性 + 影响最小 + 预期合理”。
    Legitimate Interest:necessity∧balancing test\displaystyle \text{Legitimate Interest}: \text{necessity} \land \text{balancing test}

DPO任命:请一位专职食品安全官

大餐厅后厨不能指望每个厨师“顺手”管安全,得有一位专职食品安全官:懂食材、能进所有房间、有直接向老板汇报的通道,还不能因为严格把关而被开除。GDPR 对应的角色叫数据保护官(DPO)。

并不是每家公司都必须设 DPO,但有三种情形跑不掉:核心业务需要大规模处理个人数据(如数据密集型 SaaS);大规模处理特殊类别数据(健康、种族、生物识别等);系统性、大规模监控(如行为画像)。满足条件的组织不任命 DPO,本身就是一项违规。

DPO 的任命条件可以浓缩成一个逻辑表达式:

食品安全官就位后,顾客开始提要求了:“我点的菜里到底放了什么?我要退菜!”——这便是数据主体权利。

DPO Required⇔Core Activities∧(Large Scale∨Systematic Monitoring)\displaystyle \text{DPO Required} \Leftrightarrow \text{Core Activities} \land ( \text{Large Scale} \lor \text{Systematic Monitoring} )
这是一道“当且仅当”的闸门:核心业务是前提,再满足“大规模处理”或“系统性监控”二者之一,就触发任命义务。
  1. 核心业务(Core Activities)处理数据不是顺带行为,而是业务存在的基础,如同餐厅的主营菜品,而非赠品小菜。
    Core Activities\displaystyle \text{Core Activities}
  2. 且(∧)逻辑“与”,前置条件与后置条件必须同时成立,缺一不可。
    ∧\displaystyle \land
  3. 大规模(Large Scale)判定需结合数据主体数量、数据量、持续时间等综合评估,没有一刀切的数字门槛。
    Large Scale\displaystyle \text{Large Scale}
  4. 系统性监控(Systematic Monitoring)对用户进行持续追踪与画像,如广告网络的跨站跟踪,用 ∨(或)连接,满足其一即成立。
    Large Scale∨Systematic Monitoring\displaystyle \text{Large Scale} \lor \text{Systematic Monitoring}

主体权利响应:顾客的退菜与知情权

一家尊重顾客的餐厅,应该允许顾客查看自己那道菜用了哪些原料,要求撤掉过敏原,甚至把会员卡余额带走。GDPR 把这类诉求统称为数据主体权利:访问权、更正权、删除权(被遗忘权)、限制处理权、可携带权、反对权等。

对产品团队来说,这意味着每个功能都要能回答“用户怎么行使这些权利”。用户提交“删除我的数据”请求后,你的系统必须在 30 天内完成,并且第一步是先确认请求人的身份——就像餐厅要先核对取餐号,不能把菜给错人。

响应时限是一条硬性指标:

顾客的权益有了着落,后厨还有最后一道关要过:这份菜谱要传给海外分店。出国,就得报关。

Tresponse={1 monthordinary request+2 monthscomplex request, inform within 1 month\displaystyle T_{\text{response}} = \begin{cases} 1\ \text{month} & \text{ordinary request} \\ +2\ \text{months} & \text{complex request, inform within 1 month} \end{cases}
默认 1 个月响应;复杂请求可最多延长两个月(合计三个月),但必须在一个月内告知用户延期原因与预计完成时间。
  1. 一个月基础时限收到请求后的第一个月是默认响应窗口,简单请求不得拖延,系统要能自动记录“收件日期”。
    Tresponse=1 month\displaystyle T_{\text{response}} = 1\ \text{month}
  2. 复杂请求延期请求特别复杂或数量过多时,可额外延长两个月,总时限不超过三个月。
    Tresponse=1 month+2 months\displaystyle T_{\text{response}} = 1\ \text{month} + 2\ \text{months}
  3. 告知义务延期不是默认生效,必须在一个月内告知用户“为什么延期、预计何时完成”,否则同样构成违规。
    inform data subject within 1 month\displaystyle \text{inform data subject within } 1\ \text{month}

跨境传输机制:食材出口需要“通关文牒”

想把招牌菜原材料运往海外分店,光有本地进货凭证还不够,海关还要看“通关文牒”。个人数据一旦离开欧盟/欧洲经济区(EEA),GDPR 同样设置层层关卡,防止数据流向保护水平不足的国家后“失控”。

通关文牒有三种主流形态:充分性认定(Adequacy Decision)相当于“白名单护照”——欧盟委员会认定某国保护水平达标,如日本、英国;标准合同条款(SCC)是欧盟官方发布的合同模板,接收方签字承诺按欧盟标准保护数据,是实践中最常用的工具;约束性公司规则(BCR)适合跨国公司内部流转,需监管机构批准。

传输机制的选择有严格优先级:

前厅后厨、本地海关都已就绪,千万别以为可以松口气——卫生局随时可能突击检查。这就是最后的审计与问责。

Transfer Mechanism={Adequacy Decisionfirst choiceSCC∨BCRsecond choiceDerogationslast resort\displaystyle \text{Transfer Mechanism} = \begin{cases} \text{Adequacy Decision} & \text{first choice} \\ \text{SCC} \lor \text{BCR} & \text{second choice} \\ \text{Derogations} & \text{last resort} \end{cases}
优先级从白名单到合同工具再到例外条款;能用前者就不用后者,例外情形需逐案论证,不能作为常规通道。
  1. 充分性认定欧盟委员会对目的地国家的整体评估,一劳永逸的“白名单护照”,当前覆盖约十余个国家和地区。
    Adequacy Decision\displaystyle \text{Adequacy Decision}
  2. 标准合同条款(SCC)欧盟官方模板合同,双方签署后即产生法律约束力,无需逐案审批,出海企业最常用。
    SCC\displaystyle \text{SCC}
  3. 约束性公司规则(BCR)跨国集团内部的行为准则,经监管机构批准后适用于集团内所有实体之间传输。
    BCR\displaystyle \text{BCR}
  4. 例外情形(Derogations)如数据主体明确同意、履行合同所必需等,属兜底条款,必须逐案证明必要性。
    Derogations\displaystyle \text{Derogations}

审计与问责:卫生局的突击检查

卫生局的检查通常看三样东西:上这道新菜前,有没有做过食品安全风险评估?每一批食材的进出记录是否完整可查?发生集体食物中毒后,是否在 72 小时内上报?对应到 GDPR,就是隐私影响评估(DPIA)、处理活动记录与 72 小时泄露通知。

DPIA 要在高风险处理上线前完成,如新技术大规模处理敏感数据;处理活动记录要随时能拿出来给监管看;一旦发生泄露,除非不太可能对个人造成风险,否则必须在 72 小时内通知监管机构,并在必要时告知数据主体。

违规的罚单按“全球年营业额 4% 与 2000 万欧元取较高者”计算:

到这里,这家“餐厅”才算真正把 GDPR 落到了地上:台账看得见、凭证办得齐、安全官守得住、顾客权利有回应、出口文牒备得全、审计习惯成自然。合规从来不是一次性装修,而是每天后厨开火前的例行检查——它终将成为产品团队的肌肉记忆。

Finemax⁡=max⁡(20,000,000 EUR, 4%×Global Annual Turnover)\displaystyle \text{Fine}_{\max} = \max \left( 20{,}000{,}000\,\text{EUR},\ 4\% \times \text{Global Annual Turnover} \right)
罚款不是固定值,而是“2000 万欧元”与“全球年营业额 4%”两个基准中取较高者;对巨头企业,上限可达数十亿欧元。
  1. 取较大者(max)GDPR 用的是“较高者”而非“叠加”,企业规模越大,越依营收比例计算罚单。
    max⁡(⋅, ⋅)\displaystyle \max(\cdot,\ \cdot)
  2. 2000 万欧元绝对金额基准,适用于营收较小的企业,保证罚单下限的威慑力。
    20,000,000 EUR\displaystyle 20{,}000{,}000\,\text{EUR}
  3. 4% 全球营收全球年度营业额的比例基准,让巨头也无法把罚款当“零花钱”。
    4%×Global Annual Turnover\displaystyle 4\% \times \text{Global Annual Turnover}
  4. 配套的泄露时限除罚款外,泄露通知的 72 小时同样是硬性义务,超时未报单独构成违规。
    Tbreach notification≤72 hours\displaystyle T_{\text{breach notification}} \leq 72\ \text{hours}

AI 应用场景

隐私影响评估(DPIA)自动生成

阶段:产品风险评估与治理

解决的问题:传统 DPIA 靠法务手工填写几十页问卷,一个新功能评估要 2-3 周,还常遗漏数据流转环节。AI 能自动扫描产品需求文档与数据流图,生成 DPIA 草稿并标出高风险点。

具体案例:某欧盟金融科技公司在“智能风控”功能上线前,用大语言模型解析 PRD 与系统架构图,自动识别出“读取征信数据”与“跨境存储”两个高风险项,法务只需复核修改,评估周期从 3 周压缩到 2 天。

数据主体权利请求(DSAR)自动化

阶段:数据治理与运营

解决的问题:用户提交“删除我的数据”后,传统流程需人工在十几个系统里逐个查找,常超出 30 天时限。AI 客服可识别请求类型、自动检索数据资产目录、生成清理工单并跟踪时效。

具体案例:一家跨境电商用对话机器人处理“访问/删除/更正”请求,自动定位用户 ID 关联的 47 个数据表,删改完成后回执用户,超时自动升级给 DPO,按时响应率从 60% 提升到 98%。

自动化数据映射(RoPA 持续更新)

阶段:数据发现与资产盘点

解决的问题:人工访谈部门填清单,半年就过期;AI 扫描数据库、API 日志与代码仓库,自动识别个人数据字段并归类,持续更新处理活动记录。

具体案例:某 SaaS 公司用机器学习对 200 个数据库表打标(姓名/邮箱/位置/健康),自动绘制数据流向图,RoPA 从一年一更变为实时更新,监管检查时能当场出示完整台账。

Python 演示

python63 行
# -*- coding: utf-8 -*-"""GDPR 合规成熟度快速评估工具:输入六项合规建设完成情况,输出总分与罚款风险等级"""  class GDPRComplianceChecker:    """基于 GDPR 六大落地动作的问卷式评估器"""     def __init__(self):        self.score = 0        self.weights = {            "data_mapping": 20,            "legal_basis": 20,            "dpo": 10,            "dsr_workflow": 20,            "transfer_scc": 20,            "audit_log": 10,        }        self.checklist = {            "data_mapping": "已完成数据映射盘点并维护处理活动记录 ? (y/n): ",            "legal_basis": "每类数据均已确认合法依据并有书面记录 ? (y/n): ",            "dpo": "已按条件评估并任命数据保护官 DPO ? (y/n): ",            "dsr_workflow": "已建立 30 天内响应数据主体权利的流程 ? (y/n): ",            "transfer_scc": "跨境传输已签署 SCC 或通过充分性认定 ? (y/n): ",            "audit_log": "已完成 DPIA 并留存处理活动日志 ? (y/n): ",        }     def run_survey(self, answers=None):        """answers 缺省时进入交互问卷模式;也可直接传入 y/n 字符串列表"""        if answers is None:            answers = []            for key in self.checklist:                answer = input("[" + key + "] " + self.checklist[key])                answers.append((key, answer.strip().lower() == "y"))        self._calc(answers)        self._report()     def _calc(self, answers):        self.score = 0        for key, ok in answers:            if ok:                self.score += self.weights[key]     def _fine_rate(self):        return round(4.0 - self.score / 100.0 * 3.6, 2)     def risk_level(self):        if self.score >= 80:            return "低风险"        if self.score >= 50:            return "中风险"        return "高风险"     def _report(self):        print("=" * 44)        print("合规总分: %d/100" % self.score)        print("最高罚款风险: %.2f%% 全球年营收" % self._fine_rate())        print("风险等级: %s" % self.risk_level())        if self.score < 80:            print("建议优先补齐未完成的合规项,再评估是否出海")  if __name__ == "__main__":    GDPRComplianceChecker().run_survey()
目的:用交互式问卷快速评估企业 GDPR 合规成熟度,输出合规总分、罚款风险百分比与风险等级,帮助产品团队在出海前完成自检。
  1. "data_mapping": 20数据映射权重最高,没有台账其余合规动作都无从谈起
  2. self.checklist = {...}六道核心问卷,对应文章中的六大合规落地动作
  3. answers.append((key, answer.strip().lower() == "y"))把用户回答存成“领域 + 是否完成”的键值对,便于逐项计分
  4. self._calc(answers)遍历所有答案,把已完成的领域权重累加为总分
  5. self._fine_rate()把 0~100 分线性映射到 0.4%~4.0% 的罚款风险区间,呼应“4% 上限”
  6. self.risk_level()按 80/50 分两档阈值输出低/中/高风险,给出直观结论
  7. if __name__ == "__main__"保证脚本可直接在命令行运行,无需额外入口

常见误区

误区“我在国内公司,服务器也在国内,处理的全是中国用户,GDPR 跟我没关系。”

正解GDPR 有明确的域外效力(第 3 条):只要向欧盟境内的人提供商品或服务(哪怕免费),或监控他们在欧盟境内的行为(如 Cookie 追踪、行为画像),就受管辖。公司注册地、服务器位置都不是“免死金牌”;就像一家海外餐厅把外卖送到本地顾客手里,照样要遵守本地卫生法。

为何常见:人们习惯用“注册地归属”判断法律适用,但 GDPR 采用“效果原则”——看的是数据处理行为是否触及欧盟个人,而不是公司户口本在哪儿。

误区“网上那些 App 都弹窗要同意,我也做了,用户点了'我同意',合规就完成了。”

正解同意只是六种合法依据之一,且要求自由给出、具体、知情、明确、可撤回。默认勾选、捆绑强迫、一揽子授权都不合格;用户撤回同意后必须立即停止处理。更关键的是,很多场景下“同意”并非最合适的依据——例如雇佣关系中处理员工数据,监管会质疑其“自由性”。

为何常见:把“同意弹窗”误当成合规的全部,是因为它最显眼、最容易照抄;而合同履行、合法利益等依据需要更深入的业务判断,容易被偷懒跳过。

误区“我们做了脱敏处理,把姓名替换成 ID,GDPR 就不管了。”

正解把姓名替换成 ID 通常叫“假名化(Pseudonymisation)”,不是“匿名化(Anonymisation)”。只要还能结合其他信息重新识别到个人,数据就仍属于个人数据,GDPR 依然适用。真正的匿名化要求“不可逆且无法结合任何信息识别个人”,标准极高,尤其在大数据交叉分析时代几乎很难达到。

为何常见:混淆了“脱敏了”与“匿名了”两个层级,忽略了重新识别的可能性——这正是 AI 时代数据合规最危险的盲区。

误区“我按要求指定了数据保护官,公司合规就算是做完了。”

正解DPO 只是问责机制的一环,而非合规的终点。DPO 需要独立履职、直接向最高管理层汇报、不被解雇报复,但其职责是“监督与咨询”,而不是替公司“变合规”。数据映射、合法依据、权利响应、跨境传输等一整套动作,必须由业务与技术团队真正落地。

为何常见:把“设置负责人”等同于“完成工作”,是组织合规里最常见的应付心态——就像餐厅挂了个“食品安全官”牌子,后厨却照样乱堆食材。

误区“4% 听着吓人,但我这是小生意,监管也不会真罚。”

正解4% 与 2000 万欧元是“取较高者”且是上限,实际罚款按情节分两档(1000 万/2% 与 2000 万/4%),还叠加纠正措施、业务禁令、声誉损失等隐性成本。对营收小的公司,2000 万欧元的绝对罚金同样是天文数字,足以让一家初创公司直接倒闭。

为何常见:只盯着广告效应最强的"4%"数字,忽略了罚款之外还有禁令、整改与集团层面的连带问责,低估了违规的总体代价。

面试题

Q1. 一家总部在上海的 SaaS 公司向欧盟境内用户提供软件服务并开展行为画像,GDPR 是否适用?

单选题 · easy

  • A.不适用,公司注册地不在欧盟
  • B.适用,因向欧盟用户提供服务并监控行为← 正确答案
  • C.不适用,只要数据存储在本地即可
  • D.适用,但仅限用于营销的数据

答案:B。GDPR 第 3 条采用“效果原则”:向欧盟境内的数据主体提供服务,或监控其在欧盟境内的行为,就触发管辖,与公司注册地、服务器位置无关。A、C 是常见的“属地思维”误区,D 则错误地缩小了管辖范围。

Q2. 以下哪项不属于 GDPR 规定的合法处理依据?

单选题 · easy

  • A.数据主体的明确同意
  • B.履行与数据主体所签合同之必需
  • C.保护数据主体切身重大利益之必需
  • D.数据处理者出于自身管理便利← 正确答案

答案:D。GDPR 第 6 条规定的六种合法依据包括同意、合同履行、法定义务、保护切身重大利益、公共利益以及合法利益。D 项“自身管理便利”没有对应的法定依据,正确的合法利益需要必要性加平衡测试,而非单纯便利。

Q3. 某企业年度全球营收 100 亿欧元,发生严重违规时,最高罚款是多少?

单选题 · mid

  • A.固定罚款 2000 万欧元
  • B.固定罚款 4 亿欧元
  • C.取 2000 万与营收 4% 中较高者← 正确答案
  • D.取 2000 万与营收 4% 中较低者

答案:C。GDPR 第 83 条规定罚款上限为“2000 万欧元”与“全球年营业额 4%”取较高者,而非叠加或取较低者。营收 100 亿欧元时,4% 为 4 亿欧元,高于 2000 万,故上限为 4 亿欧元。

Q4. 需要强制任命数据保护官(DPO)的典型情形是?

单选题 · mid

  • A.员工总数超过二百五十人的企业
  • B.核心业务大规模处理特殊类别数据← 正确答案
  • C.所有处理任何个人数据的企业
  • D.所有在欧盟设立分支机构的企业

答案:B。GDPR 第 37 条规定三类强制任命情形:公共机构、核心业务需大规模处理特殊类别数据、系统性大规模监控。员工人数不是判断标准,A 混淆了 RoPA 记录的简化条件;C、D 扩大了适用范围。

Q5. 以下哪项不是数据主体享有的权利?

单选题 · easy

  • A.访问相关个人数据
  • B.更正不准确的个人数据
  • C.要求删除个人数据
  • D.要求公开推荐算法代码← 正确答案

答案:D。GDPR 赋予数据主体访问权、更正权、删除权(被遗忘权)、限制处理权、可携带权、反对权等。公开推荐算法代码不在其列;算法透明度属于其他监管框架(如《人工智能法案》)的议题,不能混淆。

Q6. 向欧盟以外的“白名单国家”传输个人数据,最稳妥的依据是?

单选题 · mid

  • A.数据主体此前自行公开的资料
  • B.欧盟委员会的充分性认定结论← 正确答案
  • C.接收方单方面作出的合规承诺
  • D.双方签订的一般商务合同

答案:B。充分性认定是欧盟委员会对目的地国家保护水平的官方认可,属于“一劳永逸”的白名单通道,最稳妥。A 属于例外情形但只针对特定数据;C 的单方承诺没有法律强制力;D 的一般商务合同未包含数据保护条款,不构成合规传输工具。

Q7. 发生个人数据泄露后,控制者应在多长时间内通知监管机构?

单选题 · easy

  • A.二十四小时内
  • B.七十二小时内← 正确答案
  • C.七个工作日内
  • D.三十天之内

答案:B。GDPR 第 33 条规定,除非泄露不太可能对个人权利造成风险,否则控制者须在获知泄露后的 72 小时内通知监管机构。这与数据主体权利请求的 30 天响应时限是两个不同概念,不能混淆。

Q8. 下列关于有效同意的构成要件,正确的有?

多选题 · mid

  • A.自由给出的选择← 正确答案
  • B.针对具体目的且知情← 正确答案
  • C.通过明确行为作出表示← 正确答案
  • D.一经给出永久有效

答案:ABC。GDPR 第 4 条第 11 款定义同意须满足“自由给出、具体、知情、明确表示”四要件,且第 7 条要求同意必须像给予一样容易撤回。D 与“可随时撤回”直接冲突,故不选。

Q9. 关于数据保护官(DPO)的说法,正确的有?

多选题 · hard

  • A.具备数据保护法律与实务专业知识← 正确答案
  • B.可直接决定数据处理目的与方式
  • C.可直接向最高管理层汇报工作← 正确答案
  • D.因忠实履职而免遭解雇保护← 正确答案

答案:ACD。GDPR 第 37-39 条要求 DPO 具备专业知识、独立履职并有足够资源,可向最高管理层直接汇报,且不得因履职被解雇或处罚。B 错误:若 DPO 亲自决定处理目的与方式,就会产生角色冲突,违背独立监督原则。

Q10. 合法利益平衡测试(Legitimate Interest Balancing Test)主要考量哪些因素?

多选题 · hard

  • A.处理目的的正当性与必要性← 正确答案
  • B.优先采用对个人影响最小的方案← 正确答案
  • C.必须事先获得监管机构书面批准
  • D.权衡数据主体的合理预期与风险← 正确答案

答案:ABD。合法利益的平衡测试三要素是:目的正当性、手段必要性、对数据主体权利与合理预期的影响,并要求优先选择影响最小的方案。C 错误:合法利益依据本身不需要监管机构事前批准,只需事后能证明平衡测试成立。