上海通报三款SDK：接了第三方代码，个人信息合规责任仍在企业

这件事的本质：通报的是SDK，检查的是接入方

这次被通报的不是某一家App，而是嵌入在大量应用里的第三方组件。10月10日，上海市网信办发布《关于属地App个人信息收集使用问题的通报（2026年第六批-SDK专项）》，点名三款第三方SDK存在的问题，并要求相关运营者在15个工作日内完成整改、报送情况，逾期将依法处置处罚。名单本身不必逐一细究，值得留意的是这个动作传递出的认定逻辑：组件是第三方开发的，个人信息处理的合规责任落在接入它的运营者头上。

背景可以这样理解：根据中央网信办、工业和信息化部、公安部2026年个人信息保护系列专项行动的安排，各地网信部门对属地App、小程序等产品持续开展检测。据澎湃新闻10月底的报道，上海市网信办年内已发布六批同类通报，先后覆盖景区乐园、消费零售、未成年人保护和SDK等专项；上海市通信管理局的配套治理也在推进，2026年第四批通报涉及76款存在问题的App（SDK），8月对其中9款未按期整改的应用采取了下架处理。

第六批通报里列出的问题类型并不新鲜，但对做技术的人来说很具体：告知的收集范围与实际收集情况不一致；用户明确不同意后仍在收集；未提供个性化推送退出功能；超出必要范围收集使用个人信息。依据是《网络安全法》《个人信息保护法》《网络数据安全管理条例》以及《App违法违规收集使用个人信息行为认定方法》等公开规定。换句话说，监管检测的对象是应用整体的实际行为——SDK做了什么，会被算在应用头上。

影响谁：只要页面里嵌了第三方组件，就与此相关

统计、推送、广告、地图、客服、支付，中小企业的网站、小程序和APP普遍嵌着若干第三方SDK。真正普遍的误区有三个：一是认为合规是SDK厂商的事，通报的整改对象却写着"运营者"；二是隐私政策只写了自家功能的收集项，SDK动态获取设备信息、位置、剪贴板等数据，与声明不一致正是通报里出现频率很高的一类问题；三是把SDK当黑盒接入，此后既不升级也不下线，组件版本迭代后行为变了也没有人知道。

五项可执行的检查动作

1. 先建SDK台账。把网站、小程序、APP里实际接入的第三方组件列成清单：名称、版本、来源渠道、用途、采集了哪些字段。这项工作通常一个工作日以内可以完成，却是后面所有动作的地基。
2. 逐条对齐隐私政策。台账里的每一个采集项，都要能在隐私政策里找到对应说明；实际收集超出声明范围的，要么收窄采集，要么补充披露并说明目的、方式和范围。
3. 调整初始化时序与同意机制。涉及个人信息的SDK，在用户同意隐私政策之后再初始化；用户拒绝后不能继续收集。这一项通常需要开发介入，改动集中在启动流程。
4. 补齐退出与删除路径。个性化推送提供关闭入口，投诉与举报反馈时限控制在法定范围内，账号注销后按承诺删除或匿名化处理数据。
5. 把SDK治理写进供应商管理。选型时看厂商的合规文档与更新频率，合同里约定数据用途边界；长期不升级、不再使用的组件要有下线机制，而不是一直挂在启动链路里。

成本、周期与取舍

投入上，台账梳理与政策对齐多数企业一两个工作日可完成；需要开发改动的部分（同意时序、退出开关、权限收敛）视项目规模从数千元到万余元量级不等，仅供参考。如果是正在规划的新项目，把这些机制在开发阶段内置进去，增量成本很低；等通报到了再整改，代价就变成业务停摆和下架风险。取舍上不必追求"零SDK"——第三方组件换来的开发效率是真实的，需要的是接得明白、披露清楚、随时可撤。

相关阅读：84款应用被通报后的小程序个人信息自查清单、小程序加AI功能的备案判断路径。

尊云科技在做网站、小程序与APP开发时，会把第三方组件清单与个人信息收集说明作为交付文档的一部分，帮助企业在上线前把台账建立起来。如果你不确定现有站点里嵌了哪些组件、收集了什么，可以先从一次清单梳理开始。