Der agentische KI-Stack

Abgrenzung

In diesem Artikel geht es um agentische KI-Stacks, hauptsächlich für Business Workflows.

Es geht nicht um alle anderen Arten von KI und es geht auch nicht um Coding Agents.

KI ist ein riesiges Feld, ich fokussiere mich hier rein auf KI-Agenten, die für Business Workflows eingesetzt werden können.

Begriffe

Nun geht es los:

Der agentische KI-Stack ist eine strategische Entscheidung

Ich bin ein Fan davon, das volle Potenzial aus KI herauszuholen. Als ich darüber nachdachte, einen agentischen KI-Stack für mein Beratungsgeschäft aufzubauen, war mir klar, dass ich ihn besitzen, nicht mieten wollte. Es ist wie mit einem Haus — ich will ein Business Asset. So kam ich zu Open Source. Aber ich bin kein Dogmatiker. Und ich bin auch kein großes Unternehmen.

Meine Motivation, diesen Artikel zu schreiben, war, zu verstehen, welche Arten von agentischem KI-Stack es gibt.

Nicht alles passt für jeden

Bevor man sich für einen agentischen KI-Stack entscheidet, muss man recherchieren, welche der Typen für die eigene Branche, die eigene Organisationsgröße, die eigene Art der Organisation, die eigene Strategie, die eigenen Mitarbeiter und Partner etc. geeignet sind.

Ein eigener agentischer KI-Stack lohnt sich auch nicht für alle Geschäftsbereiche. Es gibt Bereiche, die überall 0815-Standard sind — da kann man fertige Lösungen am Markt kaufen und diese integrieren.

In manchen Branchen gibt es allerdings keine Wahl, aufgrund von Regulierung oder hochsensiblen Daten oder Geschäftsgeheimnissen.

Man muss sich also selbst intensiv damit beschäftigen, welcher KI-Stack für einen in Frage kommt. Je nach Branche oder Unternehmensgröße entscheidet man sich für einen anderen KI-Stack. In die Entscheidungen fallen natürlich auch Kosten und wie schnell man Ergebnisse sehen will.

In sehr großen Konzernen kann es sogar sein, dass verschiedene Bereiche jeweils andere agentische KI-Stacks haben, weil die Anforderungen unterschiedlich sind.

Freiheit vs. Disziplin

Beim Recherchieren ist mir bewusst geworden, dass es sich in manchen Fällen auch im Spannungsfeld Freiheit vs. Disziplin bewegt. Je mehr Freiheit ich will, desto disziplinierter muss ich bei der Entwicklung und bei der Governance sein.

Es ist also ein Trade-off.

Der agentische KI-Stack bestimmt das Operating Model

Nach dem Lesen des Artikels wird Ihnen relativ schnell klar, dass der KI-Stack maßgeblich über das Operating Model, die Organisationsform und die Arbeitsweise entscheidet. Was das jeweils im Detail bedeutet, darauf gehe ich in späteren Artikeln noch ein. Heute geht es darum, dass Sie sich einen Überblick verschaffen, und Sie werden sehr schnell sehen, wo die Unterschiede liegen.

Keine Vendor-Empfehlungen

Ich habe ganz bewusst die Namen der vorhandenen Anbieter und Lösungen weggelassen. Sie müssen das selbst recherchieren. Ich arbeite für keinen Anbieter und habe da keinerlei Vorlieben.

Ich habe auch absichtlich keine Empfehlungen geschrieben. Es hängt wirklich von so vielen Faktoren ab. Das passt nicht alles in einen Artikel, das kann man nur in mehreren persönlichen Gesprächen gemeinsam herausfinden.

Fehler passieren

Es könnten sich Fehler eingeschlichen haben und ich freue mich, wenn Sie mich darauf hinweisen. Bitte helfen Sie mir, diesen Artikel zu verbessern. Vielen Dank!

Die 6 Architektur-Schichten eines agentischen KI-Stacks

Jede Schicht baut auf der vorherigen auf. Ohne Verständnis der unteren Schichten sind Entscheidungen in oberen Schichten nicht fundiert.

1

Infrastruktur

