AI产品合规检查清单与法规应对指南

CH-15-09-010·约 16 分钟·AI安全伦理与合规·更新 2026-08-12

小张想开一家主打 AI 炒菜的网红餐厅“AI小厨”。开业前，经验丰富的老舅塞给他一张发黄的《餐饮安全自查表》：食材进货要有凭证、厨师要有健康证、菜单要标清过敏原、后厨每天要检查煤气电路、每道菜上桌前要有人把关……小张起初嫌麻烦，直到隔壁餐厅因卫生不合格被停业整顿，他才明白：这些“麻烦”不是束缚，而是让餐厅活得久的护身符。 AI 产品上线，和开餐厅一模一样。数据合规、算法备案、用户告知、风险评估、内容审核、各地监管——它们共同组成了一张“AI 产品合规检查清单”。每一个方框背后，都是一次真实的事故教训。本文带你把这张清单从头到尾打一遍勾，再讲清楚全球主要法规怎么应对，让你的产品从“能跑”升级为“敢上线”。

岗位关联

掌握这份清单，你就能像持证经营的老板一样把合规风险挡在门外。对 AI 产品负责人和法务团队而言，这是避免下架、罚款与信任崩塌的护城河。

可视化演示
数据合规检查：食材进货，凭证齐全
算法备案登记：先办证，再开业
用户告知义务：菜单写清楚，客人不踩雷
风险评估机制：开业前，先把后厨翻个底朝天
内容审核把关：上菜前，品控员最后过目
全球法规应对：海外开分店，入乡随俗
合规落地建议：把清单挂上墙，每天打勾
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

动态演示AI产品合规检查清单与法规应的核心机制，通过架构/数据/状态/性能四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

AI产品合规检查清单与法规应：数据合规数据合规与个人信息保护核查算法备案与深度合成服务申报义务核心机制可视化 AI产品合规检查清单与法规应整体架构与关键组件

数据合规检查：食材进货，凭证齐全

小张的 AI 餐厅开业前一天，去菜市场采购。老师傅教他：肉要有检疫章、菜要有检测报告、进口海鲜要有报关单，进货量按当天销量算，绝不多囤。因为食材不新鲜，轻则浪费，重则让食客进医院。对 AI 产品而言，数据就是食材，容不得半点马虎。

数据合规的底层逻辑和食材管理如出一辙：第一，数据来源必须合法，用户授权要真实有效；第二，坚持最小化收集，只取实现功能必需的字段，通讯录、位置、浏览记录不能顺手全捞；第三，跨境传输要走安全评估或签标准合同。这三项，是数据检查单上的头三道菜。

很多团队习惯先囤数据再想用途，这在合规视角是大忌。自查动作包括：梳理数据资产地图、确认授权链路、限定留存期限、检查脱敏策略是否覆盖开发与测试全链路。检查进度可以用一个公式量化：

当小张把每批食材的进货凭证贴整齐、保质期标注清楚，食客才敢放心动筷子。产品同理：数据来源、用途、期限都能讲清楚，用户和监管才愿意对你说一句“欢迎光临”。

\displaystyle \text{脱敏率} = \frac{N_{\text{masked}}}{N_{\text{sensitive}}} \times 100\%

$N_{\text{sensitive}}$ 是敏感字段总数，$N_{\text{masked}}$ 是已完成脱敏的字段数。漏掉一个字段，就像后厨藏了一块过期的肉。

敏感字段总数 $N_{\text{sensitive}}$盘点所有存储、处理个人信息的库表字段，包括姓名、手机号、身份证、位置等。
$\displaystyle N_{\text{sensitive}} = \sum \text{含个人信息的字段}$
已脱敏字段数 $N_{\text{masked}}$统计完成加密、打码、泛化处理的字段数，测试环境必须与生产环境保持一致。
$\displaystyle N_{\text{masked}} = \text{已脱敏字段的数量}$
乘 $100\%$ 换算成百分比把比值变成直观的比例，门槛目标是 $100\%$，任何一项漏脱敏都视为不合格。
$\displaystyle \frac{N_{\text{masked}}}{N_{\text{sensitive}}} \times 100\% = 100\%$

算法备案登记：先办证，再开业

餐厅开业前，小张跑了三趟市场监管局：营业执照、餐饮服务许可证、食品安全管理员证一样不能少。老舅说：“证没下来，招牌挂出去就是违法。”AI 产品也一样——提供具有舆论属性或社会动员能力的算法服务，必须先完成算法备案，才能上线对外服务。

