Status: “non-binding,” and what that actually means.
The first thing to read is the cover page. BaFin labels this document a „nicht verpflichtende Hilfestellung“ — a non-binding aid. The wording is deliberate, and so is what follows.
Three things compress that label.
First, Beweislastumkehr. In an examination, a bank that deviates from the guidance does not get to stay silent on the deviation. It must demonstrate that the chosen alternative measures provide a „gleichwertiges Schutzniveau“ — an equivalent protective level. The burden has shifted from “show me the rule you broke” to “show me the equivalent rule you kept.”
Second, the examination vehicle. A § 44 KWG-Sonderprüfung is the legal instrument by which BaFin tests how the guidance is being applied in practice. The Wirtschaftsprüfer reads the guidance, walks through the bank's process, and writes findings against the gap.
Third, the audit standard. IDW EPS 528 was issued as Entwurf on 7 August 2025 by the Bankenfachausschuss; the Konsultationsfrist closed 31 October 2025. From the 2026 Prüfungsjahr onward, the consultation-phase indulgence ends. What was advisory becomes the audit baseline.
So: „nicht verpflichtend“ in the document, Prüfungsmaßstab in the file room.
The definition that does the work: KI as IKT-Asset.
The legal pivot of the document is one sentence in Chapter I.
„KI-Systeme sind ein Unterfall der weiter gefassten Netzwerk- und Informationssysteme.“
The English translation BaFin published on 30 January 2026 renders the same hook as “AI systems are a sub-case of the broader network and information systems” (Article 3 Nr. 2 DORA).
One sentence. No new statute. The full DORA regime — Articles 5 through 15 (ICT risk management), 17 (incident management), 19 (incident reporting), 28 through 30 (third-party risk) — now applies to AI without further legislation. The mathematical model itself is treated as a software-class IKT-asset; the GPU cluster underneath it is a hardware-class IKT-asset; the embedding pipeline is a data-flow asset.
The practical reach extends to „Schatten-KI“ — shadow AI. A bank that has deployed Microsoft 365 Copilot, ServiceNow Now Assist, Salesforce Einstein, or Atlassian Rovo without inventorying these as IKT-assets has, by the guidance's reading, an incomplete Article 8 DORA inventory. The Article 8 inventory is what the Wirtschaftsprüfer reads first.
Behind that one definitional sentence sits a second consequence the guidance pulls forward in Chapter III: if the model is an IKT-asset, the output of that asset — the decision the model produces — is a protocol-bearing event under Article 17 RTS RMF (Delegierte VO (EU) 2024/1774, version control and change management) and Article 27 RTS RMF (status report in „durchsuchbarem elektronischem Format“).
Chapter II — strategy, governance, board accountability.
Chapter II makes the Leitungsorgan — the board — accountable for AI in the same way it is accountable for any IKT system: under Article 5 Abs. 2 DORA. There is no AI carve-out.
The guidance asks for a KI-Strategie either as a stand-alone document or integrated into the IKT/DORA strategy. That strategy must define risk appetite, allocated resources, and governance roles. A strategy that says “we will innovate with generative AI” but allocates no budget for cloud security or specialised AI auditors is, in the guidance's framing, internally inconsistent — a Governance-Mangel.
Chapter II also asks board members to understand specific failure modes — Model Drift, LLM-Halluzinationen, the limits of automation. The guidance does not dictate a curriculum. It does dictate that ignorance is not a defence: a Vorstand that cannot articulate why a model began returning systematically wrong credit scores after a data-distribution shift cannot then point to the data team. Article 13 Abs. 6 DORA frames the same point as a literacy obligation.
For procurement, this collapses into a contractual question: can the AI vendor produce a written policy document, signed by the vendor's own board, that the bank can put in the file? “Trust us, we have processes” is not the artefact the Wirtschaftsprüfer is looking for.
Chapter III — source code, version control, adversarial testing.
Chapter III treats AI development as software development with KI-specific additions. The verb the guidance keeps using is prüfen — examine — and the standards it points at are conventional: Article 16 Abs. 3 RTS RMF (statische Codeanalyse), Article 17 RTS RMF (Notfalländerungen, Versionskontrolle), Article 24 Abs. 2 DORA (Tests).
Three KI-specific additions sit on top.
First, version control extends to model weights and training data. Every model artefact must be reproducible; every training run must have a recorded data snapshot, a recorded weights file, and a recorded configuration. The point is not engineering hygiene — it is forensic reconstruction. When a regulator asks why a specific decision came out a specific way on a specific date, the bank must be able to replay it.
Second, adversarial testing is named explicitly. Data poisoning, evasion attacks, model inversion, and — for LLMs — prompt injection are not framed as edge cases. They are the testing baseline, with reports the bank must produce on request.
Third, code generated by AI assistants (Copilot-class tooling) gets the same static analysis pass as code written by hand, plus a check that the assistant did not introduce unintended external API calls. The risk being addressed is not productivity. It is supply-chain integrity.
Behind all three sits the audit-trail consequence: every model version must be referenceable in any later log entry that records a decision made by that version. A chain entry that says “the underwriter agent declined this loan” without naming the model version is, under Chapter III's reading, incomplete.
Chapter IV — operations, model drift, decommissioning.
Chapter IV is where the guidance does its most engineering-specific work. Three obligations stand out.
Monitoring crosses Article 9 Abs. 3 DORA (Schutzmaßnahmen) and Article 10 DORA (Erkennung) onto AI specifics. The expectation is concrete: defined drift thresholds, automated alerts when thresholds are breached, a Rollback path to a stable model version. The guidance does not specify whether drift is measured against training-data distribution, holdout-set performance, or production output — but it expects the bank to specify, document, and defend the choice.
Access control follows Article 21 RTS RMF: „rollenbasierte Zugriffsrechte“ for the model itself, the training pipeline, and the inference endpoint. A data scientist who can change a production model unilaterally is, under the guidance's reading, a control gap.
Decommissioning gets its own paragraph. The Article 8 Abs. 2 lit. a i RTS RMF formulation — „KI-Modelle nach dem Löschen unwiederbringlich entfernen“ — translates to cryptographic wiping of model weights, training data, and configuration scripts at end-of-life. Embedding-store entries fall under the same rule.
One obligation cuts across all three: the audit-trail itself does not get decommissioned with the model. When a model is wiped in 2030, the chain entries that recorded its 2026–2029 decisions remain. Otherwise the seven-year evidence window collapses the moment a model is retired.
The third-party regime: Articles 28–30 and the RTS Untervergabe.
Chapter II quietly does double duty. While its surface is governance, its tail returns to the third-party regime — Articles 28, 29, and 30 of DORA, and the RTS Untervergabe (Delegierte VO (EU) 2025/532) underneath them.
The architecture the guidance assumes:
A bank uses an AI service. That AI service runs on a foundation-model provider. That foundation-model provider runs on a hyperscaler. That hyperscaler runs specialised inference workloads on a GPU-cloud sub-contractor. The bank, by Article 30 DORA in combination with Article 3 RTS Untervergabe, must keep a complete subcontractor chain on file and be notified before any node in that chain changes.
Three operational consequences for the AI vendor's own contract follow.
First, Article 30 Abs. 3 DORA — on-site and remote audit rights. SOC 2 Type II reports are bridge evidence, not a substitute. The bank's right to send its own auditor into the vendor's facilities, including the sub-contractors' facilities, must be contractual.
Second, Article 30 Abs. 3 lit. f DORA — export formats for training data, models, prompts, and configurations. A vendor that cannot specify the export format cannot, under the regime, be the third-party provider for a critical or important function.
Third, exit-strategy under Article 28 Abs. 7/8 DORA — annually tested, with a documented Vendor-Lock-in finding for proprietary foundation models (the GPT-, Claude-, Gemini-classes) where lock-in is unavoidable.
Adjudon does not become a financial entity under DORA. But as the bank's IKT-Drittanbieter under Article 28, the same Article 30 contract minimums apply to the contract with us. We have written this in our DPA — and the audit-trail's main job in the third-party regime is making the bank's Article 28 information register, the one filed each March, reproducible from a single export bundle.
What this collapses to for the audit-trail layer.
Three articles read together pull a tamper-evident audit-trail out of DORA without ever using the phrase.
Article 17 RTS RMF demands version control over models and training data. Article 19 DORA demands incident reporting on a 4-hour, 72-hour, 30-day staged timeline, with evidence attachments per checkpoint. Article 27 RTS RMF demands the IKT-status report in „durchsuchbarem elektronischem Format“. None of the three uses the words “hash chain” or “tamper-evident log.” All three together leave no other mechanism that satisfies all three constraints simultaneously.
What the BaFin examiner needs, when they walk in:
Given an arbitrary loan-application timestamp from 2027, produce: the exact model version that decided it, the exact training-data snapshot the model was trained on, the exact policy that was active, the exact reviewer (if any) who approved it, the exact moment each piece of evidence was anchored. Reproducible offline. Without permission from the AI vendor.
“Without permission from the AI vendor” is the load-bearing phrase. An audit-trail that requires the vendor's login to verify is, in the third-party-regime sense, the wrong shape. It collapses Article 30 Abs. 3 lit. f's export requirement and Article 30 Abs. 3's audit-rights requirement into the same dependency on the vendor's continued cooperation.
The Decision Hash Chain — Adjudon's append-only SHA-256 ledger over decisions — is one operational answer to that shape. The export bundle (GET /api/v1/hash-chain/export) is replay-verifiable against the published algorithm without an Adjudon login. We have written what that means contractually in /solutions/fintech and in docs.adjudon.com/compliance/dora; this post is the legal frame those two artefacts sit inside.