营销团队如何部署 AI 构建的应用而不暴露订阅者数据

安全研究员 Joel Margolis 向 Wired 表示：“营销团队中的某个人想创建一个网站。他们不是工程师，可能几乎没有安全背景或相关知识。”同一篇 Wired 报道称，安全公司 RedAccess 发现了 5,000 多个通过氛围编程构建的应用，它们几乎没有安全防护或身份验证，其中约 40% 暴露了敏感数据。Wired 无法确认其审阅的个人或企业数据是否真实。

营销团队的 AI 应用面临这一问题的特定形式。值得构建的工具——细分群组生成器、营销活动仪表板、A/B 分析器、受众同步工具——恰恰连接着订阅者名单，而且往往还连接着广告账户。

TL;DR（太长不看版）

• 为每个邮件平台 API 密钥和广告账户令牌授予工具实际使用的最小权限，并将其保留在服务器端代码中。Mailchimp 的 Marketing API 没有权限更小的密钥类型，因此只读的 Mailchimp 任务应获得仅含必要数据的有限导出文件，而非密钥。
• 邮件平台始终是订阅状态的权威来源。工具绝不让已退出的人重新订阅，将退订请求转交平台，并在其自行发送的每封营销邮件中加入有效的退订链接。
• 经过哈希处理的自定义受众上传数据仍属于个人数据：在传送前决定哪些数据可以进入广告平台和 AI 服务，并确保每次退订都同步到广告受众。
• GDPR 规范名单的保存和使用（泄露通知、无条件反对营销的权利）；ePrivacy/PECR、CAN-SPAM 或 CASL 规范邮件发送，即使邮件来自内部工具也一样。

导致订阅者数据泄露或违反同意要求的部署错误

AI 构建的营销工具在名单上出问题，通常有两种方式：名单流出（通过密钥、公开链接或上传），或被用于已明确拒绝的人。具有管理权限的广告令牌还带来另一项风险：在公司的广告账户上产生支出。

构建该应用的 AI 编程工具在收到要求后，能够完成大部分修复。将下面每条提示视为可调整的起点，并把实际使用的提示保存在每次会话都让 AI 工具读取的规则文件中。AI 工具声称已修改并不等于证据；每条提示下的验证：步骤才是。要求它标记不确定之处，不要猜测，切勿将有效密钥或订阅者导出文件粘贴到聊天中。

将完整访问权限的邮件平台密钥替换为权限最小的密钥

仅显示人数的细分群组生成器不需要能导出名单或发送营销活动的密钥，但下列每个平台权限最大的密钥都能做这两件事。存放位置同样重要：浏览器代码需要密钥值本身来发起调用，因此加载页面的任何人都能读取它（Mailchimp 完全不支持在客户端使用其 API）。

各行依据相应平台的官方文档：Mailchimp 的 API 密钥帮助页面、SendGrid 的 API 密钥权限、Klaviyo 的身份验证指南及 Mailgun 的 API 密钥文档。Listmonk 的权限在下方 Listmonk 一节说明。

工具应获得任务允许的最小权限密钥，或不获得密钥。在 Mailchimp 上，只读任务（报表、细分人数统计）更适合使用平台自己的报表工具，或由账户所有者导出仅含任务所需字段的有限文件；代价是需要人工时间，且数据新鲜度仅限于该次导出。更改和发送任务交由 IT 处理，或留在 Mailchimp 内完成。在 ActiveCampaign、Brevo 等其他平台上，应先寻找受限密钥选项。

随后，密钥仅存在于服务器端代码中（工具自己的后端，浏览器永远不会下载），并存储为环境变量：服务器在应用启动时提供给它的值，排除在代码和代码仓库之外。

查找本项目中用于我们的邮件平台（Mailchimp、Klaviyo、SendGrid、Mailgun、Listmonk 或其他平台）以及任何广告平台（Meta、Google Ads、LinkedIn 或其他平台）的每个 API 密钥、访问令牌、密码或其他机密。使用本地机密扫描器或 IT 批准的方法，检查代码、环境文件及仓库历史。绝不将原始机密值、环境文件内容或含凭据的历史发送到外部 AI 服务。只向 AI 提供经过脱敏的发现，包括文件位置及凭据类型。请逐项说明：

- 文件和行号

- 值是直接写在代码中，还是从环境变量读取

- 使用它的代码在服务器上运行，还是在浏览器中运行

任何值只显示前四个字符。绝不输出完整密钥或令牌。

