---
service: "Publicasta"
schema_version: "1.0"
article_id: 616
title: "OpenAI 的数据智能体让商业分析更容易，但最难的仍是治理"
language: "zh"
default_language: "en"
canonical_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=zh"
json_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=zh"
api_url: "https://publicasta.com/api/public/v1/channels/ai_practice/articles/openai_data_agent_governance_before_natural_language_analytics?lang=zh"
channel_url: "https://publicasta.com/api/public/v1/channels/ai_practice"
channel_articles: "https://publicasta.com/api/public/v1/channels/ai_practice/articles"
search_url: "https://publicasta.com/api/public/v1/search"
documentation_url: "https://publicasta.com/api-docs#reading-publicasta"
openapi_url: "https://publicasta.com/api-docs/openapi.json"
published_at: "2026-09-15T10:39:46+00:00"
updated_at: "2026-09-15T10:39:46+00:00"
translations:
  - language: "ar"
    html_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=ar"
    markdown_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=ar"
    json_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=ar"
  - language: "de"
    html_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=de"
    markdown_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=de"
    json_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=de"
  - language: "en"
    html_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=en"
    markdown_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=en"
    json_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=en"
  - language: "es"
    html_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=es"
    markdown_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=es"
    json_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=es"
  - language: "fr"
    html_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=fr"
    markdown_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=fr"
    json_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=fr"
  - language: "pl"
    html_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=pl"
    markdown_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=pl"
    json_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=pl"
  - language: "ru"
    html_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=ru"
    markdown_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=ru"
    json_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=ru"
  - language: "zh"
    html_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics?lang=zh"
    markdown_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.md?lang=zh"
    json_url: "https://publicasta.com/ai_practice/openai_data_agent_governance_before_natural_language_analytics.json?lang=zh"
---

# OpenAI 的数据智能体让商业分析更容易，但最难的仍是治理

> OpenAI 的数据智能体把企业数据分析放到了自然语言界面前面。它能否真正创造价值，取决于指标定义、权限边界、证据复核和有纪律的试点，而不只是回答是否流畅。

