Methode · Agentic FinOps · Agentic AI

Agentic FinOps im FinCrime-Betrieb: Der Router ist die neue Kontrollinstanz

Warum Semantic Routing in AML-, Fraud- und KYC-Systemen nicht nur Kosten senkt, sondern Modellrisiko, Datenschutz und Auditierbarkeit steuert

Der nächste Kostenblock in der Geldwäscheprävention wird nicht nur aus Cloud-Instanzen, Datenbanken oder Case-Management-Lizenzen entstehen. Er entsteht aus Modellentscheidungen: Welcher Prompt geht an welches Modell? Welche Daten verlassen die Bank? Welche Antwort wird gecacht? Wann eskaliert ein Agent an ein teureres System? Und wer kann später erklären, warum genau diese Route gewählt wurde?

Agentic FinOps wird deshalb in Banken kein Sparprogramm. Es wird ein Kontrollmodell für autonome Kosten-, Qualitäts- und Risikodynamik.

Die zentrale Komponente dafür ist unscheinbar: der Router. In klassischen Architekturen verteilt er Last oder wählt einen technischen Endpunkt. In agentischen FinCrime-Systemen entscheidet er, ob eine KYC-Zusammenfassung lokal verarbeitet wird, ob ein komplexes Geldwäsche-Netzwerk an ein stärkeres Modell geht, ob ein bereits beantworteter Fall aus dem Cache kommt oder ob ein Vorgang wegen Risiko, Datenklasse oder Unsicherheit in die menschliche Prüfung muss.

Das Problem ist nicht, dass große Sprachmodelle teuer sind. Das Problem ist, dass ihre Kosten mit fachlicher Unsicherheit, Datenzugriff, Modellrisiko und Tool-Nutzung verschmelzen. Wer Agentic FinOps nur als Token-Optimierung versteht, baut ein Controlling-Dashboard. Wer es als Betriebsmodell versteht, baut eine Kontrollinstanz.

Von FinOps zu Agentic FinOps

FinOps entstand aus einem einfachen Kontrollverlust: Cloud-Kosten wurden variabel, dezentral und schwer zuzuordnen. Engineering-Teams konnten mit wenigen Architekturentscheidungen erhebliche Ausgaben erzeugen. Die FinOps Foundation beschreibt FinOps entsprechend als Praxis, die technische, finanzielle und geschäftliche Verantwortlichkeit für Cloud-Nutzung zusammenführt. Standards wie FOCUS versuchen, Kosten- und Nutzungsdaten über Anbieter hinweg vergleichbar zu machen.

Agentic FinOps erbt dieses Problem, aber es verschiebt die Achse.

Bei Cloud-FinOps geht es oft um Instanzen, Speicher, Netzwerk, Datenbanken, Kubernetes-Cluster oder SaaS-Verbrauch. Bei Agentic FinOps kommen neue Verbrauchseinheiten hinzu: Tokens, Kontextfenster, Tool-Calls, Retrieval, Embeddings, Modellwechsel, Prompt-Caches, Human Review, Re-Runs und Evaluationsläufe.

Für FinCrime-Systeme reicht eine Metrik wie Cost per Token deshalb nicht. Sie ist technisch sauber, aber fachlich blind. Relevanter sind Metriken wie:

• Kosten pro valide abgeschlossenem KYC-Review
• Kosten pro auditierbarem Verdachtsindikator
• Kosten pro vermiedenem False Positive
• Kosten pro eskaliertem Fall
• Kosten pro geprüftem UBO-Pfad
• Kosten pro reproduzierbarer Modellentscheidung

Erst diese Übersetzung macht Agentic FinOps bankfähig. Sie verbindet Ausgaben mit Prozesswirkung, Kontrollqualität und Nachvollziehbarkeit.

Warum FinCrime ein Sonderfall ist

In vielen Unternehmensprozessen kann ein Router pragmatisch entscheiden: einfache Anfrage an ein günstiges Modell, komplexe Anfrage an ein stärkeres Modell, wiederkehrende Anfrage aus dem Cache. Im FinCrime-Betrieb ist diese Logik gefährlich unvollständig.

