AI 接入现有业务系统前，需要核对哪些接口与权限

先确认需要完成哪一种业务动作

接入现有系统时，应先写清“读取哪些对象、更新哪些字段、在什么条件下生效”。能连通接口，只证明一条通信路径可用；是否允许当前岗位访问某条业务记录，仍需独立确认。把查询、草拟、提交和审批分开，可以让业务方逐项决定授权范围。

OWASP 关于对象级授权的说明强调，对具体业务对象的访问需要授权检查。本文据此整理接入核对问题，不提供漏洞测试步骤，也不构成完整安全审计。

依据：[1] OWASP API Security：Broken Object Level Authorization

给每个接口建立可讨论的清单

按读、草拟、写回逐级检查

1. 由业务负责人确认一条最小任务路径，并让系统负责人核对接口说明与真实开放范围。
2. 先用获准的测试记录检查读取结果，分别覆盖本人可见、他人不可见及权限被撤销的对象。
3. 生成草稿后检查字段来源和人工确认，明确模型建议不能自行提升为审批决定。
4. 获批写回后，核对目标对象、执行前状态和结果记录；结果未知时先查状态，避免重复提交。

这些步骤描述业务验收顺序，具体技术实现需由目标系统负责人结合实际能力确认。测试账号、凭据和原始业务数据不应出现在公开报告。

用假设订单同步发现隐藏分支

假设运营人员确认一份订单整理结果后，才允许写入内部待处理记录。第一轮请求超时但后台可能已经保存，如果直接再次提交，可能产生重复记录。演练应检查能否用业务关联信息查到原处理结果，并由负责人决定重试或人工补录。这是设计示例，不是实际故障或客户案例。

还应加入订单归属部门变化的情形：即使之前可读，写回前也要按当前授权核对目标对象。原会话中留下的数据如何展示和保留，需与资料权限规则一并确认。

把接入验收和运行责任留在记录里

上线前确认异常由谁接收、谁能暂停联动、恢复要满足哪些条件。仅有错误日志，缺少业务接续人，仍不足以完成交接。

准备系统概况后再沟通集成范围

沟通 AI 业务系统集成时，先提供系统用途、预期读写动作、接口开放状态、测试环境与审批联系人。没有接口文档可以先登记缺口，不要推定能通过其他方式绕过权限。交付清单应写明接入对象、例外情况、验收记录与维护边界；公开留言无需提供账号或密钥。