没有解决方案或技术类别实际上获得了安全关键系统的认证。在指定系统时，要识别危害，定义要求以避免或减轻这些危害到适当的置信水平，并提供证据证明设计和实施满足这些要求。认证只是简单地签署，在特定系统的背景下，已提供适当的证据来证明风险（某些事件发生的可能性的产物，以及如果该事件发生时的不利影响）是可接受的低的声明。最多，为特定产品（在您的情况下为 AI 引擎）提供或开发了一组证据，这些证据将在其他系统组件（也需要获取或提供证据）的上下文中进行分析，以及组装这些组件的方法进入一个工作系统。获得认证的是系统，而不是用于构建它的技术。由特定技术或子系统提供的证据很可能被重用，但将在使用该技术或子系统的每个完整系统的需求上下文中对其进行分析。
这就是为什么某些技术被描述为“可认证”而不是“已认证”的原因。例如，某些实时操作系统 (RTOS) 的版本附带一组证据，可用于支持接受它们所使用的系统。但是，这些操作系统未经认证可用于安全关键系统，因为必须在使用 RTOS 的每个总系统的总体要求的背景下评估证据。
提倡形式证明为某些类型的系统或子系统提供所需的证据。一般来说，形式证明方法不能很好地扩展（证明的复杂性至少与系统或子系统的复杂性一样快），因此通常采用证明以外的方法。无论如何提供证据，都必须根据正在构建的整个系统的要求对其进行评估。
现在，人工智能在哪里适合呢？如果要使用 AI 来满足与减轻或避免危害相关的要求，则有必要提供证据证明它们在整个系统的环境中这样做是适当的。如果 AI 未能满足这些要求，则整个系统（或受 AI 未能满足要求影响的其他子系统）有必要控制或减轻影响，因此系统整体上满足其完整的要求。
如果 AI 的存在阻止提供足够的证据证明系统作为一个整体满足其要求，则不能使用 AI。这同样适用于提供此类证据在技术上是不可能的，或者如果现实世界的限制阻止在正在开发的系统的上下文中交付该证据（例如，对可用人力、时间和其他资源的限制影响交付系统的能力）并提供符合其要求的证据）。
对于具有非确定性行为的子系统，例如 AI 的学习，任何无法随着时间的推移重复给出结果都将使得提供所需证据变得更加困难。提供的证据中存在的差距越多，就越有必要提供证据证明系统的其他部分减轻了已识别的危害。
一般而言，单独进行测试被认为是提供证据的不良手段。基本原因是测试只能根据需求确定存在缺陷（如果测试结果证明），但不能提供不存在缺陷的证据（即通过所有测试用例的系统不会提供任何未测试的证据为了）。困难在于证明测试提供了足够的需求覆盖率。这引入了在具有安全相关要求的系统中使用 AI 的主要障碍——系统级别的工作必须提供满足要求的证据，因为提供足够的基于测试的证据将非常昂贵。人工智能。
在系统级别使用的一种策略是分区。人工智能与其他子系统的交互将受到很大限制。例如，人工智能可能不会直接与可能导致危险的执行器交互，而是会向其他子系统发出请求。然后，举证责任在于其他子系统满足要求的程度，包括它们与执行器交互的方式。作为提供该证据的一部分，其他子系统可能会检查来自 AI 的所有数据或请求，并忽略任何可能导致不适当驱动（或任何其他违反整体系统要求）的内容。因此，人工智能本身实际上可能根本不满足任何与安全相关的要求——它可能只是获取信息或向其他子系统提供信息，而那些其他子系统实际上更直接地有助于满足整个系统的要求。鉴于 AI 的开发人员可能无法提供所有需要的证据，因此可以肯定的是，系统开发人员将尝试限制 AI（如果采用）可能对整个系统的行为产生的影响。
另一种策略是限制人工智能的学习机会。例如，每个训练集都将提供证据——在人工智能本身的背景下——人工智能以可预测的方式运行。每次更新训练集时都需要提供这些证据，然后需要重新对整个系统进行分析。这可能是一项重大任务（即漫长而昂贵的过程），因此人工智能或其训练集可能不会以特别高的速度更新。