Das Modell schlägt vor, der Server prüft: KI-Funktion mit Kotlin und Spring Boot

Englische Version auf zleptnig.com lesen →

Eine Fahrtenbuch-App enthält viele strukturierte Daten: Datum, Strecke, Zweck, Kilometer und teilweise Kilometerstände. Klassische Validierungsregeln erkennen fehlende oder offensichtlich widersprüchliche Werte. Schwieriger sind semantische Auffälligkeiten – etwa unterschiedlich geschriebene Ziele, ähnlich beschriebene Fahrten oder persönliche Muster, die erst im Vergleich mehrerer Einträge sichtbar werden.

Im Backend-Projekt von KM Geld entstand deshalb ein begrenzter KI-Vertikalschnitt: Eine ausdrücklich gestartete Fahrtdatenprüfung lässt ein Sprachmodell mögliche Auffälligkeiten vorschlagen. Bevor ein Hinweis angezeigt werden darf, prüft der Server IDs, Originalwerte und fachliche Regeln deterministisch. Das Modell darf keine Fahrt verändern.

Der aktuelle Stand ist ein lauffähiger und evaluierter Backend-Vertikalschnitt – fachlich bewusst noch ein Prototyp. Er ist noch nicht in die mobile App integriert und nicht öffentlich produktiv ausgerollt. Genau diese Abgrenzung ist wichtig: Die Implementierung soll belastbare Produkt- und Architekturentscheidungen ermöglichen, ohne bereits Produktionsreife zu behaupten.

Definition: Was kennzeichnet eine evaluierte KI-Funktion?

Eine evaluierte KI-Funktion ist hier als begrenzter, lauffähiger Vertikalschnitt umgesetzt, dessen Verhalten nicht nur anhand einzelner Demo-Antworten beurteilt wird. Eingaben, Ausgaben, fachliche Regeln, Fehlerfälle und Qualitätskriterien sind explizit beschrieben und reproduzierbar testbar.

Sie muss noch kein produktionsreifes System sein. Sie sollte aber belastbar genug sein, um die nächsten Produkt-, Architektur- und Investitionsentscheidungen auf Evidenz statt auf Bauchgefühl zu stützen.

Die Produktfrage: Wo bringt ein Sprachmodell wirklich Mehrwert?

Nicht jede Datenprüfung braucht ein LLM. Kilometerstände, Grenzwerte und Pflichtfelder lassen sich zuverlässiger mit klassischem Code prüfen. Sprachmodelle werden dort interessant, wo semantische Ähnlichkeit, uneinheitliche Bezeichnungen oder kontextabhängige Auffälligkeiten eine Rolle spielen.

Vor der Modellauswahl wurden daher fünf Fragen geklärt:

• Welche Teile sind deterministisch lösbar?
• Wo ist semantische Modellunterstützung sinnvoll?
• Welche Entscheidung muss beim Menschen bleiben?
• Welche Daten sind für diese Aufgabe wirklich erforderlich?
• Woran lässt sich ein brauchbares Ergebnis messen?

Das Ergebnis ist kein autonomer Fahrtenbuch-Assistent. Es ist eine optionale Prüfung ohne automatische Änderungen: Das Modell sucht Kandidaten, die Software kontrolliert sie und der Mensch entscheidet, ob ein Hinweis relevant ist.

Der Engineering-Prozess im Überblick

Produktidee, Ziel und Entscheidungsgrenzen
-> minimierter, versionierter Vertrag
-> providerunabhängiger Modell-Port
-> strukturierte Modellkandidaten
-> deterministische fachliche Verifikation
-> read-only Ergebnis für den Menschen
-> synthetische Evaluation und Iteration

Die Schritte trennen probabilistische und deterministische Verantwortung. Das Modell darf flexibel nach Zusammenhängen suchen. Der Server bleibt die Autorität für überprüfbare Daten und Regeln.

1. Entscheidungsgrenzen vor Prompt und Modell festlegen

Die wichtigsten Grenzen entstanden vor der ersten Modellintegration:

• Die Analyse wird ausdrücklich gestartet und läuft nicht unbemerkt im Hintergrund.
• Das Modell darf keine Daten verändern.
• Ergebnisse bleiben Hinweise und keine automatischen fachlichen Entscheidungen.
• Rechtliche oder steuerliche Bewertungen gehören nicht zum Funktionsumfang.
• Die Kernanwendung muss ohne den optionalen KI-Dienst funktionieren.

Diese Grenzen reduzieren Risiken und halten den Vertikalschnitt zugleich überschaubar. Ein enger Anwendungsfall lässt sich schneller implementieren, gezielter testen und ehrlicher bewerten als ein allgemein formulierter „KI-Assistent“.

