Auf den meisten Agenden steht die Frage falsch herum. Sie lautet, wo wir KI einsetzen können. Sie müsste lauten, welches Problem wir haben, das bisher niemand lösen konnte.

Der Unterschied klingt nach Wortklauberei. Er entscheidet darüber, ob am Ende etwas Nützliches im Betrieb steht oder ein teurer Aufsatz auf etwas, das vorher schon funktioniert hat.

Der Enthusiasmus ist dabei nicht das Problem. Ohne ihn würde gerade nichts entstehen, und einiges von dem, was entsteht, ist gut. Er sorgt nur dafür, dass eine bestimmte Sorte Frage nicht mehr gestellt wird.

Drei Arten, ein Modell auf Gelöstes zu werfen

Die erste ist die offensichtliche. Es gibt ein Regelwerk, es gibt eine Schnittstelle, es läuft seit Jahren. Der Vorgang ist deterministisch, prüfbar, im Zweifel vor Gericht erklärbar. Ein Sprachmodell davor macht ihn nicht besser, sondern unschärfer. Du tauschst ein korrektes System gegen ein plausibles und zahlst dafür.

Die zweite ist die unangenehme. Das Problem ist gar kein technisches. Der Prozess ist kaputt, die Zuständigkeit ungeklärt, die Datenqualität schlecht. Ein Modell davor dämpft das Symptom sehr wirkungsvoll und konserviert damit die Ursache. Das ist die teuerste Variante, weil sie erst in zwei Jahren sichtbar wird und dann niemandem mehr gehört.

Die dritte ist die politische. Der Anwendungsfall entsteht, weil ein Bereich zeigen will, dass er beim Thema vorn ist. Sichtbarkeit wird belohnt, Zurückhaltung nicht. Wer sagt, hier brauchen wir das nicht, gilt schnell als jemand, der bremst. Dagegen hilft keine Architekturentscheidung, sondern nur eine Organisation, in der dieser Satz als Beitrag zählt.

Wo es dann doch hingehört

Ich baue gerade eine KI-Assistenz für den Bahnhof. Die Frage, die mich darin am meisten beschäftigt, ist nicht, was das Modell kann. Es ist die Frage, was es nicht anfassen darf.

Die Verbindungssuche zum Beispiel ist gelöst. Fahrplan, Kanten, Umstiegszeiten, Sperrungen, darüber ein Algorithmus, der den Pfad berechnet. Du kannst testen, ob das Ergebnis stimmt, und du kannst nachvollziehen, warum es diese Verbindung ist und keine andere. Dort hat ein Modell nichts zu suchen.

Ungelöst ist das Anliegen davor.

Menschen fragen nicht in Feldern. Wer im Bahnhof steht und sagt „wo ist mein Zug“, meint manchmal genau das. Oft meint er „schaffe ich das noch“. Manchmal meint er „was mache ich jetzt“. Dazu kommen die Bedingungen, die niemand ausspricht, weil sie für ihn selbstverständlich sind. Mit Gepäck sind vier Minuten Umstieg keine vier Minuten. Wer einen Termin hat, will nicht die schnellste Verbindung, sondern die, die vorher ankommt. Wer schlecht zu Fuß ist, nimmt lieber einen Umstieg mehr und einen Weg weniger.

Das ist keine Formularfrage und auch keine Übersetzungsaufgabe. Die eigentliche Leistung dieser Schicht ist nicht, den Satz zu zerlegen. Sie ist, die Bedingung zu erfragen, die nicht im Satz steht. Wer das ernst nimmt, landet bei etwas, das eher nach Gesprächsführung aussieht als nach Suche. Das heißt nicht, jede Lücke mit einer Rückfrage zu füllen. Wer um neun in Köln sein muss, will nicht erst gefragt werden, ob heute gemeint ist. Naheliegende Annahmen trifft das Modell selbst und sagt dazu, welche. Nachgefragt wird da, wo keine Annahme naheliegt oder es mehrere Möglichkeiten gibt.

Genau da gehört ein Modell hin. Und nur da.

Groundedness ist dieselbe Frage in Code

In unserem Vorhaben geht es zuerst um Antwortqualität und Groundedness. Erst danach um Kosten. Groundedness heißt in der Praxis, dass das Modell nicht die Quelle der Wahrheit ist, sondern der Weg dorthin. Alles, was der deterministische Teil weiß, darf es nicht selbst erzeugen, sondern nur weiterreichen und belegen.

Das klingt nach einer technischen Anforderung. Es ist dieselbe Grenze wie oben, nur gegossen.

