Financial services firms in Germany and across the EU are navigating two overlapping regulatory frameworks that directly affect how AI tools can be used: MaRisk (Mindestanforderungen an das Risikomanagement), the BaFin minimum risk management standard that governs German banks and financial institutions, and DORA (Digital Operational Resilience Act), the EU-wide regulation effective January 2025 that governs ICT risk across all regulated financial entities.
Neither regulation explicitly defines “AI governance.” But both create obligations that attach directly to AI tool usage — around ICT risk management, third-party vendor controls, audit trails, and operational resilience — that many financial services firms are not yet meeting.
This article is written for compliance officers, CISOs, and IT risk managers at banks, asset managers, insurance companies, and payment institutions operating under German or EU financial services regulation.
The regulatory picture
MaRisk
MaRisk is issued by BaFin and sets the minimum requirements for risk management at German financial institutions (Kreditinstitute and other supervised entities). The most recent amendment (MaRisk 7.0, 2023) explicitly addresses model risk management and technology risk in ways that capture AI tool use.
Key modules relevant to AI:
AT 7.2 (Technical and organizational resources): Institutions must have adequate IT infrastructure and processes to support business activities. AI tools used in business processes are part of this infrastructure. If employees are using AI tools without documented risk assessments, access controls, or monitoring, AT 7.2 is implicated.
AT 7.3 (IT risk management): AI providers that receive data from the institution are external IT service providers. The module requires that institutions manage the risk of IT services provided by third parties — including data protection, availability, and processing integrity.
AT 9 (Outsourcing): When AI tools process data that is material to business operations — particularly when they could influence decisions, generate client-facing content, or handle client data — BaFin may classify them as outsourcing arrangements requiring a more rigorous contractual and monitoring framework. This includes documented service level agreements, audit rights, and exit strategies.
BT 3 (Model risk): The MaRisk amendments on model risk management require institutions to identify, assess, and monitor models used in risk-relevant decisions. AI tools used for credit assessment, fraud detection, customer communications, or regulatory reporting fall within this scope.
DORA
DORA (Regulation EU 2022/2554) entered into application on January 17, 2025. It applies to a broad range of financial entities — credit institutions, investment firms, insurance undertakings, payment institutions, crypto-asset service providers, and their ICT third-party service providers.
DORA creates four main obligations that directly affect AI governance:
ICT risk management framework (Articles 5–16): Financial entities must implement a comprehensive ICT risk management framework. AI tools are ICT tools. Ungoverned AI use — employees submitting business data to external models without documented controls — is an ICT risk that the framework must address.
ICT third-party risk management (Articles 28–44): AI model providers — OpenAI, Anthropic, Google, Microsoft — are ICT third-party service providers when they process data on behalf of the financial entity. DORA requires a pre-contractual risk assessment, a written contract with specific minimum clauses (data location, audit rights, exit rights, security standards), and ongoing monitoring. For “critical ICT third-party providers” designated by ESAs, additional oversight applies.
ICT incident reporting (Articles 17–23): If an AI provider suffers an outage, data breach, or model failure that affects the institution’s ICT systems or business processes, DORA’s incident classification and reporting requirements apply. Institutions need monitoring in place to detect and respond to such events.
Digital operational resilience testing (Articles 24–27): Institutions must test the resilience of their ICT systems, including AI-dependent processes. For DORA’s TLPT (threat-led penetration testing) requirements, AI systems embedded in critical processes may be in scope.
The three gaps most financial services firms have today
Gap 1: AI providers are not in the third-party ICT register
MaRisk AT 9 and DORA Article 28 both require institutions to maintain a register of ICT third-party arrangements. When AI tools like ChatGPT, Microsoft Copilot, or Claude are used by employees for business purposes, the providers (OpenAI, Microsoft, Anthropic) are ICT third-party service providers receiving institutional data.
Most institutions have comprehensive vendor registers for traditional IT providers — cloud platforms, core banking systems, payment processors. AI tools added in 2023–2025 often bypassed vendor management entirely: employees adopted them bottom-up, and they never entered the register.
The consequence: no pre-contractual risk assessment, no written contract with DORA-required clauses, no monitoring arrangement, no exit strategy. Under both MaRisk and DORA, this is a compliance gap.
What closes this gap: A formal AI tool inventory integrated into the third-party risk register. For each AI provider receiving institutional data, a documented risk assessment and a data processing agreement covering DORA Article 30 minimum clauses.
Gap 2: No audit trail for AI-assisted decisions
Both frameworks require that institutions can reconstruct the basis for decisions — particularly in areas like credit, fraud, customer communications, and regulatory reporting. When AI tools contribute to those decisions (drafting a credit memo, flagging a transaction, generating a client communication), the AI’s role must be auditable.
Provider-side logs (OpenAI usage dashboards, Azure AI logs) are insufficient for two reasons: they may not be retained for the institution’s required period, and they do not record the institution’s own policy decisions — whether a given use was authorized, what data classification applied, whether human review occurred.
An institution relying solely on provider logs cannot demonstrate to BaFin or a supervisory authority that AI-assisted decisions were governed in accordance with its internal controls framework.
What closes this gap: An institution-controlled audit log that captures, per AI interaction: the user identity, the tool and model used, a timestamp, the data classification of the content, the policy decision applied, and any human review or approval step. Retained for the institution’s standard record retention period (typically 5–10 years for German financial institutions under HGB and banking-specific requirements).
Gap 3: No technical enforcement of data handling policy
Under MaRisk AT 7.2 and DORA’s ICT risk management requirements, institutions must demonstrate that controls are operating effectively — not just documented. A policy that says “employees must not submit client data to external AI models” is not a control. It is a stated intention.
The question auditors and supervisors will ask is: “What prevents an employee from doing so?” If the answer is “training and awareness,” that is documentation of a risk, not evidence of mitigation.
What closes this gap: A technical control — an AI gateway or prompt inspection layer — that enforces data classification rules at the infrastructure level. When a user submits a prompt containing identified sensitive patterns (client names, account numbers, personal data), the gateway intercepts, redacts, or blocks before the content reaches the external model. This is infrastructure-level evidence that the policy is operating as designed.
What DORA Article 30 contracts with AI providers must include
For AI providers classified as ICT third-party service providers under DORA, Article 30 specifies minimum contract terms. Institutions should verify that their agreements with AI providers cover:
- Data location: Where is data processed? Where are model inference requests executed? What EU/non-EU transfers occur, and on what legal basis (Standard Contractual Clauses, adequacy decision, or other)?
- Security standards: What security certifications does the provider hold (ISO 27001, SOC 2 Type II)? What are their incident response SLAs?
- Audit rights: Can the institution audit the provider, or access audit reports (e.g., SOC 2 reports, third-party attestations)?
- Exit rights: What are the termination rights and data deletion obligations? Can the institution migrate data and processes with reasonable notice?
- Sub-processing: Who are the provider’s sub-processors? Are they disclosed? What contractual obligations flow through?
- Incident reporting: How does the provider notify the institution of security incidents, outages, or material changes to the service?
Most major AI providers offer Data Processing Agreements (DPAs) that cover GDPR requirements. Not all cover the full set of DORA Article 30 minimum terms. A gap analysis between the provider’s standard DPA and DORA’s requirements is a necessary step before the arrangement can be documented as compliant.
The MaRisk model risk angle
BT 3 of MaRisk requires institutions to identify, validate, and monitor models used in risk-relevant processes. The definition of “model” in BT 3 is broad: a quantitative method, system, or approach used to process inputs and produce outputs that inform business decisions.
AI models used in the following areas are typically in scope:
- Credit assessment: AI tools that assist in underwriting, scoring, or credit memo preparation
- Fraud and AML: AI-based transaction monitoring or anomaly detection
- Regulatory reporting: AI tools that assist in preparing supervisory submissions
- Customer communications: AI tools that generate or substantially draft client-facing content in areas where accuracy is material (e.g., investment advice, account terms)
For models in scope, BT 3 requires: model documentation, independent validation before production use, ongoing performance monitoring, version control, and a process for model change management.
If an institution is using a third-party AI model (e.g., GPT-4, Claude) as a component in a risk-relevant process without a documented model risk assessment, it has a BT 3 gap regardless of whether the AI provider itself is in the third-party register.
Building compliance in practice
The practical path to MaRisk and DORA compliance for AI use has three phases:
Phase 1: Inventory and classification
Identify all AI tools in active use across the institution. For each, determine: does this tool receive institutional data? Is it used in any risk-relevant process? What data categories does it process?
The output is an AI tool inventory with risk classification, integrated into the third-party ICT register. Tools classified as ICT third-party arrangements require contracts reviewed against DORA Article 30. Tools in risk-relevant processes require model risk assessment under BT 3.
Phase 2: Controls and documentation
For each AI tool in the inventory, implement:
- A documented data handling policy: what categories of data may be submitted, by whom, for what purposes
- Technical enforcement: an AI gateway or content inspection layer that enforces the policy at the infrastructure level
- An institution-controlled audit log: covering user identity, tool, timestamp, data classification, policy decision, and human review steps
- Contractual documentation: DPA and DORA Article 30 terms confirmed with each provider
Phase 3: Monitoring and testing
Implement ongoing monitoring of AI tool usage: automated alerts on policy violations, periodic review of the audit log by a compliance or risk function, and inclusion of AI-related ICT risks in the annual DORA resilience testing program.
Document the monitoring process — date of last review, who reviewed, what was found — in a form that can be produced to BaFin or other supervisory authorities on request.
The supervisory direction
BaFin has published guidance on AI and machine learning in financial services that aligns with the EBA guidelines on internal governance and the EBA roadmap on AI. The supervisory expectation is clear: AI is not an exception to existing governance and risk management frameworks — it is subject to them, with additional requirements in areas like model explainability and third-party concentration risk.
Institutions that treat AI governance as separate from existing ICT risk and model risk frameworks are creating more work, not less. The most efficient path is to extend existing MaRisk and DORA compliance processes to cover AI: add AI tools to the third-party register, extend the model risk framework to cover AI components, and add AI-specific controls to the ICT risk management framework.
The question BaFin will ask is not “do you have an AI policy?” It is “does your AI use comply with your existing MaRisk and DORA obligations?” The answer needs to be demonstrable, not just asserted.
Qadar AI Shield is designed for financial services teams implementing AI governance under MaRisk and DORA: institution-controlled audit logging, prompt inspection and data classification enforcement, and contract-ready documentation for third-party ICT risk assessments. Learn more.