DEV Community: Haytham

The EU AI Act scanner that cannot break your build, by design

Haytham — Wed, 14 Oct 2026 09:55:39 +0000

Every compliance tool I looked at before building my own wanted a commitment up front. Fill out a manifest. Define a system boundary. Integrate before you get any signal at all.

That's a lot to ask before you know whether the tool is even useful, and it is exactly why so many GRC rollouts stall at "next sprint."

opencomplai scan --quick skips all of it. Point it at a directory. No manifest, no config, no system-id.

It's discovery-only. It looks at what is actually in your codebase, imports, dependencies, patterns that map to Annex III categories or Article 5 prohibitions, and reports what it finds.

It cannot fail your build, because it isn't wired to any gate. There is no flag to make it block anything. That's not a lenient default someone forgot to tighten. It's architecturally separate from opencomplai check, the command that gates on a real manifest.

The reasoning is simple. The biggest barrier to compliance tooling was never the compliance logic. It's the activation energy of finding out whether you even have a problem. A scan that can't say no to running, and can't break CI on day one, removes most of the excuse not to try. I wanted the first run to be boring.

It takes about as long as reading this paragraph. You can check what categories it matches against before you run it on your own repo. The detection rules are in packages/core: github.com/Opencomplai/opencomplai.

Why a compliance tool needs its own egress allowlist

Haytham — Fri, 09 Oct 2026 07:45:29 +0000

I didn't expect the hardest security decision in a compliance engine to be about outbound network calls. It was.

Opencomplai's services occasionally need controlled external connectivity. Fetching a model card. Hitting a registry. Whatever a given integration requires.

The obvious options are two. Let every service make arbitrary outbound requests, which is bad for anything touching legal evidence. Or block everything and special-case exceptions inline in each service, which is a maintenance problem that grows with every integration.

I picked a third. egress-proxy is a dedicated service whose entire job is enforcing an allowlist for outbound connections from the rest of the stack. Nothing else talks to the outside world directly.

One choke point. One place to audit. One place to update when a new integration needs a new destination.

I'm the person who gets called when things break, sometimes at 1am. At that hour I want one place to look, not five.

For a normal web app this is overkill. For something that is supposed to produce evidence you can hand a regulator, "we can enumerate every external system this ever talked to" isn't a nice-to-have. It's part of the compliance story itself. You can't claim your evidence pipeline is trustworthy if you can't account for what it was allowed to phone home to.

It's a small service, and that is the point. It does exactly one thing instead of being a settings flag scattered across five others. Allowlist config and enforcement logic are both in the repo: github.com/Opencomplai/opencomplai, under services/egress-proxy.

I modeled EU AI Act compliance as a state machine, not a checkbox list

Haytham — Mon, 05 Oct 2026 20:55:30 +0000

Every EU AI Act control I track moves through the same five states. None of them is "done": satisfied, evidence_missing, evidence_stale, pending_review, waived.

The third one is the state most compliance tooling skips. A control isn't just satisfied or not. The evidence behind it can expire.

Opencomplai's control register attaches a freshness TTL to every piece of evidence backing a control. So a bias-testing result from eight months ago, against a model you have since retrained three times, doesn't silently keep counting as satisfied. It ages into evidence_stale and shows up in opencomplai controls status as something that needs a fresh run, not something to rediscover at next year's audit.

It's cache invalidation, applied to legal evidence instead of application data. The hard part was never storing the value. It was knowing when the value you stored stopped being true.

Each control maps to one specific article of the Act, has an owner, and moves through those five states on every CI run. "Are we still compliant" becomes a query against current state, not an annual archaeology project through old spreadsheets.

waived exists on purpose. Sometimes a control genuinely doesn't apply to a system, and pretending otherwise is its own kind of lying.

The full lifecycle, what triggers each transition and what "stale" means for different evidence types, is documented next to the code, not in a whitepaper: github.com/Opencomplai/opencomplai, see the Controls Lifecycle doc and services/evidence-vault.

An immutable ledger for legal evidence, and a tool whose only job is proving it wasn't touched

Haytham — Fri, 02 Oct 2026 12:01:23 +0000

I built a tool to prove my own evidence store wasn't altered.

Compliance evidence has a trust problem that nobody asks about until the wrong day. The question is simple: how do we know this audit log wasn't edited after the fact?

Opencomplai's evidence-vault service stores every piece of compliance evidence, scan results, eval reports, sign-offs, as content-addressed immutable artifacts. An entry's address is a hash of its content. Change the content later and you get a different address, not a changed record. Same idea Git uses for objects, applied to legal evidence instead of source code.

An immutable store is only as trustworthy as your ability to prove it is behaving like one. That's what tools/verify-ledger is for. A standalone verifier. It walks the evidence chain and confirms nothing was tampered with, and it doesn't depend on the service that wrote it.

You don't have to take my API's word for it. Run the verifier yourself against the raw ledger.

