外呼合规：能做的不靠自觉，靠硬拦
国内做外呼，最让项目停摆的不是识别率，是号码来源说不清、投诉没人处理、录音与个人信息边界模糊。这一页写清系统里具体拦了什么、留了什么痕、以及责任边界在哪里。
为什么先讲合规
技术问题能返工，合规问题不能
国内做外呼，最容易让项目停摆的不是识别率不够、不是延迟太高， 而是号码来源说不清、客户投诉没人处理、录音与个人信息留存的边界模糊。 这些问题一旦发生，代价往往是行政处罚或民事索赔，不是重做一版系统能解决的。
先把责任边界说清楚
我们是软件提供方，不是外呼业务经营方。号码是否合法持有、 是否取得客户同意、是否做了必要的报备 —— 这些责任在实际外呼的企业身上。
这不能含糊。市面上有供应商承诺「包合规」「出了事我们负责」， 这在法律上是不可能成立的：处罚对象是实施营销外呼的主体，不是卖软件的人。
我们能做的是：把监管要求做成系统里的硬约束， 让你的操作在技术上无法越界，并保留完整的执行证据。
这套系统的做法：能做的不靠自觉，靠硬拦
大多数「合规」是写在员工手册里的，靠培训和抽查维持。但外呼是高频、重复、有业绩压力的动作， 靠自觉一定会失守。所以本系统把这六类约束写进了代码路径，不提供关闭开关。
号段、时段、频次、退订 —— 这四道闸门在拨号之前就已经跑完了。
① 号段硬拦
700 号段、95 开头的服务号段、虚拟运营商号段（170/171 等）在拨号前拦截。 这些号段不得用于商业营销外呼，属于号段规划层面的规定，不是话术能规避的。
② 时段硬拦
只在允许的时段内拨打。默认工作日 9:00–12:00、14:00–20:00， 午休与夜间不呼。法定节假日表需每年导入，系统不会自己猜。
③ 频次硬拦
同一号码在同日、24 小时、7 天、30 天四个窗口的拨打次数都有上限， 上限是硬约束，不能把某个号码设成「无限拨打」。
④ 退订硬拦
客户说「不要再打」立即写入退订名单，永久生效，无冷却期。 后续所有名单导入自动比对剔除 —— 这是跨模块的，不是某个批次的事。
⑤ 录音硬开关
配置关闭录音后不写盘、连目录都不建，丢弃的字节数写入审计。 目的是杜绝「以为关了、其实一直在录」这种最危险的状态。
⑥ 预检 fail-closed
合规引擎不可用时整个批次拒收，而不是「先打了再补记录」。 失败必须显式，不允许静默降级成「放行」。
关键概念
「客户同意了」到底怎么算成立
商业营销外呼的核心前提是取得对方同意。但「同意」不是一句口头承诺， 在系统里必须能落到一条可核查的记录上。
| 要素 | 为什么必须记 | 缺失的后果 |
|---|---|---|
| 同意的渠道 | 网页表单 / 门店签署 / 电话录音同意 / 老客户合同内约定 | 说不清来源，等于无法证明取得过同意 |
| 同意的时间 | 用于判断授权是否在有效期内 | 无法回应「这个授权是三年前的，早过期了」 |
| 同意的事项范围 | 是同意「接听服务回访」还是同意「接受营销推广」，两者不同 | 超范围使用，等于没有同意 |
| 凭证引用 | 指向原始证据（表单编号、录音文件、合同编号） | 有记录但拿不出原始证据，仍然说不清 |
| 撤回记录 | 客户什么时候、通过什么方式撤回了授权 | 撤回后继续拨打，是最常见的投诉来源 |
撤回为什么必须走同一套链路
实践中最常见的漏洞是：客户在电话里说「别打了」，系统挂断了电话， 但退订记录没写进去；或者写进了退订名单，但外呼模块的合规校验绕过了这个标记。
本项目的做法是把「撤回」和「退订」收敛到同一处判定： 拨号前的合规校验必须读这个标记，而且这个判定不能有旁路。 曾经有一版实现里，合规引擎解析同意状态时绕过了撤回标记， 导致撤回在拨号路径上完全不起作用 —— 这类 bug 靠人工测试很难发现， 后来是通过「接线断言」测试才固定下来的。
不要买名单，这是刑事风险
买卖、提供、获取公民个人信息在国内可能构成刑事犯罪，不是「违规」级别的问题。 任何声称「提供精准客户名单」的供应商，都应该直接排除。
系统在设计上不提供「名单市场」功能，也不代购号码。 名单必须是你自己合法持有的客户数据，通过 CSV 导入。
数据与留痕
号码、录音、审计，各存什么、存多久
个人信息保护的核心不是「不收集」，是「收集得有必要、 保存得有期限、访问得有控制」。下面这套设计是围绕这三点做的。
「监管来查某一通电话」时能拿出什么
按时间段导出一个取证包，里面包含：这一通电话的号码（脱敏）、拨打时间、 通话时长、完整转写文本、录音文件（若开启）、意图判定与知识库命中记录、 质检评分与违规项、以及所有查看过这条记录的操作日志。
这条链路的价值不在于「我们有录音」，而在于每一项都能对应到具体的时间与人。 很多系统只能提供录音，但回答不了「谁在什么时候导出过这个录音」。
容易被忽略的三件事
这些细节经常被漏掉
下面三件事在合规检查里经常被问到，但在方案阶段几乎没人提。
AI 身份要如实告知
被客户问「你是不是机器人」时如实回答。刻意伪装在监管口径里不是加分项， 而是加重情节。系统把这个行为写死，不提供「自称真人」的选项。
转人工不能只是「挂断」
承诺转人工就必须真的有人接。只把记录标记成「已转人工」然后无人跟进， 比不承诺更糟 —— 客户会觉得被欺骗。
节假日表要每年更新
法定节假日与调休安排每年不同，系统不会自己推算。 表过期会导致在节假日照常外呼，这是很典型的投诉来源。
主叫号码要报备
外呼使用的主叫号码应与你的业务主体一致，并按线路商要求完成实名与报备。 号码来路不明是投诉后核查不过的第一道坎。
投诉要有闭环
客户投诉进来后必须有人处理、有结论、有回访。工单永远躺在待处理状态， 等于没有闭环 —— 这在检查时是明显的问题。
内部权限要分级
能导出完整取证包、能看毛利、能导入名单，应该是不同的角色。 一把万能钥匙等于没有审计。
常见问题
合规方面被问最多的五条
这些问题的答案会影响你「能不能做」这个判断，所以写得直接一些。
虚拟号段、700 号段到底能不能用来做营销外呼？
不能。这些号段的规划用途不是商业营销外呼，属于号段管理层面的规定。
实践中的风险是双重的：一是监管检查时直接不合规；二是这类号码的接通率与可信度 本来就低，客户看到这类号码更倾向于直接挂断或标记骚扰。
系统的做法是在拨号前直接拦截，并把拦截原因记录下来。 如果你拿到的一批名单里大部分是这类号码，那批名单本身就有问题。
客户说「不要再打了」，系统会怎么处理？
三件事同时发生：当前通话立即结束、该号码写入退订名单（永久）、 后续所有名单导入时自动比对剔除。
关键是第三件事——退订不是「这个批次不用了」，而是全站生效。 很多系统的退订只作用于当前名单，换一批名单导入同一个号码又会打过去， 这是投诉的主要来源之一。
另外，撤回授权（客户之前同意过、现在撤回）走的是同一条链路， 不是另一套逻辑。两套逻辑并存迟早会有一处没生效。
录音要不要事先告知客户？
建议在开场白里明确告知，这是最稳妥的做法：「本次通话可能会录音， 用于服务质量管理」。多数客户听到这句不会有负面反应，反而是信任信号。
如果因为业务原因不便在开场说，至少要在内部制度里明确录音的用途、 保存期限与访问权限，并确保录音不会被超范围使用。
系统层面：录音开关、留存天数、访问权限都是可配的， 具体取值建议由你的法务或合规负责人确认，而不是由技术决定。
用 AI 打电话需要什么资质或报备？
这不是软件层面能回答的问题，取决于你的业务性质、号码用途和所在行业。 通信管理、个人信息保护、行业专项监管（如金融、医疗、教育）可能有不同要求。
可以给你的判断顺序是：① 主叫号码是否以你公司主体实名并完成报备； ② 你的行业有没有专门的营销外呼规定； ③ 客户数据是否合法持有并能提供授权凭证。
这三条任何一条说不清，都不建议先上线再补。这也是为什么系统把「授权凭证」 做成了一等公民，而不是可选字段。
出了投诉，系统能提供什么证据？
可以导出该号码相关的完整记录：所有拨打时间与结果、 每通电话的转写文本与录音（若开启）、当时的合规判定结果、 客户是否曾表示拒绝或撤回、以及谁查看过这些数据。
最有价值的一项其实是「当时的合规判定结果」—— 它能证明系统在拨打时确实做过检查、检查结论是什么。 很多系统只有通话记录，没有决策记录，出事时说不清「当时为什么允许打这一通」。
检查会看什么
一次合规检查，通常查这几样
不同监管口径关注点不同，但底层的材料准备是相似的。 下面按「能拿出什么」来组织，而不是按条文。
| 会被问到 | 你需要能拿出 | 系统里在哪 |
|---|---|---|
| 这批号码从哪来的？ | 名单导出记录、授权凭证、导入批次信息 | 名单批次与授权凭证记录 |
| 有没有征得同意？ | 同意渠道、时间、范围、原始凭证引用 | 授权凭证五项要素 |
| 客户拒绝后有没有再打？ | 退订登记时间，以及之后零拨打的记录 | 退订名单 + 拨号历史 |
| 有没有在禁止时段拨打？ | 拨号时间分布、时段配置 | 拨号历史 + 时段配置 |
| 通话里说了什么？ | 录音（若开启）与转写文本 | 录音归档 + 全量转写 |
| 谁看过客户的完整信息？ | 查看记录：谁、何时、看了哪条 | 审计明细（只追加） |
| 投诉怎么处理的？ | 工单记录、处理结论、回访情况 | 诉求工单闭环 |
「能拿出什么」比「有没有制度」更重要
制度文件容易写，材料难补齐。检查时最常见的情况是： 公司有一份写得很完整的《外呼管理制度》，但被问到某一通具体电话时， 拿不出当时的合规判定记录。
所以系统的设计重点是每一次判定都留痕： 不只是「这通电话打了」，还要记「打之前系统判定它合规，依据是什么」。 后者才是真正能自证的部分。
内部管理
制度层面还要配三份东西
系统能拦住操作，但拦不住「制度缺失」。这三份文档在检查时通常会被要求提供。
一、外呼管理制度
写清谁能发起外呼、名单从哪来、什么情况下禁止外呼、投诉怎么处理、谁负责。 这份制度的关键不是写得漂亮，而是与实际系统配置一致 —— 制度写「每日最多一次」，系统配置却是三次，检查时两条都会成为问题。
二、个人信息处理告知与同意记录规范
写清收集什么信息、用于什么目的、保存多久、怎么删除、客户怎么撤回。 配套的同意记录要能对应到具体客户与具体时间。
三、录音管理与留存规范
写清录音是否开启、保存多久、谁能听、听之前要不要审批、到期怎么销毁。 这一份经常被忽略，但它是投诉处理时最常被追问的。
这三份文档不需要写得多复杂，但必须与系统里的实际配置对得上。 对不上的时候，检查方通常以「实际执行」为准 —— 也就是说制度写得再好， 实际配置不合规仍然算不合规。