Many Companies Use AI. Few Know How to Build an AI-Native Enterprise Data Platform.许多公司都在使用人工智能，但很少有公司知道如何构建人工智能原生企业数据平台。

Many organizations have already adopted AI to improve everyday productivity over the past few years. AI has rapidly become part of enterprise workflows:过去几年，许多组织已经采用人工智能来提高日常生产力。人工智能已迅速成为企业工作流程的一部分：

• Building internal chatbots to answer HR, IT, or policy questions.构建内部聊天机器人以回答人力资源、IT 或政策相关问题。
• Using ChatGPT or Microsoft Copilot to search and summarize documents.使用 ChatGPT 或 Microsoft Copilot 来搜索和总结文档。
• Assisting developers with code generation and debugging.协助开发人员进行代码生成和调试。
• Drafting reports, emails, meeting notes, and business presentations.起草报告、电子邮件、会议纪要和商业演示文稿。

These applications have undoubtedly improved individual productivity. But if we believe that’s where AI’s potential ends, we’re missing the important parts. The reality is that many companies stop here and fail to tap into AI’s most transformative capabilities.这些应用无疑提高了个人生产力。但如果我们认为人工智能的潜力仅止于此，那就忽略了重点。现实情况是，许多公司止步于此，未能挖掘人工智能最具变革性的能力。

AI can do much more. In my view, one of its most powerful applications lies in transforming the enterprise data ecosystem.人工智能可以做得更多。在我看来，它最强大的应用之一在于重塑企业数据生态系统。

Beyond Chatbot: What AI Agents Actually Do超越聊天机器人：人工智能智能体（AI Agents）的实际作用

Data teams in many organizations spend a significant amount of time every day answering questions from business users. For example, if you are a data analyst working for an E-commerce platform, you may receive tons of questions from business like: “Which product categories contributed most to revenue growth in Southeast Asia last quarter?“在许多组织中，数据团队每天花费大量时间回答业务用户的问题。例如，如果您是一家电子商务平台的数据分析师，可能会收到大量来自业务部门的问题，如：“上一季度东南亚地区哪些产品类别对收入增长贡献最大？”

As a data analyst, here’s what you typically do: 作为数据分析师，您通常会进行以下操作：

Business Question
      ↓
Write SQL
      ↓
Export Data
      ↓
Create Charts
      ↓
Explain Findings

Now, you hand this over to an AI agent, and the workflow becomes:现在，如果您将其交给人工智能智能体，工作流程将变成：

Business Asks
      ↓
Agent Retrieves Semantic Information
      ↓
Generates SQL
      ↓
Returns Explanation

On the surface, the business user is still just having a conversation with AI by throwing a question to get an answer. Feels a lot like chatting with a bot, doesn’t it? But working with an AI agent is fundamentally different from chatting with a chatbot.表面上看，业务用户仍然只是通过向人工智能提问来获取答案。听起来很像是在和聊天机器人对话，对吧？但与人工智能智能体协作与单纯和聊天机器人对话有着本质区别。

What is an AI Agent? 什么是人工智能智能体？

An AI agent is an autonomous system that perceives its environment, makes decisions, and takes concrete actions to achieve a goal. 人工智能智能体是一个自主系统，它能够感知环境、做出决策并采取具体行动以实现目标。

The key difference between an AI agent and a chatbot is that an AI agent can take actions instead of simply generating responses. While chatbots primarily answer questions through conversations, AI agents execute multi-step tasks, interact with software and tools, make decisions, and work toward completing a specific goal autonomously.人工智能智能体与聊天机器人的关键区别在于，智能体可以采取行动，而不仅仅是生成回复。聊天机器人主要通过对话回答问题，而人工智能智能体则能自主执行多步骤任务、与软件和工具交互、做出决策，并致力于完成特定目标。

To be more specific, the key differences between them are:具体而言，它们之间的主要区别在于：

Although the business users may feel like they’re just having a conversation with the AI agent, behind the scenes the agent is busy executing a series of actions—retrieving relevant context, generating and running SQL queries, interpreting the results, and then delivering a polished answer.尽管业务用户可能觉得只是在与人工智能智能体对话，但在幕后，智能体正忙于执行一系列操作——检索相关背景信息、生成并运行 SQL 查询、解读结果，最后提供完善的答案。