Definition und Zweck: Die Infrastruktur-Schicht ist die physische oder virtuelle Grundlage, auf der alle anderen Schichten operieren. Sie beantwortet die Frage: „Wo laufen die GPUs, die die Modelle berechnen?"

Infrastruktur stellt Rechenleistung, Speicher und Netzwerk-Konnektivität bereit. Sie ist das Fundament.

Was gibt es:

• Cloud — Hyperscaler (US): Full-Stack-Cloud mit GPU-Instanzen, global verfügbar
• Cloud — Hyperscaler (EU): EU-Regionen verfügbar
• Sovereign Cloud: Daten in EU, DSGVO-konform
• GPU-Spezialisten: GPU-optimierte Infrastructure, oft günstiger
• Serverless GPU: Pay-per-use, keine Infrastruktur-Verwaltung
• Lokale Hardware: Eigene Server im Rechenzentrum
• Eigene lokale Hardware ohne Server

Wichtig:

Infrastruktur bestimmt Datenlokation (On-Prem vs. Cloud), Skalierbarkeit (Cloud Burst) und Compliance (DSGVO, BaFin, Souveränität). Eine falsche Infrastruktur-Entscheidung ist später teuer zu korrigieren.

2

Model Serving — wie Modelle gehostet werden

Definition und Zweck: Model Serving ist die Software-Schicht, die KI-Modelle lädt, verwaltet und Inference-Anfragen bedient. Sie ist „das Gehirn" der KI — ohne Model Serving gibt es keine Intelligenz.

Model Serving stellt Modelle als Service bereit — mit APIs, die von Agents aufgerufen werden können. Es verwaltet Modell-Versionen, Batch-Größen und Performance-Optimierung.

Was gibt es:

Proprietär

• API: Frontier Models — beste Performance, keine eigene Infrastruktur
• Enterprise APIs: Enterprise-Features, Compliance-Zertifizierungen
• Self-Hosted Enterprise Serving: High-Performance, Enterprise-Support

Open-Source / Open-Weight

• API (gehostet): Open-Weight Models — Modelle offen, Hosting beim Anbieter
• Model Marketplaces: viele Modelle, pay-per-use
• Self-Hosted Inference: volle Kontrolle, eigene Infrastruktur

Wichtig:

Model Serving bestimmt welche Intelligenz verfügbar ist, wie schnell Antworten kommen und wo Daten verarbeitet werden. Task-Model-Matching bedeutet, dass nicht jede Aufgabe das größte und teuerste Modell braucht. Man ordnet jeder Aufgabe das passende Modell zu. Das reduziert Kosten und verbessert Performance. Die Voraussetzung dafür ist, dass man versteht welcher Task welche Art von Modell benötigt.

3

Agent Runtime

Definition und Zweck: Agent Runtime ist die Ausführungsumgebung für KI-Agenten. Sie kann aus folgenden Dingen bestehen, wobei nicht alle vorhandenen Agent Runtimes alle Features abdecken:

• Process Management: Agents starten, stoppen, persistent betreiben. Lifecycle von Initialisierung bis Beendigung.
• State Management: Zustand eines laufenden Agents über Sessions hinweg persistent halten. Checkpointing bei Unterbrechungen.
• Durable Execution: Jeden Ausführungsschritt persistent speichern. Bei Abbruch, Fehler oder Unterbrechung exakt dort fortsetzen wo der Agent war.
• Context Management: Steuert was in das Context Window des Modells geht. Conversation History, relevanter Kontext, Zusammenfassungen.
• Sandboxing: Isolierte Ausführungsumgebung pro Agent. Code-Ausführung, Dateizugriff und Commands ohne Risiko für Produktivsysteme.
• Tool Integration: Externe Systeme als aufrufbare Funktionen registrieren. APIs, Datenbanken, Dateisysteme, Browser, MCP-Server. Credential Management und Scoped Permissions pro Agent.
• Skill System: Wiederverwendbare Lösungsmuster aus vergangenen Aufgaben speichern, durchsuchbar machen und bei neuen Aufgaben anwenden. Der Agent lernt aus seiner eigenen Arbeit.
• Multi-Agent Coordination: Delegation, Parallelisierung, Kommunikation zwischen Agents, geteilte Task-Listen. Subagents für sequentielle Teilaufgaben, Agent Teams für parallele Workstreams.
• Self-Evaluation: Agent definiert Erfolgskriterien, evaluiert eigene Ergebnisse, iteriert bis Kriterien erfüllt.
• Message Routing: Kommunikation mit Usern und externen Systemen über verschiedene Kanäle.
• Scheduling: Zeitgesteuerte, eventbasierte oder durch andere Agents getriggerte Ausführung.
• Model Routing: Steuert welches Modell für welchen Agent oder welche Aufgabe eingesetzt wird.
• Observability: Tracing, Debugging, Audit-Trail über alle Agent-Aktionen.

