I wanted to know: what does compliance actually look like in real codebases? Not in theory documents. Not in consultancy slide decks. In the code that developers are shipping right now.

So I ran Regula, an open-source static analysis tool for AI Act compliance, against 10 popular open-source AI projects. Combined, these projects have over 219,000 GitHub stars and represent the kinds of tools developers are building with today — coding agents, research assistants, chatbot platforms, LLM gateways.

The projects

Scan time for all 10 projects: under 3 seconds combined.

What Regula checks for

Regula scans source code for patterns that map to specific EU AI Act obligations, OWASP Top 10 for LLMs, and OWASP Agentic Security risks. It classifies findings into tiers: minimal risk (no obligations), limited risk (transparency required), high risk (full compliance regime), prohibited, and cross-cutting categories like agent autonomy and credential exposure.

It does not assess whether a system is high-risk — that depends on deployment context, not code alone. What it does is flag code-level patterns that become compliance-relevant if the system is deployed in a regulated context.

What I found

553 findings across 8,659 source files. The breakdown:

The dominant pattern: agent autonomy (56.6%)

More than half of all findings are agent autonomy patterns — AI output flowing directly to system command execution, file system modification, database queries, or HTTP requests. This is the defining characteristic of the current wave of AI tooling. Developers are building agents that act, not just chat.

Three projects account for most of these: ChatGPT-on-WeChat (127), gptme (84), and LiteLLM (34). The pattern is consistent: LLM output is passed to subprocess, os.system, file write operations, or HTTP clients without a human confirmation step in the code path.

Under the EU AI Act, this matters if the system is classified as high-risk (Article 14 requires human oversight mechanisms). Under OWASP Agentic Security, it maps to ASI02 (Tool Misuse) and ASI04 (Missing Guardrails) regardless of risk classification.

Some projects handle this well. Aider, for example, has human confirmation prompts before executing commands — Regula detected the gate pattern and adjusted its confidence score accordingly. Open Computer Use runs everything inside sandboxed VMs, which is a different form of containment that Regula doesn’t currently evaluate as a mitigating control (noted for future improvement).

Limited risk is straightforward (27.8%)

154 findings relate to chatbot interfaces and synthetic content generation. Under Article 50, these systems must disclose to users that they are interacting with AI or viewing AI-generated content. This is the easiest obligation to meet — a disclosure notice in the UI. Most of these projects already do this implicitly (the user knows they’re talking to an AI), but the Act requires explicit disclosure.

LiteLLM accounts for 130 of these — expected for a proxy that routes to 100+ LLM providers, many of which generate text presented to end users.

AI security: the unsexy but important one (7.4%)

41 findings for unsafe model deserialisation (pickle/joblib loading without integrity checks), unbounded token generation, and similar patterns. These map to OWASP LLM05 (insecure output handling) and LLM10 (unbounded consumption), and become compliance-relevant under Article 15’s cybersecurity requirements.

Local Deep Research had 20 of these — primarily related to model loading from external sources without hash verification.

High risk and prohibited: context-dependent (5.6% combined)

27 high-risk and 4 prohibited findings. These are patterns that could indicate use in high-risk contexts (employment decisions, biometric processing, critical infrastructure) or prohibited practices (social scoring, real-time biometric identification). Whether they actually trigger these classifications depends entirely on deployment context, not the code itself.

LiteLLM had 16 high-risk and all 4 prohibited findings. As a universal LLM proxy, it can be used in virtually any context — so these findings reflect the breadth of its potential deployment, not inherent risk in the code.

What this means for developers building with AI

Most AI code carries no specific regulatory risk. 553 findings across 8,659 source files, concentrated in a small number of files. The majority of source files in these projects had no compliance-relevant patterns at all. The EU AI Act’s minimal-risk category — which carries zero mandatory obligations — covers the vast majority of AI code.

Agent autonomy is the pattern to watch. If you’re building agents that execute actions based on LLM output, you should be thinking about human oversight mechanisms now. Not because of regulatory panic — because it’s good engineering. An agent that can execute arbitrary system commands based on LLM output is a security risk regardless of what the EU AI Act says.

Transparency obligations are easy to meet. If your application presents AI-generated content to users or operates as a chatbot, Article 50 requires disclosure. This is a UI change, not an architecture change.

The Omnibus may simplify things further. The European Commission’s February 2026 simplification proposal would narrow the scope of high-risk classification and raise SME exemption thresholds. As of writing, it’s a proposal under legislative review — not enacted. The original August 2026 timeline remains the legal baseline.

How to run this yourself

pip install regula-ai
regula check /path/to/your/project

Regula is open-source, has zero dependencies, and runs entirely locally. No data leaves your machine. It takes under a second for most projects.

The risk patterns it checks against (389 as of v1.7.0; 330 at the time this scan was run with v1.6.1) are documented in the repository. If you disagree with a classification, you can suppress individual findings with inline comments or contribute pattern improvements upstream.