Mit dem Geschäftsproblem beginnen, nicht mit dem KI-Modell

💡 Kurzfassung: Kernaussagen

• Ein leistungsfähiges Modell ist für sich genommen keine Geschäftsfähigkeit. Daten, Regeln, operative Systeme, Berechtigungen und mitunter menschliches Urteilsvermögen tragen alle zum Ergebnis bei.
• Definieren Sie Geschäftsergebnis, Aktionsgrenze und Evidenz, bevor Sie Modelle vergleichen. Die Modellauswahl hat wenig Bedeutung, solange nicht klar ist, was sich ändern soll und wie Erfolg gemessen wird.
• Beginnen Sie mit dem einfachsten System, das die Aufgabe erledigen kann. Manche Probleme brauchen ein Modell und einen festen Ablauf; andere lassen sich besser mit SQL, herkömmlicher Software oder expliziten Regeln lösen.

Ein Unternehmen möchte den Kundensupport mit KI verbessern. Im ersten Meeting landet die Diskussion bei einer vertrauten Liste: Welches LLM ist am genauesten, ob ein leistungsfähigeres Modell besser abschneidet und ob das System mehrere Modelle braucht.

Diese Fragen sind wichtig, kommen aber später.

Entscheiden Sie zuerst, was sich im Betrieb ändern soll. Das Ziel kann schnellere Antworten, weniger Suchzeit für Mitarbeitende oder mehr beim Erstkontakt gelöste Fälle sein. Ein System, das eine Antwort entwirft, ist zudem etwas anderes als ein System, das eine Rückerstattung auslösen darf. Solange diese Entscheidungen nicht klar sind, bleibt ein detaillierter Modellvergleich technisch interessant, aber von der Geschäftsentscheidung getrennt.

Was nötig ist, um einen Supportfall zu lösen

Ein Sprachmodell kann eine Kundennachricht verstehen und eine hilfreiche Antwort entwerfen. Ein Supportbetrieb braucht mehr. Er muss das betroffene Produkt identifizieren, die aktuelle Erstattungsrichtlinie abrufen, den Bestellstatus im richtigen System lesen und eine Informationsanfrage von einer Transaktionsanfrage unterscheiden. Soll es eine Rückerstattung anstoßen, muss es Betrag, Frist und Berechtigung des Nutzers prüfen. Einige Fälle müssen weiterhin an einen menschlichen Supportmitarbeiter gehen.

Diese vollständige, wiederholbare Fähigkeit, ein Ergebnis hervorzubringen, ist die Geschäftsfähigkeit. Das Modell kann ein wichtiger Teil davon sein, ist aber nicht die Fähigkeit selbst. Daten, Geschäftsregeln, bestehende Systeme, Berechtigungen und menschliches Urteilsvermögen bestimmen gemeinsam, ob die Arbeit zuverlässig erledigt werden kann.

Architektur ist daher mehr als ein Diagramm verbundener technischer Kästen. Sie legt fest, wie Modelle, Daten, Software und Menschen zusammenarbeiten, um das gewünschte Ergebnis zu liefern. Die Unterscheidung ähnelt dem Unterschied zwischen Technologieverwaltung und Unternehmensveränderung: Technologie zu betreiben und damit eine Geschäftsfähigkeit zu verändern, sind unterschiedliche Verantwortungen.

Bauen Sie nur das System, das die Arbeit erfordert

Allgemeine Modelle können heute Text verstehen, Bilder prüfen, begründete Antworten erzeugen und Softwarewerkzeuge verwenden. Das macht eine Flotte von Modellen und Agenten nicht zur Standardarchitektur.

Ein Agent gibt einem Modell mehr Spielraum, Werkzeuge auszuwählen und die eigene Arbeit zu sequenzieren. Ein Ablauf mit bekannten Schritten braucht diesen Spielraum möglicherweise nicht. Der Produktionsleitfaden von Anthropic empfiehlt, mit der einfachsten funktionierenden Lösung zu beginnen. Der Architekturleitfaden von Google Cloud unterscheidet ähnlich zwischen festen Prozessen und offenen Aufgaben, bei denen das Modell einen Weg wählen muss.

Oft reichen ein leistungsfähiges Modell, ein enger Werkzeugsatz und softwaredefinierte Ablaufschritte. Fügen Sie ein zweites Modell, eine Routing-Schicht oder einen Agenten nur hinzu, wenn dies Qualität, Kosten, Geschwindigkeit oder Risiko nachweislich verbessert. Ziel ist nicht, KI-Komponenten anzuhäufen, sondern das Ergebnis zu erzielen, ohne Komplexität hinzuzufügen, die der Betrieb nicht braucht.

