Mit KI einen Projektauftrag auf fehlende Entscheidungen prüfen

Ein Projektauftrag ist noch nicht arbeitsfähig, wenn er ein attraktives Ziel beschreibt. Vor dem Start muss feststehen, welches Ergebnis geliefert wird, wer darüber entscheidet und woran die Abnahme erkennbar ist. KI kann fehlende Entscheidungen sichtbar machen. Sie darf die Lücken nicht mit plausiblen Zusagen füllen.

Dieser Leitfaden prüft einen fiktiven Auftrag für einen internen Wissensassistenten. Er zeigt die Differenz zwischen Textverbesserung und echter Entscheidungsvorbereitung. Alle Termine, Mengen und Rollen sind Beispielannahmen. Der Artikel ersetzt keine Prüfung eines konkreten Vertrags oder einer verbindlichen Projektvereinbarung.

Eine bessere Formulierung löst keine offene Entscheidung

Aus "Wir brauchen eine einfache Wissenslösung" kann KI einen professionell klingenden Absatz machen. Die eigentlichen Fragen bleiben trotzdem offen: Für wen ist die Lösung gedacht? Welche Quellen darf sie nutzen? Welche Antworten muss sie liefern? Wer übernimmt die Pflege? Welche Fehler verhindern die Freigabe?

Eine unklare Anforderung wird nicht dadurch prüfbar, dass sie ausführlicher formuliert ist. Die NASA-Checkliste für gute Anforderungen betont unter anderem Eindeutigkeit, Prüfbarkeit und die Vermeidung nicht messbarer Begriffe. Sie stammt aus dem Systems Engineering. Die Übertragung auf einen kleinen Büroauftrag ist eine methodische Empfehlung, keine Pflicht zur Übernahme eines Raumfahrtprozesses.

Der praktische Nutzen liegt in der Frage: Welcher Nachweis entscheidet später, ob die Anforderung erfüllt ist? Wenn darauf keine Antwort existiert, muss vor dem Start eine Entscheidung getroffen werden. Die KI kann diese Frage formulieren, aber sie kennt die Prioritäten und Befugnisse der Organisation nicht automatisch.

Der fiktive Projektauftrag

Der Ausgangstext lautet: "Bis Ende des Quartals führen wir einen KI-Wissensassistenten für den Service ein. Er soll relevante Dokumente nutzen und schnell richtige Antworten liefern. Die Mitarbeitenden werden geschult. Die IT unterstützt. Nach einem erfolgreichen Pilot rollen wir die Lösung aus. Das Budget wird bei Bedarf geklärt."

Der Text enthält eine Richtung, aber keine ausreichende Arbeitsgrundlage. "Ende des Quartals" benötigt einen konkreten Bezug. "Relevante Dokumente" nennt weder Quellen noch Eigentümer. "Schnell" und "richtig" besitzen keine Abnahmekriterien. "Die IT unterstützt" beschreibt keine vereinbarte Kapazität. "Erfolgreich" lässt offen, wer den Pilot beurteilt.

Die Aufgabe an die KI lautet deshalb: "Prüfe diesen Auftrag auf fehlende Entscheidungen. Zitiere die betroffene Passage, beschreibe die Auswirkung und formuliere eine konkrete Entscheidungsfrage. Ergänze keine Termine, Budgets, Zuständigkeiten oder Erfolgskriterien als bereits vereinbart. Kennzeichne Vorschläge ausdrücklich als Vorschläge."

Eine Lückenmatrix statt eines neu erfundenen Auftrags

Die Matrix muss vollständig genug für die Entscheidung sein, aber keine künstliche Sicherheit erzeugen. Eine Zeile mit "IT-Leitung, Freitag" ist falsch, wenn weder Person noch Termin vereinbart sind. Besser steht dort "zuständige Rolle und Termin offen". Die Projektleitung holt diese Angaben ein.

Prüfe zusätzlich, ob der Auftrag widersprüchliche Vorgaben enthält. Ein Pilot mit wenigen Quellen und ein Anspruch auf vollständige Antworten zu allen Servicefragen passen nicht zusammen. Das ist keine Formulierungsfrage. Die verantwortliche Person muss Umfang oder Anspruch verändern.

Fragen so formulieren, dass jemand entscheiden kann

"Bitte Ziel konkretisieren" ist als Arbeitsauftrag zu vage. Eine brauchbare Frage lautet: "Welche drei bis fünf wiederkehrenden Serviceaufgaben umfasst der Pilot, und welche bleiben ausgeschlossen?" Die Antwort legt einen prüfbaren Umfang fest. Die konkrete Anzahl ist hier ein Vorschlag zur Begrenzung, keine allgemeine Regel für Piloten.

Für die Quellen lautet die Frage: "Welche Dokumentgruppen werden aufgenommen, wer bestätigt ihre Gültigkeit und wie werden veraltete Fassungen ausgeschlossen?" Für die Abnahme: "Welche Fehler führen zum Abbruch, welche werden als Nacharbeit erfasst und wer entscheidet über die Freigabe?" Jede Frage muss eine Handlung oder eine Entscheidung vorbereiten.