Was dabei nicht zusammenpasst: Qualität und Belegbarkeit ziehen nicht in dieselbe Richtung. Eine perfekt geerdete Antwort kann nutzlos sein, weil sie nichts sagt. Eine hilfreiche Antwort ist immer versucht, ein bisschen mehr zu behaupten, als sie belegen kann. Du misst also nicht eine Größe, sondern ein Paar. Interessant wird der Bereich dazwischen, bei den Antworten, die stimmen könnten.

Im Bahnhof ist der selbstbewusste Irrtum teurer als das ehrliche Nichtwissen. Eine falsch verstandene Bedingung liefert eine Verbindung, die vollkommen richtig aussieht und den Anschluss kostet. Deshalb halte ich den Abbruch für das wichtigste Verhalten im ganzen System. Ein Assistent, der sagt, das kann ich nicht sicher zuordnen, dort vorne steht jemand, ist kein gescheiterter Assistent. Er ist der einzige, dem man beim zweiten Mal noch glaubt.

Die Kostenfrage kommt später und wird früh entschieden

Ob am Ende pro Anliegen ein großes Modell mehrfach läuft oder ein kleines mit sauberer Abfrage, entscheidest du in der Architektur. Die Rechnung kommt Jahre danach. Wer die Frage aufschiebt, bis der Betrieb läuft, kauft Qualität später über Modellgröße, weil das der schnellste Hebel ist und weil er da ist.

Nachhaltig ist dabei zweierlei gemeint. Das eine ist die Rechenlast, und die nennen inzwischen alle. Das andere nennt kaum jemand: Jedes Modell im Betrieb ist eine dauerhafte Prüfpflicht. Es muss beobachtet, nachgemessen und bei jeder Änderung neu bewertet werden. Ein Regelwerk, das seit zehn Jahren stabil läuft, kostet dich nichts davon. Das ist kein Argument gegen KI. Es ist ein Argument dafür, sie dort einzusetzen, wo sie etwas löst, das vorher nicht gelöst war.

Die Frage vor dem Anwendungsfall

Der Test, den ich inzwischen an jedes Vorhaben anlege, ist einfach und unbequem.

Kannst du das Problem so genau aufschreiben, dass ein Regelwerk es lösen würde? Dann brauchst du kein Modell, sondern jemanden, der es aufschreibt.

Kannst du es nicht, prüf zuerst, ob das an der Sache liegt oder daran, dass bei euch niemand die Verantwortung geklärt hat. Nur im ersten Fall ist es ein Fall für KI.

Und wenn du dann baust, halte die Schicht so klein wie möglich. Nicht aus Sparsamkeit, sondern weil alles, was du dem Modell überlässt, dauerhaft von dir überprüft werden muss.

Das ist mein wichtigstes Learning aus diesem Jahr, und es passt schlecht in die Stimmung. Der wertvollste Satz in einem KI-Vorhaben ist der, den niemand hören will.

Ein Skript hätte gereicht.

Wer ihn früh sagt, spart Geld. Wer ihn spät sagt, hat recht und niemanden mehr, der zuhört.

Man übersieht ihn leicht, und das liegt nicht an Nachlässigkeit. Es liegt daran, dass ein funktionierendes Modell auch die einfachen Fälle richtig beantwortet. Es sieht dann so aus, als hätte es sich bewährt. Dass ein Regelwerk dieselben Fälle billiger und prüfbar gelöst hätte, siehst du im laufenden Betrieb nie, weil die günstigere Variante nie gebaut wurde. Der Vergleich fehlt, also fehlt auch das Argument.

Der Satz ist trotzdem keine Absage. Er verschiebt nur, wo die KI arbeitet.

Dann lass sie das Skript schreiben

Wenn am Ende ein Regelwerk reicht, benutz das Modell dafür, es zu bauen. Genau darin ist es gut. Eine Automatisierung, die du seit zwei Jahren vor dir herschiebst, weil niemand Zeit hat, steht damit an einem Nachmittag. Was danach im Betrieb läuft, ist Code. Lesbar, testbar, versionierbar, in zehn Jahren noch nachvollziehbar, und ohne Modell im Rücken, das jemand dauerhaft beobachten muss.

Die KI taucht einmal auf, erledigt ihre Arbeit und ist wieder weg. Das ist der sparsamste Einsatz, den es gibt, und der wird selten als KI-Vorhaben gezählt, weil man ihn hinterher nicht mehr sieht.

Was bei euch gerade als KI-Vorhaben läuft: Wie viel davon wäre ein sauberes Skript und eine geklärte Zuständigkeit?

Bei uns bleibt es nicht bei der Frage. Der Pilot startet bald. Einiges von dem, was ich hier geschrieben habe, wird sich im Betrieb anders anfühlen als am Reißbrett, und genau dafür ist ein Pilot da. Wir starten und lernen weiter.