KI-Funktion in Bestandssoftware: Grenze, Daten, Verhalten im Fehlerfall

Eine KI-Funktion in Bestandssoftware ist ein abgegrenzter Teil einer bereits laufenden Anwendung, der ein Sprachmodell oder ein anderes Modell für genau eine Aufgabe nutzt. Sie arbeitet auf derselben Datenbank, unter derselben Rollenverteilung und im selben Releasezyklus wie der Rest des Programms. Was sie ändern darf und was sie nur vorschlägt, steht vor dem Einbau fest.

KI-Funktion in Bestandssoftware: was dabei entsteht

Entstanden ist am Ende kein zweites Produkt, sondern eine Funktion mehr in einem Programm, das die Fachabteilung kennt. Sie hat einen Auslöser im Ablauf, eine Eingabe, eine Ausgabe und einen Ort in der Oberfläche. Typische Beispiele sind das Vorbelegen eines Formulars aus einem eingegangenen Dokument, das Einordnen eingehender Nachrichten in bestehende Kategorien, das Zuordnen von Positionen zu einem Verzeichnis oder eine Suche, die in Freitexten findet, was die Volltextsuche übersieht.

Der Unterschied zu einem Vorhaben auf der grünen Wiese liegt in den Randbedingungen: Rechteprüfung, Protokollierung, Mandantentrennung und Freigabewege sind bereits vorhanden und gelten auch für die neue Funktion. Sie erbt den Rahmen, statt einen eigenen aufzumachen. Genau das macht den Einbau zu einer Aufgabe der Software-Weiterentwicklung und nicht zu einem Forschungsprojekt.

Wo die Grenze der Funktion verläuft

Die wichtigste Festlegung betrifft die Entscheidungsbefugnis. Ein Modell kann vorschlagen, vorbelegen, sortieren, zusammenfassen; ob sein Ergebnis unmittelbar wirksam wird, ist eine fachliche Entscheidung und keine technische. Praktisch trennt man drei Stufen: Das Ergebnis wird nur angezeigt, es wird als Entwurf gespeichert und von einem Menschen freigegeben, oder es wirkt direkt und wird nachträglich stichprobenhaft geprüft.

Die Wahl der Stufe hängt am Schaden einer falschen Ausgabe. Eine falsch vorgeschlagene Kategorie kostet einen Klick, eine falsch ausgelöste Buchung kostet deutlich mehr. Deshalb steht in der Beschreibung nicht nur, was die Funktion tut, sondern auch, was sie ausdrücklich nicht tut: keine Löschung, kein Versand nach außen, keine Änderung an abgeschlossenen Vorgängen.

Woher die Funktion ihre Daten nimmt

Eine Ausgabe ist nur so gut wie das, was die Funktion sehen darf. In einem gewachsenen System liegen die nötigen Angaben selten an einer Stelle, sondern verteilt über Stammdaten, Vorgänge, Anhänge und Verzeichnisse. Der Einbau beginnt deshalb mit der Frage, welche Felder die Aufgabe tatsächlich braucht — und endet nicht bei „so viel Kontext wie möglich“.

Zwei Regeln haben sich bewährt. Erstens gilt die Rechteprüfung des Programms auch für das Modell: Was ein Anwender nicht sehen darf, gehört nicht in die Anfrage. Zweitens wird festgehalten, welche Daten das System an einen externen Dienst übergibt; bei personenbezogenen Daten gehört dazu ein Auftragsverarbeitungsvertrag. Diese Punkte gehören in die Unterlagen, bevor die erste Anfrage das Haus verlässt.

Verhalten bei Ausfall und schwacher Antwort

Ein Modell ist ein fremder Dienst mit eigenen Störungen, wechselnden Antwortzeiten und gelegentlich unbrauchbaren Ergebnissen. Die Anwendung muss das aushalten, ohne stehen zu bleiben. Dazu gehören eine Zeitgrenze je Anfrage, ein definierter Zustand bei Zeitüberschreitung, ein Rückfallweg auf den bisherigen Ablauf und eine Kennzeichnung, dass ein Vorschlag maschinell entstanden ist.

Ebenso wichtig ist der Umgang mit formal gültigen, inhaltlich falschen Antworten. Übernimmt die Anwendung eine Ausgabe ungeprüft in ein Pflichtfeld, wandert der Fehler in den Datenbestand und fällt erst viel später auf. Ein Abgleich gegen vorhandene Verzeichnisse und ein Schwellenwert, unterhalb dessen die Funktion nichts vorschlägt, verhindern das wirksamer als jede Nachbesserung am Text der Anfrage.

Eine KI-Funktion in Bestandssoftware prüfbar machen

Prüfbar wird eine solche Funktion über eine feste Menge echter Fälle mit bekanntem Sollergebnis. Daran lässt sich messen, wie oft der Vorschlag übernommen wird, wie oft er korrigiert wird und wie oft er ausbleibt. Diese Werte gehören zusammen mit der Grenze der Funktion und dem Verhalten im Fehlerfall in die Kriterien für die Abnahme.

Dazu kommt der Nachweis, dass der Bestand unverändert weiterarbeitet: Die Funktion ist neu, das Programm ist es nicht, und die vorhandenen Abläufe müssen dieselben Ergebnisse liefern wie vorher. Diesen Teil übernimmt die Testautomatisierung. Wer nur die Trefferquote misst, prüft die Hälfte.

Wie wir eine solche Funktion einbauen

Wir bauen die Funktion in die vorhandene Anwendung, nicht daneben: dieselbe Datenbank, dieselbe Rechteprüfung, derselbe Releaseweg. Anwendungen, die im Betrieb Sprachmodelle nutzen, rufen sie über ein eigenes Gateway mit Kostengrenze auf, sodass Verbrauch und Ausfälle an einer Stelle sichtbar sind. Grenze, Datenherkunft, Verhalten bei Störungen und die Kriterien für die Abnahme halten wir vor dem Start im Angebot fest; fachliche Fragen laufen über unsere Projektleitung. Den Rahmen für eine solche KI-Softwareentwicklung beschreibt die zugehörige Leistungsseite.