企业官网建设流程全解析

Electric 平台第三方子处理方（Subprocessor）清单全解读：从云基础设施到认证服务的合规透视

【免费下载链接】electricThe agent platform built on sync.项目地址: https://gitcode.com/GitHub_Trending/el/electric

Electric（项目仓库 GitHub_Trending/el/electric）作为"构建在同步（sync）之上的 Agent 平台"，其云服务在提供 Postgres 数据同步（shapes）、持久化流（durable streams）等能力的过程中，会委托一批第三方子处理方（Subprocessor）代为处理数据。本文以 subprocessors.md 这份官方清单为骨架，完整梳理 Electric DB Inc. 公开披露的全部 18 家子处理方及其用途、处理的数据类型与所在地区，并结合 Data Processing Addendum（DPA）、隐私政策 与仓库源码，深入说明子处理方的授权机制、反对期规则、数据跨境传输安排及可验证的落地证据。读完本文，你将能快速读懂一份标准 SaaS 合规文档的结构，并掌握评估此类服务商供应链透明度的关键视角。

什么是子处理方？为什么需要这份清单

在数据保护法律（如 GDPR）框架下，"子处理方"指处理方（Processor）为履行其与数据控制者（Controller）之间的合同义务，而委托处理个人数据的第三方供应商。Electric 在其 DPA 中明确承诺：仅在合同约定范围内按客户指示处理个人数据，且任何接入个人数据的子处理方都必须与 Electric 签订书面协议，其义务条款须与 DPA 实质相当。

这份子处理方清单正是上述承诺的落地载体——它由 Electric 按照 DPA 的要求持续维护并公开发布，任何企业客户都可以据此追踪"哪些数据由谁、在哪个司法管辖区、为了什么目的被处理"。

需要特别指出的是，这份清单并非通用模板，而是与当前项目云服务的真实运行方式一一对应的业务文档。仓库中的 DPA 即印证了其业务主线：

个人数据可包含客户通过Postgres shapes同步、写入**持久化流（durable streams）**或经其他受支持协议处理的任何数据（DPA Annex I）。

子处理方的授权流程与客户反对机制

清单的更新不是随意的。根据 DPA 的 Subprocessing 章节，其核心机制包括：

• 事前授权：客户同意 Electric 使用子处理方清单中列出的第三方供应商代表其处理个人数据；
• 新增必须更新清单：在授权任何新子处理方访问个人数据之前，Electric 必须先行更新子处理方清单；
• 通知义务：清单更新会通过邮件发送给账户所有者，并同步更新公开的清单页面；
• 10 天反对期：若客户对新增子处理方有异议，可在 10 天内基于正当、有据的理由书面提出反对；对于无法在不使用该子处理方的前提下继续提供的服务部分，客户可以书面通知终止；
• 责任承继：Electric 对其子处理方造成的任何 DPA 违约承担相应责任。

这为使用该平台的企业客户提供了一条清晰的合规路径：订阅清单变更通知 → 在反对期内评估新供应商 → 必要时行使终止权。

子处理方清单全览

以下按官方清单的 10 个功能类别，完整呈现全部 18 家子处理方。表格中的"用途"、"处理的数据"与"所在地区"均为原清单原文信息。

基础设施与托管（Infrastructure & hosting）

这一层是 Electric 云服务运行的地基：AWS 承载核心计算与存储，Cloudflare 负责 CDN 分发与网络防护（与 DPA 中"通过 CDN 在边缘缓存数据以支持读侧交付"的处理目的吻合），Neon 提供托管 Postgres 数据库托管与连接（对应平台基于 Postgres 的同步能力），ClickHouse 则承担用量类分析数据的处理。

计费与支付（Billing & payments）

DPA Annex I 中明确"计量用量以用于计费"是处理目的之一，Stripe 正是该环节的支付处理承接方，处理范围被严格限定在账单与支付信息，不涉及客户业务数据。

工作流编排（Workflow orchestration）

Inngest 承担平台的后台任务与工作流编排，所接触的数据限于用户标识符、账户元数据与服务事件数据，属于典型的运维支撑角色。

错误监控与可观测性（Error monitoring & observability）

Honeycomb 提供分布式链路追踪级别的可观测性，Sentry 负责前端与后端的异常捕获，Rootly 则编排事件响应流程。三者共同构成平台的可观测性与故障响应体系，其处理的数据均为运维类元数据而非业务内容。

支持工具（Support tooling）

值得注意的是，Fernand 是清单中唯一位于欧盟境内（法国）的支持类供应商，其在 GDPR 框架下处于欧盟司法管辖区之内。

客户关系管理（Customer relationship management）

Attio 负责沉淀销售与客户交互记录，处理范围覆盖客户联系方式、账户信息与交互历史。

分析（Analytics）

这一类别体现了"双轨"分析策略：PostHog 提供功能完整的产品级分析（其在仓库 website/package.json 中以posthog-js: ^1.236.4依赖的形式真实落地），而 Plausible 作为无 Cookie 的隐私友好方案，仅接收去标识化数据，并托管于欧盟境内。

