2026 年 9 月 11—12 日，根据中央网信办、工业和信息化部、公安部联合发布的《关于开展 2026 年个人信息保护系列专项行动的公告》，经国家计算机病毒应急处理中心检测，75 款移动应用被通报存在违法违规收集使用个人信息情况。
通报依据：《网络安全法》《个人信息保护法》《网络数据安全管理条例》《App 违法违规收集使用个人信息行为认定方法》。
这类通报本身不新鲜——8 月 14 日已经有过一批 75 款（央视、中新网均有报道）。真正值得细看的是这一批名单的构成：被点名的主体大量是寄生在超级平台内的小程序，业务是租机、充电、出行、挂号这类即扫即走的生活服务。
这是一个明确的信号：个人信息保护执法，已经从头部 App 下沉到长尾应用。
一、名单里最扎眼的一组：26 款「第一类问题」
通报的第一类问题共 26 款，集中在两件事：
- 首次运行时未通过弹窗等明显方式提示用户阅读隐私政策；
- 处理个人信息前，未显著告知处理者名称、联系方式和保存期限。
这两项的技术含量极低，整改成本也不高——但正是最容易失分的地方。
26 款里的构成
据对通报名单的整理，微信小程序、支付宝小程序占了相当大的比重，按业务类型分：
| 类型 | 被点名的例子 |
|---|---|
| 租机类 | 爱豆租机、兜来租 |
| 充电类 | 习牛充电、小福充电 |
| 出行类 | 叮达出行、交发智慧出行 |
| 教育类 | 万校互联教育、阅达教育、有道精品课、云上书院 |
| 医疗类 | 厦门大学附属第一医院互联网医院、郑大一附院掌上医院 |
把这五类摆在一起看，会发现它们有一个共同的使用场景：租充电宝、扫码骑车、挂号问诊。
这个共同点非常重要：这些场景下，没有一个用户会在扫码前翻隐私政策。
不是用户不重视隐私，是场景不允许——扫码租充电宝的时候，手机可能只剩 3% 电量；挂号问诊的时候，可能正在医院大厅排队。这些场景的共同特征是：用户的使用动机极强、时间压力极大、替代方案极少。
而这恰恰是通报盯上这条链路的原因：告知义务的规定，从来不考虑用户「有没有时间看」，只考虑运营者「有没有以显著方式告知」。 只要弹窗没出现，无论用户会不会看，都算违规。
二、为什么这次沉到了小程序
过去几年，个人信息通报的对象主要是下载量巨大的独立 App，头部企业被点名是常态。这一次的变化在于主体的形态：小程序。
三个原因叠加，让小程序成了合规洼地：
① 开发门槛低 → 运营方合规能力弱
小程序的开发和发布成本远低于独立 App，运营方往往是没有专职法务的中小企业。隐私政策要么直接抄模板（抄来的模板常常连处理者名称都没改），要么干脆没有。
② 入口在平台 → 责任认知错位
很多小程序运营方有一个认识误区：业务跑在微信、支付宝的容器里，用户授权用的是平台提供的登录组件，合规责任自然归平台。
这个理解站不住，下一节专门讲。
③ 数量巨大 → 长尾几乎未被覆盖过
小程序的总量远超独立 App，而绝大多数从未进入过监管视野。过去不是它们合规，是还没轮到它们。
第三点是这次通报真正的含义：检测能力上来了。 国家计算机病毒应急处理中心的检测是自动化、批量化的，一旦把小程序纳入检测范围，长尾就会以每批数十款的规模持续出现在名单上。
一个可以验证的推论：这不会是最后一批小程序占比高的名单。 因为存量还没清完。
三、「寄生在平台内」豁免不了独立合规义务
这是小程序运营方最需要纠正的认知。三个层次：
第一层：运营者是独立的个人信息处理者。
《个人信息保护法》第十七条规定的告知义务直接落在运营者头上，不因技术载体在平台内而转移。小程序不是「平台的一个功能」，它是一个独立的业务主体在采集和处理个人信息。
第二层：平台组件替代不了运营者的动作。
平台的登录组件解决的是身份识别和基础授权的问题；而隐私政策的告知、处理目的/方式/范围的披露、第三方 SDK 的列明，都是运营者自己的动作——平台既不知道你跑了哪些 SDK，也不会替你写隐私政策。
第三层：平台责任与运营者责任是两回事，不能互相抵充。
平台方对入驻小程序负有审核和管理义务，出现纠纷时平台可能承担相应责任。但这与运营者自身的处理者义务是并列关系，不是替代关系。以为「平台会替我担着」，是把两件事混为一谈了。
一个反直觉的判断：平台生态反而放大了风险
换个角度看这件事，结论会更严重：
- 一款独立 App 被下架，用户还能通过官网、其他应用商店、历史安装包找到运营方；
- 一款小程序被平台下架，等于业务入口瞬间归零。
对依赖单一平台入口的生活服务企业来说，个人信息合规问题处理不好，损失的不只是行政责任，而是整个获客渠道。
这解释了为什么小程序在这个问题上反而应该比独立 App 更谨慎——它的容错空间更小。
四、第二类问题：第三方 SDK 披露不全
通报的第二类问题同样常见：隐私政策未逐一列出 App 本身及委托的第三方、嵌入的第三方代码插件收集使用个人信息的目的、方式和范围。
通俗讲就是：第三方 SDK 披露不全。
一个小程序里通常塞着支付 SDK、统计 SDK、地图 SDK、广告 SDK，而隐私政策里却只字不提。这在《App 违法违规收集使用个人信息行为认定方法》里属于明确的违规情形。
这一项的难点不在写作，在盘点
这一条整改起来最烦的地方是：多数企业说不清自己的小程序里到底跑了几个 SDK。
原因有三：
- 依赖传递：你引入的 SDK 自己还会引入别的 SDK，你未必知道。
- 历史沉淀：几年前的 SDK 还留在代码里，功能早就不用了，但初始化还在。
- 多端差异：同一个业务在微信、支付宝、抖音各有小程序版本，SDK 清单不一样，而隐私政策只有一份。
所以正确做法不是「改文案」，而是先做一次 SDK 盘点：
- 静态扫描：从构建产物里提取所有 SDK 标识（包名、初始化调用、特征字符串）；
- 运行时抓包：实际跑一遍，看有哪些外发域名；
- 两相对照：抓包发现的外发域名，必须在隐私政策里找得到对应的 SDK 说明。
抓包这一步特别实用，因为它能发现「文档里没写的 SDK」——这类 SDK 通常是历史遗留或依赖传递带进来的。
五、认定标准与执法链：从 2019 年到现在的完整闭环
认定标准的沿革
| 时间 | 文件 | 作用 |
|---|---|---|
| 2019 年 | 四部门发布《App 违法违规收集使用个人信息行为认定方法》 | 把「未公开收集使用规则」「未逐一列出第三方代码、插件收集使用个人信息的目的、方式、范围」等情形逐条列明，认定口径至此基本固定 |
| 2021 年 | 《个人信息保护法》施行 | 上位法，第十七条明确告知义务 |
| 2025-01-01 | 《网络数据安全管理条例》施行 | 网络数据安全的行政法规层级补充 |
| 2026 年 | 中央网信办、工信部、公安部《关于开展 2026 年个人信息保护系列专项行动的公告》 | 本年度专项行动，常态化分批通报 |
认定方法 2019 年就定下来了——这一点很关键，意味着当前被通报的绝大多数问题，不是因为规则变了，而是因为规则终于被批量执行了。
执法链已经闭合
更值得注意的是执法的递进结构。链条是：
1 | 检测发现 → 公示通报 → 整改期 → 复检/复测 → 下架 → 行政处罚 → 不良名单 |
链条上的每一环都有实证：
- 复检：上一期通报的 72 款违法违规移动应用，经复测仍有 24 款存在问题——复检不是走过场。
- 下架：就在通报前一天，2026 年 9 月 11 日，上海市通信管理局对 8 月公示的、整改期限内经复检仍未整改的 6 款 App（SDK）依《个人信息保护法》《网络安全法》《电信条例》《电信和互联网用户个人信息保护规定》作下架处理。
把这两件事放在一起看，就能明白整改窗口期是真实的考验，不是走流程：
公示之后进入整改期 → 期满复检 → 复检不过直接下架 → 下架之后还可能面临行政处罚和不良名单记录。
同一份通报，有的企业改完继续经营，有的企业一步步滑向下架，差别就在对窗口期的处置上。
六、分层整改清单
结合通报列出的问题类型，小程序运营方可以按顺序自查这几项。难度从低到高：
一、首次运行弹窗（最容易改，最常被忽略）
小程序首次启动时，以弹窗等明显方式提示用户阅读隐私政策。
这是被通报的第一大问题。判断标准很简单：靠用户自己到「设置」里翻隐私政策，等于没做。
二、告知要素齐全
四项内容必须以显著方式、清晰易懂的语言真实、准确、完整写明：
- 处理者名称：写公司全称，不能只写产品名（这一条是抄模板最容易漏的）
- 联系方式
- 保存期限
- 处理目的和处理方式
医疗、教育类小程序要特别注意：涉及敏感个人信息的，告知和单独同意的要求更高一档。这也是为什么名单里医疗、教育类小程序占比不低。
三、第三方 SDK 逐一披露
在隐私政策中逐一列明所有第三方代码和插件的名称，以及收集使用个人信息的目的、方式、范围。
工作量在盘点而不在写作（见第四节）。
四、最小必要
扫码即用的场景，不该为了营销便利强制索取通讯录、位置、相册的全套授权。
这一项是复检环节的重点核查内容。判断标准：授权范围与业务功能是否直接相关。
- 扫码租充电宝要位置：合理（要找柜机）。
- 扫码租充电宝要通讯录：不合理。
- 挂号问诊要身份证号：合理（实名就医）。
- 挂号问诊要相册全量访问：不合理（用系统选择器即可）。
五、整改窗口期管理
一旦被公示，把整改当项目来做：
- 逐条对照通报问题回改；
- 保留整改记录（复检时这是你的证据）；
- 给复检留出缓冲时间，不要卡在最后一天提交。
心存侥幸熬过公示期，等来的就是上海那 6 款的结局。
七、自测流程：把你的小程序当成通报对象走一遍
下面这套流程不需要法律背景，产品/技术同学自己就能做。按顺序走一遍，大约半小时：
第 1 步：全新安装一次
- 卸载/删除小程序，清除缓存，重新从入口进入（这一步很重要——很多问题在「已授权状态」下看不到）。
- 记录：首次启动时有没有隐私政策弹窗？
第 2 步：读一遍自己的隐私政策
- 有没有写处理者的公司全称？（不是产品名、不是品牌名）
- 有没有写联系方式？
- 有没有写保存期限？
- 有没有逐一列出第三方 SDK（名称 + 目的 + 方式 + 范围）？
第 3 步：抓一次包
- 从启动开始全程抓包，导出所有外发域名。
- 逐个对照隐私政策：每个外发域名，都能在隐私政策里找到对应的说明吗？
- 找不到对应说明的域名，就是待整改项——它可能是历史遗留 SDK，也可能是依赖传递带进来的。
第 4 步：查授权时机
- 权限是用到时才申请，还是启动时一次性全要？
- 拒绝某个权限后，业务还能不能用？（拒绝即退出 = 强制授权，属于违规情形）
- 申请的权限里，有没有与业务功能无直接关系的？
第 5 步：查第三方共享
- 看隐私政策里的共享清单是否完整（支付、统计、推送、地图、广告、客服、风控——逐个核对）。
- 特别检查：有没有接入了新的 SDK，但隐私政策没更新？这是最常见的不一致。
第 6 步：留证据
- 整改前后各截一次图，标注日期。
- 保留整改记录（改了什么、什么时候改的、由谁确认的）。
第 2 步和第 6 步最容易被跳过，但它们恰恰是最有决定性的两项：前者是 26 款被通报的直接原因，后者决定复检不通过时你能否自证。
八、三个常见疑问
疑问一：「隐私政策写了，用户不看，还算履行告知义务吗？」
算。法律上要求的是运营者以显著方式告知，不是用户实际阅读。这也是为什么通报的表述是「未通过弹窗等明显方式提示用户阅读隐私政策」——考核的是运营者的动作，不是用户的反应。
这个逻辑其实很合理：如果以「用户是否实际阅读」为标准，运营者只要把提示做得越隐蔽越好（反正没人看），反而会激励规避行为。
疑问二：「我们只采集手机号，也不算敏感信息，应该问题不大吧？」
两个误区：
- 不构成敏感个人信息，不等于没有告知义务。 告知义务适用于所有个人信息，不区分是否敏感。
- 采集范围不是唯一考核项。 通报里的问题大量集中在「有没有说清楚」，而不是「采了多少」。采集少但没说清楚，一样会被通报——这次 26 款里，多数问题正是「没说清楚」而不是「采得太多」。
反过来，敏感个人信息（医疗健康、生物识别、金融账户、行踪轨迹、不满十四周岁未成年人信息）的处理要求更高一档：需要单独同意、更充分的必要性说明。名单里医疗、教育类小程序占比不低，与此有关。
疑问三：「被通报之后改完就行了吧，影响大吗？」
取决于是否在整改期内改完并通过复检：
- 改完并通过复检 → 通报记录仍在，但业务不受影响；
- 改完但复检未通过 → 进入下架程序（上海 9 月 11 日那 6 款就是这个结局）；
- 未整改 → 下架 + 可能的行政处罚 + 不良名单记录。
另外要注意一个次生影响：通报是公开信息，会被媒体转载、被用户检索到。对被点名的产品来说，一次通报带来的品牌影响往往大于整改成本本身。
九、三个延伸判断
判断一：通报的频率会继续提高，因为检测是自动化的。
2026 年这一系列专项行动已经形成了明显的节奏（7 月、8 月、9 月连续通报）。检测由国家计算机病毒应急处理中心承担，是批量自动化的。这意味着名单长度取决于检测批次安排，而不是取决于「企业有没有变好」。
判断二：小程序的合规成本会转嫁到平台侧。
平台对入驻小程序负有审核和管理义务。当长尾小程序持续不合规，平台会被迫前置审核（例如强制要求提交隐私政策、强制弹窗组件）。最终结果是：小程序运营方会失去一部分「自由」，换来平台提供的标准化合规组件。
这对小企业其实是好事——合规从「自己搞懂法律」变成「按平台要求填空」。
判断三：9 月 20 日是个人信息保护日，这类通报大概率会集中发布。
2026 年国家网络安全宣传周的主题日是：9 月 18 日金融日、9 月 19 日青少年日、9 月 20 日个人信息保护日。
按照往年惯例，主题日前后会有对应的政策发布、成果展示与典型案例通报。「复检仍有 24 款存在问题」这类数据，很可能会在个人信息保护日当天被再次强调——因为它是执法链条闭合的最好证明。
十、一句话总结
这份 75 款名单真正的信号不是「又抓了一批」，而是两件事：
- 执法的重心从头部 App 下沉到了长尾小程序——过去不是它们合规，是还没轮到它们；
- 执法链条已经完整闭合——公示、整改、复检、下架、行政处罚、不良名单，每一环都有实证，整改窗口期是真实的考验。
对小程序运营方来说，最需要纠正的是那句「我们跑在平台里，合规归平台」。小程序运营者是独立的个人信息处理者，这个身份不因技术载体而改变；而且被平台下架的代价，比独立 App 被下架更大。
附：这次名单里暴露的三个「产品惯性」
通报名单里有几类问题，看起来是合规问题，实质是产品设计惯性。这三条尤其值得产品同学记下来：
惯性一：把隐私政策藏在「设置」深处。
很多小程序的隐私政策入口在「我的 → 关于 → 隐私政策」，三层之后。设计动机是「不打扰用户」，但合规要求恰恰相反——必须主动、显著地出现在首次使用时。
惯性二：隐私政策写产品名，不写公司名。
产品同学习惯用品牌名指代自己（「本小程序由 XX 提供」），但法律要求的是处理者的名称，也就是营业执照上的那个全称。抄模板时最容易漏掉这一项。
惯性三：第三方 SDK 只写「我们可能使用第三方服务」。
这句话在合规上等于没写。要求是逐一列明：名称、目的、方式、范围。原因是「第三方服务」这个说法无法让用户判断自己的信息到底给了谁。
这三条的共同点是：它们都是「更好看/更省事」的设计选择，而不是「更安全」的选择。当合规要求和产品惯性冲突时，通报给出的答案很明确——以合规要求为准。
素材来源
- 北京雷腾律师事务所（2026-09-14，搜狐号）：75 款 App 被通报：小程序正在成为个人信息合规的「重灾区」——9 月 12 日通报 75 款、第一类问题 26 款的具体构成与小程序名单、执法链条（公示→整改→复检→下架→行政处罚→不良名单）、上海 9 月 11 日下架 6 款、分层整改清单，本文主体事实均以此为准
- 今日头条转载（2026-09-11）：赶紧自查！这 75 款 App 违法违规收集使用个人信息——通报依据文件、上一期 72 款经复测仍有 24 款存在问题
- 央视新闻 / 中新网（2026-08-14）：75 款移动应用违法违规收集使用个人信息被通报——8 月批次同为 75 款，说明专项行动为常态化分批通报
- 通报依据：《网络安全法》《个人信息保护法》《网络数据安全管理条例》（2025-01-01 施行）、《App 违法违规收集使用个人信息行为认定方法》（2019 年四部门发布）
评论