KI-Aufträge präzisieren: Ergebnisformat und Grenzen festlegen

Ein KI-Auftrag ist prüfbar, wenn er den Verwendungszweck, die erlaubten Eingaben, die erwartete Ausgabe und die Abbruchgrenzen beschreibt. "Fasse das sinnvoll zusammen" lässt diese Entscheidungen offen. "Erstelle aus den freigegebenen Notizen eine Aufgabenliste; fehlende Zuständigkeiten bleiben leer und werden zur Klärung markiert" gibt dagegen einen kontrollierbaren Arbeitsrahmen vor.

Das Ergebnisformat allein reicht nicht. Eine formal korrekte Tabelle kann unbelegte Angaben enthalten. Ein gültiges JSON-Dokument kann eine falsche Kundennummer transportieren. Deshalb braucht dein Auftrag zwei getrennte Abnahmen: Passt die Form zum nächsten Arbeitsschritt? Und stimmen die Inhalte mit den Quellen und den fachlichen Regeln überein? Der folgende Briefingbogen ist ein eigener Praxisvorschlag für diese Trennung.

Beginne beim Empfänger des Ergebnisses

Beschreibe zuerst, wer mit dem Ergebnis weiterarbeitet. Ein Mensch liest einen erläuternden Absatz anders als ein Importprogramm. Für eine fachliche Entscheidung sind Begründung und offene Punkte wichtig. Für einen automatischen Import müssen Feldnamen, Datentypen und zulässige Werte exakt feststehen. Ein Auftrag, der beide Zwecke vermischt, erzeugt häufig einen unklaren Kompromiss.

Im fiktiven Beispiel dieses Artikels bereitet ein Serviceteam Rückrufaufgaben aus Gesprächsnotizen vor. Eine Sachbearbeiterin prüft die Vorschläge und übernimmt freigegebene Aufgaben in das CRM. Das Modell erhält keinen Schreibzugriff auf das CRM. Der gewünschte Output ist eine prüfbare Liste von Vorschlägen mit Quellenbezug. Die spätere Freigabe bleibt ein eigener Arbeitsschritt.

Aus dieser Verwendung folgen konkrete Anforderungen: Jede Aufgabe braucht einen Text, einen Status zur Zuständigkeit und eine Fundstelle. Ein Termin erscheint nur, wenn er in der Notiz ausdrücklich genannt ist. Die Quelle kann eine Bitte enthalten, die noch niemand angenommen hat. Der Auftrag muss diesen Unterschied erhalten, weil sonst aus einem Kundenwunsch eine interne Zusage wird.

Definiere die Grenze der zulässigen Schlussfolgerung

Nicht jede Ableitung ist verboten. Eine ausdrücklich genannte Bitte um Rückruf lässt sich als Rückrufaufgabe formulieren. Aus "Ich bin am Freitag nicht erreichbar" folgt dagegen noch kein vereinbarter Rückruf am Donnerstag. Schreibe deshalb auf, welche Umformung erlaubt ist und ab wann eine zusätzliche Entscheidung nötig wird.

Für das Beispiel gilt: Das Modell darf den Wortlaut verkürzen und mehrere identische Erwähnungen derselben Aufgabe zusammenführen. Es darf keine Zuständigkeit aus früheren Gewohnheiten ergänzen. Es darf keinen Termin aus allgemeinen Serviceversprechen ableiten. Wenn die Quelle widersprüchlich ist, muss es den Widerspruch ausgeben und die Aufgabe zur Prüfung markieren.

Diese Regeln gehören vor die Formatanweisung. Sonst erzeugt das Modell eine vollständig ausgefüllte Tabelle, obwohl die fachliche Grundlage fehlt. Eine passende Ergänzung liefert Arbeitsabläufe mit ChatGPT als Vorlage beschreiben. Dort steht die wiederholbare Aufgabe im Vordergrund; hier wird ihre konkrete Ausgabegrenze festgelegt.

Ein Briefingbogen mit ausgefülltem Beispiel

Der folgende Bogen ist eine eigene Arbeitsvorlage. Er ersetzt keine fachliche Regelung. Fülle ihn gemeinsam mit der Person aus, die das Ergebnis abnimmt. Wo ihr keine eindeutige Antwort habt, bleibt der Punkt offen und sperrt bei Bedarf die spätere Automatisierung.

Die letzte Zeile ist kein dekorativer Hinweis. Ohne benannte Abnahme bleibt unklar, wer die Verantwortung für eine fehlerhafte Aufgabe übernimmt. Für einen späteren technischen Ausbau muss zusätzlich feststehen, welche Felder eine Maschine prüft und welche eine Person beurteilt. Diese Aufteilung lässt sich aus dem Bogen ableiten, aber nicht durch die Formulierung "Qualität sicherstellen" ersetzen.