备案不是走形式。材料要写清楚算法基本原理、服务形式、数据来源和主要用途，监管部门据此判断你是否“底数清楚、责任明确”。上线后如果算法版本、服务范围、数据用途发生变化，还要在规定时间内履行变更备案手续——就像餐厅改菜单加新菜，要去更新经营范围。

实操中，备案周期往往被低估。建议把备案当作产品上线关键路径上的里程碑来排期：

小张把“证照上墙”当作开业的铁律，你的产品首页也该为“算法备案编号”留一席之地。合规不是拖后腿，而是给用户最硬气的承诺函。

\displaystyle \Delta T = T_{\text{launch}} - T_{\text{submit}} > T_{\text{review}}

$T_{\text{launch}}$ 是计划上线日，$T_{\text{submit}}$ 是备案材料提交日，$T_{\text{review}}$ 是预估审核周期。如果提前量不足，就只能眼看着产品“万事俱备、只欠备案”地干等。

备案提交日 $T_{\text{submit}}$材料在监管平台成功受理的日期，以回执为准。
$\displaystyle T_{\text{submit}} = \text{材料受理日期}$
计划上线日 $T_{\text{launch}}$产品预计对外提供服务的日期，由研发排期确定。
$\displaystyle T_{\text{launch}} = \text{上线排期日期}$
预留审核周期 $T_{\text{review}}$行业通行经验值通常需要数周，差值不足就意味着延期风险。
$\displaystyle \Delta T = T_{\text{launch}} - T_{\text{submit}} > T_{\text{review}}$

用户告知义务：菜单写清楚，客人不踩雷

餐厅菜单不只是价格表：辣度分级、过敏原提示、食材产地，写得越清楚，回头客越多。小张发现，标注“含花生”之后，过敏的客人反而更信任这家店。AI 产品的“菜单”，就是《隐私政策》与《用户协议》。

告知义务的核心是“显著、易懂、可撤回”。弹窗不能躲猫猫，默认勾选不等于同意；专业术语堆砌不算告知，用户看不懂等于没说。法规还要求提供撤回同意的入口——就像客人随时可以说“这道菜不要放葱”，餐厅必须照办。

可以给自己的文案做一次“可读性体检”，用公式量化告知质量：

好的菜单让客人吃得安心，好的告知让用户用得放心。把每一项告知都当成对用户的承诺去写，信任就会产生复利。

\displaystyle \text{告知完整度} = \frac{M_{\text{disclosed}}}{M_{\text{required}}}

$M_{\text{required}}$ 是法规要求告知的事项总数（如信息种类、处理目的、保存期限、权利义务），$M_{\text{disclosed}}$ 是你实际写进协议的事项数。这个比值应当等于 $1$，缺一项，就多一分被投诉的风险。

应告知事项 $M_{\text{required}}$依据适用法规逐条列出，形成一份法定告知清单。
$\displaystyle M_{\text{required}} = \text{法定告知事项的并集}$
实际告知事项 $M_{\text{disclosed}}$对照隐私政策逐项打勾，统计真正写清楚并配有显著入口的数量。
$\displaystyle M_{\text{disclosed}} = \sum \text{已落实的告知项}$
比值必须等于 $1$告知完整度不允许打折，任何一项缺失都视为不合规。
$\displaystyle \frac{M_{\text{disclosed}}}{M_{\text{required}}} = 1$

风险评估机制：开业前，先把后厨翻个底朝天

老舅教小张：开业前别急着放鞭炮，先蹲在厨房看三件事——煤气管有没有老化、电线有没有裸露、地砖会不会积水滑倒。找出隐患、贴上整改标签，比事后救火省一百倍力气。AI 产品上线前的“厨房检查”，叫算法影响评估。

评估的核心是识别“可能的伤害路径”：对个人权益的影响（就业、信贷、医疗决策）、对特定人群的偏见歧视、自动决策的可解释性、被滥用的可能性。每一项都要落到具体业务场景，而不是写一堆放之四海皆准的模板套话。

风险评估最常用的量化模型是风险矩阵：

检查完厨房，小张在隐患处贴上红色警示贴，一周后复查。风险评估不是一次性的“开业仪式”，而是伴随产品迭代的持续体检，每个大版本更新都要重新走一遍。

