企业接入 AI，先划清数据读写边界

给 AI 接 CRM、ERP，最先要确定的不是平台，而是谁有权读取和修改业务记录。作者给出的结论很明确：先找到权威数据、必要动作和最难挽回的失败，再选择权限最小、能追踪、能停掉的连接方式。

这套方法面向瑞士中小企业，但对做内部系统、客服助手和 AI 工作流的开发者同样有用。它把「模型能调用接口」拆成了更实际的问题：超时后能否重试、人工修改会不会被覆盖、停用之后队列里的任务怎么办。

接入 AI，先确定谁有权决定事实

「把 AI 接入 CRM」可能只是检索客户资料，也可能包含创建任务、修改客户状态和发送消息。名字一样，失败成本却差得很远。

作者要求先回答四个问题：什么业务事件触发连接；每个字段由哪个系统负责；哪些字段可以流转，以及用途、方向、时效和保留期限；结果延迟、重复、错误或不可用时，由谁处理。

这里的权威数据源（source of truth），就是系统发生冲突时应该以谁为准。CRM 可以负责联系偏好，ERP 可以负责发票状态，不能笼统地说「以数据库为准」，更不能让模型自己挑一个看起来合理的答案。

模型可以解释业务事实，但不能因为接入了多个系统，就自动获得裁决事实的权力。

只读通常更容易限制和撤销，却仍然可能泄露敏感记录。生成草稿、经人批准发送，与直接自动发送，也属于两种不同的权限边界。

作者引用的调查不能证明某种集成方案有效。瑞士联邦中小企业门户转述的 EY 调查覆盖 604 名员工，2026 年 7 月的报道中，89% 的受访者表示每天使用 AI；但页面没有完整抽样框和企业层面的加权方法。

OECD 的 2026 年调查则在 2025 年第四季度至 2026 年第一季度收集了 12 个国家、2,018 家中小企业的回答。其中 61% 使用至少一种 AI 应用，这些使用者中，76% 被归为依靠现成工具处理孤立任务的新手。该样本非随机，也不代表各国企业总体。

89% 和 61% 不能直接比较，调查对象、问题和分母都不同。它们支持的判断很有限：日常使用 AI，与拥有可靠的系统集成，是两回事。

原文还披露，2026 年 10 月 2—30 日，站点的搜索词「ki systemintegration kmu schweiz」获得 66 次展示、零点击、平均排名 27.3。这只是选题线索，既不是 66 个独立用户，也不是市场规模证据。

能用定时导出，就不必默认实时双向连接

作者的选择标准是：满足需求，同时尽量减少耦合。耦合指新组件对其他系统的标识符、字段结构、可用性、权限和变更节奏有多深的依赖。

原生连接器适合已经支持目标字段和流程的场景。需要检查的是它能看到哪些联系人、是否能写入、服务身份能否轮换、管理员能否查看操作记录，而不只是配置向导有几步。

定时单向导出适合允许延迟的数据。文件也需要负责人、接收位置、结构版本、时间戳和清理规则，失败后还要能对账。原文这里有个应当追问的地方：它把「允许一小时旧的数据」与「每日导出」放在同一个例子里，两者并不天然匹配。导出频率必须由最大可接受数据年龄决定。

只读 API 或检索层适合搜索、摘要和解释。结果应返回稳定记录 ID、来源时间和原记录入口，让人能核实。检索索引只是副本，不能悄悄接管库存、发票或客户同意状态的解释权。

确实需要写入时，再考虑小型适配器。它负责校验输入、限制允许操作、添加幂等键、记录结果，并把不确定的写入交给人工。幂等的意思是，同一业务事件重试时，不会再生成一张发票或重复发送邮件。

中央数据枢纽则需要多个可复用的数据转换或跨部门用途来支撑。原文引用 Deloitte 的分层、迭代集成思路，但明确承认那是咨询视角，并非独立性能研究，也不是小企业成本估算。

把边界写成配置，再用失败场景验证

原文提出 12 项检查，输入文本中每项都重复出现了一次，实际仍是 12 项。它们覆盖记录归属、数据方向、字段范围、服务身份、稳定 ID 与结构、时效、重试、并发冲突、删除保留、可观测性、异常负责人，以及退出对账。

