Welche Infrastruktur brauchen Sie, um KI-Agenten in Production zu deployen?

Die meisten Teams unterschätzen, was zwischen einem funktionierenden Prototyp und einem Production-Agenten liegt. Die Stack-Schichten — und was jede davon leistet.

Für CTOs, VP Engineering und IT-Verantwortliche · 14 Min. Lesezeit

Die Lücke zwischen Prototyp und Production

Ein KI-Agent in einem Notebook oder einer Demo-Umgebung braucht im Wesentlichen eines: ein LLM und ein paar Tool-Definitionen. Das reicht, um zu überzeugen.

Ein KI-Agent in Production braucht deutlich mehr. Nicht, weil der KI-Teil schwerer ist — sondern weil Production Anforderungen mit sich bringt, die nichts mit dem Modell zu tun haben: Concurrency, State-Management, Fehlerbehebung, Kostenkontrolle, Sicherheit, Compliance und Audit-Trails.

Zur Infrastruktur-Komplexität

Entwickler bauen oft sechs oder sieben getrennte Dienste für einen einfachen Production-Agenten: Vektordatenbank für Speicher, Object Storage für Dateien, Server für Tool-Ausführung, Orchestrierung, Queue-System, Monitoring, Gateway. Das Stack-Problem ist real — und der Grund, warum die meisten Agenten nicht über die Pilotphase hinauskommen.

Dieser Artikel beschreibt den vollen Infrastruktur-Stack für einen KI-Agenten in Production, erklärt jede Schicht und die praktischen Trade-offs zwischen Eigenbau und Managed Platform.

Die fünf Infrastruktur-Schichten

Ein Production-KI-Agent sitzt auf fünf voneinander abhängigen Schichten. Jede kann zum Flaschenhals werden. Keine ist optional.

1. Modelle & Routing — Zugang zu einem oder mehreren LLMs, Routing nach Aufgabentyp, Kosten oder Latenz. Beispiele: GPT-4o, Claude, Mistral, Gemini + Routing-Logik.
2. Orchestrierung — Multi-Step-Workflows: Aktionen sequenzieren, Tool-Aufrufe, Retry-Logik, Verteilung auf Sub-Agenten, Workflow-State. Beispiele: LangGraph, AutoGen, CrewAI, Temporal.
3. Speicher & Daten — Kontext kurzfristig (Session) und langfristig (Wissensbasen, vergangene Interaktionen, strukturierte Geschäftsdaten). Redis, Vektordatenbanken (Pinecone, Weaviate), CRM/ERP über Konnektoren.
4. Serving & Scaling — Gleichzeitige Requests, Last, Verfügbarkeit. Docker, Kubernetes oder Managed-Äquivalente, Queues für Async (Redis, SQS, RabbitMQ).
5. Governance & Observability — Jede Ausführung nachverfolgen, Zugriffskontrolle, Richtlinien, Audit-Trail. OpenTelemetry + Langfuse oder Arize, RBAC, strukturierte Audit-Logs.

Schicht 1 — Modelle und Routing

Die Modellwahl ist weniger entscheidend als viele denken. 2026 performen GPT-4o, Claude, Mistral und Gemini in den meisten Enterprise-Aufgaben gut. Wichtiger ist: behandelt Ihr Stack das Modell als austauschbar?

Multi-Modell-Routing ist in reifen Deployments Standard. Fallback-Logik ist in Production Pflicht. Lock-in-Risiko: Architektieren Sie die Modellschicht von Anfang an swappable (Abstraktion oder Multi-Provider-Gateway).

Schicht 2 — Orchestrierung

Hier entstehen die meisten Production-Ausfälle. Die Orchestrierung muss abdecken: Sequenz-Management, zuverlässige Tool-Aufrufe mit Backoff, State-Persistenz für lange Workflows, Human-in-the-Loop, Terminierungsbedingungen, Fehlerpropagation. LangGraph für stateful Agenten, Temporal für langlebige Workflows, AutoGen für private LLM-Deployments (z. B. Azure).

Schicht 3 — Speicher und Datenzugriff

Ohne Speicher ist der Agent ein zustandsloser Request-Prozessor. Drei Speichertypen: Session (Redis), semantisch (Vektordatenbanken, RAG), strukturierte Daten (CRM, ERP). Daten-Souveränität: In regulierten Branchen ist sovereign deployment (eigene VPC/On-Premise) oft der einzige Weg. Architektieren Sie die Datenschicht entsprechend von Tag eins.

Schicht 4 — Serving und Scaling

Containerisierung zuerst (Docker). Stateless vs. Stateful: Stateless für FAQs, Klassifikation, Single-Step → Serverless (Lambda, Cloud Run). Stateful für Multi-Turn, lange Workflows, Agenten mit Speicher → Container-Orchestrierung (ECS, Kubernetes). Queues für asynchrone Workloads (Redis, SQS, RabbitMQ).

Schicht 5 — Governance und Zugriffskontrolle

RBAC, IT-Validierung vor Production, vollständiger Audit-Trail (Modellversion, Input/Output, Tool-Aufrufe, Freigaben, Identität, Zeitstempel), Einhaltung der Datenresidenz (DSGVO, EU AI Act). Governance ist keine Nachrüst-Option.

Build vs. Buy

Eigenbau: volle Kontrolle, typisch 3–6 Monate bis production-ready, laufende Wartung. Sinnvoll bei sehr spezifischen Anforderungen, regulierten Umgebungen, großen Teams. Managed Platform: Infrastruktur aus einer Hand, schnellere Time-to-Production. Prüfen: Daten-Souveränität, Modell-Flexibilität, echte Audit-Fähigkeit.

Checkliste vor dem Deploy

Modelle, Orchestrierung, Speicher, Serving, Governance, Observability, Sicherheit — alle Punkte konfiguriert und getestet.

Alle fünf Schichten von Tag eins

Origin 137 stellt Modelle, Orchestrierung, Governance und Observability in einer Plattform bereit — Managed Cloud, Private Cloud oder On-Premise. Deployen Sie Ihren ersten Agenten in Tagen, nicht in Monaten.

Kostenlos starten — keine Karte erforderlich

Quellen

Shakudo, Madrona, Machine Learning Mastery, Netguru, Fast.io (2025–2026).