Phillip Merrick, 联合创始人和首席产品官，pgEdge Phillip Merrick 联合创始人和首席产品官，pgEdge

人工智能治理不是高层问题，而是数据库问题

企业内部的人工智能实验速度前所未有，但从实验到生产的路径仍然很慢。团队可以在几周甚至几天内启动试点，测试模型，并展示出有前途的结果。但是，当他们试图在大规模上部署这些系统时，进展往往停滞不前。安全问题浮现，合规要求变得更加严格，治理问题也随之增加。MIT的The GenAI Divide：2025年商业中的人工智能状态报告发现，95%的企业人工智能试点项目未能带来可衡量的商业影响。只有5%的项目达到生产阶段并产生真正的财务回报。该研究包括300多个人工智能部署和150多次高管访谈，其结论是，主要障碍不是模型能力，而是有缺陷的企业集成。多数组织将其视为高层需要解决的政策问题。我认为人工智能治理是一个系统挑战，它从数据层开始。为什么人工智能项目在试点阶段停滞许多人工智能项目因为用于原型设计的环境与企业部署的现实根本不符而失败。开发人员被激励去快速行动，利用灵活的工具、松散管理的数据集和自助式基础设施，以尽快证明价值。这对于实验是理想的，但它不能转化为需要审计、严格的访问控制、法规遵从性和运营弹性的生产环境。因此，治理通常是在概念验证之后引入的。在那时，原本应该成为一个促进因素的治理变成了一个限制因素——迫使团队为安全模型、数据流和合规假设进行改造，而这些应该从一开始就成为基础。这造成了人工智能系统在受控环境中展示的东西与企业可以安全、可靠地部署在生产中的东西之间的差距越来越大。同时，现代人工智能栈已经演变为优先考虑速度和可访问性，往往以牺牲控制为代价。开发者友好的平台使得试点变得容易，但它们可以掩盖数据的位置、使用方式和谁有访问权限。这引入了真正的运营和监管风险，包括意外的数据暴露、环境之间不明确的数据边界以及系统行为的审计跟踪不足。这些问题直接出现在生产就绪审查和合规评估中。企业调查一致显示，数据质量和治理问题是导致人工智能项目失败的主要原因，在60-70%的案例中被提及。加剧这一问题的是对第三方基础设施和托管数据库服务的日益依赖，这可能进一步分散数据所有权并使监管对齐更加复杂。在许多情况下，组织假设治理是由平台隐式处理的，而实际上责任分散在整个栈的多个层次。结果是一个悖论。加速人工智能实验的工具往往也是引入生产时的摩擦源。数据库：真正的治理层为了解决这一脱节问题，需要重新思考治理实际发生的位置。治理通常被定位为一个政策功能，由法律、合规或高管团队定义并通过文档和审查过程强制执行。虽然这些机制是必不可少的，但它们单独是不够的。治理只有在系统级别强制执行时才有意义。在实践中，这种强制执行发生在数据存储、访问和转换的地方。这使得数据库和周围的数据基础设施成为人工智能栈中最关键的治理层。现代数据库不仅仅是被动的存储库。它们定义访问权限、执行数据居住要求、管理加密和密钥控制，并生成必要的审计日志以满足安全和合规要求。它们还越来越多地作为人工智能系统与企业数据交互的控制点。这很重要，因为人工智能系统继承了其依赖的数据基础设施的治理姿态。如果底层数据库层缺乏结构、控制或可见性，那些弱点直接传播到构建在其上的人工智能系统中。没有下游应用层面的政策可以完全弥补未经治理的数据基础。这导致了一种更广泛的架构转变：治理必须从一开始就嵌入基础设施中，而不是在部署后添加。基础设施优先的方法意味着设计系统，使治理成为一个内置属性，而不是外部约束。数据访问通过受控接口进行调解。查询和系统交互默认情况下都会记录。合规规则，如访问限制、保留策略和居住要求，在系统级别强制执行，而不是通过手动监督或事后验证。这需要诸如安全查询中介层、基于策略的访问控制和分布式数据环境中的集中可观察性等架构模式。这些机制确保治理被持续强制执行，而不是定期检查。主动治理和被动治理之间的区别是根本性的。被动方法试图在系统构建和部署后纠正问题。主动方法通过将控制直接嵌入系统架构来防止这些问题的发生。在人工智能环境中，这种区别决定了系统是否可以扩展或停滞。当代理进入画面时自主代理以大多数组织尚未准备好的方式改变了治理方程。代理不仅仅读取数据，还写入数据，触发系统间的操作，并且在没有人类干预的情况下执行这些操作。这完全改变了故障模式。一个治理不善的查询会返回一个错误答案。一个治理不善的代理则会在没有任何人意识到问题之前，根据那个错误答案采取行动，更新记录，触发下游工作流，并在系统间传播决策。这就是为什么护栏不能留在应用层。一个跨多个系统操作的代理总会找到最容易的路径。控制必须在数据层强制执行，每次读写操作都必须经过调解和记录，无论是什么触发了它。Gartner 预测，超过 40% 的代理人工智能项目将因治理和可靠性问题而被延迟或取消。这个数字感觉太低了，因为它假设组织正确地将治理确定为原因，而不是将失败归因于模型或工具。根源通常在变得昂贵之前是不可见的。从实验到生产就绪人工智能成功地将人工智能从实验转移到生产的组织往往共享一个共同的特征，即他们早期就将开发环境和生产环境对齐。他们没有让实验系统偏离生产约束，而是设计了具有一致治理、安全和数据访问原则的开发和生产环境。这减少了后期生命周期中模型从原型转移到生产工作负载时的摩擦。这种对齐在人工智能从实验转移到生产的过程中至关重要，因为大多数企业仍然缺乏成熟的、生产级别的人工智能基础设施。在安全数据访问、监控、可观察性和合规执行方面仍然存在持续的差距。这些差距不是孤立的——它们是当人工智能扩展到生产环境时出现的结构性挑战，而不是仅仅停留在试点环境中。另一个在原型和生产之间的脱节发生在生产应用程序和数据库需要托管在本地或在严格管理的云账户中，但原型已经在基于云的数据库平台上开发的情况下。在成熟的组织中，人工智能工作负载被视为与其他受监管系统一样，具有相同的严谨性。这意味着一致的日志记录、严格的访问控制、持续的监控和跨团队明确的责任结构。它还需要从一开始就更紧密地将数据工程、平台工程、安全和合规功能对齐，而不是事后补充。这种方法的好处不仅仅在于风险降低。组织还体验到更快的部署周期、更少的生产故障和对人工智能系统的内部信心增强。在这种背景下，扩展人工智能不仅仅是关于模型创新，而是关于基础设施的成熟度。治理是架构的必备最终，关于人工智能治理的讨论需要超越政策，转向架构。治理通常被视为一个监督功能，但在实践中，它是通过定义数据如何访问和使用的系统来强制执行的。数据库不仅仅是一个存储层，它是安全、合规和运营完整性在人工智能栈中的控制点。随着人工智能更加深入地嵌入企业工作流程，控制点的重要性显著增加。每次模型与企业数据之间的交互都是一个治理事件，无论组织是否明确为其设计。通过优先考虑基础设施优先的治理，从数据库层开始，企业可以弥合试点和生产之间的差距。通过这样做，他们将人工智能从孤立的实验转变为一种在整个组织中嵌入的可持续、可扩展的能力。