Was gibt es:

Proprietär

• Managed Platforms: vollständig gemanagt, Enterprise-Features
• Cloud-Native: Integration in Cloud-Ökosystem
• Enterprise RPA+AI: bestehende RPA-Infrastruktur

Open-Source / Hybrid

• Frameworks: volle Kontrolle, selbst gehostet
• Low-Code: visuelle Workflow-Erstellung
• Personal Agents: lokale Installation, IDE-Integration

Wichtig:

Die Agent Runtime bestimmt wie Workflows aufgebaut, orchestriert und mit Tools verbunden werden. Sie ist die Schicht mit dem höchsten Lock-in-Risiko, weil die gesamte Ablauflogik hier liegt. Ein Wechsel der Runtime bedeutet in der Regel, Workflows neu zu bauen. Auch zwischen Open-Source-Frameworks ist die Portabilität begrenzt.

4

Data & Knowledge

Definition und Zweck: Die Data & Knowledge Schicht stellt persistente Speicherung für Daten und Wissen bereit. Sie ist „das Gedächtnis" des Systems. Ohne sie vergessen Agents nach jeder Session alles.

In dieser Schicht kann vorhanden sein:

• Memory (mehrstufig): Kurzzeit-Memory hält den Kontext innerhalb einer laufenden Aufgabe. Langzeit-Memory speichert Wissen über Nutzer, Projekte und vergangene Interaktionen über Sessions hinweg. Prozedurales Memory speichert wiederverwendbare Lösungsmuster.
• Retrieval (RAG): Agents suchen relevantes Wissen vor der Antwort. Der Trend geht weg von einfachem Vektor-Lookup hin zu hybridem Retrieval, das semantische Suche mit strukturierter Abfrage kombiniert.
• Knowledge Graphs: Modellieren Beziehungen zwischen Entitäten (Personen, Prozesse, Systeme, Dokumente). Ermöglichen Multi-Hop-Reasoning. Standard-RAG allein schafft das nicht.
• Data Ingestion: Dokumente parsen, chunken, Metadaten extrahieren, embedden, indexieren. Ohne Ingestion-Pipeline ist die Knowledge Layer leer. Die Qualität der Ingestion bestimmt die Qualität aller Antworten.
• Datenaktualität: Wissen veraltet. Ingestion-Pipelines müssen kontinuierlich laufen, nicht einmalig. Veraltetes oder widersprüchliches Wissen im System ist schlimmer als kein Wissen.

Was gibt es:

Die folgenden Technologien gehören zum eigentlichen Gedächtnis des Agent-Systems. Darüber hinaus können KI-Agenten über Tool-Integrationen auf jede beliebige Datenquelle zugreifen (das wäre aber Schicht 3). In Schicht 4 gibt es:

• Vector-Datenbanken (Embeddings für semantische Suche und RAG)
• Knowledge Graphs (Beziehungen zwischen Entitäten, Multi-Hop-Reasoning)
• Document Stores (unstrukturierte Dokumente, Volltextsuche)
• In-Memory Stores (Session-State, Kurzzeit-Memory, Caches)
• Personal Knowledge (Wikis, Notizsysteme, Markdown-Sammlungen)

Wichtig:

Data & Knowledge bestimmt was KI-Agenten wissen. Die Qualität dieser Schicht begrenzt die Qualität aller Agent-Antworten — unabhängig davon wie gut das Modell oder die Runtime ist. Schlechte Daten in einer guten Runtime mit einem guten Modell erzeugen schlechte Ergebnisse. Ohne diese Schicht fangen KI-Agenten bei jeder Anfrage bei Null an.

Der Unterschied zwischen dieser Schicht und Datenbankabfragen über Toolaufrufe aus Schicht 3 verdient einen eigenen Artikel.

5

Governance & Control

Definition und Zweck: Die Governance & Control Schicht setzt Regeln, Policies und Compliance-Anforderungen durch. Sie stellt sicher, dass KI-Agenten innerhalb definierter Grenzen operieren.

Darin enthalten:

• Policy Enforcement: Maschinenlesbare Regeln (z. B. keine PII-Daten ohne Maskierung, keine Aktionen über bestimmten Schwellenwerten ohne Freigabe)
• Access Control: Wer darf welche KI-Agenten nutzen, welche Daten sehen, welche Aktionen ausführen (RBAC, ABAC)
• Data Classification: Welche Daten dürfen in Agent-Kontexte gelangen, welche nicht. Sensitivity-Labels
• Input/Output Guardrails: Prompt-Injection-Schutz, Hallucination-Detection, Content-Filter
• Audit-Logging: Vollständige Protokollierung aller Agent-Aktionen (wer, wann, was, mit welchem Ergebnis)
• Compliance-Reporting: Reports für Behörden und interne Stakeholder (BaFin, DSGVO, EU AI Act, branchenspezifische Regulierung)

Was gibt es:

• Policy Engines (deklarative, maschinenlesbare Regeln als Code)
• Identity & Access Management (SSO, RBAC, OAuth2, OIDC, User-Lifecycle)
• Logging & Monitoring (Logs, Metriken, Alerting, Dashboards)
• AI Observability (Agent-spezifisches Tracing, Token-Tracking, Latenz, Kosten pro Agent-Call)
• Compliance-Plattformen (DSGVO, SOC2, ISO, EU AI Act, branchenspezifisch)
• Cloud-Native Governance (Policy-Enforcement integriert in Cloud-Infrastruktur)
• AI Safety & Guardrails
• Data Classification & DLP
• Model Governance (Modell-Versionierung, Registry, Approval-Workflows)
• Audit-Trail & Forensik
• Cost Governance (Token-Budgets pro Agent, Team, Use Case, Alerting bei Schwellenwerten)

Wichtig:

Governance ist der Unterschied zwischen Demo und Produktion. Ohne Governance keine Compliance, kein Audit, kein Vertrauen. Die Frage ist ob man sie selbst baut oder vom Vendor bekommt.

6

Interface

Definition und Zweck: Die Interface Layer ist der Zugangspunkt für User und externe Systeme. Sie ist das „Gesicht" des Systems, die Schnittstelle durch die Menschen und andere Systeme mit Agents interagieren.

Ein Interface ermöglicht:

• User-Interaktion: Chat, Portal, Mobile App
• System-Integration: APIs für andere Anwendungen
• Multi-Channel: Slack, Teams, WhatsApp, Web, Mobile
• Personalisierung: User-spezifische Erfahrungen

Was gibt es:

• Messaging Platforms (Enterprise/Community Chat-Integration)
• Business Messaging (Mobile-first, hohe Reichweite)
• Web Frameworks (Custom Web-Apps)
• Low-Code Portals (schnelle Portal-Entwicklung)
• API Gateways (API-Management, Rate Limiting)
• Chatbot Platforms (visuelle Bot-Erstellung)
• Voice Interfaces (Sprachsteuerung)
• IDE Integration (Developer-Fokus)

Wichtig:

Interface bestimmt User-Akzeptanz. Das beste KI-Agenten-System nützt nichts wenn User es nicht nutzen können oder wollen.

Zwischenergebnis

Die verschiedenen Schichten sind eine abstrakte Betrachtungsweise, die dabei hilft, „das große unbekannte Thema" in verständliche Einheiten herunterzubrechen.

Selbst wenn Sie kein Techie sind, können Sie sich unter jeder Schicht einigermaßen etwas vorstellen.

