为什么79%的政府官员不敢用AI？

79%的公共部门高管对AI数据安全心存顾虑——这个数字背后，是整个政府数字化转型的结构性困境。

当企业忙着把数据喂给云端大模型时，政府机构却在为"能不能联网"发愁。Capgemini的研究揭示了一个反常识现实：公共部门的AI落地，卡住的从来不是技术本身，而是那些企业根本不会遇到的约束条件。

Elastic人工智能副总裁Han Xiao（萧晗）点破了核心矛盾："政府机构对能发送到网络的数据必须极度受限，这给他们思考和管理数据的方式设定了大量边界。"

企业习以为常的，政府寸步难行

私营部门部署AI时默认的四项条件，在公共部门可能从"不便"变成"不可能"：

• 持续云连接——政府系统常运行在断网或弱网环境
• 集中式基础设施——与数据主权要求直接冲突
• 模型黑盒可接受——政府需要可核查、可验证的输出
• 数据自由流动——受法律义务严格限制

这些非技术约束导致一个尴尬局面：大量公共部门AI试点困在实验阶段，无法真正投产。Elastic对公共部门领导者的调查显示，65%的人难以持续、实时、规模化地使用数据。

基础设施层面还有一道隐形门槛。萧晗指出："政府不像私营部门那样采购GPU，他们不习惯管理GPU基础设施。获取GPU来运行模型，对许多公共部门来说是瓶颈。"

小模型为何成为务实选择

大语言模型（LLMs）的"大"字，恰恰是政府场景的原罪。数百亿参数意味着：必须联网调用、需要高端算力、推理过程不透明、数据离开本地。

小语言模型（SLMs）的突围路径很清晰：本地部署、参数精简（通常数十亿级别）、领域专精、可控可审。

这不是性能妥协，而是架构层面的重新设计。SLMs可以在边缘设备运行，无需持续联网；推理过程可追踪，满足审计要求；硬件门槛大幅降低，现有服务器即可承载。

萧晗强调了一个被低估的维度："公共部门需要AI在各种数据上可靠运行，然后能够无缝扩展而不崩溃。业务连续性往往被低估。"

落地需要回答的三个问题

对于正在评估AI方案的公共机构，务实的自检清单：

第一，数据能否不出域？如果业务场景涉及公民隐私、国家安全或敏感决策，本地化部署是硬约束，不是可选项。

第二，断网能否运行？从应急指挥到边疆政务，网络可靠性无法假设。模型必须在离线状态下保持完整功能。

第三，输出能否被审计？政府决策需要可追溯、可解释。黑箱模型的"创造力"在这里是 liability（负债）而非 asset（资产）。

这三个问题的答案，决定了应该走"接入通用大模型"还是"自建专用小模型"的路线。

弹性架构的关键价值

Elastic与公共部门合作的经验指向一个设计原则：搜索与AI的融合架构。

政府数据的核心形态不是"训练语料"，而是"可检索记录"。政策文件、案件卷宗、审批流程——这些结构化与非结构化数据的混合体，需要检索增强生成（RAG）技术的支撑。

RAG（检索增强生成）让模型先搜索本地知识库，再基于检索结果生成回答。这既保证了答案的准确性（有源可溯），又避免了敏感数据进入模型参数。

萧晗的团队观察到，公共部门对"混合搜索"的需求尤为突出：关键词匹配、语义理解、向量检索需要在同一查询中协同工作。这种复杂性在消费级AI产品中几乎不存在，却是政府系统的日常。

安全设计的三个层级

公共部门AI的安全不是单一功能，而是贯穿数据层、模型层、应用层的系统工程：

数据层：字段级加密、访问控制、数据分类分级。Elastic的搜索平台支持在索引层面实施这些策略，确保不同权限人员看到不同范围的信息。

模型层：模型本身的来源验证、版本管理、推理隔离。SLMs的优势在于可以像软件资产一样内部托管，而非依赖外部API的可用性与一致性。

应用层：查询审计、输出过滤、人机协同。关键决策环节保留人工复核节点，AI提供建议而非替代判断。

这种分层架构的代价是实施复杂度上升，但公共部门没有"先上线再迭代"的奢侈。一次数据泄露或错误决策的代价，远超系统建设的额外投入。

从试点到生产的鸿沟

公共部门AI项目的高失败率，常被归因于"官僚主义"或"技术落后"。更准确的诊断是：试点环境与生产环境的约束差异被系统性低估。

试点阶段可以调用的云端API、临时租用的算力资源、简化版的安全审查——这些在规模化部署时全部失效。生产系统必须面对：合规审计、灾备要求、跨部门数据整合、遗留系统对接。

Elastic的调研数据印证了这一点：65%的领导者卡在"持续实时规模化使用数据"这一步。这不是技术能力的欠缺，而是运营模型的不匹配。

萧晗的观察值得技术供应商深思："很多人低估了AI的运营挑战。"公共部门需要的不是更炫酷的模型演示，而是能在约束条件下稳定运行的工程方案。

硬件瓶颈的破局思路

GPU短缺是公共部门AI的显性约束，但解决方案不止"抢购显卡"一条路。