Was ein Schema tatsächlich prüft

Die JSON-Schema-Dokumentation zu Objekten unterscheidet zwischen beschriebenen Eigenschaften und Pflichtfeldern: Ein Eintrag unter properties ist nicht automatisch erforderlich. Pflichtfelder stehen in required. Mit additionalProperties: false lassen sich nicht vorgesehene Felder ausschliessen. Ein fehlendes Feld und ein vorhandenes Feld mit null sind unterschiedliche Zustände.

Daraus folgt für dein Briefing: Entscheide ausdrücklich, ob ein Wert fehlen darf, leer sein darf oder einen definierten Status braucht. Diese Entscheidung ist Teil des fachlichen Vertrags. JSON Schema prüft die festgelegte Struktur. Es liest nicht automatisch die Gesprächsnotiz und bestätigt keine Wahrheit der Angaben. Eine Quellenprüfung bleibt zusätzlich notwendig.

Ein bewusst kleines, selbst erstelltes Beispiel für einen Aufgabenentwurf lautet:

{
  "type": "object",
  "properties": {
    "task": { "type": "string", "minLength": 1 },
    "source_id": { "type": "string", "minLength": 1 },
    "review_status": { "enum": ["ready_for_review", "needs_clarification"] }
  },
  "required": ["task", "source_id", "review_status"],
  "additionalProperties": false
}

Dieses Schema verlangt einen nicht leeren Aufgabentext und eine Quellen-ID. Es prüft noch nicht, ob diese ID in deinem System existiert. Auch ein Text mit einer erfundenen Zusage passt formal hinein. Genau deshalb muss die technische Prüfung um Referenzprüfungen und fachliche Abnahme ergänzt werden. Das Beispiel ist eine Strukturübung, keine vollständige CRM-Schnittstelle.

Zeige ein richtiges Ergebnis und ein Gegenbeispiel

Eine Vorlage wird verständlicher, wenn sie dieselbe Quelle einmal korrekt und einmal unzulässig verarbeitet. Die fiktive Notiz lautet: "Kunde bittet um Rückruf zur Preisfrage. Zuständigkeit noch offen." Ein zulässiger Aufgabenentwurf ist: "Rückruf zur Preisfrage vorbereiten; Zuständigkeit offen; Klärung erforderlich." Ein unzulässiger Entwurf lautet: "Vertrieb ruft morgen mit einem Rabattangebot zurück."

Das Gegenbeispiel enthält gleich mehrere nicht belegte Ergänzungen. Markiere sie einzeln: Vertrieb als Zuständigkeit, morgen als Termin und Rabatt als Inhalt. So lernt die prüfende Person, was genau die Grenze verletzt. Die pauschale Bewertung "halluziniert" erklärt den fachlichen Fehler weniger gut als diese Zuordnung.

Verwende Beispiele nicht als Ersatz für die Regel. Ein Modell kann eine gezeigte Struktur nachahmen, ohne eine neue Situation korrekt zu behandeln. Teste deshalb weitere Varianten mit fehlender Quelle, zwei widersprüchlichen Terminen und einer Notiz ohne Aufgabe. Der Artikel Beispiele im Prompt einsetzen vertieft die Auswahl solcher Fälle.

Lege fest, was bei fehlenden Angaben passiert

Ein fehlender Termin braucht nicht automatisch eine Rückfrage. Wenn der nächste Arbeitsschritt auch ohne Termin möglich ist, reicht eine sichtbare Kennzeichnung. Fehlt dagegen die Zuordnung zum richtigen Vorgang, darf die Aufgabe nicht in eine fremde Kundenakte gelangen. Der Auftrag muss zwischen hilfreichen Zusatzangaben und blockierenden Pflichtangaben unterscheiden.

Erstelle dafür eine kleine Entscheidungsliste. Fehlende Zuständigkeit: Entwurf zur Klärung. Fehlende Quellen-ID: keine Übernahme. Widersprüchliche Termine: beide Fundstellen zeigen. Keine erkennbare Aufgabe: leere Aufgabenliste mit Erklärung. Diese Fälle verhindern den Druck, unter allen Umständen einen vollständig gefüllten Datensatz zu erzeugen.

Auch die Rückfrage selbst braucht eine Grenze. Das System fragt nach der konkreten fehlenden Information und schlägt keine unbelegte Antwort vor. "Welche Vorgangsnummer gehört zur Notiz?" ist eine klare Frage. "Gehört das vermutlich zu Kunde A?" kann eine falsche Zuordnung nahelegen, wenn dafür kein Beleg existiert. Für solche Grenzen ergänzt Quellen mit KI prüfen den fachlichen Kontrollweg.

Prüfe Form, Bezug und Bedeutung getrennt

