北京办公楼门禁人脸识别验收有哪些注意事项？凯源恒润北京监控安装工程公司汇总甲方值得追问的12个问题！

发布日期：2026-10-22 / 点击次数：67

北京办公楼门禁人脸识别验收有哪些注意事项？凯源恒润北京监控安装工程公司汇总甲方值得追问的12个问题！

做过门禁项目的人都熟悉一个场景：验收会上，乙方把检测报告摊开，上面写着识别率99.8%、活体检测≥98%、比对速度≤205ms之类的标称值，参数一项项对过去，看起来漂亮。甲方点头，签字，项目“通过”。

然后交付三个月，保安开始抱怨：下午西晒的时候人要摘帽子侧着脸才认得出，有员工拿手机照片试了一下居然开了门，消防测试那天闸机纹丝不动差点出事，业主群里有人甩出一张法院判决链接问“谁同意你存我脸的”。

参数通常来自特定测试条件下的检测报告，日子是甲方在现场一天一天过的。这两件事之间的裂缝，就是验收时值得确认而没有确认的那些问题。

下面12个问题，按现场使用中容易暴露的环节来排。每一个背后，都指向验收中容易被参数清单遮蔽的现场条件和使用场景——这些信息不一定体现在检测报告里，但对实际体验有直接影响。

本文所列问题的目的，是帮助甲方在验收中把现场条件和功能边界确认清楚，而非预设设备供应方存在隐瞒。多数供应商愿意在验收阶段配合明确的测试方案；把测试条件、测试方法和记录格式提前约定，对双方都是效率更高的做法。

第一问：你的识别率，是在什么条件下测的？

99.8%这个数字在招标文件里反复出现，但值得追问的是测试条件：什么光照、什么角度、什么人脸库规模、戴口罩算不算失败。部分公开研究或测试报告中可见的参考趋势是：光照条件、拍摄角度等因素会对识别表现产生影响，明亮光照与昏暗环境、正脸与侧脸/高角度之间的准确率可能出现差距。具体数值因测试条件而异，不宜将某一组数字直接等同于现场预期。实验室里打的是顺光、正脸、配合的“标准人”，现场站着的是逆光、侧脸、戴着口罩还边走边看手机的人。验收时不妨请乙方用项目实际点位的光照条件，拿真实员工的人脸库，连续跑三天。数字会说话，但前提是数字产生的条件和现场对得上。

第二问：逆光到底是怎么解决的，还是“调参数”解决的？

逆光不是小概率事件。大堂玻璃门、园区西晒岗亭、地库出口，每一个都可能对识别表现构成明显挑战。部分项目案例中可见，地面材质反射光强烈、摄像机截取画面中面部偏暗时，通行体验会明显下降。技术上可讨论的回答是宽动态、智能曝光、人脸区域测光，而不是“把宽动态等级调到多少”。验收时要问的不是“支不支持逆光”，而是“在这个门口，下午四点半，现在走过去，数三秒，门开不开”。一次不过，后面需要的是现场调整和复测，而不是参数解释。

第三问：活体防的到底是照片、视频，还是面具？

“双目活体”在门禁项目中较为常见，但双目提供的是第二路光谱信息，活体判定最终依赖策略和阈值，两者不是一回事。验收时值得确认：现场活体功能是否处于开启状态、阈值设置是否合理。在部分项目中，出于通过率考虑，活体检测可能被关闭或阈值被放宽，此时照片攻击的通过风险会相应上升。建议将照片、手机录屏回放、约定材质的简易面具分开测试、分别记录，以便完整了解活体检测在不同攻击类型下的实际表现。测试项目的完整性本身是验收记录的一部分。

第四问：断网了，门还能不能开？记录会不会丢？

招标文件里“断网离线运行”和“断网续传”经常被当成同一件事写。它们的区别在于：断网时设备能不能独立完成比对和开门，以及网络恢复后离线期间产生的记录能不能完整、非明文地回传。验收的动作不是问“支不支持”，而是拔掉网线，当场刷脸进门，再插回网线，登录平台看那条记录在不在。拔网线这个动作，比书面承诺更能说明实际能力。

第五问：消防联动，是软件通知，还是物理信号？

消防联动接口在技术规格中通常会有相应要求：消防信号触发时，门翼应当打开；断电时，门翼应当打开，人员自由通行。但“有接口”和“真动作”之间可能存在差异——有的项目消防信号进入软件平台，平台再下发开门指令，中间任何一个环节出现异常，闸机就可能无法按预期打开。验收时可以要求用短接消防联动接口的方式，模拟真实消防信号，观察门翼是否物理打开。涉及生命安全的功能，仅凭“平台显示已联动”不足以作为验收依据。

第六问：权限管理的颗粒度，能不能撑住三个月后的组织变化？

