企业官网建设流程全解析

摘要 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+实战业务场景。

🔗 了解更多