模型压缩技术（量化、剪枝、蒸馏）让SLMs在CPU上获得可接受的推理速度。边缘计算设备的算力提升，使得部分场景无需数据中心级部署。异构计算架构（CPU+FPGA/ASIC）在特定工作负载下性价比更优。

更根本的思路是重新分配计算负载：训练阶段可以集中进行（甚至外包），推理阶段必须本地完成。这种"重训练、轻推理"的架构，与企业的"轻训练、重调用"模式形成对照。

萧晗指出，政府机构的采购周期和运维能力与企业截然不同。选择技术路线时，必须考虑"五年后谁维护这个系统"的现实问题。

供应商选择的隐藏维度

公共部门AI采购的评估框架，正在从"功能对比"转向"风险共担"。

供应商的财务稳定性、长期支持承诺、开源组件比例、数据主权合规——这些"软实力"的权重在上升。一家初创公司的模型可能性能更优，但如果两年后倒闭，留下的技术债务由谁承担？

Elastic的商业模式（开源核心+商业支持）在公共部门有特定吸引力：避免单一供应商锁定，保留自主可控空间，同时获得企业级服务保障。

这种"开放核心"策略的代价是产品化程度较低，需要更多定制开发。但对于有专属技术团队的公共机构，这是可接受的权衡。

人员能力的结构性缺口

技术方案再完善，最终需要人来实施和运维。公共部门AI人才的困境在于：既懂政府业务又懂机器学习的人极度稀缺，而市场薪酬差距使得招聘难上加难。

务实的应对策略包括：与高校建立定向培养机制、通过服务采购引入外部专家、设计"业务人员+技术供应商"的协作模式、优先选择低代码/无代码的AI工具。

SLMs的相对简洁性在这里成为优势：微调（fine-tuning）和部署的门槛低于大模型，现有IT团队经过培训可以承担。萧晗强调，"连续性运营"要求系统不能依赖个别专家的存在。

评估ROI的特殊逻辑

企业AI项目的投资回报可以用效率提升、成本节约、收入增长来量化。公共部门的ROI计算更复杂，也更克制。

核心指标包括：决策质量的改善（错误率下降）、响应速度的提升（市民等待时间缩短）、合规成本的降低（审计通过率提高）、人员风险的缓释（关键岗位知识沉淀）。

这些指标的共同特点是：难以精确归因，需要长期追踪，且部分价值无法货币化。这要求公共部门AI项目有清晰的阶段性里程碑，而非等待"终极证明"才扩大投入。

一个实用的经验法则：如果某个AI应用在企业场景的价值是"10倍效率提升"，在公共部门场景应保守估计为"2倍风险可控的效率改善"。这种折扣不是悲观，而是对约束条件的诚实承认。

国际经验的参照与局限

爱沙尼亚的数字政府、新加坡的AI治理框架、英国的公共部门AI指南——这些案例常被引用为最佳实践。但直接复制的风险在于：制度环境、技术基础、人员能力的差异被忽视。

更有价值的借鉴是方法论层面：如何设计AI伦理审查流程、如何建立跨部门数据共享机制、如何培养公务员的AI素养。具体技术选型则需要本土适配。

Elastic在全球公共部门的项目经验显示，成功的AI部署往往遵循"最小可行产品→部门级试点→跨机构推广"的渐进路径，而非自上而下的大规模替换。

未来三年的关键变量

影响公共部门AI演进的技术趋势：边缘算力成本下降、模型压缩技术成熟、联邦学习（federated learning）框架完善、同态加密等隐私计算技术实用化。

政策层面的变量：数据跨境流动规则、AI系统透明度要求、政府采购标准更新、数字主权立法进展。

这些变量的交互将重塑"可行解空间"。今天的SLM方案可能在三年后因技术突破而显得保守，也可能因监管收紧而被证明有先见之明。

萧晗的判断是：公共部门的AI采用将长期呈现"双轨制"——对外服务场景（如市民咨询）可能接入云端大模型，内部决策支持系统则坚持本地化小模型。这种架构的复杂性是约束条件下的最优均衡。

给技术决策者的行动建议

如果你正在负责公共机构的AI落地，以下清单可供自检：

• 明确列出数据绝对不能离开本地的场景清单，这是架构设计的硬边界
• 评估现有IT基础设施的GPU/CPU算力储备，以及未来三年的扩展能力
• 要求供应商提供离线部署的完整方案，而非仅演示云端API调用
• 设计包含"断网模式"的灾备测试，验证系统在极端条件下的可用性
• 建立模型输出的审计追踪机制，确保每个关键决策有据可查
• 与法务部门确认AI应用的合规基线，避免技术方案与法律要求冲突

这些步骤不 glamorous（ glamorous），但区分了"演示成功"与"生产就绪"。

公共部门AI的真正挑战，从来不是"能不能做到"，而是"在约束条件下如何可持续地做到"。小语言模型的兴起，本质上是对这一问题的工程回应——不是追逐参数规模的竞赛，而是在控制、可靠、可审计之间寻找可行路径。对于技术供应商，这意味着产品定义需要从"功能最多"转向"约束最优"；对于政府机构，这意味着评估框架需要从"对标企业"转向"认清差异"。79%的安全顾虑不会自动消失，但可以被结构化的方案逐步化解。