In the world of data, these AI agents are usually called data agents. They focus on retrieving, querying, analyzing, and explaining enterprise data through natural language interactions. Most data platforms, like Microsoft Fabric, Snowflake, and Databricks, have data agents integrated into themselves. For example, Fabric has the Fabric data agent, Snowflake has Cortex Analyst, and Databricks has AI/BI Genie. If you don’t want to be tied to a specific platform, you can choose Julius AI or Tellius, which can connect to most mainstream data platforms, either natively or indirectly.在数据领域，这些人工智能智能体通常被称为“数据智能体”（Data Agents）。它们专注于通过自然语言交互来检索、查询、分析和解释企业数据。大多数数据平台（如 Microsoft Fabric、Snowflake 和 Databricks）都内置了数据智能体。例如，Fabric 有 Fabric 数据智能体，Snowflake 有 Cortex Analyst，Databricks 有 AI/BI Genie。如果您不想绑定在特定平台上，也可以选择 Julius AI 或 Tellius，它们可以通过原生或间接方式连接到大多数主流数据平台。

Data agents are designed to act as AI data analysts. They reduce the repetitive work of pulling data, writing routine queries and generating standard reports so that analysts spend less time performing repetitive data retrieval and reporting tasks, and more time on work that requires human judgment and critical thinking. Business users also benefit. They get analytical support 24/7 without waiting, and the agent can proactively surface insights instead of requiring someone to manually explore the data.数据智能体的设计初衷是充当人工智能数据分析师。它们减少了提取数据、编写常规查询和生成标准报告等重复性工作，使分析师能将时间投入到需要人类判断和批判性思维的工作中。业务用户也从中受益：他们可以随时获得分析支持，无需等待，且智能体能够主动呈现洞察，而无需人工手动探索数据。

Looks beautiful? But in practice, simply relying on data agents often leads an organization to the following problems:听起来很美好？但在实践中，单纯依赖数据智能体往往会导致组织面临以下问题：

• Ambiguous business terminology模糊的业务术语
• Multi-step reasoning多步骤推理
• Business rules业务规则
• Inconsistent answers答案不一致
• Retrieval quality检索质量
• Handling edge cases that sit outside predefined semantic layers处理预定义语义层之外的边缘情况
• Keeping up when data schemas change应对数据模式（Schema）变更
• Maintaining accuracy across different business contexts在不同业务背景下保持准确性

These aren’t small annoyances. For example, when the business user typed “What is the percent of revenue growth in Southeast Asia last quarter?“, it would be very frustrating if the agent answers with no data provided or provides incorrect number.这些并非小麻烦。例如，当业务用户输入“上一季度东南亚地区的收入增长百分比是多少？”时，如果智能体无法提供数据或提供错误数字，会让人感到非常沮丧。

When a data agent gets something wrong, it doesn’t just frustrate the users. To make matters worse, it can feed bad information into a business decision. 当数据智能体出错时，不仅会让用户感到沮丧，更糟糕的是，它可能会将错误信息输入到业务决策过程中。

The bottom line? Relying on data agents alone isn’t enough. The real path forward should be connecting data platforms with enterprise AI architectures.结论是什么？仅靠数据智能体是不够的。真正的前进路径应该是将数据平台与企业级人工智能架构相结合。

Where AI Fits in the Data Platform人工智能在数据平台中的位置

A typical enterprise data platform workflow looks like this: data engineers design the architecture, implement the creation of ETL pipelines and data warehouse and manage the data governance. Business users raise business-related questions, data analysts create BI reports or dashboard. Business users then use dashboard for analysis and generate insights. 典型的企业数据平台工作流程如下：数据工程师设计架构、实现 ETL 管道创建和数据仓库构建，并管理数据治理。业务用户提出业务相关问题，数据分析师创建 BI 报表或仪表板。随后，业务用户使用仪表板进行分析并生成洞察。