This matters because most "audit trail" features in GRC products are an admin-editable table with a timestamp column. I've been on the security side of enough incidents to know what a timestamp is worth when someone with database access wants to reclassify a system after the fact. Nothing. A content-addressed chain with an independent verifier is worth something.

If you're building anything where "prove this record hasn't been altered" is a real requirement, compliance or not, read how the chain and verifier are structured: github.com/Opencomplai/opencomplai, under services/evidence-vault and tools/verify-ledger.

I made my compliance tool fail the build rather than lie in the audit report

Haytham — Wed, 30 Sep 2026 07:24:46 +0000

I built my compliance tool to fail the build, and I did it on purpose. Most audit-evidence tooling has one job: make the report look complete. Mine does the opposite.

Opencomplai's Annex IV dossier generator (opencomplai docs generate) builds the package you would hand an auditor. System description. Risk classification. Evidence attachments.

Every field in that dossier comes from exactly one of three places: something automated from your manifest and risk classification, real evidence wired in from an actual scan or eval report, or an explicit placeholder that says a human hasn't provided this yet.

There is no fourth place. The generator never fills a gap with boilerplate so the PDF looks finished.

Here's the part that costs me adoption. If your system is classified HIGH-risk and the dossier still has a placeholder in a required field, the release gate fails.

Not flags. Fails. The tool that is supposed to prove you are compliant will block your deploy rather than hand you a complete-looking dossier that isn't.

I know what that does to my numbers. A tool that gates your release on missing evidence is a harder sell than one that always prints a green checkmark. It's not a great pitch. I decided I could live with that.

I spent fourteen years watching systems fail. The ones that failed worst were the ones whose reports said everything was fine. A compliance report that can't tell "we checked" from "we didn't get around to it" isn't worth generating.

If you've used GRC tooling that treats "the field has text in it" as "the control is satisfied", compare it against how this release gate actually reads dossier state before it decides pass or fail. It isn't behind a paywall, it's in services/doc-generator: github.com/Opencomplai/opencomplai.

No LLM is allowed near my compliance decisions, and CI enforces it

Haytham — Thu, 24 Sep 2026 13:53:00 +0000

I decided no LLM would go near my compliance decisions.

If a tool decides whether your AI system is legal to ship, the last thing I want deciding that is another model nobody can explain.

Opencomplai's rule engine (packages/core) and CLI are fully deterministic. No LLM. No ML inference. Not anywhere in the compliance decision path.

That's a design constraint, not a line for the landing page, and I don't just assert it. CI enforces it. Every pyproject.toml, package.json and requirements*.txt in the repo is scanned for unapproved AI/LLM packages on every PR, with excludes for tests, examples and fixtures so a demo notebook doesn't fail the build.

Add a transformers import to the risk engine without going through approval and the build breaks before it merges.

There is an ML path. packages/ai is an optional plugin with an ONNX/transformers intent classifier, plus an even more optional [deep] extra for local GGUF models via llama-cpp-python. It's opt-in, sandboxed to its own package, and it never touches the pass/fail decision. It classifies free-text system descriptions. It doesn't decide whether Article 5 applies to you.

I use AI every day. Last month I ran a workflow with more than 200 agents for more than 75 hours. So this isn't fear of the tool.

What I'm afraid of is an audit trail that says "the model decided this was compliant." That's not an audit trail. That's a liability with extra steps.

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 scanner and the full inventory are in the repo if you want to see exactly what is allow-listed and why: github.com/Opencomplai/opencomplai, docs/security/ai-inventory.md.

What actually broke when I open-sourced my own compliance engine

Haytham — Mon, 21 Sep 2026 17:39:44 +0000

I assumed projecting my private monorepo down to a public repo was a solved problem. It wasn't, and the failures were more interesting than the feature I was shipping that week.

OpenComplAI's Enterprise and Community editions live in related codebases. Every release means projecting the enterprise repo down into the public one. Strip internal packages, regenerate lockfiles, publish clean.

First. Stripping a private directory out of the public projection doesn't strip it from pnpm-lock.yaml or the workspace manifest. The lockfile still listed the private package by name, full dependency graph included, in a repo that was supposed to contain none of it. Deleting a folder isn't the same as regenerating everything that referenced it.

Second. My assemble.sh script, built to prune the enterprise-only bits, was aggressive enough to delete the public repo's own .github/ directory on a re-run. CI workflows and issue templates went with it. A prune script that can't tell "generated cruft" from "the thing that makes this repo work" will eventually delete something you needed.

I also shipped a package-lock.json that leaked the enterprise package's internal name before review caught it, and ended up with orphaned badge SVGs pointing at workflows that no longer existed after the prune.

None of these are exotic. They are what happens when "copy files, remove the private parts" is treated as a file-deletion problem instead of a full re-projection-and-verify one. Prune and regenerate, then gate on a verification pass. Not the other way around.

That's the lesson, and it took me too long to see: the script that builds something can't be the one that certifies it.

I added that verification pass after this round. sync/doctor.py and verify-sbom.sh check the projected repo's actual state. Both are in the repo if you want to see what I now consider the minimum for this kind of pipeline: github.com/opencomplai/opencomplai, under sync/.

