Viel AI ist gut, nur AI ist oft schlecht

Worum es in dieser Folge geht

Ich lese gerade viele Studien, die sagen, 95 Prozent aller Gen-AI-Use-Cases kommen nie in den produktiven Betrieb. Gleichzeitig hat HMS Analytical Software nach eigener Aussage deutlich mehr als 30 Gen-AI-Projekte abgeschlossen. Darüber habe ich mit Julian Kurz gesprochen. Julian beschäftigt sich bei HMS mit generativer KI und hat natürliche Sprachverarbeitung studiert. Er kommt also nicht nur aus der Praxis, sondern auch aus der Theorie.

Mein Ausgangspunkt war eine Frage aus dem Vorgespräch: Gibt es durch den Hype mehr reine Gen-AI-Use-Cases, oder mehr Use Cases mit unternehmenseigenen Daten? Julians Antwort: Das Verhältnis ist in seiner Arbeit gleich geblieben. Und genau das ist der Kern dieser Folge.

Die Storyline

Skepsis gegenüber der 95-Prozent-Zahl

Julian wollte die Lorbeeren nicht einfach einsacken. Er weiß nicht bei jedem Projekt, ob am Ende wirklich ein Endnutzer damit arbeitet. Und HMS wird als Beratung aktiv geholt, also bei Vorhaben, wo schon Druck, Geld und Überlegungen da sind. Wer sich dagegen schnell etwas zusammenvibecodet, scheitert eher. Trotzdem: Seine eigenen Projekte der letzten Jahre sind nach seiner Einschätzung alle in Produktion und mit gutem Feedback.

Also ich bin bei diesen Zahlen selber persönlich immer sehr skeptisch, weil das auch tatsächlich nicht meine gelebte Realität in Unternehmen wirklich jetzt darstellt.

Viel AI ist gut, nur AI ist oft schlecht

Meine These dagegen: Wir diskutieren seit zehn, fünfzehn Jahren über Daten und Infrastruktur, haben Data Scientists statt Engineers eingestellt, und die Datenvorbereitung ist vielerorts immer noch nicht abgeschlossen. Einen ChatGPT-Use-Case, der beim Übersetzen hilft, baut man schnell. Der große Mehrwert liegt aber in den unternehmenseigenen Daten, und die fehlen oft, wenn man in der Wertschöpfungskette zurückschaut. Der POC funktioniert, beim Rollout ins ganze Unternehmen bricht es.

Julian hat mir nicht widersprochen, im Gegenteil. Die Leute unterschätzen massiv, wie wenig von einem AI-Projekt wirklich AI ist. Er sitzt nicht 90 Prozent der Zeit vor einem Prompt und optimiert ihn aufs Wort, sondern baut Datenpipelines.

Ich habe das Gefühl, viel AI ist gut, aber nur AI ist oft schlecht.

Sein Vorgehen: einen Prozess in Stücke zerschneiden, an jeder Stelle sicherstellen, dass die richtigen Daten reinkommen, und die KI eher eine Form ausfüllen lassen. So bleibt alles kontrolliert, und die Domänenexperten haben echten Nutzen davon.

Aus einer Woche werden Minuten

Sein Beispiel kommt aus der Pharmaindustrie. Dort arbeiten viele Spezialistinnen und Spezialisten, die fachlich sehr gut sind, aber keine eigenen ITler haben. Sie brauchen immer wieder Visualisierungen für Studien, Einreichungen oder interne Meetings. In Großkonzernen wartet man schnell eine Woche, bis jemand aus der IT Zeit hat.

HMS hat dafür eine Anwendung gebaut, mit der sich die Leute den Code selbst erzeugen lassen. Zeig mir, was in den Daten steckt, gib mir diese Art von Visualisierung, filtere nach dieser Bedingung. Der Clou: Die KI darf nur aus validiertem Code auswählen. Mit diesem Maß an Kontrolle hilft sie wirklich.

Spannend fand ich, dass dieselbe App drei Nutzergruppen bedient. Wer selbst programmiert, sieht den Code und kann im Live-Terminal anpassen. Wer gar nicht programmiert, klickt Buttons, hinter denen vorgefertigte Prompts liegen. Und wer lieber schreibt, nutzt den Chat.