\displaystyle R = L \times I

$L$（Likelihood）是风险发生的可能性，$I$（Impact）是影响严重程度，各取 1-5 分。乘积越大风险越高，高风险项必须限期整改，否则不得上线。

可能性 $L$结合历史数据与专家判断，给风险发生频率打分（1 罕见，5 频繁）。
$\displaystyle L \in \{1, 2, 3, 4, 5\}$
影响程度 $I$按后果严重度打分（1 轻微，5 灾难），参考波及人数与权益损害。
$\displaystyle I \in \{1, 2, 3, 4, 5\}$
乘积得到风险分值 $R$范围落在 1 到 25，按阈值划分为低、中、高风险带。
$\displaystyle R = L \times I \quad (1 \leq R \leq 25)$

内容审核把关：上菜前，品控员最后过目

后厨再干净，端出去的菜也要过品控这一关：色泽不对、有异物、分量不足，统统打回重做。小张专门请了一位经验丰富的品控阿姨，她说“机器筛一遍，人再过一眼，双保险”。AI 产品生成的内容，同样要过这道关。

内容审核包含三层：自动审核模型拦截违禁、违法、有害内容；疑似内容进入人工复核队列；用户投诉与误判申诉要有畅通的处理通道。完全依赖机器，会把“创意”误杀；完全依赖人工，则扛不住内容量级。两层咬合才是常态。

为了向老板汇报，品控阿姨用一个公式统计审核质量：

品控阿姨的严格让小张明白：一家店的招牌不是广告牌，而是每一道安全到桌的菜。AI 产品的品牌，也是靠每一条安全合规的内容累积出来的。

\displaystyle \text{合规放行率} = \frac{C_{\text{ok}}}{C_{\text{total}}} \times 100\%

$C_{\text{total}}$ 是被审核内容总量，$C_{\text{ok}}$ 是确认合规并放行的数量。同时还要盯两个反指标：漏放率（违规没拦住）与误杀率（合规被错删）。

审核总量 $C_{\text{total}}$一段时间内进入审核链路的内容条数，包含机器识别与人工复核两部分。
$\displaystyle C_{\text{total}} = \text{自动识别量} + \text{人工复核量}$
合规放行量 $C_{\text{ok}}$确认无违规后正常展示的内容条数，等于总量减去拦截量。
$\displaystyle C_{\text{ok}} = C_{\text{total}} - C_{\text{reject}}$
比值与反指标监控放行率保持高位，更重要的是漏放率趋近于零，并配合申诉机制兜底。
$\displaystyle \text{漏放率} = \frac{C_{\text{miss}}}{C_{\text{total}}} \rightarrow 0$

全球法规应对：海外开分店，入乡随俗

生意做大了，小张想出海开分店。老舅泼冷水：德国的食品安全法、美国的过敏原标识法、日本的卫生管理规范各有各的脾气。“你在中国用熟的那套，到纽约可能连门都开不了。”AI 全球化的第一课，就是认清各法域的“菜系差异”。

三大主流法域各有侧重：欧盟 GDPR 强调个人数据权利与“被遗忘权”，违规最高罚全球营收的 4%；中国《生成式人工智能服务管理暂行办法》《算法推荐管理规定》等要求算法备案、内容标识、安全评估；美国暂无统一联邦法，但加州 CCPA/CPRA 等州法陆续落地，联邦层面的 AI 监管也在推进。出海产品要按“最严格适用原则”设计底座。

用公式可以盘点出海合规的覆盖情况：

小张最终在德国分店贴上了双语过敏原标识。所谓全球化，不是把中国菜单翻译成德语，而是让每个市场的客人都能用当地规则读懂你的诚意。

\displaystyle \text{法域覆盖度} = \frac{R_{\text{covered}}}{R_{\text{total}}}

$R_{\text{total}}$ 是产品实际服务的所有法域集合，$R_{\text{covered}}$ 是已完成合规适配的法域数量。覆盖率要尽量接近 $1$，因为“我不知道该国法律”从来不是免责理由。

服务法域总数 $R_{\text{total}}$统计用户所在地、服务器所在地、业务开展地涉及的全部司法辖区。
$\displaystyle R_{\text{total}} = \{ \text{法域}_1, \text{法域}_2, \dots \}$
已完成适配的数量 $R_{\text{covered}}$逐法域核对数据、备案、告知、审核四类要求是否全部落地。
$\displaystyle R_{\text{covered}} = \sum_{\text{法域} \in R_{\text{total}}} \text{达标法域}$
动态逼近全覆盖新法生效、业务扩张都会改变分子与分母，需要持续补齐缺口。
$\displaystyle R_{\text{covered}} / R_{\text{total}} \rightarrow 1$

