Ok, Hand aufs Herz: Wenn ich heute Artikel über KI im Unternehmen lese, geht es immer um dasselbe. Chatbots, Sprachmodelle, Governance, Compliance, Sicherheit, und wie man das alles in die bestehende IT bekommt. Alles wichtig, keine Frage, ich schreibe selber darüber. Aber manchmal frage ich mich, ob wir dabei das Ziel aus den Augen verlieren. Wir bauen immer bessere Chatbots, legen immer mehr Kontrolle darum herum und diskutieren, wie wir die Antworten überwachen. War das die Aufgabe? Wir wollten keine Chatbots verwalten. Wir wollten Probleme lösen.
War das die Aufgabe?
Ich sitze regelmässig in Workshops mit Firmen, die wissen wollen, wo KI ihnen hilft. Der erste Reflex ist fast immer derselbe: ein Chatbot auf der Website, ein Assistent im Intranet, der Dokumente durchsucht. Das ist nicht falsch. Es ist nur selten das, was weh tut. Was weh tut, ist der Prozess, bei dem seit Jahren jemand Daten aus drei Systemen von Hand zusammenträgt, weil die drei Systeme nicht miteinander reden. Darüber redet in den Workshops niemand, weil es nicht nach KI klingt. Es klingt nach Arbeit.
Eine Bestellung kommt herein
Nehmen wir einen ganz normalen Geschäftsprozess, einen, den ich aus einem Telekommunikationsprojekt kenne. Eine Bestellung kommt herein. Daten müssen geprüft, Informationen aus verschiedenen Systemen zusammengetragen, Entscheidungen getroffen und weitere Schritte ausgelöst werden. Heute sind daran mehrere Leute und mehrere Anwendungen beteiligt, und die Sonderfälle landen bei den zwei Leuten, die sie seit Jahren kennen.
Jetzt integrieren wir einen Chatbot. Der Mitarbeiter kann Fragen zur Bestellung stellen, Dokumente durchsuchen, sich den Status erklären lassen. Das ist eine Verbesserung. Aber der Prozess ist derselbe. Die Arbeit muss immer noch gemacht werden, die Systeme müssen immer noch miteinander reden, und jemand muss dafür sorgen, dass der nächste Schritt wirklich passiert.
Warum soll die KI hier nur Fragen beantworten? Warum erkennt sie nicht selber, welche Information fehlt, welcher Schritt ansteht, und löst ihn aus? Beim Telco-Prozess habe ich das als Vorschlag beschrieben: Sonderfälle sind nicht zufällig, sie haben Muster, und ein Agent, der die Muster kennt, kann einen grossen Teil davon vorbereiten, bevor ein Mensch draufschaut. Dort liegt die Einsparung. Nicht im Dialogfenster.
Das Problem ist nicht das Modell
Wir haben heute Modelle, die Code schreiben, Dokumente analysieren, Zusammenhänge erkennen. Trotzdem scheitern viele Projekte daran, aus einem Prototyp eine Lösung zu machen, die jeden Tag läuft. Warum? Weil ein Unternehmen nicht aus Informationen besteht. Es besteht aus Geschäftsregeln, Abhängigkeiten, Fachbereichen, Sicherheitsanforderungen und Anwendungen, die über Jahrzehnte gewachsen sind. Ein Modell kennt das nicht. Und nur weil man ihm tausend Dokumente gibt, hat es die Architektur und die Prozesse nicht verstanden.
Ich habe das zum ersten Mal in voller Grösse bei einem grossen Telekommunikationsanbieter gesehen, lange bevor es KI hiess: Die Daten liegen nie an einem Ort und nie in einer Form. Kundendaten hier, Vertragsdaten dort, Nutzungsdaten in einem dritten System, jedes mit eigener Wahrheit. Und die erste Frage, die ich seither in jedem Erstgespräch stelle, ist nicht, welches Modell, sondern: Wer verantwortet bei euch die Daten? Wenn die Antwort „das ist verteilt" ist, scheitert das Projekt, egal wie gut das Modell ist.
Wissen ist nicht die Menge an Information, die in ein Kontextfenster passt. Wissen muss man aufbauen, strukturieren und verfügbar halten: Welche Systeme sind beteiligt, welche Daten gehören zusammen, welche Regeln gelten, welche Abhängigkeiten bestehen, und was passiert, wenn man einen Prozess ändert. Genau das ist der erste Schritt in jedem unserer Projekte, und genau dafür haben wir NeoCoder so gebaut, dass ein Agent zuerst das System kennenlernt, bevor er die erste Zeile anfasst. Ohne dieses Verständnis entsteht keine Automatisierung. Es entsteht nur eine weitere Anwendung, die irgendwann niemand mehr versteht.
KI braucht Architektur, nicht nur Kontext
Das kommt in der Diskussion zu kurz. Alle reden über grössere Kontextfenster, bessere Modelle, fähigere Agenten. Aber ein grosses Kontextfenster ersetzt keine Softwarearchitektur. Wer einem Agenten immer mehr Informationen, Aufgaben und Verantwortung gibt, ohne sie zu trennen, bekommt ein System, das funktioniert, solange nichts passiert. Problematisch wird es bei der nächsten Anforderung, bei der ersten Änderung, beim ersten Fehler. Dann zeigt sich, ob man eine wartbare Lösung hat oder einen beeindruckenden Prototyp.
Darum gelten bei KI dieselben Prinzipien, die gute Software seit Jahrzehnten ausmachen: klare Verantwortlichkeiten, modulare Komponenten, definierte Schnittstellen, nachvollziehbare Abläufe, saubere Trennung der Fachbereiche. Dazu eine strukturierte Wissensbasis, auf die spezialisierte Agenten gezielt zugreifen. Nicht jeder Agent muss alles wissen. Er muss wissen, was er für seine Aufgabe braucht, und erkennen, wann er andere Komponenten oder Menschen einbeziehen muss.
Das ist auch der Grund, warum wir nicht ein grosses Modell für alles einsetzen, sondern viele kleine für je eine Aufgabe. Ein Modell, das Firmenbeschreibungen rund 900 Kategorien zuordnet, ist klein, läuft lokal und macht genau eine Sache. Fünfzig solche Modelle sind einfacher zu verstehen, zu testen und auszutauschen als eines, das alles kann und bei dem niemand weiss, warum es heute anders antwortet als gestern.
Und Governance?
Natürlich brauchen wir Governance. Sobald KI selbständig Aufgaben ausführt oder auf Systeme zugreift, müssen wir wissen, was sie darf, was sie getan hat und warum. Berechtigungen, Protokollierung, klare Verantwortlichkeiten. Ich habe vor einer Woche beschrieben, was passiert, wenn an einer einzigen Stelle die Leitplanke fehlt: 169 überschriebene Dateien, von einem Agenten, der nur liefern wollte.
Aber sollen wir dafür eine immer grössere Verwaltungsarchitektur um einen Chatbot herum bauen? Oder Sicherheit und Kontrolle von Anfang an in die Architektur der Prozesse einbauen, als Rechte, die ein Agent nicht hat, statt als Regeln, die er nicht befolgen soll? Für mich ist die Antwort klar. Governance ist Voraussetzung. Sie ist nicht das Ziel. Ein sicherer Chatbot ist noch keine Prozessautomatisierung. Der Mehrwert entsteht erst, wenn die KI die fachlichen Zusammenhänge versteht, Aufgaben zuverlässig ausführt und dabei innerhalb klarer Grenzen bleibt.
Erst verstehen, dann vereinfachen, dann automatisieren
Und hier wird es interessant. Wir sollten uns nicht damit zufriedengeben, bestehende Prozesse schneller auszuführen. Vielleicht sind sie längst unnötig kompliziert. Vielleicht werden Informationen dreimal erfasst. Vielleicht existiert ein Arbeitsschritt nur, weil zwei Systeme nicht miteinander reden. Vielleicht entstehen Verzögerungen durch Entscheidungen, die sich mit klaren Regeln automatisieren liessen. Eine gute Lösung hilft, genau diese Stellen zu finden, bevor man sie automatisiert.
So gehen wir vor, und so haben wir es bei den Testdaten für eine Behörde gemacht: nicht alles auf einmal, sondern einen Prototyp, der ein Problem löst, dann mit Abstand nochmal anschauen, drei Fehler finden, und erst dann weiter. Und wenn sich die Anforderungen ändern, muss sich die Lösung weiterentwickeln lassen, ohne dass man von vorne beginnt. Das ist ein sinnvollerer Ansatz als die Frage, welchen Chatbot man als Nächstes einführt.
Woran man es misst
Am Ende interessiert einen Kunden nicht, wie viele Agenten wir einsetzen oder welches Modell im Hintergrund läuft. Er will wissen, was besser wird.
Werden Bestellungen schneller bearbeitet? Nicht die Antwortzeit des Chatbots. Die Durchlaufzeit des Prozesses, vom Eingang bis zum Abschluss.
Sinkt die Fehlerquote? Weniger Rückfragen, weniger Nacharbeit, weniger Sonderfälle, die bei den zwei Leuten landen, die sie kennen.
Müssen Mitarbeiter weniger von Hand machen? Weniger Abtippen, weniger Zusammensuchen, mehr Entscheiden.
Können neue Anforderungen schneller umgesetzt werden? Das ist der Test für die Architektur. Wenn jede Änderung ein Projekt ist, war es ein Prototyp.
Wird die Lösung langfristig günstiger und einfacher zu warten? Eine KI-Lösung, die heute beeindruckt und morgen nur mit grossem Aufwand anpassbar ist, ist keine gute Investition.
Was bleibt
Vielleicht sollten wir uns wieder daran erinnern, warum wir Software überhaupt bauen. Nicht, um möglichst viele Technologien einzusetzen. Nicht, um jedes neue Modell auszuprobieren. Nicht, um möglichst viele Chatbots zu integrieren. Wir bauen Software, um Probleme zu lösen. KI gibt uns dafür Möglichkeiten, die es vor drei Jahren nicht gab: Wissen aufbauen, Zusammenhänge analysieren, spezialisierte Agenten einsetzen, Prozesse über Systemgrenzen hinweg automatisieren. Die Anforderungen bleiben dieselben: durchdachte Architektur, klare fachliche Strukturen, zuverlässige Funktionen, Lösungen, die sich weiterentwickeln lassen.
Und manchmal ist die beste Lösung kein Agent. Manchmal ist es eine einfache Verbesserung eines bestehenden Prozesses, die jemand seit Jahren vorschlägt und die nie Budget bekommen hat, weil sie nicht nach Innovation klingt. Das sage ich auch, wenn es mich den Auftrag kostet.
Die Zukunft von KI im Unternehmen wird nicht daran gemessen, wie intelligent die Chatbots antworten. Sondern daran, wie zuverlässig wir damit echte Probleme lösen, Prozesse verbessern und Firmen voranbringen. Erst verstehen, dann vereinfachen, dann automatisieren, dann messen. Darauf sollten wir uns konzentrieren. Wenn du einen solchen Prozess hast, der seit Jahren weh tut: Schreib mir. Die Seite „Kennenlernen" sagt, wie.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert ein eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal wird daraus ein Mix. Ich lese natürlich alles nochmal, aber niemand ist unfehlbar. Was drin bleibt, ist dann auch von mir.