别让技术方案，背组织机制的锅。
一张外部大模型调用申请单，被退回了三次。
第一次退回，因为没有写清输入数据范围。
第二次退回，因为方案里写了"仅限非敏感数据"，但没人说明什么叫非敏感、由谁判断非敏感。
第三次退回，是安全评审会上有人问了一句：如果员工把客户投诉、合同片段、会议纪要、代码日志粘进去，系统怎么发现，谁来处置？
技术同事觉得冤。API 早就调通了，测试页面也跑起来了，模型回答效果也不错。为什么到了企业里，突然变成一件所有人都不敢点头的事？
本文讨论的，不是个人随手使用聊天工具，也不是完全私有化部署，而是企业通过 API、云服务或专属资源，把外部商业大模型能力接入内部业务流程的生产化调用。
很多人以为，这事卡在技术。也有人以为，这事卡在安全。都不准确。
真正卡住的，是一个更难回答的问题：如果外部大模型出了错，这到底算谁的错？
它难进企业，不是因为一定会泄露，也不是因为一定不好用，而是它一旦进入企业流程，就变成了一个持续运行、概率输出、归责不稳定的外部智能系统。
现有审批体系，擅长管确定对象：这批数据能不能出，这个接口能不能开，这个系统能不能上线。
但它不擅长处理另一件事：一个外部模型未来每天都在接收上下文、生成判断、影响流程，如果某一次答错了、误导了、越界了，责任该怎么稳定地落到某个主体上？
这个问题没有答案，安全部门就会变成最后一道闸。
它能否定。
但很难替组织认定。
提到外部大模型的风险，很多人的第一反应是：那就私有化部署。
对央国企、金融、电信、政务、能源这些场景来说，这不只是本能反应，而是最符合直觉的安全选择。数据不出去，风险不进来，领导也好交代。
但私有化真正落地以后，问题往往换了一种形式回来。
场景还没跑通，算力先花出去了。模型部署完也只是开始，推理优化、版本升级、持续运维，每一项都要自己接住。外面的商业模型迭代快，内部平台很难跟上，业务团队用完外面的再回来用里面的，体验落差明显。
花了大价钱建了一套私有平台，安全问题缓解了，能力问题又出来了。
私有化解决的是"模型在哪里"，但解决不了"模型好不好用"。
所以真正绕不过去的问题不在私有化这条路上：如果外部商业大模型确实更强、更快、更会迭代，企业到底能不能用？怎么用？谁来认定可以用？
有一个反驳必须先接住。
企业又不是第一次把工作交给外部机构。外包客服天天处理客户投诉，律所拿走核心资料做尽调，咨询公司看遍经营数据出报告，SaaS 系统也承载大量业务流程。
这些全是"把敏感信息交给外部处理"，而且输入不确定、输出也不一定完全可控。企业照样授权，照样使用。
凭什么到了大模型，突然就用不起来了？
因为前面那些外部服务，背后通常有一个可追责的专业主体。
外包客服说错话，可以追客服流程、培训记录、质检记录、外包公司管理责任。律所意见出问题，可以追执业过失、合伙人责任、专业判断依据。咨询报告误导决策，至少能追到项目团队、交付物、合同范围和专业责任。
这些责任未必容易追，但责任链是存在的。
大模型不一样。
很多错误，并不总能还原成某个人的失职或某次操作违规。它常常夹在模型概率输出、上下文变化、厂商服务边界、企业集成控制和使用人行为之间。
可能是模型固有不确定性。可能是厂商服务边界没有说清。可能是企业集成时控制不足。可能是业务人员输入不当。可能是审批人没有要求人工复核。也可能是场景本身就不该让模型独立回答。
传统系统也会出错，复杂系统也会出现不可预见的故障。但那些错误，很多时候可以理解为偏离设计规格：一个 bug、一次配置失误、一个未覆盖的边界条件。查到了就能修，修完这类错就不再以同样方式发生。
大模型的很多错误，恰恰发生在系统按设计运行的时候。
它没有宕机，没有报错，也没有明显违规操作，只是给出了一个看起来合理、实际错误的答案。这类错误不完全是传统意义上的 bug，不能靠修一个点把它归零。
所以不能简单说"大模型无法归责"。这句话太满。更准确地说，大模型让错误归责变得不稳定。
它不是没有责任主体，而是很多时候，组织先要争论：这到底算谁的错？
厂商会说，我只是提供模型能力，客户要自己定义场景和控制边界。业务会说，我只是使用系统，模型怎么答不是我能控制的。IT 会说，我负责接入和日志，不负责业务判断。安全会说，我当初只是提控制要求，不是替你认定业务可用。数据部门会说，我只确认数据范围，不负责模型输出后果。
最后问题就悬在那里。
普通外部服务出了错，组织至少知道从哪条线去追。大模型出了错，组织先要争论这是不是一个"错"，再争论是谁的错。
归责不稳定，这才是大模型区别于很多传统外部服务的真正特殊性。不是它一定比别的服务更危险。而是它出了事之后，责任更难稳定压到一个确定的人头上。
既然归责不稳定，审批时就会发生变化。
回头看那张被退回的申请单。
数据泄露风险当然是大家最先想到的。客户信息会不会出去，合同内容会不会被留存，代码片段会不会暴露系统结构，会议纪要会不会包含经营安排。这些担心都合理。
成熟商业服务可以提供数据隔离、不用于训练、日志留存、专属资源等技术和合同安排，但对强监管企业来说，只要数据交给外部处理，就进入了第三方处理关系，必须谨慎。
但泄露不是唯一的、甚至不是最致命的卡点。
央国企并不是没有审批机制。数据共享、数据开放、系统上线、安全评审，很多事情早就可以拆成几项分别签。业务签场景。数据责任方签数据范围。安全签控制条件。IT 签入口和日志。法务签合同条款。
这套群体决策跑了很多年，机制并不新。
问题是，大模型在签字链上引入了一项新内容，而这项内容谁都签不了：
这个概率性系统未来运行中出了错，算谁的？
业务能签场景价值，但不能保证模型未来不误答。数据部门能签字段范围，但不能确认模型输出后果。安全部门能签日志、脱敏、权限、审计、阻断这些控制条件，但不能替组织接受一个持续运行的概率系统未来出错的后果。法务能签合同边界，但很难覆盖所有业务误导、声誉风险、客户影响和审计追问。
流程齐全，公章齐全，就差一个敢在"可以用"三个字后面签名的人。
签字链上少一环，整条链就闭合不了。
不是被某个人卡住。是被一个无主体的空格卡住。
这个空格为什么填不上？
两件事叠在一起。
第一件，组织的问责体系主要是为确定性责任建的。传统系统出了错，逻辑相对清楚：规则有没有设计，流程有没有执行，权限有没有越界，操作有没有违规。问责链条建立在一个假设上：错误背后总能找到一个可定位的责任人或管理缺口。
大模型打破了这个假设。
它可能在没有任何人明显违规的情况下出错。不是厂商接口异常，不是员工乱操作，也不是审批人故意放水，而是在开放输入、复杂上下文和概率输出共同作用下，结果跑偏了。
问责体系面对一个"没有明显违规者也可能出错"的系统，没有现成处理方式。
第二件，激励结构不对称。即便勉强有人能签，也没人愿意。签了没出事，没人记得你；出了事，所有人记得是你放的行。
两件事叠加，审批就会向一个方向收敛。
审批人知道，签了字之后如果出事，审计会问：你当时依据什么？而大模型恰恰是那个你很难给出充分事前依据的东西。因为它下一次在真实业务场景里会跑出什么结果，你确实说不准。
签了，也未必能自证尽责。既然怎么签都不安全，唯一能自证尽责的动作就是不签。
很多评审会最后都会走到这个场景：
技术方案讲完了，安全清单列完了，厂商承诺也签了，所有人都觉得"应该可以"。到了签字环节，会议室安静下来。
安全负责人说：方案我没意见，但这个认定不归我签。信息化负责人说：技术没问题，但数据分级和使用授权不在我职责范围。业务负责人说：我们只是想试试，不能让我们背全部风险。
最后领导说：再研究研究。
这不是谁在推诿。是"认定它可以用"这个权力，组织根本没有稳定地分配出去。
安全部门有否定权，它能说"不行"。但它没有被授权说：在这些数据、这些人员、这些控制条件下，这个场景可以用，未来剩余风险由组织接受。
很多时候，安全的"不否决"会被组织当成事实上的放行背书。于是出了事，第一个被问的就是：当初安全为什么没拦？
安全能否定，不能替组织认定。
这个缺口不补，分层准入写得再漂亮，最后都会退回同一句话：原则上可以，但这个我签不了。
审计不会问你当时感觉如何。它会问你当时依据是什么。没有依据的签字，就是裸奔。
在这个激励结构下，一刀切不是最优安全策略，但常常是最优责任策略。
多数人在那个位置都会这样。
到这里会有一个问题：如果归责这么难，为什么诸如Claude等企业有这么多企业客户？它们是不是解决了"AI 出错算谁的"？
没有。它们只是把这个问题拆小了。
金融、医疗、政府、国防这些领域，多数强监管市场都不会轻易全面放开使用。它们同样会走专有部署、合同限制、人工复核、分级授权和审计留痕。
真正差异在于，有些企业凑齐了几套配套，把这个无法一次性回答的问题拆小、分散、留痕、重新锚定，让它不再整块压到一个审批人头上。
第一，厂商责任和合同条款。一些国际厂商会把数据处理、知识产权、服务责任、赔偿边界写进合同。赔偿范围通常有限，模型输出造成的业务损失也不一定覆盖，但它至少把一小块风险从审批人肩上转移成了商业合同可以讨论的问题。
第二，人在回路。成熟企业很少让大模型直接替人做最终决策。AI 出草稿，人审核签字。前提是审核的人真有能力复核，而不是形式上点一下确认。但它至少把一部分概率性输出，重新锚定到可追责的自然人和业务流程里。
第三，渐进式授权。低风险场景先跑起来，积累真实的错误率、越界率、人工接管情况和用户反馈，再用运行数据决定能不能扩展到下一层场景。不是一次性认定"安全"，而是用真实数据逐步缩小不确定性的范围。
第四，外部治理框架。NIST AI 风险管理框架、欧盟 AI Act 这类框架，不能替企业批准使用，也不是免死金牌。但审计问"你当时依据什么"，回答"我们按照某套治理框架做了风险评估"，至少比"我们觉得应该可以"强得多。
所以，成熟企业不是解决了"AI 出错算谁的"。它们做的是另一件事：让 AI 出错这件事，不再全部压到某一个审批人的个人判断上。
厂商承担一部分。业务复核承担一部分。运行数据承担一部分。治理框架承担一部分。
审批人不再需要用个人信用去证明"它不会出事"。他只需要证明：这些风险已经被识别、分摊、监控、留痕，并且剩余风险由组织接受。
这就是差别。
国内这四条配套还不够厚。厂商责任边界不够清，人在回路容易流于形式，渐进授权缺少稳定流程，外部治理框架还没有变成企业审批材料里的常用语言。再叠加强问责环境，同样一份不完整的材料，在容错空间大的地方可能是"继续完善"，在问责压力重的地方就变成"谁批的"。
审批人最稳妥的选择，就是不批。
那国内该怎么补？
很多人的第一反应是：分场景、分级别，高风险的不碰，低风险的先试。这个方向是对的。不分场景就做，确实是蛮干。
但问题出在"分完之后怎么批"。
低风险场景，比如公开材料摘要、宣传稿润色、模拟数据问答，安全部门可能接受，业务却觉得没什么价值。真正有价值的场景，很快就会碰到客户数据、经营信息、合同文本和流程责任。
到了这些场景，"分级"本身并不自动解决前面说的那个问题：谁来认定这个级别可以用？
把场景定成"中风险"，审批人还是要签字。签的那一刻，他面对的仍然是一个概率系统、无法穷尽未来输入输出、事后归责不稳定的局面。
级别分得再细，到签字那一环，该撞的墙还是撞。有单位把场景分了五级，安全部门看完说：分级没问题，但谁来认定这个分级是对的？——又回到原点。
所以，分层不是错。但分层分的是场景，真正要转换的，是审批的标的物。
传统数据出域审批，审的是内容：这批数据能不能出。内容是确定的，审完即结案。
大模型审不了内容。因为内容是运行时才产生的，事前根本不存在。你不可能在上线前穷尽未来用户会输入什么，也不可能穷尽模型会如何回答。
硬要审内容，就是前面说的死局：审批人要为一个无法预判的东西背书，怎么签都不安全。
换一种审法
不审内容，审围栏。
不审"用户会输入什么"，而是审"如果用户输入了不该输入的，系统拦不拦得住；拦不住的时候停不停得下来；停了之后查不查得到"。
白名单人员能不能控制？统一入口能不能落实？敏感输入能不能识别和阻断？输出能不能限制为草稿？高风险结论能不能强制人工复核？越界后能不能暂停？日志能不能追溯？
这些东西不是空话。它们是可以检查、可以测试、可以留痕的围栏。
审批人签字的对象，也就变了。
过去是：我确认这批数据安全。现在是：我确认这套围栏达标。
前者要求你为未来每一次运行内容打包票。内容会变，这个包票没人敢打。后者要求你为围栏本身的有效性打包票。围栏是相对固定的，达没达标、有没有日志、能不能暂停，至少可以测试。
一个最小的围栏，可以很简单：限定白名单人员，通过统一网关调用。只允许使用公开资料、已发布制度和脱敏样例。输入输出留痕，出现敏感内容自动阻断。输出只作为草稿，关键场景必须人工确认。先跑三十天，触发越界立即暂停。
业务签场景价值，数据部门签输入范围，安全签围栏达标，IT 签日志和入口，法务签合同边界，牵头机制签试点授权和暂停规则。
没有围栏审批，出了事追问的是：你凭什么判断安全？谁同意的？这指向签字人的个人判断。有了围栏审批，追问就变成：围栏有没有按规则设置？日志全不全？越界有没有阻断？这指向围栏有没有失效，执行有没有越界。
前者是无限责任。后者是有限责任。
围栏改变了什么
但必须诚实说一句：围栏堵不死所有洞。
这不是技术不够成熟，而是这类系统的原理决定的。大模型的输入空间是开放的，输出是概率的。企业永远无法穷举它会被怎样触发，也无法穷举它会生成什么。
总有你没想到的输入，触发你没设防的输出。总有看起来合理、实际却错误的答案。总有边界内运行、但结果仍然跑偏的情况。
大模型的剩余风险，不是"再努力一下就能补全"。它在原理上就是一个正数，压不到零。
凡是把外部大模型承诺成零风险的方案，都不是治理方案，而是风险转移话术。
那审围栏到底改变了什么？
出了事审计来查的时候，有围栏的团队可以翻出日志说：这是试点授权范围内的已知残余风险，评审记录在此，越界阻断记录在此，人工复核执行记录在此。没有围栏的团队只能说：我当时觉得应该没问题。
这不是免死金牌。但它是组织第一次有机会把"外部大模型可以用"这件事，从个人拍脑袋变成一组可记录、可暂停、可复盘的组织动作。
道理讲到这里，该交代一个现实：
大多数企业不是看不见这条路，是走不出去。
第一层原因，是先例效应。今天批了代码辅助，明天就有人拿同样逻辑来申请客服摘要、合同审查、工单分析。批一个场景，不只是批一个场景，它是在打开一个口子。
打开口子的责任，远大于关上门的代价。
所以很多单位都在等别人先跑通。等一个出了事能交代、没出事能参照的"第一次"。
但更深的一层，比先例效应还难。
审围栏的出路，要求组织做一件过去很少白纸黑字做的事：明示地、集体地，认下一块明知归不了零的剩余风险。
以前审批确定性系统，审批人可以告诉自己：我审过了，所以它是安全的。大模型把这层安慰撕掉了。审完围栏，你仍然知道它可能出错。
签字这个动作，不再是说"我保证它不会出事"，而是在说：我知道它仍然有非零风险，但在这些边界和控制条件下，我同意让它试运行。
这句话，才是最难写进材料里的。
在追责环境里，它听起来不像尽责，反而像提前写好的供状。
所以最深的卡点，不是没机制、没流程、没方案。是大模型要求组织把"我们接受剩余风险"这件事，从心照不宣变成白纸黑字。而在强问责逻辑下，写下这行字的人，很容易被理解成未来风险的提前认领人。
这才是出路看得见，却走不出去的根子。
真正考验的，不是围栏会不会建，而是组织有没有能力把非零风险从个人背锅，转成集体授权。
要过三道坎
具体说，要过三道坎。
第一道，出了事的时候，批的人能拿出一句话：这不是我个人拍的脑袋，是组织按照试点授权规则集体决定的。也就是说，要有一个正式的集体授权机制，让剩余风险不压在某一个签字人头上。
第二道，追责的时候，能分清两种情况：一种是违规了、越权了、没按规则执行，该追；另一种是规则都执行了、日志都留了、人工也复核了，模型还是跑偏了。如果两种情况一锅端成"出事就是有人没尽责"，那就没人会批。
第三道，出事之后客户要解释、监管要沟通、业务要补偿、内部要复盘。这些后果谁来接？组织如果没有为此准备预案和分担机制，最后还是会回到那句老话：谁批的？
很多单位都在等别人先做。
不是等别人先用大模型。试点谁都在做。真正等的是别人先建出一套经过实践检验、出了事也能交代的围栏审批机制。
如果有一家同级别企业先把这套机制跑通了，形成了可参照的制度文本，后面的企业就可以说：我们参照了某某单位的做法。这句话的价值，不在方案多先进。在于它把首创责任转移了。
第一个吃螃蟹的人，在创新叙事里是英雄。在履责叙事里，可能是审计重点对象。
这句话不好听，但真实。
推不动的时候，至少要把缺口讲清楚：卡住项目的，不是技术能力，不是方案不好，而是"AI 出错算谁的"这件事，还没有制度答案。
别让技术方案，背组织机制的锅。
回到开头那张被退回三次的申请单。
机制、流程、围栏，该建的都可以建。但到最后，总有一块明知堵不死的剩余风险，需要有人在组织授权下认下来。
外部大模型什么时候能真进企业，不取决于模型多强、围栏多严。取决于这个组织有没有一套让人可以据以签字、事后可以证明尽责的机制。
说到底，是能不能容下一个敢于为"不确定"签字的人。
在那之前，进来的只是 API。不是能力。
（部分内容来源网络，如有侵权请联系删除）
