欧盟开发者GDPR合规地图API指南

您为地图 API 选择了欧盟数据中心。服务器在法兰克福。合同上写着「欧盟数据驻留」。您关闭了 GDPR 合规检查清单，确信自己已经覆盖了所有要求。

但您并未覆盖所有要求。

这是每年让欧盟开发者和 CTO 措手不及的合规漏洞，自 Schrems II 裁决使隐私盾失效并加强了对跨大西洋数据流的审查以来，其影响变得更为严重。如果您的地图 API 由美国公司提供，无论其服务器位于何处，您用户的位置数据都可能根据 CLOUD Act 被美国政府访问。在 GDPR 框架下，这是潜在的违规行为。在 DPA 审计中，这是一个发现项。

本指南解释了地图 API 使用的实际 GDPR 要求，为什么仅数据驻留还不够，CLOUD Act 风险在实践中意味着什么，以及如何根据严格的合规检查清单评估任何地图 API 供应商。这是美国映射公司无法可信写出的指南，因为它们无法通过自己的检查清单。

为什么位置数据需要认真对待 GDPR

位置数据在 GDPR 下处于个人数据和敏感数据的交汇点，具体取决于使用场景。第 4(1) 条将个人数据定义为与已识别或可识别的自然人相关的任何信息。IP 地址（每个地图瓦片请求都会发送给 API 提供商）是个人数据。包含家庭地址的地理编码查询是个人数据。GPS 坐标（如果被收集）可以用来推断家庭地址、工作地点、宗教活动、医疗预约和政治活动，可能符合第 9 条下的敏感数据。

当您的 Web 应用程序或移动应用加载地图、触发地理编码搜索或计算路线时，它会将这些数据点发送给您的地图 API 提供商。您的用户没有同意与旧金山的某家公司分享他们的位置，他们同意使用您的产品。作为数据控制者，您有责任确保每个处理该数据的次级处理者都符合 GDPR 要求。

如果您的地图 API 提供商未通过合规测试，您也未通过。

CLOUD Act 问题：为什么美国提供商无法声称完全符合 GDPR

《澄清境外合法使用数据法》（CLOUD Act）于 2018 年由美国国会通过，要求美国科技公司遵从合法的美国政府命令提交数据，无论该数据物理上存储在哪里。在法兰克福有服务器的美国公司仍然是美国公司。如果美国法院或联邦机构发出有效的 CLOUD Act 要求，该公司必须遵从。

这与 GDPR 产生了直接冲突。GDPR 第 48 条禁止在没有欧盟法律适当法律依据的情况下将个人数据转移给外国当局或法院。欧洲数据保护委员会已明确表示：在没有有效欧盟法律依据的情况下遵从 CLOUD Act 要求将构成 GDPR 违规。

这对欧盟开发者的实际影响是严峻的：

• Google Maps Platform（由美国公司 Google LLC 运营）即使通过欧洲数据中心处理请求，也受 CLOUD Act 义务约束。
• 在美国注册的 Mapbox 面临相同的结构性暴露。
• 任何合同语言或欧盟标准合同条款都无法改变提供服务的公司的基本法律管辖权。

这并不意味着这些公司在肆意分享您的数据。在实践中，CLOUD Act 要求针对的是执法用例，而非日常商业数据。但法律暴露是存在的，认真的 DPA 审计会识别出这一点。受监管的行业，包括医疗、金融、法律服务，根本无法接受这种暴露。

数据驻留与数据主权：理解区别

这两个术语在销售对话中经常互换使用，但它们的含义不同：

数据驻留意味着您的数据存储在特定地理位置。提供「欧盟数据驻留」的美国提供商将数据存储在爱尔兰或德国的服务器上。物理位置在欧盟，法律管辖权不在。

数据主权意味着您的数据受特定司法管辖区法律约束。对于欧盟数据真正具有主权，它必须由受欧盟法律约束的实体控制，而不仅仅是由美国母公司存储在欧盟土地上。

地图 API 的真正 GDPR 合规需要数据主权，而不仅仅是数据驻留。在以下情况下，这一区别最为重要：

• 您的应用程序处理医疗患者、金融服务用户或其他受监管类别的数据
• 您在面临正式 DPA 审计的行业运营（银行、保险、公共部门）
• 您的 CISO 或法律团队对次级处理者协议进行实质性审查
• 您面临数据主体访问请求或违规通知义务

对于大多数面向消费者的应用程序来说，CLOUD Act 要求的实际风险较低。但合规不是概率计算，要么合规，要么不合规。