This workflow has run for decades and effectively supported and empowered many businesses. Then AI came. People start thinking:这一工作流程已经运行了几十年，有效地支持并赋能了许多企业。然后人工智能出现了。人们开始思考：

• Why do business users keep asking the same questions?为什么业务用户总是问同样的问题？
• Why do data engineers spend hours validating ETL jobs?为什么数据工程师要花数小时验证 ETL 作业？
• Why do analysts manually investigate KPI changes?为什么分析师要手动调查 KPI 的变化？

Quickly, AI is embedded into the data platform. Data agents are used. Agentic coding is introduced. Then come new questions:人工智能很快被嵌入到数据平台中。数据智能体被使用，智能体编码（Agentic coding）被引入。随之而来的是新的问题：

• Why do we trust AI-generated answers without measuring their quality?为什么我们在不衡量质量的情况下就信任人工智能生成的答案？
• Why does AI become less reliable as business rules grow more complex? 为什么随着业务规则变得复杂，人工智能的可靠性反而下降了？

These aren’t isolated problems. They’re symptoms of a traditional data platform that was designed for storing and reporting data instead of collaborating with AI.这些并非孤立的问题。它们是传统数据平台的症状，这些平台的设计初衷是存储和报告数据，而非与人工智能协作。

Maybe it’s time for us to rethink the architecture itself rather than treat AI as an add-on application to existing data platform.也许是时候重新思考架构本身，而不是将人工智能视为现有数据平台的附加应用了。

For the AI architecture thing, there’s no standard answer yet. There might never be a standard answer. The AI architecture can be customised by industry, enterprise scale, business strategy and data/AI technology maturity level.关于人工智能架构，目前还没有标准答案，未来可能也不会有。人工智能架构可以根据行业、企业规模、业务战略以及数据/人工智能技术成熟度进行定制。

In my view, organizations should include at least the 3 key AI components in their data workflow – Data Agent, AI QA Agent and AI Governance & Observability. 在我看来，组织至少应在数据工作流程中包含三个关键的人工智能组件：数据智能体、人工智能 QA 智能体，以及人工智能治理与可观测性。

Enterprise AI doesn’t eliminate the need for robust data engineering implemented by humans. Instead, AI can enhance it. No matter how smart AI agents are, before they can answer business questions or validate data quality, the underlying data platform must already be reliable and scalable. In a previous article, What Can We Do When Memory Becomes the New Bottleneck in Data Engineering?, I discussed one of the challenges that every data engineer would face when processing large-scale datasets and provided several practical solutions for different scenarios. 企业级人工智能并不能消除对人工实现稳健数据工程的需求，反而可以增强它。无论人工智能智能体多么聪明，在它们回答业务问题或验证数据质量之前，底层数据平台必须是可靠且可扩展的。在之前的文章《当内存成为数据工程的新瓶颈时，我们能做什么？》中，我讨论了每位数据工程师在处理大规模数据集时都会面临的挑战，并为不同场景提供了几种切实可行的解决方案。

Let’s go back to the problems that most data agents face:让我们回到大多数数据智能体面临的问题：

• Ambiguous business terminology
• Multi-step reasoning
• Business rules
• Inconsistent answers
• Retrieval quality
• Handling edge cases that sit outside predefined semantic layers
• Keeping up when data schemas change
• Maintaining accuracy across different business contexts

To resolve these issues, we can use AI Agent SDKs to either build autonomous systems from scratch or extend the capabilities that existing data agents don’t provide out of the box. The most popular tools in the market include LangGraph, Microsoft Agent Framework, or Google ADK. I’ll discuss how to build a data agent in my next article.为解决这些问题，我们可以使用人工智能智能体 SDK 从零开始构建自主系统，或扩展现有数据智能体不具备的功能。目前市场上最流行的工具包括 LangGraph、Microsoft Agent Framework 或 Google ADK。我将在下一篇文章中讨论如何构建数据智能体。

How AI Is Transforming Data Quality Assurance人工智能如何重塑数据质量保证（QA）

