企业 AI 落地的「暗面」：Shadow AI 风险与治理路径
Shadow AI 正在侵蚀企业数据边界
Hema Raghavan 指出，当前企业面临一个严峻现实：AI 预算激增，各部门（工程、市场、销售）都被鼓励使用 AI，但这些行为已超出 IT 团队的管控范围。她举例说明，员工可能只是顺手用 AI 工具润色一份销售文案，却无意中将大量敏感数据作为提示词发送给了未获批准的 LLM 服务提供商。
更棘手的是，当企业向 AI 工具开放 CRM 等内部系统的访问权限时，数据流向完全不受监督&管理——公司既无法追踪哪些数据被送出，也无法确认是否会有未经授权的外部访问。Gartner 此前已将 Shadow AI 列为企业首要风险之一。
治理路径一：在可信平台内部署模型
针对数据泄露问题，Hema 观察到几种正在被企业采纳的治理模式。第一种是将 AI 模型直接部署在已获安全团队批准的数据库或数据仓库内部。以 Snowflake 的 Snowpark Container Services 为例，Kumo.ai 通过该服务为客户提供 AI 能力，模型运行全程不离开客户的可信环境。
治理路径二：VPC 部署与流量监控网关
第二种模式是企业自建 VPC 部署或统一网关。所有 AI 调用请求统一经由网关进出，网关负责监控「进了什么、出了什么」。Hema 透露，她的客户中已出现明确诉求：要求 Kumo.ai 的服务必须嵌入客户自有 VPC，若部署在外部则需提供清晰的权限边界说明。
治理路径三：平台级集成
部分企业选择将 AI 能力深度集成至已采购的企业平台（如 Snowflake、Databricks 等数据平台），而非单独采购点解决方案。这样做的好处是数据不必离开已有的安全边界，审计和合规工作也可以复用平台原有的管控机制。
Hema 强调，Kumo.ai 的核心思路正是针对传统机器学习管道（pipeline）的复杂性痛点：用单一基础模型替代过去繁复的特征工程，配合实时数据库查询实现预测，简化端到端流程的同时也降低了数据外泄的暴露面。
Hema Raghavan 进一步指出，AI 本身也能解决数据泄露问题。只要数据通过受控端点流出，AI 就能较好地识别个人身份信息（PII）或企业敏感数据——这类数据模式相当固定，容易被捕捉。
与此同时，另一个思路是控制 AI 一开始能访问哪些数据。在金融科技和医疗健康领域，许多客户倾向选择可精细管控数据访问权限的 AI 部署模式。Hema 以此为例说明：电子健康记录数据仅限特定人员和特定 AI 系统访问，且系统会记录所有数据的进出情况，形成完整的遥测监控。
从数百条流水线到单一基础模型
在被问及能否彻底绕过数据流水线时，Hema 表示这正是她创业前在 LinkedIn 领导 AI 团队时反复思考的问题。当时 LinkedIn 的「你可能认识的人」推荐、通知流、职位推荐等功能背后，是数十个模型和数百条数据流水线在运转。
她举了一个 Gen AI 时代的典型案例：某应用因前端追踪流水线故障，导致用户点击行为数据异常回传，模型输出开始出现怪异结果。幸好团队有完善的治理机制，能够察觉模型评分异常并及时开 war room 排查。然而追踪问题根源却极为痛苦——因为流水线 A → B → C → D 的层层依赖，一旦最上游的流水线出错，整条链路都需要逐一排查。
更棘手的是，随着模型和流水线数量不断膨胀，加上数据科学团队和仓库团队跨越数千名工程师、人员流动带来的流水线无人维护问题，「位衰减」（bit rot）让维护成本急剧攀升。
正因如此，Kumo 的核心设计理念应运而生：能否用单一基础模型取代这数百条流水线？
在线查询替代预训练：上下文学习的新范式
Hema 提到，Gen AI 中已出现一些可借鉴的模式，例如上下文学习（in-context learning）。以职位推荐为例：系统无需预先训练模型，而是实时查询数据库，将「Ryan 在找工作」等上下文信息即时发送给通用基础模型，模型直接返回推荐结果。
这意味着团队只需维护一个基础模型和一套在线查询服务即可。这种架构在可维护性上远超传统流水线方案。
Hema 将其形象地总结为：不再让流水线在数据源之间搬运数据，而是把「流水线」迁移到 AI 模型本身，让模型本身成为数据的另一种形态。
统一数据仓库：架构即治理
针对是否需要区分生产数据库与分析数据库的问题，Hema 认为，统一的数据仓库层能极大简化治理工作。在单一目录层中，团队可以集中决定哪些数据集可供 AI 使用，并内建监控机制——特别是在需要限制 AI 只能访问部分数据的场景下，统一仓库可以让管控在一处完成。
她建议，企业在 analytics 和 AI 场景中应尽可能将 ETL 收敛至单一数据仓库。虽然某些情况下因性能差异难以完全统一，但大多数企业正在朝这个方向演进。
在线服务层的数据困境
在线应用的数据需求与传统数据分析场景截然不同。以电商或新闻网站为例，用户进入页面时需要实时推荐——这类场景对延迟和并发要求极高，传统数据仓库的性能特征难以满足。
Hema 指出，分析层在数据治理方面远比在线服务层更早起步，而各个公司的在线架构差异巨大，彼此之间几乎找不到共同模式，导致在线服务层的数据治理至今缺乏标准化方案。
为什么在线架构难以标准化
Raghavan 在对话中还原了一家初创公司从零起步的典型路径：借助 Claude、Codex 等工具，创始人能在一天内搭建出一个完整的电商网站，后端通常以 Postgres 起步，几乎所有公司最初都沿着这条路走。
这一现实带来一个矛盾：当「快速用 Postgres 起步」变得极其容易时，没人愿意在早期投入精力建立统一的数据工具层。Raghavan 直言：「没有人真正打造出一款工具来统一这一切——让大家只需插入一个 AI API 网关就行。」 Donovan 也观察到类似现象：Shopify 等平台试图让电商数据操作更标准化，但每家公司最终仍在按自己的方式构建在线架构。
数据库层：商品化与专业化并行的张力
当对话转向「当 Postgres 不再够用时，企业是否会像大型云厂商那样重写整个应用以换取 10-15% 的性能提升」时，Raghavan 给出了一个清晰的框架： 数据库核心层已基本商品化。 她认为：「你遇到的每一个扩展问题，买一个现成解决方案的成本，仍然比雇一群数据库专家为你定制开发更低。」这意味着核心关系型数据库不太需要自研，大公司之外很少有人会自己造轮子。
但某些组件开始出现瓶颈：
- 日志/遥测系统：随着公司规模增长，许多 SaaS 日志服务开始力不从心，成本飙升，企业开始考虑自建
- 存储层（DISC）：S3、ADLS 等已充分商品化，几乎没有公司愿意自建存储基础设施
专业数据库的涌现：越少越好
当公司成长到一定规模，时间序列数据库、向量数据库、键值存储等专业数据库开始登场。Donovan 问出了一个关键问题：「这种专业化分工对公司而言是好事还是新麻烦？」 Raghavan 的回答一针见血：「每当团队提出一个新设计方案，我问的第一个问题永远是：能不能不再增加一个数据库？」 她强调，数据库越多，维护成本和数据同步的复杂度就越高。尤其是向量数据库——当底层 AI 模型发生变化时，嵌入向量极易失效，不同数据源之间的一致性维护会迅速变成噩梦。
因此，她的结论是：数据库越少越好。
AI 领域的标准化困局
回到 AI 与数据架构的主题，Raghavan 描述了一个正在形成的问题：不同团队在探索完全不同的 AI 实现路径——
- 团队 A 全面押注 RAG（检索增强生成）+ 向量数据库
- 团队 B 认为纯提示工程才是正道，一切数据塞进提示里
这种缺乏标准化的状态正在制造新的问题。但 Raghavan 也承认，这背后存在一个真实的权衡：作为 CTO，她希望团队大胆实验以探索可能性，但一旦探索阶段结束，如何将成果收敛、统一到现有架构中，是一个巨大的挑战。 Donovan 总结了这一困境：「整个行业在过去几年大量实验，但这让工程团队很难做出长期规划、构建一致的系统。」他提问：我们是否正在进入「实验退潮」阶段，还是仍有更多探索要进行？
这正是当前 AI 工程领域最核心的张力：创新速度与架构稳定性之间的持续拉锯。
工程卓越的三个北极星指标
Hema Raghavan 指出，很多团队在引入 AI 工具后容易陷入一个陷阱：一味追求开发速度（velocity），却忽视了系统的长期可维护性。她认为真正需要关注的指标有三个：开发速度、每个发布周期的 P-zero 严重缺陷数量，以及平均故障恢复时间（MTTR）。这三个指标才是团队的北极星，尤其在 AI 代码生成工具大规模普及的当下，后两者更容易被牺牲。
用架构设计本身做治理
Ryan Donovan 提到，很多团队会因为 AI 工具带来的速度诱惑，主动放弃后两个指标。Hema Raghavan 的解法是把架构约束直接嵌入代码库。她带领的团队开始在代码仓库中插入「由 AI 代理维护的 MD 文件」，这些文件本身就是设计规范的载体——当开发者在 IDE 中使用 coding agent 时，agent 会读取这些规范文件，并自动遵循团队约定的设计模式，从而将治理要求变成工具行为的一部分，而非依赖人工自觉遵守。
资深工程师的双重职责：带人也带 AI
对话还触及了一个深层问题：junior engineer 在 AI 辅助时代面临的独特挑战。Hema Raghavan 分享了一位资深工程师的原话：「我必须确保 AI agent 不会取代我 junior 工程师的思考能力。」在她看来，资深工程师现在同时承担两项指导任务——既要带教 human junior，也要「带教」AI agent。Junior 工程师被要求主动质疑 AI 的决策，例如「为什么你选择同步 API 而非异步 API」——这要求他们快速成长，能够独立评判 AI 输出的设计质量，而不只是接受答案。
招聘流程的根本性重塑
Hema Raghavan 透露，团队已经调整了招聘流程：不再考察「手写算法速度」或白板排序，而是给候选人布置需要使用 AI agent 完成的 take-home 任务，随后在面试中重点考察候选人能否解释 AI 做了什么、为什么做出这样的选择、方案是否合理。这种转变有几个深层原因：
- take-home 形式本身也更包容——候选人不必现场高压环境下作答
- 核心筛选标准从「写代码多快」变成「能否读懂代码、理解设计选择、给出充分测试用例验证输出」
她明确表示，「代码写得快」这件事现在由 AI agent 承担，面试要考察的是人独有的判断力。Ryan Donovan 也认同：没人再需要在白板上手写冒泡排序了。
工程团队的数据治理新挑战
在播客后半段，Hema Raghavan 重点谈了 AI 工程团队即将面临的新课题。
API 可视化与数据流向管控 她指出，未来 CIO 和 CISO（首席信息安全官）将需要专门工具来监控 API 调用和数据出口（egress）。这个需求正在从「加分项」演变为「必备项」。她提到，即便在引入新供应商时，也应该明确询问：「我能否查看所有数据的流向？」行业目前参差不齐，但标准化是必然趋势。
成本与治理的双重压力 当前行业处于「高实验阶段」，大量数据和 Token 被送往各处。她预判，接下来工程团队需要更审慎地评估成本——某些场景下，在自有参数范围内部署开源模型可能比调用外部 API 更经济。这将逐渐成为工程设计评审中的常规议题。
拥抱变化，但勿重蹈覆辙 在收尾时，Hema 特别强调：这是工程领域激动人心的时代，必须拥抱变化，但也要从过去的教训中学习。「我们会犯新的错误，但别再重复过去的错误——别在我们高速推进的时候忘记它们。」
评论