Skip to main content

European Banking Authority AI Guidelines: Implementation Mapping

Teams often ask for the EBA's AI rules as if there is one short document that answers the whole problem. In practice, European banking AI governance is spread across several real supervisory sources: the EBA Guidelines on internal governance, outsourcing arrangements, and ICT and security risk management, plus broader model-risk and operational-resilience expectations, now layered with the EU AI Act and DORA. That means implementation mapping matters more than slogan-level compliance. Keeptrusts helps with that mapping by turning approved-provider, minimization, human-review, and evidence expectations into route-level behavior.

This is useful because banks rarely fail on awareness. They fail when policy obligations from several domains meet one AI workflow and no one can say which controls are actually active at runtime.

Use this page when​

  • You are implementing AI-assisted workflows in a bank, lender, payments institution, or regulated fintech.
  • You need to connect banking governance expectations to practical route controls.
  • You want an implementation model that supports EBA-style governance without overstating what the gateway can prove on its own.

Primary audience​

  • Primary: Banking compliance officers, risk managers, platform engineers
  • Secondary: Model governance teams, security architects, internal audit

The problem​

Banking AI governance becomes difficult because the obligations are layered rather than isolated.

One workflow may raise several questions at once. A credit-operations assistant touches personal data, internal credit policy, outsourcing considerations, information-security expectations, and governance over staff reliance on generated output. A complaints-analysis assistant raises conduct, confidentiality, and audit issues. A financial-crime support tool can affect escalation quality, evidentiary handling, and operational resilience. If the control model is weak, every review function sees a different slice of the risk and assumes someone else is handling the runtime path.

That is where many AI implementations lose supervisory credibility. The institution may have strong policies on outsourcing and ICT risk, but the route can still send sensitive information to a provider path that no one explicitly approved. The business may promise that analysts review generated content, but the system still returns a polished recommendation that is easy to accept without challenge. Governance may require traceability, but the evidence is scattered across separate tools with no clear route-level story.

Banks need something simpler: a clear answer to what happens when a sensitive workflow uses AI. Which provider path is allowed? How is personal data reduced? When must a person review? What evidence is left behind? Those are operational questions, and they fit well with route controls.

The solution​

The best banking pattern is to map supervisory expectations into a small number of route invariants.

First, the institution should define which AI use cases belong in a regulated lane rather than a generic productivity lane. Those routes should start with prompt-injection so hostile content cannot redefine the task or expose hidden instructions. Where personal or account-linked information may appear, use pii-detector. Apply data-routing-policy so provider approval and declared data-handling posture are enforceable. Use citation-verifier when the route should answer from approved internal policy, risk standards, or knowledge assets. Add human-oversight whenever the output should support an analyst, not replace one.

This aligns well with the actual shape of banking supervision. Internal governance expects clear ownership. Outsourcing expectations make provider choice material. ICT and security guidance makes route discipline and reviewability important. Human oversight matters because many banking workflows are high consequence even when the AI output is formally “assistive.”

None of this means Keeptrusts is the whole banking control stack. You still need model governance, vendor assessment, resilience planning, records, and sector-specific policy. What the gateway does provide is a concrete control boundary that those other disciplines can point to.

Implementation​

The example below shows a conservative route for credit-operations memo drafting. The assistant may help assemble a structured summary for an analyst, but it cannot bypass provider restrictions or deliver a decision-ready answer without review.

pack:
  name: eba-governed-credit-operations-route
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: banking-approved-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

policies:
  chain:
    - prompt-injection
    - pii-detector
    - data-routing-policy
    - 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:
      - 'ACCOUNT-\\d{10}'
      - 'CLIENT-\\d{8}'
    redaction:
      marker_format: label
      include_metadata: true

  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

  human-oversight:
    action: escalate

  audit-logger: {}

This route does not make an underwriting or credit decision. That is deliberate. In a banking environment, the safer design is often to use AI for analyst support while keeping the person responsible for the consequential determination. The route can still save time, but it does so inside a governed path that is easier to explain to control functions.

The most useful companion pages are Banking & Investment, Data Routing Policy, Human Oversight, Pass Compliance Audits, Risk Manager Guide, and Zero-Trust AI. Together they provide a clearer operating model for institutions mapping AI controls into existing supervisory frameworks.

Results and impact​

The immediate benefit is supervisory coherence. Risk, compliance, security, and platform teams can all inspect the same route and see their concerns reflected in it. Provider restrictions are explicit. Sensitive data handling is explicit. Human review is explicit. That makes it easier to govern AI as part of the bank rather than as a disconnected innovation stream.

The other benefit is change control. Once a route is defined for a regulated use case, any relaxation becomes visible. That matters because many banking AI problems are not caused by the first deployment. They come from later scope expansion that quietly weakens the original control assumptions.

Key takeaways​

  • What teams call “EBA AI guidance” is usually a combination of real banking governance, outsourcing, and ICT expectations applied to AI workflows.
  • Banks should treat sensitive AI routes as regulated operating paths, not generic productivity features.
  • data-routing-policy and human-oversight are especially valuable in banking because provider control and analyst accountability are central supervisory concerns.
  • Route-level controls do not replace vendor governance or model risk management, but they make those disciplines more concrete.
  • A conservative assisted-workflow design is usually easier to defend than a frictionless automated one.

Next steps​