Imagine you are working for a healthcare company. Every day, you need to process millions of patient records—lab results, insurance claims, clinical notes, prescription logs. When the data arrive, you must ensure your pipelines ingest, transform and load them correctly because it’s not just about clean dashboards; more importantly, it’s about patient safety, regulatory compliance, and financial accuracy. So you prepare the list to check:想象一下您在一家医疗保健公司工作。每天，您都需要处理数百万条患者记录——实验室结果、保险索赔、临床记录、处方日志。数据到达时，您必须确保管道能够正确摄取、转换和加载，因为这不仅关乎整洁的仪表板，更关乎患者安全、合规性和财务准确性。因此，您准备了一份检查清单：

• Row counts (did we drop records during ingestion?)行数检查（摄取过程中是否丢失了记录？）
• NULL checks (are required fields empty?)NULL 值检查（必填字段是否为空？）
• Duplicate detection (same record entered twice?)重复检测（同一记录是否输入了两次？）
• Schema validation (right data types, right column names?)模式验证（数据类型和列名是否正确？）
• Range checks (is a blood pressure reading of 999 realistic?)范围检查（血压读数 999 是否现实？）
• Format validation (do date fields follow YYYY-MM-DD? Are email fields actually emails?)格式验证（日期字段是否遵循 YYYY-MM-DD？电子邮件字段是否真的是电子邮件？）
• Referential integrity (does a patient ID in the claims table exist in the patient table?)引用完整性（索赔表中的患者 ID 是否存在于患者表中？）
• Freshness checks (did today’s data actually arrive on time?)新鲜度检查（今天的数据是否按时到达？）

Based on this list, you define rules, schedule jobs to run these checks, and get alerts when something breaks. Mostly you use SQL-based validation queries, YAML or JSON rule configurations, and dashboard monitors showing pass/fail rates. Your workflow works until it doesn’t. Why? Because they only catch what you already know to look for. If you didn’t anticipate a failure mode, there’s no rule for it. Therefore, you have to manually change the rules. But for an environment with huge datasets or with data changing frequently, the rule library maintenance becomes a nightmare.基于此清单，您定义规则、安排作业来运行检查，并在出现故障时接收警报。您大多使用基于 SQL 的验证查询、YAML 或 JSON 规则配置，以及显示通过/失败率的仪表板监视器。您的工作流程在失效前一直有效。为什么？因为它们只能捕捉到您已知需要查找的问题。如果您没有预见到某种故障模式，就不会有相应的规则。因此，您必须手动更改规则。但对于拥有海量数据集或数据频繁变化的环境，维护规则库将是一场噩梦。

AI-Powered QA doesn’t replace traditional checks. Instead, it adds a layer that learns.人工智能驱动的 QA 并不会取代传统检查，而是增加了一个能够学习的层级。

Traditionally, you follow the process to complete your data QA.传统上，您遵循流程来完成数据 QA。

Define rules
      ↓
Run checks
      ↓
Get pass/fail alerts
      ↓
Investigate manually

But when you hand your QA work over to AI models, they learn what normal data looks like from historical patterns rather than solely rely on predefined rules. They catch anomalies like subtle distribution shifts, unusual correlations between fields, emerging data drift that signals a pipeline issue upstream. These anomalies haven’t yet been added to the checklist by you in advance. For the healthcare example, AI-powered QA might catch that lab results from a specific clinic which suddenly has test values 10x higher than their historical average. Traditional QA would give you a pass because the dataset has the same format, valid ranges, no NULLs and no duplicates. But AI flags it because it doesn’t look right compared to what that clinic has always produced. Embedded with AI, the whole QA workflow becomes:但当您将 QA 工作交给人工智能模型时，它们会从历史模式中学习正常数据是什么样子的，而不是仅仅依赖预定义的规则。它们能捕捉到微妙的分布偏移、字段间的不寻常相关性，以及预示上游管道问题的异常数据漂移。这些异常情况您尚未提前添加到检查清单中。在医疗保健的例子中，人工智能驱动的 QA 可能会发现某家诊所的实验室结果突然比其历史平均值高出 10 倍。传统 QA 会判定通过，因为数据集格式、有效范围、NULL 值和重复项检查均正常。但人工智能会标记它，因为它与该诊所一贯产生的数据不符。嵌入人工智能后，整个 QA 工作流程变为：

