汽车工程 AI 治理

速览.

EU AI Act 自 2024 年 8 月 1 日起生效。GPAI 义务自 2025 年 8 月 2 日起适用；高风险系统义务自 2026 年 8 月 2 日起适用。使用 GenAI 的汽车工程团队需要立即治理——而非等到 2027。

汽车企业正在从孤立的生成式 AI 实验，转向能够评审需求、分析架构、提出威胁、生成代码、编写测试、分诊缺陷、汇总事件、并调用工程工具的系统。其生产力潜力是真实的，治理挑战同样真实。

起草会议纪要的聊天机器人构成一种风险画像；提出威胁场景的 AI 助手构成另一种风险画像。一个能开 Issue、修改需求、触发测试台或建议接受残余风险的智能体，其后果会大得多——因为它影响受控的工程决策，并可能通过特权工具采取行动。

因此，汽车 AI 治理必须延伸到工作产物，而非止步于模型本身。团队需要知道：哪个 AI 系统为某条需求、TARA、控制、测试、报告或事件决策做出了贡献；它使用了哪些来源；由谁审阅；以及一旦模型、Prompt、数据或工作流后续被证明存在缺陷，会波及哪些项目。

本指南把 NIST AI 风险管理框架的四项职能——治理（Govern）、映射（Map）、度量（Measure）、管理（Manage）——适配到汽车工程与网络安全。文中还会展示 ThreatZ 与 Uraeus AI 如何在持续运营的 CSMS 内治理 AI 辅助的网络安全工作，而企业模型注册、法律分类、隐私治理与供应商管理仍由各自权威系统负责。

治理 AI 对受控工程产物的贡献

最具价值的治理问题不是"有没有人用了 AI？"，而是"AI 是否影响了车辆项目所依赖的产物或决策？"

受控产物可能包括：

项目与系统定义。
需求与架构决策。
损害与威胁场景。
攻击路径、可行性评级与风险评分。
网络安全目标、需求、控制与声明。
源代码、配置与标定建议。
测试用例、预期结果与证据摘要。
供应商评估与漏洞处置决策。
合规报告与网络安全案例。
事件分类、影响分析与修复建议。

针对每一次实质性贡献，建立一条 AI 贡献记录，并与最终产物关联。该记录应捕捉：AI 系统及版本、工作流或 Prompt 版本、用户或智能体身份、授权输入来源、检索到的证据、输出时间戳、自动化策略决策、人工审阅人、采纳/拒绝、修改、以及最终批准版本。

这比简单贴一个"AI 生成"标签更有价值。它建立了一条可审查的链条：从源证据 → AI 提案 → 人工决策 → 受控工作产物。当某个模型版本、检索源或智能体工作流后续被撤回时，它也支持影响半径分析。

从 AI 系统与工作流清单开始

大多数组织无法治理自己看不见的东西。AI 通过企业许可证、云平台、开发者助手、供应商工具、开源模型、浏览器扩展、内嵌产品功能与个人账户进入工程团队。

盘点完整的 AI 系统，而不只是基础模型。记录：

系统、业务与技术负责人。
供应商、模型家族、版本、托管方式与区域。
拟用用例与禁止用途。
用户、角色、项目与所连接的工具。
数据类别、检索来源与知识库。
Prompt 与输出是否被保留或被供应商用于训练。
智能体动作与工具权限。
人工评审与审批节点。
评估结果、局限性与接受阈值。
监管、安全、网络安全、隐私与知识产权分类。
供应商、再分包方、监控、事件响应与退役计划。

在系统获得敏感工程数据或进入生产工作流之前，必须先完成注册。发现工具能帮助识别影子 AI，但治理也应让"合规路径"比"非正式路径"更易使用。

对与 ThreatZ 对接的 AI，清单应标明它可以读取或可以提议修改的模块与实体：架构、资产、威胁、风险、控制、测试、SBOM 组件、漏洞、事件、报告或组织级目录。

按后果对用例分级

风险等级应反映 AI 能影响什么，而不是模型本身看起来多么惊艳。

