40+ KI-Systeme: Was 2 Jahre Aufbau in einer Agentur lehren
15. März 2026
Seit 2022 bauen wir bei SUMAX KI-Systeme, die tatsächlich im Betrieb laufen. Nicht als Proof of Concept, nicht im Testbetrieb, sondern produktiv: täglich genutzt von echten Mitarbeitenden für echte Kundenprojekte.
Nach 40+ Systemen gibt es Muster, die immer wieder auftauchen.
Was wir unterschätzt haben
Wartung ist teurer als der Build. Ein System in zwei Wochen zu bauen ist machbar. Es drei Jahre am Laufen zu halten, mit sich ändernden APIs, neuen Modellversionen und wechselnden Anforderungen: das ist die eigentliche Arbeit. Wer KI-Systeme baut, ohne Betriebskosten einzuplanen, plant falsch.
Prompt-Änderungen sind Deployments. Wenn ein Prompt sich ändert, ändert sich das Verhalten des Systems. Das klingt trivial, ist es aber nicht. Wir behandeln jeden Prompt wie Code: Versionierung, Review, Test. Ohne das verliert man schnell den Überblick, warum ein System plötzlich andere Outputs liefert.
Kleine Modelle erledigen 70 % der Aufgaben. Die Versuchung ist groß, immer das stärkste Modell zu nehmen. In der Praxis übernimmt Claude Haiku bei uns Klassifikation, Extraktion, Tagging: schnell, günstig, zuverlässig. Opus und Sonnet kommen für strategische Synthesen und komplexe Analysen. Dieser Router spart monatlich mehrere hundert Euro API-Kosten.
Was funktioniert
Interne Tooling vor Kundenexposition. Wir haben fast alle Systeme zuerst intern eingesetzt, bevor wir sie für Kunden gebaut haben. Das erzeugt echtes Feedback, echte Nutzung, echte Fehlerbilder, keine Laborergebnisse.
Microservices mit klarer Zuständigkeit. Unser zentrales API-Gateway mit dedizierten Service-Endpoints pro Datenquelle ist die Entscheidung, die am meisten Zeit gespart hat. Jede neue KI-Anwendung muss keine eigene Datenbeschaffung bauen.
Dokumentation als Betriebsbedingung. Kein System wird deployed ohne eine strukturierte Beschreibung: Zweck, Input, Output, bekannte Einschränkungen. Das klingt bürokratisch, ist aber der einzige Weg, mit 40+ Systemen nicht den Überblick zu verlieren.
Was ich heute anders machen würde
Weniger Systeme, schneller. Die ersten 10 Systeme haben wir zu vorsichtig gebaut: zu viele Features, zu viel Abstraktionsschicht, zu wenig Betrieb. Ein simples System das läuft schlägt ein aufwändiges System das nicht deployed ist.