企业AI战略怎么定？一页纸理清六项关键决策

企业的 AI战略要说清楚：准备改变哪些工作，期待什么结果，以及必须守住哪些边界。对于一家 10 到 200 人的公司，可以先做出六项决策，再为一项工作流程安排资源，推进接下来 90 天的试点。

董事会问起战略时，你需要给出一份可以评估的承诺：要实现什么业务结果，由谁负责，准备投入多少资源，以及出现什么证据时会停止。介绍行业趋势的演示文稿，回答不了这些问题。

什么是 AI战略？

AI战略是一组企业选择：AI 应该用在哪些业务环节，又该如何判断它的贡献。它把业务机会与资源、责任和使用边界联系起来。模型是生成草稿或建议的 AI 引擎；工作流程则包括围绕模型运转的人员、数据和控制措施。

不妨把它理解为给新同事写岗位说明书。你需要确定他要做什么，能看哪些信息，能做哪些决定，由谁检查产出，以及怎样才算表现合格。还没明确岗位职责，就开放所有系统的访问权限，显然不是好的管理方式。使用 AI 也是同样的道理。

战略决定做什么，以及接受哪些取舍；路线图安排实施进度；员工政策说明日常工作中可以做什么。三者需要衔接，也各有明确的用途。

视野也不能只停留在试点上：交付提速能否守住利润空间，会不会改变客户愿意付费的内容，或者让新的服务模式成为可能？AI 原生公司指南探讨了这类运营模式的变化。眼下的战略，应先验证其中一个具体环节。

AI战略案例：服务公司和软件公司怎么选？

战略怎么定，取决于哪个工作环节限制了业务。服务公司可能需要提高产能，为符合筛选条件的商机出具方案；软件公司可能需要帮助客户顺利完成初始配置，也就是成功用上产品。

下面以一家 30 人的服务公司和一家 80 人的软件公司为例。这两家公司的情况、工作量和资源安排都只是规划示例，不是客户实绩，也不是业绩预测。软件公司的例子中，“导入映射”指的是将客户文件中的字段与应用中的字段一一对应。

只有把每一行背后的工作内容、判断依据、负责人和边界写清楚，这些选择才构成战略。

AI战略框架：先做出六项决策

启动实施之前，先用业务语言把决策说清楚。每项决策都应能浓缩成一个短段落，支撑材料则以链接形式附在一页纸决策记录中。

1. 选定工作流程，明确它影响哪项成本或收入

选择一个会影响现有成本或收入科目的瓶颈。只说“提高生产力”，就无法分清一个项目究竟有用，还是工具本身很受欢迎。

梳理候选流程，从触发条件一直画到结果验收。标出实际耗时、等待、返工，以及由谁判断工作已经完成。再从业务价值、发生频率、数据可用性、质量能否检查、出错后果几个方面比较候选项。即使潜在收益很大，只要缺少负责人或所需数据不可用，就不应启动试点。

**服务公司：**先从提案起草入手，输入采用已获批准的客户需求简报和可复用的服务说明。对应的财务指标是每份合格商机提案投入的销售工时；另一个假设是，更快提交提案有助于赢得项目。两种判断不同，需要分别衡量。

假设公司每月准备 20 份提案，每份耗时 3 小时。如果 AI 辅助起草、审核和修改合计需要 1.5 小时，理论上可释放的产能为：

20 × (3 - 1.5) = 每月 30 小时。

这只是一个有待验证的情景。只有把腾出的时间用于争取有价值的商机、避免一笔支出，或改善交付的成本收益关系，才会形成财务价值。它不会自动降低薪酬支出，也不会自动提高赢单率。

**软件公司：**先处理客户文件中不统一的字段名称，再根据客户的配置需求准备检查清单。对于固定、熟悉的文件格式，继续使用常规导入规则。对应的成本是客户上线所需的人力；收入方面的假设则是，减少配置延误有助于客户更快获得首次有用的结果。

假设每月处理 40 次客户上线任务，每次耗时 90 分钟。如果包括检查和修改在内的总耗时降至 60 分钟，该情景下可释放：

40 × (90 - 60) / 60 = 每月 20 小时。

客户是否完成上线、之后是否继续使用，要单独衡量。内部准备工作变快，并不能证明客户留存改善。

写下决策：“我们将改进[工作流程]，以改变[业务指标]；对照[当前基线]衡量结果，同时守住[质量要求]。”AI 投资回报指南介绍了如何将观察到的流程变化，换算成有据可查的价值。

2. 明确 AI 可以不经审批做什么

如果出错可能形成对客户的承诺、泄露信息，或改变客户数据，就先采用辅助模式。辅助模式是 AI 准备建议，由人决定是否采用；自动化则是系统执行一项已定义的操作，无须逐次审批。