T1：辅助型低后果用途

例子包括起草非机密沟通、改写文本，或汇总已批准的公开材料。控制可以轻量，但隐私、知识产权与准确性仍然重要。

T2：工程支持

AI 搜索已批准的知识、解释代码、评审需求、总结发现或建议测试。它支撑决策，但不能在没有人工动作的情况下更改受控记录。

T3：受控工程生成

AI 生成可能进入已批准工作产物的需求、威胁、攻击路径、控制、代码、测试用例或合规文本。必须具备正式溯源、评估、评审与可追溯性。

T4：智能体执行

AI 能够创建或修改记录、开启或关闭 Issue、调用工具、运行分析、触发测试、变更配置或推进工作流状态。需要强工作负载身份、最小权限、执行边界与显式人工授权。

T5：产品级或安全相关 AI

AI 行为参与到车辆功能、运行决策或安全相关输出。这需要产品专属的安全、网络安全、验证与监管流程，超出本文覆盖的企业级控制。

分级应考虑可逆性、规模、可检测性、数据敏感度、下游依赖与传播范围。草稿里的措辞错误易于纠正；被复制进 30 个项目的生成式控制模式可能埋下大面积隐蔽缺陷。

在三层之间明确问责

AI 的责任经常被笼统地指给"业务方"。请明确三类负责人。

系统负责人

对 AI 服务、供应商关系、配置、访问、安全与生命周期负责。

用例负责人

对工作流、决策权、人工评审、性能要求与业务结果负责。

产物或产品负责人

对进入车辆项目的需求、架构、代码、TARA、测试、报告、Release 或运行决策负责。

同一人可兼任多个角色，但职责必须清晰。对高后果用例，应指定独立审阅人与能够暂停该系统的治理权威。

AI 不得接受自己的产出。推荐器可以提出威胁、控制或测试；负责的工程师批准、修改或拒绝它。残余风险接受、合规签字、供应商验收与发布批准应保持为人工掌控的决策。

在 Prompt 之前先治理数据

Prompt 指南固然重要，但更关键的控制在于决定系统能接收哪些数据、以及如何处理。

对以下类别的输入进行分类：

公开信息。
内部业务信息。
客户与供应商机密数据。
源代码与专有算法。
车辆架构与安全设计。
个人数据。
漏洞与事件信息。
出口管制或受监管数据。
安全分析与未发布产品信息。
凭据、密钥与其他机密。

为每个类别定义已批准的模型与托管选项。敏感工程数据可能要求私有云或本地部署、禁止供应商训练、限制保留、区域驻留、加密、受控管理员与完整审计日志。

检索系统必须保留源权限。AI 助手不应将一份供应商文档返回给无法直接打开原始来源的工程师。在检索、引用与工具调用过程中传递身份与授权。

在 ThreatZ 中，AI 应只在用户被授权访问的项目与组织数据上工作。推荐应保留对图中实体与证据的引用，而非以无依据的自由文本呈现。

控制智能体身份与权限

能调用工具的智能体应当被视作特权服务账号。

请落实：

唯一的工作负载身份。
读、提议、执行、批准权限相互分离。
对项目、仓库、工具与命令实施最小权限。
沙箱、开发、生产环境分离。
白名单、参数校验、事务上限与速率控制。
对高影响动作的人工审批。
限时凭据与快速吊销能力。
完整的工具调用与结果日志。
紧急停机开关与安全回滚路径。

不要"为了让智能体有用"就授予宽泛权限。先从只读上下文与提议变更开始；只有当评估证明性能可靠、组织能够检测、遏制并回退故障后，再扩大权限。

工具描述与被检索内容是安全边界的一部分。被篡改的工单、文档、代码注释或网页可以通过 Prompt 注入劫持智能体。要对连接器认证、校验工具输出、把指令与数据分离，并测试多步骤滥用，而不只是评估孤立 Prompt。

把 AI 辅助的 TARA 作为有边界的评审工作流来治理

AI 辅助的 TARA 是一个有力的首选用例，因为它价值明显、可度量、且天然可评审。若建议被静默转化为已批准的威胁或风险决策，它也具有风险。

