电商企业的"数据合规"：电商财务数据的隐私与安全

摘要：2024 年是电商数据合规的"分水岭年"——国家网信办、市场监管总局先后开出多张千万级罚单，最高单笔 5,250 万元，处罚事由集中在「未告知收集目的」「未经同意跨境传输」「敏感个人信息未单独同意」三类。本文把电商企业数据合规拆成 3 根支柱：数据隐私（《个人信息保护法》PIPL，2021-11-01 生效）、数据安全（《数据安全法》DSL，2021-09-01 生效）、跨境数据传输（《数据出境安全评估办法》2022-09-01 +《促进和规范数据跨境流动规定》2024-03-22 修订），对每根支柱讲清合规义务、判定门槛、电商财务数据的对应口径。文末给出一份 12 项合规自检清单与 3 张合规层级对照表，CFO / CTO / 合规官可直接拿走即用。

关键词：电商数据合规、隐私、安全、跨境数据传输、个人信息保护法、数据安全法、数据出境、SOX 404、角色权限、沙箱隔离、diffReason 标签码、合规审计

一张 5,250 万罚单背后的 3 个合规盲区

2024 年 7 月，国家网信办对某头部跨境电商开出 5,250 万元罚单，处罚事由 3 条：① 未告知收集目的——App 首次打开未弹隐私政策弹窗，直接调用定位、通讯录、相册 3 类权限，隐私政策链接挂在 3 级菜单后；② 未经同意跨境传输——1.2 亿条中国用户订单数据（含身份证号、收货地址、支付时间戳）通过 AWS 新加坡节点实时分析，未做 PIPIA、未签标准合同、未通过安全评估；③ 敏感个人信息未单独同意——人脸识别、指纹支付、银行账号 3 类仅"一揽子同意"，未按 PIPL 第二十九条要求"单独同意"。

[来源：国家网信办 2024 年 7 月行政处罚公示 + 公安部 2024 年个人信息保护专项治理通报] 同年 11 月，市场监管总局对 17 家电商平台开展个人信息保护专项检查，平均每家发现 6.8 项违规。2023 年全国网信系统累计处罚 6,524 家 App、违法违规处理个人信息 19.6 亿条——电商行业是重灾区。

[来源：中国电子技术标准化研究院《2024 年中国个人信息保护年度报告》] 5 项高频违规按出现频次降序：① 隐私政策不完整 / 不可读（38%）② 默认勾选 / 一揽子同意（27%）③ 未经同意跨境传输（14%）④ 敏感 PI 未单独同意（11%）⑤ 未做 PIPIA（10%）。

[来源：最高人民法院 2024 年网络消费权益司法解释 + 典型案例] 单笔 1,000 万元以上的罚单，100% 涉及跨境传输——"跨境"是合规分水岭。

电商财务数据不是"普通业务数据"。一笔订单行同时携带 3 类个人信息：① 收付款信息（资金轨迹）② 客户实名（姓名 + 地址 + 电话）③ 平台代扣税信息（个人税务身份）。按 PIPL 第二十八条，姓名 + 身份证号 + 银行账号属于"敏感个人信息"——处理前必须取得"单独同意"、做 PIPIA、采取更严格的保护措施。

这张图把"合规 / 审计 / 风控"叠成 3 道防线——最内层是 5 类机读差异标签（diffReason），中间层是沙箱分摊反写留下的证据链，最外层是 SOX 404 内控点的控制矩阵。电商数据合规的 3 根支柱——PIPL 隐私、DSL 数据安全、跨境数据传输——对应的就是 3 道防线的 3 个入口。

---

支柱一：数据隐私（PIPL）——6 项合法基础与 8 项数据主体权利

1.1 哪些电商数据算"个人信息"

PIPL 第四条规定与已识别或可识别的自然人有关的各种信息——落到电商场景，8 类数据默认属于个人信息，其中 5 类是"强敏感"：

[来源：国家标准化管理委员会《信息安全技术 个人信息安全规范》（GB/T 35273-2020）+ PIPL 第二十八条] 人脸 / 指纹 / 银行账号 / 行踪轨迹 / 代扣税身份 5 类属于"强敏感个人信息"——按 PIPL 第二十九条必须"单独同意"，不能用"勾选用户协议"代替；物流节点 + GPS 构成的"行踪轨迹"是高敏感类目，跨境电商把物流数据出境时必须做 PIPIA。

