Skip to main content

EU AI Act High-Risk Systems: Mandatory Governance Requirements and Implementation

If your system falls into the EU AI Act high-risk category, the governance question is no longer abstract. Regulation (EU) 2024/1689 expects a risk-management approach, data governance controls, logging, transparency and instructions for use, human oversight, and accuracy, robustness, and cybersecurity measures. Keeptrusts can implement part of that runtime stack in a way engineering teams can operate every day, but it should be treated as one component in a larger compliance program rather than a substitute for the legal, quality-management, and documentation work the Act still requires.

Use this page when​

  • You have identified a use case that may be high-risk under Article 6 and Annex I or Annex III.
  • You need to translate Articles 9 to 15 and Article 26 into deployable controls.
  • You want an implementation pattern that stays within current documented Keeptrusts capabilities.

Primary audience​

  • Primary: Compliance leads, platform engineers, security architects
  • Secondary: Product counsel, privacy officers, ML platform owners

The problem​

High-risk governance often breaks down because the obligations are distributed across too many teams. Legal owns the classification memo. Security owns provider access. Product owns user flows. ML engineering owns model behavior. Operations owns monitoring. Nobody owns the full runtime control chain.

That fragmentation matters because high-risk obligations in the EU AI Act are connected. Article 9 requires a risk-management system. Article 10 addresses data and data governance. Articles 11 and 12 require technical documentation and record-keeping. Article 13 addresses transparency and instructions for use. Article 14 addresses human oversight. Article 15 addresses accuracy, robustness, and cybersecurity. Article 26 then puts operational obligations on deployers, including use according to instructions and monitoring in production.

The most common implementation mistake is to treat governance as documentation only. Teams produce a policy PDF, but the live route still allows direct provider access, accepts uncontrolled personal data, delivers unverified outputs, and has no enforced review stop for sensitive outcomes. The opposite mistake also happens: teams publish examples with unsupported policy fields and assume those fields are enforced when the runtime currently ignores them.

The solution​

For high-risk routes, the safest Keeptrusts pattern is a dedicated gateway path with a narrow provider set, data minimization at input, output quality and grounding checks, explicit escalation instead of direct delivery, and visible audit markers in the chain. This does not complete the entire EU AI Act program, but it gives you a hard runtime envelope that aligns with the operational side of the law.

The mapping is straightforward when kept honest.

Article 10 data governance maps well to pii-detector and data-routing-policy. Those controls reduce the volume of personal data sent upstream and ensure the route only uses providers whose declared data_policy metadata satisfies your retention and training rules.

Article 14 human oversight maps to human-oversight, but only if you respect its current behavior. Today it is an output-phase escalation switch. When action: escalate is set, the gateway returns an escalated result rather than assistant content. Assignment logic, reviewer queues, and final business decisioning must exist outside the policy block.

Article 15 accuracy and robustness map to quality-scorer and, when grounded content matters, citation-verifier. These are the controls that make "do not rely on unchecked output" enforceable in the running system.

Articles 11 and 12 need careful wording. The audit-logger policy itself is a marker that reports audit logging as active in the chain. Actual record persistence, exports, and evidence packages are platform functions outside the policy evaluator. That is still useful, but it should be described accurately.

Implementation​

The following example uses only documented fields from the current policy pages and is appropriate for a dedicated high-risk route where no model output should be delivered without review.

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

providers:
  targets:
    - id: eu-zdr-primary
      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
    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: 150
    min_sentences: 2
    thresholds:
      min_aggregate: 0.7
    assertions:
      - type: contains
        name: includes-rationale
        threshold: 1.0
        mode: enforce
        severity: critical
        config:
          value: "because"

  citation-verifier:
    require_sources: true
    require_source_match: true
    rag_context:
      verify_against_context: true
      min_context_overlap: 0.7
    output_action:
      unverified_action: block

  human-oversight:
    action: escalate

  audit-logger: {}

There are two practical design consequences here. First, a high-risk route should usually be isolated from ordinary productivity traffic. If you enable human-oversight, everything that passes earlier output checks still escalates rather than returning normal content. Second, event handling matters as much as the policy chain. Your review application, case-management queue, or downstream escalation system must consume the decision event and preserve the human resolution path. That is how you turn a gateway stop into an actual governance control.

You should also keep documentation boundaries clear. Keeptrusts can help you demonstrate which controls ran, which provider was selected, which content was redacted, and whether an output was blocked or escalated. It does not generate the full technical documentation package required by Articles 11 and 13, and it does not perform conformity assessment on your behalf.

For the canonical product references, use 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​

The main benefit of this pattern is not that it makes a high-risk system simple. It makes the control boundary explicit. Providers are constrained. Sensitive input is reduced before routing. Weak or unsupported outputs do not pass silently. Sensitive routes do not deliver model output straight to the user. Decision events become exportable evidence instead of anecdotal assurances.

This is also where the governance stack becomes easier to test. You can validate that a route blocks when no compliant provider exists. You can validate that unsupported citations are rejected. You can validate that a successful output still escalates for human review. Those are operational checks, not policy statements.

Key takeaways​

  • High-risk implementation starts with Article 6 classification, but it succeeds only when Articles 9 to 15 become runtime behavior.
  • Keeptrusts is strongest at the runtime layer: redaction, routing constraints, output quality checks, groundedness checks, escalation, and evidence.
  • Current human-oversight behavior is an all-output escalation switch for the route where it is enabled.
  • Current audit-logger behavior marks audit logging as active; storage, retention, and export handling live elsewhere in the platform.
  • Do not overclaim. Keeptrusts supports high-risk governance implementation, but it does not replace the broader compliance program required by Regulation (EU) 2024/1689.

Next steps​