KI entsteht zweimal -- Copilot, deine Datenplattform und die Brücke dazwischen
Diesen Beitrag gibt es auch auf Englisch: AI Happens Twice -- Copilot, Your Data Platform and the Bridge
Mein Motto auf der Speaker-Folie für diesen Vortrag war „Manchmal muss man dem Tiger sagen, dass er orange ist.“ So ein Satz ergibt erst Sinn, wenn man das Problem gesehen hat, um das es geht, und hier war es eines, auf das Jens Kröhnert und ich jahrelang von entgegengesetzten Seiten geschaut haben. Jens ist Principal Solution Architect bei ORAYLIS in Düsseldorf, wo sie Datenplattformen, Data Warehouses und Business Intelligence bauen. Ich komme von Microsoft 365, SharePoint und inzwischen Copilot bei Solvion. Kennengelernt haben wir uns erst heuer, dabei festgestellt, dass wir beide seit rund zwanzig Jahren in unserer Firma sind und erstaunlich ähnlich ticken, und beschlossen, beide Blickwinkel auf einem Copilot-Tag in Vorarlberg gemeinsam auf die Bühne zu bringen, unter dem Titel „Copilot zu Agents: Wie Unternehmen KI produktiv skalieren“.

KI entsteht oft zweimal
Wenn wir sagen, dass KI-Initiativen scheitern, meinen wir nicht die dramatische Sorte. Wir meinen die Vorhaben, die mit viel Begeisterung starten, und nach zwei, drei, vier oder fünf Monaten fragt jemand, ob das jetzt eigentlich wirklich wer nutzt. Die Antworten sind unterschiedlich. Die einen sagen, zum Suchen ist es viel besser, die anderen nutzen es als Antwortmaschine, und dann kommt die Frage, die alles entscheidet, meistens wenn der Pilot vorbei ist: Lizenzieren wir mehr Leute, weniger, und wer ist als Nächstes dran? Genau da sehen wir, dass es oft auseinanderbricht.
Und es bricht, weil KI meistens auf zwei getrennten Inseln entsteht. Im Fachbereich probieren die Leute Copilot und ihre ersten Agents aus. Manche sind voll dabei und probieren aus, was alles geht, andere muss man erst abholen. Auf der IT-Seite reicht die Bandbreite von „das brauchen wir, das bringt uns so viel, aber es muss sicher sein“ bis zu „das wollen wir überhaupt nicht, wo liegen da die Daten, trainieren die auf unseren Daten?“ Jede dieser Sorgen ist berechtigt. Aber würdest du beide Seiten getrennt fragen, wo sie stehen und wo sie mit KI im nächsten Jahr sein wollen, bekämst du dieselbe Antwort?

