Warum der Chat nicht die KI-Plattform ist | Pexon

Constantin Budin, Principal Data & AI bei Pexon Consulting | 8 Min. Lesezeit | 31.08.2026

TL;DR

Der Chat zeigt, dass Modelle nützen. Eine Plattform braucht Gateway, Rechte, Logging und Prozesse, die ohne Menschen im Fenster laufen. Ein zweites Chatfenster ist keine Plattform. ChatGPT- und Copilot-Piloten beweisen Nutzen am Platz. Sie ersetzen keine KI-Plattform: ohne Scheduler, Audit und Tool-Rechte bleibt der Pilot eine Demo. chatbot reicht nicht, sobald niemand nachts im Fenster sitzt. Pexon Consulting trennt beides.

Der Chat-Pilot war richtig – und ist trotzdem nur die Demo

Der ChatGPT-Pilot im Unternehmen war die richtige erste Bewegung. Einkauf hat Lieferantenmails zusammenfassen lassen. Qualität hat eine Norm erklärt bekommen. Der Vorstand hat Screenshots gesehen. Ohne diesen Beweis kauft niemand weiter.

Die Enttäuschung kommt drei Monate später. Die Sitze sind belegt. Copilot antwortet in Word. Der interne Chatbot kennt die FAQ. Und trotzdem wartet der Wareneingang um 02:10 auf eine Person, die einen Lieferschein abtippt. Trotzdem liegt die Abweichungsmeldung aus der Nachtschicht bis zum Morgen im Postfach.

Das ist keine Modellschwäche. Das ist die Grenze der sichtbaren Schicht. Ein Mensch öffnet ein Fenster, tippt, kopiert, entscheidet. Sobald er Feierabend hat, steht der Prozess. KI-Plattform vs. Chatbot heißt genau diese Trennung: der Chat beweist, dass Tokens nützen. Die Plattform muss denselben Nutzen tragen, wenn niemand zuschaut.

Drei Szenen, die wir in Erstgesprächen hören, immer in dieser Reihenfolge:

Wareneingang. Der Pilot fasst den Lieferschein in fünf Sätzen zusammen. Der Disponent nickt. Nachts kommt die Palette trotzdem in die Halle, und niemand schreibt den Wareneingang ins ERP, weil der Chat kein Schreibrecht hat und kein Lauf startet, wenn die Kamera oder der Scanner ein Ereignis feuert.

Instandhaltung. Der Chat erklärt die Störung anhand der letzten drei Tickets. Der Meister ist beeindruckt. Um 02:00 legt die SPS eine Meldung. Der Chat schläft, weil niemand den Prompt setzt. Am Morgen beginnt die Schicht mit demselben Stau wie vor dem Pilot.

Kreditoren. Copilot hilft in Excel beim Abgleich. Das ist echter Office-Nutzen. Der Stapel PDF im Postfach nach 18 Uhr bleibt ein Stapel, weil Zuordnung plus Buchungsvorschlag ein Prozess mit Retry ist, kein Seat.

Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner, ISO 27001) sieht denselben Knick in vielen der 400+ Projekte: Adoption im Fenster, Stillstand in der Kette. 14 AI Agents laufen bei uns in Produktion. Keiner davon ist „der bessere Chat“. Alle brauchen einen Anstoß ohne Person, ein begrenztes Tool-Recht und einen Beleg, den ein Prüfer lesen kann. Der Pilot bleibt wertvoll. Er ist die Demo. Wer ihn zur Plattform erklärt, verkauft die Oberfläche als Betrieb.

Was nachts fehlen: Rechte, Retry, Audit, Gateway

Was nachts fehlt, steht selten auf der Pilot-Folie. Vier Bausteine, ohne die chatbot reicht nicht, sobald der Lauf ohne Sitzung starten soll. Die Tiefe für unbeaufsichtigte Agenten liegt auf der Seite Hintergrund-Agenten. Hier nur, warum der Chat sie nicht mitliefert.

Rechte. Im Chat kopiert jemand Stammdaten in die Maske. Das fühlt sich an wie Integration. Es ist Copy-Paste mit Zeugen. Ein Agent, der um 02:10 einen Wareneingang anlegt, braucht Least Privilege auf genau diese Buchung, nicht denselben Token wie die FAQ-Demo. Read ist nicht Write. Die Datenklasse steht vor dem Tool-Call, nicht im Systemprompt.

Retry. Timeout um 02:17. Der Chat endet. Der Mensch startet morgen neu, wenn er das Fenster öffnet. Ein Prozess darf das nicht. Queue, Timeout, erneuter Versuch, Abbruch mit Grund. Und ein Name: wer besitzt den Lauf am Morgen. Ohne Owner ist der Fehler ein Screenshot in einem Chat, den niemand abonniert hat.

