访客与门禁
访客预约、证件核验与通行记录是接待的基础数据。怎么接：预约走线上表单，核验结果由前台或安保录入，通行记录按次查询。边界是证件影像与人脸信息不进问答库，门禁授权接口不开放自动写入。
会议与日历
会议室、日历与参会人决定协调能否做准。字段要求包括会议室容量、设备、位置与预约时段，缺设备信息就会出现推荐了却用不了。怎么接：只读日历，写入统一走会议系统接口并保留操作日志，方便追溯改期原因。
工单与库存
报修、保洁、用品申领与库存台账决定事务类请求能否闭环。怎么接：工单系统提供创建与查询接口，库存提供安全库存与领用记录；采购审批仍在原系统完成，工具只提需求与历史价格参考。不在工具里重复审批。
协同与通知
企业即时通讯与邮件是通知的出口，必须限定发送范围与审批。为什么单独列：误发全员通知是行政场景最常见的事故，接口要支持按部门发送、二次确认与撤回，并保留发送记录。便于事后追查责任。
明确不接的数据
人脸、指纹、健康与家庭成员信息不接，访客证件影像非必要不保存。边界写进接口清单：确需保存的单独授权、单独环境、限定访问并设删除期限，避免为了便利把敏感数据堆在一处。避免二次扩散。这是硬边界。
适用与不适用
适合谁
- 正在做行政 AI 立项、需要列接口范围的 IT 与行政
- 多园区、多系统并存、数据需要打通的企业
不适合谁
- 希望接人脸识别做通行自动化的项目
- 访客与会议仍全靠纸质登记的企业
典型场景
某园区先接四类系统：访客预约表单、会议室日历、报修工单与企业即时通讯。访客核验由前台录入，会议室只读日历、写入走原接口，通知按部门发送并二次确认。人脸与证件影像不接，权限按岗位分配，日志保留查询记录。
可执行步骤
- 列出访客、会议、工单、库存、通知与快递六类的数据来源、字段与更新频率
- 标出敏感数据，明确哪些不接、哪些只在单独环境保存并单独授权访问
- 与行政确认字段口径、更新频率与责任人，形成书面接口清单并双方签字
- 优先只读接入，写入统一走原系统接口，并保留可查询的操作日志与操作人
- 通知接口限定发送范围，设置二次确认、撤回与发送记录留存的具体机制
常见坑
- 为了通行便利接入人脸与指纹信息，既超出必要范围，也很难说明保存依据与期限，风险很高。
- 会议室只接日历不接设备信息，推荐了没有投影的会议室，协调反而更费时，用户不再信任。
- 通知接口不设发送范围与二次确认，一条测试消息发给全员，撤回也来不及，只能逐一道歉。
自检与验收清单
- 六类系统的字段、更新频率与责任人是否书面化
- 敏感数据的不接清单是否明确并写入接口文档
- 是否以只读接入为主，写入是否走原系统接口
- 通知是否限定发送范围，并有二次确认与撤回
- 权限与日志是否按岗位设置，并按季度检查与清理
常见问题
一定要接门禁吗？
不一定。访客登记与核验可以由前台录入，门禁只做查询；是否接通行记录取决于安全要求。若接，建议只读并限定查询范围，不开放自动授权，避免系统绕过人工核验。
老系统没接口怎么办？
用导出文件与定时同步过渡，保留人工核对环节；不要为了接 AI 改门禁或会议系统的核心数据。等流程稳定后，再向供应商申请只读接口，范围越小越容易通过审批。
访客数据怎么管？
按最小必要收集，告知用途与保存期限，到期删除；证件影像非必要不保存，确需保存的单独授权并留访问日志。接口层面就要限制字段，而不是等数据堆起来再治理。