Learn patterns
      ↓
Detect anomalies
      ↓
Surface with context
      ↓
Explain possible cause

Similar to data agents, there are also a few AI-powered QA tools available to support enterprise QA. Popular tools include Great Expectations (rule-based primarily, with extensibility for anomaly detection through custom expectations and integrations), Soda (combining rule-based checks with ML-powered anomaly detection via Soda Cloud), Databricks Lakehouse Monitoring (native profiling and drift detection for data and ML model features) and AWS Glue Data Quality (automated quality rule recommendations and anomaly detection within the Glue ecosystem). 与数据智能体类似，目前也有一些人工智能驱动的 QA 工具可用于支持企业 QA。流行的工具包括 Great Expectations（主要基于规则，但可通过自定义期望和集成进行扩展以实现异常检测）、Soda（结合了基于规则的检查与通过 Soda Cloud 进行的机器学习异常检测）、Databricks Lakehouse Monitoring（针对数据和机器学习模型特征的本地分析和漂移检测）以及 AWS Glue Data Quality（Glue 生态系统内的自动质量规则推荐和异常检测）。

For example, if you’d like to combine your original rule-based QA with AI for the healthcare company data anomaly detection, you can use the following method.例如，如果您想将原始的基于规则的 QA 与人工智能相结合，以进行医疗保健公司的数据异常检测，可以使用以下方法。

from soda.scan import Scan
from soda.contracts.contract import Contract
from soda.contracts.check import AnomalyCheck, SchemaCheck, UserDefinedCheck

# Traditional checks: rules you define
traditional_contract = Contract(
    checks=[
        SchemaCheck(
            name="Schema validation",
            fail_if_missing_columns=["patient_id", "diagnosis_code", "lab_result"]
        ),
        UserDefinedCheck(
            name="No duplicate patient records per day",
            query="""
                SELECT patient_id, admission_date, COUNT(*)
                FROM patient_records
                GROUP BY patient_id, admission_date
                HAVING COUNT(*) > 1
            """,
            fail_if_rows_returned=True
        )
    ]
)

# AI-powered checks: anomaly detection based on learned patterns
ai_contract = Contract(
    checks=[
        AnomalyCheck(
            name="Anomaly: lab result distribution shift",
            metric="mean(lab_result)",
            anomaly_detection="ml",
            sensitivity=0.8,
            fail_if_anomaly_severity="critical"
        ),
        AnomalyCheck(
            name="Anomaly: missing diagnosis codes",
            metric="missing_count(diagnosis_code)",
            anomaly_detection="ml",
            fail_if_anomaly_severity="warning"
        ),
        AnomalyCheck(
            name="Anomaly: record volume by source",
            metric="row_count",
            anomaly_detection="ml",
            group_by=["data_source"],  # monitors each hospital's volume independently
            fail_if_anomaly_severity="critical"
        )
    ]
)

# Run the scan
scan = Scan()
scan.set_data_source_name("healthcare_db")
scan.add_contracts([traditional_contract, ai_contract])
scan.set_verbose(True)
scan.execute()

In addition to anomaly detection without predefined thresholds and root cause investigation, AI-powered QA methods have the capabilities of contextual understanding and pattern recognition across multiple dimensions. AI models can continuously relearn what “normal” means rather than wait for someone to update thresholds manually. With these features, AI greatly improves the efficiency and accuracy of data QA workflows.除了无需预定义阈值的异常检测和根本原因调查外，人工智能驱动的 QA 方法还具备跨多个维度的上下文理解和模式识别能力。人工智能模型可以持续重新学习“正常”的定义，而无需等待人工手动更新阈值。凭借这些特性，人工智能极大地提高了数据 QA 工作流程的效率和准确性。

AI Can Get it Wrong. How Do We Trust It?人工智能可能会出错。我们该如何信任它？

