内生安全上车：对比特斯拉与中国车企的AI安全底座

2026-04-02 07:49，36氪一则快讯提到：海光信息在 2026 年春季技术沟通会上，正式公开基于“内生安全”理念的多项新成果，并首发海光 DCU 软件栈年度版本。信息量不大，但信号很清晰——安全正在从“事后加固”变成“底层能力”，而且开始沿着芯片—软件栈—系统平台这条链往上走。

这件事放到智能汽车领域，会更有意思。智能座舱、城市 NOA、端到端大模型上车之后，车已经是一个移动的数据中心：采集、存储、训练、推理、 OTA 更新、云端闭环，每个环节都在吞吐数据。AI 体验拼得再猛，一旦底层安全逻辑是补丁式的，最后都会在合规、事故、品牌信任上付出代价。

我更愿意把“内生安全”当成一个可以迁移的工程方法：把安全当成系统的“原生属性”。借海光这次公开成果的契机，我们把镜头拉到“AI 驱动的汽车平台”，对比特斯拉与中国汽车品牌在 AI 战略上的一个核心差异：把安全当作 AI 生产力的一部分，还是把安全当作成本中心。

“内生安全”到底解决什么问题：从补丁式到体系化

“内生安全”要解决的核心矛盾很直白：当系统复杂度指数级上升时，传统“发现漏洞—打补丁—再发现”的方式会失效。

在智能汽车里，这种复杂度体现在三层叠加：

• 计算复杂度：域控/中央计算平台、AI 加速器、异构计算（CPU+GPU/DCU+NPU）并存
• 软件复杂度：操作系统、虚拟化、容器、AI 框架、模型、工具链、OTA 管线
• 生态复杂度：第三方应用、供应链固件、数据标注与训练外包、云端服务接口

一旦复杂度上来，攻击面就会变成“面粉状”散布在每个角落：启动链路、驱动、固件、模型文件、数据集、训练脚本、推理服务、诊断接口、OTA 包。

内生安全的工程含义可以抽象为一句话：把安全能力做进架构里，让系统默认“可验证、可隔离、可追溯、可恢复”。在半导体与芯片设计语境下，它往往从硬件信任根、指令级隔离、内存保护、加密与认证开始；而海光提到的“DCU 软件栈年度版本”，则提示我们：安全不只是芯片特性，还必须落到软件栈的可用性与可运维性上。

可被引用的一句话：AI 系统的安全，不是多装一道门，而是把承重墙从一开始就按安全标准浇筑。

为什么智能汽车更需要“内生安全”：数据闭环决定上限

智能驾驶与大模型上车的竞争，本质是“数据闭环”的竞争：

1. 车端采集（摄像头/雷达/座舱交互/车辆状态）
2. 边缘筛选与上传
3. 云端训练与评估
4. 模型灰度与 OTA
5. 车端推理与反馈

这里最容易被忽略的一点是：安全与数据闭环不是两件事。你越依赖数据闭环，越依赖“数据可信、模型可信、更新可信”。

常见风险不止是“黑客远程入侵”这种老故事，更多是 AI 时代的新型风险：

• 训练数据投毒（Data Poisoning）：脏数据混入训练集，造成特定场景误判
• 模型供应链污染：第三方模型/算子/依赖库被植入后门
• 提示注入与多模态攻击：座舱语音/图像输入诱导系统执行越权操作
• OTA 包篡改与回滚攻击：利用版本管理漏洞把车降级到可被利用的旧版本
• 隐私合规与跨境数据：数据出境、个人信息保护、车端敏感信息处理

这也是为什么“内生安全”更像是平台能力：它要覆盖从芯片到软件栈、从车端到云端、从研发到运维的全生命周期。

特斯拉 vs 中国车企：AI 战略差异，往往先体现在“安全怎么做”

两类路线在 2026 年已经非常清晰：

1）特斯拉：软件优先，安全更像“产品工程”

特斯拉的优势不只是算法或算力，更是软件与数据体系的一体化。它通常会把安全当作产品工程的一部分来管理：

