Wie wir eine kleine lokale KI im Prozess verlässlich gemacht haben

Sprachmodelle erzeugen Text Schritt für Schritt und wählen dabei jeweils eine von mehreren plausiblen Fortsetzungen. Deshalb können zwei Aufrufe mit derselben Eingabe leicht verschieden ausfallen. In einem frühen Test haben wir dieselbe Bestellung zweimal durch das Modell geschickt: Einmal stand der Wunschtermin im Ergebnis, einmal der Hinweis, der Termin sei dem Dokument nicht sicher zu entnehmen. Beides war vertretbar. Verschieden war es trotzdem.

In einem Gespräch ist das oft kein Problem. In einer Auftragsvorbereitung, einer Pflegedokumentation oder einem anderen verbindlichen Ablauf reicht „meistens richtig“ nicht.

Verlässlich wird nicht das Modell allein. Verlässlich wird die ganze Anwendung.

Warum ein größeres Modell nicht genügt

Ein größeres Modell versteht schwierige Sprache oft besser. Es kann trotzdem einen Wert erfinden, ein Feld vergessen, eine alte Information verwenden oder einen unzulässigen Schritt vorschlagen.

Bei einem Chat ist die Antwort das Ergebnis. In einer betrieblichen Lösung ist sie nur ein Zwischenschritt. Entscheidend ist, was am Ende im System steht und was tatsächlich ausgelöst wurde.

Regel 1: Große Aufgaben klein schneiden

„Bearbeite diese Bestellung vollständig“ ist ein schlechter Auftrag an ein Modell — darin stecken zu viele verschiedene Tätigkeiten. Wir trennen den Ablauf in vier Stufen. Zuerst wird erkannt, um welchen Dokumenttyp, welchen Kunden und welche Sprache es geht. Dann liest ein Schritt Positionen, Mengen, Termin und Hinweise aus dem Dokument. Ein dritter prüft die Angaben gegen Systemwerte, Regeln und Widersprüche. Erst am Ende formuliert ein Schritt den Entwurf — ausschließlich aus geprüften Angaben.

Für jeden Schritt ist festgelegt, was hineingeht, was herauskommen darf und wann er stoppt. Der Leseschritt darf Positionen erkennen, aber keinen Liefertermin zusagen. Der Formulierungsschritt darf einen guten Satz schreiben, aber keine Zahl verändern.

Diese Trennung zahlt sich mehrfach aus: Ein Fehler lässt sich einer bestimmten Stufe zuordnen, einfache Schritte laufen ganz ohne KI, jede Stufe sieht nur die Daten, die sie braucht, und Tests können eine einzelne Fähigkeit gezielt prüfen. Vor allem macht ein einzelner Fehler nicht den ganzen Vorgang unbrauchbar.

Regel 2: Die Antwort in eine feste Form bringen

Das nächste Programm braucht keine schön formulierte Antwort. Es braucht feste Felder. Die Antwort folgt deshalb einem Schema, also einer vorgegebenen Liste von Angaben:

{
  "order_number": "4711-A",
  "customer_id": "K-2049",
  "items": [
    {"sku": "GT-18", "quantity": 2500, "unit": "piece"}
  ],
  "requested_delivery_date": "2026-09-14",
  "special_notes": ["Werkzeugfreigabe beachten"],
  "evidence": [
    {"field": "requested_delivery_date", "page": 2, "quote": "..."}
  ],
  "needs_review": false,
  "review_reasons": []
}

Ein Modell, das gebeten wird, sich an ein Schema zu halten, hält sich meistens daran. Meistens. Deshalb prüft danach normale Software:

• Fehlt eine Pflichtangabe?
• Ist ein Datum wirklich ein Datum und eine Menge wirklich eine Zahl?
• Enthält die Antwort ein Feld, das nicht vorgesehen ist?
• Liegt eine Menge in einem sinnvollen Bereich?
• Gibt es Artikelnummer und Kunde in den internen Systemen?
• Zeigt die Lösung, wo der Wert im Dokument steht?

