AI Agent 上线前，先做一份授权画像和签收表

过去的 AI 试用通常停留在聊天、摘要、报告草稿和代码辅助。即使回答有误，风险主要在人工复制和采纳环节。现在的 Agent 开始连接文件、数据库、工单、CRM、BI、代码库、邮件和内部工具，它不只是生成内容，还可能触发下一步动作。

这种变化会带来一个现实问题：如果 Agent 读到不该读的数据，调用不该调用的工具，或者把草稿当成正式结论外发，事后很难只靠聊天记录说明责任。企业需要在试点开始前就写下它的身份、任务范围、动作等级、审批人、日志要求和停止条件。

授权画像的价值，是把“AI 能做什么”改写成“在什么业务场景、代表谁、使用哪些数据、经过哪些审批后，才允许做什么”。这样试点结果才能被业务、IT、安全、采购和管理层共同理解。

第一项是业务身份：Agent 是谁创建的、代表哪个团队或角色行动、服务哪条业务流程。身份不清，权限和责任都会失真。

第二项是数据范围：哪些文件、表、字段、指标、知识库、客户材料和系统上下文可用，哪些必须脱敏，哪些必须留在本地或私有化环境。

第三项是动作等级：只读检索、生成草稿、创建待办、提交审批、写入系统、外发消息、修改生产数据，必须分级处理，不能混在一个“允许使用工具”里。

第四项是人工审批：哪些动作必须由谁确认，审批记录保存在哪里，拒绝原因是否需要回写到证据包。

第五项是质量检查：SQL、指标口径、客户报告、业务建议和对外回复要用什么规则校验，哪些输出只能作为候选建议。

第六项是日志与回滚：保留输入、工具调用、模型建议、人工修改、最终输出和异常处理记录；高风险动作还要有撤回或暂停机制。

第七项是退出条件：当数据范围不足、权限不清、质量不稳定、成本失控或责任人缺位时，应暂停试点，而不是继续扩大范围。

第 1 天应完成业务问题、责任人、输入材料、数据边界和动作等级确认。这里的目标不是让 Agent 立刻展示所有能力，而是让所有参与方知道本次试点只解决哪个问题。

第 3 天应产出候选材料和风险清单。例如字段口径解释、ETL 变更说明、报告草稿、数据质量问题清单、客户回复草稿或本地资料摘要。每份候选材料都要标注来源、假设和需要人工确认的部分。

第 5 天应完成一次人工审核和质量检查。业务负责人确认结论是否可用，数据或 IT 负责人确认权限和质量风险，实施方记录需要修改的地方。

第 7 天应形成签收结论：可以进入下一阶段、需要补齐材料后再评估，或者当前不适合继续推进。这个结论要能被没有参加演示的人读懂。

如果试点只留下演示截图和聊天摘要，就不应进入更大范围。企业需要的是可复查材料，而不是一次顺利的现场展示。

如果客户的问题主要是本地文件、会议材料、截图、表格、合同、投标资料或报告草稿，先用 inchWorker 判断资料能否在本地优先边界内变成交付初稿。这个入口强调可修改、可检查和人工确认。

如果客户的问题涉及数据库、数仓、ETL、BI、指标口径、客户经营报告、权限审计或私有化部署，就应该进入 InchStack 的受控试点。这个入口强调业务问题、数据范围、模型建议、人工审核、质量证据和交付回执。

如果客户重点关心用量、月度额度、客户自管模型密钥、本地安装、私有模型网关、私有化服务、发票或合同，就应先看 pricing 和 trial 边界，避免在内容文章里提前承诺服务范围。

清晰分流能保护销售和交付质量。适合本地资料处理的客户不需要过早进入企业项目；适合企业数据闭环的客户也不应只得到一个文件整理工具。

这篇文章可以明确表达：Surinch 关注的是企业 AI 落地最后一公里，尤其是把 Agent 放进可控的数据、文件、工具和交付流程里。它可以帮助客户把业务问题拆成边界、证据和签收材料。

但文章不能承诺 Agent 替代员工专业判断，不能承诺固定收益，不能绕过人工审批，不能把本地或混合环境描述成天然安全，也不能暗示 Surinch 已经完整实现某个外部治理框架的全部要求。

对外表达应使用“候选建议、人工确认、质量证据、交付回执、停用条件、下一阶段评估”这些词。这样读者会理解这是一个可控试点和交付路径，而不是一次无限扩大权限的自动化演示。

真正适合进入下一步的客户，会愿意提供一个具体业务问题、一个数据范围、一个审批人和一个签收时间点。不能提供这些信息的需求，应先继续阅读资源中心或做轻量试用。

对销售和实施团队来说，授权画像也能降低沟通成本。客户如果能在会前确认数据范围、动作等级和审批人，就更容易进入受控试点；如果这些信息暂时缺失，双方也能尽早把需求收缩到本地资料整理或样例验证。