KI ist nicht der Engpass. Kontext ist es.

In 30 Sekunden

Die Modelle sind gut. Wirklich gut. Claude, ChatGPT, Gemini – jedes davon kann die meisten Business-Aufgaben lösen, wenn man es richtig aufsetzt.

Trotzdem stecken die meisten Unternehmen fest.

Nicht, weil die Technologie nicht reif ist. Sondern weil der Kontext des spezifischen Geschäftsprozesses nie beim Modell ankommt.

Das Kontext-Problem

Stell dir vor, du willst die Rechnungsprüfung automatisieren.

Das Modell kann Rechnungen lesen. Es kann Zahlen extrahieren. Es kann sogar Anomalien erkennen. Technisch ist das gelöst.

Aber weiß das Modell, dass:

• Rechnungen von Lieferant X immer 2 % Skonto bekommen, aber nur wenn sie innerhalb von 14 Tagen bezahlt werden?
• "Freigegeben" im Einkauf etwas anderes bedeutet als "freigegeben" in der Buchhaltung?
• Bei Beträgen über 10.000 € immer die Geschäftsführung unterschreiben muss – außer bei wiederkehrenden Verträgen?
• Der Lieferant Y seine Rechnungsnummern seit letztem Quartal geändert hat und das alte Format trotzdem noch parallel läuft?

Nein. Das weiß das Modell nicht. Und es steht auch nirgendwo dokumentiert.

Dieses Wissen lebt im Kopf der Person, die seit drei Jahren die Rechnungen bearbeitet.

Warum Dokumentation das Problem nicht löst

Die naheliegende Antwort: "Dann dokumentieren wir halt alles."

Klingt gut. Funktioniert nicht.

Erstens: Prozesswissen ist implizit. Die Person, die den Prozess kennt, weiß oft nicht, was sie weiß. Sie trifft Entscheidungen basierend auf Erfahrung und Intuition, nicht auf einem Regelwerk. Frag sie nach den Regeln, und sie wird dir vielleicht 60 % davon erzählen können. Den Rest macht sie einfach – ohne darüber nachzudenken.

Zweitens: Prozesse verändern sich ständig. Die Dokumentation von heute ist die technische Schuld von morgen. Kein Unternehmen schafft es, Prozessdokumentation dauerhaft aktuell zu halten. Wer das behauptet, lügt – oder hat noch keine echten Prozesse automatisiert.

Drittens: Die Übersetzung von Prozesswissen in technische Spezifikationen ist verlustbehaftet. Zwischen "ich weiß, wie der Prozess läuft" und "hier ist ein Prompt, der das abbildet" gehen Nuancen verloren. Immer.

Der klassische Ansatz scheitert

So läuft es in den meisten Unternehmen:

1. Die Fachabteilung hat ein Problem
2. Sie schreibt ein Ticket für die IT
3. Die IT (oder ein externer Dienstleister) baut eine Lösung
4. Die Lösung funktioniert – aber nur zu 80 %
5. Es gibt Iterationen, Meetings, Nachbesserungen
6. Nach 3 Monaten ist die Lösung "fertig" – und passt schon nicht mehr zum Prozess, weil sich der zwischenzeitlich verändert hat

Das Problem ist nicht Inkompetenz. Es ist ein Kommunikationsproblem. Das Wissen muss von Kopf A in Kopf B übertragen werden, und bei jeder Übertragung geht etwas verloren.

"Jede Schnittstelle zwischen dem Prozessexperten und dem Builder ist eine Stelle, an der Kontext verloren geht."

Die These: Process Owner als Builder

Wir glauben: Die Menschen, die den Prozess besitzen, sollten die sein, die die KI-Lösung bauen.

Nicht allein. Nicht ohne Unterstützung. Aber sie sollten am Steuer sitzen.

Warum?

• Sie haben den Kontext. Komplett. Mit allen Edge Cases, Ausnahmen und "das haben wir schon immer so gemacht"-Regeln.
• Sie erkennen Fehler sofort. Wenn das Modell eine falsche Entscheidung trifft, sehen sie es – weil sie wissen, wie die richtige aussieht.
• Sie können iterieren. Statt ein 20-seitiges Anforderungsdokument zu schreiben, testen sie direkt und passen an.
• Sie bleiben verantwortlich. Es gibt keine Übergabe, kein "das hat die IT so gebaut". Der Prozess und die Automatisierung gehören zusammen.

Was sich verändert hat: Vibe Coding und No-Code KI

Vor zwei Jahren wäre diese These noch unrealistisch gewesen. Nicht jeder kann programmieren. Nicht jeder sollte es.

Aber die Werkzeuge haben sich fundamental verändert:

Vibe Coding erlaubt es, Software per Prompt zu bauen. Du beschreibst, was du willst – und Tools wie Lovable, Cursor oder Claude Code übersetzen das in funktionierenden Code.

monday.com mit AI Blocks und Workflows ermöglicht es, KI-Automatisierungen direkt im bestehenden Workspace zu bauen – ohne eine einzige Zeile Code.

Make.com und n8n verbinden APIs visuell und erlauben es, komplexe Automatisierungen per Drag & Drop zu erstellen.

Das bedeutet: Die technische Hürde ist dramatisch gesunken. Was bleibt, ist die Kontext-Hürde – und genau die kann nur der Process Owner überwinden.

Wie das in der Praxis aussieht

Beispiel 1: Support-Ticket-Triage