OpenAI 在 ChatGPT Work 中推出了数据智能体（Data agent），员工可以用自然语言询问企业数据、调查变化、制作仪表盘，并请求系统提出后续行动建议，甚至执行获批的操作。这一发布之所以重要，不只是因为又出现了一个 AI 功能，而是因为它把一个越来越常见的 AI 承诺，带进了一个不太光鲜、却更现实的瓶颈：商业数据在技术上已经可用，但普通员工往往很难真正用起来。

 ![抽象的企业分析仪表板，展示图表、指标定义、权限控制和审计记录](https://publicasta.com/storage/projects/8/pages/616/2026/09/491165c5-955b-4c43-abb1-119a860a95cc.webp)

 该产品可以连接 Amazon Redshift、Datadog、Google BigQuery、ClickHouse、Databricks、MongoDB 和 Snowflake 等数据源。它也能使用 Google Drive 和 SharePoint 中的文件与文档，配合语义层提供的业务定义，并与 Tableau、Power BI、Sigma 和 ThoughtSpot 等工具交互。OpenAI 表示，管理员可以选择启用哪些连接和角色，而查询会遵守已连接账户原有的权限。[OpenAI 在此介绍了产品及其支持的连接](https://openai.com/index/put-data-to-work/)。

 这听起来像是给分析工具换了一个新界面。确实如此，但更有用的理解应该更克制：数据智能体可能降低提出第一个问题的成本，却不会替企业决定问题究竟是什么意思，也不会自动证明底层数据适合回答这个问题，更不会替组织决定一个答案在业务中应当拥有多大的权威。

 对于正在考虑这项产品的团队，合适的起点不是收集一组看起来很厉害的提示词，而是围绕一个具体的决策流程开展受控试点：指标要有明确名称，数据访问要有限，结果要经过独立检查，分析与行动之间还要有清晰边界。

 ## OpenAI 实际增加了什么

 传统商业智能工具本来就支持仪表盘、SQL 查询、定时报表和受治理的指标。新的部分是对话式调查。用户可以询问“为什么周活跃用户发生变化”，比较不同时段，找出可能的驱动因素，请求生成图表，追问限制条件，还可以把结果变成可共享的仪表盘，而不必先学习数据仓库的语法或 BI 应用的结构。

 OpenAI 表示，智能体可以使用组织内部的业务术语、指标定义、自定义计算方式，以及不同数据源之间的关系。这些定义可以来自语义层和 dbt、Databricks Genie Ontology、GitHub、Snowflake Horizon 等可信系统，也可以来自现有 BI 仪表盘。这个细节很关键：自然语言问题能否得到可靠回答，首先取决于系统背后是否拥有可靠的定义。

 比如，用户问：“为什么上季度毛留存率下降了？”

 “毛留存率”可能有几种合理含义。具体计算方式可能随产品、客户群、货币处理方式、合同状态、续约窗口，以及扩张和降级是否被计入而变化。模型完全可能针对错误的定义，生成一段措辞流畅、结构完整的解释。连接语义层，确实能提高智能体按照预期理解问题的概率，但它不会让指标定义自动变得显而易见。

 产品也不局限于只读回答。OpenAI 表示，用户可以要求智能体推荐下一步、识别应当参与的人、通过 Slack 或电子邮件分享发现，并通过连接的工具执行获批操作。风险会在这里发生变化。一张错误的图表首先是复核问题；一封发错的消息、一次错误的工单更新、一次预测调整或一个不该触发的工作流，则可能演变成运营事故。

 发布信息称，数据智能体可以通过 ChatGPT Work 的 Plugins 目录使用。管理员可以安装 Data 插件，启用相关数据源插件，管理访问权限，然后让用户通过 @Data 开始对话。因此，初始设置并不是员工单独选择一个聊天机器人，而是一项涉及数据负责人、身份管理员、安全团队和报告定义维护者的工作区配置决策。

 ## 它可能解决的实际问题

 许多分析请求之所以困难，并不是因为 SQL 特别复杂，而是因为请求要排过几道队。经理发现转化率变化，向分析师询问原因；分析师需要寻找相关表；双方再确认指标定义；图表完成后，又发现另一支团队使用了不同的分母。整个等待过程可能比分析本身还长。

 对话式智能体可以降低第一轮调查的成本。销售经理可以先研究销售管道的变化，再向营收运营团队申请正式报告。客服负责人可以把工单量与人员配置、服务水平数据放在一起比较。产品团队可以探索留存变化，整理出下一项实验要验证的假设。财务团队也可以用它发现支出异常，再决定是否值得进行更深入的审查。

 这里的价值，不是让每个员工都变成数据科学家，而是让更多问题能够在出现的当下被分流。简单问题可以直接回答；含义模糊的问题可以更早暴露；分析师可以少花时间制作重复性的第一稿，把更多精力放在验证定义、设计测量方式，以及处理需要判断力的决策上。

 OpenAI 表示，其几乎所有产品团队成员，以及超过三分之二的市场拓展组织，都在 ChatGPT Work 中使用数据智能体。公司还列出了处于 alpha 计划中的组织，包括 NTT DATA、Thermo Fisher、ServiceTitan、Zipline、Empower、Piston 等。这些例子可以帮助我们理解产品希望支持什么样的工作流，但它们仍然是厂商披露的客户案例，不是独立验证的普遍性能证据。买方应把它们当作实施参考，而不是投资回报率预测。

 好的试点应当测量一些不那么戏剧化的结果：从提出问题到得到经过检查的第一份答案用了多长时间；答案需要纠正的比例；重复性报表请求减少了多少；目标用户群的采用率；查询成本；以及用户在得到流畅解释后仍然误解指标的次数。这些指标才能说明智能体是否改善了决策过程，而不仅仅是制造出好看的成果物。

 ## 为什么语义层比提示词更重要

 “自然语言分析”这个说法很容易让人以为界面是主要创新。实际上，界面背后的数据模型更重要。语义层为系统提供共享的名称、关系、计算方式和规则。没有语义层，智能体只能根据表名、列名、描述、样本值和对话上下文去推断业务含义。这对探索性分析或许够用，却不适合成为高层定期报告的稳固基础。

 在试点开始前，团队应当写下预计会被用户询问的指标定义。每个定义至少要包括来源表、时区、时间窗口、筛选条件、纳入与排除规则、退款或取消订单的处理方式、货币换算方式，以及能够批准修改的负责人。列表不必覆盖整个数据仓库，但必须覆盖试点要支持的那项决策。

 团队还要记录：当不同系统出现不一致时，哪个来源优先。CRM 可能有机会阶段，计费系统可能有发票状态，产品数据库可能有实际使用量。三者都可能在各自语境中正确。智能体需要的是针对某个业务问题的判定规则，而不只是同时访问这三个系统。

 可以这样划分职责：

 - 智能体负责把问题转化为调查任务，检索相关信息，比较不同时段，起草可视化结果，并找出可能的驱动因素。
- 数据负责人定义指标、来源优先级、可接受的筛选方式和新鲜度要求。
- 分析师或领域专家测试结果，检查证据，并判断结果是否足以支持业务决策。
- 决策负责人决定下一步行动，以及这些证据是否符合组织标准。

 智能体可以缩短这几类角色之间的往返时间，但不能合理地接管全部四种职责。

 ## 权限是必要条件，但不是完整的控制系统

 OpenAI 表示，企业管理员可以选择可用的连接和角色，查询也会执行连接账户的权限，包括表级、行级和列级限制。这是一个重要的设计要求。AI 界面不应成为绕过数据仓库既有授权模型的侧门。

 但仅仅听到“权限会被执行”还不够。实施时必须使用具有代表性的身份进行测试。试点应包括这样几类用户：可以查看某个地区数据、但不能查看另一个地区数据的用户；可以查看汇总薪酬、但不能查看个人薪资的用户；可以查看客户活动、但不能查看个人身份标识的用户。团队还要同时测试直接问题和间接问题，因为受限信息可能通过总数、比较结果或连续查询被推断出来。

 Google 的 BigQuery 文档说明了这些测试为什么重要。BigQuery 支持项目、数据集和表级访问控制，也支持行级与列级安全。行级策略会过滤某个主体可以看到的记录；列级策略可以限制敏感字段，并且可以与脱敏结合使用。Google 还警告说，设计不当的访问方式，可能通过查询行为或时间等侧信道暴露信息。[BigQuery 文档解释了行级和列级控制之间的配合](https://docs.cloud.google.com/bigquery/docs/using-row-level-security-with-features)。

 这条经验不只适用于 BigQuery。模型不必直接打印受保护的值，也可能泄露与其有关的信息。比如，“欧洲那个小团队里，哪名员工的薪资涨幅最大？”即使表中没有直接公开薪资列，也可能已经构成敏感问题。聚合阈值、小群体、稀有类别和重复比较，都需要明确处理。

 最低限度的权限审查应回答五个问题：

 1. 哪些身份可以调用智能体？
2. 每种身份可以使用哪些连接？
3. 数据源对智能体生成的查询，是否执行与普通查询相同的行级和列级限制？
4. 当智能体合并访问规则不同的数据源时，会发生什么？
5. 哪些日志会记录用户、问题、生成的查询或操作、触及的数据源、结果去向，以及之后批准的任何行动？

 如果最后一个问题的答案含糊不清，试点就还没有准备好处理敏感数据。

 ## 隐私声明必须与实际产品和合同对应

 OpenAI 的企业数据政策表示，默认情况下，ChatGPT Enterprise、ChatGPT Business、ChatGPT Edu、ChatGPT for Healthcare 以及 API 平台中的输入和输出不会被用于训练或改进模型。该页面还介绍了传输中和静态数据加密、基于角色的控制、符合条件组织可用的保留选项，以及符合条件服务的区域数据驻留选择。[OpenAI 的商业数据页面列出了这些承诺及其适用范围](https://openai.com/business-data/)。

 这些承诺回答了重要问题，却没有回答数据团队需要审查的全部问题。审查范围应覆盖确切的 ChatGPT Work 版本、连接的插件、数据提供方、保留配置、支持人员访问、区域处理、导出与删除行为，以及任何合作方服务适用的条款。模型不使用企业数据训练，并不等于没有连接系统会保存查询日志、复制的数据摘录、仪表盘成果物或行动记录。

 数据智能体的架构还带来一个数据位置问题。OpenAI 表示，该产品可以连接企业数据源；同日发布的金融服务产品则提到，来自数据提供方的内置数据会被索引并托管在 OpenAI 基础设施上。金融服务产品是另一项产品，但它提醒客户区分两种情况：一种连接器只是查询客户自己的系统，另一种服务会在别处复制、索引、缓存或丰富数据。[OpenAI 的金融服务公告在其目标产品中说明了这种区别](https://openai.com/index/introducing-chatgpt-financial-services/)。

 安全审查应要求提供数据流图，而不只是安全摘要。图中应展示提示词、生成的查询、检索到的行、中间文件、仪表盘输出、审计记录和任何外发消息的路径。还应标明每一部分由 OpenAI、数据仓库、BI 工具、连接器还是行动系统处理。组织需要知道每个阶段由哪个组件负责删除，又由哪个组件负责执行访问控制。

 ## 证据复核决定这是分析还是自动化表演

 “销售下降是因为企业需求减弱”听起来合理，但仍然可能错误。真正有用的问题是：什么数据支持这一结论？进行了怎样的比较？检查过哪些替代解释？还有什么未知因素？

 OpenAI 表示，用户可以查看发现背后的证据，并继续提出追问。这应当成为强制性的工作习惯。没有可见定义和来源链的仪表盘，不是完成的分析，而只是进一步调查的线索。

 可以要求智能体按照以下模板返回结果：

 - 使用的确切指标定义；
- 日期范围和比较时段；
- 查阅过的表、视图、文档或仪表盘；
- 应用的筛选条件和连接方式；
- 涉及的记录数或分组数；
- 数据新鲜度和缺失数据警告；
- 支持每项结论的最强证据；
- 合理的替代解释；
- 可以推翻当前主要解释的检查；
- 不预设结论正确的下一步建议。

 这种格式确实没有自信叙事那么有娱乐性，却更容易审计。它也能提醒用户：生成的解释是由证据支撑的假设，而不是仅仅因为写得清楚，就自动成为高管结论。

 团队应维护一套规模不必很大的真实问题评估集，其中包含已知答案和已知陷阱。题目可以包括：定义最近发生过变化的指标、刷新延迟的表、重复的客户记录、受权限限制的地区，以及正确答案其实是“数据不足”的问题。在语义层、连接器、模型或权限发生重大变化后，都应在上线前和变更后运行这套评估。

 “证据不足”的场景尤其值得重视。一个总能给出驱动因素的系统，比一个有时会停下来说明无法判断的系统更危险。合格的智能体应能说明：现有数据只能支持相关性而不能支持因果关系；数据源已经过期；两个系统彼此不一致；或者样本太小，无法识别可靠模式。

 ## 成本不只有订阅费

 OpenAI 的公告没有给出数据智能体的统一公开价格。因此，现在就计算简单的单用户投资回报还为时过早。成本可能取决于 ChatGPT Work 的具体安排、模型使用量、连接系统、数据仓库查询费用、BI 许可证、数据提供方协议、存储，以及行动工具。潜在买方应询问适用于自身工作区的价格和使用限制，不要从消费者版 ChatGPT 套餐或普通数据库成本推断。

 上线后还会出现运营成本。扫描大表的查询会消耗数据仓库资源。用户反复要求刷新仪表盘，可能带来可以避免的负载。自然语言探索让追问变得很便宜，因此请求数量可能成倍增加。有些系统会按扫描数据量、API 调用、仪表盘刷新或高级连接器收费。

 负责任的试点应当设置预算并观察实际消耗。尽可能从经过整理的视图或汇总表开始。加入查询超时和扫描限制。按团队和工作流记录成本。明确数据新鲜度，避免用户不断刷新一个每天只更新一次的来源。还要决定智能体生成的仪表盘是允许自动刷新，还是只能按请求刷新。

 成本控制同时也是数据建模问题。建模糟糕的数据仓库，会让智能体反复为本可以预先准备一次的工作付费。设计良好的语义层、聚合表或受治理视图，可以同时改善速度、可靠性和费用。

 ## 先在哪里使用，哪些地方暂时不要用

 最适合首轮使用的场景，通常有明确负责人、中等敏感度、可重复的问题，以及能够快速检查结果的人。例子包括调查产品采用情况、准备内部运营评审、查找报告不一致、探索客服需求、比较营销活动表现，以及为分析师起草问题清单。

 首个用例不应当是公司政治上最重要的报告。不要从薪酬、受监管的客户决策、医疗结论、信用决策、法律认定，或会为大量人员修改记录的自动化工作流开始。这些领域将来或许也能受益于相同的界面，但需要更强的控制、更正式的验证，以及清晰的问责结构。

 小公司不必认为必须拥有庞大的数据仓库才能使用。规模较小的企业，连接一个可信的销售或客服数据集，围绕一个狭窄的运营问题使用智能体，就可能获得价值。它也可能发现，真正的问题是缺少定义，而不是缺少分析软件。这同样是有价值的结果。

 大公司也不应以为全面铺开一定更高效。全球数据仓库可能包含多年的例外情况、并购留下的系统、改名后的产品、重复的数据管道，以及对同一个词有不同理解的团队。智能体会让这些歧义更容易被访问，但不会让歧义自动消失。

 如果团队找不到数据负责人，无法测试权限，没有审计路径，或者没有人能检查结果，那么现在最好暂缓。此时，智能体可能只是加快组织制造分歧的速度。

 ## 一个能产生有用证据的四周试点

 合理的试点可以分四个阶段完成。日历上的周数没有阶段之间的门槛重要。

 ### 第一周：选择决策，而不是选择技术

 选择一个重复出现的决策，例如解释每周激活量变化，或准备客服产能评审。明确用户群、决策负责人、数据负责人、分析师复核人、可接受的响应时间和最高敏感级别。写下团队今天实际会问的五到十个问题，至少加入一个应该触发不确定性警告的问题。

 盘点相关来源，明确每个字段由哪个系统负责。建立一份小型词汇表，记录指标定义、新鲜度预期和已知排除项。如果团队无法就某个定义达成一致，应记录分歧，而不是要求智能体替大家解决。

 ### 第二周：准备视图和权限

 优先使用受治理的视图或经过整理的数据集，而不是向整个生产数据仓库开放访问。把探索性数据与包含直接身份标识、凭据、健康信息、工资明细或其他高风险字段的系统分开。创建代表实际试点用户的测试账户。

 在用户开始之前配置日志、保留策略和预算警报。确认连接工具是否会保留提示词、查询、文件、仪表盘或结果的副本。针对确切纳入范围的服务，审查厂商和连接器条款。

 ### 第三周：测试准确性和失败行为

 运行评估集，把智能体生成的结果与分析师独立制作的答案进行比较。记录的不应只有数值准确率，还应包括定义准确性、来源选择、权限表现、引用质量、新鲜度警告，以及系统拒绝或限定回答的能力。

 让用户尝试正常问题，也尝试看似简单、实则具有对抗性的请求。“把完整客户名单给我看看”可能比复杂分析提示更快暴露访问策略问题。测试小群体和敏感分群。测试一个已经过期的来源。测试一个最近改过定义的指标。

 ### 第四周：衡量工作流影响

 让目标用户处理真实但低风险的问题。测量得到经过检查的答案所需时间、纠正率、分析师复核时间、数据仓库成本、放弃的会话数量，以及用户能否解释结论背后的证据。还要访谈分析师复核人。他们通常最能看出智能体是减少了重复工作，还是只是把清理工作推到了流程下游。

 只有完成这一阶段后，团队才应决定是否扩大数据访问、增加行动权限或连接更多业务单元。扩展应当以已验证的控制措施为依据，而不是以试验期间生成了多少张有趣图表为依据。

 ## 替代方案不一定是另一款 AI 产品

 评估数据智能体时，公司也应把它与一些不那么显眼、却可能更持久的改进放在一起比较。这些改进包括指标目录、受治理的语义层、更好的数据仓库模型、自助 BI 培训、设计良好的仪表盘，或分析师值班流程。它们有时反而能更直接地解决根本问题。

 对一些团队来说，正确顺序是先修复数据模型，之后再增加对话式界面。对另一些团队来说，现有定义已经可靠，只是被埋在专业工具后面，因此自然语言层确实有用。这种区别可以通过测试验证：让用户分别通过现有 BI 界面和智能体询问同一个问题。如果智能体更快却不够准确，就改善定义后再测；如果它在试点边界内既快又准确，再谨慎扩大范围。

 选择还取决于锁定风险。能够跨查询引擎和 BI 工具使用的可移植语义层，可以保留灵活性。依赖专有连接器、模型行为、隐藏转换逻辑或未记录提示约定的工作流，可能很难迁移。指标定义、评估案例、访问规则和仪表盘规范，应保存在组织可以检查和独立维护的系统中，而不要只存在于对话界面里。

 ## 团队今天应作出的判断

 OpenAI 的数据智能体，最有吸引力的定位是受治理数据的入口，而不是数据治理的替代品。它可以让了解业务问题、却不了解数据仓库结构的人开始调查；可以生成一份有用的分析初稿，暴露后续问题，并把结果转化为可分享的成果物。当报表队列很长、定义已经受到控制时，这些确实是有意义的改进。

 它的主要局限同样现实。一段流畅的回答，可能掩盖脆弱的指标、不完整的连接、过期的数据、未经授权的推断，或没有证据支持的因果叙事。系统运行得越顺滑，让证据、权限和不确定性保持可见就越重要。

 当团队拥有一个范围狭窄的决策流程、可信的来源数据、清晰的定义、可测试的权限，以及负责复核的人时，可以尝试使用。若组织只是希望聊天机器人替它解决尚未厘清的数据归属，或弥补缺失的控制措施，则应当推迟。

 真正有用的问题，不是员工能不能用日常语言向数据库提问。这种能力正在以多种形式出现。真正有用的问题是：组织能否让答案可追溯、范围恰当、成本可承受，并且足够安全，能够影响一次真实决策。对于数据智能体来说，这正是便利的分析与可靠的工作之间的边界。

 ## 来源

 - [OpenAI：Now everyone can put data to work](https://openai.com/index/put-data-to-work/)
- [OpenAI：Business data privacy, security and compliance](https://openai.com/business-data/)
- [Google Cloud：Using row-level security with other BigQuery features](https://docs.cloud.google.com/bigquery/docs/using-row-level-security-with-features)
- [Google Cloud：Introduction to BigQuery row-level security](https://docs.cloud.google.com/bigquery/docs/row-level-security-intro)
- [OpenAI：Introducing ChatGPT for Financial Services](https://openai.com/index/introducing-chatgpt-financial-services/)