麦肯锡 2026 年 8 月 25 日发布的全球 AI 调查里有一条容易被忽略的数字。32% 的受访企业说，因为可以用 AI 编程代理自己搭，他们放弃采购了至少一款软件或者某项功能。同一份调查里，大约五分之一的企业表示，AI 的运营成本已经开始限制使用。八成受访者说 AI 提升了自己的工作效率。
这三条放在一起，指向同一个变化。企业软件的钱，正在从采购预算流向自建预算，而自建的成本结构跟采购完全不同。
采购软件的成本很清楚，一次性许可或者年度订阅，加实施费，加维护费。财务能预算，CFO 能审，三年总成本可以算出来。
自建的成本结构是另一回事。开发本身可能很便宜，一个业务人员配上编程代理，两周能做出一个能用的工具。真正的成本在后面，谁维护、谁改需求、谁保证它不出错、数据放哪、权限怎么管。这些成本不体现在项目立项书里，会出现在第二年的 IT 支持工单里。
这就是为什么很多公司自建了一批小工具，一年后没人维护，数据散在各处，最后又要回到采购。钱花了两次。
要把这条路走通，预算科目得改。改法有三个动作。
第一个动作是把自建项目的预算拆成两段。开发段和运营段。开发段可以小，运营段要按年计，包含维护人力、数据管理、安全审查。立项时两段一起批，只批开发段的项目，第二年一定烂尾。
第二个动作是给每个自建工具指定一个产品负责人。这个人是业务负责人。他负责说清楚这个工具解决什么问题、谁在用、什么时候可以停。没有产品负责人的自建项目，本质上是个人项目，不应该占用公司预算。
第三个动作是设一个退出机制。自建工具上线时就要写清停用条件，例如使用人数低于多少、维护成本高于采购多少、业务场景消失。写清停用条件，公司才敢多试。
还有一条预算规则值得加。自建项目的开发费用不要从业务部门的年度费用里出，从集团的数字化预算里出。业务部门出钱做的工具，会天然排斥其他部门使用，最后每个部门一套，全公司的数据口径就散了。
做错的样子很典型。业务部门提需求，IT 排不上期，业务自己找人用 AI 搭了一个。跑起来很顺，用了半年，做的人升职或者离职，工具还在跑，没人敢改。再过年，数据口径跟集团不一致，财务不认，最后废弃。整个过程没有人做错，是制度没跟上。
这件事对董事长层面的意义，比工具本身大。当业务部门能自己造工具，IT 部门的角色就从交付者变成平台与规则的提供者。这个转变如果不做，IT 会被绕开，公司会积累一堆没人管的系统。
能带走的是一张自建评估表，四问。
这段业务规则是不是我们独有的。独有的是自建的理由，通用的是采购的理由。
规则写得清不清楚。写得清，自建便宜。写在老员工习惯里，自建会很贵，因为要先把规则挖出来。
谁来维护。有名有姓，且这个人的考核里包含这件事。没有，就不要建。
三年总成本多少。把开发、维护、数据、安全、培训都算进去，与采购方案比。
四问里有两问答不上来，就走采购。这是算账。
麦肯锡那份调查里还有一条趋势值得放在预算会上看，大企业里规模化使用 AI 的比例远高于中小企业。规模优势的一部分，正在变成“自己造工具的能力”。这个能力属于管理能力，包含规则、责任、预算三件事。
对百亿级企业来说，真正的风险是买了一堆用不起来，或者造了一堆没人管。两种浪费的金额可能差不多，后者更难发现，因为它分散在各个部门的小项目里。
每年预算会，把自建项目的清单单独拉一页，写上产品负责人、年运营成本、停用条件。这一页纸，能省下的钱通常超过任何一次采购谈判。