数据源与连接器

连接器是数据进入组织记忆的通道。AIDC 把企业里的数据源归成三类——文件、业务系统、对话渠道——每一类有各自的接入方式、各自的权限约束，也各自解决一种不同的问题。这一页说明每类怎么接、接进来变成什么、以及哪些边界不可越过。

// 一句话理解

连接器不负责「把数据搬空」，只负责「把当前需要的那部分安全地取回」。所有连接器共享三条约束：只读优先、最小字段、全程留痕。做不到这三条的接入方式，在 AIDC 里不叫连接器。

三类数据源

文件类Documents

合同、方案、报价单、工艺文件、会议纪要、报表附件。这类数据没有 API，也没有 schema，但它承载了企业里绝大部分「只有人知道」的判断依据。接入方式是云盘上传与整目录迁移；接进来之后归入所有者目录并定级。

业务系统类Systems of record

OA、ERP、MES、CRM、财务系统。这类数据结构化、权威、实时，但接口权限往往控制严格。接入方式是只读接口或导出文件的定时收录；接进来之后成为语义模型里的对象实例，而不是一堆表。

对话渠道类Conversation

企业 IM、邮件、工单群。这类数据是「过程知识」的主要产地：一个决定为什么这么做，通常只写在某条消息里。接入方式是渠道接入；接进来之后，提问发生在人已经在的地方，新资料随对话自然沉淀。

五种接入方式

下表按「先易后难」排列。前两种不需要客户 IT 部门配合，通常在部署第一周就能完成；后三种需要接口与账号，安排在数据基座建成之后。

方式适用数据源权限形态典型引入时点
云盘上传 / 整目录迁移文件类操作员或成员账号，按目录定级第 1 周
知识库收录文件类（需被反复引用的语料）按知识库前缀授权，前缀即权限边界第 1–2 周
对话渠道接入对话渠道类渠道凭证存放在部门运行时，不上平台第 2–3 周
业务系统只读接口业务系统类专用只读账号，字段级白名单对象建模阶段
定时任务拉取（Routine）业务系统类、导出文件与只读接口同权限，按周期执行并留痕业务闭环阶段

接入一个数据源的六步

无论哪种方式，接入动作本身是标准化的。这六步的顺序不能调换——尤其是第 2 步在第 4 步之前：先确定谁能看，再确定怎么取。

  1. 确认所有者。这个数据源归哪个管理域？没有明确所有者的数据源不接入——它最终会变成没人维护的死数据。
  2. 确定分级。按 Company / Department / Group 判定共享范围，并记录判定理由。分级决定后续所有权限规则。
  3. 划定字段范围。只取业务问题真正需要的字段。「先全量取回，以后再筛」是最常见也最贵的错误。
  4. 建立只读凭证。为该数据源单独建账号，权限只覆盖第 3 步划定的范围，凭证存放在对应部门的运行时环境，不进入平台层。
  5. 跑一次对账。用一个已知答案的真实业务问题验证：系统取回的数据与业务侧手工核对的结果是否一致。不一致就回到第 3 步。
  6. 登记与留痕。把数据源登记进控制台的数据源清单，之后每次读取都进入操作台账，可按来源、时间、发起者回查。
// 治理规则

连接器凭证一律存放在所属部门的运行时环境，平台层只保存「这个数据源存在、状态如何、最近一次同步是什么时候」这类元数据。平台从不持有能直接访问客户业务系统的凭证。

不进平台层的东西

连接器的能力上限由数据边界决定。以下内容永远停留在客户自己的运行时里，即使技术上完全可以传出来：

平台层保存的是「关于数据的数据」：数据源清单、状态、计数、时间戳、审计元数据。完整规则见数据边界。

常见问题

问题回答
没有 API 的老系统怎么办？用导出文件 + 定时收录。牺牲实时性换来零改造，对多数经营分析场景足够。
数据质量很差，要先治理吗？不要。先接一个业务问题真正用得到的小范围，用它暴露质量问题，再定向治理——全面治理没有终点。
能不能让 AI 直接写回业务系统？可以，但必须经动作合约提交，并且要在只读版本通过评估之后。见 Action Types。
多个部门用同一个系统，怎么隔离？按部门建独立只读账号，字段范围各自划定；跨部门读取走语义模型里显式共享的对象，不共用账号。

相关阅读