Der Fall: Customer Service

Dann habe ich Julian einen Fall aus meinem Alltag gegeben: ein produzierendes Unternehmen mit 3000 Mitarbeitenden, komplett digitalisierter Customer Service, Anfragen über E-Mail, Telefon und Briefe. Reklamationen, Produktfragen, Sendungsstatus und echte Produktberatung, etwa welche Socken zu Cowboy-Stiefeln passen. Je mehr wir direkt über den eigenen Online-Shop verkaufen, desto mehr Anfragen landen bei uns. Das kostet Geld, und wir skalieren bisher über Personal.

Julians erste Antwort hat mir gefallen: erst einmal ganz viel zuhören.

Du bist als KI-Experte immer in dieser peinlichen Position: Du hast gelernt, Probleme zu lösen, aber nichts über irgendein echtes Problem.

Er will die Hybris vermeiden, mit Algorithmen den Job anderer Leute zu lösen und nach sechs Monaten festzustellen, wie hart dieser Job eigentlich ist. Weil KI schlecht darin ist, deterministisch immer dasselbe Ergebnis und hundertprozentige Sicherheit zu liefern, lenkt er die Diskussion zuerst auf beratende Funktionen und Prozesse, bei denen ein Fehler nicht so schlimm ist. Seine Ideen: Kundinnen und Kunden gar nicht erst in den Kanal schicken, sondern ihnen auf der eigenen Seite Antworten geben. Bestehende Gespräche als Datengrundlage nutzen, sauber anonymisiert. Ein Backend bauen, aus dem mehrere Use Cases schöpfen, etwa auch der First-Level-Support. Und das Routing im Second-Level-Support vorsortieren, wie er es bei einer Versicherung und einer Bank gesehen hat.

Ich habe dann aufgelöst, was wir uns tatsächlich angeschaut haben. Anfragen werden kategorisiert und wie beim Dispatching im IT-Service den richtigen Teams zugewiesen. Themen, die immer wieder dieselbe Antwort bekommen, haben wir automatisiert. Das Ticket-Level ist dadurch massiv gesunken. Der nächste Schritt: Wir haben keine große Dokumentation über alle Fälle. Also wollen wir aus den Fällen der letzten Jahre per Reverse Engineering eine Dokumentation erstellen, natürlich erst nach der Klärung mit dem Datenschutz.

Julian hält das für gut machbar. Schnelle Algorithmen holen in Millisekunden ähnliche Texte heraus, die KI liest sie dann. Man kann aber auch weitergehen und Metadaten anreichern, zum Beispiel per semantischer Analyse, ob ein Kunde im Gespräch wütender geworden ist. Aus einem Projekt bei einer großen Firma kennt er einen schönen Nebeneffekt: Die Originaldaten durfte sie rechtlich nicht speichern, die KI-Zusammenfassung schon. Allein das war schon ein Use Case.

Knowledge Graph, Semantic Layer, Kontext

An dieser Stelle wollte ich etwas sortieren, das mich selbst beschäftigt. Für mein eigenes Podcast-Setup hat mir jemand gesagt, ich bräuchte auf jeden Fall einen Knowledge Graphen. Mein Herz schlug sofort höher, neue Methodik, muss ich ausprobieren. Zum Glück habe ich mich erwischt und erst einmal hinterfragt, ob das für mein Konzept überhaupt sinnvoll ist. Am selben Tag kam übrigens ein Link, Obsidian sei raus und man müsse jetzt LLM-Wikis bauen.

Julian sieht hinter dem Hype eine Wahrheit: Alle diese Ansätze haben ihre Daseinsberechtigung, aber jeweils klassische Trade-offs.

Graphen willst du eigentlich immer, wenn du eine hohe Verknüpfung erwartest.

Das öffentliche Bild dafür ist ein soziales Netzwerk: Eine Person kennt viele Leute, andere kennen teilweise dieselben, es bilden sich Cluster. Das größte Problem eines Graphen ist, dass er deutlich teurer aufzubauen ist. Man muss alle Regeln für Beziehungen und Zusammenhänge genau aufschreiben, und am Ende fragen, ob der Aufwand, ihn aufrechtzuerhalten, es wert ist. Meine Ergänzung: Je tiefer man den Graphen in die Wertschöpfung zieht, desto mehr Tools und Prozesse profitieren davon. Wer ihn nur in den Customer Service schiebt statt über den Kunden als Ganzes, hebt den Mehrwert nicht, der den Aufwand rechtfertigt. Da waren wir uns einig.