将能够发送邮件、更改订阅者或管理广告账户的凭据标为最高优先级。

然后，将每个需要私有 API 密钥或访问令牌的调用移到服务器端代码中，并从仅服务器可用的环境变量读取凭据。浏览器中只保留文档明确允许的公开客户端 API 调用，从代码中移除暴露的私钥，并将含真实机密的文件排除在仓库之外。准确报告所做更改，并说明不确定之处，不要猜测。

注意：从聊天或代码中删除已粘贴的密钥，并不能收回其泄露。请撤销密钥（在平台设置中禁用，使其失效），再创建新密钥。

验证：打开工具，按 F12，选择 Network 标签，按团队实际使用方式操作，并查看每个请求的域名。浏览器请求直接调用邮件平台私有 API 是警示信号，但仅凭目的地址不能证明机密已暴露。检查请求头和代码中的私有凭据，不要将其值复制到 AI 聊天中。公开客户端 SDK 请求不同：它们可以合法使用公开标识符，而不是机密 API 密钥。在 Klaviyo 中，发往 a.klaviyo.com/client/ 的请求使用公钥，适合在浏览器发起；浏览器向 a.klaviyo.com/api/ 发起请求则需要调查，因为此端点通常要求私钥身份验证。确认私有凭据是否确实被传输。

其余工作由人处理：使用不归个人所有的账户创建受限密钥（用户访问权被撤销时，Mailchimp 会移除其 API 密钥），以工具命名（Mailchimp 建议每项集成使用独立密钥），并由 IT 协助存放到工具统一管理密钥的位置。计划轮换时，先将工具切换至新密钥，再撤销旧密钥，因为已撤销的 Mailchimp 密钥无法重新启用。若密钥已泄露，应立即撤销并更换。同时规划到期处理：2026 年 6 月 22 日及之后生成的 Mailchimp API 密钥，自创建起一年后到期。

仅为广告账户令牌授予工具实际使用的权限

我认为广告账户令牌是营销工具可能持有的影响最大的凭据，因为它关联着支出。具有管理权限的 Meta 令牌可创建、更改或暂停由公司广告账户付费的营销活动，并读取支出和效果数据。

这类令牌不会返回上传到自定义受众的订阅者名单。Meta 的自定义受众指南使用 SHA-256 哈希值（对每个地址进行单向转换，由平台与自身记录比较）来添加和移除人员，且没有文档记载的端点会从现有受众返回可读名单。

Meta 的权限参考说明了各项权限，并要求开发者仅选择应用所需权限。每个工具通过自己的系统用户获得独立令牌；这是 Meta 对 Business Manager 内供软件使用的账户的称呼，仅分配工具需要操作的广告账户。不要把构建者个人登录令牌放进工具，系统用户令牌则像邮件密钥一样留在服务器。所有 Google Ads 或 LinkedIn 访问也要进行相同清点。

列出此工具向 Meta Marketing API、Google Ads 或其他广告平台发起的每个调用，包括通过辅助库或 SDK 发起的调用。对每个调用提供：

- 文件和行号

- 端点或 SDK 方法

- 标签：REPORT（读取指标或支出）、MANAGE（创建或更改营销活动、广告、预算或受众），或 LEADS（读取潜客表单提交信息）

- 该标签在相应平台所需的权限

标记被多个工具使用的令牌，以及向浏览器发送令牌的代码。不要输出令牌值。若无法判断某个调用应使用哪个标签，请明确说明。

验证：用 Meta 令牌调试工具检查仪表板令牌，该工具会报告令牌持有的权限；将其与提示中的标签比较。报表仪表板的令牌应显示 ads_read，且不包含任何管理账户的权限；报表工具出现 MANAGE 或 LEADS 标签，就是需要处理的发现。然后在业务设置中确认工具使用的是系统用户令牌，而非构建者个人令牌。

关闭公开地址，仅向名单管理员显示订阅者行

托管在 AI 工具自有主机上的应用，只要有人找到地址就能打开。据 Wired 报道，RedAccess 检查的某些应用仅有微不足道的门槛，例如要求访客用任意电子邮件地址登录。这类托管适合使用虚构地址演示，也正是免费托管和隧道服务的设计用途。

另一半问题是进入后每个人能看到什么。营销活动仪表板负责展示活动层面的数字：打开率、点击率、A/B 结果和细分人数。背后的订阅者行——每个地址及其同意详情和互动历史——属于个人数据。

