The biggest compliance risk in financial services right now is not the AI tools your team approved. It is the ones they did not.
DORA has been in force since 17 January 2025, and its message to financial services is unambiguous: every AI tool an employee uses is, by definition, a third-party ICT service. Every one of those services must be documented, risk-assessed, and contractually governed.
Now ask yourself: how many AI tools are active in your organisation today? How many are actually in your register of information?
According to a 2025 survey, 98% of organisations have employees using unsanctioned applications, and shadow AI incidents now account for 20% of all data breaches, adding an average of $670,000 to breach costs. In financial services, the average cost of a breach is already $5.56 million. The gap between "what our employees use" and "what we can see" is not a productivity problem. It is a DORA problem, a GDPR problem, and an EU AI Act problem, all at once, and all of them requiring shadow AI governance that most financial services firms have not yet built.
98% of orgs have employees using unsanctioned AI tools | $5.56M average breach cost in financial services |
The DORA Problem with Shadow AI
DORA Articles 28 and 30 sit at the heart of the regulation's third-party risk framework. Together they create obligations that shadow AI directly and systematically violate.
What DORA Articles 28 & 30 Actually Require Article 28 - General Principles of ICT Third-Party Risk Management: Financial entities must manage ICT third-party risk within a documented ICT risk management framework. They remain fully responsible for compliance regardless of outsourcing. Before engagement, a risk analysis and suitability assessment of the provider must be completed. All contractual arrangements must be entered in a Register of Information and reported to supervisors at least annually.
Article 30 - Minimum Contractual Arrangements: Every contract with an ICT third-party must specify: full description of services provided; data location and processing regions; availability, confidentiality and integrity provisions; termination rights and exit strategies; audit rights for the financial entity and competent authority. |
Shadow AI tools have none of this. There is no contract. There is no risk assessment. There is no entry in the register. There is no exit strategy. A rogue ChatGPT subscription used by one analyst to summarise deal memos is, under DORA's definitions, an undocumented ICT third-party relationship, and the financial entity is fully liable.
Under Article 28(3), financial entities must report to competent authorities on the number of new ICT arrangements at least annually. If shadow AI is not discovered, that report will be wrong - and regulators can and will ask questions.
+$670K extra breach cost for organisations with high shadow AI versus those with low or none |
But It's Not Just DORA
It would be tempting to treat shadow AI as a single-regulation compliance problem. It is not. A single unmanaged AI tool can trigger multiple simultaneous violations across different legal frameworks. Consider this illustrative scenario:
The Four-Violations Scenario
A credit analyst at a mid-sized European lender starts using a consumer-grade generative AI tool to draft loan assessments and summarize client financials. They use a personal email to sign up - outside SSO - and pay with a personal card. Six months later, the firm is breached.
SI.No | Violation | What Happened |
1 | Data Breach | Sensitive financial data processed by an external, unsecured AI - no DPA, no security review. |
2 | GDPR Violation | Customer PII ingested into a consumer-grade LLM without lawful basis or explicit consent. |
3 | Internal AI Policy Breach | Employee bypasses the approved-tool register - no documented procurement trail. |
4 | Algorithmic Bias (FS-Specific) | Unvalidated model outputs feed credit or AML decisions, creating discriminatory outcomes. |
Each violation carries its own enforcement regime, its own fines, and its own reputational exposure. DORA penalties can reach 2% of global annual turnover. GDPR fines can reach €20 million or 4% of global turnover - whichever is higher. EU AI Act sanctions for non-compliance with high-risk AI requirements are up to €35 million or 7% of turnover.
A 2024 Gartner poll found that nearly two-thirds of organisations are using generative AI across business units, yet only one in five have achieved advanced governance maturity. That gap is exactly where four-violations scenarios live.
What 'Shadow' Really Means in FS Context
The term shadow AI is often treated as a synonym for "rogue" or "deliberate". In practice, only a small fraction of shadow AI use is intentionally hidden. The three categories below map to very different risk profiles - and require different responses, which is why AI risk assessment has to be applied at the category level, not just at the tool level.
Shadow AI Type | Description | Risk Level |
Intentionally Hidden | Employee knowingly bypasses approval to use a preferred AI tool. Rare but deliberate - motivation is usually speed. | Medium |
Ignorant Usage | Employee uses a consumer AI tool unaware it falls under policy. The most common category - good intentions, invisible exposure. | High |
Sanctioned but Undocumented | A business unit approves use without informing IT or Compliance. Provides false comfort - tool looks 'approved' but has no governance wrapper. | Critical |
The sanctioned-but-undocumented category is the most dangerous precisely because it feels safe. A business unit head says "yes" to a vendor demo and the team starts using the tool the next day. No procurement ticket. No IT security review. No DORA Article 30 contract. No entry in the register. From the outside it looks approved; from a compliance standpoint it is invisible.
The Discovery Gap
Most financial services security teams rely on a combination of SSO logs, endpoint detection tools, expense systems, and SIEM platforms to monitor their environment. Each of these tools is designed to monitor known, approved technology - which is precisely why they each miss a different slice of shadow AI.
Monitoring Tool | What It Catches | What It Misses |
SSO / IAM Logs | Access to approved platforms | Personal AI accounts, browser-based tools used outside SSO, mobile apps |
Endpoint Monitoring (EDR) | Locally installed AI apps | Web-based SaaS AI, API calls from scripts, AI embedded in approved SaaS |
Expense / Procurement Systems | Paid AI subscriptions billed to company | Free-tier AI tools (ChatGPT Free, Gemini Free), personal credit-card purchases |
Network DLP / SIEM | Known-signature data exfiltration | Encrypted AI traffic (HTTPS), novel AI endpoints, semantic data leakage |
The net effect is a patchwork of blind spots. An employee using the free tier of a consumer AI tool on a personal browser profile, paying nothing, accessing via HTTPS, generates zero signal in any of the four systems above. Yet that employee may be uploading client names, account numbers, and credit data every day, and AI tool discovery that runs across all four signal layers simultaneously is the only architecture that reliably closes that gap.
Cisco's 2025 research found that 46% of organisations reported internal data leaks through generative AI. More starkly, 97% of AI-related breaches lacked proper AI access controls - meaning traditional monitoring had already failed before the breach occurred.
Why DORA Makes the Discovery Gap a Legal Problem DORA Article 28(3) requires a complete, accurate Register of Information for all ICT third-party arrangements, submitted to supervisors annually. A discovery gap doesn't just mean operational risk - it means your statutory register is materially incomplete. If a regulator conducts a supervisory review and finds undocumented AI services processing financial or personal data, you are in breach of your reporting obligations on day one. |
What Montro Finds in DORA-Regulated Firms |
The Article 28 registers that Montro reviews at the start of a financial services engagement have a consistent characteristic. They are detailed on the tools the compliance team was well aware of - cloud providers, core banking systems, payment processors, and security tooling - but they are almost entirely silent on AI. That is not because the firm failed to maintain the register. It is because nobody told the compliance team that the AI summarisation tool the credit desk uses, or the AI transcription tool used by the advisory team, qualifies as an ICT third-party service under DORA's definition. The register was built carefully, against a definition the compliance team knew, and the definition is broader than they understood. That gap between what DORA actually means by ICT service and what compliance teams assume it means is where most of the missing entries sit. |
Where to Start: The 30-Day Discovery Audit
The most common reason compliance and security teams delay action on shadow AI is not disagreement about the risk - it is uncertainty about where to begin. A structured 30-day discovery audit provides a concrete, time-boxed starting point that produces actionable outputs rather than endless scoping.
Phase | Activity |
Days 1 - 5 | Data Collection - Pull SSO logs, endpoint telemetry, expense reports, browser proxy logs, and employee survey responses. |
Days 6 - 12 | AI Discovery Scan - Deploy an AI-specific discovery tool to analyse network traffic and SaaS usage for unknown AI endpoints, including shadow AI tools embedded inside already-approved SaaS products. |
Days 13 - 17 | Stakeholder Interviews - Engage department heads and power users to surface sanctioned-but-undocumented tools not visible in logs. |
Days 18 - 23 | Risk Scoring - Classify each tool against DORA Article 28 criteria, GDPR lawful basis, EU AI Act risk tiers, and internal policy. |
Days 24 - 28 | Remediation Plan - Assign each tool to one of: Register & Govern, Replace with Approved Tool, or Retire. |
Days 29 - 30 | Executive Report & Ongoing Monitoring - Deliver findings to CISO / Head of Compliance; implement continuous discovery controls. |
The output of this audit is not just a list of tools - it is the foundation of your DORA Article 28 register update, your GDPR data-flow addendum, and your EU AI Act risk classification. It transforms an invisible shadow AI governance liability into a manageable programme.
Only 17% of organisations have implemented technical controls that can automatically block unauthorised data uploads to AI platforms. A discovery audit is the prerequisite for joining that 17%.
Frequently Asked Questions
Does DORA apply to AI tools employees use on personal accounts?
Yes. DORA defines ICT services broadly as digital and data services provided through ICT systems on an ongoing basis. The definition does not require a corporate procurement relationship, it attaches to the service itself. An analyst using a consumer-grade AI tool via a personal account to process deal memos or client data has introduced an ICT third-party relationship regardless of how the account was created or paid for. The financial entity remains fully responsible for the Article 28 ICT third-party governance obligations, and the absence of a contract makes the position worse, not better.
What is the difference between the DORA Register of Information and a standard vendor register?
A standard vendor register typically captures formally procured suppliers; those that went through procurement, legal review, and contract execution. The DORA Register of Information under Article 28(3) is broader. It must capture every ICT third-party service arrangement, including tools adopted informally, tools used below procurement thresholds, and AI features activated inside already-contracted SaaS products. The register is maintained for supervisory reporting purposes and submitted periodically; an incomplete register is itself a breach of reporting obligations, independent of the underlying shadow AI exposure.
How does the EU AI Act interact with DORA for financial services firms using credit-decisioning AI?
The two regimes apply simultaneously and are not substitutes. Under DORA, credit-decisioning AI is an ICT third-party service requiring registration, risk assessment, and contractual governance. Under the EU AI Act, AI used in credit scoring falls under Annex III as a high-risk system, triggering full deployer obligations; human oversight, logging, fundamental rights impact assessment, and conformity assessment cooperation. A shadow credit-decisioning AI tool simultaneously lacks the DORA register entry and the EU AI Act deployer documentation. Both gaps are enforceable from their respective effective dates.
What should a financial entity do if it discovers a shadow AI tool that has already processed client data?
Four immediate steps. First, preserve logs and document the discovery, the timeline matters for both DORA incident classification and GDPR breach assessment. Second, assess whether the processing constitutes a personal data breach under GDPR Article 33; if so, the 72-hour notification clock may already be running. Third, assess whether the tool is a major ICT incident under DORA Article 19 criteria; client impact, duration, and data loss are the key variables. Fourth, add the tool to the Register of Information and begin the Article 28 due diligence process immediately, even retrospectively. Regulators assess responsiveness, a firm that discovers and acts is in a materially better position than one that discovers and delays.
