Ein KI-Tool zu bauen ist leicht. Ein Unternehmen zu verändern nicht.

Viele Softwaresysteme bedeuten nicht automatisch, dass in einem Unternehmen weniger wiederkehrende Arbeit anfällt. Neben den Kernsystemen bleiben Tabellen, E-Mails und kleine Lösungen bestehen, die Mitarbeitende selbst aufgebaut haben. KI beschleunigt die Entwicklung neuer Werkzeuge für solche Aufgaben. Die Arbeitsweise des Unternehmens verändert sich dadurch nicht im gleichen Tempo.

In „AI, tools and transformation“ beschreibt Benedict Evans genau diese Lücke. Ein Werkzeug leichter bauen zu können, bedeutet nicht, das richtige Problem leichter zu erkennen, eine tragfähige Lösung zu finden oder andere zur Nutzung zu bewegen. Sobald eine Lösung, die eine Person für sich entwickelt hat, die Arbeit und Entscheidungen anderer Teams beeinflusst, entstehen weitere Fragen. Es muss geklärt werden, wer sie wartet, welchen Daten man vertraut und wer einen Fehler korrigiert.

Diese Beobachtung trifft auch meine eigene Arbeit. Als wir versuchten, Gespräche zwischen Interessenten und dem Vertrieb mit KI auszuwerten, zeigte sich, wie viele Informationen und Entscheidungen hinter einer Aufgabe stecken, die zunächst einfach wirkte.

Das Gespräch allein reicht nicht

Auf den ersten Blick war die Aufgabe klar: Wir geben Gesprächsprotokolle an ein KI-Modell und lassen sie nach festgelegten Kriterien bewerten. Bald wurde deutlich, dass eine gute Beurteilung mehr als den Gesprächsverlauf braucht. Wir mussten Daten aus verschiedenen Quellen heranziehen.

Auch die Daten in unserem CRM-System, mit dem wir Kundenbeziehungen verwalten, waren nicht für diese Analyse vorbereitet. Die Einträge sind so angelegt, dass Mitarbeitende sich schnell einen Überblick über Kunden oder Interessenten verschaffen können. Für diesen Zweck ist die Struktur nützlich. Für eine detaillierte KI-Analyse wurde sie zum Problem.

Von einem Modell können wir nicht erwarten, dass es die Bedeutung selbst ergänzt, die ein erfahrener Mensch beim Blick auf einen Eintrag mitdenkt. Die Daten, die wir ihm geben, müssen deutlich genug machen, wofür eine Information steht. In dieser Hinsicht waren unsere Daten uneinheitlich. Erst im Projekt wurde der Unterschied sichtbar zwischen einem Eintrag, der die tägliche Arbeit unterstützt, und Daten, die sich für eine Analyse eignen.

Wir fanden außerdem Daten, die seit einiger Zeit nicht aktualisiert worden waren und nicht mehr aktiv genutzt wurden. Ein Teil davon könnte für Analysen wieder nützlich sein, die mit KI heute möglich werden. Zuerst mussten wir jedoch prüfen, wie aktuell und verlässlich diese Daten sind. Dass Daten noch im System liegen, bedeutet nicht, dass sie sich unmittelbar in eine Analyse übernehmen lassen.

Wir hatten zunächst geplant, Gesprächsprotokolle auszuwerten. Dann mussten wir neu bestimmen, welche Informationen wir brauchen, um den Kunden und die Umstände des Gesprächs zu verstehen.

Für ein gutes Gespräch gibt es kein fertiges Kriterium

Die Daten zusammenzuführen, reichte ebenfalls nicht. Eine Bewertung anhand allgemeiner Kriterien deckte sich nicht immer mit der Einschätzung der Führungskräfte zum selben Gespräch. Sie berücksichtigten Details und Ausnahmen, die das Modell nicht von selbst erkennen konnte.

Deshalb haben wir die Bewertungskriterien und Prompts mehrfach überarbeitet. Wir mussten genauer festhalten, worauf es in welcher Situation ankommt und welche Details das Ergebnis verändern.

