TL;DR
KI-Transformation steht auf drei Säulen: Schema (der Bauplan des Unternehmens), Memory (das strukturierte Wissen) und Runtime (die Agents und ihre Orchestrierung). Wer nur eine Säule baut - typischerweise Runtime, weil Agents das Sichtbare sind - bekommt isolierte Use Cases, die nicht skalieren. Wer alle drei hat, baut ein Fundament, das sich nicht verändert, auch wenn sich die Technologie weiterentwickelt.
Inhalt
- Warum scheitern so viele KI-Projekte?
- Was sind die drei Säulen?
- Säule 1: Schema - Regeln und Architektur
- Säule 2: Memory - Daten und Gedächtnis
- Säule 3: Runtime - Agents und Orchestrierung
- Wie hängen die drei Säulen zusammen?
- Was bedeutet das für den Mittelstand?
- Häufige Fragen
Warum scheitern so viele KI-Projekte?
Kurz: Weil sie bei der Lösung anfangen, statt beim Fundament.
Die meisten Unternehmen starten KI mit einem konkreten Use Case: Ein Chatbot für den Kundenservice, ein Agent für die Angebotsvorprüfung, eine Automatisierung im Recruiting. Das ist nachvollziehbar - man will schnell Ergebnisse sehen.
Das Problem ist nicht der Use Case. Das Problem ist, dass er isoliert gebaut wird. Der Chatbot bekommt seine eigene Datenbasis, der Angebotsagent seine eigene, die Recruiting-Automatisierung ihre eigene. Jeder Use Case ist eine Insel. Und Inseln skalieren nicht.
Wenn der dritte oder vierte Agent dazukommt, merkt man: Die Daten sind redundant, die Antworten inkonsistent, und jeder neue Use Case kostet fast so viel wie der erste. Was fehlt, ist kein besseres Tool - was fehlt, ist eine Architektur.
Was sind die drei Säulen?
Kurz: Schema (Regeln), Memory (Daten) und Runtime (Agents) - drei Schichten, die zusammen das Betriebssystem für KI im Unternehmen bilden.
Stellen Sie sich vor, Sie bauen nicht einen einzelnen Agent, sondern ein System, in dem beliebig viele Agents arbeiten können. Dafür brauchen Sie drei Dinge:
-
Schema - Was ist das Unternehmen? Welche Regeln gibt es? Was dürfen Agents, was nicht? Welche Datentypen existieren? Was ist der Bauplan?
-
Memory - Woher wissen die Agents, was im Unternehmen passiert? Welche Kunden gibt es, welche Aufträge, welche Produkte, wie hängt das alles zusammen?
-
Runtime - Welche Agents gibt es, welche Tools haben sie, wie interagieren sie miteinander, auf welchen Daten arbeiten sie?
Ohne eine dieser Säulen funktioniert das Ganze nicht. Man kann einen Chatbot bauen, der ohne alle drei auskommt - aber man kann keine KI-Transformation darauf aufbauen.
Säule 1: Schema - Regeln und Architektur
Kurz: Das Schema ist der Bauplan des Unternehmens für Mensch und Maschine - es definiert, was existiert, was erlaubt ist und wie alles zusammenhängt.
Schema ist die abstrakteste Säule, und deshalb wird sie am häufigsten übersprungen. Sie beantwortet Fragen wie: Was ist dieses Unternehmen? Welche Prozesse gibt es? Welche Rollen? Welche Datentypen? Welche Agents existieren und was dürfen sie?
Man kann sich das Schema als das Betriebshandbuch vorstellen - aber eines, das nicht nur für Menschen lesbar ist, sondern auch für Maschinen. Es ist die Beschreibung des Unternehmens in einer Form, die Agents nutzen können, um ihre eigenen Grenzen zu kennen.
Konkret umfasst das Schema:
- Unternehmensstruktur - Abteilungen, Teams, Zuständigkeiten
- Prozessdefinitionen - Welche Workflows gibt es, welche Schritte gehören dazu
- Agentenregister - Welche Agents gibt es, was ist ihr Aufgabenbereich, welche Tools nutzen sie
- Berechtigungen - Was darf ein Agent, was nicht? Darf der Sales-Agent auf Finanzdaten zugreifen? Darf der Support-Agent Rabatte gewähren?
- Datentypen und Schemata - Welche Entitäten gibt es, welche Felder haben sie, welche Validierungsregeln gelten
Ohne Schema arbeiten Agents in einer Art Vakuum. Sie wissen, was sie tun sollen (Runtime), sie haben Zugang zu Daten (Memory), aber sie kennen die Spielregeln nicht. Das führt zu Agents, die technisch funktionieren, aber Entscheidungen treffen, die nicht zur Unternehmensrealität passen.
Säule 2: Memory - Daten und Gedächtnis
Kurz: Der Knowledge Graph ist das strukturierte Gedächtnis des Unternehmens - nicht nur Dokumente, sondern Entitäten und ihre Beziehungen.
Memory ist die Säule, die am meisten unterschätzt wird. Es geht nicht darum, Dokumente in eine Vektordatenbank zu laden. Es geht darum, eine strukturierte Abbildung des Unternehmens aufzubauen: Welche Kunden gibt es? Welche Aufträge? Welche Produkte? Wer betreut wen? Was hängt womit zusammen?
Das ist der Knowledge Graph - eine Graphdatenbank, in der Entitäten (Kunden, Aufträge, Mitarbeiter) und ihre Beziehungen zueinander abgebildet sind. Die zugrundeliegende Struktur heisst Ontologie: ein formales Modell, das definiert, welche Arten von Dingen im Unternehmen existieren und wie sie zusammenhängen.
Im Kontext der Datenhaltung gibt es klare Regeln: Manche Daten bleiben ausschliesslich im ERP, manche leben nur im Knowledge Graph, manche werden synchronisiert. Ein Auftrag wird weiterhin im ERP angelegt und verwaltet. Aber die Beziehung “Kunde A hat drei offene Aufträge, wird betreut von Mitarbeiter B, der gerade an Projekt C arbeitet” - das ist Graphwissen. Und genau das braucht ein Agent, um kontextbezogen arbeiten zu können.
Wer tiefer in diese Säule einsteigen will: Im Artikel Agent Memory: Warum KI ein strukturiertes Gedächtnis braucht gehen wir im Detail auf Knowledge Graphs, Ontologien und den praktischen Aufbau ein.
Säule 3: Runtime - Agents und Orchestrierung
Kurz: Die Runtime ist die Ausführungsschicht - welche Agents es gibt, welche Tools sie nutzen, und wie sie zusammenarbeiten.
Runtime ist die Säule, über die alle reden. Hier passiert das Sichtbare: Ein Agent prüft ein Angebot, ein anderer beantwortet Kundenanfragen, ein dritter schreibt Reports. Das ist der sexy Teil der KI-Transformation.
Aber Runtime ohne Memory ist wie ein Mitarbeiter, der seine Aufgaben kennt, aber nichts über das Unternehmen weiss. Er kann Aufgaben ausführen, aber er versteht den Kontext nicht. Er weiss nicht, dass der Kunde, für den er gerade ein Angebot schreibt, letzte Woche reklamiert hat. Er weiss nicht, dass das Produkt, das er vorschlägt, einen langen Liefertermin hat.
Die Runtime umfasst:
- Agents - spezialisierte KI-Einheiten mit klaren Aufgaben und Zuständigkeiten
- Tools - die Werkzeuge, auf die Agents zugreifen können (API-Calls, Datenbankabfragen, Berechnungen)
- Orchestrierung - wie Agents miteinander kommunizieren, wer wen wann aufruft, wie Ergebnisse weitergegeben werden
- Datenzugriff - auf welche Teile des Memory jeder Agent zugreifen darf
Die Orchestrierung ist dabei der anspruchsvollste Teil. Ein einzelner Agent ist schnell gebaut. Aber ein System, in dem ein Sales-Agent bei der Angebotserstellung automatisch den Lager-Agent nach Verfügbarkeit fragt und der Finance-Agent die Kreditwürdigkeit des Kunden prüft - das ist Orchestrierung. Und die braucht klare Regeln.
Wie hängen die drei Säulen zusammen?
Kurz: Sie sind voneinander abhängig - jede Säule braucht die beiden anderen, um ihren vollen Wert zu entfalten.
Ein Beispiel aus der Praxis: Ein Fertigungsunternehmen will KI in der Auftragsverarbeitung einsetzen.
-
Ohne Schema: Agents arbeiten, Daten sind verfügbar, aber es gibt keinen Rahmen. Der Sales-Agent gewährt Rabatte, die nicht vorgesehen sind. Der Support-Agent trifft Zusagen, die die Produktion nicht einhalten kann. Die Agents tun Dinge, die einzeln sinnvoll erscheinen, aber in der Summe Chaos erzeugen.
-
Ohne Memory: Der Agent kennt den Kunden nicht. Er weiss nicht, dass dieser Kunde Sonderkonditionen hat, dass es offene Reklamationen gibt, oder dass das letzte Projekt drei Monate verzögert war. Er verarbeitet den Auftrag nach Standardregeln - technisch korrekt, geschäftlich falsch.
-
Ohne Runtime: Die Daten sind da, die Regeln sind definiert, aber es passiert nichts. Das Wissen liegt im Graph, aber kein Agent nutzt es. Das ist wie eine perfekt dokumentierte Prozessbeschreibung, die niemand liest.
Die drei Säulen müssen nicht gleichzeitig perfekt sein. In der Praxis beginnt man mit dem Schema (was ist das Unternehmen, welche Prozesse wollen wir abbilden), baut dann das Memory auf (welche Daten brauchen wir, wie strukturieren wir sie), und erst dann kommt die Runtime (welche Agents setzen wir auf diese Grundlage).
Was bedeutet das für den Mittelstand?
Kurz: Das Fundament ist überschaubar - und einmal gebaut, verändert es sich nicht, auch wenn sich die Technologie weiterentwickelt.
Der Vergleich, der am besten passt: Es ist wie ein Website-Projekt. Man definiert, was man will, wie es aussehen soll, welche Daten dargestellt werden. Der Unterschied: Die KI-Infrastruktur läuft im Hintergrund, sie ist abstrakter, aber der Prozess ist ähnlich strukturiert.
Der entscheidende Punkt für Mittelständler: Die Ontologie des Unternehmens ändert sich nicht. Ein produzierendes Unternehmen hat Kunden, Aufträge, Produkte, Mitarbeiter, Standorte, Maschinen. Diese Grundstruktur ist stabil. Was sich ändert, ist die Technologie - welche Modelle man nutzt, welche Orchestrierungsframeworks, welche Tools. Aber das Fundament bleibt.
Das heisst: Der Aufwand für Memory und Schema ist eine einmalige Investition. Nicht im Sinne von “einmal bauen und nie wieder anfassen” - natürlich wachsen Ontologie und Regelwerk mit dem Unternehmen. Aber die Grundstruktur steht, und jeder neue Use Case kann darauf aufsetzen, statt von Null zu beginnen.
Und genau das ist der Unterschied zwischen “wir haben einen Chatbot” und “wir haben eine KI-Infrastruktur”. Der Chatbot ist ein Projekt. Die Infrastruktur ist ein Asset.
Häufige Fragen
Können wir nicht einfach mit einem einzelnen Agent anfangen?
Ja, und das sollten Sie auch. Der Punkt ist nicht, dass Sie alles auf einmal bauen müssen. Der Punkt ist, dass Sie den einzelnen Agent so bauen, dass er in die grössere Architektur passt. Definieren Sie die Ontologie für den relevanten Ausschnitt, strukturieren Sie die Daten im Knowledge Graph, legen Sie die Regeln fest. Der erste Agent profitiert davon, und der zweite kann direkt darauf aufbauen.
Wie lange dauert es, das Fundament aufzubauen?
Die Ontologie für den Kernbereich eines mittelständischen Unternehmens lässt sich in wenigen Workshops erarbeiten. Das initiale Befüllen des Knowledge Graphs - je nach Datenqualität und Systemlandschaft - ist ein Projekt von einigen Wochen. Das Schema wächst iterativ. Realistisch sind erste produktive Agents auf dem neuen Fundament innerhalb von zwei bis drei Monaten möglich.
Was passiert mit unseren bestehenden Systemen?
Nichts. ERP, CRM, Projektmanagement-Tools bleiben, wie sie sind. Der Knowledge Graph ist eine Schicht darüber, die Daten aus diesen Systemen zusammenführt. Manche Daten werden synchronisiert, manche bleiben ausschliesslich im Quellsystem. Es geht nicht darum, bestehende IT abzulösen, sondern darum, eine semantische Schicht zu schaffen, auf der Agents arbeiten können.
Ist das nicht überdimensioniert für ein mittelständisches Unternehmen?
Im Gegenteil. Gerade im Mittelstand ist die Komplexität oft überschaubar genug, um das Fundament schnell aufzubauen. Ein Konzern mit 200 IT-Systemen hat eine andere Herausforderung als ein Unternehmen mit ERP, CRM und drei Spezialsystemen. Die Ontologie ist kleiner, die Datenflüsse sind klarer, die Entscheidungswege sind kürzer.
Welche Säule ist die wichtigste?
Keine einzelne - das ist der Punkt. Aber wenn man priorisieren muss: Schema und Memory vor Runtime. Die Daten und die Regeln müssen stehen, bevor Agents sinnvoll arbeiten können. Runtime ist das Ergebnis, nicht der Ausgangspunkt.
Fazit
KI-Transformation ist kein Tool-Problem - es ist ein Architektur-Problem. Die drei Säulen Schema, Memory und Runtime bilden das Fundament, auf dem skalierbare KI im Unternehmen steht. Wer dieses Fundament einmal aufbaut, schafft ein Asset, das unabhängig von der technologischen Entwicklung Bestand hat. Die Ontologie des Unternehmens ändert sich nicht. Was sich ändert, sind die Modelle, die Tools, die Orchestrierungsframeworks - aber die lassen sich austauschen, ohne das Fundament anzufassen.
Der erste Schritt ist nicht, einen Agent zu bauen. Der erste Schritt ist, die Frage zu beantworten: Was ist unser Unternehmen - in einer Sprache, die auch Maschinen verstehen?
Wenn Sie wissen wollen, wie die drei Säulen in Ihrem Unternehmen aussehen könnten, sprechen wir gerne darüber.
Basierend auf einer Folge des SNKI-Podcasts “KI im B2B” mit Manuel Zorzi und Michael Kirchberger: Jetzt anhören →