Sergio Gago 是 Cloudera 的首席技术官，拥有 20 多年的 AI/ML、量子计算和数据驱动架构经验。之前，他曾担任 Moody’s Analytics 的 AI/ML 与量子管理总监，并曾在 Rakuten、Qapacity 和 Zinio 担任过首席技术官。Sergio 是可信数据基础设施的坚定倡导者，他相信 AI 将在 2030 年前演变为企业的操作系统。
AI不再只是一个生成文本的聊天机器人。在企业环境中，AI代理正在执行诸如检索敏感数据、触发工作流、调用工具和跨系统记录活动等操作。自主性完全改变了治理讨论；最初为人类用户和传统应用程序设计的控制和程序并不适用于可以在运行时执行多步操作的软件。风险并非理论上的。可见性、访问控制和审计能力方面的小缺口可以迅速累积，导致难以检测和更难逆转的运行时故障。为了跟上这一新时代，管理AI代理不能通过添加更多的政策文档来完成。它需要通过设计来实现治理：一种架构方法，控制措施嵌入控制平面并在运行时持续执行。如果代理要像数字同事一样行事，它们必须继承与人类相同的企业防护措施，以及更强大的运行时监督。为什么治理在融合时代破裂企业架构已经进入了融合时代。数据和工作负载现在跨越多个云、私有数据中心和边缘环境。有一些组织因为需要同时管理多个流程而运行平行系统。这些流程包括单独的身份系统、日志管道、目录和批准流程。结果就是所谓的“弗兰肯斯坦平台”，每添加一个新工具或云环境，集成开销就会增加。事实上，这种碎片化正出现在日常现实中。根据最近的一项调查，47%的受访者认为复杂的访问要求和流程以及44%的受访者认为对数据位置的可见性有限是使用数据有效的障碍。这正是代理暴露系统之间的缝隙的地方。为了回答一个商业问题，代理可能需要从本地ERP系统、云CRM、另一个云中的运营遥测和协作套件中的文档中提取数据。如果组织在每个地方以不同的方式执行策略，代理将会失败，或者更糟糕的是，以无法解释或控制的方式成功。这是企业领导者必须关注的时刻。代理正在迫使更高的标准，要求在环境之间保持一致性和在运行时保持问责制。因此，治理正在被监管机构和安全机构推到聚光灯下。一个例子是NIST AI风险管理框架，它强调了在整个AI生命周期中管理风险，而不仅仅是在构建时。这是一个提醒，合规性和信任是运营责任，而不是一次性清单。从政策到平台通过设计实现治理意味着治理随着工作负载移动，而不是在每个隔离区重新实现。实际上，这依赖于三个构建块： 统一控制平面 一个地方来定义和执行身份、访问、策略、目录和授权跨云和数据中心。目标是只写一次策略并在数据和模型运行的任何地方执行，而不是在每个系统中重新构建控制系统。这防止了代理行为漂移，即同一个代理在一个环境中表现安全，在另一个环境中表现危险。一个实用的测试很简单：如果用户无法访问一列，验证代理代表用户也无法访问它。这应该表明是否正在执行跨平面的书面策略。 基于开放标准的数据织物 代理需要上下文来操作。当上下文分散在不同结构中，由不同团队拥有时，数据织物有助于标准化语义和访问模式，因此代理不需要为每个数据集学习一套新规则。像Apache Iceberg这样的开放表格格式支持这一点，允许多个引擎在不将数据复制到新隔离区的情况下共享相同的管理数据。这很重要，因为数据复制通常是治理失败的地方。一旦团队开始复制“代理需要的内容”，您就创建了一个新的、管理较少的环境。如果代理可以在不引入新权限差距的情况下跨数据集操作，治理就按预期工作。 实时可观察性和血统 代理只有在运行时可见时才是可治理的。这里的可观察性不仅仅是一种“nice-to-have”，而是运行时控制和事件响应的基础。特别地，需要有代理操作的端到端证明。代理应该能够证明操作，例如访问了哪些数据和调用了哪些工具，并且从那里，血统可以将输出连接回输入。这使得团队能够审计这些决策，并在需要时排除故障，从而证明整体合规性。将代理视为“数字同事”一种最有用的思维模型是将代理视为数字同事。这里有一个比较：就像员工有访问某些建筑和房间但不允许进入其他房间的访问徽章一样，治理允许代理具有访问限制。一个关键的补充是代理必须对其允许透露的内容有情况感知。考虑一个支持代理。它可能需要访问以前的支持案例来解决一个问题，但在这样做的同时，它不能泄露其他客户的私人细节。换句话说，代理可以使用受限的知识来推理，但仍需要执行披露边界。这不是一个“提示编写”问题，我们过去知道如何处理；相反，这是一个身份和运行时执行问题。2026年会发生什么变化：代理从实验转向生产2026年是实验结束、代理进入生产的年份。这种转变迫使企业以两种速度运营。一个是创新速度，团队在此测试新模型、工具和代理工作流以获得竞争优势。另一个是安全速度，系统必须满足合规性和运营要求，这可能包括严格的访问控制和盲点。如果没有一套架构治理，这两种速度将会冲突。如果团队在代理得到治理之前部署它们，将会出现一系列一次性的控制和运营故障。如果相反发生，安全将阻止一切，创新将转移到影子IT，破坏治理。目标不是选择一种速度。它是建立一个同时支持两种速度的架构。代理运行时治理的实用清单 如果您正在构建或扩展代理，问自己以下问题以确定治理是否真正具有架构性：您能否从头到尾解释代理访问了哪些数据来产生答案或采取行动？ 访问决策在混合环境中是否一致，还是因平台而异？ 您是否具有代理操作的遥测数据，包括工具调用、策略检查和人工升级？ 如果代理行为异常，您能否在运行时限制、暂停或隔离代理？ 您是否具有与监管义务和风险承受能力相符的部署后监控计划？ 如果您无法回答这些问题，请将代理部署视为即将发生的生产事件。治理转变需要是架构性的，否则它不存在代理将成为企业运营的标准组成部分。问题是它们是否会成为企业运营的可靠组成部分。如果代理不能像人类和关键任务软件一样自信地被治理，其后果将是真实的。我们将在数据泄露、合规性失败、运营中断和对AI程序的信任丧失中看到这些后果。领导者需要停止将代理治理视为文档练习。随着平台能力的扩展，代理治理应该是承担其他角色监督的组成部分之一。这意味着在控制平面中嵌入控制，实现操作的可观察性和决策的可审计性。然后扩展。这就是您如何获得快速移动而不会破坏企业的代理。
是的，标题很吸引眼球和煽动性，但作为一位有多年数据经验的CTO，我见证了一个变革，这个变革足以证明这种戏剧性。传统的“数据团队”——后台办公室的报告和仪表盘团队——实际上已经死亡。取而代之的是，一种新的数据团队正在出现：一种以AI为先的、产品驱动的强大团队，具有直接的收入影响。他们不再是成本中心，而是利润产生的团队。从商业智能到机器学习的旅程不久前，数据团队与商业智能（BI）同义。我们是公司数据的历史学家，生活在SQL和电子表格中，负责回答“上个季度发生了什么？”当像Hadoop这样的大数据技术出现，数据科学家成为新的性感工作时，数据团队演变了。到2010年代中期，我们不仅仅是报告；我们冒险进入数据可视化和交互式分析，为每个部门制作动态仪表盘。工作的重点是数据处理，混合来自不同来源和形状的数据集，并尝试理解领域知识。然后，2010年代后期带来了机器学习时代。数据团队开始聘请数据科学家来构建预测模型并在大量数据集中发现见解。我们从描述过去转变为预测未来：流失模型、推荐引擎、需求预测——你能想到的都有。但即使那样，我们的输出也是幻灯片和见解，而不是实时产品。我们作为内部服务局，通过分析为业务提供咨询。换句话说，我们是成本中心——有价值，是的，但与核心产品和收入有一步之遥。在最好的情况下，机器学习团队被分散到单独的单位或嵌入到产品团队中，以便他们的模型和推理可以被完全集成到平台中。 这种伟大的分歧导致了众多失败的项目，沉没的投资和失去的机会。GenAI：从支持功能到利润中心然后GenAI到来了，一切都改变了。像GPT家族和开源变体如Llama这样的强大大语言模型的发布，几乎在一夜之间就颠覆了整个格局。突然，数据团队不再只是分析业务，而是成为构建AI产品和体验的重要组成部分。当你成功地将LLM集成到面向客户的应用程序或内部工作流中时，你不再只是告知业务；你正在驱动它。一个成功实施的GenAI系统可以自动化客户支持，生成营销内容，个性化用户体验，甚至提供必要的数据来告知和训练新兴的代理AI系统。这些能力直接影响收入流。实际上，数据团队的工作成果已经从PowerPoint幻灯片转变为实时的AI驱动应用程序。GenAI团队从创新团队开始，提供了能够产生“哇”因素的概念验证。很快，每个人都成了AI工程师，在组织中传播影子IT。数据团队很快面临着一个新的问题：“你什么时候会成为一个利润中心？”当AI工程师开始创建令人惊叹的工具时，很明显是时候将两个团队合并了：控制数据的团队和构建应用程序的团队。考虑一个零售公司，它部署了一个GenAI聊天机器人来处理销售查询，或者一家银行推出了一个AI驱动的个性化投资顾问。这些不是传统的IT侧项目——它们是数字产品，能够为客户创造价值和产生收入。然而，为了在规模上创建这些系统，AI工程团队需要能够访问和操作传统团队准备好的数据。高管们已经注意到了这一点。数据团队的期望现在非常高，董事会和CEO正在寻找他们来提供下一个AI驱动的增长向量。我们从幕后分析师转变为前线创新者。这是一个令人兴奋的位置，但也带来了巨大的压力，需要在规模上交付成果。从探索到产品——一扇单向门从探索性分析到产品驱动的AI的转变是深刻而不可逆转的。为什么不可逆转？因为GenAI对业务的影响被证明太大了，不能将其降级为研发玩具。根据最近的一项全球调查，96%的IT领导者已经将AI集成到核心流程中——比一年前高出88%。换句话说，几乎每个企业都从尝试AI转变为将其嵌入到关键任务工作流中。一旦你跨过了AI在生产中提供价值的门槛，就没有回头路了。这种新的AI驱动的重点改变了数据团队的节奏和思维方式。过去，我们有长期发现项目和开放式分析的奢侈。今天，如果我们正在构建一个AI功能，它需要是生产就绪的、合规的和可靠的——就像任何面向客户的产品一样。我们已经进入了数据科学的“自主时代”。指导我们工作的问题不再是“我们可以发现什么见解？”而是“我们可以建立什么样的智能系统来实时对见解做出反应？”GenAI系统不仅仅是在回答问题；它们开始做出决定。这是一扇单向门：在经历了这种自主性和影响力之后，公司不会满足于静态报告和手动决策。现在比以往任何时候都更需要数据团队成为利益相关者和产品导向的。GenAI项目失败的残酷真相在所有的兴奋中，有一个清醒的现实：大多数GenAI项目都失败了。成功部署GenAI被证明是极其具有挑战性的。 一项最近的MIT研究发现，令人震惊的95%的企业GenAI试点项目从未提供可衡量的投资回报率。只有大约5%的AI试点实际实现了快速的收入增长或有意义的业务影响。这并不是由于缺乏潜力——而是由于做AI正确的复杂性。深入研究失败的原因，MIT研究呈现出一个清晰的图景。许多项目由于“炒作超过辛勤工作”而陷入困境——团队追逐华丽的演示用例，而不是投资于集成、验证和监控的基础方面。其他项目由于“垃圾进，垃圾出”综合征而失败——数据质量差和数据管道孤立使得项目在AI开始工作之前就已经失败了。通常，这不是AI模型有缺陷，而是周围的环境。正如研究人员所说，GenAI在实验室中不会失败；它在企业中失败，当它与模糊的目标、糟糕的数据和组织惯性相碰撞时。在实践中，大多数AI试点项目停滞在概念验证阶段，永远不会毕业到完全的生产部署。这种现实检查是一个宝贵的教训。它告诉我们，即使数据团队现在处于聚光灯下，多数团队仍然难以满足提高的期望。为了使GenAI在规模上成功，我们必须跨越一个比过去BI时代更高的门槛。超越巧妙的提示：数据、治理和基础设施很重要是什么让5%的AI项目成功，而95%的项目失败？在我的经验中（以及研究证实），获胜者专注于基础能力——数据、治理和基础设施。GenAI不是魔术；它是建立在数据之上的。没有高质量、良好治理的数据管道来喂养你的模型，即使是最好的AI也会产生不一致的结果。 Summit Partners在最近的一次分析中说得好：“使用AI的任何系统或流程的成功都取决于为其提供动力的数据的质量、结构和可访问性。”在实际操作中，这意味着组织必须在采用GenAI时加倍下注于数据架构和治理。您是否拥有统一、可访问的数据存储，AI可以从中提取数据（我指的是所有数据存储，包括数据中心、超级计算机和第三方SaaS系统等）？这些数据是否清理、整理并符合法规？是否有明确的数据来源和可审计性（以便您可以信任AI输出并知道它们是如何产生的）？这些问题现在处于最前沿。GenAI迫使公司最终整理好他们的数据治理也具有了新的重要性。当一个AI模型可能产生错误答案（或令人反感的答案）时，强大的治理不是可选的——它是强制性的。版本控制、偏见检查、人工审查和对敏感数据输入的严格安全措施都是必不可少的。没有适当的治理、培训和明确定义的目标，即使是一个强大的AI工具也会难以在业务中获得牵引力。让我们不要忘记基础设施。以规模部署GenAI需要大量的计算能力和严格的工程。模型需要实时提供，跨可能数百万个查询，延迟低。它们通常需要GPU或专用硬件，以及持续的监控、保留和生命周期管理。简而言之，你需要工业级的AI基础设施，这种基础设施是安全的、可扩展的和可恢复的。这就是私人AI的概念作为框架的由来，私人AI将基础设施与数据和治理结合起来。私人AI指的是在受控和安全的环境中开发AI，确保数据安全和合规性。最终，GenAI的成功取决于三个支柱的和谐：数据、治理和基础设施。没有一个，你就有可能加入95%从未扩展到演示阶段的项目。为什么AI工程师不能独自完成考虑到这些要求，很明显，仅仅聘用几位有才华的AI工程师并不是银弹。我们在过去几年中在数据行业中吸取了这个教训。在数据科学热潮的早期，公司试图找到“独角兽”数据科学家，他们可以做所有事情——构建模型、编写代码、处理数据和部署。这个神话自此被揭穿。正如一位资深数据科学家所说，“一个放在笔记本中的模型实际上对业务没有任何作用。”你需要将该模型嵌入到应用程序或流程中，才能产生价值。并且这需要一个跨多个技能的团队合作。在2010年代后期，我们看到数据团队分化为不同的角色：数据工程师开始构建强大的管道，机器学习工程师专注于生产模型，分析工程师管理分析层，等等。今天，GenAI将标准提升得更高。是的，你需要AI专家（提示工程师、LLM微调器等），但这些专家如果没有成熟的数据管道、治理框架和安全平台来工作，就会遇到困难。AI工程师可以在沙盒中原型化一个很好的语言模型，但将其转变为成千上万或数百万人使用的产品，需要与安全团队、合规官、数据架构师、站点可靠性工程师等进行合作。AI是一项团队运动。很诱人认为你可以将一个最先进的模型放入你的业务中，突然拥有一个AI驱动的企业。成功于AI的公司是那些建立了跨职能团队或“AI工厂”的公司，它们将所有这些部分结合在一起。他们的数据团队已经演变成全栈AI产品团队，混合了数据、建模、工程和运营专业知识。他们以数据驱动、产品驱动的方式构建和部署他们的工具，并将价值生成嵌入到每个KPI中。下一代数据团队那么，未来对新“数据团队”的展望是什么？以下是未来几年中这些团队即将面临的内容： 更少的手动ETL/ELT：乏味的数据处理将减少。随着更多的自动数据管道和AI辅助集成，团队将不再花费大量时间清理和移动数据。数据准备的苦力活将越来越多地由智能系统处理，允许人类专注于更高层次的设计和质量控制。 更少的仪表盘：无休止地调整仪表盘过滤器的时代正在消逝。AI将使自然语言查询和动态洞察力交付成为可能。用户将获得来自AI的对话式答案（附带源数据），而不是为每个问题预先构建的仪表盘。数据团队将花费更少的时间开发静态报告，更多的时间训练AI生成即时洞察力。 更多的AI原生产品开发：数据团队将成为产品创新的心脏。无论是开发新的面向客户的AI功能还是内部AI工具来优化运营，这些团队都将作为产品团队。他们将采用软件开发实践，快速原型开发，A/B测试和用户体验设计——不仅仅是数据分析。每个数据团队都将成为一个提供直接业务价值的AI产品团队。 自主代理的崛起：在不太遥远的未来，数据团队将部署自主AI代理来处理常规决策和任务。这些代理不仅仅是预测结果；它们将被授权采取某些行动（在监督下）。想象一个AI运营代理，可以检测异常并自动打开一个补救票，或者一个销售AI代理，可以实时调整电子商务定价。数据团队将负责构建和管理这些代理，推动自动化的边界。 鉴于这些变化，有人可能会说“数据团队如我们所知已经死亡”。电子表格专家和仪表盘水管工已经让位给了新东西：AI优先的团队，这些团队精通数据、代码和商业策略。但这并不是一场葬礼，而是一场庆祝。新一代的数据团队才刚刚开始，他们比以往任何时候都更有价值所以，请记住，数据工程师已经死了，长_live 数据工程师！我们所知道的数据团队已经消失，但新的数据团队——愿他们在这个AI驱动的世界中以洞察力、责任感和大胆重生——长_live 。
