在与企业负责人的许多交流中，我反复看到同一种起点：企业已经在使用AI。市场团队使用ChatGPT，销售团队测试自动化研究，客户服务上线了初步助手，一些员工也在自行搭建工作流。表面上看，这似乎就是进步。
但只要继续追问，另一幅图景就会出现。没有人能够明确说明哪些应用已经进入生产环境、它们使用哪些数据、谁对输出负责，以及它们创造了什么可衡量的贡献。若干有潜力的项目尚未成为一个可靠的系统。
本文通过一个具体场景说明这一差距。下文中的企业是一个说明性模型案例。 它既不是实际客户案例，也不是客户数据的组合。企业规模、流程与障碍均采用有意设计的现实假设，用来展示我会如何分析并构建一个典型情境。文中描述的影响不是业绩承诺，而是管理层需要建立的基线与决策标准。
我的原则很简单：企业首先需要的不是更多AI工具，而是明确AI应在哪里创造价值、如何嵌入流程，以及谁对由此形成的系统负责。
模型案例：一家拥有众多项目、却没有共同系统的成长型B2B中小企业
我们的模型企业是一家从事技术分销与服务的国际B2B中小企业，约250名员工分布在DACH地区和英国的多个地点。企业保持盈利，但面临利润压力；同时还需要在不同比例增加行政与运营人员的情况下实现增长。
| 维度 | 模型化起点 |
|---|---|
| 商业模式 | 技术产品、咨询与经常性服务收入 |
| 组织 | 约250名员工，覆盖销售、服务、运营、市场与行政 |
| 核心系统 | ERP、CRM、文档库、营销自动化与工单系统 |
| AI使用 | 市场、研究与客户服务中的多个独立工具和试点 |
| 管理目标 | 更快运营、更及时响应客户并实现可扩展增长 |
| 主要风险 | 更多工具带来碎片化、运营成本与数据暴露 |
管理层已将AI列为战略重点，但客户询盘仍靠人工分发。信息散落在电子邮件、CRM字段、文档和个人文件夹中。报价因缺少上下文而需要多次补充确认，服务团队则需从多个来源搜索产品和合同信息，月度报告也由多个系统手工汇总。
这家企业缺少的不是想法，而是结构。
管理层看到的现象与底层真实问题
在管理层看来，各种症状似乎互不相关。销售希望改善线索资格判断，运营希望减少人工交接，服务部门需要知识助手，IT担心影子AI，财务询问成本与ROI，人力资源则看到不断增长的技能培训需求。
如果每个部门各自优化，就会形成新的孤岛。因此，我不会先问应该引入哪一款工具。我首先会问：企业作为一个整体需要哪些能力？
NIST AI风险管理框架把AI风险管理视为组织级责任，并以Govern、Map、Measure和Manage四项功能加以组织。1 ISO/IEC 42001采用相似的管理体系逻辑：政策、目标和流程不应只记录一次，而应持续运行与改进。2 在我看来，两者共同印证了一个实践原则：AI的可控性来自Operating Model，而不是一次工具选择。
第一阶段：AI Readiness Assessment建立共同现实
第一步不是选择技术，而是形成可靠的现状判断。在AI Readiness Assessment中，我会审视六个共同决定AI能否规模化的维度。
| 维度 | 核心问题 | 模型案例中的典型发现 |
|---|---|---|
| 战略与价值 | AI应可衡量地支持哪些业务目标？ | 想法很多，但没有优先价值驱动因素 |
| 流程 | 哪些工作流足够稳定，可以引入自动化与AI？ | 媒介断点、例外过多、交接不清 |
| 数据与知识 | 相关信息是否可访问、最新且责任明确？ | 来源分散，质量不一致 |
| 技术与集成 | AI应如何连接CRM、ERP与工作流？ | 独立工具缺乏共同架构 |
| 治理与风险 | 谁可以使用、决策和批准什么？ | 有原则，但责任不清晰 |
| 组织与技能 | 团队能否安全采用新的工作方式？ | 个别人能力强，但缺少系统性赋能 |
在该模型案例中，实验意愿相对较高，而流程、数据和治理成熟度明显较低。这种不对称非常关键，它解释了为什么试点可以快速出现，却很少进入稳定运营。
因此，专业评估不应只给出一个成熟度分数，还必须形成一份管理层诊断：最大价值潜力在哪里？哪些依赖关系阻碍执行？生产部署前必须解决哪些风险？又有哪些项目应主动停止？
最终输出是一份AI Readiness Report，其中包含优先行动领域、风险与机会地图，以及进入下一阶段的明确Go/No-Go决策。此类分析通常需要两到三周。报告页数并不是重点，真正重要的是管理层、业务部门和技术团队首次使用同一套决策依据。
最重要的发现：并非所有好用例都是好起点
模型企业很快就能列出十个以上的AI应用：报价支持、线索研究、服务助手、预测、自动文档、知识搜索或管理报告。
但一张很长的用例清单并不是战略。我至少会从五项标准评估每一个项目。
| 标准 | 决策问题 |
|---|---|
| 商业价值 | 哪项成本、质量、风险或增长驱动因素会发生变化？ |
| 可行性 | 流程、数据和系统访问是否足够稳定？ |
| 证据形成速度 | 受控版本多快可以产生可信证据？ |
| 可扩展性 | 能否推广到其他团队、地区或流程？ |
| 风险 | 错误、数据泄露或错误决策会造成什么后果？ |
在本案例中，我不会从广泛的自主Agent系统开始，而会优先选择一个边界清晰的端到端流程：从客户询盘进入，到合格交接与完整CRM记录。
这个流程具有商业相关性、频率高，并涉及现有系统的多个层面。关键决策点仍由人负责，因此它适合验证的并不仅是一款工具，而是未来AI Operating System的运行逻辑。
第二阶段：AI Transformation Blueprint把诊断转化为架构
完成评估后，管理层知道企业目前处于什么位置。AI Transformation Blueprint回答下一个问题：我们应按什么顺序建设什么，以及在什么条件下允许进入生产环境？
模型流程的目标状态可以如下设计：
| 流程步骤 | 系统功能 | 人的责任 |
|---|---|---|
| 接入 | 从邮件、表单或销售渠道获取询盘 | 定义渠道与隐私规则 |
| 丰富 | 从已批准来源补充客户、产品与合同信号 | 批准数据源和访问权限 |
| 分类 | 建议诉求、紧急度、商业相关性和负责团队 | 定义标准并检查边缘情况 |
| 知识检索 | 提供相关产品、服务与合同信息 | 负责并更新知识库 |
| 回复草稿 | 生成结构化回复或交接草稿 | 批准、修正或升级 |
| 记录 | 在CRM记录决策、来源与结果 | 监控抽样、质量与合规 |
Blueprint并不止于该工作流。它把流程设计、数据源、集成、AI组件、角色、控制、KPI基线与现实的实施顺序连接起来，也明确哪些内容不会自动化。
欧盟AI法案采用风险导向方法，并根据不同应用要求适当的风险评估、数据质量、文档、人类监督、稳健性和准确性。3 并非每个中小企业用例都属于高风险系统，但这些原则仍是合理的架构规则：AI支持的决策影响越大，控制、可追溯性和升级机制就必须越清晰。
在该情境下，一份可靠Blueprint通常需要四到六周。此后，管理层拥有的不再是一张没有约束力的AI路线图，而是投资与执行依据。
目标架构：六个层次，而不是另一个庞大单体平台
AI Operating System不是单一平台。我将它定义为由六个层次组成的可控架构。
| 层次 | 在模型企业中的作用 |
|---|---|
| Experience | 电子邮件、表单、CRM界面与内部助手 |
| Orchestration | 规则、工作流、状态、交接与升级 |
| Intelligence | 分类、提取、生成与决策支持 |
| Knowledge & Data | CRM、ERP、产品、合同与知识来源 |
| Governance | 访问、日志、审批、评估与事件流程 |
| Measurement | 质量、周期、成本、采用率与业务影响 |
这些层次不必来自同一家供应商。关键是有意识地设计接口、责任和可迁移性。这样，即使替换模型或工具，也不必重建整个流程。