Talk to us
Research5 min read

EU AI Act for agentic AI in financial services: what applies and when

The EU AI Act does not name agents. It does not need to — an agent that acts inside a high-risk function inherits every obligation the Act attaches to that function.

Written by

Key takeaways

  • The EU AI Act is risk-based and applies to AI systems — a category that includes agents. Financial services use cases (credit scoring, trading, onboarding, underwriting, claims) are largely high-risk under Annex III.
  • The obligations that decide agent deployments are the ones agents are worst at by default: logging, human oversight, accuracy and robustness, and technical documentation.
  • The timeline is no longer distant: core high-risk obligations apply from August 2026, with further provisions into 2027.
  • The controls the Act expects — identity, oversight gates, automatic logs, documentation — are the same controls a governed deployment needs for every other reason. Building them once satisfies the regulator, the auditor and the incident review.

The classification question comes first

The EU AI Act sorts AI systems into risk tiers, and the tier decides the obligations. For financial institutions, the high-risk category is not an edge case: creditworthiness assessment, credit scoring, risk assessment and pricing in life and health insurance are explicitly listed as high-risk under Annex III. An agent that assembles evidence for a credit decision, prepares an underwriting file, or routes a prior-authorization case is operating inside a high-risk function — and the Act does not care that the “system” is a workflow of models, retrieval and tool calls rather than a single model. Providers and deployers both carry obligations, and most banks and insurers deploying agents are deployers (sometimes also providers, if they put their name on a system they substantially modified).

The practical trap is treating the agent as “just tooling” because a human stays in the loop. The Act’s oversight expectations are specific about what the human must be able to do: properly use the system, interpret its output, decide to disregard it, and intervene or stop it. An analyst who can only click “approve” on an opaque file does not satisfy that. The oversight design — what the reviewer sees, what they can decline, how they stop the run — is part of the compliance surface.

The four obligations that decide agent deployments

Record-keeping (Article 12). High-risk systems must keep automatically generated logs over their lifetime, sufficient to reconstruct events. For an agent this is the audit trail question: every tool invocation, every system change, every policy decision, every human approval — attributable to a specific agent identity, tamper-evident, with timestamps that agree across systems. Application logs do not meet this bar; they were never designed for attribution.

Human oversight (Article 14). The deployer must ensure natural persons can understand the system’s capacities and limitations, remain aware of automation bias, interpret output correctly, and intervene or halt the system. Translated into agent architecture: approval gates where the reviewer sees the proposal and the evidence behind it, authority to reject with a reason, and a tested stop control that works without the agent’s cooperation. A gate nobody can meaningfully evaluate, or a stop button that leaves in-flight work running, fails the requirement in substance.

Accuracy, robustness and cybersecurity (Article 15). Agents must perform consistently and resist attempts to alter their behavior. For deployments this means scoped permissions (the agent cannot reach what it should not), tested behavior under missing or conflicting data, and evidence of how the system handles the edge cases — which is what evaluation sets built from the institution’s own cases are for.

Technical documentation (Article 11). Providers must maintain documentation describing the system, its design, and its risk management before market placement. For agents, this maps to the registry and manifest: what the agent is for, which models and tools it uses, what data class it touches, what its risk tier is, and which version is in production. Documentation that drifts from what is running is a finding waiting to happen — which is why the manifest should be tied to the deployable artifact.

The timeline, honestly stated

The Act entered into force in August 2024 and phases in. Prohibitions and AI literacy applied first (2025). Governance structures and general-purpose model obligations applied from August 2025. The core obligations for most Annex III high-risk systems apply from August 2026, with some provisions extending to August 2027. Financial institutions in 2026 are inside the window, not ahead of it — and supervision will ask deployers what their agents are, where they act, and what evidence exists, at exactly the moment SR 26-2’s RFI and DORA examinations ask parallel questions elsewhere in the compliance calendar.

What compliance-compatible agent deployment looks like

The useful observation is that nothing on the Act’s list is exotic. Every obligation above is a control that a governed deployment needs anyway — for audits, for incident response, for the CISO’s own questions:

  • The agent registry satisfies documentation and inventory: each agent with its owner, use case, data class, risk tier and production version, tied to the approval that authorized it.
  • Per-agent identity through your IdP makes every action attributable — the precondition for logs that can reconstruct events.
  • A policy gateway checks each call before execution and writes the record: the compliance-grade log Article 12 expects, produced by the same mechanism that enforces policy.
  • Approval gates are the human oversight mechanism, designed so the reviewer can actually exercise judgment.
  • Tested stop controls — including in-flight work — are the intervention capability, proven by drill rather than asserted.

Deployed inside the institution’s own cloud, the evidence stays where EU data-residency expectations put it. This is the architecture Moring ships: agents governed from a control plane in your environment, with the Act’s obligations satisfied as a byproduct of governing the deployment properly. The EU AI Act answer page carries the requirement-by-requirement mapping, and the risk and control framework shows the six control layers underneath.

Sources

  • Regulation (EU) 2024/1689 (EU AI Act) — EUR-Lex. Articles 9–15 (high-risk requirements), 26 (deployer obligations), 72 (logging and reporting). Accessed October 2026.
  • European Commission, AI Act implementation timeline, 2026.
  • Compare with: SR 26-2 (US banking, agentic AI out of scope pending RFI) and Regulation (EU) 2022/2554 (DORA) — the DORA and agents page maps the overlap.

Frequently asked questions

Does the EU AI Act apply to agentic AI in financial services?

Yes. The Act regulates AI systems by risk, and agents used in credit scoring, trading, onboarding, insurance underwriting or claims handling generally fall in the high-risk category. The Act does not create a separate agent category — an agent acting inside a high-risk function inherits that function's obligations.

When do EU AI Act obligations apply to high-risk AI systems?

The Act entered into force August 2024 with a phased timeline: most obligations for high-risk systems under Annex III apply from August 2026, with certain obligations extending to 2027. Financial institutions deploying agents into high-risk functions should treat conformity work as current, not future.

What records must an agent keep under the EU AI Act?

High-risk systems must keep automatically generated logs sufficient to reconstruct events: for agents, that means what the agent accessed, decided, and changed, which policy allowed it, and which human approved consequential steps — tamper-evident, attributable to a specific agent identity, and consistent across systems.

Architecture & Governance

Governing Autonomous AI Agents in Production

Moring provides the runtime control layer, identity verification, human-in-the-loop approvals, and audit records needed to deploy production-grade AI agents safely.

EU AI Actagentic AIfinancial servicescomplianceAI governance

About the author

Arya Sharan

Arya SharanProduct Marketing & GTM, Moring AIChennai

Owns product marketing and go-to-market at Moring AI across positioning, demand and enablement. Works with regulated buyers on how governed AI agents are scoped, evaluated and bought. Writes about the operating questions that decide whether an agent reaches production.

LinkedIn profile