采用六阶段工作流：

受控上下文：AI 获得用户被授权访问的已批准系统模型、项目范围、目录与证据。
提议：AI 给出候选资产、损害场景、威胁、攻击路径、控制或测试用例，并附理由与来源引用。
结构化评审：合格工程师在相关架构、既有风险与源证据旁同时看到提议。
处置：评审人采纳、修改、拒绝或暂缓提议，并记录关键决策的原因。
可追溯基线：被采纳的内容成为版本化项目产物，与其 AI 贡献记录及人工批准相关联。
监测与学习：精确度、拒绝模式、漏掉的威胁、评审工作量与后续缺陷反馈进入评估与工作流改进。

ThreatZ 中的 Uraeus AI 即按此"提议-评审"模型设计。视已启用模块与当前 Release 范围，它可协助提供资产、威胁、控制与测试的推荐、为项目检查缺失链接，并协助导入或修复历史数据关系。产品团队应让"推荐"在视觉与逻辑上始终与"已批准"分离。

AI 绝不应虚构来源、悄悄变更风险方法学、批准残余风险或覆盖受控基线。当证据不完整时，正确的输出可能是一个问题或一个缺口，而非一个自信的推荐。

要求 AI 辅助产物具备溯源信息

有用的溯源信息包括：

AI 系统、模型与版本。
Prompt、智能体工作流与策略版本。
用户或工作负载身份。
输入来源与检索引用。
输出时间戳与（有意义时的）置信度指示。
自动化过滤与策略决策。
人工审阅人与处置结果。
生成后做出的修改。
最终产物版本与批准。

不要无差别保留敏感 Prompt。采用风险驱动的保留策略并保护记录。某些情况下，哈希、结构化来源列表、工作流版本与决策摘要比完整 Prompt 更合适。

溯源应可查询。若后续发现某个模型版本遗漏了一类攻击路径，组织应能识别每一份依赖它的 TARA、控制或测试提议。

针对真实工作流来评估系统

通用基准分数无法证明其适用于汽车用例。请使用具代表性的架构、术语、数据、用户与失败后果进行评估。

对工程与网络安全工作流，度量：

准确性与完整性

推荐是否技术正确？是否遗漏关键资产、威胁、假设或变体？

依据与可追溯性

每一条实质性陈述是否都可追溯至已批准来源、图中实体、规则或明确标注的推断？

鲁棒性与安全性

面对模糊输入、冲突来源、Prompt 注入、被投毒的检索内容、畸形工具输出与权限边界，系统反应如何？

一致性

同一已批准输入是否会在没有说明的情况下产生差异显著的风险处置？产出能否在不同项目与变体之间保持一致？

人因因素

评审人能否发现错误？界面是否显示来源、不确定性与审批状态？工作量是否鼓励审慎评审而非橡皮图章？

运行性能

在模型中断、额度耗尽、检索失败、供应商变更或工具部分执行时，会发生什么？

针对 AI 辅助 TARA，构建专家评审过的评估集。追踪候选威胁精确度、关键威胁召回率、不当控制、虚构来源、错误的追溯链接、重复建议、评审时长以及采纳后的实质性修改率。

在测试前定义接受阈值。高后果用例应包含负面测试、红队演练与独立评审。

人工监督需要被设计，而非被声明

"人在回路"可以指认真的专家评审，也可以指用户读一行就点"批准"。请把评审任务设计出来。

指定：谁有资格、必须可见哪些证据、评审人必须核实什么、哪些错误必须升级、是否需要第二评审人、分歧如何记录、以及哪些动作不可委派。

避免审批疲劳。如果智能体生成数百条低价值建议，用户会盖橡皮图章。请提升精确度、优先呈现高影响推荐，并把信息性输出与需审批动作分离。

对关键决策，AI 是提议者，人工掌控的工作流仍是决策权威。在 ThreatZ 中，被采纳的推荐应进入与手工创建产物相同的版本控制、审批与报告流程。

把模型与工作流变更视为工程变更