经过适当匿名化的汇总数字通常不是个人数据，但小型群组或详细分类仍可能识别个人。即使数字是匿名的，也可能透露公司竞争信息；存储每个人打开和点击记录的 A/B 分析器同样持有个人数据。团队查看汇总信息，只有管理名单的人才能查看逐行数据，并由服务器在每次请求时强制执行。

列出本应用数据库、界面、导出文件和 API 响应中包含订阅者个人数据的每个字段：电子邮件地址、姓名、电话、邮寄地址、IP 地址、位置、订阅状态、同意来源与时间、订阅日期、退订状态，以及个人打开和点击记录。对每个字段说明哪些界面和导出文件展示它。标记不确定的项目，不要猜测。

然后添加两个角色，从已登录账户获取，并在服务器上对每个页面、导出操作和 API 路由检查：

- 名单管理员：可查看订阅者行并执行导出

- 营销人员：只能查看营销活动层面的数字、细分人数和 A/B 结果，不可查看个人行或导出

其他访问均返回“拒绝访问”（403）。报告保护每个页面和路由的检查机制。

存储数据在磁盘上是否加密，要询问 IT；AI 工具无法通过阅读代码确认这一点。

验证：创建具有营销人员角色的测试账户。以该账户登录，打开营销活动仪表板（应能加载），再打开订阅者名单页面并尝试导出（二者均应停在“拒绝访问”）。然后在未登录状态下，用使用移动数据的手机打开工具地址：应完全无法加载，或停在公司登录页面。

将退订和同意记录交由邮件平台管理

工具若保留自己的名单副本，并通过双向同步或重新导入上个月导出文件写回名单，就可能把已退订者重新标为订阅，并丢失每个人在何处、何时、如何注册的记录。通常在此人收到下次营销活动之前，工具不会显露问题，而此时下述发送规则已适用。四条规则可以防止这种情况：

1. 邮件平台是订阅状态的权威来源。工具读取该状态，绝不让现有订阅者重新订阅或覆盖其记录。可以通过平台指定的退订流程转交明确的退订请求。
2. 任何批量导入或同步都不得替换现有订阅者记录，或覆盖其订阅和同意信息。经过审核的工具可以更新明确批准的字段（例如标签），但不得更改订阅状态。新注册通过平台自己的注册表单或导入路径进入，以适用平台的选择加入处理；工具自己的注册表单经过审核后，可以添加带有来源、时间和表单信息的新订阅者，但绝不能让现有联系人重新订阅，也不能覆盖其订阅或同意信息。
3. 工具进行任何发送或导出时，都在当时从平台读取状态，而非使用自己的副本。导出应排除已退订和禁止发送的联系人，或将其标为禁止发送名单，且绝不用于发送。
4. 工具复制的任何记录都须完整附带同意字段（来源、时间、表单或方式）；否则就不复制这些字段，也不声称自己持有这些信息。

列出工具向邮件平台或订阅者名单任何副本写入数据的每个位置：创建或更新订阅者的 API 调用、导入、同步和文件导出。对每项说明它是否能够：

- 更改现有订阅者的订阅状态

- 覆盖现有订阅者记录

- 包含已退订或禁止发送的联系人

对每条发送邮件或导出发送名单的路径，说明它从哪里读取订阅状态：当时的邮件平台，还是工具自己的副本。

然后修改工具，使其绝不让现有联系人重新订阅或覆盖其订阅状态，唯一例外是通过邮件平台指定流程转交明确的退订请求；绝不整体替换现有订阅者记录；在任何发送或导出前立即从邮件平台读取状态；为其复制的每条记录保留同意来源、时间和表单信息。报告所做更改，并标记不确定之处。

注意：将旧导出文件重新导入覆盖名单时，会同时带入旧状态，因此在那次导出后退订的人可能恢复为订阅状态，具体取决于平台和工具如何处理导入。

验证：在邮件平台添加测试订阅者，然后在那里将其退订。运行工具的同步、细分群组生成器和导出。在平台中，此测试订阅者应仍为退订状态；在工具导出中，应不存在或被标为禁止发送；在工具生成的任何发送名单中，都不应出现。

通过邮件平台发送，或先建立退订路径

通过 SMTP 账户或事务邮件 API 直接向名单发送唤回邮件的工具，无法自动获得邮件平台为营销邮件添加的功能（退订链接、邮寄地址、禁止发送名单检查），除非工具代码逐项实现。解决办法是让平台（或 Listmonk）负责发送，由工具构建群组或触发平台营销活动。必须自行发送的工具属于发送工具，下一节会将这类工具交由 IT 处理。