Ein AML-, Fraud- oder KYC-Agent arbeitet nicht nur mit Text. Er berührt personenbezogene Daten, Transaktionsdaten, Sanktionshinweise, interne Risikoklassifikationen, PEP-Kontexte, Adverse-Media-Auszüge, UBO-Strukturen und Fallnotizen. Jede Routing-Entscheidung kann deshalb mehrere Governance-Fragen gleichzeitig auslösen:

• Darf diese Datenklasse an diesen Modellanbieter gesendet werden?
• Ist die Verarbeitung lokal, in der EU oder bei einem Drittanbieter vorgesehen?
• Ist das Modell für Zusammenfassung, Klassifikation, Extraktion oder Hypothesenbildung freigegeben?
• Ist der Prompt Teil eines produktiven Kontrollprozesses?
• Muss die Antwort später gegenüber Revision, Aufsicht oder interner Qualitätskontrolle erklärt werden?
• Wird eine gecachte Antwort wiederverwendet, obwohl sich der fachliche Kontext geändert hat?

Damit wird der Router zur Policy-Komponente. Er ist nicht nur ein Wegweiser im technischen Verkehr. Er ist der Punkt, an dem Kosten, Datenschutz, Modellinventar, fachliche Kritikalität und Audit Trail zusammenlaufen.

Semantic Routing: Was technisch passiert

Semantic Routing bricht mit der starren Regel, jede Anfrage direkt an dasselbe Modell zu senden. Der eingehende Prompt wird zuerst analysiert. Häufig geschieht das über ein kleines Embedding-Modell oder einen Klassifikator, der die Anfrage in einen semantischen Raum übersetzt. Dort wird sie mit bekannten Aufgabenklassen verglichen: einfache Extraktion, Risikozusammenfassung, Netzwerkhypothese, Rechercheauftrag, Entscheidungsvorbereitung oder regulatorische Einordnung.

Je nach Ergebnis wählt der Router eine Route:

1. Lokale oder kleine Modelle für standardisierte Extraktion und Klassifikation.
2. Mittlere Modelle für Zusammenfassungen, Normalisierung und strukturierte Voranalysen.
3. Stärkere Modelle für komplexe Hypothesen, Graph-Interpretation und mehrschrittige Fallanalyse.
4. Kein Modell bei Policy-Verstößen, fehlender Freigabe oder zwingendem Human Review.
5. Cache bei semantisch identischen oder fast identischen Standardanfragen.

Red Hat beschreibt diese Router-Logik im LLM- und vLLM-Umfeld als Schicht, die Anfragen semantisch bewertet und an passende Backends verteilt. Für Watchdog ist daran weniger die konkrete Implementierung interessant als die Architekturverschiebung: Modellwahl wird zur eigenen Betriebsdomäne.

In FinCrime-Systemen darf diese Domäne nicht nur auf Kosten und Latenz optimieren. Sie muss mit fachlichen Policies verbunden werden.

Die vier Kontrollschichten eines bankfähigen Routers

Ein Semantic Router für FinCrime braucht mindestens vier Schichten. Fehlt eine davon, entsteht entweder ein teures Spielzeug oder ein nicht auditierbarer Kontrollbruch.

1. Task-Klassifikation

Der Router muss erkennen, welche Art von Arbeit vorliegt. Eine reine Textähnlichkeit reicht dafür selten aus. Die Route hängt nicht nur vom Prompt ab, sondern auch vom Prozesskontext.

Eine Anfrage wie “Fasse diese Akte zusammen” kann harmlos sein, wenn es um ein öffentliches Unternehmensprofil geht. Dieselbe Formulierung kann kritisch sein, wenn sie personenbezogene KYC-Daten, interne Verdachtsmomente oder Sanktionsbezüge enthält.

Die Task-Klassifikation muss deshalb mindestens Aufgabe, Datenklasse, Prozessphase und Kritikalität kombinieren.

2. Policy Gate

