KI-Funktion im Bestandscode: ein Vorgang im Repository statt eines zweiten Produkts

Eine KI-Funktion im Bestandscode ist eine gewöhnliche Entwicklungsaufgabe: dasselbe Repository, dieselbe Rechtelogik, derselbe Releasezyklus, dieselbe Abnahme. Sie wird nicht dadurch besonders, dass ein Sprachmodell darin vorkommt. Besonders ist nur die Frage, woran man ihr Ergebnis misst – und diese Frage entscheidet über den Erfolg des Vorhabens.

Was eine KI-Funktion im Bestandscode von einem Piloten unterscheidet

Ein Pilot lebt neben dem System. Er bekommt einen Export, rechnet darauf, zeigt ein Ergebnis und überzeugt im Termin. Was danach fehlt, ist jedes Mal dasselbe: Rechte, Protokoll, Fehlerbehandlung, ein Weg zurück in die Fachdaten und jemand, der den Betrieb übernimmt. Der Abstand zwischen einem überzeugenden Piloten und einer benutzbaren Funktion ist deshalb kein Feinschliff, sondern der größere Teil der Arbeit.

Innerhalb des Bestandscodes stellt sich die Sache anders: Die Erkennung oder der Vorschlag ist eine Ebene im vorhandenen System, nicht daneben. Sie liest aus derselben Datenbank, sie schreibt über dieselben Prüfungen, und wer das Ergebnis sehen oder bestätigen darf, entscheidet die Rollenverwaltung, die im Haus ohnehin gilt. Ausgeliefert wird sie im selben Zug wie jede andere Änderung – über denselben Zweig, dieselben Tests, dieselbe Freigabe.

Damit verschiebt sich auch die Frage vor dem Start. Sie lautet nicht mehr, ob ein Modell eine Aufgabe im Prinzip lösen kann; das lässt sich an einem Nachmittag ausprobieren und beweist wenig. Sie lautet: Woran erkennen beide Seiten nach der Lieferung, dass das Ergebnis brauchbar ist? Wer diese Frage nicht beantworten kann, sollte nicht bauen, sondern zuerst die Abnahme klären.

138 Schreibweisen, 75 Lieferanten: ein prüfbares Ergebnis

Zwei Beispiele aus Projekten in Produktion und Handel zeigen, wie so ein Kriterium aussieht. Im ersten ging es um eine Lieferantenliste, die über Jahre aus Belegen gewachsen war: derselbe Betrieb stand dort in vielen Varianten, mit Rechtsform, ohne Rechtsform, mit Tippfehler, mit Zusatz. Ergebnis der Bereinigung: 138 Schreibweisen → 75 Lieferanten; 1 922 Positionen nutzbar.

Das Kriterium war hier nicht „das Modell erkennt Namen gut“, sondern eine Zahl, die jemand im Haus nachzählen kann: Wie viele Positionen lassen sich nach der Bereinigung einem eindeutigen Lieferanten zuordnen und in einen Monatsvergleich bringen. Ein Vorschlag, den niemand bestätigt hat, gilt in dieser Rechnung nicht als Treffer.

Das zweite Beispiel betrifft Preisalarme. Ein Alarm bei jeder Preisänderung erzeugt schnell Blindheit – gemeldet wird alles, angesehen wird nichts. Also wurde verglichen, was vergleichbar ist: gleiche Einheit, gleiche Menge, gleicher Zeitraum. Ergebnis: 1 561 Positionen neu bewertet, unvergleichbare Sprünge herausgefiltert. Auch das ist ein Kriterium, das man prüfen kann, ohne an die Technik zu glauben.

In beiden Fällen entscheidet nicht das Modell, sondern das System. Der Vorschlag kommt aus dem Sprachmodell, die Regel bleibt im Code: Schwellen, Einheiten, Zuordnungen und der Fall, in dem nichts entschieden wird, sondern ein Mensch gefragt wird. In Kundenprojekten prüfen zuerst unsere KI-Werkzeuge jede Änderung, danach ein Entwickler.

Wo ein Sprachmodell die falsche Antwort ist

Die ehrliche Einschränkung zuerst: Ein Modell ersetzt keine fehlende Datenquelle. Wenn die Information, die gebraucht wird, im Haus nirgends steht, entsteht sie auch nicht durch eine sprachliche Näherung – dann ist die richtige Aufgabe eine Anbindung und keine Erkennung. Drei weitere Fälle, in denen wir abraten:

• Die Regel ist aufschreibbar. Was sich als Tabelle, Formel oder eindeutiger Abgleich formulieren lässt, gehört genau dorthin. Das Ergebnis ist reproduzierbar, im Betrieb sparsamer und ohne laufende Kosten je Aufruf.
• Das Ergebnis ist nicht prüfbar. Wo niemand sagen kann, was richtig gewesen wäre, gibt es kein Kriterium und damit keine Abnahme. Solche Vorhaben landen erfahrungsgemäß im Dauerbetrieb der Meinungen.
• Die Daten dürfen nicht hinaus. Welche Felder ein Modell überhaupt zu sehen bekommt und welche vorher entfernt werden, halten wir im Angebot fest. Verarbeiten wir personenbezogene Daten im Auftrag, schließen wir einen Auftragsverarbeitungsvertrag.

Zum Betrieb gehört außerdem eine Grenze, die vor dem Start steht: Anwendungen, die im Betrieb Sprachmodelle nutzen, rufen sie über ein eigenes Gateway auf – mit Protokoll je Aufruf und einer Kostengrenze. Ohne diese Grenze ist der Aufwand einer solchen Erweiterung im Betrieb nicht vorhersehbar, und das ist für den Auftraggeber schlechter als ein langsamerer Weg.

KI-Funktion im Bestandscode: so nehmen wir sie ab

Unser Vorgehen beginnt mit dem Kriterium, nicht mit dem Modell. Zuerst wird festgelegt, an welcher Zahl oder welchem Vergleich das Ergebnis gemessen wird und auf welchem Ausschnitt der echten Daten. Dieser Ausschnitt wird eingefroren, damit später nicht die Grundlage wandert. Erst danach entsteht Code – im bestehenden Zweig, mit Tests, die dieselbe Prüfung automatisch wiederholen.

Geliefert wird in Teilen, und der erste Teil ist bewusst klein: eine Auswertung, die Vorschläge erzeugt, ohne etwas zu verändern. Erst wenn die Zahlen aus der ersten Runde stimmen, bekommt die Erweiterung Schreibrechte. Wie wir das vertraglich fassen und welche Unterlagen dazugehören, steht auf der Seite KI-Softwareentwicklung im bestehenden System; die Einordnung des Begriffs selbst im Lexikon unter KI-Funktion in Bestandssoftware.

Was dabei bewusst nicht passiert: Wir bauen keine zweite Anwendung neben Ihrem System, und wir hinterlassen keine Komponente, die nur wir betreiben können. Die Erweiterung liegt im selben Repository, sie wird mit denselben Werkzeugen ausgeliefert wie der Rest, und die Dokumentation beschreibt sie in der Sprache der Fachlichkeit statt in der des Modells. Mit vollständiger Bezahlung gehen die Nutzungsrechte am eigens erstellten Code auf den Auftraggeber über.