Vorher: IT baut ein ML-Modell zur Ticket-Klassifizierung. Training auf historischen Daten. Ergebnis: 70 % Accuracy. Nicht schlecht, aber nicht gut genug für Produktion.

Nachher: Die Support-Teamleiterin baut einen KI-Agenten mit monday.com AI Workflows. Sie kennt die Regeln: "Alles mit 'Server down' ist P1. Alles von Kunde X ist immer mindestens P2. Passwort-Resets können warten." Sie formuliert die Regeln als Prompt. Ergebnis: 95 % Accuracy am ersten Tag.

Der Unterschied? Kontext.

Beispiel 2: Angebotserstellung

Vorher: Vertrieb fragt IT nach einem Tool. IT evaluiert 6 Monate. Entscheidet sich für eine Enterprise-Lösung. Implementierung dauert weitere 4 Monate. Der Vertrieb nutzt es nicht, weil es nicht zu ihrem Prozess passt.

Nachher: Der Vertriebsleiter baut ein Angebots-Tool mit Lovable an einem Wochenende. Es zieht Kundendaten aus monday.com, generiert Texte mit Claude und erstellt PDFs. Nicht perfekt. Aber es wird benutzt – und wird jede Woche besser, weil er selbst daran iteriert.

Beispiel 3: Reporting

Vorher: Die Geschäftsführung bekommt jeden Montag ein Report-PDF. Manuell erstellt, 4 Stunden Arbeit. Daten aus drei verschiedenen Systemen zusammenkopiert.

Nachher: Die Ops-Managerin baut einen Make.com-Flow, der Daten aus monday.com, HubSpot und der Buchhaltung zieht, von Claude zusammenfassen lässt und automatisch verschickt. Aufwand nach Setup: 0 Stunden.

Die Rolle der IT und externer Berater

Das bedeutet nicht, dass IT-Teams oder externe Berater überflüssig werden. Im Gegenteil – ihre Rolle verändert sich:

Von Builderm zu Enablern:

• Sie stellen die Infrastruktur bereit (APIs, Zugriffsrechte, Security)
• Sie schulen Process Owner in den Tools
• Sie reviewen Lösungen auf Security und Skalierbarkeit
• Sie greifen ein, wenn die Komplexität die No-Code-Grenze überschreitet

Externe Berater wie wir bei Till Freitag arbeiten als Sparringspartner:

• Wir helfen, den richtigen Ansatz zu wählen
• Wir bringen Erfahrung aus 35+ KI-Projekten mit
• Wir trainieren Teams in Vibe Coding und KI-nativer Entwicklung
• Wir übernehmen die komplexen Teile – Custom Apps, Integrationen, Agent-Architekturen

Das Ziel: Der Process Owner sitzt am Steuer. Wir sitzen auf dem Beifahrersitz.

Der Context-Engineering-Ansatz

Statt "KI-Implementierung" reden wir lieber von Context Engineering. Das bedeutet:

1. Context Mapping: Welches implizite Wissen steckt in diesem Prozess? Wer hat es? Wo sind die Edge Cases?
2. Context Capture: Wie bringen wir dieses Wissen in eine Form, die ein LLM nutzen kann? (Prompts, System Instructions, Knowledge Bases, strukturierte Daten in monday.com)
3. Context Testing: Funktioniert die KI-Lösung mit den realen Edge Cases? Erkennt sie die Ausnahmen?
4. Context Maintenance: Wie bleibt der Kontext aktuell, wenn sich der Prozess ändert?

Dieser Ansatz ist fundamental anders als der klassische ML-Ansatz ("gib mir Trainingsdaten und ich baue ein Modell"). Er ist wissensgetrieben, nicht datengetrieben.

Was das für dein Unternehmen bedeutet

Wenn du KI in deinem Unternehmen einführen willst, stell dir diese Fragen:

1. Wer hat den Kontext? Nicht: Wer kann programmieren. Sondern: Wer kennt den Prozess bis ins Detail? Wer trifft die Entscheidungen? Wer weiß, was "normal" ist und was nicht?

2. Haben diese Menschen die Werkzeuge? Kennen sie Lovable, Make, monday.com AI Workflows? Haben sie Zugang? Wissen sie, was möglich ist?

3. Gibt es eine Unterstützungsstruktur? Wer hilft, wenn sie nicht weiterkommen? Wer reviewed die Lösungen? Wer kümmert sich um Security?

4. Ist die Kultur bereit? Dürfen Fachabteilungen "einfach bauen"? Oder muss alles durch die IT? Wird experimentiert oder spezifiziert?

Fazit: Kontext schlägt Code

Die Modelle werden immer besser. GPT-5, Claude 4, Gemini Ultra – sie werden noch leistungsfähiger sein als heute.

Aber der Engpass bleibt derselbe: Der Kontext muss von den richtigen Menschen kommen.

Kein Modell der Welt kann wissen, dass "freigegeben" in deinem Unternehmen drei verschiedene Dinge bedeutet. Kein Modell kann die Intuition deiner Ops-Managerin ersetzen, die in 2 Sekunden erkennt, ob eine Rechnung in Ordnung ist oder nicht.

Die Lösung ist nicht bessere KI. Die Lösung ist, die Menschen mit dem Kontext zu befähigen, KI selbst einzusetzen.

KI ist nicht der Engpass. Kontext ist es. Und den haben nur deine Leute.

---

Du willst dein Team befähigen, KI-Lösungen selbst zu bauen? Sprich mit uns über unsere Vibe Coding Workshops und KI-Enablement-Programme.