10 篇博文 含有标签「enterprise」

你正在对接的采购团队最终会提出一个重置你架构的问题：“我们可以自带模型 API 密钥吗？”回答“可以”能赢得订单。但回答“可以”同时也意味着你的信任边界、成本边界和运营边界发生了转移 —— 而大多数产品团队只有在合同签署、第一个月的使用产生了一个没人知道如何回答的服务工单后，才会发现这一点。

BYOK 在公司内部推销时被视为一个开关。客户粘贴一个密钥，你的代码从保险库（Vault）读取它而不是从你自己的账户读取，然后推理流程照常进行。但这并不是一个开关。这是一场由销售驱动的架构重构，它会波及成本分摊、安全事件响应、可观测性、速率限制、模型版本锁定以及值班问责。那些在没有意识到这一点的情况下就交付产品的团队，最终会在一年后为了修复这些问题而重构整个平台层，而付费企业客户则在焦急等待。

一个在内部基准测试中得分 94%、在演示中令利益相关者印象深刻、通过所有离线评估的模型，进入生产后仍然可能跌落至 7% 的真实客户数据有效准确率。这不是假设——这是多个企业 AI 部署中有据可查的结果，也是一种更广泛模式的症状：从"试点成功"到"生产价值"之间的鸿沟，正是大多数企业 AI 悄然消亡的地方。

在各行各业，大约 85–88% 的企业 AI 试点项目从未到达生产。每启动 33 个 PoC，只有四个能够上线。尽管模型能力大幅提升，这一比例三年来几乎没有改变。失败的根源几乎从不在于模型是否足够好——几乎总是在于成功演示与真实用户真正依赖该系统完成实际工作之间所发生的事情。

几乎每一次企业 AI 部署中都会出现同一种模式：工具在演示中表现出色，上线生产后却悄然止步于 70–80% 的潜力。团队将其归咎于模型质量、上下文窗口限制或检索失效。然而大多数情况下，这个诊断是错的。真正的问题在于：他们要求 AI 扮演一个它在结构上无法胜任的角色——至少目前如此，也许永远如此。

"AI 能完成这项任务"与"AI 能胜任这个角色"之间的鸿沟，是企业 AI 领域最昂贵的误解。

90% 的公司员工都在使用个人 AI 账号——ChatGPT、Claude、Gemini——来完成工作，而其中 73.8% 的账号是非企业性质的。与此同时，57% 使用未经批准的 AI 工具的员工正在与其共享敏感信息：客户数据、内部文档、代码、法律草案。大多数高管认为他们的政策可以防止这种情况发生。但数据表明，实际上只有 14.4% 的团队部署的 AI 获得了全面的安全批准。

领导层认为正在发生的事情与实际发生的事情之间的差距，就是影子 AI 治理问题。

大多数公司的本能反应是下达禁令。在网络层面封禁个人聊天机器人账号、发布政策备忘录、进行年度培训，并称之为治理。这是最糟糕的应对方式——不是因为担忧是错误的，而是因为这种干预措施在没有缩小问题的同时，反而让问题变得不可见。

你的团队在 3 月发布的 AI 功能对你一半的潜在客户来说是无法销售的，而工程部门目前对此还一无所知。在客户执行（AE）的 Slack 频道里，一个成交概率原本为 80% 的项目刚刚被踢出了预测名单，因为潜在客户的 CISO 发来了一份包含 92 个问题的安全评估以及一份 AI 补充协议。第 31 题要求提供你的训练数据来源证明文档。第 47 题询问是否记录了提示词（prompts）、记录在何处、保存多长时间以及谁有权阅读。第 63 题询问你的推理过程是否可以固定在欧盟（EU）区域。第 78 题要求提供针对 OWASP LLM Top 10 语料库的提示词注入防御率，并按模型版本列出实测数字。销售团队只有 72 小时来做出回复。而 AI 团队中没有一个人写下过这些问题的答案。

这就是新的围墙。财富 500 强的采购团队现在会进行 2023 年尚不存在的 AI 功能专项安全审查，而你的工程部门需要的答案其实并不难产生 —— 只是目前没人负责这件事。这些问题是具体的，框架是公开的，但大多数 AI 产品却在悄无声息中变得无法销售给受监管的企业，因为答案从未被记录下来。