Vor der Modellwahl braucht der Router ein Policy Gate. Es entscheidet nicht, welches Modell am günstigsten ist, sondern welche Route überhaupt zulässig ist.

Typische Regeln:

• Personenbezogene Rohdaten dürfen nur über freigegebene Umgebungen laufen.
• Sanktions- und PEP-Kontexte brauchen strengere Protokollierung.
• Verdachtsnahe Hypothesen dürfen nicht automatisch als Befund ausgegeben werden.
• Bestimmte Tools sind nur nach Human Approval erlaubt.
• Hochkritische Fälle bekommen keinen Cache-Treffer ohne Kontextprüfung.

Hier berührt Agentic FinOps unmittelbar DORA, Auslagerungsmanagement, Informationssicherheit und Modellrisikomanagement. Seit dem 17. Januar 2025 ist DORA für den Finanzsektor anwendbar. Agentische KI, die produktive Prozesse unterstützt, ist damit nicht nur Innovation, sondern Teil der digitalen operationalen Resilienz.

3. Kosten- und Qualitätsentscheidung

Erst danach kommt die ökonomische Entscheidung. Sie lautet nicht “billigstes Modell”, sondern “günstigstes Modell, das die geforderte Qualität unter der erlaubten Policy erfüllt”.

Dafür braucht der Router Telemetrie:

• erwartete Tokenkosten
• historische Fehlerrate je Task
• Latenz je Modell
• Cache-Hit-Rate
• Eskalationsrate in Human Review
• Re-Run-Quote
• Anteil verworfener Antworten
• Qualität gegen Golden Datasets

Ohne diese Daten bleibt Routing Bauchgefühl. Mit ihnen wird Routing zu einer messbaren Betriebsentscheidung.

4. Audit Trail

Jede Route muss rekonstruierbar sein. Der Audit Trail darf nicht nur speichern, welches Modell geantwortet hat. Er muss zeigen:

• welche Aufgabe erkannt wurde
• welche Datenklasse vorlag
• welche Policy angewendet wurde
• welcher Schwellenwert überschritten oder unterschritten wurde
• welches Modell gewählt wurde
• ob ein Cache-Treffer genutzt wurde
• welche Kosten entstanden sind
• ob Human Review ausgelöst wurde
• welche Version von Prompt, Policy, Tool-Schema und Router-Regel aktiv war

Das ist der Punkt, an dem Agentic FinOps in AML-Observability übergeht. Kosten werden nicht mehr nachträglich erklärt. Sie werden Teil der Entscheidungsprovenienz.

Semantic Caching ist kein kostenloser Shortcut

Semantic Caching wirkt betriebswirtschaftlich verführerisch. Wenn eine sehr ähnliche Anfrage bereits beantwortet wurde, liefert der Cache die vorhandene Antwort zurück. Die LLM-Kosten fallen weg oder sinken deutlich.

Im FinCrime-Kontext ist genau das ambivalent.

Eine Standardfrage wie “Extrahiere Handelsregisternummer, Sitz und Rechtsform aus diesem öffentlichen Text” kann gut cachefähig sein. Eine Fallfrage wie “Bewerte die Risikosignale in dieser KYC-Akte” ist es nur unter strengen Bedingungen. Schon kleine Kontextänderungen können fachlich relevant sein: neuer wirtschaftlich Berechtigter, aktualisierte Sanktionstreffer, geänderte Risikoklasse, andere Jurisdiktion, neuer Adverse-Media-Hinweis.

Der Cache darf deshalb nicht nur semantisch ähnlich prüfen. Er braucht fachliche Cache Keys:

• Datenstand
• Dokumentversion
• Jurisdiktion
• Risikotypologie
• Fallstatus
• Policy-Version
• Modellversion
• Freigabestatus

Sonst spart ein System Tokens und produziert gleichzeitig veraltete Evidenz.

Die falsche Agentic FinOps-Kennzahl