Wenn eine Entscheidung mehrere Funktionen betrifft, benenne die unterschiedlichen Beiträge. Der Fachbereich beurteilt die Antwortqualität, die IT den technischen Betrieb und die zuständige Datenverantwortung die Zugriffsgrenzen. Eine gemeinsame Besprechung ersetzt nicht die eindeutige Entscheidung darüber, wer den Pilot freigibt.

Ein begrenzter, fiktiver Entscheidungsstand

Angenommen, die Beteiligten bestätigen nach der Prüfung einen Pilot für fünf Servicepersonen und zwei Aufgabenklassen. Es werden nur freigegebene Produktinformationen und aktuelle interne Anleitungen genutzt. Externe Kundenkommunikation und automatische Änderungen bleiben ausserhalb des Piloten. Der Assistent liefert Antworten mit Quellen; eine Person prüft sie vor jeder Weiterverwendung.

Diese Festlegungen sind im Beispiel bewusst als nachträglich getroffene Entscheidungen dargestellt. Sie dürfen nicht schon im ersten KI-Entwurf als vorhandene Vereinbarung erscheinen. In einem echten Projekt müssen Quelle, Datum und bestätigende Rolle jeder Entscheidung dokumentiert sein.

Für die Qualität wird ein Testkatalog mit bekannten Soll-Antworten erstellt. Die Pilotfreigabe verlangt, dass keine gesperrten Testinformationen offengelegt und keine unbelegten verbindlichen Zusagen erzeugt werden. Weitere Qualitätskriterien werden anhand der konkreten Aufgaben festgelegt. Eine willkürliche Prozentzahl ohne Fehlerklassifikation ist kein brauchbarer Ersatz.

Abhängigkeiten als Startbedingungen behandeln

Ein Projekt kann eine klar formulierte Aufgabe besitzen und trotzdem nicht startfähig sein. Wenn die Quellen ungepflegt sind, Testkonten fehlen oder die fachliche Prüfkapazität nicht zugesagt ist, fehlen Voraussetzungen. Erfasse diese Abhängigkeiten getrennt von den gewünschten Funktionen.

Jede Startbedingung erhält einen Nachweis. "Zugriff vorhanden" muss durch einen Test mit der vorgesehenen Rolle bestätigt werden. "Quellen freigegeben" braucht eine erkennbare Fassung und Verantwortlichkeit. "Prüfkapazität eingeplant" braucht eine tatsächliche Zusage, nicht nur eine Zeile im Projektplan.

Der Artikel zu Zugriffsrechten vor dem Wissensassistenten liefert dafür die Rollenprüfung. Die Aktualisierung der Wissensdatenbank behandelt die fachliche Gültigkeit. Beide Prüfungen können offene Startbedingungen ergeben, ohne dass die Projektidee deshalb grundsätzlich falsch ist.

Annahmen sichtbar halten

Nicht jede offene Frage muss einen kleinen Pilot vollständig blockieren. Manche Annahmen lassen sich im Versuch prüfen. Dann muss aber klar sein, welche Entscheidung auf der Annahme beruht und wann sie überprüft wird. Eine Vermutung über die tägliche Fallzahl ist beispielsweise eine Planungsannahme, solange keine Messung vorliegt.

Unterscheide drei Kategorien: bestätigte Entscheidung, prüfbare Annahme und blockierende Lücke. Ein ungeklärter Nutzerkreis ist meist eine blockierende Lücke für Rechte und Testdesign. Eine angenommene Bearbeitungszeit kann als Messhypothese in den Pilot eingehen. Eine dokumentierte Quellenfreigabe ist eine bestätigte Entscheidung.

Die KI darf diese Kategorien nicht vermischen. Formulierungen wie "Wir gehen davon aus" sind nur dann hilfreich, wenn die Annahme einen Verantwortlichen und einen Prüfschritt besitzt. Sonst werden offene Punkte lediglich sprachlich beruhigt. Im Arbeitsblatt muss sichtbar bleiben, welche Konsequenz ein Scheitern der Annahme hat.

Den Auftrag mit einem Gegenfall prüfen

Ein Gegenfall testet, ob die Grenzen verständlich sind. Eine Teilnehmerin fragt den Assistenten nach einem vertraulichen Personaldokument, das nicht zum Pilot gehört. Die erwartete Reaktion ist keine improvisierte Antwort, sondern die Einhaltung der definierten Zugriffssperre. Ein anderer Nutzer verlangt den automatischen Versand einer Antwort. Diese Aktion liegt ausserhalb des vereinbarten Umfangs.

Wenn das Team diese Fälle unterschiedlich beurteilt, ist der Auftrag noch nicht eindeutig genug. Die Grenze muss vor der Umsetzung präzisiert werden. Der Gegenfall ist besonders nützlich, weil positive Beschreibungen oft mehrere Interpretationen zulassen. "Unterstützt den Service" kann sonst vom reinen Entwurf bis zur autonomen Kundenkommunikation alles bedeuten.