合规落地建议：把清单挂上墙，每天打勾

开业一个月，小张发现检查全靠记性不靠谱：煤气今天查了，明天忘；台账三天不写就断档。老舅送来一块白板，上面是《每日自查表》，谁负责、哪天查、结果如何，全部留痕。“制度不落地，合规就是墙上口号。”

落到 AI 产品团队，建议做三件事：第一，把本文清单固化成《产品合规检查表》，按模块拆成可执行的自查项；第二，责任到人，数据、算法、运营、法务各司其职，每个检查项都有明确的 owner；第三，定期审计，按季度或在大版本发布前跑一遍全量体检，发现问题进整改台账。

用成熟度模型给团队做体检，是最直观的管理手段：

白板上每天画满的对勾，是小张最踏实的时刻。合规从来不是一次性的通关，而是每天重复的认真。你的团队每周花十分钟过一遍清单，产品就能少踩很多坑、多活很多年。

\displaystyle \text{合规成熟度} = \frac{P_{\text{pass}}}{P_{\text{total}}} \times 100\%

$P_{\text{total}}$ 是合规清单总项数，$P_{\text{pass}}$ 是已达标项数。建议以 90% 作为上线红线：低于红线，版本冻结；高于红线，也别忘了“重大变更即复检”。

清单总项 $P_{\text{total}}$把法规要求翻译成产品团队听得懂的检查动作，形成可勾选清单。
$\displaystyle P_{\text{total}} = \text{全部自查项数量}$
达标项 $P_{\text{pass}}$由 owner 逐项确认通过，并附上截图、日志等证据留痕。
$\displaystyle P_{\text{pass}} = \sum \text{通过的自查项}$
红线阈值 90%按风险容忍度设定，低于红线立即冻结版本，先整改后上线。
$\displaystyle \frac{P_{\text{pass}}}{P_{\text{total}}} \times 100\% \geq 90\%$

AI 应用场景

智能客服机器人的上线合规体检

阶段：产品上线前的合规审查阶段

解决的问题：传统做法是“功能先上、合规后补”，上线后遭投诉、被约谈甚至下架。AI 方法是用合规检查清单工具逐项打勾、自动生成报告，并在 CI 流程中结合代码扫描，自动发现未授权采集的数据字段。

具体案例：某电商公司上线智能客服前，用合规审计脚本跑完 30 项清单，发现“对话录音默认留存 3 年”违反最小化原则，改为 90 天后自动删除，并在隐私政策中明示，顺利通过备案审核。

出海社交产品的 GDPR 合规改造

阶段：数据出境与用户权利保障阶段

解决的问题：用户遍布欧洲，传统做法是“一套隐私政策走天下”，一旦违规面临最高全球营收 4% 的罚款。AI 方案是按法域建立差异化数据处理规则，用自动化工具识别欧洲用户数据，落实删除权、可携带权与撤回同意入口。

具体案例：某出海 AI 绘图 App 面向欧盟用户增加“数据导出与删除”入口，并将训练数据中的欧洲用户人脸数据全部剔除，重新提交数据保护影响评估（DPIA），获得当地数据保护官的认可。

大模型生成内容的全链路审核

阶段：内容安全运营阶段

解决的问题：生成式 AI 输出不可控，传统关键词过滤无法识别语义变体。AI 方案是三层咬合：第一层分类模型识别违禁意图，第二层人工复核兜底，第三层用户申诉反馈闭环，同时对 AI 生成内容添加显式标识。

具体案例：某国产大模型助手上线后，通过“机器初审 + 人工抽检”机制把违规输出拦截率提升到 99.2%，同时提供申诉入口，显著降低了误伤正常提问的比例。

Python 演示

python55 行