Von außen mag das nach besser formulierten Anweisungen für ein Modell aussehen. Doch bevor wir eine Anweisung verbessern können, müssen wir die Begründung für unsere eigene Entscheidung erklären. Warum bewerten wir ein Gespräch als erfolgreich? Warum beurteilen wir dasselbe Verhalten in einem anderen Fall anders? Eine Ausnahme, die für Menschen im Unternehmen selbstverständlich ist, bleibt für das Modell unsichtbar, solange sie nicht ausdrücklich beschrieben wird.

Auch jede Einschätzung einer Führungskraft ungeprüft als richtig zu behandeln, löst das Problem nicht. Wir müssen verstehen, woher die Abweichung kommt: Haben wir dem Modell Informationen vorenthalten, ein Kriterium zu unklar gelassen oder müssen wir unsere eigene Bewertung noch einmal prüfen?

Diese Erfahrung hat mir gezeigt, wie viel Arbeitswissen in alltäglicher Urteilskraft steckt. Beim Aufbau des Analysewerkzeugs mussten wir dieses Wissen ebenfalls sichtbar machen. Zeit brauchte vor allem die Arbeit, Dinge ausdrücklich zu beschreiben, von denen das Unternehmen annahm, sie bereits zu wissen.

Wir entscheiden auch, wo das System endet

Manche Grenzen lassen sich nicht allein aus Daten oder dem Modell ableiten. Das Gesundheitswesen ist ein direktes Beispiel.

Ein Chatbot kann helfen, Informationen von einem Patienten zu erfassen. Erhält dasselbe System die Aufgabe, eine Diagnose zu stellen, verändert sich die Verantwortung, die es übernimmt. Die EU-Medizinprodukteverordnung erfasst beispielsweise auch Software, die für bestimmte medizinische Zwecke bestimmt ist. Entscheidend ist die Zweckbestimmung. Allein der Einsatz einer Software in einer Gesundheitseinrichtung macht sie nicht zu einem Medizinprodukt.

Diese Abgrenzung erläutere ich ausführlicher in meinem türkischsprachigen Beitrag über den Unterschied zwischen Chatbots, Triage und Medizinprodukten.

Wir haben uns entschieden, diagnostische Entscheidungen bei den Ärzten zu belassen. Die Grenzen der Branche und des regulatorischen Rahmens waren Teil dieser Entscheidung. Die ärztliche Entscheidungshoheit zu schützen, entsprach aber auch unserer eigenen Arbeitsweise. Dass ein Modell eine Antwort erzeugen kann, ist kein ausreichender Grund, ihm diese Entscheidung zu übertragen.

Ein System zu entwickeln heißt deshalb auch festzulegen, wo es endet. Informationen zu erfassen, sie für eine Bewertung vorzubereiten und eine medizinische Entscheidung zu treffen, kann im selben Gespräch stattfinden. Die Verantwortung ist jeweils eine andere.

Ein persönliches Projekt ist etwas anderes als die Arbeit des Unternehmens

In persönlichen Projekten habe ich den direkteren Nutzen von KI erlebt. Als ich die Infrastruktur von PeşinTaksit vereinfacht habe, konnte ich eine Aufgabe in etwa einer Stunde erledigen, für die ich sonst keine Zeit eingeplant hätte. Das Projekt gehörte mir, ich kannte den Bedarf und konnte die Änderung selbst entscheiden.

Bei der Analyse von Verkaufsgesprächen mussten dagegen die Aufgabenbeschreibung, die Daten und die Bewertungskriterien gemeinsam betrachtet werden. Die kurze Entwicklungszeit aus dem einen Fall auf den anderen zu übertragen, würde einen Teil der nötigen Arbeit aus der Rechnung ausblenden.

Wer Zeit oder Budget für ein KI-Projekt plant, muss deshalb auch die Datenaufbereitung und die gemeinsame Bewertung mit Menschen einplanen, die die Arbeit kennen. Das sind keine unnötigen Verzögerungen vor dem Einsatz des Werkzeugs. Sie gehören dazu, damit es nutzbar wird.

Ein funktionierender Prototyp zeigt, dass ein Projekt vorankommt. Ob ein Unternehmen auf dieser Grundlage Entscheidungen treffen kann, lässt sich erst erkennen, wenn Daten und Kriterien gemeinsam geprüft werden.