周五下午，销售总监把一份含客户手机号的表格粘进公网大模型，让它整理成跟进话术。表格里有一万两千条记录。这件事在很多公司每周都在发生，且几乎没人认为它是个事故——直到客户投诉电话打进来，或者法务在合同评审时问了一句：这些数据出过公司网络吗？
对中小企业来说，AI 的诱惑和风险是同时到来的。业务侧要效率，IT 侧要可控，老板要的是别出事、别多花钱。三方诉求叠在一起，往往演变成一场拉锯：要么一刀切禁用，业务偷偷用；要么放任自流，数据边界彻底消失。
误区：私有化等于买服务器
第一个常见误解是，私有化部署意味着采购 GPU 服务器、搭建机房、养一个算法团队。按这个标准算，几百万起步，中小企业自然望而却步。于是「等规模大了再说」成了默认答案，风险被无限期搁置。
实际发生的变化是，模型能力与硬件正在解耦。经过量化与蒸馏的行业模型，在单台带消费级显卡的工作站上就能跑出可用效果；更轻量的场景甚至只需要一台配置尚可的普通服务器。真正决定成本的，不是算力，而是你到底要让 AI 干什么。
第二个误解更隐蔽：认为只要不把数据传给第三方，就天然合规。事实是，数据留在本地却全员可访问、无日志、无脱敏，审计时同样说不清楚。合规的核心不是「数据在哪」，而是「谁在什么时候、对哪些字段、做了什么」。
判断：先分清三类数据
在讨论部署形态之前，建议先做一次数据分级。把公司数据粗暴分成两类——能公开的和不能公开的——几乎没有指导意义。更实用的分法是三类：可外发的（公开资料、通用文案）、限内部的（流程文档、产品参数）、禁外发的（客户信息、报价、合同、工艺参数）。
分级之后，问题会变得具体：只有第三类数据必须严格留在内网，第二类可以走受控通道，第一类完全没必要私有化。很多企业一上来就要求全部本地化，结果预算被第一类数据吃掉，真正敏感的场景反而没资源做。
动作一：从一个高价值场景切入
不要做全公司 AI 平台。选一个数据敏感、重复度高、且结果容易验证的场景先跑通。典型候选是客服话术生成、招标文件初筛、售后工单归类、内部制度问答。这些场景的共同点是：输入是内部文档，输出有人工复核环节，出错成本可控。
以一个常见做法为例：把产品手册、历史工单和售后 FAQ 整理成知识库，部署在内网，用检索增强的方式让模型基于自有资料回答。这样既避免了模型凭空编造，也让数据始终不出内网。上线周期通常以周计，而不是以季度计。
动作二：把权限和日志当成必需品
私有化部署最容易被忽略的部分，是权限与审计。建议在选型时就把三个问题问清楚：能不能按部门隔离知识库？能不能记录每次提问的用户、时间与命中的文档？能不能对手机号、身份证号等字段做自动脱敏？
这三项能力看起来不产生业务价值，但它们是出事时的唯一证据链。更实际的是，它们会反过来约束使用方式——当员工知道提问有记录，乱贴数据的行为会自然减少。管理成本往往比技术成本更值得投入。
动作三：留一条可回退的路
私有化不等于永久锁定。建议在架构上保留两个出口：一是模型可替换，行业模型迭代很快，今天够用的版本半年后可能落后；二是数据可导出，知识库的原始文档与标注结果应保持标准格式，避免被某家厂商的私有结构绑死。
这一点在采购阶段就要写进要求。很多中小企业吃亏的地方不是买贵了，而是三年后想换方案时发现数据搬不走，只能继续续费。可迁移性本身就是一种议价能力。
场景：三类企业的不同侧重
制造类企业通常更关心工艺参数与图纸不出厂。常见做法是把设备手册、维修记录放进内网知识库，让一线工程师用自然语言查询，减少对老师傅经验的单点依赖。这类场景对模型能力要求不高，对准确性要求极高，检索增强比纯生成更合适。