云端 AI 服务可能更换模型、安全过滤、上下文长度、检索行为、API、托管方式或再分包方。内部团队也会改 Prompt、工具、目录与智能体权限。

定义"实质性变更"触发条件：

新模型或新供应商。
新检索语料或安全目录。
Prompt、智能体工作流或策略变更。
新工具权限或项目范围。
新数据类别。
微调、适配器或嵌入变更。
评估出现显著漂移。
新的法律或供应商条款。

在投入生产使用前运行回归评估。保留先前已批准配置与回滚路径，记录每个版本下产生过的受控产物。

一个连通的 CSMS 能让变更影响分析真正可行。若某个模型或工作流失败，ThreatZ 可协助识别与受影响 AI 贡献相关的架构元素、威胁、控制、测试、报告与项目。AI 平台或模型注册仍是模型生命周期的真相源；ThreatZ 提供的是产品安全侧的影响半径。

对运行中的 AI 进行监测

上线前评估只是基线。请持续监测：

按系统、团队、项目、数据类别划分的使用量。
被拒绝或违反策略的请求。
工具调用与特权动作。
人工采纳、拒绝与实质性修改率。
无依据推荐与引用失败。
检索失败与陈旧来源。
Prompt 注入与连接器安全事件。
成本、延迟、可用性与模型漂移。
未完成评审的高影响输出。
意外用例或跨项目访问。

对智能体系统，请监测动作序列，而不只是单次调用。一连串被允许的动作可能产生整体上不安全的结果。

把实质性的 AI 发现连接到受影响的项目与产物。如果一个模型缺陷影响了进入车辆项目的网络安全需求或测试，那它就不只是 IT 事件。

准备 AI 事件与产物召回手册

AI 事件可能包括机密数据泄露、未授权工具执行、有害生成代码、被破坏的需求、错误的合规内容、Prompt 注入、供应商被入侵或缺陷推荐被大规模复用。

响应应当：

停用或限制系统并吊销凭据。
保留日志、模型与工作流版本及相关证据。
识别受影响的用户、产物、项目、供应商、Release 与报告。
评估产品、安全、网络安全、隐私与合同影响。
隔离、复审或纠正生成的产物。
在必要时通知相关方。
更新评估、控制与培训。
批准受控复用或退役该工作流。

最难的工作是产物召回。ThreatZ 可通过把 AI 贡献记录链接到受控网络安全产物及其下游关系来支持这一过程。组织随后可以提问：例如，工作流版本 X 提议了哪些高风险控制，又被复用到了哪些项目？

2026 年的监管与标准背景

EU AI Act 自 2024 年 8 月 1 日起生效，并分阶段适用。被禁止的实践与 AI 素养义务自 2025 年 2 月起开始适用；治理规则与通用人工智能（GPAI）模型义务自 2025 年 8 月起适用。欧盟委员会当前的实施页面表明：在 2026 年 8 月 2 日起，绝大多数剩余规则适用；针对特定高风险系统则有更晚日期，遵循 2026 年关于 AI Omnibus 的政治协议。组织应在发布或合规决策前立即核对最终立法文本与官方指南。

并非每个内部工程助手都属于该法案下的高风险 AI 系统。即便某项具体义务不适用，治理能力依然有价值：清单、角色、数据治理、技术文档、日志、人工监督、准确性、鲁棒性、网络安全与上线后监测。

NIST 的 AI RMF 通过"治理-映射-度量-管理"提供自愿性结构。其生成式 AI 简版补充了被生成式系统放大的风险所对应的动作。ISO/IEC 42001 提供组织级 AI 管理体系框架。汽车安全、网络安全、质量与软件标准仍适用于受 AI 影响的产物与产品。

正确的方式是整合式保证，而非另起一摞 AI 文书的孤岛。

ThreatZ 的可治理 Uraeus AI 控制模式

ThreatZ 不是企业模型注册中心、不是通用隐私平台、也不是法律意义上的 AI Act 分类引擎。其最强角色是在汽车网络安全工程内部治理 AI 贡献。

