KI-Workflows brauchen Tests, nicht nur Intuition

Wenn ein KI-Workflow nur dadurch geprüft und getestet wird, dass jemand ein paar Antworten liest und „sieht gut aus“ sagt, ist er vermutlich noch kein Workflow für den Unternehmenseinsatz. Er ist weiterhin ein Experiment.

Derzeit versuchen viele Unternehmen den Sprung von „klassischen“ KI-Chat-Interaktionen hin zu einer KI-Nutzung, die auf den eigenen Bedarf zugeschnitten ist: eigene Skills, spezialisierte Agenten und zentrale automatisierte Workflows.

Doch je weiter man sich von dem Chat-Interface entfernt, desto deutlicher wird ein praktisches Problem: Intuition skaliert nicht.

Eine kleine Anpassung an einem zentralen KI-Setup sieht immer harmlos aus:

• Man passt eine Skill-Definition an, damit ein Randfall besser funktioniert.
• Man wechselt auf ein neueres Modell, weil die Benchmarks vielversprechend aussehen.
• Man wechselt auf ein kleineres Modell, um API-Kosten zu senken.

Aber wenn im Prompt eines Agenten ein Fehler behoben wird, kann das leicht negative Auswirkungen auf den Use Case haben, der in der vorherigen Woche noch funktioniert hat. In der KI-Welt kann eine kleine Prompt-Änderung an einer Stelle eine überraschend große Regression an einer vollkommen anderen Stelle auslösen.

Wenn wir in klassischer Software eine gemeinsam genutzte Bibliothek anfassen, lassen wir Tests laufen. Bei KI verlassen sich viele Teams weiterhin auf manuelle Prüfung und Bauchgefühl. Sie testen ein paar Beispiele, sehen, was sie sehen wollen, und liefern aus.

Prompts, Systemanweisungen und Agenten-Workflows sind nicht bloß Konfiguration. Sie definieren Softwareverhalten. Und Verhalten kann Regressionen entwickeln.

Diese Seiteneffekte allein mit manuellen Prüfungen zu verfolgen, ist praktisch unmöglich. Wer den Schritt vom Herumprobieren mit KI zum professionellen Einsatz gehen will, für den wird Zuverlässigkeit zu einem der entscheidenden Faktoren. Ein Geschäftsprozess lässt sich nicht auf der Grundlage von Versuch und Irrtum skalieren.

Eine KI-Testsuite aufsetzen

Das Claude-Plugin meines Bereichs mit mehreren zugeschnittenen Skills muss zuverlässig funktionieren. Menschen nutzen es in ihrer täglichen Arbeit, und die Akzeptanz hängt stark von verlässlichen Ausgaben ab.

Um Änderungen mit mehr Sicherheit vorzunehmen, nutze ich automatisierte Tests mit promptfoo.

1. Die Assets: die konkreten Prompts, Skills und Modelle benennen, die evaluiert werden sollen.
2. Die Datensätze: realistische Eingabedateien oder Szenarien vorab festlegen.
3. Die Assertions: strenge, automatisierte Regeln für die Ausgabe aufstellen. Hält die Ausgabe das geforderte JSON-Schema ein? Verweigert das System die Antwort, wo es sie verweigern soll? Wurden die richtigen Tool-Calls aufgerufen?

Woran man auf Organisationsebene merkt, dass sich das auszahlt:

• Sicherere Iteration: Wenn sich ein KI-Skill falsch verhält, nimmt man zuerst den fehlschlagenden Fall in die Testsuite auf, danach passt man den Prompt an. So entsteht der Nachweis, dass die Korrektur wirkt, ohne unbemerkt altes Verhalten auszuhebeln.
• Belegte Kostenoptimierung: Man möchte ein leistungsfähiges Modell gegen ein günstigeres tauschen? Die Testsuite kann verschiedene Modelle miteinander vergleichen. Erfüllt das günstigere Modell dieselben Assertions, erfolgt der Wechsel mit Belegen statt bloßem Bauchgefühl.

Die Hype-Phase der KI hinter sich zu lassen heißt, die eigenen KI-Setups mit derselben Disziplin zu behandeln wie jedes andere Software-Artefakt.

Dabei kann man jederzeit klein anfangen: ein paar realistische Beispiele sammeln, klare Erwartungen an die Ausgaben festlegen und diese Beispiele bei jeder Änderung am Setup erneut durchlaufen lassen.

Damit lassen sich weit mehr Fehler finden, als es mit Bauchgefühl je möglich wäre, und es entsteht die Grundlage dafür, KI über einen ganzen Bereich zu skalieren: die Sicherheit, iterieren zu können, ohne die Qualität zu verschlechtern.

Über das Testen hinaus: Verantwortung

In größeren Organisationen wird daraus auch eine Frage des Betriebsmodells. Wer ist Owner eines gemeinsam genutzten KI-Skills? Wie werden Änderungen geprüft? Welche Beispiele stehen für akzeptables Verhalten? Und wann ist ein Modellwechsel gut genug für den Rollout?

Tests beantworten all das nicht, aber sie geben Teams eine belastbare Faktengrundlage für die Diskussion.

Beispiel: promptfoo im Einsatz

Hier ein einfaches Beispiel, wie eine promptfooconfig.yaml aufgebaut ist.

promptfoo lässt sich an viele Formen der Evaluation anpassen. Das Werkzeug zählt weniger als die Gewohnheit: einen stabilen Satz von Testfällen pflegen und ihn ausführen, sobald sich das KI-Setup ändert.

providers:
  - id: anthropic:messages:claude-sonnet-4-6
  - id: anthropic:messages:claude-opus-4-8

prompts:
  - |-
    Analysiere dieses Support-Ticket und gib ein JSON-Objekt mit sentiment
    (positive, neutral, negative) und summary zurück: {{ticket}}

tests:
  - vars:
      ticket: "Ich warte seit drei Tagen auf meine Rückerstattung. Das ist inakzeptabel."
    assert:
      - type: contains-json
        value:
          required:
            - sentiment
            - summary
          type: object
          properties:
            sentiment:
              type: string
              enum: ["positive", "neutral", "negative"]
            summary:
              type: string
      - type: contains
        value: "negative"

  - vars:
      ticket: "Können Sie mir bitte meinen Kontostand nennen?"
    assert:
      - type: contains-json
        value: file://./path/to/schema.json
      - type: contains
        value: "neutral"