你的 AI 功能属于哪一档：六个功能、三档风险与十一项动作

合规不是一份放在帮助中心的文档，而是产品里那些默认打开、默认关闭和默认要求确认的开关。

一、一个默认打开的开关，赔了十一封道歉信

2026 年 3 月，周闻给「回音」加上了「自动发送」：模型生成回复后，如果置信度超过阈值，就直接发给终端消费者。功能上线第 9 天，一位商家在凌晨收到 11 条错误回复，其中一条承诺「全额退款并保留商品」，超出了店铺政策。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

他当天把开关默认关掉，逐个联系受影响的消费者。事情不大，但它暴露了一个顺序问题：他先做了功能，再想责任；而责任应该反过来决定功能怎么开。

事后他复盘了两件事：一是自动发送的阈值只看了置信度，没看内容类型；二是开关上线时没有任何人确认过「最坏会发出什么」。这两件事都不需要新技术，只需要在功能表里多加一列。

AI 合规的第一步不是写政策，是给功能分档。 分档决定默认值、确认点和证据要求；档位没定，后面所有文档都只是形容词。

二、三问分档：用途、对象、是否替人做决定

他给六个功能问了三个问题。

按这三问，六个功能的分布是：摘要、知识问答、情绪标注属于最小风险；回复草稿、退款建议属于有限风险；自动发送属于高风险。

有限风险的两个功能也有差别：草稿面向消费者，但发送前有人看；退款建议不自动执行，但一旦被采纳，影响的是钱。前者靠角标，后者靠「建议」两个字和二次确认。

档位不是给监管看的，是给默认值用的。 最小风险可以默认开，有限风险要默认「人发送」，高风险要默认关；三个默认值写进代码，比写在制度里有效。

分档时最容易犯的错，是把「技术上能做」当成「风险上可接受」。自动发送在技术上只差一个按钮，在责任上却把「人决定」换成了「模型决定」，这是另一个档位。

三、十一项动作：从清单到证据

分完档，他列了十一项动作。它们不是十一个部门，而是一个人在两周内能跑完的十一件事。

十一项动作 × 2.5 小时 ≈ 27.5 小时。这个数字只是判断成本，不含实现；它的作用是让人知道「先想清楚」本身就需要三天，而不是一个下午。

这个数字还有一个用法：当有人问「合规要花多久」时，先给 27.5 小时的判断成本，再给 186 小时的建设成本；两个数字分开，才不会把「想一想」和「做出来」混为一谈。

先做第 1、2 项，再做别的。 功能清单和分档没写出来，数据来源、披露和复核都会变成拍脑袋；写完这两项，后面的动作才有对象。

他把这张表放进发布检查单：新增一个 AI 功能，先填功能、对象、是否替人决定三行，再决定档位。填不完，就不进开发排期。

检查单的作用不是增加流程，而是把「这件事该谁想」变成一个可见的空格；空格空着，发布就过不去。

四、把档位写进开关，而不是写进文档

分档之后，三个默认值落到产品里。

第一个是默认关闭。自动发送只有商家主动开启才生效，开启时弹一次说明，写明「AI 生成的回复可能出错，你需要为最终内容负责」。380 家里只有 41 家开启，占 10.8%。

第二个是默认人工发送。回复草稿生成后不自动发出，商家点「发送」才走；草稿上方有一条「AI 起草，请确认」的角标，每月出现 23,000 次。

第三个是默认记录。最小风险的功能不打扰用户，但每次调用留一条日志：功能、模型版本、耗时、是否被采纳。日志保留 30 天，用于事后回答「当时为什么这么答」。

日志不记录完整对话正文，只记录功能、版本、耗时、是否采纳与一个哈希；这样既能复盘，又不会把用户内容再复制一份。

默认值是合规最便宜的实现方式。 它不需要用户读文档，也不需要客服解释；用户看到的就是产品行为，而行为本身就是披露。

他还留了一个例外通道：商家可以申请开启自动发送，但要签署一页确认，说明使用场景与复核人。这个通道一年只开了 3 家，全部是内部客服团队，终端消费者看不到自动回复。

例外通道要留记录：谁申请的、什么场景、复核人是谁、多久复查一次。没有记录的例外，过三个月就会变成默认值。

三个默认值加上例外通道，构成了一张开关表。开关表要跟着功能表一起版本化：功能增加、档位变化、默认值调整，都留一条变更记录。

复算：
功能：6 = 最小 3 + 有限 2 + 高 1
占比：3 ÷ 6 = 50.0%；2 ÷ 6 = 33.3%；1 ÷ 6 = 16.7%
判定成本：11 项 × 2.5 h = 27.5 h
默认关闭：自动发送开启 41 ÷ 380 = 10.8%
每日志覆盖：46,000 次请求，日志 46,000 条/月

复算里最值得记住的是 27.5 小时：它比一次误发事故的道歉成本低得多，但大多数人是反过来安排的。

五、行动清单与复算验收

• 列出所有 AI 功能，写清每个功能的用途。
• 对每个功能问「用途、对象、是否替人决定」三问。
• 把功能分成最小、有限、高三档并记录依据。
• 给高风险功能设默认关闭，开启需要主动确认。
• 给有限风险功能设「AI 起草、人发送」的默认路径。
• 给最小风险功能保留调用日志，至少记录功能与版本。
• 把十一项动作写进发布检查单，缺项不进排期。
• 每季度重跑一次分档，功能变化会改变档位。

验收标准：任取一个 AI 功能，都能说出它的档位、默认值和一条对应的控制。

前四条是「把功能看清」，后四条是「把默认值落地」。如果只有一小时，先做第三条：没有分档，后面的披露与复核都没有判断依据。

使用边界与实操验收

三档不是法律分类。 它是产品内部的风险分级，用来决定默认值和控制强度；是否落入某个辖区的监管范围，要以当地官方原文和专业意见为准，本文不构成法律意见。

分档会随功能变化。 同一个模型，从「生成草稿」改成「自动发送」，档位就变了；每次改交互都要重跑三问，不能沿用旧结论。

高风险不等于不能做。 默认关闭、逐条确认、保留复核记录，仍然可以做；不能做的是「默认开、无人看、出了事再说」。

最小风险也需要日志。 不打扰用户不等于不留证据；没有日志，事后无法回答「这条内容是谁生成的、用的哪个版本」。

分档结果要能被非技术的人读懂。 如果一页纸说不清，说明分档还停在技术语言里，落不到产品开关上。

关键参考与核验范围

• EU AI Act 官方文本 ：用于核对风险分级与透明度义务的原文结构。
• EU AI Act 条文浏览 ：用于按条款查找风险分类与适用时间表。
• NIST AI 风险管理框架 ：用于核对风险识别、评估与处置的通用流程。

以上链接于 2026-10-27 实测可公开访问；未核验版本、条款更新与适用范围。核验日期：2026-10-27。

范围上只讨论一人产品如何给 AI 功能分档并落到默认值，不判定任何辖区是否适用、不提供法律意见，也不评价具体模型或供应商。

系列导航

• 下一篇：数据来源台账：七个来源、两条许可不清与三条个人信息路径
• 回到目录：一个人的 AI 合规：六个功能、二十二项供应商条款与一次客户审查
• 相关阅读：一个人给产品加 AI：判据、成本、护栏与验收