自动化应采用更严格的准入标准：结果能够可靠检查，后果能够控制，操作能够撤销。这些只是初筛条件，全部满足也不能替代成功的试点和明确的负责人。如果软件和具备相应能力的人员都无法检查输出，就应暂缓这种用途。

**服务公司：**AI 可以起草文字、找出缺失信息。客户负责人审批服务范围、交付承诺和最终提案。试点期间，系统不能发送提案、签署任何文件，也不能修改商业条款。相比协商文件内容，把已获批准的文档归档到正确文件夹，可能更适合作为后续自动化的对象。

**软件公司：**AI 可以建议将客户文件中的“Company”字段映射到应用的“Organization”字段。客户上线专员检查映射关系，常规软件校验必填字段和格式。实际执行导入、修改生产环境记录，仍需遵循现有审批流程。在检查和恢复机制得到验证后，可撤销的预发布环境配置操作，才可能适合自动化。

区分风险的关键是错误会造成什么后果，而不是界面看起来像不像聊天机器人。没有执行能力的草稿，与接入了写入操作的系统，运行边界完全不同。

写下决策：“AI 可以[准备或执行此操作]。[这些操作]必须由指定人员审批。系统绝不能[禁止的操作]。”

3. 选择自建、采购，还是配置现有应用

标准能力能满足要求，就直接采购。对于能体现流程特点、且公司有能力持续维护的部分，再考虑自建。如果现有应用已经适合这项工作，只是需要接入经过批准的文档、规则或系统，就采用配置方式。

“自建”不等于训练模型。你可以购买模型访问服务，再搭建外围流程：信息怎样进入模型，建议怎样检查，用户怎样审批操作。

用同一套验收条件比较这些路径：能否保留权限控制，展示审核者需要的证据，导出记录，并支持回退方案？比较时，也要计入集成、评估、员工培训、事件处理和日常维护。一个没有运行负责人的原型，不能算赢得了“自建还是采购”的比较。

**服务公司：**如果起草应用能遵守公司的数据边界和审核流程，就采购并配置它。经过批准的资料库和提案检查清单应保持可迁移。产品如果无法满足客户数据的使用限制，再漂亮的演示也无济于事。此时应减少使用的数据、改换路径，或者暂缓。

**软件公司：**购买模型访问服务，再自建面向各客户的字段映射界面、授权检查、数据校验和审批记录。这些部分应与产品紧密结合，因为它们承载着这款应用特有的客户上线逻辑。模型连接应保持可替换，避免更换供应商时还要重建整套上线流程。

当标准产品无法满足一项有价值的需求，而公司又能负担定制方案的长期维护责任时，选择才应转向自建。想拥有自己的 AI 品牌，不属于这种需求。

写下决策：“我们选择[采购／配置／自建]，因为[具体要求]。由[负责人]负责维护，并通过[退出路径]确保流程可以恢复运行。”

4. 明确每种用途需要哪些数据和权限

每种用途只应获得完成任务所需的信息和权限。“接入公司数据”过于笼统，不能作为授权依据。

记录数据来源、允许使用的人、流程所需的字段，以及维护人。明确哪些内容可以发给供应商，能否被保留或用于训练，如何删除，以及日志中保留什么。使用公司数据前，应根据所选服务当前的条款和控制能力核实这些要求。获准订阅某项服务，不代表可以上传所有文档。

读取和执行也要分别决策。Open Worldwide Application Security Project（OWASP）关于过度自主性的指导建议限制功能和权限，对影响重大的操作要求审批，并在下游系统中执行授权检查。告诉模型“不要访问其他客户”，不能替代应用本身对这类访问的阻止机制。

**服务公司：**使用当前客户已获批准的需求简报、经过批准的服务说明，以及获准复用的案例。排除其他客户的保密提案和员工私人笔记。仅向获授权的客户团队成员开放访问。草稿中的事实性表述应注明来源，方便审核者核查；没有依据的内容应退回修改。

**软件公司：**使用当前客户的字段名，以及理解映射关系所必需的最少量示例值。对非必要的个人数据做脱敏处理。在当前客户账户的权限范围内检索信息，搜索索引也不例外。不要把身份验证密钥或其他客户的记录放入模型上下文。试点只能提出映射建议，没有更新生产环境记录的权限。

两家公司都应测试应被拒绝的请求、来源缺失和来源过时的情况。只有成功回答，无法证明边界有效。

写下决策：“本用途可为[获授权用户]读取[来源和字段]，遵循[保留规则]。仅允许写入[目标位置或无]。变更由[数据负责人]批准。”

5. 将结果和风险落实到具体负责人

