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 MIT licensed, 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
    steps:
      - uses: actions/checkout@v4

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

      - name: Install OpenComplAI
        run: pip install opencomplai

      - name: Run compliance checks
        run: opencomplai check

The exact CLI flags and config options (scoping which frameworks to check, ignoring specific paths, setting severity thresholds) are 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 should get a report similar in spirit to a linter or a test runner: which systems it found, what it classified them as, and what's missing. Something like:

OpenComplAI: scanned 3 AI-integrated services
  ✓ recommendation-engine: minimal risk, transparency notice present
  ✗ resume-screener: likely high-risk (Annex III, employment), missing human oversight logging
  ✓ chat-widget: limited risk, disclosure requirement met

1 issue found. See report for remediation guidance.

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.