集团负责人向 AI 提问“上季度华东区毛利率是多少”，财务系统、BI 报表和区域自建看板给出三个不同数字。每个数字都能追溯到某张库表，却没有一个能让决策者直接签字。问题并不在模型，而在于企业提供给 AI 的是分散数据，并非可直接使用的业务上下文。
关键问题通常集中在三处。口径上，“活跃客户”“有效订单”“毛利率”在 CRM、ERP 与数据仓库里各有定义；人工分析靠会议对齐，机器调用时却没有这层缓冲。语义上，业务术语分散在指标文档、SQL、报表命名和几位老员工的记忆里，大模型读得懂表结构，读不出某个字段在上一年改过统计规则。权限上，多数试点给 AI 配一个高权限只读账号，或复用某位分析师的凭据；数据范围小、参与人少时看不出问题，一旦接入更多数据源和使用方，就成了合规方面的严重问题。Forrester 的判断很直接：企业需要的是一个受治理的上下文层，而不只是更多数据。
四个能力层
实时上下文层位于数据源与 AI 之间，作用对象是“可计算的企业共识”——哪些指标存在、怎么算、归谁负责、当前状态如何、谁有权看哪一部分。它本身不产生新的业务数据。
业务语义层负责口径统一，关键差别在于定义必须可执行：查询引擎能解析、AI 能读取、返回结果时能附带说明。最小的一组属性包括业务名称与同义词、计算逻辑与过滤条件、维度与层级、责任人与变更记录、适用范围与已知限制。一个实用判据是，AI 给出的数字若无法说明用的是哪个口径、哪份数据、什么时间范围，这层就还没做实。
分布式连接与实时信号层解决“不搬数据、不猜状态”。混合云下多套系统各管一段，逻辑连接——统一元数据视图、按需联邦查询、必要时受控物化——通常优于全量复制，代价是跨源一致性需要额外设计。实时信号面对的是另一类失效：库存、在途、审批状态在分钟级变化，上下文不刷新，模型再准也只是在给过时建议。
权限与策略层决定边界。Atlan 提出的思路值得采纳：RBAC 应从工具与 API 授权延伸到数据检索环节，智能体按角色获得其所检索上下文的访问权。工程上有几条值得坚持：权限继承源系统而非另造一套；在检索时过滤，而不是在生成后遮挡；按场景动态调整粒度；为 AI 单独设身份以便归属和回收；保留上下文快照，出问题能复现“当时它看到了什么”。
顺序比清单更重要
四层不是并列的采购项。权限设计会反过来影响语义层的粒度划分，先做语义后补权限，往往意味着返工而非加配置。同样，把 RAG 当作上下文层也不成立——检索解决的是资料能否找到，没有解决数字按哪个口径算。
衡量这一层建得值不值，与其看模型评测分数，不如看几个业务指标：AI 输出与人工复核的一致率是否上升、口径争议工单是否减少、新场景接入是否还要重复定义指标、权限事件能否定位到人。归根结底只有一个问题：当 AI 被追问“这个数字从哪来”，它能否给出经得起追问的回答。