# We scanned public AI repos for EU AI Act compliance. Nearly every one failed. > Source: > Published: 2026-08-27 20:10:33+00:00 We scanned public AI repos against the EU AI Act's requirements. Nearly every one failed at least one requirement. The code wasn't bad. Developers already know how to write structured logging, input validation, and human-oversight checkpoints. Nobody told them these are now legal requirements for high-risk AI systems shipped into the EU. The EU AI Act's high-risk obligations are in force now. The deadline that mattered, Aug 2, 2026, already passed. If your AI system falls under Annex III, you need a risk classification and a technical documentation file: Annex IV, 9 sections, mapping what your system actually does to what the regulation requires. Annex III covers more ground than most teams expect, including credit scoring, CV screening and hiring tools, biometric categorization, insurance underwriting, and exam scoring. Most engineering teams don't know if they're in scope. Fewer have the documentation. A team starting from zero needs 3-6 months to produce that documentation package by hand, before anyone's even checked whether the underlying system does what the docs claim. The failures we're seeing aren't random. Articles 9 (Risk Management), 12 (Record-Keeping), and 14 (Human Oversight) fail most often. Article 11 (Technical Documentation) has a high pass rate, because developers already write docstrings and type hints, and that habit happens to satisfy most of what Article 11 asks for. Where good engineering practice already overlaps with the legal requirement, teams pass. Where that connection hasn't been made yet, they fail. It's an awareness gap, not a carelessness one. If your company runs a GRC platform (OneTrust, Vanta, Credo AI), you might assume this is already covered. It isn't. Those tools read cloud config, identity systems, and questionnaire answers. They don't read your code. Say the risk in your AI system lives in application logic: a scoring function, a ranking model, an inference call that feeds a hiring or lending decision. A cloud-config scan can't see any of that. The evidence the EU AI Act actually asks for, what the system does, what oversight exists, what happens when it's wrong, lives in the code and the documentation next to it. Not in an IAM policy. None of this means you should rip out your GRC platform. Evidence from code and attestations from a questionnaire are different kinds of proof, and most teams only have the second kind. Compliance content usually stays abstract. Here's something concrete instead: one real detection pattern, simplified for this post but built on real Semgrep rule syntax. Article 14 requires that high-risk AI systems be designed so a human can effectively oversee their operation. That includes the ability to intervene or override an output before it gets acted on. Here's a simplified version of the kind of rule that checks for it: ``` rules: - id: eu-ai-act-example.article-14-missing-human-oversight-hook languages: [python] severity: WARNING message: > High-risk AI inference call has no human-oversight hook (approval, override, or review checkpoint) nearby. EU AI Act Article 14 requires human oversight measures for high-risk AI systems before their output is acted on. metadata: article: "14" category: human-oversight patterns: - pattern-either: - pattern: $RESULT = $MODEL.predict(...) - pattern: $RESULT = $CLIENT.chat.completions.create(...) - pattern-not-inside: | if $APPROVED: ... - pattern-not-inside: | $RESULT = require_human_approval(...) ``` The rule looks for a high-risk inference call, a model prediction or an LLM completion, whose result flows straight into downstream logic with no oversight checkpoint anywhere nearby. No conditional gate. No approval or override call in scope. The code works fine. There's just nothing in it that gives a human the chance to catch a bad output before it gets acted on. Flip it around and the passing version of the same code just adds one checkpoint: ``` result = model.predict(applicant_data) if require_human_approval(result): finalize_decision(result) ``` Same model, same prediction. One line of difference, and that line is exactly what Article 14 is asking for. This is a simplified example, not the literal production rule. The real ruleset covers more languages, more oversight-hook idioms, and confidence handling not shown here. It's still real Semgrep syntax, checking for a real pattern, mapped to a specific article and paragraph. Every finding traces back to something specific in the regulation, not a vague "AI governance" checkbox. One pattern kept showing up in other compliance tooling we looked at: middleware that silently lets a request through when a check times out or errors. That's worse than having no check at all. It produces an audit trail that says "compliant" when nobody actually verified anything. Scanara's merge gate is fail-closed by design. If the check can't run, the PR gets blocked. It doesn't get silently waved through. A compliance check that quietly allows on failure isn't really a check. It's a false audit trail, and that's worse than an honest gap. Free tier, self-serve. Connect a repo and see what it actually finds. No sales call, no questionnaire: [https://scanara.io/en/?utm_source=devto&utm_medium=launch&utm_campaign=post-launch-2026-08](https://scanara.io/en/?utm_source=devto&utm_medium=launch&utm_campaign=post-launch-2026-08) Genuinely interested in pushback here. What's the real false-positive rate on pattern-based detection like this at scale, once you're past the illustrative example above? Does automated evidence like this actually hold up to an auditor, or is it still compliance theater dressed up in YAML? And with enforcement authorities still being designated in most EU member states, how much of this is really "required now" versus "required eventually, once someone's actually checking"? I'd rather hear the hard questions in the comments than pretend there aren't any.