数据集成总览

企业里真正有价值的信息，大多不在数据库里——它在个人电脑的文件夹、聊天记录的附件、几十份互相引用的表格，和只有某几个人知道怎么读的业务系统里。数据集成板块回答一个问题：怎样把这些东西收进一套有归属、有分级、AI 读得到的组织记忆，而不是先做一个大数据平台。

// 一句话理解

数据集成不是「把数据搬到一起」，而是「让每一份资料都有主人、有密级、有出处」。搬完之后要能回答三个问题：这份文件归哪个部门？谁（包括哪个数字员工）能看？AI 引用它时能不能给出出处？三个都答得上来，集成才算完成。

这个板块回答什么

下面七页覆盖从「资料还散在各处」到「数字员工能带出处地回答」的完整链路。它们不假设你已经有数据仓库，也不要求你先做主数据治理——集成从组织的目录结构开始，而不是从 ETL 开始。

数据基座与 Agent 基座任何建模开始之前的两层底座：先让组织拥有不依赖个人的记忆，再让这份记忆第一次能被「问」。 C-suite 文件系统十个根目录与十个管理域一一对应的所有权地图——每份资料归谁，从目录结构上就能看出来。 数据源与连接器三类数据源与五种接入方式：文件、业务系统、对话渠道，各自怎么连、连进来变成什么。 知识库与语料治理AI 可读语料的治理层：落对桶、权限对、检索得到、回答可溯源。 文件面与云盘一套文件面覆盖工作目录与知识库：浏览、上传、搜索、分享，以及不可越过的路径纪律。 Context Gateway资料分发的关卡：按任务、身份、权限只提供当前需要且有权查看的最小资料集。 数据边界什么数据允许出现在哪一层——集成的上限由这条边界决定，不由技术可行性决定。

三段结构：收录 → 定级 → 分发

无论数据从哪来，它在 AIDC 里都要走完同样的三段。把这三段分开，是集成能被审计、能被回滚、能被交接的原因。

收录Ingest

资料进入组织的边界：上传到云盘、由连接器从业务系统只读取回、或从对话渠道沉淀下来。收录动作记录来源、时间与提交人——一份没有来源的资料，后面所有引用都无法追溯。

定级Classify

每份资料落到一个所有者目录，并按 Company / Department / Group 三级确定共享范围。定级是权限的输入，不是标签：没有定级的资料默认按最严一级处理，而不是默认开放。

分发Serve

数字员工不做全库检索。Context Gateway 按当前任务和身份，组装一个最小可用的资料包并附带出处指针。分发是唯一的读取通道——绕过它的读取在系统里不存在。

推荐的落地顺序

集成最常见的失败方式，是一次性把所有系统都接上，然后没有人说得清哪份数据是权威的。推荐顺序反过来：先把「人已经在用的资料」收好，再接系统。

  1. 建目录骨架。先确定十个管理域的根目录与负责人，再往里放东西。目录结构一旦稳定，后面所有权限规则都挂在它上面。
  2. 收人手上的文件。把散在个人电脑与聊天记录里的现行文件迁进云盘，按目录归位、按三级定级。这一步不需要任何系统对接。
  3. 建知识库。把制度、规范、手册、历史方案这类「要被反复引用」的语料收录进知识库，让数字员工能带出处引用。
  4. 接对话渠道。把日常沟通接进来，让提问发生在人已经在的地方，同时让新的资料随对话自然沉淀。
  5. 只读接业务系统。最后再接 OA / ERP / MES。第一版一律只读——先证明系统能正确理解这些数据，再谈写回。
// 治理规则

业务系统的第一版接入永远是只读的。写回能力必须等到对应的动作合约（Action Type）定义完成、并通过一次真实评估之后才开放——先证明读得对，再允许写。

常见误区

误区后果正确做法
先做统一数据仓库，再谈 AI半年内没有任何可用产出，业务侧失去耐心先收现行文件，两周内就能有能回答问题的数字员工
把所有资料一次性全量导入过期文档与现行文档混在一起，回答不可信只收现行版本；历史版本单独归档、默认不进检索
用「谁上传谁负责」代替定级密级靠自觉，跨部门泄露只是时间问题定级是目录属性，不是上传者属性
让 AI 直接连生产数据库没有权限过滤，也没有出处，出问题无法归因一律经 Context Gateway 分发，读取动作全部留痕

相关阅读