这些项目不能靠累计得分过关。对高影响写入，一个关键缺口就可能要求停止；使用合成数据的低风险只读原型，可以采用不同要求。

最容易被忽略的是「结果未知」。请求超时，可能只是响应丢失，目标系统其实已经执行成功。此时盲目重试就可能重复写入。作者要求用稳定事件标识或幂等键保存结果；目标不支持去重时，应进入人工复核队列。

并发修改也一样。AI 读完记录后，人可能已经更新了它。提交前需要拒绝过期更新、重新读取或请求批准，不能默认最后一次写入获胜。

作者用一家假想的瑞士建材经销商演示了边界：员工发起「起草订单进度」，应用只传订单 ID 和工单 ID；只读服务检查员工权限，再返回 ERP 状态、更新时间和来源入口；模型生成草稿，CRM 保存内部备注，员工核对后发送。模型不可用时，员工仍能直接操作 ERP 和 CRM。

这是设计练习，没有真实部署或生产力测量。下面的清单用于把职责和限制写进项目工单，原样保存为 integration-manifest.json：

{
  "name": "order-status-draft",
  "version": 1,
  "businessOwner": "Customer operations lead",
  "technicalOwner": "Named integration operator",
  "systemsOfRecord": {
    "orderStatus": "ERP",
    "contactPreference": "CRM",
    "supportConversation": "CRM"
  },
  "direction": "read_then_draft",
  "readSources": ["ERP.order_id", "ERP.status", "ERP.updated_at", "CRM.case_id"],
  "writeTargets": ["CRM.internal_draft"],
  "excludedFields": ["payment_credentials", "free_text_hr_notes"],
  "freshnessMinutes": 30,
  "serviceIdentityOwner": "IT administrator",
  "leastPrivilege": true,
  "humanApprovalForExternalSend": true,
  "idempotencyKey": "case_id + draft_version",
  "auditCorrelationId": true,
  "failureMode": "hold_for_human",
  "exceptionOwner": "Customer operations queue",
  "exitProcedure": "disable_service_identity_then_reconcile_queue",
  "retentionOwner": "Privacy lead",
  "testEvidence": ["read_scope", "duplicate_retry", "stale_record", "revoke_access"]
}

重点看 writeTargets：虽然流程先读取数据，仍会写入 CRM.internal_draft，所以 direction 是 read_then_draft，并非完全只读。freshnessMinutes: 30 是示例要求，不是通用推荐值。

清单于 2026 年 11 月 1 日为文章起草。作者还给出仅依赖 Python 标准库的检查命令 python check_manifest.py integration-manifest.json，但本次输入里的脚本在函数中途截断，不能直接运行。即使获得完整脚本并通过，也只代表声明满足结构检查，不代表权限配置有效或部署安全。文中提及的 12 个场景也是设计测试用例，不是 12 家企业的实测结果。

我的判断

我认同这篇把权限、失败处理和退出机制放在选型之前。它对 AI 编程项目尤其有用，因为生成一段接口调用代码很快，明确谁能修正错误、谁来处理积压任务，往往更难。

但这是一套工程经验框架，没有连接器、定时导出和适配器之间的成本、故障率或维护工时对照。不能据此断言小适配器一定更便宜，或者原生连接器一定更可靠。

适配器还要求团队有人维护身份、队列和日志。承担不了这些工作时，人工审核草稿或现有业务模板可能更合适。反过来，人工批准也不能只增加一个按钮：审核者必须能看到来源、更新时间和实际发送内容，否则只是形式上的控制。

配置文件里的承诺，只有经过权限检查和失败测试，才算系统行为。

能拿来做什么

• 给内部客服助手写需求时，先列出字段归属、最大可接受数据年龄、异常负责人和退出步骤，再确定使用原生连接器、定时任务还是只读 API。
• 用 Node 实现订单查询服务时，按当前登录员工检查记录权限，只返回必要字段、稳定 ID、来源时间和记录入口；前端把这些信息放在草稿旁边，方便审核。
• 让 AI 辅助编写写入接口时，把重复请求、响应丢失和人工并发修改写进验收场景；目标系统无法去重的操作，进入复核队列。
• 在测试环境撤销服务凭据、停掉任务，并核对待处理事件与派生数据的处置方式，确认业务人员仍有人工操作路径。