Frontend AI, Backend AI und die Kompetenz, die niemandem gehört
Jens hat den beiden Seiten Namen gegeben, die ich seither verwende. Frontend AI ist Copilot, die KI, die alle Mitarbeitenden vor sich haben, gut für alles vom Tortenrezept bis zur echten geschäftlichen Frage. Backend AI ist die konsolidierte Datenplattform, der Ort, an dem ein Unternehmen seine wichtigsten Daten endlich aus den operativen Silos herauszieht und eine Version der Wahrheit schafft. Früher hieß das Business Intelligence, heute Data Lake oder Analytics-Plattform, die Namen ändern sich, die Idee bleibt dieselbe. Nach Jens’ Erfahrung haben viele Unternehmen diese Hausaufgabe noch nicht gemacht.
Jede Seite hat ihren typischen blinden Fleck. Die Datenplattform liefert Insights, aber das Potenzial kommt im Arbeitsalltag nicht an, und Governance und Lifecycle sind da, schaffen es aber nie bis ins Frontend. Copilot-Agents dagegen nutzen, was leicht erreichbar ist, statt das, was wirklich zählt, und ihre Use Cases enden genau dort, wo Unternehmensdaten anfangen. Unsere Kolleginnen und Kollegen lernen Copilot, nutzen es, und dann kommt die naheliegende Frage: Wie komm ich zu meinen KPIs, zu meinen Umsatzzahlen? Nicht alles liegt in Microsoft 365, nicht einmal bei uns intern, und genau diesen nächsten Schritt, den echten Arbeitskontext ins Kontextfenster zu bringen, hat heuer mit MCP-Servern und Ähnlichem richtig Fahrt aufgenommen.
Erfolgreiche KI braucht also drei Kompetenzen, nicht zwei. Backend AI, Frontend AI und die Fähigkeit, beide zu verbinden, und genau die liegt meistens bei niemandem.
Die Abkürzung, die dir nur deine eigene Wahrheit liefert
Mit meinem Hintergrund könnte ich mich hinsetzen und einen Copilot-Agent bauen, der von ganz oben im Stack direkt bis zu den Daten durchgeht, in sechzig, siebzig Minuten, wenn ich die Rechte hab. Easy. Und dann kommt ein Kollege und sagt, schön, das ist deine Lösung mit deiner Interpretation der Daten. Bauen fünf Leute diese Abkürzung, gibt es fünf Definitionen derselben Kennzahl, und in einem großen Unternehmen fängt das schon bei etwas so Grundlegendem an wie der Frage, wie Marge definiert ist. Die alte SharePoint-Regel gilt immer noch: Nur weil du es kannst, heißt das nicht, dass du es solltest.
Jens hatte die passende Geschichte von seiner Seite. ORAYLIS wurde früher für Business Intelligence angefragt, irgendwann wollten alle stattdessen Self-Service-BI, und sie mussten jedes Mal erklären, dass es zuerst einen stabilen BI-Kern braucht, bevor man die Leute mit Self-Service loslässt. Es ist dieselbe Geschichte noch einmal, nur diesmal geht es um Kontext.
Wie die Verbindung in der Praxis aussieht
Gezeigt haben wir das mit zwei Demos. In der ersten liegen Einkaufsdaten in Microsoft Fabric, die eine Version der Wahrheit für den Einkauf. Früher musste man SQL können, um damit zu arbeiten. Heute schaltet man einen Fabric Data Agent ein und stellt Fragen in normaler Sprache, das ist Backend AI. Dann der Wechsel ins Frontend. Eine Kollegin im Einkauf soll den drei wichtigsten Lieferanten jede Woche eine Mail schicken, also muss sie zuerst wissen, wer diese drei sind. Das muss sie nicht selbst erheben und keine Geschäftslogik definieren. Aus Microsoft 365 Copilot heraus zapft sie einfach den Backend-Agent an, der die qualitätsgesicherte Antwort liefert, und macht von dort mit ihrem eigenen Arbeitsablauf weiter.
Die zweite Demo geht in die andere Richtung, und nach der fragen die Leute am meisten. Kann man Daten lesen und interpretieren, will man sie schnell auch ändern, direkt aus dem Agent heraus. Eine eingebaute Funktion dafür gibt es noch nicht, aber man kann einen MCP-Server schreiben, ein Tool, das in den Kontext des Harness geladen wird und versteht, dass du diesen oder jenen Datensatz im anderen System geändert haben willst. Das ist dieselbe Geschichte wie Teams vor zehn Jahren, kein Kontextwechsel mehr, du bleibst in einem Fenster. Nicht verhandelbar ist die Identität. Das Schreiben muss unter meiner Identität passieren und nachvollziehbar sein, genau so, als hätte ich die Änderung selbst im System gemacht. Weil Copilot unter meiner Identität läuft, ist das lösbar, und erst das macht den ganzen Kreislauf sicher.

