Open-Source-KI ist für Banken und Versicherer 2026 vor allem dann sinnvoll, wenn sensible Daten in der EU bleiben sollen und der Einsatzkontext sauber klassifiziert wird. Für Kreditscoring greift regelmäßig Hochrisiko-KI nach Anhang III der EU-VO 2024/1689, für Fraud Detection dagegen typischerweise nicht; genau diese Trennung entscheidet über Aufwand, Governance und Budget.
Letzte Aktualisierung: 23. März 2026
Finanzhäuser sollten deshalb nicht mit dem Modell beginnen, sondern mit dem Zweck. Wer Open-Source-KI in der Finanzdienstleistung einsetzen will, muss zuerst Use Cases inventarisieren, die Pflicht zur KI-Kompetenz nach Artikel 4 umsetzen und interne Freigaben dokumentieren. Für typische Einstiegsfragen zu Rollen, Fristen und Nachweisen ist zusätzlich die FAQ relevant.
Welche OS-Modelle für Finanz-KI?
Für Finanz-KI eignen sich Open-Source-Modelle nur dann, wenn Lizenz, Hosting, Latenz und Auditierbarkeit zum konkreten Prozess passen. Ein allgemeines Basismodell für interne Recherche ist etwas anderes als ein Modell, das Begründungen für Kreditentscheidungen oder Fraud-Flags vorbereitet.
Die technische Auswahl lässt sich 2026 auf wenige sinnvolle Kategorien verdichten:
| Modell oder Klasse | Typischer Finanz-Einsatz | Stärken | Grenzen |
|---|---|---|---|
| Llama 3.1 8B Instruct | Interne Wissensabfrage, Richtlinienassistenz, E-Mail-Entwürfe | Geringere Infrastrukturkosten, breite Tool-Unterstützung | Für komplexe Fachbegründungen oft zu schwach |
| Mistral Small oder Mixtral | Dokumentenanalyse, Compliance-QA, interne Assistenten | Gute Effizienz bei europäischem Hosting | Qualitätsstreuung je nach Prompt und RAG |
| Falcon 40B | Anspruchsvollere Analyse, längere Fachtexte, strukturierte Extraktion | Stark für Self-Hosting-Szenarien mit klarer Datenhoheit | Höherer GPU-Bedarf, langsamer als 7B- bis 8B-Klassen |
| Spezialisierte Embedding-Modelle | Ähnlichkeitssuche in Richtlinien, Verträgen, Ticketdaten | Für Retrieval oft wichtiger als das Haupt-LLM | Kein Ersatz für fachliche Entscheidungslogik |
Für Banken ist deshalb meist eine Zwei-Schichten-Architektur sinnvoll. Ein kleineres Modell bearbeitet Suche, Klassifikation und Vorstrukturierung; ein stärkeres Modell wie Falcon 40B oder eine vergleichbare 30B- bis 40B-Klasse übernimmt nur Fälle mit hoher Komplexität.
Prüfen Sie vor der Auswahl mindestens diese Punkte:
- Ist die Lizenz wirklich offen oder nur „open weight“ mit Nutzungsvorbehalten?
- Reicht das Modell für Textanalyse und Retrieval oder soll es entscheidungsnahe Empfehlungen erzeugen?
- Können Sie Versionen, Prompts, Logs und RAG-Quellen revisionsfest speichern?
- Liegt die produktive Last eher bei 1.000, 10.000 oder 100.000 Vorgängen pro Monat?
Open Source ist im Finanzsektor kein Selbstzweck. Der Vorteil entsteht erst, wenn Datenhoheit, Dokumentation und Kostenkontrolle messbar besser sind als bei einer Cloud-API.
Kreditscoring = HOCHRISIKO (Annex III)
Kreditscoring für natürliche Personen ist im AI Act kein Graubereich, sondern ein ausdrücklicher Hochrisiko-Fall. Anhang III erfasst KI-Systeme zur Bewertung der Kreditwürdigkeit natürlicher Personen oder zur Festlegung ihres Kreditscores im Bereich wesentlicher privater Dienstleistungen.
Für Finanzunternehmen ist damit die erste Compliance-Frage nicht „Ist das Modell Open Source?“, sondern „Beeinflusst dieses System Zugang, Preis oder Konditionen eines Kredits für eine natürliche Person?“. Wenn die Antwort Ja lautet, greifen ab dem 2. August 2026 die strengen Anforderungen für Hochrisiko-KI; die Qualifikationspflicht aus Art. 4 gilt bereits seit dem 2. Februar 2025.
Die operative Einordnung für typische Use Cases ist klar:
| Use Case | AI-Act-Einstufung | Begründung |
|---|---|---|
| Bonitätsscore für Privatkredit | Hochrisiko | Anhang III zu wesentlichen privaten Dienstleistungen |
| Vorprüfung von Hypothekenanträgen natürlicher Personen | Hochrisiko | Einfluss auf Zugang zu Finanzierung |
| KI-gestützte Ablehnungsempfehlung bei Konsumentenkredit | Hochrisiko | Entscheidungsvorbereitung mit erheblicher Wirkung |
| Interne Analyse von Firmenbilanzen für B2B-Kredit ohne natürliche Person | Nicht automatisch Hochrisiko | Prüffall, aber nicht derselbe Annex-III-Tatbestand |
Für Hochrisiko-KI reichen allgemeine KI-Richtlinien nicht aus. Betreiber müssen insbesondere Gebrauchsanweisungen des Anbieters befolgen, menschliche Aufsicht organisieren, Eingabedaten im Nutzungskontext bewerten und schwerwiegende Vorfälle weitergeben, soweit Art. 26 dies verlangt.
Ein sauberes Kreditscoring-Setup braucht deshalb mindestens:
- Einen dokumentierten Zweck mit klarer Abgrenzung zu bloßer Assistenz.
- Einen menschlichen Freigabeschritt mit echter Eingriffsmöglichkeit.
- Ein Protokoll für Datenqualität, Drift, Fehlklassifikation und Beschwerden.
- Schulungen für Fachbereich, Modellrisiko, Compliance und Revision.
Wenn Sie diese Logik vertiefen wollen, ist unser Überblick zu Hochrisiko-KI nach Annex III der nächste sinnvolle Schritt. Für Finanzhäuser ist das der rechtliche Kern der gesamten Open-Source-Strategie.
Fraud Detection ist nicht Hochrisiko
Fraud Detection in Banken und Versicherungen ist nach dem AI Act regelmäßig kein Hochrisiko-Fall wie Kreditscoring. Das ist für die Praxis entscheidend, weil Betrugserkennung meist Sicherheits- und Integritätszwecken dient und gerade nicht die Kreditwürdigkeit natürlicher Personen festlegt.
Die Verordnung unterscheidet nicht nach Branche, sondern nach Eingriffslogik. Für den Finanzsektor ist vor allem die Klarstellung aus Erwägungsgrund 58 relevant: KI-Systeme zur Betrugserkennung bei Finanzdienstleistungen fallen nicht allein deshalb unter Hochrisiko, weil sie in regulierten Instituten eingesetzt werden.
Die typische Abgrenzung sieht so aus:
| Fraud-Use-Case | Typische Einstufung | Warum |
|---|---|---|
| Erkennung auffälliger Kartentransaktionen | Regelmäßig nicht Hochrisiko | Fokus auf Transaktionsmuster, nicht auf Kreditwürdigkeit |
| Netzwerk-Analyse für Geldwäsche-Indikatoren | Regelmäßig nicht Hochrisiko | Sicherheits- und Compliance-Zweck, kein expliziter Annex-III-Fall |
| Priorisierung manueller Fraud-Reviews | Regelmäßig nicht Hochrisiko | Assistenzfunktion ohne unmittelbare Bonitätsentscheidung |
| Vollautomatische Sperre mit erheblicher Wirkung auf Privatkunden | Einzelfallprüfung nötig | Kann zusätzliche DSGVO-, Transparenz- oder Haftungsfragen auslösen |
Nicht Hochrisiko bedeutet allerdings nicht „compliancefrei“. Fraud-Systeme brauchen weiterhin klare Schwellenwerte, Falsch-Positiv-Management, menschliche Eskalation, diskriminierungsarme Feature-Auswahl und belastbare Dokumentation.
Für Banken und Versicherer ist diese Checkliste praxistauglich:
- Trennen Sie Fraud Detection technisch und organisatorisch von Kreditscoring.
- Dokumentieren Sie, dass das System Anomalien priorisiert und keine Bonitätsentscheidung trifft.
- Begrenzen Sie automatische Maßnahmen auf klar definierte Risikostufen.
- Prüfen Sie zusätzlich DSGVO, bankaufsichtliche Governance und Beschwerdeprozesse.
Diese Trennung spart Aufwand an der richtigen Stelle. Wer Fraud Detection fälschlich wie Kreditscoring behandelt, überbaut die Governance; wer beides gleichsetzt, unterschätzt dagegen die Risiken im echten Hochrisiko-Pfad.
BaFin-Anforderungen + AI Act
BaFin-Aufsicht und AI Act laufen in der Finanzbranche parallel, nicht alternativ. Banken und Versicherer müssen deshalb bestehende Governance aus MaRisk, DORA, Auslagerungssteuerung und Modellrisikomanagement mit den AI-Act-Pflichten verzahnen.
Der AI Act beantwortet die europäische Produktsicherheits- und Grundrechtslogik. BaFin erwartet zusätzlich, dass Institute Risiken aus Daten, Modellen, IT-Betrieb, Kontrollverfahren und Verantwortlichkeiten in bestehende Aufsichtsstrukturen einbetten.
Für die Umsetzung ist folgende Matrix belastbar:
| Themenfeld | Relevante Regel | Praktische Konsequenz |
|---|---|---|
| KI-Kompetenz | Art. 4 AI Act seit 2. Februar 2025 | Rollenbezogene Schulungen für Fachbereich, Compliance, IT und Revision |
| Hochrisiko-Betrieb | Art. 26 AI Act ab 2. August 2026 | Nutzung nach Anleitung, Aufsicht, Monitoring, Vorfallmanagement |
| Grundrechte-Folgenabschätzung | Art. 27 AI Act | Vor Inbetriebnahme bei Hochrisiko-Deployer-Konstellationen prüfen |
| IT-Resilienz | DORA seit 17. Januar 2025 | Logging, Incident Response, Drittparteirisiko und Testregime mit KI zusammendenken |
| Risikosteuerung | MaRisk-Rahmen der BaFin | KI in Governance, Kontrollen, Verantwortlichkeiten und Validierung verankern |
Für Finanzhäuser ist besonders wichtig, dass Open Source die Aufsicht nicht entschärft. Wenn ein Institut Falcon 40B oder ein anderes Modell selbst hostet, sinkt zwar der Drittlandbezug, aber die Verantwortung für Logging, Patching, Zugriffskontrolle, Modellwechsel und Betriebsstabilität steigt.
Eine belastbare Minimalarchitektur umfasst:
- Ein KI-Inventar mit Zweck, Anbieterrolle, Modellversion und Datenquellen.
- Eine Freigabelogik zwischen Fachbereich, Informationssicherheit, Datenschutz und Compliance.
- Ein separates Prüfprogramm für Hochrisiko-Use-Cases wie Kreditscoring.
- Ein Nachweispaket aus Schulung, Richtlinie, Testprotokollen und Incident-Prozess.
Für die Qualifikationsseite genügt keine Einmal-Schulung für das ganze Haus. Die Anforderungen unterscheiden sich zwischen Fraud Operations, Kreditrisiko, Modellvalidierung, Revision und Management, weshalb Artikel 4 in der Praxis rollenbasiert umgesetzt werden muss.
Falcon 40B und andere Modelle für Finance
Falcon 40B ist für Finanzunternehmen interessant, wenn längere Fachtexte, bessere Extraktion und stärkere interne Analyse wichtiger sind als minimale Infrastrukturkosten. Für Standard-Workflows ist ein kleineres Modell aber oft wirtschaftlicher und leichter zu kontrollieren.
Die Auswahl sollte deshalb nach Prozessstufe erfolgen, nicht nach Modellhype. Ein Kreditprozess mit Dokumentenaufnahme, Vorstrukturierung, Richtlinienabgleich und menschlicher Entscheidung braucht meist mehrere spezialisierte Komponenten statt eines einzigen „Supermodells“.
Die folgende Einordnung ist für 2026 praxistauglich:
| Modellklasse | Geeignet für | Weniger geeignet für | Infrastrukturhinweis |
|---|---|---|---|
| 7B bis 8B | FAQ, Richtlinienchat, erste Klassifikation, Zusammenfassungen | Komplexe Begründungen in sensiblen Einzelfällen | 1 GPU im mittleren Bereich oft ausreichend |
| 12B bis 14B | Anspruchsvollere Extraktion und Fachassistenz | Sehr hohe Parallelität bei knappem Budget | Höherer VRAM-Bedarf, mehr Tuning nötig |
| 30B bis 40B wie Falcon 40B | Tiefere Analyse, längere Kontexte, anspruchsvolle Review-Fälle | Breiter Rollout an Tausende Nutzer ohne starke Infrastruktur | Dedizierte GPU-Server oder Multi-GPU sinnvoll |
| Embedding-Modelle plus RAG | Richtlinien-, FAQ- und Dokumentensuche | Finale Entscheidungsvorbereitung ohne Fachlogik | Oft wichtigster Hebel für Qualität und Nachvollziehbarkeit |
Falcon 40B ist damit kein Universalstandard für Banken. Es ist eine Option für Institute, die intern kontrollierte Inferenz, sensible Datenverarbeitung und höhere Textqualität kombinieren wollen, ohne vollständig von externen API-Anbietern abhängig zu sein.
Vor der Produktivsetzung sollten Finanzteams diese Fragen beantworten:
- Brauchen Sie tatsächlich ein 40B-Modell oder löst RAG mit einem 8B-Modell das Problem günstiger?
- Können Sie Antwortzeiten, Tokenkosten und GPU-Auslastung messen statt schätzen?
- Ist das Modell nur Assistenz oder beeinflusst es einen regulierten Entscheidungsprozess?
- Wie dokumentieren Sie Modellupdates, Prompt-Änderungen und Rückfallverfahren?
Gerade im regulierten Umfeld gewinnt meist nicht das größte Modell, sondern die am besten eingehegte Kombination aus Retrieval, Logging und menschlicher Kontrolle. Das gilt für Banken, Versicherer und Fintechs gleichermaßen.
ROI-Rechnung: Self-Hosting vs. Cloud
Self-Hosting lohnt sich in der Finanzbranche wirtschaftlich erst bei sensiblen Daten, konstantem Volumen und belastbarem Betriebsmodell. Für kleine oder wechselhafte Workloads bleibt eine Cloud-API meist günstiger, selbst wenn Open Source technisch attraktiv wirkt.
Die Kostenentscheidung sollte als Total Cost of Ownership gerechnet werden. Ein dedizierter GPU-Server, Monitoring, Backups, Betriebsaufwand, Sicherheitsupdates und interne Validierung sind in Finanzumgebungen keine Nebenkosten, sondern Pflichtbestandteile.
Ein realistisches Vergleichsmodell sieht so aus:
| Kostenblock pro Monat | Self-Hosting in der EU | Cloud-API |
|---|---|---|
| GPU-Server oder Cluster | 250 bis 1.500 EUR | 0 EUR Fixkosten |
| Storage, Logging, Backups | 50 bis 200 EUR | meist im API-Preis oder Zusatzdiensten |
| Betriebsaufwand intern | 500 bis 2.000 EUR | 100 bis 500 EUR für Integration und Kontrolle |
| Variable Nutzungskosten | gering bei hoher Auslastung | linear mit Nutzung |
| Datenhoheit und Auditierbarkeit | hoch | abhängig vom Anbieter |
Für die Entscheidungslogik reicht meist diese Faustregel:
- Unter 5.000 komplexen Vorgängen pro Monat ist Cloud oft wirtschaftlicher.
- Ab etwa 10.000 bis 50.000 volumenstarken Vorgängen kann Self-Hosting kippen.
- Bei hochsensiblen Finanzdaten kann Self-Hosting schon vor dem Preisvorteil sinnvoll sein.
- Ohne internes Betriebs-Know-how frisst Governance den rechnerischen Kostenvorteil schnell auf.
Ein vereinfachtes Beispiel macht die Größenordnung sichtbar:
| Szenario | Cloud-Kosten | Self-Hosting-Kosten | Tendenz |
|---|---|---|---|
| 3.000 interne Compliance-Anfragen/Monat | 100 bis 300 EUR | 900 bis 2.000 EUR | Cloud günstiger |
| 20.000 dokumentenlastige Fraud-Reviews/Monat | 700 bis 2.000 EUR | 1.100 bis 2.400 EUR | Einzelfall, Architektur entscheidet |
| 60.000 sensible Finanzanfragen/Monat mit EU-Only-Anforderung | 2.000 bis 6.000 EUR | 1.500 bis 3.500 EUR | Self-Hosting kann wirtschaftlich werden |
Die wirtschaftlich saubere Empfehlung lautet deshalb: Starten Sie mit einem klar abgegrenzten Use Case und messen Sie echte Last, Falsch-Positiv-Quote, Bearbeitungszeit und Betriebsaufwand. Erst wenn diese Zahlen vorliegen, ist eine Entscheidung zwischen Cloud, Hybrid und Self-Hosting belastbar.
Wenn Sie Open-Source-KI in Bank oder Versicherung einführen wollen, sollten Sie Compliance und Architektur gemeinsam entscheiden. Unsere EU AI Act Schulung zeigt Teams aus Fachbereich, Compliance und IT, wie Art. 4, Hochrisiko-KI, Rollenklärung und dokumentierbare Prozesse zusammenhängen; der Kurs endet mit Abschlusstest und Zertifikat.