一、写在前面的话

不少企业 AI 落地一年下来，格局高度一致：外围跑得欢，核心纹丝不动。

客服机器人接了，内部知识问答上了，代码辅助全员铺开——这些都在非核心链路。而交易撮合、资金清算、核心风控决策、定价权限，几乎没有一家敢把模型真正放进去自动放行。

表面看是"模型不行"，其实是没人敢把核心链路交给一个概率生成的东西。一个裸 LLM 给出"给这位客户 8 折"的建议，决策者第一时间问的不是"对不对"，而是"错了谁负责、钱怎么追回来"。

本文不讨论"核心业务能不能接 Agent"——答案是能，但前提是按四道闸全满 + 私有化接入，且组织侧真正兜底。前几篇讲了治理的二分法（公共的归平台、场景的归企业），也讲了厂商工具为什么结构性差核心半步。这一篇，把镜头推到企业自己身上：技术上怎么接，组织上怎么扛。

二、先分清：核心和非核心，是两套治理标准

回顾系列前文：企业上模型大多停在非核心，根子是核心业务要确定性输出，裸模型给不了。但"给不了"被校准过——单体模型给不了，模型 + 架构系统可以给。区别只在代价。

非核心场景（客服、内部问答、营销文案），治理可以很轻：抽检 + 合规护栏即可，错了最多丢脸、返工。这就是为什么它们最先上模型——治理成本可承受。

核心场景（资金、清算、核心风控、定价），治理必须全满：四道闸（确定性下沉工具层 / 双层护栏 / Verification / 人在回路）全部拉满，且部署形态必须是纯私有化。因为错了是真金白银损失 + 合规事故——治理成本不可省。

所以"核心业务怎么安全接"，第一步不是选模型，是承认：核心业务的治理强度，是外围场景的数倍，且无法用"上 AI 就完了"糊弄过去。这部分前文《GLM + DeepSeek 救不了企业落地》第六节"治理强度跟着场景走"已展开，不再重复。

三、技术骨架：核心业务安全接入的五道闸

承认了治理要全满，落地就成了架构问题。核心业务安全接入的骨架，是五层，且每层都对应"场景治理企业自补"的那半步。

第 0 层：部署前提（没有它其余免谈）

核心数据绝不能出域。所以 Agent harness 必须跑在客户环境内、路由私有 LLM（GLM / DeepSeek 本地部署），而非公有云 API。这是硬门槛——平台侧得真支持 on-prem、私有 LLM 路由、企业级 connector（SSO、secret 管理、最小权限）。这一步过不了，后面四道闸无从谈起。

第 1 层：最小权限接入（动作空间收敛）

通过 connector / MCP 接核心系统时，只给"读"或"受限写"，绝不给 admin。前文那个折扣 Agent 翻车，根子就是权限没收敛——接核心系统的第一闸就是"你能碰什么"。动作空间越窄，爆炸半径越小。

第 2 层：确定性下沉工具层

核心决策逻辑（折扣权限表、清算规则、风控阈值）写成 skill / 规则引擎，模型只抽参数（客户 ID、申请值），不判断业务。规则在企业数据里，模型既拿不到也改不了。这就是系列反复说的"确定性下沉"——把"什么算越权"变成代码，而非指望模型懂业务。

第 3 层：双层护栏

公共护栏（通用安全 / PII / 基础合规）平台或开源方案（NeMo Guardrails / LlamaFirewall / Presidio）能给；场景护栏（权限匹配、金额上限、流程约束）必须由客户自写，挂在护栏框架上。二分法在此落地：公共的归平台 / 开源，场景的归企业。

第 4 层：Verification + 人在回路

核心动作（资金、核心写操作）高风险必须人工复核才放行。人在回路不是"可选优化"，是核心业务的强制闸。模型再想错，也出不了这道门。

第 5 层：审计 + 责任归属

所有动作留痕（日志 / 记忆）可追溯；最终责任专人负责制——AI 不背锅。审计是前面四层的保险，也是出事后能定位、能回滚的前提。

这五层合起来，就是前文说的 Runtime。它不是某个产品的功能，而是企业自己搭在 harness 之上的确定性架构。平台（哪怕是治理基础设施领先的 WorkBuddy）只给空插槽，规则企业自己填。

四、组织侧：技术骨架填不满的那半步

但企业真实世界里，倒在"技术都对了"之后的案例，比倒在"技术没搭好"的还多。原因只有一个：治理落到人，才算落地。

4.1 谁对最终输出负责

四道闸能拦 99% 的越权，但 1% 的残余风险永远在。谁来背这 1%？答案是专人负责制：AI 产品经理 + 业务 owner 共担，而非"AI 自己负责"。模型不具责任主体资格，责任必须落在人身上。这一点写进制度，比写进代码难，但更关键。

4.2 组织架构怎么配

治理不能靠一个英雄式的 AI 负责人。需要业务、技术、合规三角共治：治理委员会定边界，AI 风险官（AI Risk Officer）盯护栏覆盖率和回滚成功率，业务 owner 对最终输出签字。前文预告里说"组织可运营"那半句，落到这里就是——governance 是一个角色，不是一个功能。这套形态并不新鲜，它和金融业管操作风险、安全域管漏洞响应是同一套组织逻辑，只是对象换成了 Agent。

4.3 决策者怎么下决心上模型

很多决策者卡在"上不上 AI"这个二元问题。正确的问法是"基于爆炸半径分级授权"：按动作风险（只读 / 受限写 / 资金动作）而非按"上不上"决策。低风险动作自动放行，高风险动作强制人在回路。把"要不要 AI"换成"这个动作的风险配哪一级闸"，决策就从口号变成可执行的授权矩阵。

4.4 组织成熟度是真正的 gate

技术骨架能买、能搭、能抄开源；组织能力买不来。一个没有治理委员会、没有 AI 风险官、没有人愿意在输出上签字的企业，就算把五道闸搭得再满，也只是"有闸没人守"。组织成熟度，才是核心业务能不能上 Agent 的真正门槛。

五、诚实的边界

文章讲得乐观，但有两道边界必须说清，免得被决策者一句话挑翻。

其一，平台侧 gate 仍在。前面五层的前提是 harness 真能 on-prem + 私有 LLM 路由 + 企业 connector。若平台做不到（尤其当它是某个云厂商、利益上倾向导流自家模型），核心业务在"数据出域"这道就过不去。这正是前一篇《为什么厂商给的 Agent 工具，永远差企业核心业务半步》论证的——差的那半步，写的是企业的名字。开源中立 harness（如捐给 Linux 基金会 AAIF 的 Goose）能绕开厂商利益冲突，但代价是企业自己养（无 SLA、无合规认证、自运维）。

其二，客户侧责任不减。场景治理仍是企业自写（平台只给插槽），组织兜底仍是企业自己的事。技术框架把"治理"从口号变成可搭的骨架，但骨架里的血肉（规则、责任、人），技术给不了。

闭环回来：公共的归平台 / 开源，场景的归企业，组织的归组织自己。三层责任，没有一层能外包。

六、写在最后

核心业务的门，钥匙写的是企业的名字。

技术给骨架，组织填血肉——骨架能买，血肉得自己长。再领先的 harness，也只发空插槽、不发场景规则；再满的四道闸，也只拦风险、不替你背锅。

企业 AI 落地，难的从来不是把模型接进来。难的，是接进来之后，有人愿意、也有能力为它负责。

技术可行，从来不等于组织可运营。