Diese Abstraktion hilft enorm beim Verstehen der verschiedenen Typen von agentischen KI-Stacks.

Hier nun diejenigen, die ich identifiziert habe. Es gibt vielleicht noch weitere Typen. Ich habe mich auf die gängigsten beschränkt.

Verschiedene Typen von agentischen KI-Stacks

Nicht jede Organisation muss alle 6 Schichten selbst bauen. Plattformen decken unterschiedliche Schichten ab. Jeder Typ wird mit komplettem 6-Layer-Diagramm dargestellt.

Es gibt folgende Typen:

1. Ecosystem-Integrated
2. Managed Control Plane
3. Enterprise Application Suites
4. Infrastructure-Only
5. Managed Execution & self-hosted Control
6. Selbstgebaut / Open-Source Frameworks

Es gibt auch Mischformen, aber der Artikel ist so schon sehr lang, also betrachte ich mal nur diese.

Für jeden Typ sehen wir uns die Architekturschichten an.

Farblegende:

Typ 1: Ecosystem-Integrated Platforms

KI als Feature im bestehenden Ökosystem. Tief integriert, aber nur innerhalb des Ökosystems nutzbar.

Dieser Typ beschreibt Plattformen, die KI eher für alle Mitarbeiter bereitstellen. Typ 3 wäre eher für bestimmte Business-Bereiche. Teilweise gibt es Anbieter, die beides sind.

Governance im Detail

Vendor übernimmt: Vollständige DLP, Compliance Center mit Templates, Audit-Logs im Ecosystem-Format (für eDiscovery), automatische Data-Classification, Integration in Ecosystem-Apps, Prompt-Injection-Schutz, Basis-Output-Validation.

Organisation muss selbst machen: Ecosystem-spezifische Policies konfigurieren, User-Management im Ecosystem, Reporting nur im Ecosystem-Rahmen möglich, Sensitivity-Labels für Dokumente vergeben. Externe Agents nicht abgedeckt.

Workflow-Anpassungsfähigkeit & Use-Case-Freiheit

• Workflow-Design: Ecosystem-Paradigma (z. B. Copilot Studio: Power-Fx, Google: AppScript)
• Use-Case-Auswahl: Nur Use Cases innerhalb des Ecosystems (Teams, Outlook, Gmail, Docs)
• Integrationen: Nur Ecosystem-Apps + begrenzte externe Connectors
• Business-Logik: Nur wenn Ecosystem sie unterstützt
• Skalierung: Ecosystem skaliert automatisch, aber Lizenzkosten steigen linear
• Business-Transformation: Nur Optimierung bestehender Ecosystem-Prozesse, keine neuen Geschäftsmodelle

Typ 2: Managed Control Plane Platforms

Vollständig gemanagte Plattformen die Layer 1, 3, 4, 5, 6 bereitstellen. Organisation entscheidet nur Layer 2 (Model-Auswahl) und definiert eigene Workflows.

Governance im Detail

Vendor übernimmt: RBAC/SSO-Integration, Audit-Logging-Infrastruktur, Basis-Policies (Rate Limits, Quotas), Compliance-Zertifizierung der Platform (SOC2, ISO27001), Monitoring-Dashboard, Prompt-Injection-Schutz, Basis-Output-Validation.

Organisation muss selbst machen: Eigene Business-Policies definieren, User-Rollen konfigurieren, Compliance-Reports für Behörden erstellen (BaFin, DSGVO), Human-in-the-Loop Workflows designen, Data-Classification Policies definieren.

Workflow-Anpassungsfähigkeit & Use-Case-Freiheit

• Workflow-Design: Workflows müssen Platform-Paradigma folgen
• Use-Case-Auswahl: Beliebige Use Cases möglich, solange Platform-Modelle sie unterstützen
• Integrationen: Platform-Connectors vorhanden, Custom-Integrationen erfordern Platform-spezifischen Code
• Business-Logik: Komplexe eigene Logik nur wenn Platform es unterstützt
• Skalierung: Platform skaliert automatisch, Cost-Control selbst verantworten
• Business-Transformation: Schnell neue Use Cases testen, aber bei Erfolg Lock-in-Risiko