Diese Prüfung ersetzt kein Fachwissen. Sie fängt aber viele einfache Fehler ab, bevor ein Mensch sie suchen muss.

Regel 3: Fakten außerhalb des Modells prüfen

Ein Sprachmodell kann uneinheitliche Texte verstehen und gute Formulierungen erzeugen. Es ist aber nicht die richtige Quelle für aktuelle Bestände, Preise oder Kapazitäten. Diese Werte kommen direkt aus den zuständigen Anwendungen.

Texte nur aus geprüften Angaben erzeugen

Für eine Auftragsbestätigung erhält das Modell bereits geprüfte Fakten und freigegebene Textbausteine. Wie wichtig das ist, zeigte ein früher Testlauf: Aus einem „voraussichtlich lieferbar“ in den Eingangsdaten machte das Modell ein flüssiges „wird geliefert“. Der Satz war eleganter. Er war auch eine Zusage, die niemand gemacht hatte.

Zahlen und Zusagen werden deshalb fest eingesetzt oder nach dem Schreiben noch einmal mit den geprüften Angaben verglichen. Das Modell darf Stil und Satzbau verbessern. An den Fakten kommt es nicht vorbei.

Regel 4: Unsicherheit sichtbar machen

Ein Modell kann nicht verlässlich selbst angeben, wie sicher es ist. Eine Prozentzahl aus der KI ist deshalb höchstens ein Hinweis. Besser sind Merkmale, die sich wirklich prüfen lassen:

• Eine Pflichtangabe fehlt oder widerspricht einer anderen Angabe.
• Eine Artikelnummer existiert nicht.
• Text im PDF und sichtbares Dokument zeigen verschiedene Werte.
• Ein wichtiger Wert hat keine klare Fundstelle.
• Zwei Prüfwege kommen zu verschiedenen Ergebnissen.
• Der Fall passt zu keiner bekannten Dokument- oder Prozessvariante.

Bei solchen Signalen wechselt der Vorgang in den manuellen Modus. Die zuständige Person sieht den Grund und die betroffene Stelle. Das ist schneller als ein rotes Warnsymbol ohne Erklärung — und deutlich schneller, als den Fehler drei Systeme später zu suchen.

Menschliche Freigabe muss prüfbar sein

Eine gute Oberfläche zeigt Quelle, erkannten Wert, Systemprüfung und vorgeschlagenen Text nebeneinander. Ein einzelner „OK“-Knopf unter einem langen KI-Text schafft vor allem einen weiteren Knopf.

Wie wir Verlässlichkeit messen

Eine Demo mit zehn ausgewählten Dokumenten beweist wenig — Demos gehen immer gut, die Dokumente sind ja ausgesucht. Für die Freigabe braucht es einen festen Testsatz mit normalen Fällen, Grenzfällen und den Fehlern, an denen frühere Versionen gescheitert sind.

Die richtigen Grenzen hängen vom Schaden eines Fehlers ab. Eine falsche interne Kategorie ist anders zu bewerten als ein falscher Liefertermin. Das muss vor dem Test feststehen — nicht nach dem ersten Ergebnis, das nicht gefällt.

Warum ein kleineres lokales Modell ausreichen kann

Ein allgemeiner Chat muss sehr viele Aufgaben beherrschen. Unsere Anwendung löst einen engen Prozess. Sie erhält passende Funktionen, aktuelle Unternehmensdaten, feste Ausgaben und klare Prüfungen.

Damit muss das Modell nicht alles wissen. Es muss nur die wenigen Teile gut lösen, für die Sprache oder Bilder wichtig sind. Die Software fängt den Rest ab.

Fazit

Ein kleineres lokales Modell wird durch einen besseren Prompt nicht unfehlbar. Verlässlichkeit entsteht aus dem Aufbau der Anwendung: kleine Aufgaben, feste Ausgaben, unabhängige Prüfungen und ein sauberer Weg für unklare Fälle.

Die entscheidende Beschaffungsfrage lautet deshalb nicht nur: Welches Modell gewinnt den Vergleich? Wichtiger ist: Was verhindert, dass ein Modellfehler zu einem Geschäftsfehler wird?