2. Nur notwendige Daten über die Modellgrenze geben

Das Modell erhält nicht automatisch das vollständige Domänenobjekt. Für die Fahrtdatenprüfung gibt es einen eigenen Request-Vertrag mit den tatsächlich benötigten Feldern:

• kurzlebige Request-ID
• Datum
• Start und Ziel
• Zweck
• Kilometer
• Fahrttyp
• optionale Kilometerstände

Stabile Datenbank-IDs, Notizen, Kilometergeldsätze, Audit-Zeitpunkte, Geräte- und Accountdaten sind weder Teil des API-Vertrags noch des Modell-Payloads.

Vertrags- und Prompt-Version werden getrennt behandelt. Dadurch lässt sich die Modellanweisung anhand neuer Evaluationen weiterentwickeln, ohne gleichzeitig den öffentlichen API-Vertrag zu ändern. Mobile- oder Webclients bleiben von internen Prompt-Iterationen entkoppelt.

3. Spring AI hinter einem eigenen Kotlin-Port kapseln

Spring AI übernimmt die technische Integration lokaler und cloudbasierter Modelle. Die Fach- und Anwendungsschicht kennt trotzdem weder einen konkreten Anbieter noch das Framework. Ihr Vertrag ist ein bewusst schmaler Kotlin-Port:

fun interface TripAnalysisModel {
    fun analyze(command: TripReviewCommand): TripAnalysisResult
}

Die Implementierung besitzt drei Adapter mit unterschiedlichen Aufgaben:

Adapter	Zweck
Deterministischer Fake	schnelle, reproduzierbare Standardtests ohne Netzwerk und Modellkosten
Lokales Modell über Spring AI und Ollama	reale Modellantworten lokal entwickeln und evaluieren
Cloud-Modell über Spring AI und OpenAI	bewusster, kostenpflichtiger Vergleich unter getrennten Kontrollen

Spring AI liefert dabei echten Integrationsnutzen: Providerkonfiguration, Modelloptionen, Timeouts, native Structured Outputs und die Einbettung in Spring Boot. Der eigene Port verhindert jedoch, dass Prompt-, Provider- oder Frameworkdetails in die Fachlogik durchsickern.

Die Verantwortlichkeiten bleiben klar:

1. Spring AI integriert Modelle.
2. Die Anwendung orchestriert die Fahrtdatenprüfung.
3. Kotlin-Domain-Code entscheidet, welche Kandidaten fachlich gültig sind.

Diese Trennung ist besonders für bestehende JVM- und Enterprise-Systeme relevant. Eine KI-Funktion wird dadurch Teil einer testbaren Softwarearchitektur und nicht zum isolierten Fremdkörper. Mehr zum technischen Umfeld steht auch unter App-Backend-Entwicklung.

4. Structured Output als Format, nicht als Wahrheit behandeln

Structured Output ist nützlich: Das Modell liefert bekannte Felder, definierte Kategorien und eine maschinenlesbare Struktur. Eine formal korrekte Antwort kann inhaltlich trotzdem falsch sein.

Das Modell könnte beispielsweise:

• eine nicht vorhandene Request-ID nennen
• einen Originalwert falsch zitieren
• eine numerische Auffälligkeit falsch klassifizieren
• denselben Befund mehrfach zurückgeben
• eine unerlaubte rechtliche oder steuerliche Aussage formulieren
• unerwartet lange Texte erzeugen

Deshalb endet die Vertrauenskette nicht beim JSON-Schema. Modellausgaben bleiben externe, probabilistische Eingaben.

5. Modellvorschläge vor der Anzeige verifizieren

Jeder Modellkandidat durchläuft eine serverseitige Prüfung. Nur wenn die relevanten Bedingungen erfüllt sind, wird daraus ein anzeigbarer Befund.

Der Verifier prüft unter anderem:

• Gehören alle referenzierten IDs zur aktuellen Anfrage?
• Decken die Belege die betroffenen Fahrten vollständig ab?
• Stimmen beobachtete Werte exakt mit den kanonischen Originaldaten überein?
• Erfüllt eine numerische Kategorie die in Kotlin definierten Schwellenwerte?
• Bleiben Erklärung und Korrekturvorschlag innerhalb der Produktgrenzen?
• Ist der Befund ein Duplikat oder überschreitet er das Anzeigelimit?

Numerische Regeln werden nicht nur im Prompt beschrieben, sondern im Domain-Code erneut berechnet. Ein Vertragstest schützt zusätzlich davor, dass Prompt und Server-Policy unbemerkt auseinanderlaufen.