这类工具需要在每封营销邮件中提供发送后仍有效的退订链接，并在页脚提供发件人身份和邮寄地址，满足下方发送法律表中的时限要求。它还需要自己的禁止发送名单，在每次发送前检查，并作为持久的禁止发送记录维护；备份和恢复流程必须防止较旧的订阅者数据库覆盖较新的退出记录。CAN-SPAM 对事务邮件另有规定。

对于大量发送者，仅在邮件页脚放链接可能不够。Gmail 要求每天向个人 Gmail 账户发送 5,000 封或以上邮件的发件人，为营销邮件及订阅邮件提供 RFC 8058 一键退订支持。这意味着除可见退订链接外，还要添加 List-Unsubscribe 和 List-Unsubscribe-Post 邮件头。一键退订端点必须处理 POST 请求；仅通过 GET 请求打开 URL 不应让人退订。在以此规模发送前，请 IT 验证这些要求。

为工具发送的每封营销邮件添加退订链接，并实现其背后的退订端点。
若工具受 Gmail 大量发送者要求约束，还要实现由有效 DKIM 签名覆盖的 RFC 8058 一键退订邮件头，以及基于 POST 的端点。绝不能仅因 URL 被打开就触发退订。不确定之处应标记并交由 IT 审核。
退订端点收到有效请求（点击链接、提交表单或 API 调用）时：

- 立即将地址加入与订阅者表分开存储的禁止发送名单

- 记录请求时间及其来源渠道

- 若名单保存在我们的邮件平台，也通知平台将该地址退订

每次发送前检查禁止发送名单，并跳过所有匹配地址。导入、同步或数据库恢复过程中，绝不自动从禁止发送名单移除地址。遵循公司批准的保留政策，仅保留为履行退出要求所必需的最少禁止发送信息，绝不允许导入或同步重新加入被禁止发送的地址。确保备份包含禁止发送名单，恢复订阅者表时不得更改它。在每封营销邮件页脚加入我们的发件人姓名和邮寄地址，使用将由我填写的占位内容。报告更改内容及其覆盖的发送范围。

验证：在测试名单中添加一个你控制的种子地址，通过工具发送测试营销活动，并点击该种子地址收到邮件中的退订链接。该地址现在应出现在禁止发送名单中（若邮件平台保存名单，则平台中也应显示已退订）。再次向同一测试名单发送：种子地址应收不到任何邮件。

负责公司邮件合规的人提供这些占位内容所需的发件人姓名和邮寄地址。

在数据流出前，决定哪些内容可以传给广告平台和 AI 工具

有两类代码路径默认向外发送订阅者数据：将细分群组上传到 Meta 或 Google 自定义受众的同步，以及将订阅者字段传给 AI API（用于撰写主题行或潜客评分）、分析脚本和 webhook 的调用。

Meta 和 Google 可以使用经 SHA-256 哈希处理的联系人标识符匹配客户受众。Google 的 Data Manager API 要求提交前对电子邮件地址和电话号码进行规范化及哈希处理，而某些通过 Google Ads 界面进行的上传可在上传过程中处理哈希。哈希是平台将地址匹配到个人资料的方法，并不使该人匿名（参见常见问题）。

对于新的 Google Customer Match 集成，在构建同步前先检查支持哪种上传 API。自 2026 年 4 月 1 日起，Google 限制新采用者使用旧版 Customer Match 上传方法，并引导这些集成使用 Data Manager API。

Meta 的客户名单受众条款要求广告主保证拥有分享数据所需的权利、许可及法律依据。Google 的 Customer Match 政策要求在隐私政策中披露此分享，并在法律要求时取得同意。

为简化处理，此工具将每次退订也视为停止广告匹配的请求。这是公司采取的保守政策，并非声称法律要求每次针对特定渠道的邮件退订都必须从所有广告受众中移除该人。

因此，上传路径只能接收公司已批准用于广告匹配的群组；公司必须在隐私负责人或已获任命的数据保护官（DPO）指导下，确立适当的法律依据。已退订和禁止发送的联系人不得进入任何上传，退订则触发从每个受众按哈希值移除该人（下方 GDPR 一节解释原因）。

所有接收订阅者数据的 AI 或分析服务都必须经公司批准。分享个人数据前，确认提供商是作为处理者还是独立控制者，并落实适当合同保障，包括在需要时签订数据处理协议。

