KI ist heute in nahezu jeder Organisation angekommen. Gleichzeitig entstehen unzählige Kennzahlen: Anzahl der Prompts, aktive Nutzer, entwickelte Use Cases oder geschulte Mitarbeitende. Selten zuvor war die Einführung einer neuen Technologie so transparent messbar. Dennoch bleibt die entscheidende Frage oft unbeantwortet: Welcher konkrete Wertbeitrag entsteht daraus für das Unternehmen?
Diese Frage ist alles andere als trivial. Denn die meisten Aussagen zum Erfolg von KI-Initiativen basieren auf drei Quellen und keine davon liefert ein wirklich belastbares Bild des tatsächlichen Business Impacts.
Drei Quellen – ein unvollständiges Bild
Demonstrationen. Eine gute Demo ist ein Versprechen, kein Beweis. Sie läuft auf ausgewählten Beispielen mit vorbereiteten Daten begleitet von jemandem, der das System kennt. Was sie zeigt, ist Machbarkeit. Was sie nicht zeigt, ist der Montagmorgen im Regelbetrieb – mit unvollständigen Angaben, Sonderfällen und Kolleg:innen, die keine Zeit haben, ein Ergebnis nachzurecherchieren.
Nutzungszahlen. Sie sagen, ob Menschen ein Werkzeug anklicken. Sie sagen nichts darüber, ob dadurch ein Vorgang schneller abgeschlossen, eine Entscheidung besser getroffen oder eine externe Rechnung kleiner wurde. Hohe Nutzung kann Wirkung bedeuten – oder dass viele Menschen viel Zeit damit verbringen, Antworten zu prüfen, die sie am Ende nicht verwenden.
Business Cases in Pilotgröße. Der häufigste Fehler ist kein Rechenfehler, sondern eine Verwechslung: Gerechnet wird der Anwendungsfall, nicht der Betrieb. Integration, Pflege des Kontexts, Prüfschritte, Verbrauchskosten pro Anfrage bleiben außen vor. Solche Fälle sind wirtschaftlich, solange sie klein bleiben. Das ist das Gegenteil dessen, was Skalierung bedeutet.
Warum die korrekte Einschätzung des Wertbeitrags von KI gerade jetzt besonders relevant ist
Bei klassischer Software durfte ein unscharfes Bild lange bestehen bleiben. Eine Lizenz kostete, was sie kostete, und Erfolg hieß vor allem: mehr Menschen nutzen dasselbe System zum gleichen Preis.
Bei KI ist das in zwei Punkten anders. Erstens erzeugt jede zusätzliche Nutzung zusätzliche Kosten. Erfolg treibt hier die Ausgaben, nicht nur den Nutzen. Wer das nicht modelliert hat, wird von seinem eigenen Fortschritt überrascht. Zweitens übernehmen diese Systeme zunehmend nicht nur Vorschläge, sondern Arbeitsschritte. Damit wird die Frage nach Verantwortung sehr konkret: Wer prüft, wer haftet, und wer entscheidet, dass etwas nicht mehr eingesetzt wird?
Das eigentliche Risiko ist dabei nicht das offene Scheitern. Ein abgebrochenes Projekt ist ein sichtbares Ereignis mit einer Lehre. Teurer ist das stille Muster: Initiativen, die weiterlaufen, Nutzungszahlen liefern, in Statusberichten grün stehen und den Punkt nie erreichen, an dem sie im Ergebnis erscheinen. Sie sehen aus wie Fortschritt und sind ein Plateau.
Kontext und Steuerung: Zwei Lücken, die sich nicht einzeln schließen lassen
Meist gelten zwei Ursachen gleichzeitig und sie lassen sich nicht getrennt beheben:
Die erste ist eine Steuerungslücke: kein Verantwortlicher mit Budget, keine gemessene Ausgangslage, keine Zahl zu den Kosten pro Fall, kein Gremium, das monatlich mit Daten entscheidet. Vorhanden ist meist ein Regelwerk und Regelwerke beantworten, was erlaubt ist, nicht, wer wofür einsteht.
Die zweite ist eine Kontextlücke: Ein Sprachmodell ohne Zugang zum Arbeitszusammenhang ist wie ein sehr belesener Praktikant am ersten Tag, ohne Systemzugriff, ohne Vorgeschichte, ohne Kenntnis darüber, wer im Haus was entscheidet. Es liefert plausible, allgemeine Antworten. Plausibel genügt für eine Demo, nicht für eine Entscheidung.
Steuerung ohne Kontext erzeugt die Verwaltung von Dingen, die im Betrieb kaum funktionieren werden. Kontext ohne Steuerung erzeugt das Gegenteil: viele nützliche Helfer, die schnell entstehen und die nur selten inventarisiert, geprüft, bepreist oder in letzter Konsequenz auch wieder abgeschaltet werden. Beides fühlt sich nach Fortschritt an. Beides endet auf demselben Plateau. Wirkung entsteht deshalb nicht als Summe, sondern als Produkt: Kontext mal Steuerung mal Verantwortung. Ist ein Faktor null, ist das Ergebnis null.
Ein AI Operating Model ist mehr als Governance
Auf die Steuerungslücke reagieren viele Organisationen mit einem Regelwerk, einer Richtlinie oder einem Kompetenzzentrum. Das ist nicht falsch, aber es ist ein Bruchteil der Aufgabe und meist genau der Teil, der bremst, ohne zu helfen.
Ein AI Operating Model beantwortet nicht nur, was erlaubt ist, sondern eine deutlich unangenehmere Frage: Wer arbeitet künftig wie mit wem, und wer verantwortet das Ergebnis? Das betrifft drei Ebenen.
Richtung. Ein priorisiertes Wertportfolio statt einer Ideenliste. Acht bis zwölf Hebel entlang weniger Ende-zu-Ende-Prozesse, mit einer bewussten Nein-Liste. Dazu Unit Economics, also Kosten pro Fall statt Cloud-Sammelrechnung.
Menschen und Arbeitsweise. Hier ist die Lücke in den meisten Organisationen am größten, und hier entscheidet sich Skalierung. Es braucht neue Rollen mit echten Namen: Verantwortliche für den Wertbeitrag, einen Verantwortlichen pro Agent für Zweck, Grenzen, Qualität und Abschaltung – und Fachexperten, die im Betrieb Stichproben prüfen. Es braucht differenzierte Kompetenzen statt Schulung für alle: Alle müssen KI-mündig sein, ein Teil muss Kontext geben und Abläufe konfigurieren können, wenige bauen. Am meisten unterschätzt wird die Führungsebene: Wer KI nicht in seiner Prozesslandkarte denken kann, blockiert Hunderte Menschen. Und es braucht eine Entscheidung pro Prozessschritt, wie Mensch und Agent zusammenarbeiten – schlägt der Agent nur vor, erledigt er delegierte Teilaufgaben oder arbeitet er unter Stichprobenkontrolle? Damit verschiebt sich auch, was „fertig“ heißt, wenn der erste Entwurf in acht Sekunden vorliegt.
Fundament. Es braucht ein Verzeichnis, in dem jeder produktive Agent registriert ist, klar definierte Leitplanken, automatisierte Qualitätsprüfungen und Kostentransparenz pro Vorgang. Der einfachste Weg im Unternehmen muss der konforme sein, sonst gewinnt die Schatten-IT.
Zusammengehalten wird das von einem gemeinsamen Herzschlag – wöchentlich Qualität und Vorfälle, monatlich Nutzung und Kosten pro Fall, quartalsweise die Entscheidung über Finanzierung, Skalierung oder Abschaltung.
Kein Gremium ohne Zahlen, keine Zahlen ohne Gremium.
Was der Atlassian Teamwork Graph anders macht als eine Suche
An einer Stelle stößt jedes Betriebsmodell an seine Grenze. Governance kann festlegen, wer für Kontext verantwortlich ist. Erzeugen kann sie ihn nicht.
Der verbreitete Ansatz dafür ist ein Suchindex über Dokumente: Inhalte werden zerlegt, in Vektoren übersetzt und bei einer Frage nach Ähnlichkeit wieder herausgesucht. Das funktioniert für „Was steht in unserer Reiserichtlinie?“. Es funktioniert nicht für die Fragen, die im Arbeitsalltag wirklich anfallen, weil deren Antwort nicht in einem Dokument steht, sondern in Beziehungen zwischen vielen: Welche Anforderung hängt an welchem Vorgang? Wer entscheidet darüber? Was blockiert was, und seit wann? Wurde etwas Vergleichbares bereits verworfen, und mit welcher Begründung?
Genau diesen Unterschied adressiert Atlassians Teamwork Graph. Er modelliert nicht Textabschnitte, sondern die Objekte der Arbeit – Menschen, Teams, Ziele, Vorgänge, Dokumente, Code, Gespräche – und die Kanten zwischen ihnen: gehört zu, blockiert, wurde entschieden von, ersetzt, verweist auf. Diese Struktur entsteht aus Systemen, in denen Arbeit ohnehin stattfindet, und lässt sich über Konnektoren auf Quellen außerhalb der Atlassian-Welt ausdehnen. Auf diesem Graphen setzen Atlassians Rovo-Agenten auf: Sie recherchieren, fassen zusammen und übernehmen Arbeitsschritte nicht auf Basis eines Dokumentenindex, sondern auf Basis der Beziehungen zwischen den Objekten der Arbeit. Drei Eigenschaften machen den praktischen Unterschied:
Mehrstufige Fragen werden beantwortbar. Ein Index findet, was einer Frage ähnlich sieht. Ein Graph kann Ketten verfolgen. Von einem Unternehmensziel über die zugehörigen Initiativen und Vorgänge bis zu der offenen Abhängigkeit, die das Ziel gefährdet. Das ist keine Textähnlichkeit, das ist Struktur.
Historie bleibt erhalten. Der Graph kennt nicht nur den aktuellen Stand, sondern den Weg dorthin. Damit wird begründbar, warum etwas so ist, wie es ist und das ist häufig wertvoller als eine Zusammenfassung des Ist-Zustands.
Rechte und Herkunft sind mitgedacht. Ein Agent erbt die Zugriffsrechte des Menschen, für den er arbeitet, und jede Antwort kann nachvollziehbar auf ihre Quellen geprüft werden. Beides ist keine Formalie. Ohne Rechtevererbung entsteht ein Compliance-Vorfall mit Anlauffrist. Ohne Nachvollziehbarkeit wird eine Antwort zur Kenntnis genommen, aber nicht verwendet – und ohne Verwendung gibt es keinen Nutzen, egal wie gut das Modell ist.
Der letzte Punkt ist auch der Grund, warum diese Ebene offen sein muss: Atlassians Rovo-Agenten arbeiten auf diesem Graphen, aber über Standards wie das Model Context Protocol (MCP) können auch Agenten anderer Anbieter auf denselben Arbeitskontext zugreifen. Kontext gehört nicht in ein einzelnes Werkzeug, sondern unter das ganze Werkzeugportfolio.
Und genau hier greifen beide Ebenen ineinander. Ein Graph macht Antworten brauchbar. Ein Operating Model macht sie belegbar, bezahlbar und verantwortet. Wer nur das eine hat, hat die halbe Wahrheit und die hält keiner Vorstandsvorlage stand.
Vier Prinzipien für den Weg aus dem Pilotstatus
Erst weniger, dann größer. Fünf Anwendungsfälle mit Verantwortlichen, Ausgangswerten und Kostentransparenz sind aussagekräftiger als fünfzig, die nebeneinanderher laufen. Skalieren heißt weglassen.
Agenten wie Mitarbeitende behandeln. Aufgabenbeschreibung mit klaren Grenzen, Einarbeitung mit Zugriffsrechten, Probezeit mit Stichproben, Leistungsbetrachtung im Quartal und ein geregeltes Ausscheiden. Die meisten Organisationen haben einen Prozess, um jemanden einzustellen. Kaum eine hat einen, um einen Agenten wieder abzuschalten.
Kontext ist ein Produkt, kein Projekt. Arbeitszusammenhang verfällt. Ohne benannte Verantwortung für Aktualität und Aufräumen ist er nach sechs Monaten eine Fehlerquelle. Und bevor ein 18-monatiges Datenprojekt startet, lohnt der Blick darauf, wie strukturiert der Arbeitskontext in Vorgangs- und Wissenssystemen bereits vorliegt. Häufig deutlich besser als vermutet.
Wirkung statt gewonnener Zeit. „Gesparte Stunden“ sind eine Zwischengröße. Ein tragfähiger Nutzennachweis hat eine zusätzliche Zeile: Wohin fließt die gewonnene Kapazität. In Wachstum, in Qualität, in den Abbau eines Rückstands, in geringere externe Ausgaben? Wer diese Zeile offenlässt, hat das Gespräch über den Wert nicht geführt, sondern verschoben. Teams spüren das übrigens sehr genau. Wo die Frage offen bleibt, sinkt die Bereitschaft, Effizienzgewinne überhaupt sichtbar zu machen.
Dominik Frosch und Harry Kuessner sprechen bei der Handelsblatt Jahrestagung „Future Workplace“ über „Vom Pilot zum Business Impact: Was es wirklich braucht, um KI über den Pilotstatus hinaus zu skalieren“.