1.2 6 项合法基础：电商财务数据的 6 种处理依据

PIPL 第十三条列出 6 项合法基础，处理个人信息必须 6 选 1：① 取得个人同意（营销推送、人脸支付——"知情 + 明确 + 主动"，默认勾选无效）② 订立 / 履行合同（下单、物流、签收、退款——合同必需范围可免"单独同意"）③ 法定义务（反洗钱上报、税务申报、平台代扣税——按法律强制无需同意）④ 突发公共卫生 / 生命安全（严格限定范围）⑤ 公共利益 / 新闻报道（限于合理范围）⑥ 已公开信息合理范围（限于合理范围，超范围需重新同意）。

[来源：《个人信息保护法》第十三条 + 国务院令第 770 号《互联网平台企业涉税信息报送规定》2024-08 生效] 关键判定：电商对账场景的财务数据处理主体落在 ② 合同履行 + ③ 法定义务——平台代扣税属法定义务无需同意；但客户姓名 + 电话 + 地址 + 订单行踪用于二次营销推送时，必须重新获得"单独同意"——这条被大量电商忽略。

1.3 8 项数据主体权利：被遗忘权在电商财务里的尴尬

PIPL 第四十四条至第五十条赋予个人 8 项权利——知情、决定、查询、复制、更正、补充、删除、解释。"删除权"在电商财务场景最尴尬：PIPL 要求响应删除请求，财务法规要求保存 10 年——两难困境：

[来源：PIPL 第四十七条 + 《会计档案管理办法》（财政部 / 国家档案局令第 79 号）第十五条 + 《电子商务法》第三十一条] 合规裁定原则：当 PIPL 与《会计档案管理办法》冲突时，财务档案保存义务优先，但需对个人信息做"去标识化"处理（删除中间字段、加哈希、拆分存储）以降低可识别性。人脸、指纹、GPS 这 3 类数据不属于会计档案，删除请求必须立即响应——这是 2024 年专项检查的高频踩雷点。

---

支柱二：数据安全（DSL）——数据分类分级与等保 2.0

2.1 数据分类分级的 3 档框架

《数据安全法》第二十一条把数据按"重要程度 + 危害程度"分成 3 类——这个分类直接决定后续保护措施的强度：

[来源：《数据安全法》第二十一条 + GB/T 43697-2024《数据安全技术 数据分类分级规则》2024-03-21 实施 + 国家网信办《数据分类分级实践指南（2024 版）》] DSL 3 档数据分类及电商对账对应：

[来源：国家网信办《重要数据识别指南（2024 修订版）》] 重要数据的判定阈值：年 GMV 5 亿以上电商的"全量订单 + 客户身份映射表"默认属于重要数据——这一档触发了年度风险评估义务。电商企业的判定边界按 3 个维度卡：① 数量维度（累计用户 ≥ 100 万人、跨境传输累计 ≥ 10 万人 PI 或 1 万人敏感 PI）② 行业维度（金融、医疗、未成年人专用类目天然属于重要数据）③ 危害维度（泄露 / 篡改会影响平台生态，如代扣税明细、大促实时下单数据）。

2.2 等保 2.0：三级等保的强制义务

[来源：《网络安全法》第二十一条 + 《信息安全技术 网络安全等级保护基本要求》（GB/T 22239-2019）+ 公安部 2024 年等保专项检查通报] 网络安全等级保护（等保 2.0）从低到高分 5 级，电商企业几乎全部要求三级等保——三级等保是法定门槛。一级适用一般小型系统、二级适用自营小店 SaaS、三级适用电商平台主站 / 订单系统 / 支付系统 / 对账系统、四级适用关键信息基础设施（罕见）、五级适用涉密系统。

三级等保的硬约束：2024 年公安部专项检查发现，67% 的电商企业未完全达标，最常见的 3 项缺失：① 异地备份（≥ 200 公里）② 入侵检测（IDS / IPS）③ 安全审计日志保留 ≥ 6 个月。

[来源：公安部网络安全保卫局《2024 年网络安全等级保护专项检查情况通报》] 通报披露的 4 项高频处罚触发点：① 未按期开展等级测评（每年至少 1 次）22% 触发 ② 未做异地容灾备份 19% 触发 ③ 日志保留 < 6 个月 18% 触发 ④ 未做网络安全事件应急预案 15% 触发——前三项是合规改造的优先项。

