把 AI 问数嵌入自己的系统，需要解决哪些产品问题？

很多企业不希望员工再打开一个新系统问数据。

他们更希望 AI 问数直接出现在已有工作入口里：

• •ERP 里的经营分析页；
• •CRM 里的客户看板；
• •门店系统里的店长工作台；
• •投放系统里的渠道复盘页；
• •内部 Agent 平台；
• •飞书、企微、钉钉或 Teams。

所以，“把 AI 问数嵌入自己的系统”会成为一个高频需求。

但这件事不只是放一个 iframe。

问题一：用户身份怎么传递

嵌入页面里最重要的问题是：当前是谁在问？

如果只是把一个统一链接嵌进去，所有用户看到的可能是同一套权限。

这在企业场景里不可接受。

店长、区域经理、总部运营、财务、市场、外部合作伙伴，应该看到不同的数据范围。

所以嵌入式 AI 问数必须处理身份映射、登录状态、组织关系和角色权限。

问题二：权限是否和主系统一致

用户在主系统里能看到哪些数据，AI 问数里也应该遵守同样边界。

否则会出现两类问题。

一种是主系统看不到的数据，被 AI 问出来了。

另一种是主系统可以分析的范围，AI 因为权限配置不同而答不出来。

真正可用的嵌入式分析，需要统一用户身份、数据源权限、行级权限、字段级权限和敏感字段策略。

问题三：会话能不能恢复

AI 问数不是一次性搜索。

用户可能先问“本周华东区销售额”，再追问“拆到城市看看”，然后继续问“哪些门店下降最明显”。

如果嵌入页面一刷新，历史上下文就丢了，体验会很差。

所以嵌入式 AI 问数需要处理会话恢复、历史对话、上下文延续和不同业务页面之间的入口关系。

问题四：上下文从哪里来

嵌入到 CRM 时，用户可能正在看某个客户。

嵌入到门店系统时，用户可能正在看某家门店。

嵌入到投放系统时，用户可能正在看某个渠道或活动。

AI 问数如果能理解当前页面上下文，就可以减少用户重复描述问题。

例如用户在某门店页面里问“最近下降是什么原因”，系统应该知道“最近”是什么时间范围，“这个门店”是哪一个门店。

这需要主系统和 AI 问数之间传递安全、明确、可审计的上下文。

问题五：哪些域名和系统可以嵌入

企业不应该让 AI 问数随便被任意网站嵌入。

嵌入能力需要可信域名、来源校验、链接时效、权限校验和安全策略。

否则，一个看似方便的嵌入入口，可能变成数据泄露入口。

AskTable 如何承接嵌入式 AI 问数

AskTable 的嵌入能力，不只是展示一个聊天框。

它要让企业把问数能力放进自己的业务系统，同时继续使用 AskTable 的数据源、语义层、权限治理、历史对话和分析能力。

BuildTable 负责把数据整理成 AI 可理解的数据基础。

AskTable 负责在嵌入场景里处理自然语言问数、追问、图表和权限内回答。

企业自己的系统负责承接业务入口和业务动作。

这样，用户在熟悉的页面里就能问数据，而不是在多个系统之间来回切换。

结论

嵌入式 AI 问数的重点不是嵌入，而是嵌入以后还能不能可信。

真正需要解决的是身份、权限、会话、上下文、安全和审计。

如果这些问题处理好了，AI 问数就不再是一个单独工具，而会变成企业业务系统里的数据智能入口。

参考来源

• •Microsoft Learn：Consume a Fabric Data Agent in Microsoft Copilot Studio
• •Microsoft Learn：Fabric data agent creation