1. 为什么2025年的AI安全问题核心不再是“模型”而是“基础设施”过去两年我们聊AI安全聊的最多的是模型幻觉、提示词注入、越狱攻击这些东西。但如果你真的在一线摸过大型模型的部署和运维你会意识到一个残酷的事实模型层面的安全手段再完善也扛不住底层基础设施被人捅穿。算力集群被入侵、训练数据被窃取、模型权重被篡改、推理服务被DDoS打到瘫痪——这些问题里至少有一半以上不是模型算法能解决的而是云平台、硬件、网络、存储这些“地基”的安全问题。百度智能云发布的《AI基础设施安全白皮书 2025》之所以值得认真读就是因为它把视角从“模型安全”拉回到了“承载模型的那套物理和逻辑底座”。这和我过去一年处理过的好几个真实案例是吻合的。比如某客户训练集群里的NCCL通信数据被旁路抓包导致训练样本特征泄露再比如某个大模型推理服务在压测时暴露了GPU显存中的数据残留下一批用户的请求可能反推出前一批用户的中间计算结果。这些问题你用再强的护栏模型、再多的提示词过滤都解决不了必须回到基础设施层面去堵。对于正在做AI原生应用、大模型微调或者企业私有化部署的团队来说这份白皮书的参考价值在于它把AI安全从“纯软件层”扩展成了一个覆盖硬件可信根、虚拟化隔离、数据加密流转、供应链完整性、合规治理的工程体系。也就是说安全工程师、云平台架构师、算法工程师这三拨人以前各管一段现在必须坐到同一张桌子上。这篇内容我会重点拆解白皮书中我认为最有信息量的几个方向顺带附上我在实际项目中踩过的一些坑和验证过有效的做法。2. AI基础设施安全的“四层视图”白皮书的核心分析框架白皮书里我最认可的一点是它对AI基础设施做了一个非常清晰的分层。这个四层视图虽然不是什么新技术名词但它把原本零散的安全能力归到了一个统一的坐标系里方便你对照检查自己的短板。2.1 算力层从可信根到异构计算的信任边界第一层是底层硬件和算力资源。GPU、TPU、FPGA这些异构计算设备加上服务器的CPU、内存、固件构成整个AI系统能够运行的物理前提。白皮书强调的“可信根”概念在这里变得非常重要——也就是说你得能证明一台服务器从开机那一刻起就是可信的BIOS没有被改过、固件没有植入后门、启动链路上的每个组件都经过完整性校验。我在实际项目中见过一个典型的反面案例某客户从第三方渠道采购了一批二手GPU服务器用于内部推理集群搭建结果运行三个月后发现有节点被用于挖矿后来排查发现是UEFI固件里被植入了恶意模块重装系统都没用。这就是可信根失守的典型案例。所以白皮书把“硬件可信根启动度量运行时度量”作为算力层安全的基础要求不是纸上谈兵而是血的教训。2.2 数据层训练数据全生命周期中的流转安全第二层是数据准确说是AI数据的全生命周期安全。从数据采集、预处理、标注、训练、验证、微调到最终部署后的推理调用数据在每个环节都存在不同的暴露风险。白皮书特别提到了三个容易被忽视的点。第一是数据完溯源——不仅仅是“这份数据从哪来的”而是要能证明“这份数据从采集到进入训练集中间没有被篡改过”。第二是加密流转尤其是跨节点、跨机柜甚至跨数据中心的训练数据传输。第三是差分隐私和脱敏的统一策略。这一点在实际项目中很难做到统一因为不同业务线的数据脱敏标准不一致有的用掩码有的用泛化有的直接哈希结果在数据融合训练时隐私保护强度完全不一致等于没有统一防线。2.3 模型层从训练到推理的连续性防护第三层是模型本身的安全。白皮书对模型层的描述涵盖了三个环节训练过程安全、模型文件安全和推理安全。训练过程安全关注的是训练框架、分布式调度组件、通信库是否存在可被利用的漏洞。举个例子很多团队用的是开源的分布式训练框架这些框架的Master节点往往有Web管理界面如果暴露在非信任网络里攻击者可以通过提交恶意任务的方式间接控制worker节点执行任意代码。这类攻击路径在真实世界里是存在的而且隐蔽性极高。模型文件安全则是相对容易被忽略的一块。很多团队对模型权重的保护力度远低于对数据库密钥的保护模型文件直接放在共享存储上权限配置宽松。白皮书的观点是模型权重应该具备完整的数字签名和版本校验机制任何非授权的修改都应该能被发现。推理安全涉及到的是运行时的问题。比如模型推理服务是持续暴露在公网上的攻击者可以通过大量恶意请求耗尽计算资源也可以利用模型的置信度信息做成员推断攻击判断某些样本是否存在于训练集里。这些都是模型层的真实风险。2.4 应用层Agent工作流与大模型应用的全新攻击面第四层是AI原生应用层也是2025年新增攻击面最多的地方。随着Agent化应用的普及模型不再是简单的一句话接一句话地处理请求而是会调用工具、访问数据库、操作外部系统。这个过程中安全边界被急剧扩大。一个AI客服Agent在处理用户请求时可能需要查询用户订单数据库、调用支付接口、发送短信。攻击者如果精心构造自然语言输入就可能诱导Agent执行预期之外的操作。这就已经不是传统Web应用安全能覆盖的场景了。白皮书把应用层的身份认证、权限管控、会话隔离、输出内容安全都归到了这个层级我觉得是很有前瞻性的判断。3. 白皮书中值得实操的三道技术防线机密计算、零信任与供应链完整性如果说四层架构是告诉你“哪些地方有风险”那白皮书后半部分给出的技术防线就是你“具体用什么手段去防”。这三道防线我认为是2025年AI基础设施安全里含金量最高的部分。3.1 机密计算让“数据在计算过程中也可信”成为可能传统的数据保护思路是静止时加密、传输时加密但运行时数据必然以明文形式存在于内存中。这在以前是个默认接受的风险但在AI训练场景中这个问题被放大了。因为训练数据集往往规模庞大而且高度敏感如果一台训练节点被攻破内存中的数据暴露规模可能就是几个GB甚至几十个GB。白皮书着重讲了基于硬件的可信执行环境也就是TEE。简单说TEE机制下CPU或GPU会在硬件层面划分出一个隔离的执行环境数据和代码在这个环境内完成计算即使操作系统或者宿主机被攻破也无法访问TEE内部的数据。当前主流的实现包括Intel TDX、AMD SEV-SNP、NVIDIA的机密计算方案以及基于RISC-V架构的可信执行环境。在实操层面我建议有敏感数据训练需求的团队认真评估TEE的落地成本。一个可行的路径是把训练过程中的数据预处理环节放到TEE里做脱敏再把脱敏后的数据交给常规GPU集群训练。这样一个折中方案成本增加不算太大但能把最有风险的数据暴露时间窗口尽量压缩。3.2 零信任架构在AI场景中的迁移适配零信任架构核心原则是“永不信任始终验证”。在传统IT架构里这套原则已经实践了好多年但在AI基础设施场景里迁移起来并没有那么顺滑。原因在于AI基础设施的内部流量模式和传统业务有本质差异。传统Web业务是“用户到应用服务器到数据库”这种清晰的东西向链路你可以在每个边界上做严格的访问控制。但AI训练集群的流量模式是“分布式节点之间高频全互联”GPU节点每训练一个step就要和其他节点同步梯度数据。这种通信频率极高、连接数量极多如果按照传统零信任那种逐一认证授权的模式性能开销会大到不可接受。白皮书对这个问题给出的思路是“分域微分”把整个AI基础设施划分成若干个信任域域间严格执行零信任管控域内则依赖底层隔离能力保证安全。这个思路我认为是务实的——你不太可能在每个GPU卡的通信链路上都做一次TLS握手认证但在不同的安全域边界上做严格的管控是完全可行的。实际落地时一个比较容易上手的切入点是对管理面的零信任改造。训练任务提交、集群资源申请、模型发布这些操作都通过统一的身份认证和权限管理系统来做并且配上严格的可追溯审计。这样即使内网某个节点被攻破攻击者也无法立即横向移动到管理面发起更高级的操作。3.3 供应链完整性AI基础设施里最容易被忽视的深水区白皮书把供应链安全单独拿出来讲这一点让我印象深刻。AI基础设施的供应链比传统IT更长、更复杂也更难把控。算力层面GPU服务器的固件、驱动、管理接口均有供应链风险软件层面AI框架的开源依赖动辄几十万个组件任何一个上游包被投毒都可能通过依赖传递进入你的训练环境模型层面如果你使用了从网上下载的预训练模型攻击者完全可以构造一个带后门的模型权重在特定输入条件下触发恶意行为。这种“AI供应链投毒”的攻击方式隐蔽性极高且很难被发现。我见过一个比较小众但值得警惕的做法是攻击者向开源模型库提交一个性能表现不错的模型但在权重中嵌入了一个“特定keyword触发”的后门。使用者在常规测试集上看到的性能指标很好但一旦在生产环境里触发了那个隐藏的keyword模型就会输出有害内容或者执行恶意路径。这个问题在纯算法层面很难提前防范只能通过供应链管理手段来控制。实操建议就三条一是建立软件物料清单所有引入的软件组件都必须有明确的来源登记和漏洞跟踪二是对模型文件的来源、哈希校验、签名做严格管理不随便跑陌生人提供的权重三是对供应商做分级审查越是核心的硬件和软件越要追溯其供应链上下游来历。4. 从合规必做题到安全治理白皮书透露的三个行业信号白皮书不只是讲技术方案它还花了相当的篇幅在讲安全治理和合规趋势。我读完之后发现里面藏着三个值得所有做AI的人关注的行业信号。4.1 安全不再是上云之后的“补丁”而是选云时的“前提条件”过去大多数企业选择云平台时核心考量点是价格、算力规模、框架兼容性安全往往是后面才补的。白皮书释放的信号是在AI基础设施层面安全能力正在从“售后选项”变成“售前必选项”。这个变化背后的逻辑很直接。企业如今上AI往往涉及核心数据资产——训练数据、模型权重、用户信息。这些资产一旦泄露影响不可逆。与其事后补救不如在选型阶段就把安全能力作为和算力同等重要的评估维度。如果一个云平台无法说清楚它的硬件可信根机制是什么、GPU实例之间的隔离技术是什么、供应链管理做了哪些事情那它在2025年的AI基础设施竞争中就会失去入场券。4.2 大模型备案只是起点安全治理走向全流程化国内的大模型备案和生成式AI服务监管过去两年已经逐步成熟。白皮书在这一点上的补充是备案只是一张入场券之后的常态化安全治理才是真正的重头戏。全流程化安全治理体现在几个方面第一是安全评估要从“上线前一次评估”变成“上线后持续评估”因为模型会持续更新、数据会持续增加、应用场景会持续扩展每一次变化都可能带来新的安全风险。第二是安全责任要从“安全团队单独扛”变成“业务、算法、运维、安全四方共担”任何一个环节都不能只当旁观者。第三是安全审计要从“出了问题再查”变成“全链路可追溯”操作行为、数据流向、模型版本变更都要有完整清晰的审计日志。4.3 安全左移还是右移答案是全流程覆盖前几年DevSecOps圈子里喜欢争论安全左移还是右移意思是安全介入应该早还是晚。白皮书借AI基础设施场景给出的答案很明确——不是选一边而是全流程覆盖。在需求阶段要定义清楚数据合规边界和模型安全目标在开发训练阶段要嵌入代码审计和训练数据保护在部署上线阶段要做漏洞扫描和渗透测试在运行阶段要做好威胁监测和应急响应在模型退役阶段还要确保权重彻底销毁、数据不可恢复。任何一个环节的缺失都会成为安全链条中最薄弱的那一环。5. 基于白皮书框架的自检清单照着查一遍就能发现不少问题如果觉得白皮书内容太大、不知道从哪里下手我做了一份自检清单你可以直接拿回去对照现有的AI基础设施做个初步体检。5.1 算力与硬件侧服务器固件是否做过完整性校验有没有定期巡检计划GPU/NPU驱动和带外管理接口的访问权限是否受限计算节点是否有侧信道隔离措施防止同一物理机上的跨租户攻击废弃和退役的硬件设备存储介质是否做过数据销毁5.2 数据侧训练数据的存储是否默认加密密钥由谁管理、如何轮换数据从存储到训练节点的传输链路是否加密数据标注、清洗等环节的外协人员访问权限和审计机制是否到位训练日志和中间检查点中是否可能包含原始数据或敏感特征这一条在实际项目中特别容易翻车。很多团队的训练日志里会同步打印部分样本内容或者中间层的特征输出安全团队往往没有意识到这些日志本身也是敏感数据的载体。5.3 模型侧模型文件是否有版本管理、数字签名和完整性校验预训练模型的来源是否可信是否做过安全评测微调过程是否引入了新的数据投毒风险模型推理服务是否有针对恶意输入的检测和限流机制模型输出的内容安全过滤是前置过滤还是后置过滤覆盖面是否足够5.4 运行与管理侧AI平台的管理平面是否启用了多因素身份认证用户提交训练任务之前是否有资源配额和内容审核机制推理服务是否存在可被利用的注入点或路径穿越漏洞是否有覆盖全链路的日志采集和溯源能力应急预案里是否包括了“模型被篡改”“训练数据泄露”“推理服务被攻击”这几种AI特有场景6. 未来一到两年AI基础设施安全会往哪走白皮书收尾部分的趋势判断我认为值得展开聊几句因为它大概率会决定接下来一两年的技术走向和职业发展方向。6.1 安全能力将更多下沉到硬件芯片层软件层面做安全始终会有性能损耗和绕过风险。未来AI安全的决胜点会在硬件层面。芯片内置加密引擎、GPU显存加密、NVLink/PCIe链路上的硬件级防护、以及专门为AI设计的机密计算指令集都会成为标配。算力芯片厂商之间的竞争除了比拼浮点算力安全特性的强弱也会成为重要指标。6.2 AI用于安全对抗的趋势不可逆AI基础设施安全未来不只是“保护AI”也包括“利用AI做防护”。传统的规则和签名机制在面对自动化生成攻击载荷时已经力不从心。大模型可以分析海量日志并快速发现异常模式也可以基于代码语义识别漏洞。安全运营的效率提升在不远的将来会明显依赖AI的辅助分析能力。6.3 安全人才的知识结构需要重置最后说点个人的判断。过去做云安全核心知识体系是网络、系统、虚拟化、容器这些。AI基础设施安全在这个基础上需要增加分布式训练架构、GPU编程模型、模型运行机制、数据处理管道的理解。单纯会渗透测试或者会写WAF规则的人在AI安全领域的价值正在下降真正紧缺的是那种既懂安全攻防也能看懂训练脚本、理解模型结构、知道数据管道薄弱点在哪儿的复合型人才。我自己的体会是这两年做AI项目的安全方案最大的挑战往往不是技术本身而是安全人员和技术人员“鸡同鸭讲”。安全工程师说“要加密”算法工程师说“加密会拖慢训练效率”安全说“要隔离”运维说“隔离会增加延迟”。白皮书提供了一套双方都能参考的公共语言让安全需求和技术实现能放在同一个框架里对话。这是它最有价值的地方。如果你打算系统性地给自己的AI业务做一次安全升级建议把白皮书里的四层架构当作参考基线先从数据层和模型层入手这两层是当前大多数AI团队最容易出问题的地方。等这两层的安全能力补齐了再往算力层的可信根和供应链纵深推进。路要一步一步走安全要一层一层补。