Mittelständische Unternehmen stehen bei KI-Initiativen vor anderen Herausforderungen als Konzerne. Die Budgets sind kleiner, die Teams schlanker, und die Erwartungshaltung zwischen "das löst alles" und "das ist nur Hype" schwankt oft innerhalb einer Sitzung. Was es braucht, ist ein architektonischer Rahmen, der Pilot-Geschwindigkeit mit Produktions-Stabilität verbindet.
Der typische Fehler: zu früh auf Hyperscaler setzen
Viele erste KI-Projekte scheitern nicht an der Qualität des Modells, sondern an den laufenden Kosten. Eine RAG-Anwendung, die 5000 Euro pro Monat an Inference-Gebühren erzeugt, überlebt selten das erste Budget-Review. Dazu kommt der Daten-Abfluss in die USA — für viele B2B-Kunden aus regulierten Branchen ein No-Go.
Der pragmatische Einstieg läuft stattdessen über selbstgehostete, skalierbare Infrastruktur: ein Kubernetes-Cluster (on-premise oder bei einem europäischen Provider), ein Object Store wie MinIO für Dokumente, eine Postgres mit pgvector für Embeddings und ein Gateway-Layer, das zwischen lokalem Modell und Cloud-Fallback vermitteln kann.
Vier Komponenten, die zusammenspielen müssen
Der Stack, der sich in unseren Projekten bewährt hat, besteht aus vier Bausteinen: Einem Indexer, der Dokumente aus MinIO liest, chunked und als Embeddings in pgvector schreibt. Einem Gateway, das Modell-Requests bündelt, Rate Limits durchsetzt und Fallback-Logik implementiert. Einem Orchestrator, der je nach Anfrage den richtigen Agenten auswählt — Chat, Suche, Katalog, Download. Und einem Frontend-Widget, das per iframe in bestehende Webseiten eingebettet werden kann.
Die Trennung ist nicht akademisch. Jede dieser Komponenten entwickelt sich in unterschiedlichem Tempo weiter, und jede hat ein eigenes Sicherheits- und Compliance-Profil. Ein monolithischer Ansatz zwingt alle in das gleiche Kostenmodell und Release-Zyklus.
Vom Pilot zur Produktion
Der Übergang vom Pilot zur Produktion scheitert oft an der Frage: "Wer betreibt das im Alltag?" Ohne klare Antwort landet das Projekt bei dem, der es gebaut hat — und wird mit dem ersten Personalwechsel zur technischen Schuld.
Die saubere Antwort ist eine GitOps-Pipeline mit ArgoCD: Jede Änderung am System ist ein Commit, jedes Release ein Tag, jeder Rollback ein git revert. Das senkt die Anforderungen an das Betriebsteam dramatisch und macht das System unabhängig von einzelnen Personen.
Was als Nächstes kommt
Im nächsten Beitrag zeigen wir, wie diese Architektur in einem konkreten Kundenprojekt zur Anwendung kam — inklusive der Stolpersteine, die wir nicht vorhergesehen hatten.