Skip to main content

EU AI Act Compliance: Mapping Risk Categories to Keeptrusts Policy Controls

The EU AI Act does not require the same control set for every AI workflow. Under Regulation (EU) 2024/1689, the first operational question is not which model you run; it is whether the use case falls into a prohibited practice, a high-risk AI system, an AI system with specific transparency duties under Article 50, or a lower-risk system that still needs ordinary security and privacy controls. Keeptrusts helps after that classification step by enforcing gateway controls, constraining provider routing, and recording decision evidence. It does not decide the legal category for you and it does not replace legal review.

Use this page when​

  • You need to turn an EU AI Act legal classification exercise into concrete gateway controls.
  • You are standardizing one platform across multiple AI use cases with different regulatory burdens.
  • You want a practical way to distinguish where Keeptrusts can enforce a control and where policy, product, or legal process must do the rest.

Primary audience​

  • Primary: Compliance officers, platform owners, technical leaders
  • Secondary: Security engineers, privacy engineers, product counsel

The problem​

Many teams start with a single "AI compliance" checklist and then apply it everywhere. That is a weak approach under Regulation (EU) 2024/1689. The EU AI Act separates prohibited AI practices under Article 5, high-risk AI systems under Article 6 plus Annex I and Annex III, and AI systems subject to specific transparency duties under Article 50. In practice, that means a public chatbot, a hiring workflow, and an internal summarization tool do not need the same runtime treatment.

The second problem is translation. Legal teams speak in Articles, annexes, and obligations. Engineering teams speak in policy chains, routing rules, and event logs. If nobody maps one to the other, one of two things happens. Either every use case gets a heavy control stack that slows delivery and obscures accountability, or important workflows go live with only generic logging and no enforceable review stop.

Keeptrusts is most useful in that translation layer. It gives you a deterministic gateway point where you can redact inputs, filter provider targets, verify output quality or grounding, and force escalation instead of normal output delivery. What it does not do is certify that a use case is lawful, classify a system automatically, or generate the full technical documentation package the Act may require.

The solution​

A practical mapping starts with four buckets.

For prohibited practices under Article 5, the right implementation answer is usually to refuse the use case. Keeptrusts can still help by blocking defined request classes or sensitive prompt patterns before upstream calls, but gateway controls are a backstop, not a legal basis to operate a banned use case.

For high-risk AI systems under Article 6, Keeptrusts supports the runtime side of governance: data minimization through pii-detector, provider restrictions through data-routing-policy, output quality and groundedness checks through quality-scorer and citation-verifier, review stops through human-oversight, and decision-stream visibility through audit-logger plus platform events and exports. Those controls align well with operational aspects of Articles 9 to 15, especially where the issue is whether the system can be constrained, reviewed, and evidenced in production.

For systems subject to Article 50 transparency duties, the gateway is the place to make disclosures testable. The disclosure itself may live in the UI, an application template, or an output policy, but Keeptrusts can verify required phrases, block ungrounded claims, and log that the relevant route applied the right transparency controls.

For lower-risk systems, the goal is not zero governance. It is proportionate governance. Teams still need privacy, access control, provider selection discipline, and audit visibility even when the AI Act does not impose the high-risk stack.

A useful operating model is to classify each route, not just each application. One product can expose a low-risk drafting assistant, a transparency-scoped customer chatbot, and a high-risk decision-support workflow. Those should not share the same policy chain.

Implementation​

The simplest implementation pattern is to bind specific gateway configs to specific regulatory routes. High-risk routes should use the heaviest controls and dedicated review workflows.

pack:
  name: eu-ai-act-high-risk-route
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: eu-reviewed-provider
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        allow_internet_egress: false
        local_only_processing: false

policies:
  chain:
    - pii-detector
    - data-routing-policy
    - quality-scorer
    - citation-verifier
    - human-oversight
    - audit-logger

policy:
  pii-detector:
    action: redact
    healthcare_mode: false
    pci_mode: false
    redaction:
      marker_format: label
      include_metadata: true

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    on_no_compliant_provider: block
    log_provider_selection: true

  quality-scorer:
    min_output_chars: 120
    min_sentences: 2
    assertions:
      - type: contains
        name: includes-review-context
        threshold: 1.0
        mode: enforce
        severity: critical
        config:
          value: "review"

  citation-verifier:
    require_sources: true
    require_source_match: true
    output_action:
      unverified_action: block

  human-oversight:
    action: escalate

  audit-logger: {}

That example is deliberately conservative. It uses documented fields from current policy pages. It also reflects an important design choice: human-oversight is a simple escalation switch in the current implementation. If you enable it on a route, the assistant output is not delivered normally. Instead, the gateway returns an escalated result and emits the corresponding decision event. That makes it appropriate for high-risk or Article 22 style flows, but too strong for ordinary drafting assistants.

For transparency-scoped routes, do not reuse the same chain automatically. Use a lighter route that verifies disclosure or disclosure-ready output, and reserve human-oversight for publication or decision scenarios that truly require manual review.

The pages that matter most for this mapping are EU AI Act Compliance, Meet EU AI Act Requirements with Pre-Built Controls, Configuration & Policy Overview, PII Detector, Data Routing Policy, and Compliance Officer Guide.

Results and impact​

When teams map risk categories to route-specific controls, the compliance conversation becomes much cleaner. Legal and compliance can say which bucket applies. Engineering can show which chain, which provider restrictions, and which evidence exports are attached to that bucket. Product can see which experiences require disclosure, which ones require review, and which ones can operate with lighter controls.

This also reduces false confidence. A low-risk internal assistant should not inherit a high-risk control narrative just because the company uses one gateway everywhere. A high-risk workflow should not claim compliance because it has generic logging. The route-to-control mapping forces explicit decisions.

In organizations that also have sector-specific obligations, the same approach keeps regulations separate. For example, a financial entity may care about DORA, Regulation (EU) 2022/2554, for resilience and operational governance. Keeptrusts logs, routing controls, and change discipline can support those programs, but DORA is not the same as the EU AI Act and should not be collapsed into the same checklist.

Key takeaways​

  • Regulation (EU) 2024/1689 is risk-based. Start with classification, then attach controls.
  • Keeptrusts does not determine whether a use case is prohibited, high-risk, or Article 50-scoped. It operationalizes the control stack after that decision.
  • Route-level governance is better than app-level governance when one product serves multiple regulatory scenarios.
  • Use only documented policy fields in production configs. Current human-oversight is an escalation switch, and current audit-logger is an allow-only audit marker.
  • Separate EU AI Act controls from adjacent frameworks such as GDPR and DORA, even if the same gateway supports evidence for all three.

Next steps​