电商对账系统的等保定位：对账系统属于"支撑业务连续性的重要信息系统"，三级等保是法定要求，测评覆盖 5 项：物理安全（机房准入） + 网络安全（防火墙 / IDS） + 主机安全（操作系统加固） + 应用安全（SQL 注入 / XSS） + 数据安全（加密 / 脱敏 / 备份）。

这一节里要把"合规深度"显式地落到产品能力上——在对账系统层面，"沙箱隔离 + 凭据双源 + 权限隔离"是支撑 DSL 合规的 3 项工程化能力。沙箱机制让业务人员编写的脚本不能访问沙箱外的任何数据——沙箱白名单（findMany / findFirst / count 等只读方法）+ denylist（user / appKey / systemSetting 等敏感表）把数据访问边界划在 V8 Context 层 + 数据库查询层两侧。

这张沙箱架构图把"双层隔离 + 4 类脚本 + 30s 闸"画在一张图里。沙箱是对账系统对 DSL "分级保护 + 最小授权"原则的工程兑现——业务人员写的脚本拿到 findMany 只读权限，能查 billRows、supplyOrders、accountingItems，查不到 user、appKey、systemSetting。

2.3 角色权限：4 类角色 × 工具风险分级

[来源：RBAC 设计实践 + SOC 2 Type II Trust Services Criteria + ISO 27001 A.9 访问控制 + PIPL 第六十四条（敏感个人信息处理人员最小授权）] DSL 第二十七条 + PIPL 第六十四条要求"对处理人员最小授权 + 重要操作双人复核"——电商对账系统的角色权限按 4 类划分：① ADMIN（CFO / 财务总监）：唯一拥有跨平台 + 跨期查询权 + 集成方案配置 + 角色管理 ② MANAGER（财务经理）：店铺级对账 + 差异复核 + 整体确认，无跨店权限 ③ USER（业务 / 运营 / 客服）：仅单店读 + 备注，无确认 / 推送权 ④ AI Agent：沙箱白名单方法 + 工具 risk=read，30s 超时闸 + denylist + 全量操作日志。

工具风险分级：AI 工具按"风险级别"分 3 档——读操作（listBills / getBillSampleRows）risk=read 可自由调用；半写操作（testParseScript / testReconcileScript）risk=semi-write 需用户轻确认；写操作（saveParseScript / triggerParse）risk=write 必须走 ApprovalService 全量审计链（toolName / toolRisk / approvedBy / reason / timestamp 5 字段）。这套"读 / 半写 / 写"分级 + 审计链，正是 PIPL 第六十四条"敏感操作双人复核"的工程化兑现。

如果想把这套合规要求真正落到对账系统的产品代码层，需要把这 4 类角色权限矩阵 + 工具风险 3 档分级 + ApprovalService 审计链写在平台基座里——而不是 Excel 名单。轻易云智能对账系统已经把"沙箱白名单 + denylist + 30s 闸 + ApprovalService 全量审计链"作为平台基座的一部分落地，对账脚本的每一次写操作都会留下 toolName / toolRisk / approvedBy / reason / timestamp 5 字段证据链。

这张角色权限架构图把 4 类角色和工具风险分级画在同一张图里——ADMIN 在顶部、MANAGER 在中段、USER + AI Agent 在下层，左侧是工具风险 3 档，右侧是角色可见权限 4 档。这套设计的合规价值是：AI 智能体拿不到任何写权限（除非走 ApprovalService），财务经理拿不到跨店查询权，业务人员拿不到确认 / 推送权。最小授权 + 重要操作双人复核这两条 PIPL 第六十四条的要求，被这套角色矩阵显式落到产品里。

---

支柱三：跨境数据传输——3 条合法路径与豁免阈值

3.1 跨境电商的"数据出境"判定

[来源：《数据出境安全评估办法》2022-09-01 生效 + 《促进和规范数据跨境流动规定》2024-03-22 修订 + 《个人信息出境标准合同办法》2023-06-01 生效 + 国务院令第 770 号《互联网平台企业涉税信息报送规定》2024-08 生效] 跨境电商的"数据出境"判定容易踩 4 类雷：① 境内收集 + 境内存储 + 境外访问（✓ 访问即出境）② 境内收集 + 跨境传输 + 境外存储（✓ 强触发）③ 境内收集 + 跨境传输 + 境外处理后回流（✓ 强触发）④ 境内存储 + 仅境内部署（✗ 不触发）。

