EU AI Act Risk Classification: Enterprise Technical Guide for System Mapping and Compliance Triage

Overview

EU AI Act risk classification is the process of determining whether an AI system falls into the Act's unacceptable risk, high-risk, limited-risk, or minimal-risk categories. Its core purpose is to align technical controls, documentation, and governance with the obligations that apply to the system's intended purpose, deployment context, and impact on people.

Enterprises use risk classification to answer three operational questions:

• What are we building or buying? Identify the model, application, users, and decision path.
• What obligations apply? Map the use case to prohibited practices, Annex III high-risk domains, transparency duties, or low-risk treatment.
• What evidence do we need? Produce logs, model cards, DPIAs, human oversight procedures, and supplier attestations.

In practice, classification is not a one-time legal memo. It is a repeatable control in the SDLC and vendor onboarding process, usually owned jointly by security, privacy, legal, enterprise architecture, and the AI platform team.

Architecture

A production-ready EU AI Act classification workflow usually includes these components:

• AI system inventory: CMDB, service catalog, or GRC register storing owner, purpose, model type, vendor, and deployment status.
• Intake questionnaire: Structured metadata on use case, affected users, geography, data categories, and automated decisioning.
• Policy engine: Rules that map answers to risk classes and required controls.
• Evidence store: Versioned repository for assessments, model documentation, test reports, and approvals.
• Workflow orchestration: CI/CD or ticketing integration to block releases until required evidence exists.
• Audit logging: Immutable logs for who classified the system, what changed, and why.

Deployment models

• Centralized governance service: Best for large enterprises with many AI products.
• Embedded pipeline control: Best for platform teams enforcing classification in GitHub Actions, GitLab CI, or Azure DevOps.
• GRC-integrated model: Best when ServiceNow IRM, Archer, or OneTrust already manages compliance workflows.

Data flow

1. Product team submits AI use case metadata.
2. Policy engine evaluates prohibited use and high-risk indicators.
3. Workflow assigns obligations such as transparency notice, FRIA/DPIA review, human oversight, or conformity assessment preparation.
4. CI/CD checks for required artifacts before promotion.
5. Audit trail and dashboards expose status to compliance and security teams.

Implementation Guide

A lightweight implementation can be built with a Git-based registry and Open Policy Agent.

1. Create a repository for AI system records.
2. Store each system as JSON.
3. Evaluate records with OPA policies.
4. Fail CI when classification is missing or controls are incomplete.

CLI setup

mkdir -p ai-act-registry/systems ai-act-registry/policy
cd ai-act-registry
curl -L -o opa https://openpolicyagent.org/downloads/latest/opa_linux_amd64_static
chmod +x opa
./opa version

System record

{
  "system_id": "hr-candidate-screening-01",
  "owner": "talent-platform",
  "purpose": "ranking job applicants",
  "model_type": "ml-classifier",
  "deployment": "saas",
  "geography": ["EU"],
  "uses_biometric_data": false,
  "affects_employment": true,
  "automated_decision_support": true,
  "vendor": "Workday"
}

OPA policy

package euaiact

default risk_class = "minimal-risk"

risk_class = "unacceptable-risk" if {
  input.prohibited_practice == true
}

risk_class = "high-risk" if {
  input.affects_employment == true
}

risk_class = "limited-risk" if {
  input.generates_synthetic_content == true
}

Run evaluation

./opa eval -i systems/hr-candidate-screening-01.json -d policy 'data.euaiact.risk_class'

CI gate example

CLASS=$(./opa eval -f raw -i systems/hr-candidate-screening-01.json -d policy 'data.euaiact.risk_class')
if [ "$CLASS" = "high-risk" ]; then
  test -f systems/hr-candidate-screening-01-controls.yaml || { echo "Missing controls file"; exit 1; }
fi

Code Examples

1. Bash validation script

#!/usr/bin/env bash
set -euo pipefail
for f in systems/*.json; do
  class=$(./opa eval -f raw -i "$f" -d policy 'data.euaiact.risk_class')
  echo "$f => $class"
  if [[ "$class" == "high-risk" ]] && [[ ! -f "${f%.json}-controls.yaml" ]]; then
    echo "ERROR: controls missing for $f" >&2
    exit 2
  fi
done

2. YAML control manifest

system_id: hr-candidate-screening-01
risk_class: high-risk
controls:
  human_oversight: required
  logging: enabled
  data_governance: approved
  transparency_notice: published
  supplier_assurance: collected
approvers:
  - legal
  - privacy
  - security

3. Python reporting script

import json, glob
for path in glob.glob('systems/*.json'):
    with open(path) as f:
        data = json.load(f)
    flags = []
    if data.get('affects_employment'):
        flags.append('Annex III employment indicator')
    if data.get('uses_biometric_data'):
        flags.append('biometric processing review')
    print({'system_id': data['system_id'], 'flags': flags})

Security Hardening

• Encrypt the evidence repository with AES-256 at rest and enforce TLS 1.2+ in transit.
• Use RBAC so product teams can submit records, while only governance approvers can change final classification.
• Store approvals and policy changes in immutable logs such as WORM storage or signed Git commits.
• Separate model telemetry from compliance evidence to reduce unnecessary access to personal data.
• Integrate with IAM and PAM for privileged actions such as policy updates and exception approvals.

Comparison

Troubleshooting

Error 1: Missing required field

Log sample:

2026-04-11T09:14:22Z validator ERROR system_id=hr-candidate-screening-01 msg="schema validation failed" field="purpose" error="required property missing"

Fix: enforce JSON schema validation in pre-commit and CI before OPA evaluation.

Error 2: Policy package not found

Log sample:

Error: 1 error occurred: policy/classify.rego:1: rego_parse_error: package expected

Fix: ensure the Rego file starts with package euaiact and has valid syntax.

Error 3: Controls file missing for high-risk system

Log sample:

ERROR: controls missing for systems/hr-candidate-screening-01.json
CI job failed with exit code 2

Fix: add the control manifest and require approvals from legal, privacy, and security before merge.

Best Practices

Do

• Classify by intended purpose, not by model complexity. A simple scoring model in hiring can be high-risk.
• Version every decision with timestamp, owner, and rationale.
• Automate evidence checks in CI/CD and vendor onboarding.
• Reassess after change events such as new data sources, new jurisdictions, or expanded user groups.

Don't

• Don't assume a general-purpose model is low risk when embedded in a regulated workflow.
• Don't keep classification in spreadsheets without audit trails.
• Don't separate legal review from technical architecture; data flow and human oversight materially affect classification.
• Don't treat transparency obligations as optional for synthetic content or chatbot use cases.