# -*- coding: utf-8 -*-"""AI产品合规检查清单工具""" class ComplianceAuditor:    """模拟AI产品上线的合规审查流程"""     def __init__(self, product_name):        self.product_name = product_name        self.results = []          # 每项检查结果 (名称, 是否通过)        self.pass_count = 0        # 已通过数量     def check(self, item_name, passed):        """记录一项检查结果"""        self.results.append((item_name, passed))        if passed:            self.pass_count += 1        return passed     def report(self):        """输出合规报告与上线结论"""        total = len(self.results)        rate = self.pass_count / total if total else 0.0        print("产品: " + self.product_name)        print("检查项: %d, 通过: %d" % (total, self.pass_count))        print("合规成熟度: %.1f%%" % (rate * 100))        if rate >= 0.9:            print("结论: 达到上线红线, 可以发布")        elif rate >= 0.6:            print("结论: 存在风险, 需限期整改后复检")        else:            print("结论: 不合规, 禁止上线")        for name, ok in self.results:            print(("[PASS] " if ok else "[FAIL] ") + name)        return rate  def main():    auditor = ComplianceAuditor("智能客服机器人")    # 数据合规检查    auditor.check("用户数据已获得授权", True)    auditor.check("敏感字段已脱敏", True)    auditor.check("数据留存期限合法", False)    # 算法与告知    auditor.check("算法已完成备案", True)    auditor.check("隐私政策显著告知", True)    auditor.check("提供撤回同意入口", False)    # 风险与内容    auditor.check("完成算法影响评估", True)    auditor.check("内容审核机制上线", True)    auditor.check("建立用户申诉通道", False)    auditor.report()  if __name__ == "__main__":    main()

目的：把正文的“合规检查清单”落成可执行的 Python 工具，逐项打勾并输出合规成熟度与上线结论。

class ComplianceAuditor:把合规检查封装成一个“主厨”，所有检查任务都交给它记录与裁决。
self.results.append((item_name, passed))每一条检查结果按“名称 + 是否通过”存进清单，方便最终输出报告。
rate = self.pass_count / total if total else 0.0计算合规成熟度，对应正文公式：达标项数除以清单总项数。
if rate >= 0.9:90% 是上线红线，低于它就冻结版本，先整改后发布。
auditor.check("算法已完成备案", True)模拟人工打勾；实际项目中可替换为读取自动化扫描与检测的结果。

常见误区

误区“用户点了一下'我已阅读并同意'，我就尽到告知义务了，后面用户反悔也没用。”

正解同意必须建立在“知情”基础上：告知内容要显著、易懂、真实，默认勾选或一揽子打包勾选通常无效。用户还应能随时撤回同意，且撤回前的处理仍须合法。就像餐厅菜单写了“含花生”，但字小到看不见，客人吃出过敏后，餐厅依然要担责。

为何常见：把“点击动作”等同于“有效同意”，忽略了告知的可理解性与用户选择的自由性。

误区“备案材料提交成功，就等于拿了免死金牌，产品可以随便改、随时上。”

正解提交不等于通过，材料可能被驳回补正；上线后算法原理、服务范围、数据用途等发生重大变化，须在规定时间内履行变更备案。就像餐厅拿到执照后私改经营项目，不更新经营范围照样会被处罚。

为何常见：把备案想象成“一次性行政许可”，忽略了监管是动态、持续的。

误区“手机号打码、姓名替换成编号，这不就是匿名数据了吗？拿去训练模型、卖给第三方都没问题。”

正解脱敏只是降低识别风险，不等于匿名化。现代重识别技术能在多源数据碰撞下还原身份；法规上的“匿名化”标准高得多，一旦能结合其他数据间接识别个体，仍属于个人信息。就像给马赛克了车牌的车拍照，结合行车记录仪数据照样能锁定车主。

为何常见：混淆了“脱敏”与“匿名化”的技术强度和法律效果，把手段当成了终点。

误区“我又不是大厂，做个内部 demo 工具，又不对外卖，肯定不受监管。”

正解个保法与算法备案等以“处理个人信息行为”和“向公众提供服务”为触发点，不按公司规模划线；只要处理真实用户数据，就要履行告知、最小化、安全等义务。内部工具泄露员工或测试用户数据，同样面临处罚。自家小饭馆也要办健康证，规模小不等于没规矩。

为何常见：存在侥幸心理与“未被处罚 = 合法”的幸存者偏差。

面试题

Q1. 关于算法备案，下列说法正确的是？

单选题 · easy

A.完成备案后产品永久免检
B.备案信息变更需及时更新← 正确答案
C.仅大型企业需要备案
D.算法备案完全是自愿的