• OTA 是常态：频繁更新意味着必须建立严密的签名、验证、灰度与回滚策略
• 数据回流依赖规模：规模越大，越需要数据分级、脱敏、访问审计与训练可追溯
• 平台统一：硬件相对收敛，方便把安全机制做成“平台默认能力”

这类思路的结果是：安全投入能直接换来迭代速度与事故成本下降——安全不是“拖后腿的流程”，而是“迭代的护栏”。

2）中国汽车品牌：生态更复杂，安全更像“供应链工程”

中国车企的现实约束是生态与供应链复杂度更高：多芯片、多域控、多供应商软件、多种 OS/中间件并存。于是安全常常被拆散到不同团队、不同供应商：

• 芯片厂做硬件安全
• Tier1 做系统加固
• 主机厂做合规与渗透测试
• 云服务商做账号与权限

问题是：当责任被切碎，漏洞也会在缝隙里长出来。

这正是海光这类“芯片 + 软件栈”厂商公开“内生安全”成果的价值：它提供一种更可落地的路径——把安全从“采购清单”拉回“架构设计”，让车企在异构算力与多供应商现实下，仍能建立统一的安全基线。

我的判断：未来三年，中国车企 AI 体验的分水岭，不在“模型参数更大”，而在“平台安全能力是否可复用、可规模化”。

从 DCU 软件栈想到的三件事：车端 AI 安全该怎么落地

海光提到“首发 DCU 软件栈年度版本”，这类节奏（年度版本、工具链化）对汽车很有启发：车端 AI 安全要可持续，不能靠一次性项目。

1）把“信任链”做完整：启动—固件—驱动—模型—应用

车端 AI 平台的信任链至少要覆盖：

• Secure Boot：启动链路校验，防止固件被替换
• 固件与驱动签名：供应链来源可验证
• 模型文件签名与版本绑定：模型不是“普通资源文件”
• 运行时完整性度量：关键进程/容器被篡改可检测

如果你只能证明“系统没被改”，却证明不了“模型没被换”，那在端到端驾驶时代等于没设防。

2）把“隔离”做工程化：域隔离不够，还要算子与数据隔离

汽车传统的隔离更多是域控层面（座舱域 vs 智驾域）。但大模型上车后，隔离必须更细：

• 训练/推理环境隔离（云端尤其关键）
• 多租户数据隔离（车队数据、测试车数据、员工数据）
• 权限最小化与零信任访问（研发、运维、标注、外包）

在芯片与软件栈维度，这意味着虚拟化、容器安全、机密计算/可信执行环境（TEE）会越来越“标配化”。

3）把“可追溯”做成制度：数据、特征、模型、指标四账合一

AI 安全最怕“出了事说不清”。建议车企建立“四本账”，并用工具链强制执行：

1. 数据账：数据来源、脱敏策略、访问记录
2. 特征账：特征生成代码版本、统计分布漂移
3. 模型账：训练配置、依赖库、权重哈希、评测报告
4. 指标账：线上指标、长尾场景、回归测试、事故复盘

这套体系看似“研发流程”，实则是内生安全在 AI 时代的落地形态。

车企与供应链的下一步：把安全当作“算力利用率”的乘数

在“人工智能在半导体与芯片设计”这条主线里，很多团队把注意力放在算力、带宽、功耗与良率上。但我越来越确信：安全会成为算力利用率的乘数。

原因很现实：

• 安全薄弱会降低 OTA 频率，直接降低模型迭代速度
• 合规风险会限制数据回流规模，直接影响训练数据质量
• 事故与召回会迫使策略保守化，等于把算力闲置

所以，海光信息公开“内生安全”成果，表面是安全议题，背后其实是产业链的共识迁移：要在 AI 时代跑得快，底座得先“跑得稳”。

如果你在做智能汽车平台（主机厂、Tier1、芯片与软件栈厂商都算），我建议用一个简单的自检问题收尾：

你的 AI 平台能否在 72 小时内完成一次“可验证、可回滚、可审计”的模型 OTA？

能做到，说明你开始具备内生安全的雏形；做不到，体验再好也会被现实按下暂停键。