Viele Agentic FinOps-Dashboards werden mit Kosten pro Modell, Kosten pro Nutzer, Kosten pro Token und Kosten pro Endpoint beginnen. Das ist verständlich, aber für FinCrime nicht ausreichend.

Die gefährlichste Kennzahl ist die isolierte Einsparquote.

Wenn ein Institut meldet, dass es 60 Prozent LLM-Kosten durch Routing reduziert hat, ist das allein keine gute Nachricht. Die relevante Frage lautet: Was ist mit Qualität, Fehlerquote, Eskalationen, Datenschutz, Time-to-Review und Auditierbarkeit passiert?

Ein bankfähiger Router muss deshalb gegen Qualitäts- und Kontrollmetriken laufen:

• Wurden komplexe Fälle fälschlich an schwächere Modelle geroutet?
• Sind risikoreiche Daten in nicht freigegebene Umgebungen gelangt?
• Haben Cache-Treffer veraltete oder unpassende Antworten wiederverwendet?
• Ist die Human-Review-Quote sinnvoll gesunken oder gefährlich verdrängt worden?
• Können Revision und zweite Linie die Router-Entscheidungen prüfen?

Agentic FinOps darf kein Anreizsystem werden, das teure Modelle vermeidet, obwohl der Fall sie fachlich braucht. Die bessere Zielgröße ist nicht niedrigster Verbrauch. Sie ist kontrollierte Wirtschaftlichkeit.

AgentOps, DecOps und DataOps greifen hier ineinander

Die Ops-Landkarte teilt sich in zwei Welten. Die etablierten Disziplinen haben bereits ihre anerkannten Referenzwerke, Metriken und Betriebsrituale. Die neuen KI-getriebenen Disziplinen entstehen dagegen noch in Preprints, Framework-Dokumentationen und produktionsnahen Erfahrungsberichten. Gerade deshalb ist es wichtig, sie nicht als lose Buzzword-Sammlung zu behandeln, sondern als Architekturgeschichte: Jede Ops-Disziplin stabilisiert einen anderen Teil des Systems.

Die Fundamente: DevOps und DevSecOps

DevOps ist der ältere Bruch mit der Trennung zwischen Entwicklung und Betrieb. Sein Kanon ist relativ stabil. Accelerate von Nicole Forsgren, Jez Humble und Gene Kim operationalisiert Softwarelieferfähigkeit über DORA-Metriken wie Deployment Frequency, Lead Time, Change Failure Rate und Mean Time to Restore. The Phoenix Project übersetzt dieselbe Betriebslogik in eine Organisationsgeschichte: Engpässe, ungeplante Arbeit, Silos, Schuldzuweisung und fehlende Flusskontrolle. Securing DevOps von Julien Vehent ergänzt die Sicherheitsdimension: Security muss in CI/CD, Infrastrukturtests und Deployment-Pfade eingebaut werden, nicht als spätes Freigaberitual am Ende.

Für FinCrime-Systeme ist das die Basisschicht. Ohne versionierte Deployments, automatisierte Tests, nachvollziehbare Änderungen und Security Gates wird jede darüberliegende AI- oder Decision-Schicht zur Blackbox.

Daten und Modelle: DataOps und MLOps

DataOps verschiebt dieselbe Betriebsdisziplin auf Datenflüsse. Fundamentals of Data Engineering von Joe Reis und Matt Housley ist hier ein praktischer Anker, weil es Daten nicht als Rohstoffromantik behandelt, sondern als Lifecycle: Ingestion, Transformation, Storage, Serving, Governance und Qualität. Für AML, Fraud und KYC ist das entscheidend. Ein Agent, der auf schlechte, verspätete oder unprovenierte Daten zugreift, produziert keine Intelligenz, sondern beschleunigte Unsicherheit.

MLOps setzt eine Ebene später an. Designing Machine Learning Systems von Chip Huyen verschiebt den Blick weg von Modellmathematik hin zu Produktionssystemen: Feature Stores, Trainingsdaten, Drift, Monitoring, Latenz, Durchsatz, Feedback Loops und Retraining. Im FinCrime-Kontext wird daraus die Frage: Welche Modellentscheidung ist noch gültig, wenn sich Typologien, Kundendaten, Sanktionslisten oder Betrugsmuster verändern?

