开源 AI 合规引擎 Opencomplai：决策路径零 LLM 依赖

开发者近期开源了面向 EU AI Act 的合规引擎 Opencomplai，其核心设计理念是：合规决策路径中不出现任何 LLM 调用，并由持续集成（CI）流程强制执行这一约束。

设计原则：合规判定必须可追溯

作者在文章中明确表示，决定不引入 LLM 处理合规判断，是出于工程上的考量而非营销口号。其逻辑是：如果一个工具用于判定某 AI 系统「是否可以合法上线」，那么最不应该充当这一判定者的，恰恰是另一个无法解释自身行为的模型。

按照 EU AI Act 的要求，监管机构或企业内部法务团队需要能够逐条追溯系统被归类为「高风险」的具体规则，而不是一个概率分布的输出。Opencomplai 把这一需求转化为硬性工程约束。

CI 强制：禁止静默引入 AI 依赖

为了让「零 LLM」不只是口号，Opencomplai 在 CI 流水线中加入了一道依赖扫描：

• 仓库内所有 pyproject.toml、package.json、requirements*.txt 文件会在每个合并请求（PR）时被扫描。
• 任何未经审批的 AI / LLM 相关包都会导致构建失败，无法合并。
• 测试、示例和 fixture 文件被加入白名单，避免演示用的 Notebook 触发误报。

也就是说，如果有开发者在风险判定引擎中擅自 import transformers，构建会在合并前直接中断。这种「制度化」的约束比口头声明更难以绕过。

可选 ML 插件：分类而非判定

Opencomplai 并非全盘拒绝机器学习。仓库中的 packages/ai 是一个可选插件，包含：

• 基于 ONNX / Transformers 的意图分类器，用于对自由文本形式的系统描述进行分类。
• 通过 [deep] 额外依赖，可以加载本地 GGUF 模型（依赖 llama-cpp-python）。

但该插件与合规决策严格隔离：

• 全部能力被沙箱化在独立包内。
• 它只做「这段文本在描述什么」的分类，不会判断 EU AI Act 第 5 条是否适用于当前系统。
• 「通过 / 不通过」的结果完全由确定性规则引擎产出，与 ML 插件无关。

作者立场：不是反 AI，而是反「不可解释的判定」

文章作者强调，自己并非 AI 反对者——上个月他运行过一个包含 200 多个智能体、累计时长超过 75 小时的工作流。他担心的是：当审计日志里写「由模型判定为合规」时，这并不是一条可用的审计线索，而是「多走几步的法律责任」。

对监管方或企业法务而言，能够把判定结果回溯到一条具体、可读的规则，比拿到一份概率分数更有价值。Opencomplai 试图用工程手段，把这种可追溯性固化到每一次构建之中。

仓库地址：github.com/Opencomplai/opencomplai，完整依赖清单与白名单理由见 docs/security/ai-inventory.md。