KI-Anwendungs­fälle auf eine gemeinsame Agenten­architektur bringen

Die Geschäfts­leitung eines städtischen Wohnungs­konzerns hat sechs Business Cases priorisiert, und zwei davon stehen vorn. Der erste ist ein Agent, der Mitarbeitenden Richtlinien und Arbeits­anweisungen im Chat zugänglich macht, der zweite ein Voicebot, der Mieteranrufe entgegennimmt, klassifiziert und weiterleitet. Der naheliegende Weg wäre gewesen, beide getrennt auszuschreiben. Genau das ist die Frage, die zu klären ist: Sind das zwei Projekte oder zwei Anwendungen desselben Systems? Dahinter liegt eine Reihe von Punkten, die kein Anbieter­angebot beantwortet — wo die Richtlinien­dokumente heute liegen und wem sie gehören, welche Zugriffsrechte gelten, wie das Anrufrouting heute tatsächlich läuft, welche Systeme in der Anliegen­bearbeitung beteiligt sind, und unter welchen Bedingungen für Hosting, Datenschutz und Compliance das Ganze überhaupt betrieben werden darf.

Die wichtigste Entscheidung des Tages war eine Verneinung. Zwei priorisierte Anwendungs­fälle führen fast zwangsläufig zu zwei Projekten, zwei Beschaffungen und zwei Systemen — und ein paar Jahre später zu der Frage, warum das Wissen im einen System für das andere unsichtbar ist. Der Regelwerke-Agent und der Voicebot brauchen dieselben Dinge: Zugriff auf geprüfte Dokumente, ein Rechtekonzept, eine Modell­anbindung, eine Protokollierung. Was sie unterscheidet, ist die Oberfläche. Daraus folgt eine Plattform mit zwei Agenten, nicht zwei Lösungen mit einer Schnittmenge.

Die Reihenfolge im Workshop war Plattform, Anwendungs­fall, Zusammen­führung. Erst die Anforderungen an den Kern und die Rahmenbedingungen, unter denen er betrieben werden darf. Dann je Anwendungs­fall der Fachbereich, der weiß, wo die Dokumente liegen und wie ein Anruf heute wandert. Am Schluss die Konsolidierung. Umgekehrt herum — erst die Anwendungs­fälle, dann die Plattform — entsteht eine Architektur, die zwei Sonderfälle nachträglich unter einen Hut bringen muss.

Zu jedem Anwendungs­fall gehört der Fachbereich, aber nur zu seinem Block. Die IT und die Unternehmens­entwicklung waren den ganzen Tag dabei, die Fachleute für Regelwerke und für den Service jeweils nur in ihrem Zeitfenster. Das ist keine Höflichkeit gegenüber vollen Kalendern, sondern eine Bedingung dafür, dass diese Menschen überhaupt kommen. Ein Architektur­workshop, zu dem alle den ganzen Tag erscheinen sollen, findet entweder nicht statt oder ohne die, auf die es ankommt.

Die härteste Frage im Regelwerke-Block war nicht technisch. Sie lautete: Kann ein KI-System das bestehende Problem allein lösen? Wenn Richtlinien widersprüchlich, veraltet oder in mehreren Fassungen abgelegt sind, dann beantwortet ein Agent Fragen zuverlässig falsch. Deshalb standen Datenqualität, Aktualität, Versionierung und Eigentümerschaft der Dokumente im selben Block wie die Retrieval-Logik — und daraus wurde ein eigener, vorgelagerter Arbeitsstrang statt einer Fußnote im Umsetzungs­plan.

Der Voicebot rechnet sich an einer Zahl, die der Konzern selbst hat. Die interne Auswertung der Kontakteingänge zeigt rund 100.000 Vorgänge im Jahr über acht Kanäle, rund ein Viertel davon telefonisch. Das ist die Grundlage, auf der sich über Automatisierungs­grade reden lässt, ohne zu raten: Welche Anliegen kommen häufig, welche sind standardisiert, wo entstehen Fehlleitungen. Ein Anbietervergleich ohne diese Zahlen vergleicht Funktions­listen.

Am Ende steht ein Zuschnitt, kein Wunschzettel. Ein Proof of Concept braucht eine Grenze und ein Kriterium, an dem sich nach ein paar Wochen entscheiden lässt, ob weitergemacht wird. Beides ist im Workshop festgelegt worden, zusammen mit einer Roadmap, die schnelle Schritte von mittelfristigen trennt. Der erste dieser Schritte ist inzwischen beauftragt.