新项目上线时，权限表是干净的。三个月后，离职的没删干净，调岗的还留着旧门权限，外包人员拿了临时卡变成了长期通行，这些是物业和行政在实际运营中需要面对的事。验收时值得关注的不只是“能不能设权限”，还包括：分时段、分区域、多门互锁、反潜回、权限到期自动失效，这几件事在平台上操作起来需要几步。如果每次调整权限都需要依赖乙方工程师，系统的日常运维效率会明显受限。

第七问：通行记录存多久，谁有权调，调出来是什么格式？

记录留存的问题，甲方往往在出事后才想起来问。根据《人脸识别技术应用安全管理办法》，除法律、行政法规另有规定外，人脸信息的保存期限不得超过实现处理目的所必需的最短时间。门禁通行记录属于另一层数据，但逻辑相通——留存需要有明确的安保、审计或纠纷调处场景，而不是“以后可能有用”。验收时应当确认：记录默认存多久、到期是否自动清理、导出是否脱敏、谁有查询权限、日志本身能不能被篡改。如果回答是“存着不占多少空间”，这本身提示需要进一步确认留存策略和清理机制。

第八问：人脸底图存在哪里，有没有“必须上云”？

《人脸识别技术应用安全管理办法》第八条规定：除法律、行政法规另有规定或者取得个人单独同意外，人脸信息应当存储于人脸识别设备内，不得通过互联网对外传输。部分项目的默认架构是将人脸底图同步到云端或中心平台，以便统一管理，但这在合规上需要逐项判断是否具备法定例外或单独同意基础。验收时可以问清楚：底图存在设备本地还是服务器、是否经由公网传输、传输是否加密、远程运维人员是否可能接触到原始人脸图像。架构层面的问题，往往能提前暴露合规层面的风险。

第九问：不同意刷脸的人，有没有另一条路走？

这是物业项目需要特别留意的环节。《人脸识别技术应用安全管理办法》第十条明确规定：实现相同目的或者达到同等业务要求，存在其他非人脸识别技术方式的，不得将人脸识别技术作为唯一验证方式；个人不同意通过人脸信息进行身份验证的，应当提供其他合理、便捷的方式。从公开判例和监管实践看，仅张贴通知而住户未明确提出异议，通常难以满足“单独同意”的要求；以“不录人脸就无法正常出入”等方式变相强制，也与上述原则不符。验收时应当确认的不只是“有没有备选方案”，还包括备选方案是否实际可用、是否附加不合理条件。一张门禁卡、一个密码键盘的成本不高，但它是合规要求落地的一个具体环节。

第十问：记录和底图的删除，是谁的权利，怎么操作？

“删除权”在验收会上不常出现，但在运营期会出现。员工离职、租户退租、业主撤回同意，都涉及人脸底图和关联记录的清理。验收时可以关注：删除操作是逐个手动还是支持批量触发、删除后备份中是否仍有留存、删除动作本身是否留痕。如果系统设计中没有为“撤回同意后的处理”预留可操作的路径，合规要求在技术层面就缺少落地支点，仅靠制度文本难以充分实现。

第十一问：这套系统三年后谁维护，备件和固件更新走什么渠道？

人脸门禁是硬件、算法、平台三层叠在一起的东西，任何一层停止更新，整套系统都会面临老化风险。验收时值得确认：固件安全补丁由谁推送、算法模型是否随版本升级、过保后的备件价格和响应时效如何约定。很多项目的真实成本不只在建设期，也在第三年的一次主板故障或一次算法升级。把这些写入验收备忘录，比单纯比较初始报价更有长期意义。

第十二问：出了事，责任边界画清楚了吗？

这是最不技术、也最需要在签字前确认清楚的一问。识别错误导致尾随进入、活体被绕过导致财产损失、人脸数据泄露导致诉讼，这些场景下：设备责任、算法责任、平台责任、运维责任、甲方管理责任，各占多少？合同里如果只有一句概括性的“乙方保证系统稳定运行”，责任边界实际上是不清晰的。验收签字的那一刻，涉及的不仅是工程款，还有后续若干年的安全责任和合规责任。

写在最后

这12个问题，指向的是同一件事：人脸识别门禁的验收，不只是对参数清单，也是对使用场景、功能边界和责任分配的确认。乙方交付的是设备和算法，甲方承接的是每天数千人进出的通行体验、消防疏散的底线，以及在个人信息保护框架下作为个人信息处理者的管理责任。

实验室里的99.8%值得尊重，但现场下午四点半的那一道逆光、拔掉网线的那一次刷脸、消防信号触发时门翼的那一下打开、业主问“我不录脸能不能回家”时给出的那条路——这些是验收中同样需要落到现场的内容。

签字之前把该确认的条件确认清楚，签字之后对系统的实际能力也就有了更合理的预期。