Auch ein Liefergegenstand braucht einen Gegenfall. Wenn nur eine Demonstration geliefert wird, erfüllt das keinen Auftrag für einen betreuten Arbeitsablauf mit Pflege und Ausfallregel. Die Betriebsübergabe nach dem Pilot zeigt, welche Fragen bereits vor dem Start in den Auftrag gehören.

Akzeptanzkriterien von Aktivitätslisten unterscheiden

"Workshop durchgeführt", "Tool eingerichtet" und "Dokumentation erstellt" beschreiben Aktivitäten oder Liefergegenstände. Sie belegen nicht automatisch, dass der Arbeitsablauf nutzbar ist. Ein Akzeptanzkriterium muss den erwarteten Zustand zeigen. Für den fiktiven Wissensassistenten ist beispielsweise relevant, ob eine vorgesehene Testrolle eine freigegebene Antwort mit passender Quelle erhält und gesperrte Inhalte nicht sieht.

Die Aktivität kann trotzdem nötig sein. Eine Einweisung bereitet die Anwendung vor, aber ihre Teilnahmebestätigung ersetzt keinen Praxistest. Der Projektauftrag muss deshalb zwischen Durchführung und Wirkung unterscheiden. Wenn nur die Durchführung beauftragt ist, darf die spätere Zusammenfassung keine geprüfte Anwendungskompetenz behaupten.

Auch die Abnahmeverantwortung braucht einen klaren Gegenstand. Die IT kann bestätigen, dass der Dienst erreichbar ist. Der Fachbereich muss beurteilen, ob die Antwort zur Aufgabe passt. Keine der beiden Aussagen allein trägt eine vollständige Betriebsfreigabe. Der Auftrag muss die benötigten Teilnachweise zusammenführen und benennen, wer daraus die Gesamtentscheidung trifft.

Einen begrenzten Start trotz offener Fragen entscheiden

Ein Projekt muss nicht jede künftige Detailfrage vor dem ersten Versuch beantworten. Es muss aber wissen, welche offenen Fragen im Versuch zulässig sind. Ein künstlicher Test ohne echte Daten kann beginnen, während die spätere Datenfreigabe noch geprüft wird. Eine produktive Nutzung mit Kundeninformationen kann sich nicht auf dieselbe Ausnahme berufen.

Dokumentiere einen begrenzten Start deshalb ausdrücklich: erlaubte Daten, erlaubte Nutzer, erlaubte Aktionen und Abbruchkriterien. Im fiktiven Beispiel beginnt zunächst eine Übung mit künstlichen Dokumenten. Sie prüft die Verständlichkeit der Antwortvorlage, nicht die Eignung der echten Wissensbasis. Dieser Nachweis darf später nicht als vollständige Quellen- oder Berechtigungsabnahme verwendet werden.

Die Entscheidungsliste enthält auch den nächsten Übergang. Vor dem Wechsel zu echten freigegebenen Dokumenten müssen Quellenstand und Zugriffe geprüft sein. Vor einer externen Kommunikation kommt eine weitere Freigabe hinzu. So entsteht ein schrittweiser Aufbau, dessen Grenzen jederzeit sichtbar bleiben.

Wenn die KI einen Projektplan erstellt, muss sie diese Übergänge erhalten. Ein automatisch vorgeschlagener Zeitplan darf blockierende Voraussetzungen nicht in gewöhnliche Aufgaben ohne Konsequenz verwandeln. Die Projektleitung prüft deshalb besonders die Stellen, an denen aus einem Versuch ein produktiver Ablauf wird. Dort ändern sich häufig Datenumfang, Verantwortlichkeit und Fehlerfolgen zugleich.

Was nach der Prüfung vorliegen muss

Das Ergebnis ist ein überarbeiteter Auftrag mit nachvollziehbarer Entscheidungsliste. Offene Punkte bleiben als solche sichtbar. Jeder Liefergegenstand besitzt einen Abnahmenachweis. Die Rollen sind bestätigt, und die Grenzen des Piloten sind verständlich. Ein hübsch formulierter Text ohne diese Ergänzungen ist nur ein redaktioneller Entwurf.

Prüfe die Vollständigkeit gegen die ursprünglichen Aussagen. Keine wichtige Einschränkung darf beim Umschreiben verschwinden. Wenn Budget oder Termin noch offen sind, darf die Zusammenfassung sie nicht als geklärt darstellen. Bewahre den Ausgangstext und die Entscheidungsliste auf, damit spätere Änderungen erkennbar bleiben.

Für laufende Steuerung ergänzt der Beitrag zu KI im Projektmanagement die Perspektive. Für neue Wünsche nach einer Freigabe nutze das Änderungsregister mit KI. Ein klarer Projektauftrag verhindert Änderungen nicht, macht ihre Folgen aber sichtbar.

Quellenstand: 22.10.2026. Die NASA-Checkliste begründet die Anforderungen an eindeutige und prüfbare Aussagen. Auftrag, Lückenmatrix und Pilotentscheidungen sind eigene fiktive Beispiele. Sie belegen keine Zustimmung realer Beteiligter und keine vertragliche Auslegung.