Typ 3: Enterprise Application Suites

Komplett-Pakete von Enterprise-Anbietern. Kombinieren Infrastructure bis Interface in einer Suite.

Governance im Detail

Vendor übernimmt: Suite-interne Governance komplett, Integration in Suite-Apps, Compliance für Suite-Use-Cases (zertifiziert), Audit-Logs für Suite-Aktionen, Data-Governance innerhalb Suite, Prompt-Injection-Schutz, Basis-Output-Validation.

Organisation muss selbst machen: Suite-Policies konfigurieren, User-Management in Suite, Governance nur innerhalb der Suite (externe Agents nicht abgedeckt), Reporting nur für Suite-Use-Cases, Hybrid-Szenarien selbst bauen.

Workflow-Anpassungsfähigkeit & Use-Case-Freiheit

• Workflow-Design: Suite-Paradigma
• Use-Case-Auswahl: Nur Use Cases die Suite unterstützt
• Integrationen: Tiefe Suite-Integration, externe Systeme nur über Suite-Connectors
• Business-Logik: Nur wenn Suite sie unterstützt
• Skalierung: Suite skaliert automatisch, aber Lizenzkosten steigen stark
• Business-Transformation: Nur Transformation innerhalb Suite-Rahmen, keine AI-native Products außerhalb

Typ 4: Infrastructure-Only Providers

Nur Infrastructure und Model Serving (Layer 1–2). Organisation baut Layer 3–6 selbst.

Governance im Detail

Vendor übernimmt: Nur Infrastructure-Security (physische Sicherheit, Netzwerk-Isolation). Keine Governance-Features, kein Audit-Logging, keine Compliance-Tools, kein Prompt-Schutz, keine Output-Validation, kein Human-in-the-Loop.

Organisation muss selbst machen: Kompletten Governance-Stack aufbauen, model-spezifische Guardrails implementieren (z. B. keine PII in Model-Requests), Audit-Logging selbst (alle Model-Calls mit User-ID, Timestamp, Input/Output-Hash), Compliance-Reports selbst, Prompt-Injection-Schutz selbst, Output-Validation selbst, Escalation-Workflows selbst.

Workflow-Anpassungsfähigkeit & Use-Case-Freiheit

• Workflow-Design: Beliebiges Paradigma, eigener Code
• Use-Case-Auswahl: Jeder Use Case möglich, Model-APIs sind generisch
• Integrationen: Jede Integration selbst, keine Vendor-Connector-Grenzen
• Business-Logik: Ohne Limits, eigener Code zwischen User und Model
• Skalierung: Provider skaliert Infrastructure, Cost-Control selbst
• Business-Transformation: Komplett neue Geschäftsmodelle, Model-APIs sind Commodity

Typ 5: Managed Execution & self-hosted Control

Der Modell-Anbieter stellt Inference und Tool-Use-fähige Execution über eine API bereit. Die Organisation baut darauf die gesamte Agent-Logik selbst: Memory, Skills, Orchestrierung, Scheduling, Multi-Agent-Koordination.

Infrastructure (Layer 1) und Model Serving (Layer 2) liegen beim Anbieter. Layer 3 ist geteilt: Execution beim Anbieter, alles darüber beim Unternehmen. Layer 4, 5 und 6 baut die Organisation selbst.

Governance im Detail

Vendor übernimmt: Modell-eigene Safety-Guardrails (Content-Filter, im Modell eingebaut), API-Level Rate Limiting und Usage Tracking, Token-Verbrauchsdaten über API-Dashboard.

Organisation muss selbst machen: OPA/Kyverno-Policies, Keycloak/Auth0, Output-Validation (Hallucination-Detection, Content-Filter, JSON-Schema-Checks), ELK/Grafana, Audit-Logging, Compliance-Reports (BaFin-MaRisk, DSGVO, GxP), Escalation-Workflows, Prompt-Injection-Schutz.

Workflow-Anpassungsfähigkeit & Use-Case-Freiheit