Beim Kunden als Beispiel wird der Nutzen greifbar. Bestellung, Produkt, Kanal und Kunde hängen auf mehreren Ebenen zusammen, und man kann an jedem Punkt einsteigen. Julians wildere Idee dazu: Wenn man für jedes Gespräch festhält, ob die Wut über den Verlauf gestiegen ist, lässt sich fragen, an welchen Produkten besonders viele Kundinnen und Kunden hängen, die wütender geworden sind.

Und der Semantic Layer? Julian trennt die Begriffe nicht so scharf, wie es oft versucht wird. Ein Graph kann der komplette Semantic Layer sein, in dem der ganze Kontext steckt. Wer über den Semantic Layer redet, redet eher über das Design. Kontext ist das, was man für eine konkrete Anfrage daraus herauszieht. Man kann Kontext aber auch ohne Semantic Layer oder Graph herstellen, und es gibt Semantic Layer, die keine Graphen sind. Julian selbst spricht lieber von Context Engineering und vereint gern verschiedene Quellen: Datenbanken, Dokumente, Daten aus dem Prozess. Meine reverse-engineerte Customer-Service-Dokumentation wäre für ihn übrigens kein Knowledge Graph, sondern ein klassisches Kontextdokument.

Das Burger-Rezept

Zurück zur Eingangsfrage. Mein Eindruck, bewusst schwarz-weiß: Viele Unternehmen stellen ChatGPT- oder Copilot-Lizenzen bereit, die Leute beantworten damit E-Mails und übersetzen, aber niemand schaut sich den Gesamtprozess an. Bottom-up hebt man tägliche Effizienzen. Den Prozess top-down zu hinterfragen braucht dagegen gut geplante Projekte, Workshop-Tage und Gespräche mit mehreren Leuten. Dafür nehmen sich viele Unternehmen keine Zeit.

Julian hat das zugespitzt: Leute haben mit KI dieselben Probleme wie mit ihren Partnern, Familien und Eltern. Sein Beispiel ist die Frage nach einem guten Burger-Rezept. Die Industrieküche rechnet die Kosten pro 100 Portionen, der Lifestyle-Blog braucht Wagyu-Beef und schöne Bilder, und jemand anderes will einfach ein Abendessen aus dem Supermarkt. Und dann ärgert man sich, dass die KI keine Gedanken lesen kann.

Eines der Nummer-eins-Trainings, die ich Leuten empfehlen würde, ist Kommunikationstraining, um besser mit KIs zu arbeiten.

Es geht darum, Probleme zu beschreiben, zu zerlegen und zu verstehen. Oft fangen Leute an, ein Problem zu bearbeiten, bevor sie es verstanden haben, und das geht selten gut.

Brauchen wir mehr Kommunikation als Technik?

Daraus habe ich die Frage abgeleitet, ob sich gerade die Skills verändern, die wir brauchen. Als ich vor über 15 Jahren im Agenturbereich angefangen habe, kam ein Entwickler jeden Morgen mit einem Aktenkoffer. Was drin war, habe ich erst nach einem Jahr erfahren: nur seine Hausschuhe. Heute sitzen Entwicklerinnen und Entwickler viel näher an der Fachabteilung und brauchen mehr soziale Kompetenz.

Julian sagt ehrlich, er wisse es nicht, seine Glaskugel sei so gut wie die von allen anderen. Beides kann wahr sein. Wer einen Softwareingenieur einstellt, erwartet weiterhin, dass der bei der Frage Websocket oder REST-API nicht einfach irgendwas klickt. Aber ohne KI von Hand zu programmieren hält Julian inzwischen für hanebüchen, so viel weniger produktiv ist das. Die gewonnene Zeit steckt er in Meetings, in denen er technische Entscheidungen durchdenkt, und ins Design der Harnesses, in denen die KI arbeitet.

