Ugo Lattanzi
Diese Seite gibt es auch aufEnglishItaliano
Veröffentlicht am

Wann man nicht automatisieren sollte

In jedem KI-Projekt kommt der Moment, in dem jemand fragt, warum das System noch einen Menschen braucht. Meist ist das die wichtigste Frage im Raum — und meist wird sie zu schnell beantwortet.

Vor einiger Zeit haben wir für ein Versorgungsunternehmen eine Support-Plattform gebaut. Die Form war gewöhnlich genug: interne und kundenseitige Assistenten über einer Retrieval-Schicht, direkt mit dem Support-Postfach verbunden, mit einem Antwortentwurf zu jeder eingehenden Anfrage. Interessant ist, wo wir aufgehört haben.

Die Mitarbeitenden bleiben der letzte Schritt. Sie lesen den Entwurf, bewerten ihn mit Daumen und einer Zeile Freitext, bearbeiten ihn und senden ihn. Die Bewertungen fliessen in ein Dashboard. Und auf Continuous Learning — den offensichtlichen nächsten Schritt, den jedes Anbieterdeck auf Folie vier setzt — wurde bewusst verzichtet.

Diagramm der Support-Plattform: Anfrage, Retrieval, Entwurf, Mitarbeiter, Versand. Der Mitarbeiter ist der letzte Schritt und bleibt menschlich, die Wissensbasis aktualisiert sich nicht selbst.
Die Form des Systems. Die Einschränkung des Kunden war nicht technisch — und sie hat entschieden, wo die Automatisierung endet.

Die Einschränkung war nicht technisch

Der Kunde wollte nicht, dass die Wissensbasis implizit von denjenigen umgeformt wird, die gerade im Support sitzen. Er wollte sie besitzen: wissen, was darin steht, wer es eingetragen hat und wann. Das ist keine Vorsicht gegenüber KI. Es ist eine völlig vernünftige Haltung dazu, wer dafür geradesteht, was das Unternehmen seiner Kundschaft sagt.

Man hätte diskutieren können. Es gibt gute Gegenargumente — Review-Gates, gestufte Freigabe, versionierte Wissensbestände, Rollback. Ich habe sie alle schon vorgebracht. Aber die ehrliche Einschätzung dieses Raums war: Die Diskussion hätte mehr Vertrauen gekostet, als die Funktion wert war, und ein System ohne sie würde täglich genutzt, während eines mit ihr hinter einem Freigabeprozess läge, für den niemand Zeit hat.

Ein autonomes System, das niemand einschaltet, bringt nichts. Ein unterstützendes im täglichen Einsatz bringt alles.

Was man aufgibt und was man gewinnt

Ohne Continuous Learning verbessert sich das System schubweise statt laufend. Jemand muss das Dashboard ansehen, die schlecht bewerteten Entwürfe lesen und entscheiden, was in der Wissensbasis zu ändern ist. Das ist echte Arbeit, und sie ist langsamer.

Gewonnen wird ein System, dem die Organisation wirklich vertraut, eine Wissensbasis, die für die Verantwortlichen lesbar bleibt, und ein ehrliches Feedback-Signal — denn Mitarbeitende bewerten offen, wenn ihre Bewertungen nicht im Hintergrund stillschweigend die Quelle der Wahrheit umschreiben.

Das Muster, verallgemeinert

Die interessante Frage war nie, was das Modell kann. Sondern, wie viel eine Organisation davon verträgt. Und diese Aufnahmefähigkeit hängt an Vertrauen, Regulierung, Verantwortung und Gewohnheit — nichts davon bewegt sich im Tempo der Technologie.

Der nützliche Schritt bei einer solchen Einschränkung ist deshalb die Frage, ob es ein Missverständnis ist, das man korrigieren kann, oder eine Haltung, um die man herum entwerfen sollte. Missverständnisse sind eine Stunde Erklärung wert. Haltungen sind eine Architektur wert.

In der Praxis gehe ich heute von unterstützend vor autonom aus und halte den Menschen am letzten Schritt, bis es Belege gibt — gemessen, nicht behauptet — dass es sicher ist, ihn wegzunehmen. Nicht aus Vorsicht gegenüber KI. Sondern weil sie so am Ende wirklich genutzt wird.

← Alle Artikel
Ugo Lattanzi — Applied AI Architect Keine Cookies. Aggregierte, cookiefreie Analytics über Cloudflare.