• Workflow-Design: Beliebiges Paradigma für die selbstgebaute Orchestrierung, aber Execution-Patterns durch den Vendor vorgegeben
• Use-Case-Auswahl: Jeder Use Case möglich, solange er über die API des Anbieters abbildbar ist
• Integrationen: Jede Integration selbst gebaut
• Business-Logik: Ohne Platform-Limits im eigenen Code, Execution-Fähigkeiten abhängig vom API-Anbieter
• Skalierung: Eigene Schichten selbst skalieren, Inference skaliert der Anbieter, Token-Kosten selbst verantworten
• Business-Transformation: Neue Geschäftsmodelle möglich, mit Abhängigkeit bei der Execution-Schicht. Differenzierung liegt in der selbstgebauten Orchestrierung und im Domänenwissen.

Typ 6: Selbstgebaut

Selbst gebauter agentischer KI-Stack, evtl. mit Open-Source-Frameworks die selbst gehostet und betrieben werden. Volle Kontrolle über alle Schichten, hoher eigener Aufwand.

Governance im Detail

Da es bei Typ 6 keinen Vendor gibt, gibt es maximal das, was Open-Source-Frameworks anbieten. Daher: keine Managed Services, kein Monitoring, keine Audit-Logs, keine Compliance-Tools, kein Human-in-the-Loop, keine Guardrails.

Organisation muss selbst machen:

• OPA/Kyverno Policies schreiben (z. B. Agent darf keine PII-Daten lesen ohne Maskierung)
• Keycloak/Auth0 betreiben (SSO, RBAC, User-Lifecycle)
• Output-Validation: Hallucination-Detection, Content-Filter, JSON-Schema-Checks
• ELK/Grafana-Stack aufsetzen (Logs, Metriken, Alerting)
• Audit-Logging implementieren
• Compliance-Reports selbst generieren (BaFin-MaRisk, DSGVO, GxP)
• Escalation-Workflows selbst coden
• Prompt-Injection-Schutz selbst integrieren (Lakera Guard oder eigene Rules)

Workflow-Anpassungsfähigkeit & Use-Case-Freiheit

• Workflow-Design: Beliebiges Paradigma (State-Machines, Event-Driven, Multi-Agent, Custom)
• Use-Case-Auswahl: Jeder Use Case möglich, keine Platform-Beschränkungen
• Integrationen: Jede Integration selbst gebaut, keine Vendor-Grenzen
• Business-Logik: Ohne Platform-Limits, eigener Code, eigene Rules
• Skalierung: Muss selbst skalieren (Kubernetes, Load-Balancing), aber keine Vendor-Cost-Cap
• Business-Transformation: Komplett neue Geschäftsmodelle möglich, Platform limitiert nicht

Auf einen Blick

Fazit

Während der Arbeit an diesem Artikel ist mir klar geworden, dass KI im besten Falle die Business Strategie erweitert, weil ich neue Geschäftsmodelle aufbauen kann. Aber gleichzeitig begrenzt die Business Strategie die KI-Strategie.

Je nachdem wie meine Business Strategie aussieht, entscheide ich mich gegen bestimmte Typen von agentischem KI-Stack.

Die Entscheidung hängt von vielen Faktoren ab.

Es gibt nicht „das eine" Operating Model

Bestimmt ist Ihnen beim Lesen auch klar geworden, dass Sie je nach Stack ganz unterschiedliche Rollen benötigen, die Ihnen das aufbauen oder implementieren und die es letztendlich betreiben. Die Entwicklung ist unterschiedlich. Der Governance-Teil ist unterschiedlich. Und wenn Sie neue Geschäftsmodelle aufbauen wollen, benötigen Sie evtl. Rollen, die Sie vielleicht noch gar nicht auf dem Schirm haben.

Das bedeutet: Jeder Typ eines agentischen KI-Stacks hat unterschiedliche Konsequenzen für die Organisation. Es ergeben sich daraus:

• unterschiedliche Operating Modelle
• unterschiedliche Teamzusammensetzungen
• unterschiedliche Arbeitsweisen
• unterschiedliche Organisationsdesigns

Und man benötigt sehr wahrscheinlich für jeden Typ unterschiedliche KI-Berater.