1. 这条民调数字背后普通人在担心什么73% 这个数字一出来我朋友圈里做 AI 产品的、做数据合规的、还有几个在传统行业做风控的老朋友几乎同时转了同一条消息。大家讨论的角度不太一样但核心情绪是共通的公众对 AI 公司的信任赤字已经大到没法用“技术还在早期”这种话糊弄过去了。先把这条民调本身说清楚。路透社和益普索联合做的这项调查核心结论是大约 73% 的美国受访者认为AI 公司在“防止 AI 造成灾难性后果”这件事上做得不够。注意这里的措辞不是“AI 技术本身危险”也不是“AI 会抢走工作”而是把矛头指向了公司这个主体——你们这些造 AI、卖 AI、部署 AI 的机构在安全防护上的投入和透明度没达到公众期待的水平。这个指向性非常关键。它意味着公众的焦虑已经从“技术恐惧”升级成了“治理不信任”。技术恐惧可以靠科普缓解但治理不信任只能靠制度、流程和可验证的行动来修复。我做过几年企业级软件的安全合规咨询见过太多团队在“技术能力”上很强但在“让外部相信我们做了该做的事”这件事上几乎零投入。AI 行业现在整体就处在这个状态。这篇文章我想聊的不是这条民调的政治含义而是把它当成一个信号拆解一下AI 公司在安全防护上到底应该做什么、公众在担心哪些具体场景、以及一个普通从业者或团队负责人能从这条新闻里拿走什么可落地的东西。不管你是做模型的、做应用的、还是做企业采购决策的这条民调都值得你花二十分钟认真对待。适合读这篇的人AI 产品经理、技术负责人、安全合规岗、企业 IT 采购、以及任何想把 AI 用在自己业务里但心里没底的人。我会尽量少讲空话多讲能直接对照检查的清单和判断标准。2. 拆解“防止灾难”这四个字公众到底在怕什么2.1 灾难不是科幻片是四个具体的失效场景很多人一听到“AI 灾难”就想到终结者这其实是把问题娱乐化了。我在实际做风险评估的时候会把“灾难性后果”拆成四个层级从近到远分别是第一层个体级伤害。比如 AI 给出的医疗建议导致误诊、AI 招聘系统系统性歧视某一类候选人、AI 客服在用户情绪危机时给出错误引导。这类事件每天都在发生只是大多数没上新闻。第二层组织级失控。比如企业把核心决策交给 AI 但缺乏人工复核导致大规模错误放贷、错误拒保、错误裁员。这类事件的破坏力是批量化的。第三层基础设施级风险。比如 AI 系统被恶意利用来生成大规模钓鱼内容、自动化攻击脚本、深度伪造的欺诈素材。这已经不是单个公司的问题而是整个数字生态的问题。第四层长期系统性风险。比如模型能力集中在极少数机构手里、训练数据不可追溯、评估标准不统一导致整个行业在“没人能独立验证安全性”的状态下狂奔。公众说的“防止灾难措施不够”大概率指的是前三层尤其是第一层和第二层——因为这些是他们能感知到的。第四层是从业者才关心的但恰恰是第四层决定了前三层的天花板。2.2 为什么公众把责任归给“公司”而不是“技术”这里有个很微妙的心理机制。技术是中性的这个说法在公众那里已经失效了。原因很简单技术不会自己部署自己是公司决定把它部署到哪里、给谁用、用什么防护级别。我举个实际例子。同一个大语言模型用在内部知识库检索和用在面向公众的医疗咨询风险等级完全不同。前者出错最多是员工查不到资料后者出错可能耽误治疗。但很多公司在两个场景用的是同一套防护策略甚至根本没有场景分级。公众虽然不懂技术细节但他们能感觉到“你们没认真对待不同场景的差异”。所以这条民调的本质是公众在要求 AI 公司展示场景化的安全投入而不是笼统地说“我们很重视安全”。重视是态度投入是证据。2.3 73% 这个比例意味着什么我查了一下这类调查的历史数据做对比。在自动驾驶、基因编辑、核能这些领域公众对“企业安全措施是否足够”的怀疑比例通常在 50% 到 65% 之间波动。73% 是一个相当高的数字说明 AI 行业的信任度比这些传统高风险行业还要低。更值得注意的是这个数字在不同人群中的分布。根据我看到的公开分析年轻群体和高学历群体的怀疑比例并不比整体低多少。这打破了一个常见假设——“懂技术的人会更信任 AI 公司”。实际情况是越了解技术边界的人越清楚当前防护措施的薄弱环节在哪里。这对 AI 公司的启示很直接你不能靠“教育用户”来解决信任问题因为最该被教育的那批人恰恰是最不信任你的那批人。你只能靠可验证的行动。3. AI 公司现在实际做了哪些防护缺口在哪3.1 当前主流的安全投入清单我在过去两年接触过十几家不同规模的 AI 公司从几十人的初创到几千人的大厂团队。把他们的安全投入归归类大致是这么几块防护类型典型做法覆盖比例我的观察主要缺口模型层防护红队测试、对抗训练、输出过滤较高大厂基本都有测试标准不统一结果不公开应用层防护内容审核、人工复核、限流中等取决于产品形态场景分级粗糙复核流于形式数据层防护数据溯源、隐私脱敏、授权管理偏低尤其初创训练数据来源不透明组织层防护安全委员会、伦理审查、外部审计很低多数是摆设没有独立否决权披露层防护模型卡、系统卡、事件报告极低出了事基本不主动说这张表里最扎眼的是最后两行。组织层和披露层的投入恰恰是公众最在意、也最容易验证的部分但也是行业做得最差的部分。模型层和应用层的技术防护外人看不懂但“你们有没有一个能否决产品上线的安全委员会”“出了事故多久披露”这些是公众能理解的。3.2 为什么技术防护做得再多公众还是不买账这里有个认知错位。技术团队觉得“我们做了这么多红队测试、加了这么多过滤规则”但公众看到的是“你们连最基本的透明度都没有”。我打个比方。这就像一家餐厅后厨装了一堆高级消毒设备但从不允许顾客看后厨也不公布食材来源。顾客的怀疑不会因为你说“设备很高级”而消除反而会觉得“你这么遮遮掩掩是不是设备根本没在用”。AI 公司现在普遍处在这个状态。技术防护是“后厨设备”披露和治理是“明厨亮灶”。73% 的不信任很大程度上不是对技术能力的怀疑而是对“你们愿不愿意让我看见”的怀疑。3.3 一个被忽视的缺口中小 AI 公司的安全能力大厂好歹有资源做安全团队真正的问题在中小公司。我见过不少十几人的 AI 创业团队产品已经服务几十万用户了但安全防护就是创始人兼着看一眼没有任何系统化流程。这不是他们不负责任而是安全投入在早期没有直接商业回报很容易被无限期推迟。但公众不会区分你是大厂还是初创出了事都是“AI 公司”的锅。所以这条民调的压力最终会通过监管和舆论传导到每一个从业者身上。4. 从这条民调能拿走的可落地动作4.1 给 AI 产品团队的场景分级自查表如果你在做 AI 产品不管规模大小我建议你先做一件事把你们所有的 AI 功能按风险等级分个类。不用很复杂就三档高风险输出直接影响人身安全、财产、法律权益、心理健康。比如医疗建议、金融决策、招聘筛选、危机干预。中风险输出影响用户体验但可逆。比如内容推荐、客服应答、代码补全。低风险输出仅作参考、有明确人工兜底。比如内部检索、草稿生成。分完类之后对照检查高风险功能有没有人工复核环节有没有输出边界限制有没有异常情况的熔断机制如果高风险和中风险用的是同一套防护那你的缺口就很大。提示场景分级不是做一次就完事产品每加一个新功能都要重新过一遍。我见过太多团队在早期分了级后来功能越加越多分级表再也没更新过。4.2 透明度建设的最小可行方案公众要的透明度不是让你公开模型权重和训练数据那既不现实也没必要。最小可行的透明度是让外部知道你的安全流程存在且在被执行。具体可以做这几件事成本都不高发布简版系统卡一页纸说明这个 AI 系统能做什么、不能做什么、已知的失败模式是什么。不用很学术说人话就行。建立事件披露机制明确什么级别的事故会在多长时间内对外说明。哪怕只是承诺“重大安全事件 72 小时内发布初步说明”都能大幅提升信任。引入外部视角哪怕请一两个外部顾问参与安全评审也比纯内部闭环强。外部人的价值不在于技术多强而在于“有人能从外面看”。定期发布安全投入摘要不用很详细说清楚这季度做了哪些测试、发现了哪些问题、怎么修的。这些事加起来一个两三个人的团队一两周就能搭起框架。关键是愿不愿意做。4.3 给企业采购方的判断清单如果你是在企业里负责采购 AI 服务的人这条民调对你是个提醒你不能只看功能演示和报价得看供应商的安全治理成熟度。我整理了一个简单的判断清单采购时可以直接问你们有没有独立于产品团队的安全评审流程谁有否决权过去一年有没有发生过安全事件怎么处理的有没有对外披露你们的模型训练数据来源能不能追溯有没有版权和隐私审查如果我这个场景属于高风险你们能提供什么额外的防护配置出了事故责任怎么划分有没有明确的 SLA 和赔偿机制供应商如果对这些问题的回答含糊其辞那风险就要你自己扛了。5. 常见问题与实操避坑5.1 小团队资源有限安全投入怎么排优先级这是我最常被问到的问题。我的建议是先做“防大错”的事再做“防小错”的事。防大错指的是高风险场景的人工兜底、输出内容的硬性边界比如医疗场景不能给具体用药剂量、异常情况的自动熔断。这些不需要很多资源但能挡住最严重的后果。防小错指的是更精细的内容过滤、更全面的红队测试、更复杂的对抗训练。这些可以随着业务增长逐步补。很多团队的误区是反过来先花大力气做精细过滤但高风险场景连人工复核都没有。这是典型的“用战术勤奋掩盖战略懒惰”。5.2 怎么判断自己的安全措施“够了”没有绝对的标准但有一个实用的判断方法假设你的 AI 系统明天出了一个严重错误你能不能拿出一套完整的记录证明你在上线前做了合理的防护、在上线后做了持续的监控。如果能那你的措施在“尽职”层面是够的。如果不能那不管技术多先进你都是裸奔。这个判断方法来自法律上的“合理注意义务”概念。公众和监管不会要求你做到完美但会要求你证明你认真对待了。记录和流程就是你的证据。5.3 透明度会不会带来额外的法律风险这是很多法务和老板的顾虑主动披露问题会不会被抓住把柄我的观察是主动披露的风险远小于被动曝光的风险。主动披露时你掌握叙事主动权可以说明背景、原因、改进措施。被动曝光时你只能被动挨打而且公众会默认你之前一直在隐瞒。当然披露要有策略。不是所有细节都要公开但“发生了什么类型的问题、影响范围多大、我们怎么处理的”这个框架要有。具体的技术细节和用户数据当然要保护。5.4 这条民调会不会只是一阵风不会。我判断这类公众情绪有几个特征一旦形成很难逆转会通过监管和采购行为逐步落地对行业的实际影响有滞后但持续。具体到 AI 行业我预计未来一两年会看到几个变化安全治理岗位的需求上升、第三方安全评估服务兴起、企业采购时安全条款权重提高、以及针对 AI 事故披露的行业规范逐步形成。这些变化对认真做安全的团队是利好对糊弄的团队是压力。6. 我个人在实际操作中的几点体会做了几年 AI 相关的安全合规工作我最大的体会是安全这件事技术只占三成流程和意愿占七成。我见过技术能力很强的团队因为老板觉得“安全拖慢进度”而把防护做得形同虚设也见过技术一般的小团队因为负责人认真用很朴素的方法把风险控制得不错。公众感受到的“措施不够”大多数时候不是技术不够而是意愿不够。另一个体会是透明度建设越早做越省事。早期产品简单披露框架搭起来很容易。等产品复杂了、用户多了、出过事了再补成本和难度都翻倍。我建议任何做 AI 产品的团队在第一个版本上线前就把系统卡和事件披露机制的基本框架定下来哪怕内容很粗糙。最后一个很实际的建议别把安全当成一个项目当成一个习惯。每次迭代、每次加功能、每次换模型都花十分钟过一遍风险清单。这十分钟的投入长期看能省掉无数麻烦。73% 这个数字不是要吓唬谁它只是在提醒我们公众的耐心是有限的而信任一旦失去重建的成本高得惊人。