Many people think AI governance means security: role-based access, data masking and confidential information safely stored. But after AI is fully integrated to your enterprise system, governance is about something broader: can you explain and stand behind every answer your AI gives?许多人认为人工智能治理意味着安全：基于角色的访问控制、数据脱敏和敏感信息安全存储。但当人工智能完全集成到企业系统后，治理的含义更加广泛：您能否解释并为人工智能给出的每一个答案负责？

Imagine you are a portfolio manager in an investment firm. One day, you asked a data agent: “Which funds exceeded their ESG targets last quarter?” The agent pulled data, ran the numbers and returned an answer. A month later, you asked the same question but got a different answer. In the past month, nobody changed the query or updated the data. And nobody knew what shifted inside the agent and why.想象一下您是一家投资公司的投资组合经理。有一天，您问数据智能体：“上一季度哪些基金超过了 ESG 目标？”智能体提取数据、运行计算并返回了答案。一个月后，您问了同样的问题，却得到了不同的答案。过去一个月里，没有人更改查询或更新数据。也没有人知道智能体内部发生了什么变化以及原因。

Now AI governance matters. Unlike traditional IT governance or data governance, AI governance and observability usually focus on the following areas:现在，人工智能治理变得至关重要。与传统的 IT 治理或数据治理不同，人工智能治理和可观测性通常关注以下领域：

Prompt Versioning提示词版本控制（Prompt Versioning）

Prompt versioning means treating prompts like any other software artifact. Similar to the process in software engineering, AI engineers store prompt versioning in Git, tag releases, and log which version was active when a query ran. So when the portfolio manager asks why last month’s answer is different, the first place to look is whether the prompt changed. If it did, you have your explanation. If it didn’t, you need to dig deeper. It matters for data agents because a small wording change can shift results without anyone realizing it.提示词版本控制意味着像对待其他软件制品一样对待提示词。类似于软件工程流程，人工智能工程师将提示词版本存储在 Git 中，标记发布版本，并记录查询运行时的活动版本。因此，当投资组合经理询问为什么上个月的答案不同时，首先要查看的就是提示词是否发生了变化。如果是，您就找到了解释；如果不是，则需要深入挖掘。这对数据智能体很重要，因为微小的措辞变化就可能在无人察觉的情况下改变结果。

Hallucination Detection幻觉检测

Data agents hallucinate and it’s dangerous because a hallucinated number looks like a real number. That’s why hallucination detection is one of the hottest areas that many AI experts research on.数据智能体会产生幻觉，这很危险，因为幻觉产生的数字看起来像真实的数字。这就是为什么幻觉检测是许多人工智能专家研究的最热门领域之一。

When you take the hallucination detection for data agents, you can verify outputs against source data. Methods include SQL execution validation, results grounding and confidence scoring.在进行数据智能体的幻觉检测时，您可以根据源数据验证输出。方法包括 SQL 执行验证、结果溯源和置信度评分。

Tracing追踪（Tracing）

Tracing is the “what happened” layer, which records every step the AI application took. If you want to trace a data agent, you can use tools to record the user’s question, how it was interpreted, which SQL was generated, which tables were queried, what results came back, and how the final answer was composed. LLM tracing tools include LangSmith, Weights & Biases, and Phoenix, which are commonly used alongside data platforms.追踪是“发生了什么”层，它记录人工智能应用采取的每一步。如果您想追踪数据智能体，可以使用工具记录用户的问题、它是如何被解读的、生成了什么 SQL、查询了哪些表、返回了什么结果，以及最终答案是如何构成的。LLM 追踪工具包括 LangSmith、Weights & Biases 和 Phoenix，它们通常与数据平台一起使用。

Monitoring监控

Monitoring is tracing plus time. Just as you monitor data pipelines for freshness and anomalies, you monitor AI agents for behavioral drift. You monitor your AI tools by signals. For example, you can monitor the signals like query success rate, answer latency, answer refusal rate and user feedback trends for a data agent. As these signals are critical for you to determine if your agent is actually good at its job, AI monitoring system is equally important to AI-empowered QA system. The two monitoring systems should feed into the same observability stack.监控是追踪加上时间维度。正如您监控数据管道的新鲜度和异常一样，您也需要监控人工智能智能体的行为漂移。您可以通过信号监控人工智能工具。例如，您可以监控数据智能体的查询成功率、答案延迟、答案拒绝率和用户反馈趋势。由于这些信号对于判断智能体是否胜任工作至关重要，人工智能监控系统与人工智能赋能的 QA 系统同样重要。这两个监控系统应接入同一个可观测性栈。

