Why I Banned LLMs From My Compliance Engine

Overview

The growing integration of artificial intelligence into critical infrastructure has sparked intense debate regarding accountability and regulatory compliance. In a recent engineering statement, the team behind the open-source project Opencomplai announced a hard technical constraint: no large language models (LLMs) are permitted within their core compliance decision engine.

This policy is not merely a design preference but is actively enforced through continuous integration (CI) pipelines. By scanning dependency files for unapproved AI packages, the project ensures that legal determinations remain traceable, deterministic, and free from the opacity often associated with neural network inference.

The Deterministic Core

The central premise of the Opencomplai engine is that compliance decisions—determinations of whether an AI system is legal to ship—must be grounded in explicit, readable rules rather than probabilistic outputs. If a tool is responsible for assessing regulatory adherence, the final decision cannot rest on another model whose reasoning process is difficult to explain or audit.

To achieve this, the core rule engine, located in the packages/core directory, and its associated command-line interface are fully deterministic. There is no machine learning inference or LLM interaction anywhere in the path that leads to a pass or fail verdict. This architectural choice eliminates the risk of "black box" liability, where a regulator might demand an explanation for a decision that was derived from hidden weights and probabilities rather than codified logic.

A regulator, or your own legal team, needs to trace why a system got classified high-risk down to a specific readable rule, not a probability distribution.

The author emphasizes that this approach addresses a fundamental gap in current AI governance frameworks. An audit trail that simply states "the model decided this was compliant" is legally insufficient. It represents a liability with extra steps rather than a verifiable record of due diligence.

CI-Enforced Compliance

Translating this philosophy into practice required more than code comments; it demanded infrastructure-level enforcement. The project employs a rigorous CI strategy that scans every pyproject.toml, package.json, and requirements*.txt file in the repository on every pull request.

The scan specifically looks for unapproved AI and LLM-related packages. If a developer attempts to add a library such as transformers to the risk engine without going through a formal approval process, the build fails before the code can merge. This creates a technical barrier against accidental or intentional drift from the deterministic standard.

However, the restrictions are nuanced. The exclusion list is carefully configured to allow tests, examples, and fixtures to proceed without breaking the build. This ensures that a demonstration notebook containing AI references does not inadvertently halt legitimate software development workflows.

The result is a system where the integrity of the compliance engine is protected by the same mechanisms that secure modern software supply chains. It shifts the burden of proof from human review to automated verification.

The Optional AI Plugin

While the core engine remains strictly non-AI, the project does not entirely reject the utility of artificial intelligence in adjacent tasks. The packages/ai module exists as an optional plugin, strictly separated from the compliance decision path.

This plugin includes an intent classifier built on ONNX and transformers, which can analyze free-text system descriptions. Additionally, an even more optional [deep] extra provides support for local GGUF models via llama-cpp-python.

Crucially, this AI capability is sandboxed. It is opt-in and never touches the pass/fail logic. Its function is limited to classification and description, never judgment. This separation allows developers to leverage AI for convenience and analysis while maintaining a clear boundary between informational assistance and regulatory determinations.

The author notes that this distinction is vital. They personally use AI extensively, citing a recent workflow involving more than 200 agents running for over 75 hours. Therefore, the restriction is not born out of a general fear of the technology, but out of a specific concern for auditability in high-stakes contexts.

Industry Implications

The Opencomplai approach reflects a broader tension in the AI industry between the flexibility of generative models and the rigidity required by law. As regulations such as the EU AI Act come into effect, organizations are under increasing pressure to demonstrate how their systems make decisions.

Current practices that rely on opaque LLMs for compliance checks face significant scrutiny. Auditors cannot verify the reasoning of a neural network in the same way they can review a line of business logic. The Opencomplai model offers a template for how engineering teams can maintain velocity with AI tools while preserving the explainability demanded by regulators.

For teams considering similar architectures, the project provides its scanner and full inventory for inspection. The repository and the security documentation detail exactly what is allow-listed and why, offering a transparent look at the trade-offs involved in building deterministic compliance systems.

As the legal landscape for AI matures, the insistence on traceable, rule-based decisions over probabilistic outputs may become a standard rather than a niche engineering choice. The Opencomplai experience suggests that with the right CI safeguards, it is possible to harness AI without sacrificing accountability.