Die erste Prüfung kontrolliert die Form: gültiges JSON, richtige Felder, zulässige Statuswerte. Die zweite Prüfung kontrolliert den Bezug: Existiert die Quellen-ID, gehört sie zum freigegebenen Fall und ist die Fundstelle erreichbar? Die dritte Prüfung kontrolliert die Bedeutung: Steht die Aufgabe tatsächlich dort, und bleibt ihr Status erhalten?

Diese Trennung hilft bei der Fehlerbehebung. Ein falscher Feldname erfordert eine andere Korrektur als eine erfundene Zusage. Wenn du alle Fehler als "schlechte Antwort" sammelst, verliert das Team diese Unterscheidung. Dokumentiere deshalb die verletzte Regel und den betroffenen Ausschnitt. Die neue Fassung muss genau gegen diesen Fehlerfall geprüft werden.

Bei maschineller Weiterverarbeitung kommt eine weitere Grenze hinzu: Ein formal akzeptierter Entwurf darf nicht automatisch dieselben Rechte erhalten wie ein fachlich freigegebener Datensatz. Halte Freigabestatus und Generierungsstatus getrennt. Ein Modellaufruf erzeugt einen Vorschlag. Erst der vorgesehene Abnahmeprozess erlaubt die externe Wirkung.

Lege auch die Reihenfolge und Länge bewusst fest

Ein Ergebnisformat enthält mehr als Feldnamen. Für eine Übergabe kann die Reihenfolge der Aufgaben relevant sein: nach ausdrücklich genanntem Termin, nach Quellenreihenfolge oder nach einem freigegebenen Prioritätsfeld. Wenn keine Priorisierung beauftragt ist, darf das Modell Dringlichkeit nicht allein aus einem energischen Tonfall ableiten. Beschreibe deshalb die Sortierregel oder lasse die ursprüngliche Reihenfolge erhalten.

Auch Längengrenzen brauchen einen Zweck. Eine kurze Anzeige im Fachsystem kann ein knappes Aufgabenfeld verlangen, während die Begründung separat gespeichert wird. Kürze nicht so stark, dass Bedingungen verschwinden. Im fiktiven Fall muss der Hinweis auf eine offene Zuständigkeit erhalten bleiben, selbst wenn der Aufgabentext dadurch länger wird. Bei einem Konflikt zwischen Formatgrenze und notwendiger Bedeutung wird der Fall zur Prüfung markiert.

Prüfe diesen Konflikt mit einem absichtlich langen Beispiel. Die erwartete Ausgabe kann aus einem kurzen Titel und einer vollständigen Erläuterung bestehen. Falls das Zielsystem nur ein einziges kurzes Feld erlaubt, muss der Fachbereich entscheiden, wie die nötige Information sicher erhalten bleibt. Ein Prompt kann diese Systemgrenze nicht wegformulieren.

Dokumentiere zuletzt, ob leere Ergebnisse zulässig sind. Eine Notiz ohne Aufgabe darf keine erfundene Aufgabe erzeugen, nur weil das Format eine Liste erwartet. Die leere Liste ist in diesem Fall das fachlich richtige Ergebnis. Ein zusätzlicher Status erklärt, dass die Prüfung durchgeführt wurde und keine passende Aufgabe vorlag. Damit unterscheidest du ein gültiges leeres Ergebnis von einer fehlgeschlagenen Verarbeitung.

Teste die Vorlage vor ihrer Weitergabe

Baue einen kleinen Satz unterschiedlicher Fälle auf. Ein normaler Vorgang prüft den Hauptweg. Ein Vorgang ohne Aufgaben prüft die leere Ausgabe. Ein Fall mit widersprüchlichen Aussagen prüft die Klärung. Ein Fall mit Anweisungen innerhalb der Notiz prüft, ob die Quelle als Material behandelt wird. Ein Fall mit sehr langen Angaben prüft die vereinbarten Längengrenzen.

Die Zahl der Fälle ist kein Qualitätsnachweis für sich. Massgeblich für die Prüfung ist, ob die wichtigen Fehlerarten tatsächlich vorkommen. Dokumentiere pro Fall das erwartete Verhalten vor dem Test. Eine Vorlage besteht nicht allein dadurch, dass jede Antwort lesbar ist. Sie muss an den vorher festgelegten Grenzen korrekt reagieren.

Gib den Bogen anschliessend einer anderen Person und lasse sie einen neuen Fall bearbeiten. Wenn sie die Regeln ohne mündliche Ergänzungen versteht, ist die Übergabe nachvollziehbar. Muss sie ständig nachfragen, fehlen Angaben im Auftrag. Eine KI-Vorlage im Kollegentest prüfen beschreibt diesen letzten Schritt. Erst danach erhält die Vorlage den vereinbarten Einsatzstatus und eine verantwortliche Person für spätere Änderungen.