CEO 对公司的战略选择负责；流程负责人对改变在实际工作中是否有效负责；技术人员负责实施层面的控制措施。审核者必须具备拒绝输出所需的专业能力、时间和权限。

National Institute of Standards and Technology（NIST）的 AI 风险管理框架核心内容将风险工作分为治理、映射、测量和管理。它要求高管对 AI 风险决策负责，明确监督安排，并建议在部署前和运行期间开展测试。这些都应视为持续责任。

本文引用的 NIST 和 OWASP 指导，已于 2026 年 10 月 26 日对照其一手文档核实。六项决策结构和公司案例，是本文为实际应用所作的归纳，不是认证框架。

**服务公司：**销售总监对提案周转时间和质量负责。客户负责人审批服务范围和对客文档。运营负责人管理访问权限及经过批准的资料来源。CEO 决定剩余风险是否可接受，以及是否让更多工作进入这套流程。

**软件公司：**客户成功负责人对客户上线结果负责。指定工程师负责授权、校验、监控和恢复。客户上线专员审核建议。产品负责人决定内部试点是否已达到向客户发布的条件，CEO 则对公司的整体风险状况负责。

在小公司，一个人可以兼任多个角色，但各项职责仍需明确。记录谁有权暂停流程，谁处理事件，谁可以批准重启。指定了审批人，却没有给他检查证据的时间，等于这项控制措施没有人落实。

更全面的控制措施记录可参考 AI 治理框架，员工日常操作规范可参考 AI 可接受使用政策。向实际执行工作的人说明新增职责，也要讲清楚系统出错时该怎么做。

写下决策：“[人员]对结果负责；[人员]审批影响重大的工作；[人员]维护控制措施；[人员]有权停止和重启流程。”

6. 设定预算、评审节奏和停止条件

先为一个范围明确的验证项目配置资源，再根据证据决定是否追加。除了现金支出上限，也要计入人员工时。即使软件已经可用，审核、修改、培训和维护仍会占用人力。

**服务公司：**示例中的试点安排为，在 90 天内投入 40 小时运营工时，用于配置、资料清理、培训和评估。常规提案审核仍需单独安排人员并衡量耗时。销售总监每周检查提案周转时间、总投入工时、服务范围修改情况，以及释放出来的产能是否得到利用。CEO 每月审议是否继续投入资源。

**软件公司：**示例安排为，试点期间投入 10 个工程人日，另加客户上线专员每周 2 小时。启用付费服务前，先向财务明确现金支出上限。这些工程工时只覆盖范围有限的内部试验；面向生产环境的功能需要另行估算。每周检查客户上线总工时、映射错误、客户完成情况，以及访问控制失效情况，由管理层每月做出决策。

两个例子都应在启动前约定以下条件：

• **扩大范围：**有代表性的工作满足预先约定的质量和权限要求；计入审核及修改后，总工时有所改善；并且有负责人能够支撑更大的范围。
• **调整方案：**方向有帮助，而且某项具体修正，例如改进资料来源或缩小任务范围，有可信的路径在剩余资源内达到目标。
• **停止：**计入检查成本后收益不复存在，所需数据无法使用，或流程无法遵守其运行边界。一旦发生未经授权的访问或操作，应立即暂停。

服务公司不应接受一个虽然更快、却会引入严重服务范围错误的流程。软件公司也不应接受一个演示更流畅、却会泄露其他客户数据的方案。产出再多，都无法抵消这些问题。

写下决策：“我们批准在[评审日期]之前投入[现金上限]和[人员工时]。出现[证据]时扩大范围，存在[可修正的差距]时调整方案，触发[条件]时停止。”

90 天行动计划：从决策走到验证

用这 90 天收集足够的依据，决定是否继续投入。走完日程，不等于获得了扩大范围的许可。下面的时间安排只是规划建议；如果缺少前提条件，项目就可能需要停留在较早阶段。

1. 1

   第 1-30 天：敲定计划，建立基线

   明确高管发起人、流程负责人、技术负责人和审核者。梳理现有流程，衡量一项工作从头到尾的投入，包括审核、修改和异常处理。用 AI 就绪度评估找出该流程在数据、权限和运行支持方面的缺口。

   服务公司应收集一组获准使用的提案需求简报、最终文档、工时记录，以及服务范围修改案例。软件公司应收集经过批准的客户上线案例、映射决策、完成记录和导入失败案例。要纳入棘手情况，不能只有顺利的演示样本。

   就六项决策、质量检查清单、人员安排和现金支出上限达成一致。告诉受影响的员工哪些工作会改变，反馈将如何使用，以及腾出的产能将投向何处。

   **进入下一阶段所需的证据：**已签署的决策页、可用的基线、获准使用的数据，以及能解释什么样的结果才算合格的审核者。如果尚未具备这些条件，就用下一阶段的时间补齐缺口。

