收益：
- 能够解释 ISO 26262 功能安全和 ISO 21448 (SOTIF) 框架及其对包含人工智能的系统的影响
- 能够管理汽车环境中的数据隐私、驾驶员数据、网络安全 (ISO/SAE 21434) 和道德风险
- 通过了解人工智能输出不能替代合格工程师的批准，能够保持人类对安全关键决策的责任
您处于本模块最关键的单元中。到目前为止，我们已经将人工智能视为从设计到制造、从测试到供应链的加速器。但汽车领域的决定性问题是：这个系统会伤害任何人吗？谁负责？本单元以通俗易懂的语言涵盖了在安全关键行业中负责任地使用人工智能的框架——功能安全、SOTIF、网络安全、隐私和道德。核心原则保持不变：人工智能输出永远不会取代有能力的工程师的认可；安全关键决策和责任属于人类。
ISO 26262：功能安全
ISO 26262 是道路车辆电气/电子系统的功能安全标准。功能安全；它涉及确保当系统发生故障（传感器损坏、软件故障）时不会导致危险情况。
该标准的核心是 ASIL（汽车安全完整性等级）。危险从三个维度进行评估：
- 严重性：如果发生的话会有多糟糕？ （轻伤或死亡）
- 暴露：这种情况发生的频率是多少？
- 可控性：驾驶员能在多大程度上控制局势？
这三者相结合，形成从 ASIL A（最低）到 ASIL D（最高，例如制动、转向）的级别。随着级别的提高，开发、测试和文档要求变得更加严格。
主要
样品系统
需求强度
A.
车内照明故障
低
B.
尾灯
中等
C.
一些ADAS功能
高
D .
制动、转向、安全气囊
最高
提示：了解某个功能的 MAIN 级别可以告诉您在该功能中使用 AI 需要多少注意力。如果没有独立的安全验证，则不能接受基于功能中人工智能输出的任何决策。
ISO 21448 (SOTIF)：预期功能的安全性
经典功能安全 (ISO 26262) 重点关注“如果系统出现故障会发生什么？”的问题。但人工智能检测系统存在一个新问题：即使系统从未出现故障，也可能存在不足。相机工作正常，但无法识别雪板；雷达是固态的，但它会将静止的车辆视为幽灵信号而忽略。这里没有硬件/软件故障；问题在于该功能的预期范围的限制。
ISO 21448 - SOTIF（预期功能的安全性）正是解决了这一差距：即使系统按设计运行，也可以管理因无法识别的场景、检测限制和不可预见的情况而产生的风险。在基于人工智能的 ADAS/自动驾驶中，SOTIF 与 ISO 26262 一样重要。
框架
焦点
例子
ISO 26262
失败带来的风险
传感器损坏，信号消失
ISO 21448（SOTIF）
不充分/不认可的风险
坚固耐用的相机无法识别雪板
ISO/SAE 21434
网络安全
系统攻击、数据操纵
注意：AI 模型是统计性的；他们不能保证自己会“正确地看待每一种情况”。 SOTIF 旨在缩小这些本质上有限的系统中未知危险场景的范围，并将剩余风险降低到可接受的水平。 “该模型的准确率达到 99.9%”并不能证明安全性。
ISO/SAE 21434：网络安全
联网和软件定义的车辆很容易受到网络攻击。远程攻击者可以改变制动命令、窃取遥测数据或欺骗检测模型（对抗性攻击：通过在盘子上放置小贴纸使模型误识别）。 ISO/SAE 21434 是车辆网络安全的工程框架。在人工智能的背景下，有两个风险很突出：欺骗模型（对抗性）和毒害训练数据（数据中毒）。对安全至关重要的人工智能系统应该针对这些攻击进行测试。
隐私和个人数据
现代车辆是一个“车轮上的数据中心”：位置、驾驶行为、音频，甚至车载摄像头。其中大部分是个人数据，受 KVKK（土耳其）和 GDPR（欧洲）管辖。 VIN（底盘号）可以识别车辆并间接识别其所有者。基本原则：
- 数据最小化：仅收集需要的数据。
- 目的限制：不得将数据用于收集目的以外的目的。
- 匿名化/假名化：删除或编码个人识别信息。
- 明确同意和透明度：驾驶员必须知道正在收集什么。
- 安全存储和传输。
注意：将原始 VIN、位置历史记录或驾驶行为发送到公共云 AI 工具可能会侵犯隐私和合同风险。使用这些数据时，请将其匿名并使用受数据保护的制度环境。
道德和工程师责任
人工智能带来了一些伦理风险：
- 偏差：如果训练数据在某些条件下占主导地位（例如白天、浅色皮肤、某些区域道路），则模型在代表性不足的条件下（夜间、不同条件）可能表现不佳。这是一个漏洞。
- 过度自信（自动化偏见）：人们盲目相信自动化并推翻自己的判断。如果测试工程师仅仅因为人工智能说“通过”就停止查看原始数据，那么这是一种危险的趋势。
- 责任丧失：“模型决定”不是辩护理由。决定背后应该始终有一个人签字。
小型案例研究
情况 1 - SOTIF 限制。自动紧急制动系统通过了所有实验室测试，没有出现任何故障。在田野里，在低矮的阳光下，一辆白色卡车将拖车误认为是天空，刹车迟了。这不是故障，而是 SOTIF 漏洞：系统完好无损，但场景超出了检测极限。团队将此场景添加到测试库中，并加强雷达融合。结论：“无故障”并不能证明安全；不足也是一种风险。
案例 2 - 有偏见的数据。行人检测模型主要使用白天数据进行训练；夜间记忆力显着降低。该团队平衡和重新训练夜间和弱光数据，并分别报告夜间场景。结论：在某些情况下，不平衡的数据会造成致命的漏洞。
案例 3 - 隐私泄露预防。一位分析师正要将车队数据粘贴到公共人工智能工具中，这时他注意到数据包含原始 VIN 和 GPS 位置。它通过匿名化数据在企业环境中工作（vehicle_01..arac_50 代替 VIN，区域代码代替位置）。结果：一时的注意阻止了严重的 KVKK 违规行为。
提示模板
模板 1 - 事先/风险初步评估（草案）：
角色：您是功能安全顾问。任务：准备一份草案以帮助对功能进行危害和风险分析。背景： 功能：自动紧急制动；城市和城际。约束：ASIL 的精确分配；列出严重性/暴露性/可控性维度的问题和注意点；表明最终任务由授权的安全工程师负责。输出：大小 |评价问题|注意事项表。
模板 2 - SOTIF 场景扫描：
角色：您是 SOTIF 专家。任务：列出检测功能可能“系统完好但不充分”的场景。场景：摄像头+雷达；低太阳、雪、隧道出口、异常物体。输出：场景 |为什么不足|削减建议。
模板 3 - 隐私控制：
角色：您是数据保护 (KVKK/GDPR) 顾问。任务：在共享数据集之前进行隐私审核。背景：舰队遥测；这些列包含 VIN、GPS、驾驶分数。约束：哪些字段是个人数据，应该如何匿名化，什么是我根本不应该共享的；排序。输出：字段 |风险|推荐交易图表。
模板 4 - 偏差检查：
角色：您是机器学习安全和公平审核员。任务：告诉我如何在检测模型中寻找偏差风险。背景：行人检测；训练数据加权日/城市。输出：要检查的条件 |测量|风险标志。
弱提示/强提示
弱提示：
确认一下这个自动制动系统安全吗？
试图获得人工智能安全许可是危险的；批准属于授权工程师。
强力提示：
角色：您是功能安全和 SOTIF 顾问。任务：列出在自动制动功能的安全评估中我应该提出哪些问题以及应该收集哪些证据。背景：基于人工智能的检测；摄像头+雷达； ASIL 可以很高。约束：“批准”系统；根据 ISO 26262（缺陷）和 SOTIF（缺陷）提供单独的问题和证据列表；强调最终批准权在于授权的安全工程师。输出：框架|问题|所需证据表。
常见错误
- 将“无故障”与“安全”混淆。 SOTIF 缺陷可以在不发生故障的情况下导致死亡。
- 获得人工智能安全许可。授权工程师负责批准并承担责任。
- 将模型准确性误认为是安全性的证明。 99.9% 的准确率并不表明剩余风险已得到管理。
- 不保护个人数据。 VIN/位置/驾驶行为属于 KVKK/GDPR 的范围。
- 忽视偏见和过度自信。数据不平衡和对自动化的盲目信任都是漏洞。
综上所述
- ISO 26262 管理因故障而产生的风险（具有 ASIL），而 ISO 21448/SOTIF 则管理无故障的故障风险；两者对于人工智能检测都至关重要。
- ISO/SAE 21434 网络安全；对抗性攻击和数据中毒攻击是人工智能特有的威胁。
- 在 KVKK/GDPR 范围内，数据最小化、目的限制和匿名化是强制性的； VIN/位置是个人数据。
- 偏见、过度自信和责任丧失是主要的道德风险。
- AI输出不能替代合格工程师的认可；安全关键决策和签名始终属于个人。
应用任务
选择安全相关功能（例如车道保持）。 (1) 讨论为什么该功能的 ASIL 级别在严重性/暴露/可控性维度上可能会高/低。 (2) 使用模板 2 生成 5 个“系统可靠但不充分”的场景。 (3) 使用模板 3 对相关数据集进行机密性审核。 (4) 解释为什么说“模型已确认”不是一种抗辩。
清单
- [ ] 我评估了该功能的实际维度（我将确切的分配留给了权威机构）。
- [ ] 我区分了 ISO 26262（故障）和 SOTIF（不足）。
- [ ] 我已经考虑到网络安全（对抗性/中毒）风险。
- [ ] 我对个人数据进行了匿名化和最小化。
- [ ] 我检查了偏见和过度自信的风险。
- [ ] 我已确认合格工程师已获得安全许可。