Audit. Der Chat-Verlauf ist eine Unterhaltung. Der Prüfer will eine Lauf-ID, den Tool-Call, das Ergebnis, wer den Retry ausgelöst hat. Tenant-Logs der Suite zeigen, dass jemand um 14:03 Copilot genutzt hat. Sie zeigen nicht, dass um 02:10 Beleg 48112 zugeordnet wurde. Ohne dieses Protokoll bleibt der Nachtlauf eine Geschichte.

Gateway. Modell, Region, Budget, Trace sitzen vor dem Call, nicht in der Chat-UI. Ohne Gateway teilt sich der FAQ-Bot das Kontingent mit dem Buchungsagenten. Ein Team dreht das Modell, der Nachtprozess schreibt plötzlich mit einem anderen Endpoint. Spend und Sperre fehlen. Der Pilot hat das nie gebraucht, weil immer jemand zugeschaut hat.

Ein Beispiel statt einer Bewertungstabelle: Die Qualitätssicherung will Abweichungen aus dem MES nach Schichtende vorbereiten, nicht erst um 08:30. Der Chat kann die Norm erklären. Der Lauf braucht ein Ereignis aus dem MES, ein Read auf die letzten Messpunkte, ein Write nur auf den Entwurfsdatensatz, drei Retries bei Timeout, eine Lauf-ID für den Auditor. Fehlt eines von vier, bleibt es ein Chat-GPT-Pilot im Unternehmen mit netten Antworten am Tag.

Support bleibt 8×5. Der Prozess darf nachts laufen. Ein Mensch muss nicht um 02:10 im Fenster sitzen und nicht um 02:10 das Telefon abnehmen. Wer 24-Stunden-Verfügbarkeit der Beratung verspricht, vermischt Scheduler und Servicezeit.

Warum ein zweites Chat-Abo das nicht heilt (tote Connectoren, Feature-Kill)

Die naheliegende Reaktion nach dem Pilot: ein zweites Chat-Abo. Schöneres Fenster, mehr Connectoren in der Preisliste, „Enterprise“ auf der Rechnung. Das heilt die Nacht nicht. Es verdoppelt die Demo.

Tote Connectoren sind das erste Loch. Im Pitch sind SharePoint, Jira, SAP, Mail, CRM angehakt. Im Betrieb ist der SAP-Write „in Roadmap“, der Jira-Connector hängt an einem persönlichen Token. Sie zahlen die Breite und bekommen denselben Copy-Paste-Pfad, nur mit anderem Logo. Ein Connector ohne Schreibpfad, Retry und Lauf-ID ist Dekoration.

Feature-Kill ist das zweite. Eine Funktion, die der Pilot genutzt hat, verschwindet „aus Sicherheitsgründen“ oder wandert in ein teureres Paket. Die Fachseite hat sich daran gewöhnt. IT darf erklären, warum der Button weg ist. Auf einer eigenen Plattform entscheiden Sie, welche Fähigkeit bleibt. Im Seat-SaaS entscheidet die Roadmap des Anbieters.

Wer den zweiten Chat sechs Monate als „die KI des Hauses“ etabliert, kauft Lock-in in der Fläche, nicht in der Kette. IdP-Lücken, Drosseln, On-Prem erst ab einer Sitzzahl, die Sie nicht geplant hatten. Den Vergleich Seat-Chat gegen eigene Plattform führt der Unabhängigkeits-Check. Hier zählt nur der Satz: ein zweites Fenster startet um 02:10 immer noch keinen Prozess.

Kaufen Sie den zweiten Chat, wenn Sie eine bessere Oberfläche für denselben Sitz brauchen. Nicht als Ersatz für Gateway, Rechte, Audit und Scheduler. Sonst haben Sie zwei Demos und einen Wareneingang, der auf den Morgen wartet.

Copilot darf Office bleiben

Copilot muss nicht weg, damit eine Plattform entsteht. Das ist der häufigste Fehlschluss nach dem Pilot. Jemand will „endlich eine Linie“ und plant den Cutover: Sitze kündigen, alles in den internen Chat, fertig. Das bestraft die Breite und heilt die Nacht nicht.

Copilot darf Office bleiben. Word, Excel, Outlook, Teams: dort sitzt die Arbeit am Tag, dort ist der Seat der richtige Vertrag. Eine Mail umformulieren, eine Tabelle erklären, eine Folie anstoßen. Das ist sichtbar, interaktiv, an den Menschen gebunden. Genau dafür ist die Suite gebaut.

Was Copilot nicht ist: der Owner des Wareneingangs um 02:10. Der Seat endet mit der Session. Die Suite loggt Nutzung, nicht Ihren Fachprozess. ERP-Write nach Least Privilege, Queue, Retry, Lauf-ID gehören nicht in denselben Kanal wie „fass mir diesen Absatz kürzer“. Wer beides in ein Fenster zwingt, macht entweder Office langsam oder den Nachtlauf unbelegbar.