Security安全性

In addition to the traditional security questions discussed by data governance, there are specific concerns brought by AI data agents – query injection, data exfiltration through prompting and over-permissioning.除了数据治理讨论的传统安全问题外，人工智能数据智能体还带来了特定的担忧——查询注入、通过提示词进行数据泄露，以及权限过大。

• Query injection: When a user types a question, the agent generates query which has a chance to slip in destructive commands. The solution to this problem is to use parameterized queries, enforce read-only execution, and block any statement that tries to modify data rather than run generated query directly.查询注入：当用户输入问题时，智能体生成的查询有可能混入破坏性命令。解决此问题的方案是使用参数化查询、强制执行只读执行，并拦截任何试图修改数据的语句，而不是直接运行生成的查询。
• Data exfiltration through prompting: A user could craft a prompt that tricks the agent into pulling sensitive data and sending it somewhere it shouldn’t go. The solution is to conduct tool-call allowlisting and output scanning which allow the agent only to do what you’ve explicitly permitted and check anything leaving the system.通过提示词进行数据泄露：用户可能会精心设计一个提示词，诱导智能体提取敏感数据并发送到不该发送的地方。解决方案是进行工具调用白名单限制和输出扫描，仅允许智能体执行您明确许可的操作，并检查离开系统的任何内容。
• Over-permissioning: AI agents can run with a broad service account that sees everything. So there’s risk that they serve data to the user who shouldn’t have access to. The solution is to pass the end user’s security context through to the data layer so every generated query respects the user’s actual permissions.权限过大：人工智能智能体可能以一个能看到所有内容的广泛服务账户运行。因此存在它们向无权访问的用户提供数据的风险。解决方案是将最终用户的安全上下文传递到数据层，以便每个生成的查询都尊重用户的实际权限。

Human Feedback人类反馈

Only user feedback helps you find the room for improvement that you never anticipated. There are many ways to collect feedback.只有用户反馈才能帮助您找到未曾预料到的改进空间。收集反馈的方法有很多。

Human feedback matters because real users will ask questions you’ve never anticipated. In order to collect feedback, the simplest method is to allow users to thumbs-up / thumbs-down on every answer, with an optional comment field. But when AI governance and observability is set properly in the enterprise AI architecture, you can get more from the system. If a user marks an answer as incorrect, the system can capture the full trace so that AI engineers can investigate. The feedback improves the evaluation dataset, identifies confusing business terms, highlights queries where the agent consistently struggles and tell you where to invest in prompt engineering over time.人类反馈之所以重要，是因为真实用户会提出您从未预料到的问题。收集反馈最简单的方法是允许用户对每个答案进行“点赞/点踩”，并提供可选的评论字段。但当企业人工智能架构中正确设置了人工智能治理和可观测性时，您可以从系统中获得更多。如果用户将答案标记为不正确，系统可以捕获完整轨迹，以便人工智能工程师进行调查。反馈能改进评估数据集，识别令人困惑的业务术语，突出智能体始终难以处理的查询，并告诉您随着时间的推移应在何处投入提示工程。

Governance and observability sound bureaucratic. But in practice, they differentiate a demo from something you can trust and make decisions on. As the three key components of an AI-driven enterprise data architecture, data agents, AI-empowered QA, and AI Governance work together to build a trustworthy collaborator with humans.治理和可观测性听起来很官僚。但在实践中，它们将演示产品与您可以信任并据此做出决策的产品区分开来。作为人工智能驱动的企业数据架构的三个关键组件，数据智能体、人工智能赋能的 QA 和人工智能治理共同协作，构建了一个值得人类信赖的合作伙伴。

Thank you for your reading!感谢您的阅读！

Buy me a coffee if you like this article! 如果您喜欢这篇文章，请请我喝杯咖啡！