Die meisten KI-Demos sterben auf dem Weg in die Produktion. Das Modell, das im Loom-Video begeistert hat, fällt in dem Moment auseinander, in dem ein echter Nutzer sich vertippt, die Latenz montags um 8 Uhr hochschießt, das gehostete LLM Sie mitten im Monat rate-limitet oder die Rechnung eintrifft.
In den letzten zwei Jahren habe ich KI ausgeliefert, statt sie vorzuführen. RogueAI.de ist mein persönliches KI-Labor — über 20 Systeme, durchgängig auf Hetzner Deutschland gebaut: RAG-Pipelines, KI-Agenten, LoRA-Fine-Tuning, Dokumenten-KI, ein Meeting-Copilot und Offline-Sprachdiktat. Keine Kundenarbeit, kein kommerzielles Produkt. Echte Systeme, die heute in Produktion laufen.
Hier ist, was mich das tatsächlich gelehrt hat — über Infrastruktur, Kosten, UX und die Lücke zwischen einem funktionierenden Prototyp und einem funktionierenden Produkt.
Warum ich 20+ produktive KI-Apps gebaut habe, statt eine zu polieren
Der konventionelle Rat lautet „bau eine Sache richtig gut“. Zwei Jahre lang habe ich das Gegenteil getan. Eine Anwendung lehrt Sie eine Domäne. Zwanzig lehren Sie die Muster, die über Domänen hinweg tragen — und diese Muster sind das eigentliche wiederverwendbare Kapital.
Ein Renten-Rechner ist strukturierte numerische Daten mit regulatorischen Vorgaben — Monte-Carlo-Simulationen über Tausende von Marktpfaden. Eine Steuer-Dokumenten-KI ist OCR plus Extraktion plus regelbasierter Abgleich. Ein Meeting-Copilot nimmt Audio-Transkripte auf und denkt im Nachhinein über sie nach. Ein Sprachdiktat-Tool verarbeitet Echtzeit-Sprache unter striktem Latenzbudget. CompliBot — 38 Endpunkte — verarbeitet Tausende von Dokumenten über Compliance-Workflows hinweg. Jedes ist eine andere Form von Engineering-Problem.
Die Datenformen unterscheiden sich. Die Nutzererwartungen unterscheiden sich. Die Latenztoleranzen unterscheiden sich. Was beim zwanzigsten Build konstant bleibt, ist die Architektur. Es läuft auf eine kleine Zahl von Entscheidungen hinaus, die man einmal trifft und für immer wiederverwendet.
Die Infrastruktur-Entscheidung hinter dem Ausliefern produktiver KI: Hetzner Deutschland
Jedes RogueAI-System läuft auf Hetzner Deutschland. Nicht AWS, nicht GCP. Der Grund ist keine Ideologie — es sind Unit Economics und EU-Datenresidenz.
Der typische SaaS-Stack — Cloud-LLM, Cloud-Vector-Store, alles Cloud — verbrennt schnell Geld. Eine RogueAI-Anwendung auf einem Hetzner-VPS kostet pro Monat weniger als die äquivalente AWS-Konfiguration pro Tag. Über 20+ Anwendungen hinweg ist das der Unterschied zwischen einem tragfähigen Labor und einem unbezahlbaren.
Die Architektur ist über das Portfolio hinweg konsistent: Docker-Container in isolierten Netzwerken, Caddy als Reverse Proxy, automatisierte Health-Checks mit automatischer Wiederherstellung, Modelle lokal über Ollama oder whisper.cpp deployt, wo die Latenz es verlangt, und nirgendwo US-Cloud-APIs im Datenpfad. (Mehr zum deutschen Mittelstands-Audit-Kontext, dem das dient: Cybersecurity-Beratung in Deutschland.)
Es gibt Trade-offs. Kein Managed Kubernetes. Kein Managed Embedding-Service. Postgres provisionieren Sie selbst. Bei kleiner bis mittlerer Skalierung sind diese Einschränkungen Features — sie erzwingen architektonische Einfachheit.
Wann gehostete LLMs beim Ausliefern produktiver KI helfen — und wann nicht
Die größte Kostenvariable ist der LLM-Aufruf. Zehn Dollar pro Million Tokens klingt günstig, bis ein einzelner Nutzer an einem Nachmittag Millionen von Tokens verbrennt.
Ich teile RogueAI-Anwendungen in drei Klassen:
- Gehostetes LLM (Anthropic, OpenAI): für Anwendungen, bei denen Nutzer höhere Latenz tolerieren und der Wert pro Aufruf hoch ist. Dokumenten-KI-Workloads — Steuerdokumente, komplexe Verträge — passen hierher. Qualität zählt mehr als Kosten.
- Self-hosted Ollama: für Anwendungen, bei denen das Volumen hoch und die Komplexität pro Aufruf niedrig ist. Sprachdiktat läuft vollständig auf lokalen Modellen, weil der Nutzer eine Antwort im Sub-Sekunden-Bereich erwartet und allein der Netzwerk-Roundtrip die UX kaputtmachen würde.
- Hybrid: für Anwendungen, bei denen die ersten 90 Prozent der Arbeit mit einem kleinen selbst gehosteten Modell erledigt werden können und nur Randfälle ein gehostetes LLM brauchen. Meeting-Copilots passen hierher — das lokale Modell übernimmt den Großteil der Zusammenfassung, das gehostete LLM die Anfragen, bei denen Qualität am meisten zählt.
Die architektonische Lektion: Verpflichten Sie sich nie auf einen einzigen LLM-Anbieter. Bauen Sie die Anwendung so, dass das LLM eine austauschbare Komponente ist. Ich habe RogueAI-Anwendungen mehr als einmal zwischen gehostet und selbst gehostet verschoben, und die Kosten dafür hängen vollständig davon ab, ob die Abstraktion von Anfang an richtig war.
Kostenmanagement ist ein Feature produktiver KI, keine Pflichtübung
Als ich zum ersten Mal eine RogueAI-Anwendung ohne Token-Limits pro Nutzer auslieferte, erzeugte ein einziger fehlgeleiteter Nutzer eine Rechnung, die größer war als das fiktive Monatsabo des Kunden. Kostenexplosion ist kein Bug — es ist ein fehlendes Feature.
Jede RogueAI-Anwendung hat jetzt:
- Token-Budgets pro Nutzer — pro Session, pro Minute, pro Tag
- Aggressives Caching auf der Prompt- und auf der Embedding-Ebene
- Harte Obergrenzen, die laut scheitern statt teuer zu scheitern
- Echtzeit-Kosten-Dashboards, die Anomalien innerhalb von Minuten sichtbar machen
Das ist unglamouröse Arbeit. Es ist auch das, was ein Produktionssystem von einem Jugend-forscht-Projekt trennt. Jeder Prototyp, der in die Produktion übergeht, wird zuerst an Kostendisziplin erwachsen, bevor er an irgendetwas anderem erwachsen wird.
RAG-Architektur für produktive KI: Was funktioniert hat, was nicht
Retrieval-Augmented Generation ist die Standardarchitektur für KI über Dokumente. CompliBot — 38 Endpunkte, die Tausende von Dokumenten verarbeiten — ist das größte RAG-System im RogueAI-Portfolio, und mehrere andere Systeme nutzen leichtgewichtigere RAG-Muster. Was ich dabei über Compliance-Dokumente, Steuerformulare, Meeting-Transkripte und CRM-Datensätze hinweg gelernt habe:
- Chunking zählt mehr als das Embedding-Modell. Zwei Stunden in die Abstimmung der Chunk-Grenzen für einen bestimmten Dokumenttyp zu stecken, bringt bessere Ergebnisse als das Upgrade von einem kostenlosen auf ein kostenpflichtiges Embedding-Modell.
- Aktualität schlägt Recall in den meisten Domänen. Nutzer hätten lieber eine etwas weniger präzise Antwort aus dem Dokument dieser Woche als eine perfekt präzise Antwort aus einem Dokument, das überholt ist.
- Zitate sind das Produkt, kein Feature. Eine RAG-Anwendung, die ihre Quellen nicht zeigen kann, ist in einer regulierten Branche nicht deploybar. Bauen Sie das Rendering der Zitate, bevor Sie das Rendering der Antwort bauen.
- Hybrides Retrieval (semantisch + Keyword) gewinnt. Semantische Suche allein verfehlt durchweg Exakt-Match-Abfragen, die Nutzer tatsächlich tippen. Keyword-Suche allein verfehlt paraphrasierte Abfragen. Zusammen decken sie beide ab.
Für RAG ist das Einfachste, das funktioniert, meist die richtige Antwort: PostgreSQL mit pgvector, lokale oder gehostete Embeddings, hybrides Retrieval und das Rendering der Zitate als erstklassige Komponente.
LoRA-Fine-Tuning als Werkzeug für produktive KI
Eine Handvoll RogueAI-Anwendungen nutzt LoRA-Fine-Tuning statt fertiger gehosteter Modelle. Das Muster, das funktioniert hat: ein kleines, spezialisiertes LoRA für eine enge Aufgabe trainieren — Bildgenerierung in einer bestimmten Markenstimme, Inhaltsklassifizierung mit einer Nischentaxonomie, strukturierte Extraktion für eine Dokumentenfamilie — statt zu erwarten, dass ein Allzweckmodell das gut erledigt.
Fine-Tuning passt in eine bestimmte Nische: wenn die Kosten pro Aufruf eines gehosteten LLM für das Volumen zu hoch sind und die Aufgabe eng genug ist, dass ein kleines Modell ein großes erreichen kann — die richtigen Trainingsdaten vorausgesetzt. Es passt nicht überall, aber wo es passt, verändert es die Unit Economics grundlegend.
Multimodale Muster beim Ausliefern produktiver KI
Zwei RogueAI-Anwendungen verarbeiten Nicht-Text-Eingaben. Die Muster unterscheiden sich stark voneinander:
- Sprachdiktat ist Echtzeit und vollständig offline. Das Latenzbudget liegt bei 200 ms End-to-End, bevor der Nutzer es merkt. Self-hosted whisper.cpp ist Pflicht; allein das Netzwerk verbraucht zu viel des Budgets. Das Electron-Tray-App-Muster — Hotkey zum Starten des Diktats — funktioniert, weil das lokale Modell sich aufwärmen kann, während der Nutzer mitten im Gedanken ist.
- Meeting-Copilots arbeiten im Nachhinein. Das Latenzbudget beträgt Minuten statt Millisekunden. Hier verdienen gehostete LLMs ihre Kosten — Qualität zählt mehr als Geschwindigkeit.
Dokumenten-KI-Workloads — Steuerdokumente, Compliance-Dokumente, individuelle Batch-Pipelines — liegen dazwischen: Offline-Batch-Verarbeitung, bei der Durchsatz mehr zählt als Latenz. Die allgemeine Lektion für multimodale Arbeit: Wählen Sie zuerst Ihr Latenzbudget, dann das Modell. Drehen Sie diese Reihenfolge um, und Sie bekommen schöne Demos, die sich nicht ausliefern lassen.
UX-Muster, die über alle 20 produktiven KI-Apps hinweg funktioniert haben
Ein paar UX-Entscheidungen tragen über jede Anwendung hinweg, die ich ausgeliefert habe:
- Streaming-Antworten als Standard. Nutzer tolerieren drei Sekunden progressiven Text weit besser als drei Sekunden Spinner.
- Abgerufenen Kontext zeigen. Wenn die KI eine Dokumentfrage beantwortet, rendern Sie die Quell-Absätze darunter. Nutzer vertrauen Antworten, die sie überprüfen können.
- KI-Vorschläge opt-in machen, nicht opt-out. Ein Steuerdokument automatisch zu vervollständigen ist aufdringlich; einen „Zusammenfassen“-Button anzubieten ist es nicht.
- Immer den manuellen Weg anbieten. KI ist schneller, wenn sie funktioniert, aber jeder Nutzer braucht gelegentlich die Version mit dem deterministischen Tool. Machen Sie den KI-Weg nie zum einzigen Weg.
Das sind keine KI-Erkenntnisse. Es sind UX-Erkenntnisse. Der Großteil dieser Arbeit ist UX-Arbeit, die zufällig LLMs einbezieht.
Wo ich die Grenze gezogen habe: ausliefern vs. polieren
Die meisten RogueAI-Anwendungen habe ich auf „gut genug“ ausgeliefert, nicht auf „poliert“. Die Regel war einfach: Eine Anwendung, die ein echtes Problem heute zu 80 Prozent löst, schlägt eine, die es in sechs Monaten zu 95 Prozent löst.
Die Anwendungen, die am besten gealtert sind, sind die, die ich am schnellsten ausgeliefert und an denen ich iteriert habe. Die, die am schlechtesten gealtert sind, sind die, die ich vor dem Launch polieren wollte — als sie „fertig“ waren, hatte sich das Problem weiterbewegt.
Also liefern Sie auf 80 Prozent aus. Reden Sie mit den Leuten, die es nutzen. Verbessern Sie die Teile, die ihnen wirklich wichtig sind. Die anderen 15 Prozent Politur, die Sie sich vorgestellt haben, waren meist für Probleme, die niemand hatte.
Was ich beim nächsten Mal anders machen würde
Wenn ich RogueAI heute von Grund auf neu starten würde:
- Die Kostenkontroll-Schicht vor dem ersten KI-Aufruf bauen. Jedes Projekt, Tag eins.
- Bei jedem RAG-System standardmäßig auf hybrides Retrieval setzen. Rein semantische Suche hat mich zu oft gebissen.
- Auf eine einzige Observability-Schicht über alle Anwendungen hinweg standardisieren. Im Moment hat jede Anwendung ihre eigene Logging-Story; das Debugging auf Portfolio-Ebene ist schwerer, als es sein müsste.
- Mehr in Evaluations-Harnesses investieren, bevor skaliert wird. Die Anwendungen, die am einfachsten zu warten sind, sind die mit deterministischen Testfällen, die ich bei jedem Modellwechsel ausführen kann.
- Architekturentscheidungen dokumentieren, während ich sie treffe. Zwanzig Anwendungen später ist das Problem des institutionellen Gedächtnisses real.
Im Rückblick alles offensichtlich. Nichts davon war offensichtlich, bevor ich ein Dutzend Anwendungen ausgeliefert und beim Altern beobachtet hatte.
Das RogueAI-Portfolio als Beweis fürs Ausliefern produktiver KI
Ich habe RogueAI gebaut, um echte Arbeit zu erledigen, nicht um etwas zu beweisen. Aber das Portfolio wurde zum Beweis. Für Recruiter und Kunden, die wissen wollen, wie produktive KI tatsächlich aussieht, ist die Antwort: 20+ echte Anwendungen, die heute laufen — nicht noch ein Architektur-Foliensatz.
Wenn Sie 2026 produktive KI planen und pragmatischen Input von jemandem wollen, der viel davon ausgeliefert hat, ist das genau das, was ich tue.
Das RogueAI-Portfolio ist live unter rogueai.de — Fallstudien zu Rente, Steuerdokumenten, Sprache, Meeting-Copilot, Fine-Tuning und CRM-Workflows sind heute einsehbar. Für KI-Engineering-Mandate fragen Sie ein Review an. Siehe auch FwChange.com für Firewall-Change-Automatisierung.