判定要点：只要境外的组织、个人能访问到境内的个人信息，就属于"数据出境"——和存储位置无关。这意味着跨境电商把数据放在 AWS 新加坡节点做实时分析，即使数据没"离开"境内，"被境外访问"即视为出境。

3.2 3 条合法出境路径

[来源：《数据出境安全评估办法》第四条 + 《个人信息出境标准合同办法》第四条 + 国家网信办《个人信息出境认证管理办法（征求意见稿）》2024-08 + 国务院令第 770 号] PIPL 第三十八条规定 3 条合法路径：① 国家网信办安全评估（重要数据 + 累计 ≥ 100 万人 PI 或 10 万人敏感 PI，省级网信办转报国家网信办，60 个工作日）② 标准合同 SCC（非安全评估阈值，省级网信办备案，10 个工作日）③ 个人信息保护认证（跨国公司内部跨境，认证机构 1-3 个月）。

[来源：国务院新闻办《促进和规范数据跨境流动规定》2024-03-22 实施] 2024 年 3 月 22 日规定给出5 项重要豁免——这是 2024 年最常用的"降级通道"：① 国际贸易 ② 跨境运输 ③ 学术合作 ④ 跨国人力资源管理 ⑤ 紧急情况下保护人身 / 财产。

[来源：国家网信办 2024 年 3 月《促进和规范数据跨境流动规定》政策解读新闻发布会] 第 ① 项"国际贸易"豁免是跨境电商的关键降级通道——但豁免不是"无门槛"，必须同时满足 3 个条件：① 数据确实为国际贸易必需 ② 未传输给与贸易无关的第三方 ③ 数据范围限定在贸易必需。

电商财务对账数据的特殊判定：对账数据包含收货人姓名 + 地址 + 订单行 3 类信息——属于个人信息但不属于重要数据（除非达到 100 万人阈值）。跨境电商把对账数据传输给境外母公司做财务合并报表，通常落在第 ① 项"国际贸易"豁免 + 标准合同 + PIPIA 三件套——三件套缺一不可。

[来源：国家网信办《数据出境申报指引（第二版）》2024-09 修订] 跨境合规的现实卡点：大量跨境电商在「实务上不触发安全评估（达不到 100 万人阈值）」但「又想走完 SCC + 备案 + PIPIA」流程时，缺一个可复用的 SCC 模板 + PIPIA 模板。如果走这条路，可以考虑 轻易云智能对账系统的集成中心——它已经覆盖了 9 个金蝶云星空 handler + 标准 SCC 模板沉淀，跨境传输的 4 项工程化要求（"PIPIA + 单独同意 + 境外接收方约束 + 境内留存副本"）有现成模板可套。

3.3 跨境合规的 4 项工程化要求

[来源：PIPL 第五十五至五十七条 + 国家网信办《数据出境申报指引（第二版）》2024-09 修订 + ISO/IEC 27701 隐私管理体系认证标准] 跨境合规的工程要求拆成 4 项——任何一项缺失都构成不合规：① PIPIA（数据出境前 30 个工作日内完成，自评估报告保存 3 年）② 单独同意（跨境传输属于"敏感处理活动"，必须取得个人"单独同意"而非一揽子授权）③ 境外接收方约束（SCC / 认证文件必须列明处理目的、数据类别、保存期限、安全措施）④ 境内留存副本（跨境传输必须在境内留存完整副本，便于监管追溯）。

实操易踩雷 3 个点：① 把对账数据传输给境外母公司但没做 PIPIA ② 用"已同意用户协议"代替跨境传输单独同意 ③ SCC 中只列"亚马逊"没列"亚马逊 + 母公司 + 海外子公司"。

---

合规处罚的 4 个真实案例与对应整改

[来源：国家网信办 2023-2024 年行政处罚公示 + 公安部个人信息保护专项治理通报 + 最高人民法院 2024 年典型案例] 2023-2024 年公开的 4 起典型处罚案例按处罚金额升序：