审计此工具发起的每个对外调用：邮件平台、广告平台（包括受众上传）、AI API（OpenAI、Anthropic 或其他）、分析工具及 webhook。逐个准确列出请求体或 URL 中出现的订阅者字段。说明哪些调用可以减少字段或完全不使用订阅者数据而完成任务。最后按名称列出所有外部服务，以便与我们批准的供应商核对。

验证：报告列出的每个发给 AI 或分析服务的订阅者字段，都应是任务必需字段；每个服务名称都应在公司批准名单上。不在名单上的服务应交由负责签署供应商合同的人处理。

对于工具中每条向 Meta、Google Ads 或其他广告平台上传联系人的路径：

- 遵循各平台的规范化规则，在上传前于服务器端对电子邮件地址和电话号码进行 SHA-256 哈希处理

- 仅上传[公司批准用于广告匹配的群组]内的联系人

- 上传时排除已退订和禁止发送的联系人

- 联系人退订时，向其曾被上传的每个受众发送按哈希值移除的请求

- 记录每次上传和移除的时间、受众、联系人数，以及触发操作的用户或任务

报告所做更改，并标记任何不确定之处。

验证：让一个属于已上传群组的测试联系人退订。工具下次同步后，检查是否已向每个相关受众发送移除请求。确认每个广告平台已成功处理移除，而不仅仅是工具记录或提交了请求。标记失败或部分完成的移除，以便重试及 IT 审核。

工具对名单执行的操作决定其运行位置

仅显示营销活动数字的工具运行在团队控制的服务器上，只能通过专用网络访问；显示订阅者行的工具还需增加公司登录，因为角色依赖它。发送营销邮件或同步广告受众的工具，应使用平台自身功能，或在任何人使用前交由 IT 处理。

审批要求对应表格各行：两个只读行需要邮件平台管理员签发密钥，更改名单的行需要第二人审阅，发送行需要 IT；受众上传还要进行隐私审核。

专用网络意味着工具完全不响应外部访问。AI 工具编写的登录页面任何人都能访问，其安全程度仅取决于背后的代码；这正是 RedAccess 能发现接受任意邮件地址登录的应用的原因。

我在这里的规则是：从专用网络开始，在角色需要的地方再叠加公司登录。对于已付费使用托管部署平台并审核供应商的团队，内置登录和机密存储的托管平台也可行。

服务器端应交由 IT 协助，并为服务器和密钥指定一名负责人。工具在 VPS（团队完全控制的租用服务器）上运行，由 Coolify 或 Dokploy 等部署工具根据代码运行应用，并保管其环境变量，包括平台密钥。

专用网络可使用 Tailscale，设置更快，但依赖它自己的协调服务（Headscale 可替代该服务）；也可使用完全自托管的 WireGuard。公司登录（使用公司账户单点登录）由 Authentik 或 Keycloak 提供，反向代理（Caddy 或 Nginx Proxy Manager）则在工具面向网络的位置添加 HTTPS。

将邮件引擎迁移至 Listmonk

除了在当前平台使用受限密钥，另一条路径是将名单和发送迁移到自托管名单管理器，从而不再使用商业平台密钥。Listmonk（v4.0.0 及更高版本）允许每个工具拥有独立 API 用户，并通过名单角色限制其只能访问该工具涉及的名单。

只读工具获得其名单的查看权限，不得发送；campaigns:send 和 tx:send（事务邮件）只授予发送工具。受限工具的角色应避免三项特别危险的权限：会覆盖按名单角色限制的 lists:get_all 和 lists:manage_all，以及 subscribers:sql_query；Listmonk 的角色和权限文档警告，后者允许“直接从数据库查询所有名单和订阅者，越过单个名单及订阅者权限”。在认定工具受名单限制前，也要审查 subscribers:get_all、campaigns:get_all 和 campaigns:manage_all 等广泛权限。只为每个 API 用户授予任务所需权限。Listmonk 面向营销活动，而非多步骤自动化（何时 Listmonk 不是合适工具）；Mautic 可在同类服务器上承担这种自动化。

代价是持续维护：团队将负责发送域名身份验证（SPF、DKIM 和 DMARC）、用于投递邮件的 SMTP 中继、补丁、备份及送达率。若名单很小、无人能负责服务器，或现有平台的发送信誉和自动化承担着团队依赖的工作，留在平台并使用受限密钥更合适。

无论哪条路径，都需要有人负责一台服务器，运行部署工具和专用网络；自托管路径还需运行 Listmonk 及 SMTP 中继。我们的 Linux VPS 提供 root 访问权限，Listmonk、Mautic、Tailscale、WireGuard 和 Authentik 可作为一键应用部署。这样 IT 协助可把时间用于配置和审核，而不是安装；持续打补丁仍由团队负责。