令人沮丧的是，这一切并不神秘。问卷是有模板的。预期的答案也是有据可查的。真正的失败模式在于：AI 功能在发布时被假设现有的 SOC 2 报告能像过去十年那样在企业交易中发挥同样的效力 —— 事实并非如此。

企业团队基于基准测试和演示选择LLM供应商，然后在生产环境中才发现SLA实际保障的内容——通常远低于预期。你费力谈下来的99.9%可用性保证并不涵盖延迟。法务团队签署的数据处理协议，除非明确添加了相关条款，否则并不禁止供应商用你的输入数据进行训练。而没有人量化的供应商集中风险，在某次遥测部署级联影响Kubernetes控制平面导致核心产品中断四小时后，会以最惨烈的方式暴露出来。

这不是采购问题，而是采购单独无法解决的工程问题。构建AI系统的工程师需要理解这些合同实际说了什么——以及没说什么。

你发布了 AI 功能。你将其内置于产品中。你编写了帮助文档。然而，六个月后，你最资深的企业用户仍然在将文本复制粘贴到 ChatGPT 中，以完成你的功能原本就能原生实现的事情。这不是培训问题。这是一个可发现性（discoverability）问题，也是当今企业软件中 AI 投资浪费最普遍的来源之一。

这种模式已有详尽的记录：49% 的员工表示他们在工作中从不使用 AI，74% 的公司难以从 AI 部署中扩大价值。但有趣的失败模式并不是那些明确抵制的后期采用者，而是那些每天打开你的产品、却从未意识到原本值得他们付费的 AI 功能就潜伏在光标一键之遥处的活跃用户。

你的发票解析器可能运行得不错。给它一个来自世界 500 强供应商的清晰、数字化的 PDF —— 结构化的行、一致的列宽、机器生成的文本 —— 它就能以近乎完美的准确度提取行项目。但当有人上传一份来自区域供应商的多页合同、一份带有手写修改的扫描表格，或者一份表格标题在第 3 页而数据行延续到第 6 页的财务报表时，提取器就会悄无声息地失败，返回部分数据，或者自信地生成结构化输出，而这些输出的错误方式是任何下游校验都无法捕捉到的。

这是企业级文档智能的核心问题：使你的系统崩溃的文档并不是边缘案例。它们往往是具有最高业务价值的文档。

大多数企业安全团队都有一套相当成熟的内部威胁模型：心怀不满的员工将文件下载到 USB 驱动器，将电子表格发送到个人邮箱，或者带着凭据离职。检测策略是已知的 —— DLP 规则、出口监控、UEBA 基准。这些策略没有考虑到的是这样一种场景：你给每位员工都提供了一个能够以机器速度规划、执行并掩盖多阶段操作的工具。这正是部署 AI 编程助手和基于 RAG 的文档代理的实际效果。

问题并不在于这些工具在隔离状态下是不安全的。而在于它们极大地放大了一个受攻击或怀有恶意的内部人员在单次会话中能完成的任务。内部人员事件的平均成本每年已达到每家机构 1740 万美元，83% 的机构在过去一年中至少经历过一次内部攻击。AI 工具并没有引入新的威胁类别 —— 它们只是成倍地增强了每一个现有威胁类别的能力。

你的 AI 演示确实令人印象深刻。高管观众们纷纷点头，工程副总裁（VP of Engineering）直言“这就是未来”，试点项目也获得了真金白银的预算批准。六个月后，周活跃用户数（WAU）停滞在 12%。在全体会议上，这款工具会被客气地提及。没人忍心宣布它已经失败。这就是试点坟场（pilot graveyard）——优秀的演示项目最终消亡的地方。

这种失败并非个案。大约 88% 的企业 AI 试点项目从未进入生产阶段。只有 6% 的企业成功地将生成式 AI 项目从试点推向了具有一定规模的生产环节。从“会议室里令人惊艳”到“日常工作流中的支柱”之间的巨大鸿沟，正是大多数企业 AI 投资付诸东流的地方。

原因不在于模型，而在于演示之后发生的一切。