top of page
kordic-logo
Contact

How to Code EU AI Act Risk Compliance Directly Into Your Pipeline

  • Writer: Jessica Piikkila
    Jessica Piikkila
  • Jun 10
  • 6 min read

  • Date: June 10, 2026

  • Author: Jessica Piikkila and Agentic Risk Agent

Executive Summary

If you deploy or import AI systems in the European Union, compliance isn't a future problem on a slide deck. It is an active enforcement headache. If you mess up, the fines are brutal and can cost up to €35 million or 7% of your global annual turnover. Let me help you image this better, in practice it means whichever cost is the most devastating for the company is what the fines will cost them.


Your legal department communicates these terms in contracts and AI company guidelines that everyone in the company has to sign off on that they read the policy. But people held responsible for catching violations and screw ups are the brave soldiers that are responsible for writing the code and monitoring the systems.


This guide is for the engineers actually holding the pagers.

Below is the concrete blueprint to register your AI assets, write Policy-as-Code rules, write real-time checks inside your model pipelines, and run telemetry to keep regulators off your back.

Technical & Operational Architecture

Operational compliance requires a central AI Registry linked to your continuous integration deployment (CI/CD) pipelines and production environments. This architecture uses Open Policy Agent (OPA) alongside model telemetry frameworks to dynamically catalog, assert, and review models.

+───────────────────────+        Metadata Payload       +─────────────────────────+
│ AI System Development │ ────────────────────────────> │  CI/CD Automated Gate   │
+───────────────────────+                               +─────────────────────────+
                                                                     │ Validates Class
                                                                     ▼
+───────────────────────+        Drift & Bias Logs      +─────────────────────────+
│ Post-Market Telemetry │ <──────────────────────────── │   Central AI Registry   │
+───────────────────────+                               +─────────────────────────+
            │                                                        │ Verification Log
            ▼                                                        ▼
+───────────────────────+                               +─────────────────────────+
│ Compliance Dashboards │ <──────────────────────────── │    OPA Policy Engine    │
+───────────────────────+                               +─────────────────────────+

Prerequisites

Before running this implementation:

  1. Model Registry: Access to a central hub (e.g., MLflow, Hugging Face, or a raw application catalog).

  2. Infrastructure: A GitOps engine (GitHub Actions or GitLab CI) with the Open Policy Agent (OPA) CLI installed on your runner images.

  3. Cross-Functional RACI: A clear understanding of who owns legal accountability, who handles ML pipelining, and who acts as the operational compliance authority when errors flag.

Operationalization Steps


Step 1: Establish the AI Asset Metadata Schema

To assess risk automatically, each AI model or service must state its functional footprint, training profile, and deployment context using a standardized system metadata file (ai-manifest.json).

Save this template inside your global model repository folder:

{
  "$schema": "https://governance.internal.net/schemas/ai-manifest-v1.json",
  "system_id": "SYS-8842-FRAUD-DETECTION",
  "system_name": "CreditRiskScoreModel",
  "version": "2.4.1-rc1",
  "intended_purpose": "Profiling of natural persons for creditworthiness and scoring.",
  "risk_classification_override": null,
  "data_categories": [
    "biographic",
    "financial_history",
    "transaction_patterns"
  ],
  "human_oversight_mechanism": "Manual reviewer validation for high-variance decisions",
  "dependencies": {
    "base_model": "Llama-3-8B-Instruct-v1",
    "fine_tuning_datasets": ["s3://ml-data-lake/audit/credit_bias_mitigated_v2.parquet"]
  }
}

Step 2: Implement Policy-As-Code (OPA) for AI Risk Classification

Deploy Rego policy files within the automated build pipeline. This step checks the system's intended_purpose and target datasets against categorizations designated as High-Risk or Unacceptable (Prohibited) under Annex III of the EU AI Act.

Save this policy file as risk_classifier.rego:

package ai_governance

default allow = false
default is_high_risk = false
default is_prohibited = false

