当扫描结果看起来像法律判定时
如果您可能在欧盟提供 AI 智能体，自然会问：“我们的代码能通过 EU AI Act 吗？”一款扫描文件并按条款显示 PASS 的工具颇具吸引力，因为它似乎能在法务审查前迅速找出风险区域。
AIR Blackbox 的制作者报告称，他们扫描了 11 个开源项目中的 5,754 个 Python 文件，平均得分为 2.2/6，只有 23 个文件在全部六项条款中获得 PASS。对于 Article 9，97% 的文件未找到制作者映射的信号；Article 12 为 89%，Article 14 为 84%。
但不应将其解读为“EU AI Act 检查了代码并淘汰了 97%。”这既不是欧盟机构的调查，也不是法律意义上的合规性评估，而是工具制作者定义的文件级启发式规则的结果。
23 个 PASS 实际意味着什么
在当时的基准测试中，某一条款的 PASS 意味着：在与该条款关联的多个子信号中，至少有一个在文件中被发现。这 23 个文件是在六项条款中分别满足这一条件的文件，并非被认定为在法律上遵守了 EU AI Act 的六项条款。
在基准测试当时，制作者将风险分类、访问控制和风险审计关联到 Article 9，将错误处理和测试等关联到 Article 15。 制作者举例的 LiteLLM 认证模块已经具备访问控制、结构化日志、时间戳和错误处理。 这里的启示不是“这 23 个文件有什么特别秘诀”，而是日常运营控制也可能在静态分析中显现为有用线索。仅凭公开资料，无法确认其余所有 PASS 文件的共同点。
这些数字难以作为基准复现。
用于扫描的各仓库提交、文件选择标准和原始 JSON 无法通过当前公开路径复现。我们也未能确认对误报率和漏报率进行验证的独立评估。因此，不应将 2.2/6 或 0.4% 用作您项目的及格线或行业平均水平。
法律看的是系统，而不是文件
EU AI Act 的相关义务比单一代码模式宽泛得多。Article 9 要求对高风险 AI 系统的整个生命周期持续、反复实施并记录风险管理体系。Article 11 所称的技术文档也不是 docstring 或类型提示，而是为了让主管机关评估系统符合性、在投放市场前编制并保持最新的文档。
| 条款 | 法律要求的系统层面确认 | v1.15.0 扫描器寻找的主要线索 |
|---|---|---|
| Article 9 | 风险识别、评估、缓解和定期审查 | 错误处理、fallback·recovery |
| Article 11 | 能够进行符合性评估的最新技术文档 | 文档·类型信息 |
| Article 12 | 在系统生命周期内自动记录事件的能力 | 日志·审计追踪调用 |
| Article 14 | 可忽略·覆盖输出或安全停止系统的人类监督手段 | human-in-the-loop、用量·预算控制 |
| Article 15 | 准确性、稳健性和网络安全 | retry·backoff、提示注入防御、输出验证 |
右列概括的是当前公开的 v1.15.0 实现，与扫描 5,754 个文件时使用的映射不同。当前代码扫描器将错误处理和 fallback·recovery 归入 Article 9，将 human-in-the-loop 和用量·预算控制归入 Article 14，将 retry·backoff、提示注入防御和输出验证归入 Article 15。
存在日志调用并不能证明保留期限或可审计性。即使存在审批函数，也无法说明运营人员能否及时介入。扫描器应被用作指向待核查位置的导航工具，而非证据。该仓库也说明，此工具不是经过认证的合规性测试，而是发现潜在缺口的起点。 其自评覆盖的是预先准备的 72 个 fixture 和 12 项检查，并不保证对任意生产代码的准确性。
首次扫描应先分离结果的来源
您需要 Python 3.10 或更高版本、待检查项目的本地源代码，以及安装软件包和执行命令的权限。以下流程不是法律合规判定，而是在代码中寻找初步控制线索的工作。本文以已确认的 v1.15.0 发行版为准进行说明，但更新后检查条件和输出可能变化。
- 在项目环境中安装软件包。
pip install air-blackbox - 先记录已安装版本和帮助信息。 在检查报告中记录软件包版本和执行日期，并通过已安装命令的帮助信息确认选项。不要将历史基准测试中的条款映射直接套用到当前输出。
- 进入项目根目录。 如果是生产仓库，请从单独分支或只读副本开始。
- 首次比较时，关闭可选分析和历史保存后执行。
air-blackbox comply --scan. -v --no-llm --no-save
v1.15.0 的默认命令会检查本地网关状态，并同时输出静态检查和运行时检查。如果有 Ollama 和默认模型，它可以执行 AI 分析；在默认设置下，也会在本地保存检查历史。上述选项排除可选 LLM 分析和历史保存，使首次静态结果更便于比较。 - 区分网关未连接与控制缺失。即使没有 localhost:8080 网关，静态检查仍可能继续。如果运行时检查显示没有观测数据，应将其单独记录为尚未验证运行时，而不是把它当作控制不存在的证据。
- 一并保存每项检查的状态和 evidence 文案。当前 CLI 不再像历史案例那样提供按条款计的 6/6 分数，而是为每项检查输出 PASS·WARN·FAIL。PASS 也并不总是表示找到了控制信号。例如，Article 9 的错误处理检查在找不到直接 LLM 调用时，可能会条件性地显示 PASS。不要只转录状态；还要阅读检查条件和 evidence。
- 只将输出了位置的项目关联到文件。部分检查不会显示文件名或行位置，而只显示“在 N 个文件中发现”之类的汇总。不要把没有位置的结果记录为已自动确认代码位置；应根据该检查的检测模式，另行进行代码搜索和人工核查。
- 与系统证据进行比对。PASS·WARN·FAIL 都不是法律判定。请确认风险登记册、最新技术文档、实际日志保留、人类停止权限以及准确性·稳健性·安全性测试中的控制是否真正有效。
- 最后分类适用范围。请另行评估系统是否属于高风险类别、您的组织是提供者还是部署者，以及适用哪一项实施时间表。
首次成功标准不是 6/6。只要保存了安装版本和执行选项、每项检查的状态和 evidence，并且只把实际输出位置的项目关联到相应文件，第一步就完成了。请将没有位置的汇总结果和没有运行时数据的检查分离到后续搜索与运营核查清单中。
是否面向欧盟及实施日期也需要另行确认
即使是欧盟以外的经营者，如果在欧盟市场投放或提供 AI 系统，或其输出在欧盟被使用，也可能落入适用范围。但不能仅因有一名欧盟用户就一概得出结论。还应同时考察提供者·部署者角色及实际的市场提供关系。
实施时间表也不能简化为 2026 年 8 月 2 日这一天。该法原则上自该日起普遍适用，但当前官方指引将 Annex III 的特定高风险领域列为 2027 年 12 月 2 日，将嵌入受监管产品的 Annex I 高风险系统列为 2028 年 8 月 2 日。禁止性做法、AI 素养和通用 AI 义务适用其他时间表。
罚款也因违规类型而异。最高 3,500 万欧元或全球年营业额的 7% 是违反 Article 5 禁止性做法的上限。违反 Article 16 等一般经营者义务的上限为 1,500 万欧元或 3%；对中小企业，适用金额和比例中较低的上限。 这就是为什么不应把一项 Article 9 警告直接等同于“7% 罚款风险”。
根据韩国官方法令沿革，《人工智能基本法》已于 2026 年 1 月 22 日施行。 不过，不能凭欧盟扫描器的结果判断韩国国内法是否适用。国内分类和义务应依据单独的官方法令进行审查。
如果想进一步深入
Regulation (EU) 2024/1689 整合文本 查阅 Article 2·9·11·12·14·15·99 的现行措辞，可了解静态分析信号与系统义务之间的差异。 eur-lex.europa.eu
AI Act 官方政策指引 适合用于确认各项义务的适用时间及高风险系统时间表。 digital-strategy.ec.europa.eu
airblackbox/airblackbox 可用于确认当前安装命令和静态缺口分析局限的官方仓库。 github.com
AIR Blackbox v1.15.0 源码 可了解当前 CLI 如何处理静态·运行时检查、可选 Ollama 分析和本地历史保存。 raw.githubusercontent.com