评估地图 API 供应商 GDPR 合规性的实际检查清单

评估任何地图 API 提供商的 GDPR 合规性时请使用此检查清单：

法律实体和管辖权

• API 提供商是否在欧盟或欧洲经济区注册为法律实体？
• 母公司（如有）是否也在欧盟管辖范围内，没有在美国注册的母公司？
• 提供商是否在其 DPA 中明确确认没有 CLOUD Act 暴露？

数据处理协议

• 提供商是否提供引用具体 GDPR 条款的全面 DPA？
• DPA 是否识别所处理的个人数据类别（IP 地址、查询字符串、坐标）？
• DPA 是否规定数据保留期限和删除义务？
• 是否列出了次级处理者，它们是否也是欧盟管辖区实体？
• DPA 是否涉及违规通知时限（GDPR 要求 72 小时）？

数据存储和处理

• 所有数据是否都在欧盟内存储和处理，并有文件记录表明没有第三国转移？
• 服务之间的数据传输（CDN、分析、支持工具）是否有文件记录且符合 GDPR？
• 提供商是否在账户级别提供数据驻留选择？

安全认证

• 提供商是否获得 ISO 27001 认证（信息安全管理的国际标准）？
• 提供商是否定期接受第三方安全审计？
• 是否有记录在案的漏洞披露和补丁管理流程？

用户权利和控制

• 您能否配置 API 以最小化数据收集（例如匿名 IP、无分析跟踪）？
• 提供商是否支持数据主体访问请求和删除请求？
• 是否有应对欧盟 DPA 监管查询的文件化流程？

MapAtlas：从第一天起就为欧盟数据主权而构建

MapAtlas 是欧洲地图 API 平台，由在欧盟注册的公司 MapMetrics 运营。我们的基础设施在欧盟管辖范围内运行，没有美国母公司，没有 CLOUD Act 暴露。ISO 27001 认证已到位，我们的 DPA 记录了具体的数据类别、保留政策和次级处理者承诺。

这不是一家添加了欧盟数据中心选项的美国公司，而是一家欧盟公司，在这里欧盟合规是默认架构，而不是附加功能。

我们的地图可视化和样式 API 通过欧盟基础设施处理瓦片请求。地理编码查询、路线计算和所有其他 API 调用在离开您的应用程序的那一刻起就留在欧盟管辖范围内。DPA 反映了这一点，它不是从美国法律模板改编的样板文本。

对于在受监管行业构建应用程序的开发者，或任何希望真正合规而非表面合规的欧盟企业，这一区别是实质性的。

在 GDPR 合规方面比较地图 API 提供商

有关完整的定价和功能比较，请参阅我们对 MapAtlas vs. Google Maps 和 Mapbox vs. MapAtlas 的细分分析。如果成本也是一个考量因素，请参阅 2026 年 Google Maps API 定价，合规差距是叠加在显著价格差异之上的。

欧盟开发者现在的实际步骤

如果您目前正在使用美国地图 API 提供商并且无法立即切换，以下是降低暴露的临时步骤：

1. 在 IP 地址离开您的源站之前对其进行匿名化。 一些地图 API 允许您通过自己的服务器传递请求，在到达第三方 API 之前去除或哈希处理 IP 地址。这不能完全解决 CLOUD Act 问题，但可以减少个人数据暴露面。

2. 审计您的地图 API 实际收集的内容。 仔细阅读提供商的隐私政策和 DPA。识别他们从您的用户那里接收的每一类个人数据。在您自己的数据映射寄存器中记录这些内容。

3. 更新您的隐私声明。 您的隐私声明必须披露接收个人数据的次级处理者。如果您使用 Google Maps，Google LLC 是次级处理者。您的用户有权知道这一点。

4. 评估您使用场景的风险级别。 显示静态办公室位置地图的营销网站与将患者路由到诊所的医疗应用具有非常不同的风险概况。相应地调整您的紧迫性。

5. 切实评估迁移成本。 切换地图 API 是一项技术任务，而不是改变业务的项目。大多数迁移可以在一两个冲刺中完成。我们的定价页面显示了成本比较，我们的文档涵盖了从 Google Maps 和 Mapbox 的技术迁移路径。

欧盟的数据保护框架是世界上最全面的，并且正在被积极执行，仅 2023 年就开出了 13 亿欧元的 GDPR 罚款。位置数据是个人数据。地图 API 处理位置数据。合规链从您的用户直接延伸到您的 API 提供商。验证该链中的每个环节，如果某个环节无法通过上述检查清单，请用能够通过的环节替换它。