在巴塞罗那举行的 FabCon 与 SQLCon 2026，把讨论重点放在了一个比“让模型更聪明”更基础的问题上：企业是否已经准备好让 Copilot 和智能体安全、稳定地使用数据？Microsoft Fabric 与 SQL 相关创新所指向的共同目标，是构建可信、可治理、可被 AI 消费的数据基础。
对开发和数据团队来说，这意味着 AI 项目的起点不应只是选择一个模型或接入一个聊天界面，而应是重新检查数据的来源、语义、权限、质量与交付方式。
AI 能否可靠工作，取决于数据基础
Copilot 和智能体需要的不只是“更多数据”，而是能够回答以下问题的数据：
- 这条记录来自哪个系统，什么时候生成？
- 当前指标采用了什么业务定义？
- 用户是否有权看到这条数据？
- 不同系统中的客户、订单和产品是否已经统一？
- 当数据发生变化时，答案是否能够及时反映？
如果这些问题没有明确答案，模型即使生成了语法流畅的回复，也可能引用过期数据、混用指标，或者泄露用户无权访问的信息。因此，面向 AI 的数据平台需要把数据工程、SQL 分析、治理和权限控制放在同一条链路上。
Fabric 可以被理解为这条链路的协作基础：数据进入平台后，需要经过整理、建模、质量检查和权限治理，再以适合分析与智能体检索的方式提供出去。SQL 则仍然是许多团队定义业务事实、构建语义层和验证结果的重要工具。
从“数据湖”走向“可解释的数据产品”
一个实用的数据基础不应只是一堆表或文件。面向 Copilot 和智能体时，团队更需要把数据组织成可解释的数据产品：
- 明确数据契约：规定字段含义、类型、必填约束和更新频率。
- 建立统一语义：例如明确“活跃客户”“净收入”和“逾期订单”的计算口径。
- 记录数据血缘：让使用者知道指标来自哪些源表和转换步骤。
- 执行质量检查：发现重复主键、缺失值、异常数量和延迟刷新。
- 继承访问控制：智能体的答案不能绕过原有的行级或列级权限。
- 保留可审计性：记录数据版本、查询来源和 AI 使用的数据范围。
这类设计会直接影响智能体的表现。一个能够返回“本月销售额为 X”的系统还不够好；更好的系统应该能够解释指标定义、数据时间范围、过滤条件和适用权限。
一个可改造的 SQL 数据基础示例
下面是一个最小示例，展示如何把订单明细整理成适合分析和后续 AI 使用的业务视图。示例使用常见 SQL 语法；在 Fabric Warehouse、SQL Server 或其他兼容环境中运行前，请根据实际日期函数和权限语法做少量调整。
-- 1. 原始订单表：生产环境中通常由数据管道写入
CREATE TABLE dbo.orders (
order_id BIGINT NOT NULL,
customer_id BIGINT NOT NULL,
order_status VARCHAR(30) NOT NULL,
order_date DATE NOT NULL,
total_amount DECIMAL(18,2) NOT NULL,
updated_at DATETIME2 NOT NULL,
CONSTRAINT pk_orders PRIMARY KEY (order_id)
);
-- 2. 统一业务口径：只把已完成订单计入净销售额
CREATE VIEW dbo.v_customer_sales AS
SELECT
customer_id,
CAST(order_date AS DATE) AS sales_date,
COUNT_BIG(*) AS completed_order_count,
SUM(total_amount) AS net_sales_amount,
MAX(updated_at) AS source_updated_at
FROM dbo.orders
WHERE order_status = 'Completed'
GROUP BY customer_id, CAST(order_date AS DATE);
-- 3. 提供给分析或检索流程的稳定查询
SELECT
customer_id,
SUM(completed_order_count) AS completed_orders,
SUM(net_sales_amount) AS net_sales_amount,
MAX(source_updated_at) AS last_refreshed_at
FROM dbo.v_customer_sales
WHERE sales_date >= DATEADD(day, -30, CAST(GETDATE() AS date))
GROUP BY customer_id;
这段代码本身不会自动构建 Copilot，但它体现了几个关键原则：原始数据和业务语义分层、指标定义集中管理、状态过滤显式表达，以及刷新时间可追踪。实际项目中还应补充主键唯一性检查、金额范围检查、数据延迟监控和访问策略。
如果智能体需要回答自然语言问题，可以让检索层只访问经过认证的视图，而不是直接扫描所有原始表。这样做既减少了模型误读字段的机会，也更容易审计答案使用了哪些数据。
Fabric、SQL 与智能体之间的边界
构建 AI 数据基础时，几个边界需要提前划清：
- 数据平台负责事实与权限：不要把关键业务规则只写在提示词中。
- 语义层负责定义指标：不要让每个智能体自行猜测“收入”或“客户”的含义。
- 检索层负责选择上下文：不要把整个数据仓库无差别塞给模型。
- 模型负责理解与交互：不要把模型生成的文字当作未经验证的事实。
- 应用层负责执行动作：涉及退款、改价或删除数据时，应增加审批、幂等和审计机制。
这也是数据治理与 AI 安全必须一起设计的原因。即使模型本身没有直接查询数据库的权限，若检索服务没有继承用户身份，仍然可能把受限数据暴露给错误的使用者。
落地时可以采用的检查清单
在把 Fabric 或 SQL 数据接入 Copilot、智能体和内部问答应用前，可以按下面顺序检查：
- 是否为关键指标指定了唯一的业务定义和负责人？
- 是否能够标记数据的新鲜度、来源和版本？
- 是否有自动化质量规则，而不是只依赖人工抽查？
- 是否验证了用户身份、行级权限和列级敏感信息？
- 是否限制智能体只访问认证后的表、视图或检索索引？
- 是否保留提示词、查询、数据版本和最终动作的审计记录？
- 是否为低置信度答案设计了人工升级路径？
FabCon 与 SQLCon 2026 所传达的重点，可以归纳为一句话：AI 应用的竞争力不只来自模型能力，也来自数据是否可信、可理解、可控和可持续刷新。对于正在建设 Copilot 或智能体的团队，最稳妥的路径是先把数据契约、SQL 语义层、治理策略和权限边界做好，再逐步扩大模型能够访问和执行的范围。