Behind the Scenes:
Von 0 auf Produktion
Ein ehrlicher Bericht darüber, was gebaut wurde, was schiefging, und warum fünf Minuten Warten manchmal die einzige Lösung ist.
Was ist Beyond AI/FinCrime OS?
Beyond AI/FinCrime OS ist ein Open-Source-Projekt für FinCrime Compliance über föderative KI-Agenten. Das Ziel: Compliance-Aufgaben — Sanctions Screening, Horizon Scanning, OSINT-Recherche — nicht über einen monolithischen KI-Blob abzuwickeln, sondern über spezialisierte, unabhängig deploybare Agenten, die miteinander kommunizieren.
Sprint 1 ist der Sanctions Screener. Kein Luxus-Feature, sondern das Fundament: Bevor ein System behaupten darf, es mache Compliance, muss es zumindest in der Lage sein, einen Namen gegen Sanktionslisten zu prüfen.
Das Endergebnis läuft unter sanction.endvater.de/search. Eine Testabfrage für „Wladimir Putin“ liefert zwei Treffer mit Score 0.9 — einmal aus den Sanctions-Daten, einmal aus den PEP-Daten. „Max Mustermann“ liefert null Treffer. Beides wie erwartet.
Der Weg dorthin war — nennen wir es — lehrreich.
Der Stack
Lokal (Entwicklung)
| Komponente | Rolle |
|---|---|
FastAPI + uvicorn | API-Backend |
yente | OpenSanctions selbst-gehostet, Port 8100 |
ElasticSearch 8.15 | Index-Backend für yente |
Neo4j 5 Community | Knowledge Graph |
Ollama (kimi-k2.5:cloud) | LLM-Gateway, Claude API als Fallback |
Produktion (Hostinger KVM 2)
Ein einzelner Server: 8 GB RAM, 4 vCPU, 100 GB NVMe, Ubuntu 22.04. Kein Kubernetes, kein Managed Service, kein Cloud-Provider der einem monatlich einen Brief schickt. Nur ein VPS und Docker Compose.
Was diesen Server interessant macht: Er lief bereits. Darauf liefen schon Traefik v3 als Reverse Proxy, eine Neo4j-Instanz, Ollama mit einem Cloud-Relay-Modell, Chroma und weitere Services. Neu hinzugekommen sind für Beyond AI/FinCrime OS: ElasticSearch, yente und das FastAPI-Backend.
API-Endpoints
- GET /search?q=NAME Browser-Suche mit HTML + JSON
- POST /api/screen REST API für programmatischen Zugriff
- GET /api/status Health-Check
Netzwerk-Topologie
Docker-Compose-Projekte leben standardmäßig in ihrer eigenen Netzwerk-Blase. Das ist gut für Isolation, schlecht wenn man Services aus anderen Projekten wiederverwenden will. Da auf diesem Server bereits Traefik, Neo4j und Ollama aus anderen Projekten laufen, muss der beyond-ai-api-Container explizit in deren Netzwerke eingehängt werden.
Ein Container, vier Netzwerke. Das ist kein Designfehler, sondern die bewusste Entscheidung, geteilte Infrastruktur zu nutzen statt alles zu duplizieren.
RAM-Budget auf 8 GB
| Service | RAM | Status |
|---|---|---|
neo4j | ~1,0 GB | wiederverwendet |
ollama (kimi-k2.5:cloud) | ~0,3 GB | wiederverwendet |
chroma + openclaw + traefik | ~0,5 GB | wiederverwendet |
ElasticSearch | 1,0 GB | neu |
yente | ~0,4 GB | neu |
beyond-ai-api | ~0,2 GB | neu |
| OS + Docker | ~1,5 GB | basis |
| Gesamt | ~4,9 GB | ✅ |
ElasticSearch ist mit 1 GB Heap-Größe konfiguriert — das absolute Minimum, aber für den Use Case ausreichend. yente indiziert bei jedem Start die Datensätze neu in ES, das ist der teuerste Moment.
Die Probleme
Kein Produktions-Deployment läuft beim ersten Versuch durch. Wer das behauptet, lügt oder hat sehr kurze Deployments. Hier ist, was tatsächlich passiert ist:
Docker Desktop lief nicht
Bevor auch nur eine Zeile Code geprüft werden konnte: Docker Desktop war auf dem Entwicklungsrechner nicht aktiv. Kein Container, keine hilfreiche Fehlermeldung, nur stille Verweigerung.
Das Repository hatte kein Dockerfile
Das GitHub-Repo existierte, aber ohne die nötigen Build-Artefakte. Kein Dockerfile, keine requirements.txt, keine main.py. Diese mussten von Grund auf erstellt werden:
Das ist kein Bug, sondern der Zustand eines Projekts in einem frühen Sprint — die Infrastruktur wird zusammen mit dem Code entwickelt.
Falscher ENV-Variablenname bei yente
yente nimmt eine ElasticSearch-URL als Konfiguration entgegen. Die naheliegende Vermutung:
Funktioniert nicht. yente ignoriert diese Variable stillschweigend. Der korrekte Name:
Falsches yente Manifest-Format
yente benötigt ein Manifest, das die zu ladenden Datensätze beschreibt. Die index.json von OpenSanctions direkt zu referenzieren lag nahe — enthält sie doch Metadaten zu allen Datensätzen. Das Problem: Sie enthält keine direkt verwendbaren FtM-Entity-Ressourcen im erwarteten Format.
Falsches HTTP-Verb für yente /match
Die yente-Dokumentation erwähnt einen /match-Endpoint. Getestet mit GET, wie man es für eine Suche intuitiv erwartet. Funktioniert nicht. yente /match erwartet POST mit einem spezifischen FtM-Body:
schema meint hier nicht JSON-Schema, sondern den Entitätstyp — Person, Organization, Vessel.Datenindizierung dauert fünf Minuten
Beim ersten Start lädt yente die kompletten Datensätze herunter und indiziert sie in ElasticSearch. Das sind etwa 1,7 Millionen Entitäten. Das dauert.
Kein Fehler, keine Fehlermeldung, kein Fortschrittsbalken der Mut macht. Wer nicht weiß, dass das normal ist, fängt an, Container neu zu starten — was die Indizierung von vorne beginnen lässt.
Let’s Encrypt ACME-Challenge schlägt fehl
Das komplizierteste Problem. Traefik war so konfiguriert, dass globale HTTP→HTTPS-Redirects auf Entrypoint-Ebene aktiv waren:
Klingt vernünftig. Das Problem: Let’s Encrypt validiert neue Domains über HTTP-01-Challenges. Der ACME-Client fragt über HTTP an, bekommt einen 301 auf HTTPS zurück, folgt dem Redirect, landet bei einer 404, und die Challenge schlägt fehl.
Alle neuen Files mussten erst ins Repository
Klingt trivial, ist eine echte Stolperfalle: Der Server klont das GitHub-Repository. Was nicht committed und gepusht ist, existiert auf dem Server nicht.
Dockerfile, docker-compose.prod.yml, manifest.yml — alles lokal erstellt, lokal getestet, aber noch nicht im Remote-Repo.
Was am Ende läuft
Zwei Suchanfragen als Smoke-Test:
Putin steht auf EU-Sanktionslisten und ist als PEP klassifiziert.
Ebenfalls korrekt.
Die Endpoints sind erreichbar, SSL-Zertifikat von Let’s Encrypt wird über Traefik automatisch erneuert. Kein manueller Aufwand für Zertifikate.
Ausblick: Sprint 2 & Sprint 3
Horizon Scanning
Automatisiertes Monitoring von FATF-Veröffentlichungen, EU-Regulierungsentwürfen, BaFin-Rundschreiben. Das System erkennt neue Compliance-relevante Developments frühzeitig und bereitet sie strukturiert auf.
OSINT
Strukturierte Informationsgewinnung aus offenen Quellen für Enhanced Due Diligence. Negative News Screening, Corporate-Ownership-Graphen, Verbindungsanalyse.
Der gesamte Code ist öffentlich: github.com/endvater/beyond-ai
