摘要 AI 项目落不了地根源通常不是模型能力而是四个组织问题数据归属、权限确认、失败追责、经验沉淀。这四个问题在传统软件里可以绕过在 AI 里绕不过。2025年初一家股份制银行的信贷部门完成了一套AI辅助审贷系统的技术验收。模型在测试集上的准确率是91%技术评审的结论是可以上线。 八个月后这套系统仍在运行但信贷员的实际使用率接近零。系统每天生成风险评分没有人看。信贷员用自己的判断做决策偶尔瞄一眼AI的分数作参考从不以它为准。 不是因为模型不准。是因为没有人解决过一个更基础的问题如果AI说批人说不批最后出了坏账谁负责没有人回答过这个问题所以信贷员选择了最安全的做法不用它。数据归属 谁先开放 | 权限确认 谁授权 | 失败追责 谁兜底 | 经验沉淀 谁来记SERIES MAP · 系列位置1 驻场≠FDE | 2 四个断层 | 3 怎么建01 GAP 1 · 数据归属 数据在谁手里谁就不想先动很多AI项目在启动会上听起来条件齐备有业务需求有预算有技术团队有管理层支持。但项目真正推进时数据成了第一道墙。 数据分散在各部门手里销售部门有客户行为数据风控部门有历史坏账数据运营部门有流程日志IT部门管数据库权限。每个部门都愿意配合没有部门愿意先开放。 原因很简单**开放数据意味着被审查。**数据里有多少脏数据、有多少口径不一致、有多少历史遗留部门本身也不完全清楚。先把数据拿出来的部门先暴露问题。 这个问题不是技术问题是激励问题。解法不靠技术手段靠的是把数据贡献写进项目KPI——让先开放数据的部门从暴露风险变成记录贡献。这个改变正是FDE在数据断层上能做的事。现场观察 · 一个常见误判 数据断层的真实原因不是「数据孤岛」这个技术词而是谁先动谁先输的组织博弈。解决它的工具不是数据中台是让数据贡献变得对贡献方有利。02 GAP 2 · 权限确认 AI 给了建议谁来执行AI系统的运行逻辑是分析输入 → 给出建议或动作 → 执行。在演示里第三步看起来顺理成章。在真实业务里第三步往往卡住。 AI说这笔订单有欺诈风险建议拦截。谁拦截客服代表的职责是处理问题不是做风险判断。风控主管有权限但不可能每笔单都过他的桌子。AI给的建议停在系统里没有人接没有人确认也没有人否决。 这个问题的本质是组织的权限边界是为人工流程设计的没有为AI建议设计执行入口。FDE做的其中一件事是把AI建议的执行权在组织里落地哪个级别的建议谁可以直接执行哪个建议需要上一级确认哪个建议必须有人工审核才能生效。这不是技术架构是业务规则的显性化。03 GAP 3 · 失败追责 AI 出了错谁负责这是四个断层里最难处理的一个在中国组织文化里尤其突出。 传统工作里出了问题有相对清晰的追责逻辑是谁做的决定就找谁。人工判断的结果人工负责。但AI的决策是概率性的它不做决定它给建议或预测。当AI建议被人执行后出了问题责任在AI还是在执行的人在部署AI的IT部门还是在业务部门 这个问题没有自然的答案。组织必须事先设计一套什么类型的错误由AI承担通过调整模型解决什么类型由人工执行者承担什么类型触发流程复盘而非个人追责。 没有这套设计业务部门就会选择不让AI进真实决策流程从根本上切断AI的使用价值。上面那家银行的信贷员做的是理性选择不是对AI的偏见。现场观察 · 一个常见误判 信贷员不用 AI不是因为他不相信 AI而是因为用了 AI 之后他的责任边界变模糊了。把这种行为理解成「用户阻力」是错的。这是组织问责结构在个人层面的理性反应。04 GAP 4 · 经验沉淀 每个项目结束一次完整的学习机会就消失了项目结束时团队通常能留下什么代码仓库、部署文档、用户手册。有时候还有一份项目总结PPT。 留不下来的是什么哪些失败路径被走过、哪些数据质量问题被踩坑、哪些组织阻力在哪个节点出现、评测标准为什么最后定成那样、客户现场哪些隐性规则没写在文档里。 这些东西才是AI落地经验里最有价值的部分。它们停留在做过这个项目的人脑子里项目结束就散了。下一个类似项目重新摸索重新踩坑。 而且这种失效不只在项目结束时发生项目进行中也会。FDE 把发现传回来了但组织端没有做好接收的准备。业务负责人说「收到我们研究一下」IT 说「需要走需求流程」。两个回答哪一个都不是拒绝但哪一个都没有推动任何决策。发现停在流程入口三个月后还在那里。 根本原因不是没有人有能力处理而是没有人被明确要求在指定时间内给出答复。组织的接收端和FDE的输出端一样需要被设计谁的工作是消化现场发现谁有权做决定发现到达后多少天内要有回应。这套东西不存在经验沉淀断层就会从项目中途一直延续下去。 这就是这批经验真正的归处不只是项目报告而是可复用的场景接入模式、常见失败路径、评测标准模板、组织阻力处理方式。每一次结构化沉淀都变成了下个项目的起点——不会因为一个人离职而消失而是变成了团队的集体记忆。◆ ◆ ◆那位信贷员现在每天还是用自己的判断做决策偶尔瞄一眼AI的分数。他没有做错任何事。 这四个断层有一个共同特征它们都不是纯技术问题但也没有哪一个是靠写几行代码就能绕过去的。数据归属要靠权责设计权限确认要靠流程重设失败追责要靠问责框架经验沉淀要靠结构化复盘机制。每一个问题都需要业务、IT、法务、管理层坐在一起做出选择而不是靠工程师单独解决。 而且这四个断层不需要同时打通——每个行业都有一个比其他三个更容易突破的起点。找到那个起点是下一篇要做的事。 下一篇我们看具体怎么做在制造、金融、政务三个场景里这四个断层各自从哪个口子开始打通以及三个月内哪些事是可以推进的。如果您也对AI落地中的组织断层问题感兴趣不妨了解观远数据的相关产品。观远数据以让业务用起来 让决策更智能为使命致力于为零售、消费、金融、高科技、制造、互联网等行业的领先企业提供一站式数据分析与智能决策产品及解决方案。观远数据专注智能分析平台为您提供一站式BI至AI智能分析全链路场景深耕零售、消费品、电商、金融、先进制造、医疗医药、互联网等行业200实战业务场景。 了解更多
摘要 AI 项目落不了地根源通常不是模型能力而是四个组织问题数据归属、权限确认、失败追责、经验沉淀。这四个问题在传统软件里可以绕过在 AI 里绕不过。2025年初一家股份制银行的信贷部门完成了一套AI辅助审贷系统的技术验收。模型在测试集上的准确率是91%技术评审的结论是可以上线。 八个月后这套系统仍在运行但信贷员的实际使用率接近零。系统每天生成风险评分没有人看。信贷员用自己的判断做决策偶尔瞄一眼AI的分数作参考从不以它为准。 不是因为模型不准。是因为没有人解决过一个更基础的问题如果AI说批人说不批最后出了坏账谁负责没有人回答过这个问题所以信贷员选择了最安全的做法不用它。数据归属 谁先开放 | 权限确认 谁授权 | 失败追责 谁兜底 | 经验沉淀 谁来记SERIES MAP · 系列位置1 驻场≠FDE | 2 四个断层 | 3 怎么建01 GAP 1 · 数据归属 数据在谁手里谁就不想先动很多AI项目在启动会上听起来条件齐备有业务需求有预算有技术团队有管理层支持。但项目真正推进时数据成了第一道墙。 数据分散在各部门手里销售部门有客户行为数据风控部门有历史坏账数据运营部门有流程日志IT部门管数据库权限。每个部门都愿意配合没有部门愿意先开放。 原因很简单**开放数据意味着被审查。**数据里有多少脏数据、有多少口径不一致、有多少历史遗留部门本身也不完全清楚。先把数据拿出来的部门先暴露问题。 这个问题不是技术问题是激励问题。解法不靠技术手段靠的是把数据贡献写进项目KPI——让先开放数据的部门从暴露风险变成记录贡献。这个改变正是FDE在数据断层上能做的事。现场观察 · 一个常见误判 数据断层的真实原因不是「数据孤岛」这个技术词而是谁先动谁先输的组织博弈。解决它的工具不是数据中台是让数据贡献变得对贡献方有利。02 GAP 2 · 权限确认 AI 给了建议谁来执行AI系统的运行逻辑是分析输入 → 给出建议或动作 → 执行。在演示里第三步看起来顺理成章。在真实业务里第三步往往卡住。 AI说这笔订单有欺诈风险建议拦截。谁拦截客服代表的职责是处理问题不是做风险判断。风控主管有权限但不可能每笔单都过他的桌子。AI给的建议停在系统里没有人接没有人确认也没有人否决。 这个问题的本质是组织的权限边界是为人工流程设计的没有为AI建议设计执行入口。FDE做的其中一件事是把AI建议的执行权在组织里落地哪个级别的建议谁可以直接执行哪个建议需要上一级确认哪个建议必须有人工审核才能生效。这不是技术架构是业务规则的显性化。03 GAP 3 · 失败追责 AI 出了错谁负责这是四个断层里最难处理的一个在中国组织文化里尤其突出。 传统工作里出了问题有相对清晰的追责逻辑是谁做的决定就找谁。人工判断的结果人工负责。但AI的决策是概率性的它不做决定它给建议或预测。当AI建议被人执行后出了问题责任在AI还是在执行的人在部署AI的IT部门还是在业务部门 这个问题没有自然的答案。组织必须事先设计一套什么类型的错误由AI承担通过调整模型解决什么类型由人工执行者承担什么类型触发流程复盘而非个人追责。 没有这套设计业务部门就会选择不让AI进真实决策流程从根本上切断AI的使用价值。上面那家银行的信贷员做的是理性选择不是对AI的偏见。现场观察 · 一个常见误判 信贷员不用 AI不是因为他不相信 AI而是因为用了 AI 之后他的责任边界变模糊了。把这种行为理解成「用户阻力」是错的。这是组织问责结构在个人层面的理性反应。04 GAP 4 · 经验沉淀 每个项目结束一次完整的学习机会就消失了项目结束时团队通常能留下什么代码仓库、部署文档、用户手册。有时候还有一份项目总结PPT。 留不下来的是什么哪些失败路径被走过、哪些数据质量问题被踩坑、哪些组织阻力在哪个节点出现、评测标准为什么最后定成那样、客户现场哪些隐性规则没写在文档里。 这些东西才是AI落地经验里最有价值的部分。它们停留在做过这个项目的人脑子里项目结束就散了。下一个类似项目重新摸索重新踩坑。 而且这种失效不只在项目结束时发生项目进行中也会。FDE 把发现传回来了但组织端没有做好接收的准备。业务负责人说「收到我们研究一下」IT 说「需要走需求流程」。两个回答哪一个都不是拒绝但哪一个都没有推动任何决策。发现停在流程入口三个月后还在那里。 根本原因不是没有人有能力处理而是没有人被明确要求在指定时间内给出答复。组织的接收端和FDE的输出端一样需要被设计谁的工作是消化现场发现谁有权做决定发现到达后多少天内要有回应。这套东西不存在经验沉淀断层就会从项目中途一直延续下去。 这就是这批经验真正的归处不只是项目报告而是可复用的场景接入模式、常见失败路径、评测标准模板、组织阻力处理方式。每一次结构化沉淀都变成了下个项目的起点——不会因为一个人离职而消失而是变成了团队的集体记忆。◆ ◆ ◆那位信贷员现在每天还是用自己的判断做决策偶尔瞄一眼AI的分数。他没有做错任何事。 这四个断层有一个共同特征它们都不是纯技术问题但也没有哪一个是靠写几行代码就能绕过去的。数据归属要靠权责设计权限确认要靠流程重设失败追责要靠问责框架经验沉淀要靠结构化复盘机制。每一个问题都需要业务、IT、法务、管理层坐在一起做出选择而不是靠工程师单独解决。 而且这四个断层不需要同时打通——每个行业都有一个比其他三个更容易突破的起点。找到那个起点是下一篇要做的事。 下一篇我们看具体怎么做在制造、金融、政务三个场景里这四个断层各自从哪个口子开始打通以及三个月内哪些事是可以推进的。如果您也对AI落地中的组织断层问题感兴趣不妨了解观远数据的相关产品。观远数据以让业务用起来 让决策更智能为使命致力于为零售、消费、金融、高科技、制造、互联网等行业的领先企业提供一站式数据分析与智能决策产品及解决方案。观远数据专注智能分析平台为您提供一站式BI至AI智能分析全链路场景深耕零售、消费品、电商、金融、先进制造、医疗医药、互联网等行业200实战业务场景。 了解更多
)