各位数字化转型的舵手，不论你是 CIO、CDO 还是企业内部的 AI 负责人，过去一年里，你是否也经历过这样的场景：高调启动了某个 AI 项目，结果雷声大雨点小，业务部门根本不买账，甚至最后悄无声息地烂尾了？
如果你的答案是肯定的，别灰心，你绝不是一个人。Gartner 的数据显示，虽然大家都在疯狂往 AI 里砸钱，但近一半的企业根本无法证明这些项目的商业价值。Regions Bank 的首席数据与分析官 Manav Misra 一针见血地指出，真正的挫败感往往来源于“不切实际的期望”。
实际上，问题往往不在于技术本身，而在于技术之外的“人”和“流程”。组织架构、运营模式的缺陷，随时可能让你的 AI 战车偏离赛道。
为了避免下一个 AI 项目重蹈覆辙，福建CIO网整理了一份“避坑指南”，咱们一起来看看那些容易忽视的非技术性失误。
如果你还指望靠着自己的 IT 团队或者某个“卓越中心 (CoE)”单打独斗，就能把 AI 推向全公司，那几乎注定要失败。FTI Consulting 的 Sumeet Gupta 强调，CIO 往往习惯从技术平台的视角去推动项目，但很多时候问题的核心根本不在这儿。
记住，AI 项目本质上是“利用技术解决业务问题”的业务项目。
寻找“业务共同发起人”：你需要找到那些对盈亏负责、清楚地知道“成功长什么样”的业务领导者，和他们一起共同领导项目。
让业务发现机会，让 IT 筛选方案：正如 Jack Henry 的首席数据官 Keith Fulton 所说，机会应该由业务领导者首先发现，然后由 AI 专家来评估哪些想法最靠谱，并将其列入候选名单。不要过度依赖外部顾问，你需要的是能在内部给你泼冷水的务实伙伴。
让产品经理懂业务：Misra 的做法很值得借鉴：让懂业务的产品经理加入团队，直接对接业务负责人，确保项目不偏离真实的业务需求。
项目的成功指标谁来定？千万别由 IT 部门代劳。
指标应由业务方制定：Gupta 明确表示，决定项目成败的指标，应该由那些对业务盈亏负责的人来拍板。CIO 可以提供如何衡量的建议，但核心的业务指标必须由业务负责人决定。
定期审查：这些指标不是定好就放一边了。业务和技术团队必须保持紧密沟通，每个季度都要进行复盘和审查。
这是最常犯的错误之一：技术团队闭门造车，开发出各种酷炫的功能，结果业务用户根本不用。如果没人用，你的代码写得再优雅也是白搭。
应对用户的恐惧和怀疑：员工面对 AI，难免会有“饭碗被抢”的焦虑。Fulton 指出，让人们将 AI 视为助手而不是替代品，这是变革管理中的一大挑战。
让用户参与每个环节：Gupta 强调，从项目启动之初，到开发过程的每一步，都需要用户的深度参与。在转型过程中，特别是涉及技术时，如果用户没有参与，项目绝不会成功。
培养早期“拥护者”：如果推广受阻，不妨效仿 Misra 的策略：寻找早期的支持者，为他们提供资源，让他们去影响身边的同事。同时，采用分阶段的推出方式，持续追踪使用率。
建立专门的指导团队：Fulton 分享了他们在 Jack Henry 的经验：专门设立了一个十人的指导团队，手把手教员工如何使用工具，通过正确的引导来赢得他们的支持。
不要仅仅把 AI 看作是自动化的工具，在动手之前，先全面审视你的工作流。
工作流重设与变革管理必须同步：Gupta 分享过一个案例，一家公司设计了非常完善的 AI 工作流，却因为没有做好与之相匹配的变革管理，导致几个月都没人真正使用。
运用“第一性原理”：深入了解你想解决的问题、期望的结果和输入条件，然后重新构思在引入 AI 后，这个流程该如何运作。缺乏围绕 AI 进行的重新发明或构想，是首要问题。
化繁为简：Fulton 则建议，对于复杂的企业流程，不要指望一蹴而就。可以先从简单的任务自动化开始，因为目前来看，Agent（智能体）处理简单流程的效果要比处理复杂流程好得多。与其画复杂的流程图，不如直接告诉 LLM 具体的步骤，让它自己去摸索工作流。
在启动项目前，我们经常会陷入“数据准备焦虑”，觉得数据不够干净、不够完美，项目就没法推进。
打破完美主义：Gupta 指出，并非所有项目都需要绝对完美、无暇的数据。很多时候，公司纠结的数据问题，其实和他们要做的实际用例根本没关系。
对症下药：Fulton 解释说，数据对于机器学习来说是关键，但对于大多数大语言模型（LLM）而言却并非如此——除非你需要进行复杂的预测、极度个性化的客户交互或是精准的线索评分。
聚焦核心数据：如果项目确实需要高质量数据，Misra 建议：只锁定那些必须用到的关键数据，集中精力去清理它们。借助现代的 AI 辅助数据清理和集成工具，这个问题其实没你想的那么难解决。
当然，这并不意味着你可以忽视数据质量、元数据管理和数据溯源等合规性要求，Gartner 分析师 Avivah Litan 提醒，这些问题同样需要引起重视。
Talasaz 提醒我们，治理非常关键，尤其是在编排和可观测性方面。你需要对 Agent 的行为保持可见性，因为它们有时候会做出偏离预期的举动。
警惕“智力”与“经验”的混淆：Fulton 指出，很多重大失败的根源在于公司对 LLM 期望过高，在没有验证的情况下盲目信任。LLM 也会犯低级错误，缺乏特定领域的深层背景。
保留“人工审核 (Human-in-the-loop)”：无论 AI 给出的建议多漂亮，在投入生产环境前，人工审查依然是必不可少的环节。
拆解复杂任务：Fulton 发现，当 LLM 处理的信息量超过其上下文窗口的限制时，就容易“胡言乱语”（即幻觉）。因此，在实践中，与其让 AI 运行一个漫长的自主流程，不如将其拆解成一个个简短、边界清晰的任务，这样得到的结果反而更可靠。
严控“影子 AI”：员工私自使用不受监管的 AI 工具会带来巨大的安全隐患。可以通过强制培训、严格的审批流程以及提供丰富的官方 AI 工具来降低这种风险()。
为什么很多 PoC 项目最终无疾而终？
目标错位：Talasaz 认为，当负责执行试点的人和期望看到结果的人目标不一致时，项目很容易失败。必须在最开始就明确试点的目的是什么：是为了探索实验，还是要获得确定性的业务成果？
算好经济账：Gupta 提到一个案例，有公司在没有进行财务评估的情况下就贸然启动了项目。结果在详细分析后发现，AI 带来的收益根本覆盖不了前期的投入和后续的运营成本。在砸钱之前，务必进行严谨的财务分析。
容错率的考量：金融等行业对准确率的要求极高，99% 的成功率在某些业务场景下可能毫无价值，因为那 1% 的错误足以毁掉所有的信任。
规模化难题：工程师搭建的 PoC 在小范围内可能很完美，但放大到整个企业时，可能会面临人才、基础设施或成本的巨大瓶颈。
团队连贯性：如果 PoC 结束后，原班人马撤离，新团队接手，很容易造成知识断层和项目延期。Talasaz 建议最好由同一个团队将项目从 PoC 推进到生产阶段。
设定硬性指标：Gupta 建议设定明确的里程碑，例如通过用户模拟测试，或者必须达到某个准确率阈值，才能进入下一阶段。
恭喜你，项目终于上线了！但别高兴得太早。
警惕运营风险：关注模型漂移等持续性问题，同时也要防范更深层的风险，比如被单一供应商锁定（API、数据湖等）。
管理技术债务：Gartner 预测，未来几年很多企业将面临 AI 升级延迟和维护成本飙升的问题。这就要求我们在设计阶段就考虑长远，采用开放标准、模块化架构，并严格执行 IT 生命周期管理规范，如维护 AI 注册表、实施漂移监测等。
正如 Talasaz 所说，AI 项目要想成功，细节决定成败()。你必须深入到业务的最细微处，从上至下理解业务成果，从下至上夯实技术基础。
最后，借用 Fulton 的一句话与大家共勉：“有时候不是永远不行，只是还没到时候。” 如果某个工具或方案目前行不通，别急着全盘否定，也许只是时机未到，不妨等几个月后再试试，也许就会迎来爆发式的增长。
Tips：技术名词速览
CoE (Center of Excellence)：卓越中心。在企业中，通常指由跨部门专家组成的团队，负责在特定领域（如 AI）推广最佳实践、提供指导和支持。
LLM (Large Language Model)：大语言模型。一种基于深度学习的人工智能模型，能够理解和生成人类语言，如大家熟知的 ChatGPT 背后的模型。
Agent：智能体。能够感知环境并自主采取行动以实现特定目标的 AI 系统。
PoC (Proof of Concept)：概念验证。在项目全面展开前，为了验证某个概念或理论的可行性而进行的小规模实验。
正文：企业AI项目为何停滞——以及CIO们能做些什么
在过去一年启动了AI（人工智能）项目但未达到预期，甚至完全失败的CIO（首席信息官）并不孤单。根据Gartner（高德纳）的研究，对AI项目的投资激增，但近一半的企业难以证明其商业价值。Regions Bank的首席数据与分析官Manav Misra（马纳夫·米斯拉）表示：“人们带着不切实际的期望投入其中，这就是最大失望的来源。”他和许多其他从业者表示，技术不是问题，问题在于围绕技术的一切。组织、运营和结构上的失败在项目推进的每一步都导致项目脱轨。
图源：Kylbabka / Shutterstock
虽然CIO的团队可能在模型选择、平台架构和数据管道方面目光敏锐，但在许多情况下，选择了错误的项目，业务成果和成功指标的定义不够细致，与业务领导者的协作水平不足，或者从一开始就没有让用户参与进来。
AI项目也可能受到用户的恐惧、不确定性和怀疑的困扰。银行业技术提供商Jack Henry的首席数据官Keith Fulton（基思·富尔顿）表示：“我们曾因培训海外替代员工而获得报酬，现在我们又因培训AI来取代我们而获得报酬。” 至少就目前而言，现实情况是，虽然LLM（大语言模型）可以提高生产力，但它们需要用户对输出进行审查和验证。他说，AI就像需要指导的聪明实习生。
Colonial Pipeline前首席技术与数据官Afshean Talasaz（阿夫谢安·塔拉萨兹）补充道：“过去的方法手册已经不再有效。你需要深入研究这些事情的细节，弄清楚你想要做什么，并明确你的期望。”
不要让这些非受迫性失误成为你下一个AI项目的致命弱点。
一、停止独自领导AI项目，开始共同领导
FTI Consulting的高级董事总经理兼人工智能与数字化转型业务负责人Sumeet Gupta（苏米特·古普塔）表示，如果你要求CIO独自运营一个AI CoE（AI卓越中心），这几乎从来都不是成功的秘诀。他说：“CIO最终可能经常从平台导向视角推动项目，而大多数问题并不在于此。”因为这些不是技术项目，而是碰巧使用AI来实现期望业务成果的业务项目。“你需要与所在企业中合适的业务负责人共同领导这个项目，因为只有这样才能解决基本的业务问题。”
Fulton（富尔顿）对此表示赞同，他说AI项目需要由业务部门来领导。“业务领导者首先发现机会，然后AI专家可以帮助他们对这些可能性进行分类，以确定哪些应该列入候选名单，”他说，并补充说在这一步不要依赖顾问，“你需要一个内部合作伙伴，他会让你保持谨慎。”
Fulton（富尔顿）很早就吸取了这个教训。“唯一失败的实验是一年前的一次咨询合作，该合作变成了在财务部门使用AI进行的一次盲目探索，当时基于这项技术未能找到任何有用的案例。”
另一方面，Misra（米斯拉）的团队中有来自业务部门的产品经理，所以他们对业务需求有清晰的了解。他们与业务领导者会面，帮助他们确定可行的机会。“你需要一位愿意为价值做出承诺并投资进行正确构建的执行发起人，并且业务负责人必须清楚成功的真正样子，”他说。
二、业务所有者应设定成功指标
CIO应在前期与业务领导者合作，确定并就哪些指标决定在解决期望业务成果方面的成功达成一致。业务和技术团队都应每季度审查这些指标。
Gupta（古普塔）表示：“对该业务负责P&L（盈亏）的人应该负责对此进行衡量，并确定指标应该是什么。CIO可以就如何衡量发表意见，但将纳入盈亏的业务指标应该始终由负责盈亏的人来确定。”但要取得成功，你需要的不仅仅是管理层的认可。
三、用户需要参与其中，否则他们不会支持
如果员工不使用这项技术，任何IT项目的最佳计划都将毫无意义，这对于AI来说尤其如此。Gupta（古普塔）回忆起一家公司的一项举措，他们投资围绕一个AI模型构建了一个包装器，但最终没有带来任何独特的商业价值。“CoE（卓越中心）的AI团队认为开发这个会很有趣，但没有让更广泛的用户群体参与到这些讨论中，”他说。
Fulton（富尔顿）补充说，人们对AI存在恐惧和怀疑。他说：“让人们将其视为助手而非替代品，在组织转型管理方面这是一个巨大的挑战。但是，例如，虽然AI可以提出建议，但在向客户交付任何东西之前，人工审查是一个必不可少的验证步骤。”
这就是为什么用户需要从一开始以及在过程的每一步都参与进来。Gupta（古普塔）说：“我无法告诉你我经历过多少这样的案例，技术团队构建了一个能做所有这些事情的AI产品，但业务用户却没有使用它，因为他们没有参与到这个过程本身。在转型中，尤其是涉及技术时，这种情况永远不会成功。”
Misra（米斯拉）回忆起一个业务部门，他们最初没有获得所需的认可水平，这减缓了部署速度。“有人会说他们不确定它是否会起作用，这就会引发一个怀疑的循环，”他说。他建议确定并支持早期的拥护者，为他们的同事创建研讨会，并分阶段推出，同时每季度衡量使用情况和采用率。
从最早阶段就与用户接触还有另一个好处，即转型不会让人感觉那么大，因为他们看到它是逐步发生的。在Jack Henry公司，Fulton（富尔顿）非常重视指导。他说：“我们有一个十人的团队来帮助人们使用这些工具。如果我们以正确的方式引导他们，我们可以赢得他们的支持。但如果不适合，我们不会强迫他们。”
Gupta（古普塔）表示，最终，你需要转变用户的态度，并让他们作为过程的一部分承担责任。这意味着让他们参与讨论AI可能如何影响工作流程以及应如何解决任何必要的变更。
四、全面考虑工作流程和变更管理的影响
在使用AI进行自动化之前，CIO和利益相关者应该审查当前和计划中的工作流程，以及它们将如何影响生产力和员工的工作方式。Gupta（古普塔）说：“工作流程重新设计和变更管理是相辅相成的。例如，一家公司的一个AI产品很长时间都没有被使用，因为他们没有围绕它进行任何变更管理。”
该公司设计了一个相当复杂的AI智能体工作流程，以消除大量的手工劳动，并提高其业务运营关键部分的流程准确性。但是，为了使工作流程得到正确采用，他们必须解决一些与劳动力相关的运营模式和变更管理问题。他补充说：“这没有及时完成。所以，虽然AI工作流程本身构思良好且开发得当，但在几个月的时间里都没有得到有效利用。”
他将他所谓的“第一性原理”应用于每个项目：了解你试图通过工作流程解决的问题、期望的结果以及你的输入是什么，然后重新思考在未来使用人工智能时它可能如何运作。他说：“你必须根据这些限制进行设计。围绕AI缺乏重新发明或重新想象是首要问题。”这需要与业务领导者和用户都进行接触。
Jack Henry公司的Fulton（富尔顿）有不同看法，他认为一开始不要重新设计所有东西，而是从任务自动化开始并在此基础上构建。“业务流程再造已经存在20年了，但从未充分发挥其潜力，”他说，因为这很昂贵，而且大公司即使没有数千个，也有数百个业务流程。他补充说，如今，智能体AI在更简单的业务流程上比在更复杂的业务流程上效果更好。
也就是说，智能体开始理解业务流程并对其进行优化。“与其使用机器人RPA（流程自动化）工具构建工作流程图，你只需告诉LLM步骤应该是什么，它就会为其确定自己的工作流程，”Fulton（富尔顿）说。然而，能够在无需大量人工配置的情况下自主优化复杂的多步骤企业工作流程的智能体仍处于早期阶段，尚未在大规模应用中得到验证。
然而，如果没有对数据要求的正确理解，即使是最善意的工作流程设计和组织转型管理计划也可能行不通。
五、数据准备焦虑使项目陷入瘫痪
关于在启动AI项目之前要准备好所有数据的传统观念可能会在项目开始之前就阻碍项目进展。“许多公司认为如果没有数据，项目就行不通，”Gupta（古普塔）说。但并非所有项目都需要原始纯净的数据。公司常常会在与实际用例不相关的数据问题上栽跟头。
“对于机器学习模型来说，数据是一个大问题，但对于大多数大语言模型来说并非如此，”Fulton（富尔顿）说，除非项目专注于复杂的预测、客户级别的个性化或销售线索评分等方面。但如果在这些情况下需要数据，Misra（米斯拉）说要确定项目所需的特定数据，并只专注于这些数据，这样由于基于AI的数据清理、集成和准备工具，你所面临的数据问题就会更容易解决。
然而，Gartner杰出副总裁分析师Avivah Litan（阿维瓦·利坦）表示，有很多合理的数据问题确实应该让人停下来思考。这些问题包括数据质量、元数据和数据溯源方面的差距，这些差距会妨碍合规性、可解释性和监管报告，以及孤立的数据集和不成熟的元数据管理，这些都会阻碍监管准备工作。
六、AI可能很聪明，但并不总是可靠
Talasaz（塔拉萨兹）说，在编排和可观测性方面，治理是一件大事。他说：“智能体可以做它们原本不打算做的事情，你需要对此有可见性。”
Fulton（富尔顿）补充说，重大失败的根本原因是公司对LLM期望过高，并且在没有验证步骤的情况下就信任它们。他说，LLM会遇到问题、犯愚蠢的错误，并且缺乏特定领域的背景信息。“在评估输出时，不要将智能与经验和背景混淆，所以在投入生产使用之前，每个AI输出都需要人工审查，”他说。
对于更复杂的任务，当LLM处理需要比可用的上下文窗口所能处理的更多背景信息的问题时，它也可能会迷失方向。在那个时候，所有内容都会被压缩以适应，LLM可能会失去节奏并开始产生幻觉。“LLM可以做很多这样的事情，但它们越大，就越容易失去头绪，”Fulton（富尔顿）说。他发现，在实践中，较短、更有边界的任务比较长时间运行的自主流程产生更可靠的结果，他也相应地构建了Jack Henry公司的AI使用方式。
失败也可能来自意外出现的未经批准的项目。Talasaz（塔拉萨兹）说：“对于影子AI，人们担心的是有人以不受监管的方式为关键工作流程构建东西。然后当它出错或损坏时，就没有可观测性，给组织带来可持续性挑战和风险。”
虽然Gartner的一项调查显示，69%的组织怀疑或有证据表明员工使用了被禁止的AI工具，但Jack Henry公司已经采取措施，通过强制性培训和审批流程来维持严格的数据治理，以尽量降低这种风险。公司政策严格禁止未经批准的工具，如公共聊天机器人，并且公司提供了100多个基于AI的应用程序，希望用户不会觉得有必要去使用其他工具。
七、太多PoC（概念验证）过早夭折
Talasaz（塔拉萨兹）说，当运行试点项目的人员与期望从项目中得到不同结果的人员之间存在脱节时，试点项目可能会失败。“要清楚试点项目的预期目的是什么，无论是更多地用于实验，还是在获得预期结果方面有高度确定性，” 他说。
一些试点项目在没有完全理解其商业利益的情况下就推进了。Gupta（古普塔）回忆起一家公司，该公司在没有对项目的商业价值进行适当经济分析的情况下就启动了一项AI计划。他说，这是一个重要的立项决策节点，应该在构思AI用例之后、企业投入资金之前进行。“当我们介入并进行财务分析时，我们发现AI计划的一次性和持续运营成本将超过预计节省的中位数，”他说。
其他项目则达不到要求。试点项目可能90%的时间都能正常运行，而要达到99%的成功率可能需要六个月的时间来调整和清理数据。但像Jack Henry这样的金融服务企业要求100%的正确性，Fulton（富尔顿）说。“一个99%的时间都能正常运行的业务流程自动化工具是没有价值的，”他说，因为仅仅一个错误就可能失去业务领导者的信心，让试点中途夭折。
人们经常发现，工程师构建的PoC在规模化时不起作用，或者规模化成本过高。“你可以构建一个PoC，但可能没有合适的设计和工程人才或基础设施来对其进行规模化，”Talasaz（塔拉萨兹）说。
另一个潜在的挫折是时间问题。一旦试点项目结束，原来的团队通常会回到他们的日常工作中，把他们的知识也带走，而新的团队会接手，这可能会减缓项目的进度。“我希望由同一个团队将项目从PoC推进到生产阶段，”Talasaz（塔拉萨兹）补充说。Gupta（古普塔）建议设定明确的“存活证明”里程碑、对智能体工作流程进行用户模拟，以及PoC在进入下一阶段之前必须达到的准确性阈值。“如果没有合适的人员参与和正确的里程碑，这就是这些试点项目被搁置的原因，”他说。
八、实现了生产，但运营可持续性不确定
你的试点项目现在已经投入生产，并且目前运行良好。那么如何保持动力呢？“如果大多数团队在将项目投入生产时遇到困难，他们就没有充分考虑可持续性问题，但你必须考虑到这一点，”Talasaz（塔拉萨兹）说。
监测诸如模型偏移等持续的运营问题很重要，但像厂商锁定风险和不断增加的技术债务等更基本的问题也很重要，这些问题可能会延迟未来的升级并增加升级成本。如果在设计和试点阶段没有考虑到这些问题，那么在进入生产阶段时这些问题可能已经难以根除。
Gartner警告不要让你的数据、模型或工作流程被锁定在单一供应商的API（应用程序编程接口）、数据湖或平台工具中。相反，应遵循开放标准，并在人工智能堆栈设计中使用开放API和模块化架构。至于技术债务，Gartner预测，在未来四年内，50%的企业将面临AI升级延迟以及由于未管理的生成式AI技术债务而导致的维护成本上升的问题。它建议企业维护一个AI注册表、强制执行模型卡片、实施漂移监测，并要求供应商提供模型变更通知。换句话说，应用与任何其他IT项目相同的IT生命周期管理规范。
九、细节至关重要
AI项目有很多需要弄清楚的地方，但Talasaz（塔拉萨兹）说，成功的关键在于细节工作，不仅是在数据、治理等技术方面，还在于业务中的实际运作方式。他说：“深入了解工作的具体内容。从期望的业务成果向下推进，从技术基础向上推进。”
如果技术是问题的一部分，也不要放弃这个想法。可能只是时机不对。Fulton（富尔顿）说：“去年我们为开发人员尝试了几种不同的代码辅助工具，它们无法在像我们这样大的系统上运行。”但八个月后，团队再次尝试了相同的工具，现在采用率呈爆发式增长。“有时候不是永远不行，只是还没到时候，”他说。