答案：B。算法备案是法定义务而非自愿，也不分企业大小；备案不是“一次通关”，变更算法版本、服务范围或数据用途都需及时更新备案，就像餐厅改经营范围要去更新证照。A、C、D 都与动态监管逻辑相悖。

Q2. AI 产品向用户告知的内容应包含哪些？

多选题 · mid

A.算法的基本运行原理← 正确答案
B.决策结果对权益的影响← 正确答案
C.解释方式与申诉渠道← 正确答案
D.公司内部员工的薪酬

答案：ABC。告知义务要求把算法原理、对用户权益的影响、解释与申诉方式讲清楚，好比菜单标注辣度与过敏原。员工薪酬与用户权益无关，不属于告知范围，所以 D 不选。

Q3. 风险公式 R = L × I 中，字母 L 表示什么？

单选题 · easy

A.风险发生的影响程度
B.风险发生的可能性← 正确答案
C.违规罚款的具体金额
D.合规整改所需的人天

答案：B。L 是 Likelihood（可能性），I 是 Impact（影响程度），两者各取 1-5 分相乘得到风险分值。影响程度对应 I 而不是 L，罚款金额与整改人天都不是该公式的变量。

Q4. 欧盟 GDPR 对违规企业的最高罚款标准是？

单选题 · mid

A.全球营收的百分之二
B.全球营收的百分之四← 正确答案
C.固定金额一百万欧元
D.按单次事件定额罚款

答案：B。GDPR 规定最高可处全球年营收 4% 或 2000 万欧元（取较高者），目的是让巨头也无法把罚款当成本。2% 对应较轻档位，固定金额与单次定额的说法都不准确。

Q5. 内容审核机制的正确做法包括哪些？

多选题 · mid

A.自动识别违禁违法内容← 正确答案
B.保留人工复核的托底← 正确答案
C.提供误判申诉的处理通道← 正确答案
D.审核结果永不向用户解释

答案：ABC。内容审核是“机器初筛 + 人工复核 + 申诉通道”三层咬合，类似品控阿姨“机器筛一遍，人再过一眼”。完全不解释审核结果会激化误判矛盾，D 不可取。

Q6. 数据最小化收集原则的核心含义是？

单选题 · easy

A.只收集实现功能必需的数据← 正确答案
B.尽量收集更多数据做储备
C.完全禁止收集用户数据
D.用户数据越全产品越好

答案：A。最小化收集强调“够用就好”，只拿实现功能所必需的字段，像餐厅按当天销量进货、不囤积。完全禁止收集不现实，多多益善恰恰是合规反例。

Q7. 下列哪一项属于用户告知义务的要求？

单选题 · mid

A.用深奥术语描述细节
B.显著方式告知并获得同意← 正确答案
C.上线之后补充通知即可
D.仅在官网角落备查

答案：B。告知义务要求“显著、易懂、事前”，弹窗要醒目、语言要平实、获取同意要在处理之前，像菜单把过敏原标在显眼位置。事后补通知、角落备查、堆术语都不能算有效告知。

Q8. 算法影响评估应当关注哪些维度？

多选题 · hard

A.对个人权益的潜在影响← 正确答案
B.是否存在偏见与歧视← 正确答案
C.自动决策的可解释性← 正确答案
D.竞争对手的经营数据

答案：ABC。影响评估聚焦“伤害路径”：对就业、信贷等个人权益的影响，对特定人群的偏见歧视，以及自动决策能否被解释，如同开业前检查煤气、电线、地砖。竞争对手数据与评估无关。

Q9. 中国生成式人工智能管理办法要求的是？

单选题 · mid

A.对生成内容进行标识← 正确答案
B.禁止企业使用任何训练数据
C.生成内容无需安全评估
D.所有算法必须完全开源

答案：A。我国《生成式人工智能服务管理暂行办法》要求对 AI 生成内容进行标识，并履行安全评估等义务，同时鼓励使用合法来源数据，并不禁止训练数据，也不强制开源。B、C、D 均不符合规定。

Q10. 关于合规审计，推荐的做法是？

单选题 · hard

A.产品上线前审计一次即可
B.定期审计加重大变更复检← 正确答案
C.每年底象征性走个过场
D.被投诉时才启动内部审计

答案：B。合规是持续状态而非一次通关：按季度定期审计，大版本或重大变更时额外复检，像餐厅每天打钩、每周大扫除。只审一次、年底走过场、出事了才查，都会让风险在暗处发酵。