Damit entsteht eine klare Rollenverteilung: Das Sprachmodell sucht semantisch flexible Kandidaten. Die Software prüft alles, was anhand vorhandener Daten und expliziter Regeln überprüfbar ist. Ein separater technischer Deep Dive mit konkreten Kotlin-Ausschnitten zu dieser Trust Boundary erscheint in Kürze.

6. Evaluation von Anfang an mitbauen

Einige überzeugende Antworten im Browser reichen nicht für eine Modellauswahl. Deshalb gehört zur Implementierung ein synthetisches Golden Dataset mit positiven, negativen, sicherheitsrelevanten und größeren Testfällen.

Gemessen werden unter anderem:

• Schema-Gültigkeit
• Precision und Recall insgesamt und pro Kategorie
• Grounding der tatsächlich angezeigten Befunde
• abgewiesene Modellkandidaten
• Prompt-Injection- und Policy-Fälle
• Latenz und Tokenverbrauch
• bei Cloud-Modellen zusätzlich geschätzte API-Kosten

Aktueller, versionierter Evaluationsstand

Die Ergebnisse sind eine Momentaufnahme des Teststands vom 12. August 2026. Grundlage waren die vierte Version des KI-Workflows, ein Golden Dataset mit 59 synthetischen Testfällen und die zu diesem Zeitpunkt verwendete Modellkonfiguration:

Provider und Modell	Schema	Precision	Recall	Grounding	Security
Ollama, gpt-oss:20b, low	100 %	96,2 %	86,2 %	100 %	bestanden
OpenAI, gpt-5.6-luna, low	100 %	100 %	100 %	100 %	bestanden

Das ist kein allgemeines Modellranking. Die Ergebnisse gelten nur für diese Kombination aus Modell, Konfiguration, Prompt und Dataset. Jede relevante Änderung verlangt eine neue Evaluation. Beim lokalen Lauf entstehen zwar keine API-Kosten, Hardware, Energie und Entwicklungszeit bleiben aber reale Aufwände.

Gerade die Unterschiede sind aufschlussreich: Das lokale Modell bestand die definierten Gates, ließ aber einzelne erwartete Befunde aus. Der Cloud-Kandidat erreichte im begrenzten Dataset vollständige Precision und Recall. Diese Daten helfen bei der nächsten Produktentscheidung; sie beweisen keine Qualität außerhalb der getesteten Fälle.

7. Lokales Modell und Cloud bewusst vergleichen

Ein lokales Modell ermöglicht reale Modelltests ohne laufende API-Kosten und ohne automatischen Cloud-Fallback. Ein Cloud-Modell dient als expliziter Vergleich unter getrennten Zugangsdaten, Budgets, Timeouts und Datenkontrollen.

Die Provider-Auswahl ist bewusst konfiguriert. Wenn Ollama lokal nicht verfügbar ist, wechselt das System nicht stillschweigend zu einem kostenpflichtigen oder datenschutzrechtlich anders zu bewertenden Anbieter.

Das macht auch sichtbar, dass „lokal“ und „Cloud“ keine rein technische Geschmacksfrage sind. Qualität, Latenz, Hardware, Betriebsaufwand, Region, Retention und Kosten müssen für das konkrete Produkt gegeneinander abgewogen werden. Einen breiteren Überblick über solche Produktentscheidungen gibt die Seite KI-Agenten und In-App-Assistenten.

8. Was vor einem produktiven Einsatz noch fehlt

Ein bestandener Golden-Dataset-Lauf macht den Vertikalschnitt nicht produktionsreif. Der aktuelle Stand deckt die fachliche und technische Kernlogik ab. Für einen produktiven Einsatz müssen die KI-Funktion, die vorgesehenen Clients und der spätere Betrieb jedoch als vollständiges System betrachtet werden.

Dazu gehören insbesondere:

• Integration und UX in den vorgesehenen Clients
• Authentifizierung, Autorisierung und Schutz vor missbräuchlicher Nutzung
• Prüfung von Hosting, Modellprovider und Datenflüssen
• Monitoring von Qualität, Kosten und Fehlerverhalten
• Last-, Sicherheits- und Ende-zu-Ende-Tests
• klare Verantwortlichkeiten für Modell-, Prompt- und Policy-Updates
• kontrollierter Rollout mit realen Qualitäts- und Kostenmetriken

Der Vertikalschnitt beantwortet damit nicht jede Produktionsfrage. Er zeigt aber, ob die fachliche Idee technisch tragfähig ist und welche Produkt-, Betriebs- und Datenschutzentscheidungen vor einem realen Einsatz noch getroffen werden müssen.

Was sich auf andere KI-Produkte übertragen lässt

Der Prozess ist nicht auf Fahrtenbuchdaten beschränkt. Er passt überall dort, wo ein Modell Vorschläge aus vorhandenen Daten ableitet und die Anwendung überprüfbare Grenzen benötigt:

• Dokumenten- und Datenqualitätsprüfung
• interne Support- und Service-Assistenten
• strukturierte Extraktion aus Freitext
• Vorbereitung manueller Freigaben
• semantische Dubletten- oder Konsistenzprüfung
• erklärbare Vorschläge in Fachanwendungen

Das konkrete Domänenmodell ändert sich. Die Trennung aus minimiertem Vertrag, Modell-Port, Verifikation, Human-in-the-loop und Evaluation bleibt.

Fazit

Der wichtigste Schritt bei der Entwicklung war nicht die Wahl des Modells. Entscheidend war ein so klar abgegrenztes Produktziel, dass sich probabilistische und deterministische Aufgaben sauber trennen lassen.

Kotlin und Spring Boot bilden dafür ein stabiles Backend-Fundament: klarer Vertrag, austauschbare Provider, testbare Fachregeln, kontrollierte Fehlergrenzen und eine Evaluation, die Modellentscheidungen nachvollziehbar macht.

So wird aus einem schnellen KI-Experiment eine evaluierte technische Grundlage, die nicht nur in einer Demo plausibel wirkt, sondern konkrete Antworten für die weitere Produktentwicklung liefert.

Sie planen eine KI-Lösung für Mobile Apps, Web oder bestehende Softwaresysteme?
creative workline unterstützt bei Produktabgrenzung, Architektur und Umsetzung – von Android und iOS über Web/PWA bis zu Kotlin-/Spring-Boot-Backends, Modellintegration und Evaluation.
Projekt besprechen

FAQ

Braucht jede KI-Funktion ein Golden Dataset?

Sobald verschiedene Prompts, Modelle oder Konfigurationen verglichen werden sollen, braucht es reproduzierbare Testfälle und erwartete Ergebnisse. Für einen frühen Vertikalschnitt kann das Dataset klein sein. Es sollte aber die wichtigsten positiven, negativen und sicherheitsrelevanten Fälle enthalten.

Reicht Structured Output zur Absicherung einer LLM-Antwort?

Nein. Structured Output stabilisiert das Format. IDs, Belege, fachliche Regeln und erlaubte Aussagen müssen weiterhin gegen vertrauenswürdige Daten und eine explizite Policy geprüft werden.

Warum Kotlin und Spring Boot für AI Engineering?

KI-Funktionen und LLM-Integrationen bestehen nicht nur aus Modellaufrufen. Sie benötigen APIs, Validierung, Security, Metriken, Tests und Integration in bestehende Systeme. Kotlin und Spring Boot eignen sich besonders, wenn bereits JVM- oder Enterprise-Landschaften vorhanden sind und KI als Produktfunktion integriert werden soll.

Lässt sich die KI-Funktion auch mit Node.js, TypeScript oder Python umsetzen?

Ja. Die beschriebenen Architekturprinzipien sind nicht an Kotlin oder Spring Boot gebunden. Ein klarer API-Vertrag, eine gekapselte Modellintegration, deterministische Prüfungen und eine reproduzierbare Evaluation lassen sich ebenso mit Node.js und TypeScript oder mit Python umsetzen.

Je nach Technologie-Stack übernehmen Frameworks unterschiedliche Teile dieser Integration: LangChain4j im Java-/JVM-Umfeld, das Vercel AI SDK für TypeScript-Anwendungen und Pydantic AI für typisierte Python-Integrationen. Sie sind keine direkten 1:1-Alternativen, unterstützen aber jeweils zentrale Aufgaben wie Modellzugriff, strukturierte Ausgaben oder Tool-Integration.

Die konkrete Umsetzung basiert auf Kotlin und Spring Boot, weil die Funktion in ein bestehendes JVM-/Spring-Backend integriert wird und sich fachliche Regeln dort typisiert und testbar abbilden lassen. Entscheidend sind die bestehende Codebasis, die Kompetenzen im Team und die Betriebsanforderungen.

Ist ein lokales Modell automatisch die bessere Datenschutzlösung?

Nein. Lokaler Betrieb kann Datenflüsse reduzieren, löst aber nicht automatisch Zugriffsrechte, Logs, Gerätesicherheit, Modellherkunft oder fachliche Risiken. Die geeignete Architektur hängt vom konkreten Produkt und seinem Schutzbedarf ab.

Wann ist eine KI-Funktion produktionsreif?

Nicht allein nach einem erfolgreichen Modelltest. Zusätzlich müssen Client-Zugriff, Abuse Controls, Kosten, Datenschutz, Monitoring, Fehlerverhalten, UX und Verantwortlichkeiten für Modell- und Prompt-Updates geklärt und im vollständigen System getestet sein.