If you're shipping an AI feature and selling into the EU, compliance checks belong in the same place as your unit tests: your CI pipeline. Not in a spreadsheet, not in a quarterly review, in the pipeline that runs on every push. Here's how to get Opencomplai running in GitHub Actions.

Step 1: Install the package

Opencomplai is a free, open-source Python package. Add it to your project like any other dependency.

pip install opencomplai

It's AGPL-3.0 open source, so there's no procurement process to run through before you can try it in a branch. Pin the version in your requirements.txt or pyproject.toml the way you would any other tool that gates your build.

Step 2: Add a workflow step

Create a workflow file, or add a job to an existing one, that installs the package and runs its checks against your repository. A minimal version looks something like this:

# .github/workflows/compliance.yml
name: AI Compliance

on:
  pull_request:
  push:
    branches: [main]

jobs:
  compliance-check:
    runs-on: ubuntu-latest
    env:
      MODEL_NAME: hiring-system
      USE_CASE: recruitment screening of candidates
    steps:
      - uses: actions/checkout@v7

      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Opencomplai compliance check
        run: |
          pip install opencomplai
          opencomplai init \
            --system-id "${{ env.MODEL_NAME }}" \
            --intended-purpose "${{ env.USE_CASE }}"
          opencomplai check --scan-mode ci

The full set of CLI flags and config options is documented at docs.opencomplai.com/getting-started/installation. Treat the snippet above as a starting point, not gospel, and confirm the current command syntax there before you commit it.

Step 3: Read the output

When the check runs, you get a short report and an exit code, like a test runner. Here's a real run against a recruitment-screening system, which the EU AI Act treats as high-risk:

Opencomplai Compliance Check
  system_id:    hiring-system
  commit_ref:   HEAD
  result:       CONTROL_FAIL
  duration_ms:  0
  signed:       no (OSS unsigned)
  failed_controls: EU_AIA_ART6_HIGH_RISK, EU_AIA_ART6_PROFILING

  Artifact written to compliance-artifact.json

The command exits with code 1, which fails the job. It also writes compliance-artifact.json, the evidence record for that commit.

The value here isn't the pass/fail line, it's that the finding is timestamped and tied to a specific commit. That's the evidence trail an auditor or an enterprise security reviewer will eventually ask for, generated automatically instead of reconstructed from memory six months later.

Step 4: Interpret a failure correctly

A failing check usually means one of two things: a system's risk classification changed (a new use case pushed it toward Annex III), or a required control (audit logging, a human override path, a transparency notice) isn't wired up yet. Don't treat a failure as a legal verdict, treat it as a prompt to look closer. Read the flagged finding, decide whether the classification is right for your actual use case, and either fix the gap or note why it doesn't apply. For a broader walkthrough of what the Act actually requires engineers to build, see our guide to EU AI Act readiness.

Step 5: Make it run on every PR

The pull_request trigger in the workflow above is doing the real work. Running the check only on main means you find out about a compliance regression after it's already merged. Running it on every PR means a reviewer sees the result before they hit approve, the same way they'd see a failing test. If your team already treats a red CI check as a hard blocker for merging, this should slot into that same expectation with zero extra process.

Why this beats a manual review cycle

Manual compliance reviews happen in batches, usually right before a launch or a big customer's security questionnaire lands in your inbox. By then the system has changed a dozen times and nobody remembers which version was actually reviewed. Running the check in CI ties every commit to a compliance snapshot as it happens, which is the same shift-left logic we've written about for AI compliance in general. Set it up once, and the evidence collects itself.

Updated October 2026 (release 0.12.0): the GitHub Action has a strict input that adds --with-gaps --scan --fail-on major --require-exemption-record --sign-if-available. A flag you set through args, sign or with-gaps wins. Exit codes and CLI defaults are unchanged.