Fachliche Logik: DecOps

DecOps oder DecisionOps hat seine theoretischen Wurzeln im Domain-Driven Design. Eric Evans’ Domain-Driven Design ist hier das schwere, aber zentrale Referenzwerk: Die fachliche Sprache muss im Modell selbst sichtbar werden. Für FinCrime heißt das: Verdacht, Typologie, Risikofaktor, wirtschaftlich Berechtigter, PEP-Treffer, False Positive und EvidencePackage dürfen nicht nur Labels in Tickets sein. Sie müssen als Domänenbegriffe mit Zuständen, Regeln und Verantwortlichkeiten modelliert werden.

Die operative Brücke liefert DMN. Real-World Decision Modeling with DMN von James Taylor und Jan Purchase zeigt, wie Entscheidungen als Modelle geführt werden können: nicht nur als Code, sondern als fachlich lesbare, versionierbare und ausführbare Entscheidungslogik. Genau dort liegt der DecOps-Kern für AML-Szenarien, KYC-Schwellen, Eskalationsregeln und Sanktionsprüfungen.

Kostenkontrolle: FinOps

FinOps entsteht aus der Ökonomie variabler Infrastruktur. Cloud FinOps von J.R. Storment und Mike Fuller beschreibt, wie Engineering, Finance und Business gemeinsam Cloud-Kosten steuerbar machen. Der entscheidende Punkt ist kulturell: Kosten werden nicht nachträglich vom Controlling erklärt, sondern als laufende Engineering-Information sichtbar gemacht.

Agentic FinOps erbt dieses Muster, aber die Einheit ändert sich. Es geht nicht mehr nur um Instanzen, Speicher oder Netzwerk. Es geht um Kosten pro Task, Prompt, Retrieval, Tool-Call, Cache-Treffer, Human Review und auditierbarem Ergebnis.

Die Frontier: AgentOps und Agentic FinOps

AgentOps und Agentic FinOps haben noch keinen stabilen Buchkanon wie DevOps oder MLOps. Der Stand der Technik entsteht derzeit stärker in Papers, Referenzimplementierungen, Framework-Dokumentationen und produktionsnahen Patterns. Papers zu ReAct, Tool Use, LLM-Observability, Evaluation und agentischen Workflows definieren den Forschungsrand. Frameworks wie LangChain, LangGraph, OpenTelemetry-GenAI-Instrumentierung, vLLM-Router, LiteLLM oder andere Agent-Builder prägen, wie Tracing, Memory, Tool-Calling, Budgetgrenzen und Human-in-the-Loop tatsächlich umgesetzt werden.

Das macht diese Disziplinen nicht weicher. Es macht sie riskanter. Wer heute AgentOps betreibt, muss mit Wissen arbeiten, das noch nicht kanonisiert ist. Wer heute Agentic FinOps betreibt, muss Kosten, Qualität, Modellrisiko und Governance verbinden, bevor die Literatur einen sauberen Standard liefert.

Im FinCrime-Betrieb greifen diese Disziplinen deshalb ineinander:

• DataOps stellt sicher, dass die Datenqualität, Schemata und Lineage der Eingaben stimmen.
• DecisionOps oder DecOps verwaltet fachliche Regeln, Schwellen, Risikologiken und Freigaben als versionierte Entscheidungsartefakte.
• MLOps kontrolliert Modellversionen, Drift, Evaluationsdaten und Deployment.
• AgentOps beobachtet Tool-Calls, Reasoning-Pfade, Abbruchbedingungen, Speicher und Laufzeitverhalten.
• Agentic FinOps verbindet diese Spuren mit Kosten, Budgets, Attribution und Unit Economics.

Der Router sitzt genau an der Kreuzung. Er konsumiert Datenqualität, wendet Entscheidungsregeln an, wählt Modelle, begrenzt Agenten und erzeugt Kosten. Deshalb gehört er nicht allein dem Plattformteam. Er braucht gemeinsame Ownership von Engineering, Fachbereich, Compliance, Informationssicherheit, Einkauf, Datenschutz, Risikocontrolling und Revision.

