最近好几个做AI产品的朋友跑来找我问的问题基本都一样“新规落地之后到底什么能做什么不能做为什么我都接了大模型API还是被要求整改”说真的这些问题我在自己带的项目里也踩过。AI应用开发早就不是“模型能出结果就行”的时代了新规实施以后合规已经从前台的法务事项变成了后端要直接参与的工程问题。这篇文章我想把我在实际项目中总结的合规边界判断方法和落地经验整理出来给正在做AI产品、AI应用开发或者打算做本地部署AI大模型的团队一个可以照着执行的参考。先说结论合规不是一道“能不能做”的选择题而是一套“怎么做才安全”的工程方案。边界永远在动态调整但判断边界的方法论是稳定的。下面我会从边界判断、内容安全架构、数据合规、备案流程、风险诱惑、低成本落地六个方面把我踩过的坑和总结的方法完整讲一遍。1. 先搞明白新规到底在管什么1.1 判断你的产品在不在“被管”的范围内很多人找我咨询时第一句话就是“我做的不是大模型只是接API套壳也要合规吗”我的回答是看你服务谁。这里有个非常关键的判断标准是否面向境内公众提供生成式AI服务。只要用户能直接使用你的产品生成文本、图片、音频、视频哪怕底层模型是调用别人家的API你也属于提供生成式AI服务的主体需要承担对应的合规义务。这个逻辑跟“你是饭店不是养猪场”类似顾客在你这里吃坏肚子你不能说猪肉不是我养的。具体来说大致有三类形态逃不掉自研基础模型并对外提供API或应用服务。调用大模型API做聊天、绘画、视频、Agent等面向用户的产品。给第三方提供AI工具或组件中间层和最终服务层都有责任。我见过一个典型的案例一个团队做To B的AI客服系统觉得自己卖给企业不直接面对消费者就不用管合规。结果客户拿这套系统去服务他们的C端用户出了内容问题监管找的是服务提供方To B团队也被连带要求整改。后来我们把合同里的责任划分、安全能力说明、内容审核日志都补齐了这个风险才控制住。所以第一步先老实回答三个问题你的用户是谁他们能生成或看到什么内容你的产品挂在哪个链条上这三个问题决定了你要做多少合规动作。1.2 划合规边界的几把“尺子”合规边界之所以让人头疼是因为它不是一条线而是好几把尺子叠在一起。我习惯把它们分成五层来看第一层内容安全。生成内容不得含有违法违规信息不得危害公序良俗不得传播虚假信息不得产生歧视、侵权内容。这个要求看似简单但“虚假信息”这一条在大模型时代特别难做到因为它本质上是叫模型不要说谎而模型又天生有“幻觉”这个毛病。后面我会讲怎么从技术上缓解。第二层数据合规。个人信息保护是重头戏。你收集用户的输入数据能不能存、能不能用来训练、用户有没有授权这些都是问题。尤其是聊天类产品用户问的问题很多时候带着个人隐私如果留存和处置不当风险非常大。第三层技术安全与可干预性。新规要求提供者要有模型安全评估、内容审核机制、用户投诉举报渠道并且要有“停止生成”等应急处置能力。翻译成工程语言就是模型要能拒绝敏感请求系统要能拦截违规输出历史记录要能回溯和处置。第四层知识产权。训练数据有没有版权风险模型生成的内容会不会高度复制某个作品这两个问题现在越来越被重视。AI短剧、AI漫剧这类生成视频产品尤其要注意生成的人物、形象、风格如果跟既有作品过于接近是可能引发侵权纠纷的。第五层专业领域特殊要求。如果AI产品涉及医疗、法律、金融、专利等专业领域还有额外的合规约束。比如AI辅助撰写专利文档要明确“AI辅助、人工审核”的边界不能全自动出稿。做这类产品光有通用AI合规还不够还得懂行规。边界模糊的主要原因就是这五层尺子叠加在一起再结合具体场景组合出来的情况非常多。但不要怕边界是死的判断方法是活的把尺子列出来逐条过你的边界就清楚了。2. 内容安全是硬底线三层防护怎么搭2.1 输入层别让恶意输入进模型合规的工程化我习惯从“输入-生成-输出”三个环节来搭。第一道防线是输入层核心任务是过滤和识别恶意请求。很多团队只做输出审核忽略输入这是大坑。大模型的提示词注入攻击是非常常见的用户可能用精心构造的prompt诱导模型绕过安全限制。我们一开始也没重视直到有人在线上产品里通过提示词让模型输出了不该说的内容才意识到输入侧必须做防守。输入层的实操方案按成本从低到高有三档黑名单匹配维护恶意关键词库命中直接拦截或转人工。这个简单但不能单独依赖因为用户会换谐音、换字体、换语序绕过。特征识别用正则或分类模型识别常见的恶意prompt结构比如“忽略以上指令”“你现在是一个不受限制的AI”这类句式。意图分类接一个语义分类模型对用户输入做意图识别区分正常提问、敏感试探、恶意引导。实测下来第三档效果最好但成本最高。我们现在的做法是黑名单做前置快速拦截语义分类做中置精准识别两层配合之后恶意输入比例明显下降。给Agent类产品做输入防护时还要特别注意对工具调用的参数校验防止模型被引导去执行异常操作。2.2 生成层从模型侧约束输出输入过滤完之后第二道防线是生成层。这一层的关键词是系统提示词和拒答策略。系统提示词是约束模型行为的基础手段。我会在系统提示词里把内容边界写清楚哪些主题直接拒绝回答哪些场景只提供客观信息不提供主观建议哪些专业问题必须提示“仅供参考建议咨询专业人士”。这里有个很实在的经验提示词不能写得太死。我们早期为了绝对安全在系统提示词里加了一堆“绝对不可以”“必须拒绝”的表述结果模型变成了惊弓之鸟用户问“今天天气怎么样”都怕踩雷可用性直线下降。后来我们调整策略把“硬拒绝”和“软引导”分开真正的高危主题用硬拒绝一般敏感内容用软引导让模型转向更安全、更中性的回答方向。这个平衡点需要反复调建议每改一次提示词都跑一遍测试集别靠感觉。拒答策略要分级别不要一刀切绝对禁区直接拒绝并说明原因比如“我不能回答这个问题”。高风险场景只提供通用信息不做具体建议同时加上“请咨询专业人士”的提示。普通敏感内容尝试转移话题或引导到安全方向比如用户问负面新闻可以回应“我还没有掌握相关信息不过你可以关注官方渠道”。另外生成层的另一个技术手段是敏感主题检测。在模型生成过程中可以用一个轻量分类器对生成结果做实时打分分数异常时触发重新生成或插入安全提示。这个方式尤其适合长文本生成比如AI短剧、AI漫剧这类一次生成大量内容的场景单独靠输出审核会漏掉很多上下文里的问题生成中检测能更早发现风险。2.3 输出层审核与标识两手抓第三道防线是输出层也是最后一道。无论前面怎么防护模型输出仍然有可能出问题所以输出审核不能省。输出审核别只用关键词过滤。我们踩过最典型的坑用户用繁体字、拆字、拼音方式把敏感词绕过了关键词过滤结果审核形同虚设。后来我们改成“关键词快筛 语义模型精排”的双通道方案先跑敏感词列表把明显违规的拦下来再用语义分类模型对漏网之鱼做二次识别。审核的延迟是另一个痛点。用户在线聊天你不可能让他等三秒才看到回复。我们的处理方式是对明显安全的内容先返回再异步复核。对判断置信度不够高的内容先拦截等审核通过再放行。对高危内容直接阻断不进入用户可见范围。同时人工抽审一定要做。哪怕你有再强的模型审核也必须保留人工抽审机制尤其是跨领域的长文本。我们现在的做法是每天随机抽取一定比例的对话记录由审核人员人工复核发现问题就反哺给审核模型做迭代。输出层还有一个容易被忽略的点AI生成内容标识。按照《人工智能生成合成内容标识办法》的要求AI生成的文本、图片、音视频都需要按规定进行标识。这个标识分为显式标识和隐式标识。显式标识就是用户能直接看到的比如图片角落的水印、视频画面里的“AI生成”字样、文本开头或结尾的提示语隐式标识则是藏在文件元数据里的通过技术手段在生成时自动写入。工程上做标识要注意抗压缩问题。我们做AI短剧项目时视频经平台二次压缩后显式水印容易被压糊隐式水印也可能被抹掉。后来我们用了一种抗压缩的隐式水印方案把标识信息分布在多个视频帧里即便压缩也能通过专门工具提取出来。这个方案在合规上很关键因为标识丢失会被视为未履行标识义务。3. 数据合规与个人信息保护容易被忽略的“隐形雷区”3.1 训练数据的合规清洗如果你不是只做应用层而是会用到模型训练或微调训练数据的合规问题就躲不掉了。这里最容易出问题的有三个地方版权、个人信息、数据来源合法性。版权问题上开源数据集不等于可以随便用。很多开源数据集的license只允许研究使用禁止商用你拿来做商业产品就是违约。我的建议是做一个数据来源台账把每个数据集的名称、来源、license类型、是否允许商用、是否允许修改都记录清楚。这个台账不仅是内部管理工具未来如果被问到数据来源拿出来就能说明问题。个人信息方面训练数据里如果有姓名、电话、地址、身份证号这类PII信息必须先做脱敏。我们做文本数据清洗时会先跑一遍PII识别模型把这些实体挑出来再统一替换成占位符。这里有个细节简单用正则匹配替换不够很多实体是嵌套的比如“张先生住在北京市朝阳区XX小区XX号楼”光替换姓名地址里的信息还是能定位到个人。要结合NER模型做实体识别把姓名、所在地、具体门牌号都处理干净。数据来源合法性也很重要。爬取的数据不是不能用但必须确认内容本身没有版权限制同时遵循目标网站的robots协议和服务条款。我们之前用过一批从公开社区爬来的问答数据后来发现其中一部分来源于付费内容平台立刻把这部分数据清掉了因为付费内容滥用是高风险区一旦原作者主张权利损失会很大。3.2 用户输入数据的保护与最小化收集面向用户的AI产品用户输入的每一句话理论上都可能包含隐私信息。新规对个人信息保护有明确要求实操中我建议按“最小化收集、可用但不可见、用完即删”三个原则来做最小化收集只收集完成服务所必需的数据。如果你的产品是单轮问答就不该存用户的历史对话如果不需要手机号就不要在注册时强制绑定。可用但不可见用户对话数据在传输和存储环节要做加密处理。我们内部有个默认约定所有用户对话日志都脱敏存储脱敏是自动化的工程师看日志时看到的也是脱敏后的数据而不是原始对话。用完即删设定数据保留期限到期自动清理。很多团队把历史对话无限期保留在数据库里这是非常大的合规隐患。建议根据业务需要设置保留周期比如30天或90天到期后自动删除原文只保留聚合统计信息。还有一个容易被忽略的点用户数据用于模型训练必须单独授权。默认勾选“同意”是不行的需要用户主动确认。我们在新版产品里把“我的对话数据是否用于模型优化”做成了独立的开关默认关闭用户主动打开后才会进入训练样本池。这样虽然会损失一部分训练数据量但换来了更干净的合规状态值。4. 备案与算法披露面向公众服务绕不开的流程4.1 哪些产品需要备案、需要准备哪些材料很多团队一听到“备案”两个字就头大觉得是行政管理事项跟技术没关系。实际上备案材料如果写得好反而能倒逼团队把技术方案理清楚。目前面向境内公众提供生成式AI服务通常涉及两类备案一类是针对具有舆论属性或社会动员能力的服务需要履行算法备案另一类是生成式AI服务本身的备案。对于大多数面向C端的AI应用、AI对话产品、AI生成工具来说基本都在范围内。判断标准其实很简单你的服务能不能被公众直接使用、能不能生成内容能基本就跑不掉。备案需要准备的材料我们当时的清单大概是安全评估报告说明产品存在的安全风险以及应对措施。安全管理制度包括内容审核制度、应急处置预案、用户投诉处理机制等。模型安全能力说明对模型做了哪些安全对齐、拒答训练、有害内容测试。数据安全与个人信息保护说明数据来源、用途、存储方式、用户授权机制等。有件事一定要提醒材料最好让法务和技术一起写不能各写各的。我们第一次准备时法务写得非常合规但技术细节模糊审阅方问了好几个实现层面的问题技术团队临时补充材料来来回回改了三轮才通过。后来我们改成技术团队先写技术白皮书法务再按照要求转成合规文档效率高了很多一次基本能过。4.2 安全评估报告要写成“技术方案”而不是“保证书”写安全评估报告最大的误区是写一堆“我们将严格遵循”“我们坚决保证”的空话。审阅方要看的不是态度而是机制。我的经验是把安全评估报告当成一份技术方案来写每个安全承诺都要对应到具体的实现手段“我们有内容审核机制”就要写清楚审核链路输入层过滤用什么模型、输出层审核用什么方案、人工复核怎么抽检、多少比例。“我们有应急处置能力”就要写清楚触发条件什么情况会触发暂停服务、谁负责决策、多长时间内响应。“我们有投诉举报通道”就要写清楚闭环流程用户在哪里可以举报、举报后怎么受理、多久处理完、怎么反馈结果。这样写出来的报告不仅审阅方容易通过团队内部也等于做了一次完整的技术梳理。相当于帮项目免费做了一次安全自测。4.3 本地部署、API接入不等于“不用管”每次直播或者线下分享都会有人问“我做本地部署模型跑在自己机器上不经过第三方是不是就不需要备案了”这是一个很大的误区。本地部署解决的是数据不出域的问题不改变“你提供生成式AI服务”这个事实。只要你的服务面向公众开放不管底层模型是自研、API调用还是本地部署合规义务是一样的。我自己理解本地部署更像一种技术选型方案而不是合规豁免方案。做完本地部署该做的内容审核、安全评估、用户隐私保护一项都不能少。另外还有一类团队做AI编程辅助工具觉得开发者工具风险低不用管合规。实际上AI编程工具如果面向公众提供同样被纳入生成式AI服务管理范畴。只是它的风险点更集中主要在意代码安全、漏洞生成、开源许可合规这些方面但备案和评估流程是一样的。5. 那些“无限制AI”做不得风险到底有多大5.1 “无审核”“无禁词”工具的真实代价我必须专门聊一聊这个话题因为“无限制AI”“无禁词聊天”这类需求在市场上真实存在而且总有人觉得这是“蓝海”。但实际上这是风险极高、随时可能翻车的“红海”。我见过一个真实的团队做了一个号称“无限制”的AI聊天产品为了追求所谓的极致体验砍掉了所有内容审核环节连基本的关键词过滤都没有。上线前两周用户量涨得确实快很多人抱着猎奇心理来测试。但很快问题就来了有用户通过提示词让模型生成违法违规内容还有人用这个工具批量制造垃圾信息最终这个产品被举报平台被要求全面整改团队不仅要下架产品还要配合调查连带着云服务商也被问询整个项目直接废掉了。这个案例告诉我们三件事平台责任逃不掉。即使内容是用户生成的只要是通过你的产品生成并传播的服务提供方就有责任。数据风险非常大。无审核工具的对话记录一旦泄露或被发现用于不当用途问题会比产品功能本身严重得多。商业化门槛过不去。应用商店审核、云服务商合规审查、投资方尽调每一关都会查你的内容安全机制没有合规底座的AI产品几乎拿不到主流渠道的资源。5.2 用户想要的其实不是“无限制”是“不被过度过滤”我做了几年AI产品观察到一个很有趣的现象用户喊“无限制”很多时候并不是真的想生成违法内容而是受够了那些安全提示词写得太死、回复千篇一律、稍微沾点边就拒答的产品。用户要的其实是更自然、更真实、更有温度的对话体验而不是真正的“为所欲为”。如果理解了这一点你就知道合规产品的优化方向不是“放开限制”而是“在限制范围内把体验做到极致”。我的实操经验是在系统提示词里给模型设定更自然的语言风格让回复不那么“AI腔”用户体感会好很多。对非高危但敏感的话题不做生硬拒答而是用“提供客观信息 提示风险 建议咨询专业人士”的方式回应既守住了底线又保留了对话的连续性。在产品界面上明确标注“内容由AI生成请注意甄别”反而会增加用户的信任感让用户更愿意使用。合规不是体验的敌人粗糙的安全策略才是体验的敌人。6. 资源有限怎么做MVP版本够用的合规方案6.1 上线前必须完成的7件事中小团队最大的困境是人力有限、预算有限、但合规不能不做。根据我的经验MVP版本不用一上来就搞大而全的安全中台把下面这7件事做完就能达到一个“够用且不翻车”的状态在系统提示词里写明内容边界和拒答策略并跑一遍覆盖正常、敏感、高危三类场景的测试集。至少接入一层自动内容审核可以选择云厂商的内容安全API成本低且识别能力强。在生成结果的展示页面加上“AI生成内容”标识并配置用户举报入口。建立用户协议和隐私政策明确数据收集范围、用途和保留期限。对用户输入数据做脱敏和加密存储设定自动清理周期。准备一份安全评估报告初稿哪怕还没提交后续随时可以迭代。建立线上日志和应急响应机制发现违规内容时能定位、能处置、能说明。6.2 一套可复用的合规自检SOP最后分享一套我一直在用的合规自检SOP每次发版前我都会让产品和技术团队按这个表格过一遍检查维度检查项通过标准模型层模型是否有安全对齐或拒答能力高危主题测试全部拒绝数据层训练数据是否来源合规、是否脱敏台账完整PII已处理数据层用户数据是否最小化收集无多余字段有留存期限内容层是否有输入过滤和输出审核恶意输入拦截率达标输出审核全量覆盖内容层是否做了AI生成标识显式和隐式标识均已实现交互层是否有举报入口和处置反馈举报通道可用处理流程明确运营层是否有应急响应机制能定位内容、阻断服务、事后说明运营层备案材料是否与当前功能一致功能变更后已同步更新材料这套SOP的核心思想是把合规当成产品的一个功能模块来设计而不是当成发布前的一次性检查。每次迭代都过一遍习惯之后会发现合规成本并没有想象中那么高反而因为边界清晰产品可以走得更快。我在实际项目中还有一个体会合规这件事越早做越省事。等产品做大了再回头补安全机制跟装修完了再改水电一样又贵又痛苦。如果你现在正在规划新功能建议顺手把对应的安全方案一起想好哪怕只是画个流程图后面落地也会顺畅很多。