Wen ich nächstes Jahr einstellen sollte

Dann wurde es konkret. Ich könnte nächstes Jahr ein oder zwei Rollen besetzen, um den Customer Service mit Technologie besser zu machen, und habe bereits Infrastruktur, BI, Analytics, Marketing Technology, Application-Teams und Softwareentwicklung. Julians Rat: die Person, die im Vorstellungsgespräch die meiste ehrliche Begeisterung für das Problem zeigt. Das hätte er vor fünf Jahren auch gesagt, aber es ist wahrer geworden. Dazu jemand, der sich die Hände schmutzig gemacht hat, denn Theorie hat ihren Platz, ist aber maßlos überschätzt. Ein begeisterter Allrounder also.

Ich hatte eher die kommunikative Person erwartet. In meinen Organisationen habe ich bewusst oder unbewusst immer ein PMO im Data-Bereich aufgebaut: Projektleute nah am Fachbereich, die Probleme verstehen, kleinschneiden und in die Organisation zurückgeben. Früher hieß diese Rolle oft Business Analyst. Ich glaube, sie wird die Königsklasse der AI-Organisation. Julian war hundertprozentig bei mir: Ohne diese Person funktioniert es nicht. Der sehr technische Experte kann der zweite oder dritte Hire sein. Startups haben oft genug Begeisterte und brauchen Workhorses, in Konzernen ist es eher umgekehrt.

Und du kannst jemandem kein intrinsisches Feuer antrainieren.

Was ihn begeistert: Leute in großen Konzernen, die selbst ein Problem sehen, eine komplette Anwendung bauen, und ein Chef, der zuhört und Softwareingenieure holt, um sie richtig umzusetzen. HMS hat mehrere solcher Prototypen schon professionalisiert, auch wenn das nicht die Regel ist.

Unsichtbare Arbeit sichtbar machen

Zum Schluss habe ich ein altes Thema angesprochen. IT und Data stehen selten im Rampenlicht. Niemand klopft einem auf die Schulter, weil in diesem Monat kein Server ausgefallen ist. Unsere Aufgabe ist es eher, die Fachabteilung zum Scheinen zu bringen. Julian hat eine neue Möglichkeit ergänzt, die er tatsächlich sieht: Mit einem guten Semantic Layer lassen sich die Learnings der KI auch denen anbieten, die Produkte oder Marketing gestalten. Und wer die Logs der KI als Self-Service-Plattform für Statusupdates nutzt, spart Meetings. Die Leute müssen nicht warten, bis sie den Experten erwischen, sondern holen sich den Stand selbst.

Privat hat Julian zwei Apps für sich geschrieben. Eine Finanz-App, weil es kein Haushaltsbuch gab, das gleichzeitig Vermögensplanung macht. Und eine graphbasierte Wissensdatenbank zu Meditation und Yoga, in der Lehrreden, Bücher und Videotranskripte verschiedener Lehrer zusammenlaufen, sodass er zu einem Fachbegriff sofort vergleichen kann, wer was dazu gesagt hat. Einen Filmtitel hat er nicht genannt, aber einen alten David-Lynch-Film beschrieben, in dem ein Mann auf einem Rasenmäher seinen Bruder besucht. Das Schöne daran: Es gibt keinen Feind, nur Leute, die einander bei echten Problemen helfen.

Warum mich das besonders umtreibt

AI, Digitalisierung und Data sind für mich Werkzeuge im Werkzeugkasten. Am Ende muss man herausfinden, ob man einen Nagel oder eine Schraube vor sich hat. Dabei hilft Vibe Coding tatsächlich: Wenn die Fachabteilung schon einen Prototyp gebaut hat, ist das Problem oft genauer beschrieben als in jedem Lastenheft, und die IT kann darauf ein besseres Fundament legen.

Was ich aus dem Gespräch mitnehme: Nicht die Wahl zwischen Knowledge Graph, LLM-Wiki oder Semantic Layer entscheidet über ein Gen-AI-Projekt, sondern ob jemand das Problem verstanden hat und mit maximaler Motivation lösen will. Mich interessiert, wie es bei euch aussieht: Wer übersetzt bei euch zwischen Fachbereich und Technik? Schreibt mir.