邮件投递（Email delivery）

平台发出的邀请邮件与账户通知类事务性邮件由 Resend 投递，其处理的数据为收件人邮箱与邮件正文内容。

认证（Authentication）

这一类别与 隐私政策 中"可使用 Google 或 GitHub 等第三方服务访问平台"的描述相互印证。同时，Supabase 在本项目生态中扮演双重角色——既是 OAuth 认证子处理方，也是被 docs/sync/integrations 文档 收录的受支持的托管 Postgres 集成选项。

日程安排（Scheduling）

Calendly 用于安排 onboarding（入门引导）通话，仅处理用户邮箱与日程数据。

数据跨境传输与标准合同条款（SCC）

从上述清单的"所在地区"列可以看出，绝大多数子处理方位于美国，这与 DPA 的 Restricted data transfers 章节 直接相关。当客户受欧盟数据保护法律管辖时，Electric 作为"数据导入方（data importer）"将标准合同条款（EU SCCs，依据欧盟委员会 2021/914 号实施决定批准）并入 DPA，并完成如下关键填充：

• 启用第 7 条的docking clause（允许后续追加签约方）；
• 第 9(a) 条采用option 2，其中约定的通知期为30 天；
• 第 11(a) 条的可选救济条款被删除；
• 第 17 条适用法律为爱尔兰法，第 18(b) 条的管辖法院为爱尔兰法院；
• 英国 GDPR 适用时，同步以英国国际数据传输附录（UK SCCs）予以补全，且终止权归属于导入方。

这意味着：虽然子处理方多位于美国，但每一次跨司法管辖区的数据流转都处于 SCC 契约框架之下，为 EEA/瑞士/英国的数据主体提供了可追溯的法律保障。

仓库中的可验证证据

清单所述并非纸面承诺，仓库中可以找到多条佐证：

• website/package.json 在 dependencies 中真实声明了posthog-js: ^1.236.4，印证了 PostHog（PostHog Cloud — US）被实际用于网站与产品分析；
• DPA Annex I 完整描述了处理的数据类别（标识符、应用数据、用量与行为数据、位置数据等）、处理频率（服务存续期内持续进行）与处理目的（持久化流数据摄取、按 TTL 与保留配置存储、跨基础设施复制、边缘 CDN 缓存、通过 HTTP 流式协议向终端客户端交付、处理 Postgres 复制流（shapes）等）；
• 隐私政策 的"信息共享"章节明确将服务提供商（托管、IT、支持、邮件投递、广告与营销、网站分析等）列为共享对象，并在 Cookie 政策 中解释了第三方 Cookie 与去标识化分析的工作机制；
• 整个合规文档体系集中存放于 website/about/legal 目录，包含 subprocessors.md、dpa.md、privacy.md、terms.md 与 delete-account.md 五个相互关联的文档，构成一个自洽的合规文档集。

企业客户与开发者应当如何利用这份清单

对企业客户而言，这份子处理方清单是一份可操作的合规工具，建议按以下步骤使用：

1. 定期比对：清单页标注了"Last Updated"日期（当前仓库版本为 2026 年 7 月 23 日），结合 DPA 规定的"新增子处理方须先更新清单 + 邮件通知账户所有者"机制，订阅变更即可第一时间感知供应链变化；
2. 利用反对期：对任何新增子处理方，在 10 天反对期内评估其所在地区、处理的数据类型与用途是否符合自身合规要求，必要时行使书面终止权；
3. 对照处理范围：将自身业务数据与各子处理方的"处理的数据"列逐项比对，确认没有超出清单范围的数据被委托处理；若自身数据涉及欧盟/英国数据主体，可进一步核对 SCC 条款填充内容（爱尔兰法、30 天通知期等）是否满足审计要求；
4. 结合 DPA 审计条款：如需深度验证，可依据 DPA 的 Audit 章节 索取第三方安全审计报告，或在满足提前 30 天通知等条件下申请审计。

对技术开发者而言，这份清单同样是有价值的"基础设施地图"——它侧面勾勒出该 Agent 平台云服务的技术栈轮廓：AWS + Cloudflare 的托管与分发底座、Neon 的 Postgres 托管、ClickHouse 的用量分析、Inngest 的后台编排、Honeycomb/Sentry/Rootly 的可观测性矩阵，以及 Google/GitHub/Supabase 三种 OAuth 认证入口，为理解 README.md 所描述的同步平台架构提供了合规视角的补充。

小结

子处理方清单虽然只是一份表格，却是 SaaS 服务商数据治理透明度的核心窗口。通过将其与 DPA、隐私政策及仓库源码交叉对照，我们可以看到 Electric 在第三方数据处理上建立了"公开清单 → 事前授权 → 更新通知 → 10 天反对期 → SCC 跨境保障"的完整闭环。对于任何计划将业务数据交给该平台的团队，读懂这份清单、理解其更新机制，是开展合规评估的第一步，也是最小必要的数据治理动作。

【免费下载链接】electricThe agent platform built on sync.项目地址: https://gitcode.com/GitHub_Trending/el/electric