一种可辩护的控制模式是：

授权上下文：RBAC 限定用户与 AI 服务可访问的项目、目录、架构、供应商与证据。
生成提案：Uraeus AI 给出推荐、评审发现或导入/链接修复建议，而非静默修改已批准产物。
保留依据：提案保留其来源实体、工作流版本与相关证据。
要求处置：合格负责人采纳、修改、拒绝或上升该推荐。
结果基线化：被采纳内容进入版本控制与常规 CSMS 审批。
链路验证：控制与需求关联到测试与证据；失败或陈旧的证据可重新开启评审。
影响监测：事件、漏洞、架构变更或模型缺陷可回溯到受影响的风险与产物。
透明报告：项目能展示哪些内容由 AI 辅助、谁批准、以及最终决策由哪些证据支撑。

这在商业上比把 AI 定位为"自动化 TARA"更稳。其价值是受治理的加速：平台可在保持工程问责、可追溯性与审计证据完整的前提下，减少重复性分析。

在 ThreatZ 中开展 90 天可治理 AI 试点

选定一个有边界的工作流，例如为某个 ECU 提议威胁与测试用例，或对一个项目审查缺失的风险-控制-测试链接。

第 1–30 天：定义范围与基线

第 31–60 天：配置与评估

以"仅提议"模式运行 Uraeus AI。度量精确度、关键遗漏、虚构来源、错误链接、评审耗时与 Prompt 注入抗性。记录每一次处置，并在不静默更改风险方法学的前提下调优工作流。

第 61–90 天：在控制下运行

启用已批准工作流，含 RBAC、溯源、评审、版本化、监测与事件响应。模拟一次模型或检索缺陷，并证明团队能识别每一条受影响的提议与已批准产物。

只有在试点同时满足工程价值与控制阈值后再扩展。

面向领导层的指标

请追踪：

已注册并分级的 AI 系统与工作流占比。
高后果用例中具有已批准评估的占比。
使用唯一最小权限身份的智能体工具占比。
具备完整贡献记录的 AI 辅助受控产物。
推荐的采纳、拒绝与实质性修改率。
AI 辅助 TARA 的关键威胁召回率与不当控制率。
无依据引用与错误追溯链接率。
因模型或工作流问题影响产物的识别时长。
等待回归测试的模型或供应商变更数量。
Prompt 注入与未授权工具调用事件。
按用例划分的评审工作量与业务结果。
被检测到的未批准 AI 服务。

不要只用许可证、Prompt 或生成内容数量来衡量成功。要衡量 AI 是否在不削弱产品控制的前提下改善了工程结果。

常见问题

企业层的 AI 使用策略够了吗？

不够。策略是必要的，但每个实质性用例还需要负责人、数据规则、评估、权限、产物级溯源、人工监督、监测与变更管理。

ThreatZ 中的 AI 能批准 TARA 或残余风险吗？

AI 可协助提议与项目评审，但应由问责工程师批准受控产物与风险决策。AI 不应批准自身产出。

智能体式 AI 有何不同？

智能体可借助工具采取行动、修改系统，并把多步动作串成时间序列。治理必须控制身份、权限、动作序列、审批与回滚，而非仅生成文本。

在 ThreatZ 中最强的首选用例是什么？

针对单个 ECU 的威胁、控制或测试用例的有边界"提议-评审"工作流是有力首选，因为质量、评审工作量、溯源与安全失败都可度量。

AI 系统应多久重新评估一次？

在模型、供应商、数据、Prompt、目录、工具权限或工作流发生实质性变更后重新评估，并按风险驱动的、由运行监测信息支撑的时间表持续进行。

权威参考

NIST AI Risk Management Framework
NIST AI RMF Playbook
NIST Generative AI Profile
European Commission AI Act implementation page
Regulation (EU) 2024/1689 - the EU AI Act
European Commission guidelines for providers and deployers of high-risk AI systems
ISO/IEC 42001:2023 - AI management systems

汽车工程的 AI 治理： 控制 GenAI、智能体与 AI 生成的工程产物