# Rule 1: Determine Prohibited Class (Biometric categorization, social scoring)
is_prohibited {
    input.intended_purpose == "Real-time remote biometric identification in public spaces"
}

is_prohibited {
    input.intended_purpose == "Social scoring or trust-worth calculation by public authorities"
}

# Rule 2: Determine High-Risk Class (Credit scoring, employment, law enforcement)
is_high_risk {
    input.intended_purpose == "Profiling of natural persons for creditworthiness and scoring."
}

is_high_risk {
    contains(lower(input.intended_purpose), "employment")
}

# Rule 3: Evaluation logic block
allow {
    not is_prohibited
}

Step 3: Inject Classification Gates into the GitOps Pipeline

We do not allow code changes to slip past checks on a developer's machine.

To prevent human error, map the policy verification step directly into your automated workspace environment. Update your central repository CI actions to evaluate every single commit against the OPA rules.


In write paths or pull-request paths, create .github/workflows/compliance-verification.yml:

name: EU AI Act Risk & Compliance Gate

on:
  push:
    branches: [ main, release/* ]
  pull_request:
    branches: [ main ]

jobs:
  validate-governance:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

      - name: Setup Open Policy Agent (OPA)
        uses: open-policy-agent/setup-opa@v2
        with:
          version: 'latest'

      - name: Run Risk Classification Audit
        run: |
          opa eval --data risk_classifier.rego --input ai-manifest.json "data.ai_governance" > evaluation_result.json
          cat evaluation_result.json
          
      - name: Block on Prohibited Classification
        run: |
          PROHIBITED=$(jq '.. | .is_prohibited? // empty' evaluation_result.json)
          if [ "$PROHIBITED" = "true" ]; then
            echo "ERROR: Deployment blocked. Asset is categorised under PROHIBITED AI Practices."
            exit 1
          fi

      - name: Assert High-Risk Checklist Output
        run: |
          HIGH_RISK=$(jq '.. | .is_high_risk? // empty' evaluation_result.json)
          if [ "$HIGH_RISK" = "true" ]; then
            echo "SUCCESS: Classification determined: HIGH-RISK. System demands audit trail generation ..."
            echo "HIGH_RISK_COMPLIANCE_REQUIRED=true" >> $GITHUB_ENV
          fi

Step 4: Execute Bias and Robustness Testing Targets

High-risk systems require clean operations and verifiable training history (Article 10) to combat systemic bias. Run tests using a fairness evaluation engine during the compilation pipeline step.

# test_compliance_bias.py
import pandas as pd
from sklearn.metrics import selection_rate # Example metric

def test_demographic_parity():
    # Load synthetic verification baseline
    test_data = pd.read_parquet("s3://ml-data-lake/audit/verification_set.parquet")
    predictions = load_model_and_predict(test_data)
    
    # Calculate Disparate Impact Ratio
    privileged_selection = selection_rate(test_data['actual_outcome'], predictions, pos_label=1, sensitive_features=test_data['gender'] == 'male')
    unprivileged_selection = selection_rate(test_data['actual_outcome'], predictions, pos_label=1, sensitive_features=test_data['gender'] == 'female')
    
    disparate_impact = unprivileged_selection / privileged_selection
    
    # Strict regulatory guardrail (0.80 - 1.25 metric boundary)
    print(f"Computed Disparate Impact Metric score: {disparate_impact}")
    assert 0.80 <= disparate_impact <= 1.25, f"Bias metric violation under EU AI Act expectations: {disparate_impact}"

Step 5: Establish the Conformity Evidence Registry

When your test run validates successfully, bundle your compliance runs into an encrypted, read-only file repository.

This is what you hand over when the auditors show up with questions.

# Compile and lock the conformity folder
export BUILD_ID="run-sys-8842-rev24"
mkdir -p compliance_archive/$BUILD_ID

mv evaluation_result.json compliance_archive/$BUILD_ID/
mv test_results.xml compliance_archive/$BUILD_ID/
cp ai-manifest.json compliance_archive/$BUILD_ID/

tar -czf ${BUILD_ID}_evidence.tar.gz compliance_archive/$BUILD_ID
gpg --recipient governance@kordic.ai --encrypt ${BUILD_ID}_evidence.tar.gz

Step 6: Post-Market Monitoring System Integration (Telemetry)

Compliance is not a point-in-time snapshot. Dynamic real-time production telemetry must actively flag user overrides, performance shifts, and data drift (Article 61).

Structure your backend telemetry loops to publish events automatically to operational databases:

{
  "timestamp": "2026-06-10T16:39:16Z",
  "system_id": "SYS-8842-FRAUD-DETECTION",
  "runtime_transaction_id": "tx-9923408-cf",
  "data_drift_detected": false,
  "concept_drift_score": 0.041,
  "human_override_triggered": true,
  "override_reason_code": "User requested manually review; edge credit profiling validation override active."
}


Validation & Success Criteria

Validate your automated setup before leaving it in the hands of dev teams:

  • Build Break Verification: Intentionally create a dummy branch change where your ai-manifest.json intended_purpose is updated to "social scoring". Verify that your CI pipeline returns an exit code of 1 and blocks the path.

  • Signed Payload Generation: Ensure an encrypted, signed .tar.gz.gpg compliance bundle lands in your storage target after every system release.

Operational Governance & Security

Security & Permissions

  • Git Access Rights: Prevent developers from bypassing policy definitions. Keep critical Rego folders restricted to approved workspace security and compliance managers.

  • Production Deployment Isolation: Run code-signing functions in isolated secure runner processes to preserve authenticity.

Operation & Performance

  • Build Phase Speed: Run light validation steps during Git staging blocks. Keep heavy model verification calculations inside asynchronous stages to prevent pipeline lag.

  • Telemetry Performance Overhead: Dispatch bias and log alerts over async channels to ensure runtime processing performance remains stable.

What to Avoid

  • Sprawling Spreadsheets: Flat offline files and emails do not scale. Manual reviews fail under system updates.

  • Outdated System Manifests: Never update models in staging environment scopes without concurrently auditing ai-manifest.json metrics. Outdated configurations run high risks of missing compliance windows entirely.

Maintenance & Troubleshooting

  • Dynamic Regulatory Changes: As rules shift, update central Rego logic pools (risk_classifier.rego). Set a recurring schedule to sanity-test older, lower-priority applications to verify they haven't moved into high-risk domains under updated rules.

  • System Assertions Override: If an operation falls under legal exception paths but checks flag high risk, implement the "risk_classification_override" value inside ai-manifest.json only alongside signed and verified regulatory exemptions stored in the secure environment tracking archives.

Monitoring and Measuring Success

Compliance Metric

Database Trace Location

Target Operational SLA

Asset Registry Coverage

/api/v1/compliance/coverage_index

100% of productive configurations backed by active manifests

Pipeline Intercept Metric

Active build pipeline run state logs

Zero high-risk setups bypass policy checks without generating a signed package

Telemetry Trace Coverage

Global monitoring platform logs

Drift and active override markers logged inside a tight 5-second interval

Exception Status Duration

Internal Exception Tracking records

Periodic manual verification cycles triggered at least every 180 days


Kordic is currently testing the Google Cloud Platform (GCP) solution and we learned that it handles this exact pipeline structure by baking automated governance directly into Vertex AI (Google’s unified machine learning platform) and its foundational infrastructure toolsets.

Instead of forcing you to build everything from scratch via custom code and scripts, GCP offers built-in enterprise services that correspond perfectly to each metric outlined above.


In fact, true story, when building one of our multi-agent projects, we hit a lot of roadblocks when pulling in different users to help build onto the solution. You can't just add users and assign personas, you have to really understand how to govern GCP and adjust the policies. Annoyed the heck out of us but now we understand what's at stake for highly regulated customers.

Comments

bottom of page