Open-source KI-Finanzberater: Investitionen und Schulden managen ohne Cloud-Datenübertragung

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. Ich entwickle produktive Agenten-KI-Systeme für B2B-Kunden in der DACH-Region auf Basis von Claude, Supabase, n8n, Doppler und selbst gehostetem Postgres. In der Praxis zeigt sich immer wieder: Finanzabteilungen wollen Investitionen und Verbindlichkeiten KI-gestützt steuern – aber DSGVO und NIS2 schließen Cloud-basierte Lösungen faktisch aus.

Warum ein KI-Finanzberater ohne Cloud zwingend ist

Für die meisten regulierten Unternehmen in Deutschland, Österreich und der Schweiz ist es undenkbar, Kontodaten oder Finanztransaktionen über SaaS-Tools wie Plaid oder Tink in die Cloud zu übertragen. Bereits verschlüsselte API-Aufrufe werden von Compliance-Teams abgelehnt. Die einzige stabile Lösung: Open-source, vollständig selbst gehostete KI-Pipelines, die alle Daten im eigenen Perimeter halten.

Architektur: Open-source und auf den eigenen Servern

SaaS? Nicht zulässig

Externe Lösungen bedeuten Kontrollverlust. In meinen DACH-Projekten ist die Vorgabe eindeutig: "Keine Cloud, keine externen LLM-Calls." Dies gilt sowohl für die Datenspeicherung als auch für KI-Inferenz.

Zentrale Komponenten für einen selbst gehosteten KI-Finanzberater

So läuft der Pipeline im Produktivbetrieb

1. Import von Bankumsätzen

Zugänge erfolgen per lokalen CSV/XML-Dateien oder direkt via Bank-API mit Zwei-Faktor-Authentifizierung. Beispiel-Workflow in n8n:

{
  nodes: [
    {
      type: "n8n-nodes-base.readBinaryFile",
      parameters: { filePath: "/data/inbox/bank.csv" }
    },
    {
      type: "n8n-nodes-base.csvParse",
      parameters: { delimiter: ";" }
    },
    {
      type: "n8n-nodes-base.postgres",
      parameters: {
        query: "INSERT INTO transactions (date, amount, description) VALUES ({{date}}, {{amount}}, {{description}})"
      }
    }
  ]
}

Alle Daten bleiben im eigenen Rechenzentrum. Für erhöhte Anforderungen wird auf Datenbankebene mit pgcrypto verschlüsselt.

2. Analyse der Transaktionen mit lokalem LLM

Für die KI-Analyse kommen ausschließlich lokal gehostete LLMs (z.B. Llama 3, Mistral via Ollama) zum Einsatz. Beispiel-Integration:

import ollama
from supabase import create_client

db = create_client("http://localhost:54321", "service_key")
transactions = db.table("transactions").select("*").execute()

for tx in transactions.data:
    prompt = f"Kategorisiere: {tx['description']}, Betrag: {tx['amount']}"
    result = ollama.chat(model="llama3", prompt=prompt)
    db.table("transactions").update({"category": result}).eq("id", tx["id"]).execute()

Der LLM sieht ausschließlich Daten, die lokal gespeichert sind – niemals Rohdaten außerhalb der Infrastruktur.

3. Automatisierte Empfehlungen zu Investitionen und Schulden

Ich setze RAG (Retrieval-Augmented Generation) ein: Transaktionshistorie wird mit SentenceTransformers vektorisiert, Embeddings landen in pgvector. Die lokale LLM generiert Empfehlungen auf Basis ähnlicher Muster.

from sentence_transformers import SentenceTransformer
import psycopg2
model = SentenceTransformer('all-MiniLM-L6-v2')
conn = psycopg2.connect(...)
cur = conn.cursor()
cur.execute("SELECT id, description FROM transactions")
embeddings = []
for row in cur.fetchall():
    emb = model.encode(row[1])
    cur.execute("UPDATE transactions SET embedding=%s WHERE id=%s", (emb.tobytes(), row[0]))
conn.commit()

Risikoanalysen zu Verschuldung und Zahlungsrückständen erfolgen automatisiert mit Warnmeldungen in der Benutzeroberfläche.

Sicherheit und Compliance: Was funktioniert in der Praxis?

Statische Sicherheitsprüfung in der LLM-Integration

In mehreren aktuellen Projekten traten SQL-Injection-Muster im LLM-generierten DB-Code auf. Semgrep und Bandit im CI/CD sind Pflicht. Beispiel für ein GitHub Actions-Workflow:

name: CI
on: [push]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Semgrep
        run: semgrep --config=python .
      - name: Run Bandit
        run: bandit -r .

Mindestens 20% der LLM-generierten Datenbanklogik erfordern nach der Prüfung manuelle Anpassung (eigene Erfahrungswerte).

DSGVO: Auditierbarkeit und keine externe Datenübertragung

Audit-Logs und – besonders im Finanzbereich – externe Sicherheitsprüfungen (z.B. mit gitleaks) sind Standard. Verarbeitung und Speicherung erfolgen ausschließlich auf eigenen Servern, keine Cloud, keine externen APIs. Damit erfüllen Sie DSGVO, BSI Grundschutz und Anforderungen der EU AI Act.

FAQ

Welche LLMs sind für den selbst gehosteten Betrieb geeignet?

Llama 3, Mistral, Falcon – alle können lokal betrieben werden, bei sorgfältigem Ressourcenmanagement.

Lässt sich ein Mobile-Client anbinden?

Ja, über Supabase oder FastAPI – jedoch nur innerhalb geschützter Netzwerke oder via VPN.

Wie werden KI-Empfehlungen validiert?

Mehrstufig: statische Codeanalyse, manuelle Überprüfung, Testpipelines mit synthetischen Daten vor Rollout.

Wie lange dauert die Einführung?

In der Regel 3–6 Wochen, falls Infrastruktur steht. Der Hauptaufwand liegt in der sicheren Integration und Dokumentation.

Wie reagieren Sie auf geänderte Compliance-Vorgaben?

Mit CI/CD und statischer Prüfung (Semgrep, Bandit) können Sicherheitsregeln kurzfristig angepasst werden.

In welcher Stufe Ihrer Pipeline treten im Produktivbetrieb die meisten Herausforderungen auf – Datenintegration, LLM-Inferenz oder Validierung der Empfehlungen? Ihr Erfahrungswert interessiert mich. Ich biete kostenfreie 30-Minuten-Stack-Audits für DACH-Unternehmen mit KI-Anforderungen im regulierten Umfeld. Schreiben Sie mir auf LinkedIn oder an @ger_dennis_ai.