Skip to main content

DORA Compliance: AI Governance for EU Financial Services Resilience

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, is not an AI law. It is an operational resilience regime for financial entities. But once a bank, insurer, payment institution, or investment firm starts relying on LLM workflows for service operations, knowledge retrieval, case triage, internal support, or customer communications, those workflows become part of the ICT risk landscape that DORA expects firms to govern. Keeptrusts helps by putting a technical control point between your applications and upstream model providers so routing, redaction, review, and evidence are enforced consistently instead of left to convention.

Use this page when​

  • You are introducing AI-assisted workflows into an EU-regulated financial services environment.
  • You need a practical way to align AI operations with DORA themes such as ICT risk management, third-party risk control, and evidence collection.
  • You want to understand what Keeptrusts can enforce directly and what still belongs in your broader resilience program.

Primary audience​

  • Primary: Financial services platform engineers, security architects, compliance officers
  • Secondary: Risk managers, operations leads, product counsel

The problem​

DORA became applicable on 17 January 2025. From that point on, financial entities were expected to operate with a more disciplined approach to ICT risk, resilience testing, incident handling, and ICT third-party risk. AI introduces a new version of the same old governance problem: business teams adopt a capability quickly, but the operational control surface stays vague.

That usually shows up in four places.

First, AI routes are often treated like simple SaaS integrations even when they influence regulated operations. A support assistant might summarize complaints, draft incident updates, or prepare internal remediation notes. Those outputs can affect customer communications, operational decisions, and evidence trails, even if the model never makes the final decision itself.

Second, provider routing is usually under-documented. Teams say they use an approved model, but failover logic, dev environments, or copied configuration files quietly expand the list of real providers in production. DORA does not tell you to use one specific vendor, but it does require disciplined control over ICT dependencies and operational risk. A hidden fallback path is the opposite of disciplined control.

Third, firms often rely on policy statements instead of runtime enforcement. They tell employees not to paste customer data or incident details into unapproved tools, but the approved internal route still has no technical guardrails. If a payment investigation note, fraud case summary, or privileged operations detail reaches the wrong provider, the resulting risk is not fixed by a handbook paragraph.

Fourth, teams confuse logging with evidence. A generic application log that says a request happened is not the same as evidence that the request ran through the correct governed route, with the correct provider restrictions, under the correct review rule.

The solution​

For DORA-aligned AI governance, the useful pattern is route separation by operational criticality.

Low-risk internal drafting routes may only need prompt-injection blocking, limited redaction, and provider restrictions. Medium-risk operational routes may also need output quality checks so weak responses are not passed through as if they were reliable runbooks. High-impact routes, such as incident communications or customer-affecting operational summaries, may need a hard review stop so the gateway returns an escalation result rather than assistant content.

Keeptrusts supports that pattern with a small set of technical controls that map well to resilience practice.

Use prompt-injection first to protect the request boundary from jailbreaks and instruction-hijack attempts. Use pii-detector to redact or block obvious identifiers before they reach the provider. Use data-routing-policy to filter provider targets based on declared retention and training metadata, so non-compliant providers never participate in selection for that route. Use quality-scorer to reject responses that are too short or that fail deterministic assertions you care about. Use human-oversight when a route must stop normal delivery and force a review workflow. Finally, place audit-logger in the chain so the decision stream records audit logging as an active control, while remembering that durable storage, retention, and exports are handled elsewhere in the platform.

That last point matters. DORA readiness is broader than a gateway policy stack. You still need vendor governance, resilience testing, incident management, change control, and a real operating model. Keeptrusts is useful because it gives those broader controls a deterministic enforcement point at runtime.

Implementation​

One practical example is an internal operations route used to draft customer-impacting incident summaries. The route redacts known identifiers, limits provider eligibility, checks output quality, and then escalates every result for human review before release.

pack:
  name: dora-incident-summary-route
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: reviewed-zdr-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
        accepts_tokenized_input: true

    - id: standard-provider
      provider: openai
      model: gpt-5.4-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: false
        training_opt_out: true
        retention_days: 30

policies:
  chain:
    - prompt-injection
    - pii-detector
    - data-routing-policy
    - quality-scorer
    - human-oversight
    - audit-logger

policy:
  prompt-injection:
    use_embedding: false
    detection:
      attack_patterns:
        - "ignore.*previous.*instructions"
        - "reveal.*system.*prompt"
    encoding:
      decode_base64: true
      normalize_unicode: true
      detect_homoglyphs: true
    boundaries:
      enforce_delimiters: true
      reject_fake_boundaries: true

  pii-detector:
    action: redact
    detect_patterns:
      - 'CASE-\\d{8}'
      - 'ACCT-\\d{10}'
    redaction:
      marker_format: label
      include_metadata: true
      custom_markers:
        generic_id: "[REDACTED-ID]"

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

  quality-scorer:
    min_output_chars: 120
    min_sentences: 3
    assertions:
      - type: contains
        name: requires-operator-review-note
        threshold: 1.0
        mode: enforce
        severity: critical
        config:
          value: "Operator review required before external release."

  human-oversight:
    action: escalate

  audit-logger: {}

This route does not make a model response safe by magic. It does something more useful: it narrows the runtime options to the ones your resilience program explicitly accepts. The reviewed provider remains eligible. The non-zero-retention fallback is excluded. Sensitive identifiers are redacted before routing. Weak outputs are rejected. And if the route is configured as review-only, the assistant never delivers content directly to the downstream caller.

That is the kind of predictable behavior compliance, risk, and operations teams can actually test. It is also the sort of pattern that fits well with existing Keeptrusts references like EU AI Act Compliance, Configuration & Policy Overview, Data Routing Policy, Audit Logger, and the Compliance Officer Guide.

Results and impact​

The main gain is operational clarity. Instead of arguing in abstract terms about whether a route is "approved," teams can point to the exact controls that make it approved: which providers are allowed, how sensitive content is treated, whether outputs can be delivered automatically, and how evidence is produced.

That helps more than compliance. Security teams gain a reliable request boundary. Platform teams get cleaner separation between low-risk and high-impact AI routes. Incident responders stop guessing which model path handled a sensitive workflow. Compliance teams can distinguish between generic AI usage data and the decision stream for specific resilience-sensitive routes.

It also improves change discipline. When a provider or route configuration changes, the change has a visible governance effect. That is better than discovering weeks later that a team quietly widened retention tolerance or enabled a fallback target that never went through review.

Key takeaways​

  • DORA is not an AI law, but AI routes still sit inside the ICT risk perimeter DORA expects you to govern.
  • Keeptrusts helps by enforcing runtime restrictions on provider selection, redaction, output handling, and review stops.
  • audit-logger should be described accurately as an allow-only audit marker in the chain, with durable evidence handled by surrounding platform services.
  • High-impact routes should usually be separated from low-risk drafting routes rather than governed by one generic AI policy.
  • Keeptrusts supports DORA-aligned operations, but it does not replace resilience testing, vendor governance, or incident-management obligations.

Next steps​