Manchmal lautet die beste Antwort: keine KI

Ob eine Erstattungsfrist abgelaufen ist, benötigt möglicherweise kein Sprachmodell. Wenn Bestelldatum, Produkttyp und Vertragsbedingungen erfasst sind, können eine SQL-Abfrage und explizite Geschäftsregeln genauer, günstiger und leichter prüfbar sein.

Optimierungssoftware kann für Schichtplanung oder Routenplanung passen, wenn Ziele und Einschränkungen explizit sind. Für Vorhersagen aus strukturierten Tabellen kann klassisches maschinelles Lernen ein starker Ausgangspunkt sein.

Eine einfachere Methode zu wählen, ist kein gescheitertes KI-Projekt. Es ist solides Systemdesign. In einem realen Chatbot-Projekt war die schwierige Aufgabe nicht nur, eine Antwort zu erzeugen: Integration, zuverlässige Übergabe und laufender Betrieb bestimmten das Ergebnis.

Eine Grenze zwischen Vorschlag und Aktion

Ein Modell kann die richtigen Informationen für eine Erstattungstransaktion vorbereiten. Das gibt ihm nicht die Befugnis, die Transaktion auszuführen.

Definieren Sie bei Systemen, die Geld, Kundendaten oder externe Kommunikation betreffen, zwei Grenzen getrennt: welche Aktionen ein Modell empfehlen darf und welche Aktionen das System tatsächlich ausführen darf. Einem Modell zu sagen, es dürfe nur autorisierte Aktionen ausführen, ist keine Zugriffskontrolle. Die Transaktion muss gegen die tatsächlichen Berechtigungen des Nutzers oder Dienstes geprüft, bei Bedarf zur menschlichen Freigabe geleitet und später prüfbar protokolliert werden. Auch der OWASP-Leitfaden zu übermäßiger Handlungsautonomie empfiehlt, Aktionen im Kontext des Nutzers und nur mit den erforderlichen Berechtigungen auszuführen.

Autorisierung ist kein Sicherheitsmerkmal, das man am Ende ergänzt. Sie ist eine Geschäftsentscheidung, die an den Anfang des Entwurfs gehört.

Messen Sie die Arbeit, nicht nur die Antwort

Ein Supportsystem kann einem Kunden sagen: „Ihre Erstattung wurde veranlasst.“ Der Satz kann klar sein und der Richtlinie entsprechen. Entscheidend ist zunächst, ob das Bestellsystem tatsächlich einen Erstattungsvorgang enthält.

Selbst dieser Eintrag beweist noch keinen Geschäftserfolg. Wenn sich Lösungen beim Erstkontakt, Kundenzufriedenheit, Verluste und Arbeitslast der Supportmitarbeitenden nicht verändern, ist das beabsichtigte Ergebnis möglicherweise nicht eingetreten.

Messen Sie die Modellantwort, die vom System abgeschlossene Aktion und die Wirkung auf das Unternehmen getrennt. Dieselbe Unterscheidung erscheint beim Prüfungsengpass in KI-generiertem Code: Ein Ergebnis zu erzeugen beweist nicht, dass es richtig umgesetzt wurde.

Drei Entscheidungen vor der Modellauswahl

Klären Sie vor dem Modellvergleich drei Entscheidungen:

1. Geschäftsergebnis: Welche Entscheidung, welcher Ablauf oder welches messbare Ergebnis soll sich verändern? Wie sieht der aktuelle Ausgangswert aus?
2. Aktionsgrenze: Wird das System Informationen liefern, eine Empfehlung vorbereiten oder eine reale Transaktion ausführen? Wo ist menschliche Freigabe erforderlich?
3. Evidenz: Wie werden Modellantwort, abgeschlossene Aktion, Kosten und Geschäftsergebnis gemessen?

Sind diese Entscheidungen geklärt, lassen sich die nötigen Daten, Regeln, Integrationen und Modelle deutlich leichter identifizieren.

Die Modellauswahl ist nicht trivial; sie beeinflusst sowohl die Fähigkeiten des Systems als auch seine Wirtschaftlichkeit. Nützlich wird sie aber erst, nachdem das Unternehmen verstanden hat, was es verändern will und innerhalb welcher Grenzen das System arbeiten muss.

Die nächste Frage lautet möglicherweise nicht „Welches Modell ist besser?“, sondern: „Braucht dieses Problem überhaupt KI?“

Diese Entscheidung untersuche ich anhand von drei realen Systemen in Wann braucht Prozessautomatisierung tatsächlich KI?

Die weiteren Entscheidungen zu Modellen, Informationen, Autorität und Bewertung finden Sie im Leitfaden zum Entwurf eines KI-Systems für Ihr Unternehmen.