I scanned 10 open-source AI apps for EU AI Act compliance. Here’s what I found.

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

The 10 projects span coding agents, research assistants, chatbot platforms, and LLM gateways, collectively representing 219,000 GitHub stars and 8,659 source files. They were chosen because they reflect what developers are actually building and deploying with AI today, not theoretical use cases.

Runtime varies with repository size, language mix, command options, and environment.

What Regula checks for

Regula scans source code for patterns associated with EU AI Act provisions, OWASP Top 10 for LLMs, and OWASP Agentic Security risks. It reports candidate tiers and cross-cutting categories such as agent autonomy and credential exposure. These are code-level indicators for human review, not legal classifications or proof that every applicable duty was detected.

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

Regula flagged 553 findings across 8,659 source files. Agent autonomy dominated at 56.6% of findings, followed by limited-risk transparency patterns (27.8%), AI security issues (7.4%), high-risk indicators (4.9%), credential exposure (2.5%), and prohibited-practice patterns (0.7%). Most source files had no findings. Checked-in scan results.

The checked-in April 2026 benchmark records 553 findings across 8,659 source files; see the archived source data and reproducibility qualifications. The breakdown reported by the original run was:

Source data for this table.

The dominant pattern: agent autonomy

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) 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).

Transparency-related patterns need context

154 findings relate to chatbot interfaces and synthetic content generation. They identify candidates for an Article 50 review; they do not establish that a duty applies. Article 50 contains different duties, roles, conditions and exceptions, so a disclosure or machine-readable mark must be designed for the applicable paragraph and context.

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: an important review surface

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-practice signals are context-dependent

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 files in this sample had no matched elevated-risk pattern. The archived April 2026 benchmark reported 553 findings across 8,659 source files, concentrated in a small number of files. That file-level observation does not establish that a project is minimal risk, outside the Act, or free of mandatory duties; those questions depend on the system, actor, intended purpose, and deployment context.

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 needs a scoped review. A chatbot or synthetic-content match can prompt review under Article 50, but does not by itself establish the applicable paragraph or required measure. Some duties involve user-facing disclosure; others include machine-readable marking or deployer obligations.

The Omnibus is now enacted. Regulation (EU) 2026/1744 entered into force on 27 July 2026. It changes more than dates and sets 2 December 2027 for the Annex III path and 2 August 2028 for the Annex I product-embedded path; the full amended provisions and transition rules still need to be applied to the facts.

How to run this yourself

Install Regula with pip and point it at a project directory to obtain a pattern-based risk scan. Regula is open-source, has zero core dependencies, and its local scan engine does not upload project files. Results include file paths, line numbers, and EU AI Act article references for matched findings; runtime varies with project size and hardware.

pip install git+https://github.com/kuzivaai/getregula.git@main
regula check /path/to/your/project

Regula is open-source, has zero core dependencies, and processes scan inputs locally without uploading project files. Runtime varies with project size and hardware.

The historical scan used the pattern set recorded with the archived benchmark. Pattern findings should be reviewed against code and deployment context; suspected false positives can be reported upstream with reproducible evidence.