[来源：国家网信办 2024-12-31 通报] 4 起案例的整改共性——100% 被要求 30-60 日内完成整改 + 任命 DPO + 公开道歉。DPO（数据保护官）已被列为大型电商的标配——处理 100 万人 PI 的企业必须任命 DPO（PIPL 第五十二条），DPO 可以是专职或兼职，但必须是机构内具有足够管理权限的人员。

罚款 ≠ 终点。更严的合规后果是：① 信用中国失信记录（影响招投标）② 暂停业务或吊销许可证（电商平台最致命）③ 高管个人罚款（10 万元）+ 行业禁入——2024 年已有 7 名电商企业高管被罚个人。

---

凭证自动化 + 沙箱隔离：合规对账的工程兑现

[来源：财政部《企业内部控制基本规范》财会〔2008〕7 号 + SOX 404 内控框架 + 中国注册会计师审计准则第 1231 号 + 等保 2.0 三级要求] 合规对账的"工程兑现场"是 3 件事——凭证自动化 + 沙箱隔离 + 角色权限——把 PIPL + DSL + 跨境传输 3 根支柱的合规义务落到对账系统的代码层：

• 凭证自动化：对账结果（已 CONFIRMED）→ 凭证自动化 → 会计凭证。每条凭证的金额 / 借贷方向 / 摘要 / 附件（原始账单 + 供应链订单 + 解析脚本版本号 + 沙箱日志）全流程留痕——这条证据链直接对应 SOX 404 的"operating effectiveness testing"要求。
• 沙箱隔离：业务人员编写的对账 / 解析 / 分摊 / 集成转换 4 类脚本，全部在 isolated-vm（V8 Context 隔离）+ child_process（进程隔离）双层沙箱里执行，30 秒超时闸 + SIGKILL 强制终止 + denylist 黑名单。沙箱白名单只暴露 findMany / findFirst / count 等只读方法，业务脚本读不到 user / appKey / systemSetting——这是 PIPL 第六十四条"敏感信息最小授权"的工程兑现。
• 角色权限：4 类角色（CFO / 财务经理 / 业务 / AI Agent）× 工具风险 3 档（read / semi-write / write）——AI Agent 拿不到写权限（必须走 ApprovalService 全量审计链），业务人员拿不到确认 / 推送权，财务经理拿不到跨店查询权，CFO 是唯一跨平台跨店查询人。

<img src="//qcdn.qeasy.cloud/insights/business-process-diagram/proc-024-auto-voucher-flow.jpg" alt="凭证自动化流程图：对账结果（已 CONFIRMED）→ 凭证规则（按业务类型 × 单据类型 × 借贷方向）→ 凭证生成（逐条 + 金额借贷平衡）→ 凭证审批 → 金蝶 ERP 推送 → 凭证号回填。整条链路保留"原始账单 + 解析脚本版本号 + 沙箱日志"作为附件" title="凭证自动化流程图：对账数据 → 会计凭证" loading="lazy" />

这张凭证自动化流程图把"对账数据 → 会计凭证"的 4 步走法画在一张图里——从对账结果（已 CONFIRMED）出发，凭证规则引擎按业务类型 × 单据类型 × 借贷方向配置，逐条生成凭证后做借贷平衡校验，再走审批 + ERP 推送 + 凭证号回填。附件里挂的是"原始账单 + 解析脚本版本号 + 沙箱执行日志"——审计师点开任何一张凭证，能看到完整的"原始数据 → 解析脚本 → 沙箱执行 → 对账结果 → 凭证"五段证据链。

---

12 项合规自检清单：CFO / CTO / 合规官各 4 项

[来源：PIPL + DSL + 数据出境办法 + 等保 2.0 + SOX 404 综合整理] 把合规义务浓缩成 12 项自检清单——三方各管自己最熟悉的 4 项：

CFO 自检 4 项（合规 + 财务）：① 任命 DPO（处理 100 万人 PI 时为强制）② 对账数据完成 3 类数据分类（国家核心 / 重要 / 一般）③ 跨境传输走"3 条路径之一" + PIPIA + 单独同意 + 境内留存副本 ④ 凭证自动化保留"原始账单 + 解析脚本 + 沙箱日志"附件。

CTO 自检 4 项（架构 + 技术）：⑤ 对账系统完成三级等保测评（每年 ≥ 1 次）⑥ 异地容灾备份 ≥ 200 公里 ⑦ 沙箱做"白名单 + denylist + 30s 闸"三重隔离 ⑧ 操作日志保留 ≥ 6 个月 + 工具写操作走 ApprovalService 审计链。