Your hiring AI is either high-risk, or already illegal!

Haytham — Tue, 15 Sep 2026 17:41:38 +0000

If your recruitment AI scores a candidate's "enthusiasm" from their interview video, that's not a 2027 compliance problem. It's already illegal, and has been since February 2025.

Most HR tech content lumps every AI hiring feature into one "get ready for the EU AI Act" bucket. In reality, there are two very different buckets, with two very different deadlines:

HIGH-RISK (Annex III(4)(a)) — Full obligations enforceable 2 December 2027

CV and resume screening that ranks or filters applicants
Video-interview platforms that score responses or delivery
Psychometric and skills assessments feeding a hiring decision
Sourcing and matching algorithms deciding who a recruiter even sees
Programmatic job-ad targeting that decides who sees a role at all

Required: documented risk assessment, technical documentation, bias testing, human oversight, disclosure to candidates, and an audit trail. Fines for failing these run up to €15M or 3% of global turnover.

PROHIBITED (Article 5) — Came into force since 2 February 2025

Inferring a candidate's emotions from facial expression, voice tone, or body language (Article 5(1)(f)) — the EU AI Office's guidance explicitly extends "workplace" to the recruitment and interview stage
Inferring personality traits from social media or non-work behaviour to filter candidates (Article 5(1)(c))

There's no phase-in, no grace period, no documentation that makes this compliant. Fines run up to €35M or 7% of global turnover. So if your ATS or interview platform has a "culture fit" or "engagement" score built on facial or voice analysis, it needs to come out, not get documented.

Here's the part that actually matters for engineering teams building HR Tech: the difference between these two buckets often comes down to a single feature flag or a single import. The exact same candidate scoring codebase can be high-risk today and prohibited tomorrow, depending on what a new PR adds — and that's not something a compliance team reviewing quarterly is going to catch in time.

That's the gap we built OpenComplAI to close: EU AI Act checks that run in your CI, on every commit, not a policy review that happens after the feature has already shipped. The same detection model that flags an unrecognised biometric import in a codebase applies the same way to an emotion-inference library landing in a candidate-scoring pipeline — caught before merge, not discovered at audit time.

If you're building or buying AI hiring tools, it's worth an afternoon auditing your stack against these two lists specifically, not just "are we EU AI Act ready" in the abstract.

OpenComplAI is free and open source, and still early enough that feedback from people actually working in HR tech shapes what we build next.

Repo: https://github.com/opencomplai/opencomplai

Treating EU AI Act Compliance as Code: A CI/CD Approach

Haytham — Fri, 14 Aug 2026 09:38:26 +0000

The EU AI Act's transparency obligations (Article 50) became enforceable on August 2, 2026. If you're shipping AI features into the EU, that's not a future date to plan around anymore, it's now.

Most teams still handle this the way we handled security compliance in 2015: a spreadsheet, a legal review, and a PDF nobody opens again until the next audit. That doesn't scale, and it doesn't fit how software actually gets built and shipped continuously.

What if compliance was a build step, not a document?

That's the idea behind OpenComplAI, an open-source project I've been building: EU AI Act risk classification and compliance checks that run in your pipeline, the same way you'd run a security scanner or a linter.

How it works

The core is a deterministic, rule-based risk engine, no ML inference involved in the compliance decision itself (the dependency list is scanned in CI specifically to enforce that). It's Python underneath (Pydantic v2 for the data models, Typer/Rich for the CLI), with a small set of services behind it:

a Gateway API (Node/TypeScript) for request routing
a Risk Engine that runs the classification logic
an Evidence Vault for immutable, content-addressed audit trails
a Doc Generator that produces Annex IV-format compliance dossiers

Quickstart

pip install opencomplai
opencomplai init --system-id my-model --intended-purpose "customer support chatbot"
opencomplai check

There's also a zero-setup discovery mode that never fails your build, useful for figuring out where you stand before you gate anything:

opencomplai scan --quick .

And a pre-commit hook if you want the check earlier than CI:

- repo: https://github.com/opencomplai/opencomplai
  rev: v0.1.2
  hooks:
    - id: opencomplai-quick-scan

What it actually checks

The interactive checker (opencomplai checker --web, or --local for a fully offline version) walks through whether the Act applies to your system at all, and if so, whether you're a provider or a deployer, since the obligations differ substantially. From there it handles risk-tier classification (including general-purpose AI model considerations) and generates the evidence trail you'd actually need to hand to an auditor.

Where it stands

It's early. Community edition is AGPL-3.0; there's a commercial tier in the works for teams that want a hosted dashboard, SSO, and additional rule engines, but the core compliance engine is fully open.

I'd genuinely value feedback from anyone who has done EU AI Act conformity work manually: what parts of that process actually generalize into rules, and what still needs a human in the loop? Issues, PRs, and just general "here's what we ran into" reports are all welcome.

Repo: https://github.com/opencomplai/opencomplai