DEV Community: Haytham

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