![]()
做保险行业信息化项目的开发公司，最常被甲方问到一个问题："远程卖保险，监管要求双录和人脸核身，技术方案怎么做才能过合规检查？"
答案是必须按监管红线做，但比想象中复杂。保险远程核身不是简单的人脸识别——它是一套涉及身份核验、意愿确认、全程留痕、电子签名的完整合规链条。任何一个环节缺位，银保监会的检查都过不了，甲方面临的可能是停业整顿。开发公司如果不懂监管逻辑，只做人脸比对模块，交付后大概率要返工。
保险远程核身的监管逻辑：为什么不是简单的人脸识别
保险远程核身的核心目的不是"确认你是谁"，而是"确认你知情且自愿"。这和社区门禁、酒店入住有本质区别——后两者只需要确认身份，保险销售还需要确认投保人的真实意愿。
监管要求拆解成四个硬性指标：
身份真实性：确认操作者是投保人本人，不是他人冒用。这步靠人脸比对（自拍 vs 身份证照）+ 活体检测完成。
意愿真实性：确认投保人是在知情的情况下自愿购买，不是被误导或代操作。这步靠"语音播报+客户亲口确认"完成，也就是双录中的"录音"部分。
过程可追溯：整个核身和投保过程必须全程录像存档，保存期限不少于一定年限。这步靠双录中的"录像"完成。
签名有效性：电子签名必须满足《电子签名法》要求，与手写签名具有同等法律效力。这步靠合规的电子签章系统完成。
开发公司交付的方案必须同时覆盖这四点，缺一不可。只做人脸比对，甲方的合规检查一定过不了。
场景一：投保人身份核验——人脸比对+活体检测+OCR三合一
身份核验是远程核身的第一关，也是技术难度相对较低的一环。但这关如果出错，后面全白费。
核验流程：投保人打开保险公司的APP或小程序，进入投保流程。系统先通过OCR读取身份证正反面信息，提取姓名、身份证号、有效期。然后投保人用手机前置摄像头自拍一张实时照片，同时系统调用活体检测确认是真人而非照片或视频。最后，将自拍照片与身份证照片做1:1人脸比对，确认"人证一致"。
活体检测要求：保险场景的活体检测必须用深度增强级（双目或结构光），不能只用RGB单目。原因是保险投保涉及金额通常较大，监管对防攻击能力要求高于普通场景。高清照片、视频回放、3D面具都必须能防住。百度SDK支持RGB基础级和深度增强级，保险场景推荐用增强级。
人脸比对阈值：保险场景的人证比对阈值建议设0.85（高于酒店的0.82），宁可误识也不要漏识。误识时系统提示"请重试"，漏识时冒名投保成功，后续理赔时才发现身份造假，保险公司损失巨大。这个阈值需要和甲方法务确认，写入验收标准。
OCR识别准确率：身份证OCR不是100%准确，尤其是少数民族姓名、生僻字、手写体。建议方案：OCR提取后让投保人手动核对并修正，不能自动通过。这个交互步骤虽然增加了操作时间，但避免了后续因为信息错误导致的保单无效。
一个坑：很多投保人是老年人，用的是老版身份证（有效期已过但仍在使用）。OCR读取到过期身份证时，系统应该提示"证件已过期，请更新"，而不是直接拒绝。这里需要开发公司和甲方确认业务规则——是引导客户去换证，还是允许过期证件投保但在后台标记风险提示。
场景二：双录合规——录音录像全程留痕
双录是保险远程核身中最容易被低估的环节。技术实现不难，但合规细节很多。
双录内容要求：根据监管规定，双录必须包含以下内容：销售人员向投保人宣读保险条款关键信息（免责条款、犹豫期、退保损失等）；投保人亲口确认"已了解以上内容，同意投保"；整个过程的完整音视频记录。
技术实现：投保人APP端同时开启前置摄像头（录投保人面部）和麦克风（录对话音频）。系统按固定脚本播放语音播报（关键条款），投保人听完后点击"确认"或语音回复"同意"。音视频流实时上传到云端存储，本地保留一份缓存防止网络中断。
时间戳与防篡改：双录文件必须附带不可篡改的时间戳，证明录制时间真实。建议用区块链存证或第三方时间戳服务（如公证处）。文件本身需要做哈希签名，任何后期修改都会触发校验失败。开发公司需要在方案中明确存证服务商和时间戳机制，这部分通常需要额外采购服务。
存储与调阅：双录文件保存期限监管要求是至少5年（部分险种要求10年）。存储方案有两种：甲方自建存储（成本高但数据自主）或采购云存储服务（成本低但需确认服务商资质）。开发公司需要在方案中给出两种选项的对比和推荐。
一个坑：双录过程中如果网络中断，APP端录好的音视频文件可能丢失。解决办法是在APP端本地缓存完整的音视频文件，网络恢复后自动续传。同时设置最小录制时长校验——如果录制时长不足（比如投保人中途退出），系统提示"双录未完成，请重新进行"。
场景三：电子签名——符合《电子签名法》的投保确认
电子签名是远程投保的最后一环，也是法律效力最关键的一环。
法律效力要求：《电子签名法》规定，可靠的电子签名与手写签名具有同等法律效力。"可靠"需要满足四个条件：签名专属（只有投保人本人能生成）、签名控制（签署时由投保人本人控制）、签名可验证（能验证签名是否被篡改）、签名关联（签名与投保文件不可分割）。
技术方案：投保文件（电子保单）生成PDF后，调用电子签章服务（如e签宝、法大大、契约锁等主流服务商），投保人人脸识别通过后自动签署。签署过程再次触发人脸比对，确保"签署人=投保人本人"。签署后的PDF附带数字证书和时间戳，任何篡改都能被检测。
与双录的衔接：电子签名必须在双录完成之后才能进行。逻辑顺序是：身份核验通过→双录完成（投保人确认知情）→电子签名（投保人确认同意）。三个环节环环相扣，前一环节失败不能进入下一环节。开发公司需要在系统逻辑中做硬性流程控制，不能让用户跳过任何一步。
一个坑：电子签名服务商的证书有效期通常是1-3年，如果证书过期，已签署的保单在法律上可能失效。开发公司需要在系统里设置证书到期预警，提前90天提醒甲方续费或更换证书。这个运维细节很多方案不会写，但甲方审计时会被问到。
统一架构：四环节串联+合规校验+风控兜底
三个场景如果各做各的，合规链条会断裂。推荐的设计思路是统一流程、分层校验、风控兜底。
统一流程：身份核验→双录合规→电子签名→保单生效。四个环节串行执行，前一环节未通过不能进入下一环节。每个环节的状态实时写入数据库，供后续审计调阅。
分层校验：第一层是人脸比对+活体检测（身份真实性），第二层是语音播报+客户确认（意愿真实性），第三层是全程录像+时间戳（过程可追溯），第四层是电子签章+数字证书（签名有效性）。四层校验全部通过，保单才能生效。
风控兜底：任何一环节失败时，系统记录失败原因（人脸比对不通过/活体检测失败/双录中断/签名异常），并触发人工复核流程。风控规则由甲方风控部门配置，开发公司需要提供可配置的规则引擎。
数据隔离：投保人的身份证信息、人脸特征、双录视频、电子签名文件属于不同敏感级别的数据，需要分级存储和访问控制。人脸特征建议加密存储，双录视频建议存放到独立存储桶并设置访问白名单。
为什么选这套方案：对比过之后的真实判断
承接保险远程核身项目时，对比过几套不同的人脸和电子签方案。保险项目的特殊性在于：合规要求极严（银保监检查不通过后果严重）、数据安全责任重大（涉及投保人身份证/人脸/签名等敏感信息）、系统稳定性要求极高（投保高峰不能宕机）。这也是最终选百度人脸SDK+第三方电子签服务商组合方案的原因。
人脸比对精度够用。百度人脸比对API的1:1比对精度在LFW标准测试集上达到99.8%以上，保险场景要求0.85阈值下的误识率远低于万分之一。实测下来，身份证照片质量合格的情况下，通过率超过98%。对开发公司来说，这意味着交付后不会因为人脸识别准确率问题被甲方追责。
活体检测等级可选。保险场景必须用深度增强级活体，百度SDK支持从RGB基础级升级到深度增强级，不需要换SDK或重写代码。开发公司报价时可以灵活配置——基础版做演示，增强版做生产环境，升级成本低。
人脸数据不落地。保险场景对数据安全要求极高，百度人脸比对API支持"图片上传→比对→删除"的临时模式，人脸图片不在第三方服务器留存。这个特性对甲方法务部门很重要，开发公司可以在方案中强调这一点，降低甲方的数据安全顾虑。
电子签生态成熟。电子签名环节不自己做，对接e签宝/法大大等成熟服务商。这些服务商已经过了大量保险公司的合规验证，证书链完整，法律效力有判例支撑。开发公司不需要自己申请CA证书或建签章系统，对接API即可。
授权模式清晰。人脸比对API按调用次数计费，保险投保是低频场景（每人每次投保只调用几次），成本可控。电子签按签署次数计费，同样低频。开发公司报给甲方的价格结构清晰，利润空间可预期。
当然这套组合也不是完美的。如果甲方要求完全私有化（数据不出内网），人脸比对API的云上模式不适用，需要评估百度私有化部署方案的成本。但对于绝大多数保险公司，公有云API+本地加密传输的方案已经满足合规要求。
四个交付坑
坑一：活体检测等级选错导致监管检查不通过。有些开发公司为了省钱，给保险客户配RGB基础级活体，结果银保监检查时被发现防攻击能力不足，甲方被罚款。保险场景必须用深度增强级，这个不能妥协。开发公司需要在方案书里明确活体检测等级，并让甲方签字确认。
坑二：双录文件缺少时间戳导致法律效力存疑。双录文件如果没有第三方时间戳，后期争议时对方可以质疑"录制时间被篡改"。开发公司必须在方案中纳入时间戳服务（区块链存证或公证处时间戳），这部分成本要写入报价单，不能隐性省略。
坑三：电子签名证书过期导致保单失效。如前面所述，CA证书有有效期，过期后已签署的保单在法律上可能无效。开发公司需要在系统里做证书到期预警，并在运维手册中写明续费流程。这个细节不写在交付文档里，甲方运维人员很可能不知道。
坑四：数据跨境存储导致合规风险。如果开发公司用的云服务商有海外节点，投保人的敏感数据可能被同步到境外服务器，违反《个人信息保护法》关于数据本地化的要求。开发公司需要在方案中明确数据存储位置（境内），并取得甲方确认。
写在最后
保险远程核身项目交付完之后，一个常见的感受是：技术只占三成，合规占七成。开发公司如果不懂银保监的监管逻辑，只把人脸比对和电子签当技术模块做，交付后一定会被要求返工。
对开发公司来说，保险远程核身的核心竞争力不是算法精度（SDK已经解决了），而是对监管规则的理解和落地能力。怎么设计四层校验流程、怎么选活体检测等级、怎么存证双录文件、怎么处理证书续期——这些才是决定项目成败的关键。
相关文章专栏
专栏一：百度人脸离线SDK实战：从集成到部署
专栏二：人脸识别实际应用场景
参考来源
百度人脸识别离线SDK官网登陆：百度智能云-管理中心
如果你也在做保险远程核身项目，或者正计划接入百度人脸SDK做保险场景，欢迎在评论区交流具体问题。