2. 2

   第 31-60 天：开展受控试点

   先用历史案例评估拟采用的流程。另留一组不参与配置的案例，避免评估只是在奖励系统已经围绕其调整过的样本。随后在获准的边界内处理真实工作，并保留原流程作为回退方案。

   服务公司的每份草稿，在对外发出前都要审核。记录缺乏依据的表述、遗漏的要求、服务范围变更和总投入工时。软件公司则由专员审核映射建议，执行常规导入校验，并测试其他账户的数据确实无法访问。

   培训时，让用户处理一个普通案例、一个具有误导性的建议，以及一个必须上报的案例。要求他们演示如何纠正和上报问题，并观察在正常工作中是否能切实完成审核。

   **进入下一阶段所需的证据：**获接受和被拒绝的案例、实际测得的审核工时、异常记录，以及已经演示过的流程暂停方法。只有一场有说服力的演示还不够。

3. 3

   第 61-90 天：决定扩大、调整，还是停止

   将同类工作与基线比较，计入中途放弃的尝试和返工。解释案例难度或工作量的变化。如果试点规模不足以支撑某项结论，应明确说明不确定性。

   服务公司要检查腾出的提案产能是否得到利用，质量是否保持稳定。跟踪赢单结果，但不要把每项变化都归因于 AI。软件公司则要区分“专员投入减少”和“客户激活改善”；后者需要单独的证据。

   在第 90 天的评审中，决定为明确的下一阶段范围提供资金、批准一次范围受限的调整，还是结束试点。任何扩展都应针对新增用户、数据和操作，重新进行权限与质量审查。即使内部助手效果良好，面向客户的上线辅助功能仍需作为一次新的发布单独决策。

   **本阶段应留下的证据：**有记录的决策、明确承担责任的负责人、更新后的边界，以及下一次评审日期。

哪些企业可以现在开始，哪些应该等待或保留原流程？

如果工作反复发生、问题可以衡量、输入获准使用，并且有人能够检查结果，就可以开始。在这些条件下，两家示例公司都可以从小范围的内部辅助试点起步。

如果数据使用权尚未厘清、访问边界无法落实，或无人承担审核，就应暂缓在真实业务中使用。不过，准备工作仍然值得推进：测量基线、整理资料库、建立权限，并定义范围更小的任务。

如果简单规则已经能可靠解决问题，就保留现有流程。必填字段检查或固定审批规则，不需要模型重新解释。对于 AI 生成的建议，也应继续保留这些控制措施。

创始人眼下要做的是确定优先级、落实资源；运营负责人要记录交接环节和异常情况；技术负责人则要先证明检查机制和权限控制有效，再增加系统的自主执行能力。

关于 AI战略，哪些说法被夸大了？

**把全公司自动化比例当作起点，并不合适。**不同操作带来的后果不同。即使提案起草已经快了很多，继续要求客户负责人审批，仍可能是正确的设计。

**自建系统并不能消除依赖。**资料来源、模型行为、集成、人员配置和客户预期的变化，仍然需要你来应对。采购应用，也不会免除你对使用方式的责任。应该选择一条公司有能力长期支撑的路径。

**工具使用量不是业务结果。**提示词更多、账号席位更多、生成文档更多，完全可能与周转时间毫无改善、检查工作增加同时出现。应报告验收通过的工作和业务结果，并计入纠错所需的工作量。

**一页纸战略是决策记录，不能包办整套运营机制。**评估案例、访问记录、事件处置流程和实施细节，应作为背后的支撑材料保留。简短有助于管理层决策，但不会省去确保决策可靠所需的工作。

常见问题

制定 AI战略时，最关键的考虑是什么？

把拟采用的用途与可衡量的业务结果挂钩，并指定具体负责人。随后明确：在错误形成对客户的承诺、泄露数据或改变生产系统之前，如何发现它。如果没有切实可行的质量检查方法，就应缩小使用范围，或者暂缓。

一页纸企业 AI战略模板

把下面的内容复制到文档中，填入空白处。答案尽量简短，支撑记录用链接附上，不要把一页纸扩写成演示文稿。周一，CEO 和流程负责人应围绕首个拟采用的用途共同填写，再约定基线评审时间。

公司：______ 高管发起人：______ 决策日期：______
规划周期：______ 至 ______ 流程负责人：______

向董事会这样说明：“我们用 AI 改进 ______，从 ______ 开始。已批准投入 ______ 资源，并遵守 ______ 边界。由 ______ 对结果负责。我们将在 ______ 根据 ______ 证据，决定下一步投入。”

想了解如何将 AI 决策落实为可运行的业务流程，可以订阅邮件通讯。