Kein zweiter Assistent

Ein Standard, von dem hier bewusst abgewichen wird

Neue Softwareprodukte starten heute fast reflexhaft mit einer bestimmten Grundausstattung: Echtzeit-Updates statt Neuladen, ein moderner technischer Unterbau, und praktisch immer ein eigener In-App-Chatbot, über den Nutzer Fragen stellen können, ohne die Anwendung zu verlassen. Dieser Chatbot gehört mittlerweile fast so selbstverständlich zu neuer Software wie eine Suchleiste.

Für JiCo ist genau dieser eine Baustein keine Lücke, die irgendwann nachgeliefert wird, sobald Zeit dafür ist. Es ist eine bewusste, begründete Abweichung vom sonst üblichen Standard. Der Grund dafür ist keine Frage von Aufwand, Priorität oder Budget — es ist eine strukturelle Überlegung, die sich nicht mit mehr Entwicklungszeit lösen liesse: JiCo ist bereits die KI-Schnittstelle zu Jira und Confluence. Ein zweiter Assistent daneben, der zusätzliche Fragen zur Software selbst beantworten soll, würde kein neues, bislang unbesetztes Bedürfnis abdecken. Er würde dasselbe Bedürfnis ein zweites Mal bedienen — mit doppeltem Aufwand für halb so viel Nutzen.

Warum es hier nicht nur um Aufwand geht, sondern um Haltung

Der Standard, von dem hier abgewichen wird, formuliert für einen In-App-Assistenten eine bestimmte Grundhaltung: „vorschlagend, nicht ausführend" — der Chatbot soll helfen und Vorschläge machen, aber nicht selbstständig etwas verändern. Bei den meisten Produkten ist das eine sinnvolle, aber letztlich freiwillige Designentscheidung unter mehreren möglichen. Bei JiCo ist genau diese Haltung nicht eine von mehreren Optionen, sondern der eigentliche Daseinszweck des gesamten Produkts, festgeschrieben als unumstössliche Regel: Kein Schreibzugriff ohne menschliche Freigabe, ausnahmslos — auch dann, wenn JiCo die genaue Art eines Werkzeugs gar nicht sicher einordnen kann. In diesem Fall gilt es automatisch als schreibend, nie als harmlos.

Wo andere Produkte diese Zurückhaltung als eine von mehreren gleichwertigen Ausprägungen behandeln, die man je nach Zielgruppe unterschiedlich stark ausprägen kann, ist sie bei JiCo der eigentliche Grund für die Existenz des Produkts. Eine Änderung, die diese Regel irgendwo aufweichen würde — und sei es nur an einer scheinbar unwichtigen Nebenstelle wie einem zweiten, vermeintlich harmlosen Chat-Fenster —, wäre deshalb streng genommen kein neues Feature. Es wäre ein Defekt am Kern des Produkts, unabhängig davon, wie nützlich das neue Feature für sich genommen erscheinen würde.

Die einfachere Rechnung, die hinter dieser Entscheidung steht

Zwei getrennte Gesprächsoberflächen für dieselbe grundlegende Aufgabe bedeuten in der Praxis: zwei Stellen, an denen Personendaten überhaupt erst in einen Modellkontext gelangen könnten, statt einer. Zwei Stellen, an denen die Freigabe-Logik über die Zeit hinweg konsistent gehalten werden müsste, mit dem Risiko, dass eine Stelle bei der nächsten Änderung übersehen wird. Zwei Stellen, die ein Audit-Trail lückenlos erfassen müsste, statt sich auf einen einzigen, gut verstandenen Pfad konzentrieren zu können.

Die einfachste tragfähige Lösung ist an dieser Stelle nicht die mit den meisten Funktionen oder der grössten Bausteinliste — es ist die mit dem einen klar nachvollziehbaren Pfad, der alles trägt: ein Weg vom KI-Client bis zu Jira, durch dieselbe Schwärzung, dieselbe Freigabe, denselben lückenlosen Beleg. Ein zweiter, paralleler Weg daneben würde diesen einen Pfad nicht sinnvoll ergänzen. Er würde seine Garantie durchlöchern, und zwar an einer Stelle, die auf den ersten Blick harmlos aussieht, weil dort ja „nur" Fragen zur Software selbst gestellt werden sollen.

Der Unterschied zu einem gewöhnlichen Software-Chatbot

Ein gewöhnlicher In-App-Chatbot bei einem anderen Produkt beantwortet in aller Regel harmlose Fragen zur Bedienung und greift selten selbst verändernd in die eigentlichen Kundendaten ein — er erklärt, wie eine Funktion bedient wird, mehr nicht. Bei JiCo läge die Sache anders, und genau das macht den Unterschied so bedeutsam: Ein zweiter Assistent, der neben der eigentlichen Jira-Anbindung existiert, hätte kaum eine sinnvolle Existenzberechtigung, ohne irgendwann ebenfalls Zugriff auf dieselben sensiblen Inhalte zu bekommen, über die JiCo wacht — sonst wäre er nur ein glorifiziertes Inhaltsverzeichnis der eigenen Dokumentation, mit begrenztem Nutzen.

Sobald aber auch nur die Möglichkeit bestünde, dass ein zweiter Kanal ebenfalls mit denselben Ticketinhalten in Berührung kommt, wäre die gesamte sorgfältig aufgebaute Kette aus Schwärzung, Freigabe und Beleg auf einen Schlag halbiert — nicht weil der zweite Kanal absichtlich schlechter gebaut wäre, sondern weil es strukturell zwei Kanäle gäbe, die beide gepflegt, geprüft und synchron gehalten werden müssten, mit doppelter Gelegenheit für ein Versehen.

Was das für Nutzer im Alltag bedeutet

In der Praxis heisst das: Wer etwas über JiCo selbst wissen will — wie eine Einstellung funktioniert, was ein bestimmter Status bedeutet, wie ein Fehler zu lesen ist —, findet die Antwort im Handbuch, in der Dokumentation im Kundenportal oder direkt im Panel selbst, nicht in einem zusätzlichen Chat-Fenster, das nebenbei mitläuft und potenziell dieselben Fragen über einen zweiten, weniger kontrollierten Kanal beantworten würde. Das ist ein bewusster Verzicht auf Komfort an einer Stelle, damit an der eigentlich entscheidenden Stelle — dem Umgang mit Personendaten aus Jira und Confluence — nichts verwässert wird.