Meine Empfehlung bleibt, zuerst das Lesen zu bauen und das Schreiben dazuzunehmen, wenn es wirklich jemand verlangt. Einen Agent schreiben zu lassen ist technisch sehr einfach. Als Mensch dabei die Kontrolle zu behalten ist viel schwieriger, und Jens hat es besser gesagt, als ich es könnte: Human Control ist für uns inzwischen das wichtigere Stichwort als Human in the Loop. Du musst darauf vertrauen können, dass der Agent genau die eine atomare Operation ausführt, die du wolltest, und nicht etwas, das als „A1, A2, A3, A4“ zurückkommt und nebenbei still mehr verändert hat.
Um von Pharma- oder Automobil-Beispielen wegzukommen, haben wir auch meine Pizza Factory gezeigt, eine komplette .NET-Anwendung, die eine Pizzeria simuliert, stellvertretend für irgendein Drittsystem, denn das Geschäft läuft nicht nur in Microsoft 365. Mit den SharePoint Copilot Apps und MCP Apps gibt Copilot nicht mehr nur Text zurück, sondern echte, interaktive Oberflächen, zum Zeitpunkt des Vortrags noch in Preview. Gebaut war das Ganze an einem Nachmittag, und das Repository ist öffentlich.
Die Backend-Seite stellt Microsoft gerade unter dem Label IQ auf. Fabric IQ steht für Daten, Work IQ ist die Weiterentwicklung von Microsoft Graph mit Zugriff in natürlicher Sprache auf alles in Microsoft 365, und Foundry IQ deckt das institutionelle Wissen ab, das in tausenden Dokumenten irgendwo anders liegt und noch aufbereitet werden muss, bevor eine KI gut damit arbeiten kann. In Fabric IQ ist Jens zu Hause, in Work IQ sind wir es.
Die IT baut den Platz, der Fachbereich spielt
Ich war früher Nachwuchstrainer im Fußball, und eines haben sie uns dort beigebracht: die Kinder spielen lassen. Spielen Sieben-, Acht- und Neunjährige und du kommst dazu, ist der Instinkt, alles zu korrigieren. Lass es. Lass sie spielen, bis sie fertig sind, und dann beginnt das Training. Übertragen auf KI wünsch ich mir, dass die IT ihre Aufgabe darin sieht, den Platz zu bauen. Der Rasen ist gemäht, das Wasser rinnt ab, wenn es regnet, das Flutlicht funktioniert, die Kabinen sind da, und die Linien sind klar, sprich Security und Governance. Innerhalb der Linien spielt der Fachbereich. Die IT kann nicht jede Abteilung an der Hand nehmen und zu ihrem Glück führen, das skaliert nicht. Was sie kann, ist zentrale Services bereitstellen und einen Rahmen, in dem sich eine Maker-Community frei bewegen kann, ohne dass etwas kaputtgeht.
Wo man anfängt
Zum Schluss hatten wir vier Fragen, und es sind dieselben, die wir in jedem ersten Workshop stellen würden. Erstens Kontext und Standortbestimmung: Wie ist der Stand eurer Daten und ihrer Nutzung, und was wissen die beiden Seiten voneinander? Zweitens Zielbild und Wirkung: Was soll KI wirklich verändern, und woran erkennt ihr Erfolg? Schon „wir führen Copilot ein“ und „wir führen Copilot gut ein“ sind zwei verschiedene Ziele, und eine Zahl im Geschäftsbericht hängt selten nur an Copilot. Drittens Machbarkeit und Leuchtturm: Was geht heute schon, was braucht erst ein Fundament, und welcher Fall überzeugt beide Seiten? Viertens Fokus und Fahrplan: Was passiert in den nächsten sechs Monaten, und wer entscheidet was?
Beim Fahrplan komm ich immer wieder auf Eisenhowers Satz zurück, dass Pläne nichts sind, Planung aber alles ist. Mit einer neuen Ankündigung alle paar Wochen ist ein Plan nach vier Wochen alt, also lieber in kürzeren Zyklen planen, drei Monate, vielleicht sechs, und aushalten, dass der Nebel dichter wird, je weiter man hinausschaut.
Und die richtigen Rollen gehören an einen Tisch: IT-Leitung, CIO oder CDO, die Leitung von Data, BI oder Analytics, wer Microsoft 365 und Modern Work verantwortet, eine Fachbereichsleitung mit KI-Ambitionen und mindestens eine Person, die entscheiden kann. Mich erinnert das an den Weg von On-Premises in die Cloud, als die Exchange-, SharePoint- und Directory-Leute plötzlich miteinander reden mussten, obwohl sie jahrelang im selben Gebäude gesessen sind. Jens hat dasselbe von seiner Seite erzählt. Bei manchen Großkunden in der Region sind unsere beiden Firmen seit vielen Jahren Dienstleister und haben noch nie miteinander geredet, und die Abteilungen auch nicht. ORAYLIS baut die belastbaren Zahlen, wir schulen die Leute, die sie brauchen, und die wissen oft gar nicht, dass es diese Zahlen gibt.
KI darf ruhig zweimal entstehen. Sie sollte nur nicht bei zwei Versionen der Wahrheit landen.
Die Folien
Unser Deck in der deutschen Originalfassung, so wie wir es gehalten haben.

Enjoyed this post? Let's connect on LinkedIn:
Follow on LinkedIn →

