How should financial institutions include AI systems in DORA compliance programmes?

Why This Matters for Security Teams

DORA pushes financial institutions to prove that operational resilience covers the full ICT stack, and that includes AI systems when they process data, trigger workflows, or depend on external services. The mistake many programmes make is treating AI as a separate innovation track instead of an in-scope asset class with owners, dependencies, and failure modes. That creates gaps in inventory, incident classification, testing scope, and supplier oversight. The regulatory lens is set out in the EU Digital Operational Resilience Act (DORA), while identity and access controls should still be anchored in NIST Cybersecurity Framework 2.0.

For AI-heavy environments, the real risk is not just a model outage. It is an AI tool or agent that can call APIs, consume secrets, or chain actions across systems without the controls being visible to the second line or to auditors. That is why NHI governance matters alongside DORA governance: machine identities, service accounts, and API tokens are often the mechanism that makes AI operational. The same problem shows up in breach reporting and audit evidence, which is why NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives remains relevant here. In practice, many security teams encounter the AI control gap only after an incident review or audit request, rather than through intentional design.

How It Works in Practice

Start by extending the ICT asset inventory to include every AI model, chatbot, orchestration layer, API integration, plugin, and autonomous agent. Each item should have an accountable owner, a business purpose, data classifications, upstream and downstream dependencies, and a list of credentials or tokens it can use. That gives compliance teams evidence that the AI is not an unknown shadow service. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful for translating that inventory into lifecycle controls.

From there, map AI systems into DORA workflows in four places:

• Incident reporting: define what constitutes an AI-related disruption, data leak, or unsafe automated action.
• Resilience testing: include prompt injection, model failure, API dependency loss, and fallback-path testing.
• Third-party governance: review model hosts, vector databases, managed inferencing, and MCP-style tool chains as critical suppliers.
• Access governance: ensure every AI workload has a non-human identity, least-privilege entitlements, and short-lived secrets where possible.

For identity proofing and workload controls, align the implementation with NIST SP 800-63 Digital Identity Guidelines and treat AI credentials as operational secrets, not developer convenience artefacts. Current guidance suggests this is strongest when the system uses just-in-time credential issuance, explicit approval for high-risk actions, and time-bound tokens that expire after the task completes. Where AI systems can autonomously retrieve secrets or invoke tools without runtime policy checks, DORA evidence tends to become brittle because ownership, blast radius, and control effectiveness are no longer defensible. High-risk exposure patterns are well illustrated by the DeepSeek breach. These controls tend to break down when AI is embedded inside legacy automation that reuses shared service accounts and undocumented API keys.

Common Variations and Edge Cases

Tighter controls often increase operational overhead, so institutions have to balance resilience and auditability against deployment speed and model agility. That tradeoff becomes sharper when AI is used for customer service, fraud operations, or developer productivity, because those environments may need fast release cycles and multiple vendors. Best practice is evolving, but there is no universal standard yet for how granular DORA evidence should be when an AI agent acts through several chained services.

For that reason, many teams split AI into tiers. Low-risk assistive tools can sit under standard change and access controls, while autonomous or decisioning agents need stronger approvals, separate secrets, dedicated monitoring, and explicit fallback rules. The compromise is especially important when an AI system can influence payments, onboarding, or trading workflows, because intent-based behaviour is harder to predict than static application logic. Industry material such as NHIMG’s Top 10 NHI Issues helps frame the recurring control failures, while DORA’s own resilience expectations should be read alongside DORA — Digital Operational Resilience Act. For institutions with highly dynamic agentic workloads, the toughest edge case is not model quality; it is proving that the right identity, policy, and recovery controls existed at the moment the AI acted.

Related resources from NHI Mgmt Group

• How should financial services teams evaluate AI compliance platforms for examiner readiness?
• What do financial institutions get wrong about shadow AI discovery?
• How should financial institutions govern explainable AI in high-risk use cases?
• How should financial institutions balance DORA compliance with customer authentication experience?