Das klingt schwerfällig. In Banken ist es aber die realistische Alternative zu unkontrollierter Automatisierung.

Ein Zielbild: der FinCrime Routing Ledger

Die technische Zielarchitektur sollte nicht beim Router enden. Sie braucht einen Routing Ledger.

Der Ledger speichert nicht die gesamte Modellantwort als Ersatz für Case Management. Er speichert die prüfbare Entscheidungsspur:

Decision Record · Routing LedgerRoutingDecision
  task_type: kyc_risk_summary
  data_class: personal_confidential
  policy_version: fincrime-ai-policy-v3
  prompt_version: kyc-summary-v12
  model_candidate_set: [local-small, hosted-medium, hosted-frontier]
  selected_route: hosted-medium-eu
  confidence: 0.91
  cache_status: bypassed
  reason: high_context_specificity
  estimated_cost: 0.18 EUR
  actual_cost: 0.21 EUR
  human_review_required: true
  decision_time: 2026-05-24T09:42:00Z

Der konkrete Datensatz kann anders aussehen. Entscheidend ist das Prinzip: Eine Modellroute ist ein fachlich relevanter Decision Record.

In einem reifen FinCrime-System wird dieser Record mit Fallereignissen, Datenprovenienz, Tool-Calls, Evaluationsmetriken und Review-Entscheidungen verbunden. Dann lässt sich später nicht nur sagen, was der Agent geschrieben hat. Es lässt sich zeigen, warum das System ihm diese Aufgabe, dieses Modell, diese Daten und diese Grenze gegeben hat.

Was Institute jetzt prüfen sollten

Agentic FinOps beginnt nicht mit einem Toolkauf. Es beginnt mit einer Inventur der agentischen Kosten- und Risikopunkte.

Fünf Fragen reichen für den ersten Stresstest:

1. Welche FinCrime-Prozesse nutzen bereits LLMs, auch informell über Fachbereichstools, Copilots oder manuelle Prompts?
2. Welche Datenklassen dürfen in welche Modellumgebungen, und ist diese Regel maschinenlesbar?
3. Gibt es eine freigegebene Taxonomie für Tasks, die ein Router erkennen soll?
4. Werden Kosten pro fachlichem Ergebnis gemessen oder nur technische Verbrauchswerte?
5. Kann eine unabhängige Kontrollfunktion Routing-Entscheidungen nachvollziehen?

Wenn eine Bank diese Fragen nicht beantworten kann, ist Semantic Routing noch keine Optimierung. Dann ist es ein nicht dokumentierter Steuerungsmechanismus.

Die Watchdog-These

Semantic Routing wird im FinCrime-Betrieb oft als Effizienztechnik eingeführt werden. Das ist der falsche Einstieg.

Der Router entscheidet nicht nur über Kosten. Er entscheidet über Datenwege, Modellzuständigkeit, fachliche Eskalation, Cache-Wiederverwendung, Tool-Zugriff und Auditierbarkeit. Damit wird er Teil des internen Kontrollsystems.

Agentic FinOps ist deshalb nicht die Disziplin, die LLM-Rechnungen nachträglich erklärt. Es ist die Disziplin, die verhindert, dass autonome Systeme unbemerkt wirtschaftliche, regulatorische und fachliche Entscheidungen treffen.

Der sparsame Agent ist nicht automatisch der bessere Agent. Der bessere Agent ist der, dessen Kosten, Qualität und Grenzen beweisbar betrieben werden.

Transparenz: Konzept, Struktur und Formulierung wurden aus einem bereitgestellten Gemini-Share mit Codex weiterentwickelt. Regulatorische und technische Eckdaten wurden gegen offizielle beziehungsweise technische Primärquellen geprüft.

Agentic FinOps · Agentic AI · AML Observability · Semantic Routing · RegTech Architecture · FinOps