关键讯息，D1时间送达！
企业网D1net
AI让人人都能构建解决方案，却不意味着人人都能判断什么值得做、什么风险可控。随着技术能力普及，企业真正的挑战已从开发速度转向战略取舍、责任治理与架构整合。技术部门必须守住三项核心职责：判断什么值得构建、让治理成为加速器、打造安全可靠的数字化基础。未来的竞争，不只在于谁能更快使用AI，更在于谁能将AI转化为持续增长的力量。
在AI时代，有三件事不会因为技术能力的普及而变得不再重要。企业需要重新认识它们，并采取相应行动。
在过去近三十年的大部分时间里，技术部门的权威建立在一个简单的事实之上：它掌握着其他部门不具备的能力。如果业务部门需要软件，就会找IT部门，这种格局如今已不复存在。现在，市场营销团队只需利用三个AI工具——其中甚至可能包括IT部门从未评估过的工具——就能在一个长周末里搭建出一个可以运行、面向客户的原型。到了周一早上，首席营销官(CMO)就可以进行演示。
人们通常认为，AI对技术组织的影响在于让工程师的工作速度更快，但更具深远意义的变化是：整个企业都变得更有能力了。在一项针对2万名知识工作者的调查中，58%的AI使用者表示，如今他们能够完成一年前还无法完成的工作。
其中许多人在构建解决方案时，不会过多考虑这些成果最终需要运行于怎样的现有技术环境，与此同时，技术部门的绩效衡量标准仍然是系统正常运行时间和服务成本，而且它正日益被要求为整个组织中种类繁多、不断扩张的AI工具组合承担责任。
日益增长的风险在于，技术部门可能被彻底绕过，核心技术决策逐渐转移到那些自认为已经具备足够技术能力、因而可以自行作出决定的人手中，即便他们并不具备作出这些决定所必需的背景信息和整体视野。
随着AI领域不断演变，越来越多的人以前所未有的速度参与技术相关的讨论，CIO的角色也随之发生变化：他们需要拨开纷繁复杂的信息迷雾。新的职责不再局限于制定合理的技术战略，还包括更加清晰地界定方向，以严谨的标准和审慎的判断，明确AI究竟能够在哪些领域推动增长。
由CIO主导的举措应当着眼于借助AI持续放大企业的增长效应，而不是任由一系列代价高昂的试验分散组织的注意力、不断增加组织的臃肿程度，让一个本已高速运转的组织背负更多负担。
发生了哪些变化
构建能力大幅提升，IT的关注重点从速度转向价值
技术能力的提升使团队能够显著增加产出，但产品管理、设计、治理以及利益相关方之间的协调，并没有以同样的速度发展。
制约因素已经从“能不能把东西做出来”，转变为“能不能就应该做什么达成共识”。
为了解决这个问题，我们看到，一些组织增加了产品经理，帮助梳理和合理化需求，另一些组织则将产品判断的责任下放给工程团队，而这往往又会演变为关于任务执行顺序的讨论。有些公司甚至同时采取这两种做法，这恰恰说明，真正需要解决的问题从未得到明确的答案。
自动化已经深入价值链，但责任归属问题始终没有解决
1979年，一句广为流传、通常被归于IBM的话指出：“计算机永远无法被追究责任，因此，计算机永远不应该作出管理决策。”
将时间快进到近半个世纪后的今天，系统已经能够生成备选方案、执行不同变体并分析结果，其速度之快，过去即使是称职的分析师也可能需要花费数天才能完成同样的工作。
但系统仍然无法做到的一件事，就是对最终结果承担责任。
模型可以给出建议，但当监管机构提出质询时，不能由模型的名字出现在决策责任人的位置上。
随着自动化不断向价值链上游延伸，相关工作并不会消失，而是逐渐集中到两个方面：作出决策，以及为决策结果作出解释并承担责任。
AI自动化首先是一个技术与数据问题，而技术领导者最有条件判断哪些决策可以安全地交由模型作出。
SaaS应用的清理整顿，首先是架构问题，其次才是成本问题
过去十年间，SaaS工具不断扩张，导致大多数企业拥有大量功能重叠的应用程序，以及彼此割裂的数据。面对这种局面，人们很容易想到把应用整合和清理的工作交给采购部门，再将节省下来的费用计入收益。
但在当前环境下，这种做法可能代价高昂。
原因在于，同一套支离破碎的技术环境，不仅推高了软件许可证的支出，也会降低企业级AI的实际表现。
一个AI智能体的能力，取决于它能否就某个客户获取一致、可靠的信息。而在大多数企业现有的技术环境中，根本不存在一个能够始终如一地提供一致答案的数据基础。
如果继续累积彼此缺乏协调的新AI解决方案，就有可能在本已碎片化的基础之上，进一步加剧技术工具和系统的无序扩张。
单独来看，这三个问题都很常见，但当它们同时出现时，就会改变CIO及其团队开展工作的层级和视角。
IT部门的职责不再只是判断某项工作何时能够交付，而是进一步判断这项工作究竟是否值得开展。
IT部门需要识别哪些决策可以自动化，哪些决策则应当继续由人来作出。
最后，CIO团队还需要通过治理企业技术环境的演进路径，维护整个企业技术体系的完整性。
只有技术部门才能承担的三项核心职责
当整个企业的技术能力都在不断增强时，IT部门的角色也随之演变：它需要指导和建议各业务团队应该构建什么，以及应该如何构建。
IT部门可以选择亲自构建大多数解决方案，只与其他团队合作开展少数重点项目，也可以将构建工作完全分散到各个业务部门，但无论采用哪种模式，IT部门都应当掌握决定哪些东西可以进入企业技术环境的关键控制权。
优先级管理、责任归属和架构治理，对于CIO及其团队而言都不是新概念。但在今天的环境下，它们需要以不同的方式加以落实。
1. 判断什么值得构建
过去，资源稀缺本身就能形成约束和纪律：当工程团队的产能是瓶颈时，需求优先级通常通过排队机制来决定。
但现在，企业可能同时收到一系列完全合理、确实可行的需求，而且每项需求都有自己的业务负责人和商业论证，这时，就必须有人坚持判断：究竟哪些事情值得构建。
对于技术领导者而言，这是一个本质上不同的问题，它要求他们将战略和企业整体能力置于资源产能或单纯技术能力之上。
项目管理办公室(PMO)可以为项目安排执行顺序，也可以标记项目之间的依赖关系，但它通常无法识别系统之间的不兼容问题，也未必知道某项功能其实早已存在于其他系统之中。
技术部门能够看到整个局面，而这正是判断战略性项目组合所必需的视角。
尝试构建的成本低，并不意味着后续持有和维护的成本也低。
构建成本可能大幅下降，但运行、保护、支持以及最终退役某项技术资产的成本并不会随之消失。此后的每一年，都需要由某个团队持续承担这些成本，而这个团队甚至可能从未选择过这项技术。
真正的问题从来不是能不能把它做出来。
维护企业技术体系完整性的关键纪律，在于拒绝那些单独来看似乎都合理的需求。
过去，当拒绝的理由是“没有足够的资源”时，这件事相对容易。如今，当一个看起来完全可行的演示原型已经摆在眼前时，拒绝就必须建立在对需求本身的判断之上，这要困难得多。
这项职责应当由技术部门承担，因为只有从整个技术体系的全局出发，才能看清那些在局部看来合理的选择，究竟会在什么地方累积成整体失效。
应该怎么做
找出组织中哪些类型的决策最容易成为大量工作的准入关口，这些决策通常涉及数据访问权限、对既定标准的例外处理，以及将解决方案从开发或测试环境正式发布到生产环境。
建立能够指导这些判断的标准，然后授权一个跨职能治理委员会，持续、一致地应用这些标准。
大多数企业已经设有或计划设立类似的治理机构，但只有大约一半的企业建立了正式的AI工作审批流程。
因此，应当明确这一流程，并要求整个企业遵循统一的决策逻辑，无论最终的决定是批准还是拒绝。
在为大型矩阵式组织设计运营模式时，我们发现，最能推动管理层采取行动的指标之一是决策延迟时间。
由于延迟往往并不完全归属于任何一个团队，它就很难被纳入某个团队单独负责的绩效指标中。
因此，应当从端到端的流程衡量决策延迟，并将这一数字呈现给那些能够通过日程安排和资源配置影响决策效率的高管。
应该衡量什么
从提出问题到正式承诺作出决定的中位天数。
被拒绝的提案占全部提案的比例，因为如果一个治理委员会几乎批准所有提案，它实际上只是在安排需求的执行顺序，而不是在真正管理企业的项目组合。
2. 将治理转化为提升企业速度的杠杆
在许多企业中，我们已经发现，各种形式的员工自主开发AI解决方案的实践正在开展，而且往往处于无人治理的状态，甚至在组织尚未决定是否允许这些活动之前，它们就已经开始了。
IBM在2026年的数据泄露研究发现，涉及影子AI的安全事件占比在短短一年内增长了一倍以上。
CIO的职责，是确保AI试验和开发发生在可见、可管理的环境中，建立在受到支持的技术基础之上，并且能够产生可衡量的结果。
如果企业具备清晰的流程、可以复用的技术资产，以及能够帮助业务快速扩大规模的实际记录，业务部门就会有理由优先来找IT，而不是绕开IT自行行动。
这意味着，设计运营模式时，应当把快速作出承诺和决策作为核心目标。
如今，企业的整体速度取决于组织能够多快达成共识并作出承诺，但大多数公司把这当成一种文化问题，而实际上，它是运营模式本身的属性。
业务部门最直接感受到的是响应时间。
当业务团队看到某个职能部门能够在一个周末内搭建起一个解决方案时，它就会据此衡量技术部门的效率：从提出需求到取得成果，IT究竟需要多长时间？与业务部门认为自己能够独立完成的速度相比，又慢了多少？
应该怎么做
建立清晰的分级机制，根据使用场景的风险、安全性、架构影响和数据影响，对不同类型的开发活动进行管理。
明确说明业务部门可以构建什么、可以使用哪些数据，以及哪些工作必须通过技术部门的流程开展。
大多数人只需要使用已经发布、可以直接使用的解决方案，规模较小的一部分人可以基于获批的模式进行配置，而人数更少的一部分人，才需要构建能够向生产系统写入数据或执行操作的解决方案。
每个级别都应当有相应的培训要求和责任标准。
这也是划定责任边界的关键：哪些事情可以由模型自主决定，哪些事情必须由一个具体的人具名负责。大多数组织至今仍无法在审计中充分证明自己已经明确建立了这样的边界。
分级管理的目的，是通过能力建设和相应要求让团队具备进入某一级别的条件，而不是简单地授予或拒绝开发权限。
这样，工作就可以进入与其风险和复杂程度相匹配的通道，而不必让所有项目都受到同一套准入标准的限制。
接下来，应当让合规路径成为最快的路径，并为其配备组件库、参考实现、预先审核通过的连接器，以及用于评估和验证AI系统表现的测试框架。
仅仅设置防护措施并不足以维持秩序。
如果业务部门将某项控制措施感受为阻碍，它就会成为绕过该措施的理由。
而且，仅仅发布相关工具和规范也无法确保它们真正发挥作用，因此，应当把能力建设和使用指导视为正式交付这条开发路径的一部分。
应该衡量什么
新建的、由业务部门构建的解决方案中，采用规定合规路径运行的比例。
新构建的解决方案中，至少使用了一项已发布、可复用技术资产的比例。
3. 企业赖以构建的数字化基础框架
当企业中的每个人都能够构建解决方案时，问题就不再是“谁来编写代码”，而变成了“所有这些东西究竟运行在什么基础之上”。
过去，安全性、隐私保护、数据质量、自动化测试和可观测性通常是单个系统的属性，由构建该系统的人负责，而这个人往往来自IT部门。
如今，这些能力必须成为企业级平台的固有属性，由企业集中提供，并默认赋予所有基于这些平台构建的解决方案。
例如，一个基于已发布数据构建的仪表板，不应该与一个能够向客户记录中写入信息的AI智能体适用完全相同的治理策略。
但两者都需要拥有清晰的路径，以确保它们能够按照预期产生作用。
架构一致性也应当在这里得到保障，这样，无论是在仪表板中，还是在自主运行的AI智能体中，同一个客户标识符都能始终保持一致的含义。
如果缺少这样一套基础框架，当业务部门开始自行构建解决方案时，IT部门的瓶颈并不会消失，只会转移到其他环节。
那个原本已经准备好在周一演示的原型，可能需要等待三个月，才能完成安全审查、隐私评估、数据质量修复，以及编写最初根本没有人考虑过的测试和监控机制。
技术部门再次成为瓶颈，只不过这一次，瓶颈出现在开发周期的后期，更容易被所有人看见，而且比起在任何东西尚未构建之前就排起的需求队列，这时业务部门对IT的耐心通常也更少。
应该怎么做
建立适用于业务部门所构建的所有解决方案的身份认证和访问控制模式。
针对最重要的数据领域，设定明确的数据质量门槛。
在编写测试时，应当假定部分代码可能由机器生成，而不是完全依赖传统的人工编写代码的开发方式。
建立覆盖AI智能体和应用程序的可观测性机制。
同时，将这些措施与治理工作中确定的分级体系对齐，使投入的资源和控制措施与项目的实际风险和规模相匹配。
同样的基础框架也应当适用于需要退役的系统，因为应用整合与清理决策，不仅应当降低软件许可证费用，还应当减少整个技术架构的复杂性和维护负担。
接下来，应当为这套基础框架配置适当的资源。
在需要专业判断，或者必须有人承担责任的地方保留人工参与，其余可以自动执行的工作，则交由系统运行。
如今，真正稀缺的资源已经不再是构建能力，而是审查能力。
知识工作者已经将审查列为AI时代重要性提升最快的技能之首。
最后，应当主动培养具备审查能力的人才，因为过去那些帮助员工积累相关能力的重复性工作，现在正逐渐被自动化。
如果组织只是把这项工作留给人才战略部门，而不将其纳入运营模式设计，那么三年之后，就会发现自己缺乏足够的人才储备。
应该衡量什么
默认满足生产环境就绪标准的AI解决方案占比。
在关键数据领域中，拥有唯一、权威的数据记录系统，并且所有相关系统都能通过一致的方式访问该系统的领域占比。
从书面明确技术部门的职责开始
上面讨论的大部分措施，都需要几个季度才能落实，但有一件事，这个月就可以完成。
把技术部门的职责明确写下来：哪些事情由它负责，哪些事情由它赋能，哪些事情需要与其他部门协同推进，以及哪些事情不再由它承担。
然后，与其他高管共同推动共识的形成，尽可能减少IT角色中的模糊地带。
旧有模式很简单：市场营销部门提出想法，IT部门负责构建。
正在形成的、缺乏管理的新模式同样简单：市场营销部门自行构建，之后再要求技术部门确保其安全。
但理想的目标模式应当有所不同：市场营销部门仍然可以自行构建解决方案，但必须建立在由IT部门提供支持的基础之上，从而确保解决方案安全、可扩展，并且能够得到持续支持和维护。
根据微软发布的《2026年工作趋势指数》，在AI带来的影响中，组织层面的因素——例如组织文化、管理者支持和人才管理实践——所解释的影响程度，超过了个人努力所报告影响的两倍。
无论企业是否主动推动，运营模式都将发生变化。
真正尚未确定的是：这种变化究竟会经过有意识的设计，还是在无序演进中被动发生？
对于CIO而言，未来十年将面临一个关键选择：是主动塑造企业的AI发展议程，还是仅仅执行由其他人制定的议程。
关于企业网D1net(www.d1net.com)
企业网(D1net.com)-企业 IT 第 1 门户。面向 IT 行业高端甲方人群(CIO 首席信息官)最精准专业的媒体，面向约六万政企 CIO、信息中心主任、科技部总经理等 IT 主管，提供资讯、营销、活动、项目合作推介等服务。拥有专业注册会员(IT 从业者)约 188万人，主要读者为政企用户及其信息主管、软硬件厂商等，服务过的企业级厂商逾五百家，国内toB的头部IT厂商基本都是D1net的客户。
同时，企业网D1net也运营着国内最大的CIO(首席信息官)专家智库和智力输出变现及社交平台-信众智，也是国内最大的科技高管社交平台。旗下运营19个IT行业公众号(微信搜索D1net即可关注)。
如果您在企业IT、网络、通信行业的某一领域工作，并希望分享观点，欢迎给企业网D1net投稿。
投稿邮箱：
editor@d1net.com
合作电话：
010-58221588（北京公司）
021-51701588（上海公司）
合作邮箱：
Sales@d1net.com
企业网D1net旗下信众智是CIO（首席信息官）的专家库和智力输出及资源分享平台，有六万多CIO专家，也是目前较大的CIO社交平台。
信众智对接CIO为CIO服务，提供数字化升级转型方面的咨询、培训、需求对接等落地实战的服务。也是国内较早的toB共享经济平台。同时提供猎头，选型点评，IT部门业绩宣传等服务。
扫描 “二维码” 可以查看更多详情
