3. 安全与合规基本概念

在自动驾驶数据闭环中，“安全”并不是一个单一指标，而是由多个相互关联、边界清晰又彼此补充的概念共同构成的体系。很多团队在早期只关注“功能是否正常”，却忽略了功能安全、预期功能安全、网络安全、数据隐私与法律法规之间的分工与协同，导致后期在合规审查、事故复盘或数据出境评估时出现系统性缺口。本节将围绕这五个核心概念，建立一张可落地的认知地图。

一、核心原理：五类安全概念的边界与协同

功能安全（Functional Safety, FuSa）关注的是系统故障引发的危害。它假设系统本身存在随机硬件失效、系统性失效，要求通过安全机制将风险降低到可接受水平。典型标准是 ISO 26262，核心手段包括危害分析与风险评估（HARA）、ASIL 等级划分、安全目标与安全机制设计。

预期功能安全（Safety of the Intended Functionality, SOTIF）关注的是系统无故障但性能不足引发的危害。例如感知算法在逆光、雨雾、异形车辆等场景下漏检，或决策算法对罕见场景理解不足。ISO 21448 是其核心标准，重点在于场景识别、触发条件分析、已知不安全与未知不安全场景的收敛。

网络安全（Cybersecurity）关注的是恶意攻击与未授权访问。ISO/SAE 21434 与 UN R155 构成了主要框架，覆盖 TARA 分析、安全启动、SecOC 通信、OTA 签名、密钥管理与入侵检测。它保护的是数据与控制的完整性、真实性和可用性。

数据隐私（Data Privacy）关注的是个人信息与敏感数据的合法处理。自动驾驶车辆采集的车外影像、车内音视频、位置轨迹、生物特征等，均可能构成个人信息甚至敏感个人信息。GDPR、中国《个人信息保护法》《汽车数据安全管理若干规定》等提出了告知同意、最小必要、匿名化、本地化存储等要求。

法律法规体系则是上述技术安全要求的外部约束与责任边界。它既包括产品准入、型式认证、事故责任，也包括数据出境、测绘资质、算法备案等运营合规要求。

二、方法流程：从概念到闭环落地

在数据闭环工程中，五类概念需要被映射为可执行的活动，而不是停留在文档层面。推荐按以下流程推进：

1. 场景与资产梳理：识别数据闭环中涉及的功能、数据流、接口、外部依赖与利益相关方。
2. 风险与合规分析：并行开展 HARA、SOTIF 场景分析、TARA、隐私影响评估（PIA）与法规适用性分析。
3. 需求与机制设计：将安全目标、安全机制、隐私策略、合规控制点写入系统需求与数据字典。
4. 验证与确认：通过仿真、封闭场地、道路测试、渗透测试、数据审计等方式验证控制有效性。
5. 运营与监控：建立事件上报、漏洞管理、数据访问审计、法规变化跟踪机制。
6. 复盘与迭代：将事故、near-miss、漏洞、投诉转化为场景库与需求更新，回流到数据闭环。

三、案例/场景：一次数据回传引发的合规连锁反应

某自动驾驶公司计划将测试车采集的车外视频回传至云端，用于感知模型训练。技术团队认为视频已做车牌模糊化，风险可控。但在合规评审中发现：

• 视频中包含行人面部、道路环境与地理位置，仍可能构成个人信息；
• 部分数据需传输至境外服务器，触发数据出境安全评估；
• 车辆未取得测绘资质，高精度地图相关数据采集存在合规风险；
• OTA 升级包未做签名校验，存在被篡改的网络安全风险。

最终，该项目被迫调整数据架构：增加本地脱敏与匿名化处理、限制出境数据范围、补充测绘合作方资质、引入 SecOC 与安全启动机制。这个案例说明，安全与合规不是事后补丁，而是数据闭环架构设计的前置输入。

四、误区与复盘：常见认知偏差

五、关键参数与检查清单

在工程落地时，可将以下参数作为数据闭环安全与合规的基线检查项：

# 安全与合规基线检查示例
FuSa:
  - HARA 完成，ASIL 等级已分配
  - 安全目标与安全机制可追溯
SOTIF:
  - 已知不安全场景清单已建立
  - 触发条件与性能边界已量化
Cybersecurity:
  - TARA 完成，攻击树已评审
  - 安全启动 / SecOC / OTA 签名已启用
Privacy:
  - 数据分类分级完成
  - 告知同意、最小必要、匿名化策略已落地
Legal:
  - 数据出境评估已完成
  - 测绘资质、算法备案、事故上报路径明确