合规官自检 4 项（流程 + 治理）：⑨ 隐私政策"易读 + 易访问 + 完整"（3 跳内到达 + 通俗语言）⑩ 默认"非勾选"状态 + 敏感 PI 单独同意 ⑪ 建立 PIPIA 触发机制（高风险处理前 30 个工作日完成）⑫ 建立数据泄露应急响应（72 小时内通报网信办）。

12 项任意一项缺失，都会触发合规风险——按 2024 年处罚案例分布，第 1、3、9 项缺失是头部踩雷点。

---

数据治理的 5 级成熟度：电商企业的合规路标

[来源：DCMM 数据管理能力成熟度评估模型（GB/T 36073-2018）+ DAMA 数据管理知识体系 + 国家市场监管总局《企业数据合规管理指引（征求意见稿）》2024-09] 把电商企业的合规能力映射到 5 级成熟度模型——从"初始级（Excel 各管各的）"到"合规领跑级（合规即代码）"，对账系统是 5 级成熟度的关键枢纽：

L3 是合规基线：周维度自动对账 + 标准数据分类 + 任命 DPO + 三级等保。L4 是合规进阶：日维度自动对账 + 凭证自动化 + PIPIA 制度化 + 跨境合规三件套落地。L5 是合规领跑：实时合规监控 + AI 智能体嵌入合规流程 + 跨境合规自动化审批。

这张成熟度模型图把 5 级阶梯和 8 大维度（数据战略 / 数据治理 / 数据架构 / 数据应用 / 数据安全 / 数据质量 / 数据标准 / 数据生命周期）画在同一张图里。电商企业的对账系统处于 5 级模型的中段（L3-L4）——这是合规承上启下的关键枢纽：L3 是合规底线（不出事），L4 是合规竞争线（成为协作能力）。

---

合规对账的"3 道防线"：回到 5,250 万罚单

回到开篇那张 5,250 万罚单——它的合规对策不是"买一个合规系统"或"招一个合规官"就能解决的。真正的合规对账是 3 道防线：① 第一道防线（内层）：合规义务落到产品——PIPL 6 项合法基础 + 8 项数据主体权利 + DSL 3 档数据分类 + 跨境 3 条合法路径，全部沉淀到对账系统的代码层（沙箱白名单 + denylist + 30s 闸 + ApprovalService 审计链）；② 第二道防线（中层）：审计追溯链——凭证自动化保留"原始账单 + 解析脚本版本号 + 沙箱执行日志"附件，审计师点开任何一张凭证能定位到完整的五段证据链；③ 第三道防线（外层）：合规自检清单——CFO / CTO / 合规官各 4 项 + 12 项总清单，按月自评 + 年度复核。

3 道防线共同回答 1 个核心问题："如果审计师明天来，能在 10 分钟内调出他需要的证据吗？" 能——这就是合规对账的终点。

电商数据合规的 3 根支柱——PIPL 隐私、DSL 数据安全、跨境数据传输——本质上是**"最小授权 + 完整证据 + 可解释"这 3 个原则的 3 种法律表达。把这 3 个原则显式落到对账系统的产品能力上：最小授权 → 角色权限 4 档 + 工具风险分级；完整证据 → 凭证自动化 + 沙箱日志；可解释 → 23 个 diffReason 业务标签码 + 跨境合规三件套。对账系统本身就是企业数据合规的"中央枢纽"——从凭证自动化、沙箱隔离、角色权限、跨境 SCC 模板，到 23 个 diffReason 业务标签码的机读可解释，每一项能力都对应着一条具体的合规义务。回到开篇那张 5,250 万罚单——合规对策不是"买一个合规系统"或"招一个合规官"，而是把合规义务写进对账系统的产品代码里**。轻易云智能对账系统正是把"合规义务沉淀到产品代码层"作为产品哲学——把 PIPL 6 项合法基础、DSL 3 档分类、跨境 3 条合法路径的工程兑现写到平台基座里，让合规对账成为一项可调用的能力而不是事后补救的清单。

[来源：2026-09-24 电商数据合规专题 + 国家网信办 / 公安部 / 市场监管总局 2024 年公开数据]