地点包括欧盟的法兰克福和阿姆斯特丹、英国伦敦及美国多个城市；你的选择决定工具及任何名单副本的存放地点（使用 Listmonk 时还包括名单本身）。地点是与 DPO 讨论的一项依据，不能替代讨论，也不会单凭自身使工具合规。

营销邮件的同意与反垃圾邮件规则

订阅者名单适用的 GDPR 要求

GDPR 并不要求直接营销处理必须以同意为依据：序言第 47 段称，此类处理“可被视为基于合法利益进行”。若营销改为依赖同意，第 7 条要求公司“能够证明”每个人已同意，并使撤回同意与给予同意一样容易。这正是邮件平台中同意来源和时间的作用。

更严格的规则见 GDPR 第 21 条。无论依据为何，个人都可随时反对直接营销，包括相关画像；一旦提出反对，“不得再为此类目的处理个人数据”。与同条款下其他反对不同，营销不适用利益权衡测试。对于此工具，最安全的默认做法是，将一般性的直接营销反对视为适用于该人数据的所有营销用途：发送名单、工具群组及广告受众。特定渠道的退订范围可能更窄，因此公司应与隐私负责人制定偏好规则，确保适当履行每项请求。

名单泄露或被错误更改可能构成个人数据泄露。第 33 条要求不得无故拖延地通知监管机构（国家数据保护监管部门），并在可行时于知悉后 72 小时内通知，除非该泄露不太可能给个人带来风险。英国对应法律是 UK GDPR，由 ICO 执行。

发送法律：ePrivacy 与 PECR、CAN-SPAM 及 CASL

欧盟 ePrivacy 规则及英国 PECR 要求向个人发送营销邮件前取得同意，并为现有客户提供范围有限的“软性选择加入”例外。英国另有适用于慈善目的、须满足特定条件的软性选择加入例外；本文侧重商业营销。加拿大 CASL 要求明示或默示同意。美国 CAN-SPAM 不要求发送前取得同意；它要求提供有效退出机制、在 10 个工作日内履行退出请求，并在每封邮件中提供准确的发件人信息和邮寄地址。

《ePrivacy 指令》第 13 条中的软性选择加入适用于在销售中取得、用于推销自身类似产品的联系方式，且收集时及每封邮件中都要提供免费拒绝机会。英国版本为 PECR 第 22 条规定，ICO 的邮件营销指南对此作了解释。第 13 条还禁止隐瞒发件人或未提供有效退出请求地址的营销邮件，PECR 第 23 条规定在英国作出同样要求。

CAN-SPAM 金额来自 FTC 的 CAN-SPAM 指南，其中还说明退出地址不得出售或转让，但转给受雇协助遵守 CAN-SPAM 的公司除外。CASL 规则见 CASL 第 6 条和第 11 条，处罚见 ISED 的 CASL 概述。

常见问题

GDPR 是否适用于我自行构建的新闻邮件工具？

答案取决于公司在哪里运营，以及工具持有谁的数据，而不是工具如何构建。根据第 3 条，GDPR 适用于在欧盟设立的公司，也适用于向欧盟境内个人提供商品或服务，或监测其在当地行为的欧盟以外公司。具体公司是否属于适用范围，应询问其 DPO。

我们的 Klaviyo API 密钥泄露后会怎样？

持有 Full Access 密钥的人可更改名单；Read-Only 密钥仅允许查看。创建仅含工具实际使用权限范围的替代密钥（Klaviyo 后续无法向现有密钥添加权限范围，因此现在就要选好），立即撤销泄露密钥，将工具切换至替代密钥，并检查是否存在无人认可的导出或名单更改。若名单可能已被读取，应按可能的 GDPR 泄露处理。

经过哈希处理的邮件名单仍属于个人数据吗？

根据 GDPR，若能关联回某个人，答案是肯定的。序言第 26 段将“通过使用附加信息可归属于某自然人”的假名化数据视为有关可识别个人的信息。我的理解是，广告匹配正因如此才能工作：平台可用自己已有的地址计算相同哈希值。

B2B 营销邮件遵循同样规则吗？

并非所有地方都一样。FTC 表示，CAN-SPAM 不为企业对企业邮件提供例外。PECR 的邮件规则覆盖个人，ICO 确认可以向公司发送营销邮件。对于欧盟国家和加拿大，请咨询法律顾问。