Der saubere Schnitt: sichtbare Schicht bleibt Microsoft 365. Unbeaufsichtigte Arbeit liegt auf der eigenen Plattform. Hybrid, nicht Glaubenskrieg. Den Hand-off beschreiben wir auf der Copilot-Hybrid-Seite. Pexon ist Microsoft Partner. Wir reißen die Suite nicht aus, um eine Demo zu retten. Lassen Sie die Sitze, die Fachbereiche wirklich nutzen, und benennen Sie parallel einen Prozess, der ohne Sitzung laufen muss.

Erster Use-Case auf der eigenen Plattform

Der erste Use-Case ist kein zweiter Chatbot. Er ist eine Kette mit Trigger, begrenztem Write, Owner am Morgen. Wer mit „wir brauchen Assistenten für alle“ startet, baut wieder ein Fenster. Wer mit einer Nachtlücke startet, baut Plattform.

Drei Filter, bevor jemand ein Modell wählt:

1. Es gibt schon ein Ereignis. Scanner, MES, Postfach, ERP-Status, Cron. Wenn der Anstoß „jemand öffnet den Chat“ ist, bleiben Sie beim Pilot.
2. Das Write ist klein und benennbar. Ein Entwurfsdatensatz, eine Queue-Karte, eine Klassifikation plus Vorschlag. Nicht „der Agent darf SAP“. Least Privilege oder es bleibt Demo.
3. Jemand besitzt den Lauf um 08:30. Name, Vertretung, was bei grauem Ergebnis passiert. Ohne Owner ist Retry Theater.

Beispiel, das die Filter überlebt: Eingangsrechnungen nach 18 Uhr. Trigger ist das Postfach. Der Agent liest den Belegkopf, ordnet Kreditor und Kostenstelle als Vorschlag zu, schreibt nur in einen Entwurfsbeleg, drei Retries bei Timeout, Lauf-ID ins Log. Die Buchhaltung prüft am Morgen die grauen Fälle. Copilot darf in Excel helfen, der Chatbot darf FAQ beantworten. Die Plattform trägt nur diese eine Kette.

Das Gegenbeispiel ist der Unternehmensassistent, der alles kann. Kein Trigger, Write überall, Owner niemand. Das ist der Pilot in groß.

Den Einstieg ohne Cutover beschreibt das Plattform-Setup: Gateway, Identität, eine Quelle, Guardrails, Copilot bleibt an. Wie die Harness sitzt, steht auf der Agenten-Plattform. Der Cluster ist die Open-Source-KI-Plattform. Der erste Prozess, der ohne Fenster überlebt, steht unter Use-Cases auf der Plattform.

Wählen Sie die Kette, die heute schon nachts wartet. Der Chat-Pilot hat bewiesen, dass Modelle nützen. Der erste Use-Case muss beweisen, dass Nutzen ohne Fenster überlebt.

Häufig gestellte Fragen

Warum reicht ein ChatGPT- oder Copilot-Pilot nicht als KI-Plattform fürs Unternehmen?

Weil der Pilot Nutzen am Platz zeigt und die Plattform Nutzen ohne Sitzung tragen muss. Gateway, Rechte, Logging, Scheduler. Ein zweites Chatfenster ändert das nicht. chatbot reicht nicht, sobald der Prozess nachts starten soll.

Heilt ein zweites Chat-Abo die Lücke?

Nein. Tote Connectoren und Feature-Kill lassen Sie in der sichtbaren Schicht. Der Vergleich Seat gegen eigene Plattform steht unter Unabhängigkeit. Nachtlauf, Retry und Audit liegen auf der Hintergrund-Agenten-Seite.

Muss Microsoft Copilot raus?

Nein. Copilot darf Office bleiben. Die Suite ist die Breite am Tag. Unbeaufsichtigte Arbeit gehört auf die eigene Plattform. Hybrid ist der normale Pfad, Cutover der teure.

Was ist der erste Use-Case, wenn der Pilot schon läuft?

Eine Kette mit Ereignis, kleinem Write und Owner am Morgen. Nicht ein zweiter Assistent. Einstieg ohne den bestehenden Stack abzuschalten: Setup.

Läuft das dann rund um die Uhr mit Support?

Der Prozess darf nachts laufen. Der Support bleibt 8×5. Scheduler ist kein Bereitschaftsdienst. Wer beides vermischt, kauft Erwartung, die niemand halten will.

Nächster Schritt

Der Chat-Pilot war richtig. Er ist die Demo. Wenn eine Kette ohne Fenster laufen soll, ist der nächste Schritt nicht das zweite Abo.

Lesen Sie, was unbeaufsichtigte Agenten auf der eigenen Plattform brauchen: Hintergrund-Agenten. Den Cluster drumherum: Open-Source-KI-Plattform.

Verwandte Themen