„Wir wollen etwas mit KI machen“ ist kein Briefing, sondern ein Symptom. Projekte, die bei einer Technologie starten („wir brauchen einen Chatbot“, „lasst uns ein Modell fine-tunen“), verbrennen regelmäßig das Budget eines Quartals, bevor irgendjemand sagen kann, welche Geschäftszahl sich bewegen soll. Ein gutes KI-Briefing passt auf eine Seite und ist absichtlich unbequem auszufüllen: Es erzwingt das Geschäftsproblem vor jeder Technologie, verlangt genau eine messbare Erfolgsgröße und macht Datenlage und Veto-Berechtigte explizit. Dieser Artikel liefert diese einseitige Struktur, ein ausgefülltes Beispiel und die Fehler, die Briefings leise scheitern lassen.
Warum die meisten KI-Briefings Nicht-Antworten produzieren
Das typische KI-Briefing scheitert auf eine von wenigen wiederkehrenden Arten, und jede erzeugt dasselbe Symptom: ein Team, das selbstbewusst auf ein Ziel zubaut, auf das sich niemand geeinigt hat.
| Briefing-Fehler | Wie er klingt | Was er verursacht |
|---|---|---|
| Technologie-zuerst-Framing | „Wir brauchen einen RAG-Chatbot für den Support“ | Das eigentliche Problem (langsame Antworten? falsche Antworten? Kosten?) wird nie benannt oder gemessen |
| Keine Metrik | „Effizienz mit KI steigern“ | Erfolg ist undefinierbar, also kann das Projekt weder gelingen noch gestoppt werden |
| Daten-Optimismus | „Wir haben massenhaft Daten“ | Monat drei: Die Daten sind verstreut, unlabeled oder DSGVO-beschränkt |
| Unsichtbare Rahmenbedingungen | Latenz-, Budget- oder Compliance-Grenzen tauchen erst im Review auf | Eine technisch funktionierende Lösung, die nie live gehen darf |
| Fehlende Veto-Instanz | Recht, Betriebsrat oder Security sehen das Projekt erst beim Rollout | Blockade in letzter Minute, nachdem der teure Teil erledigt ist |
Das einseitige Briefing: sieben Felder
Das ist das ganze Dokument. Jedes Feld hat eine erzwingende Frage; lässt sich ein Feld nicht ehrlich ausfüllen, ist genau diese Lücke das erste Arbeitspaket des Projekts, noch bevor irgendein Modell angefasst wird.
- 1Geschäftsproblem (2-3 Sätze, ohne Technologie-Vokabular): Was tut heute weh, wer spürt es, was kostet es. Test: „KI“ streichen, der Absatz muss weiterhin Sinn ergeben.
- 2Erfolgsmetrik (1 Zeile): die eine Zahl, die sich bewegen soll, ihr Ist-Wert, ihr Zielwert und bis wann. Beispiel: „Erstantwortzeit von 8h auf unter 1h bis Q3.“
- 3Datenlage: welche Daten die Lösung braucht, wo sie liegen, wem sie gehören, ob sie gelabelt sind und auf welcher Rechtsgrundlage sie genutzt werden. Unbekanntes wird als unbekannt notiert.
- 4Rahmenbedingungen: harte Grenzen bei Latenz, Kosten pro Transaktion, Hosting/Datenresidenz, Erklärbarkeit und Compliance, jeweils mit Quelle (Regulierung, Vertrag, Policy).
- 5Stakeholder: wer sponsert (zahlt), wer den Output täglich nutzt, wer das System nach dem Launch betreibt und wer ein Veto hat, jeweils als Person benannt, nicht als Abteilung.
- 6Scope und explizite Nicht-Ziele: was die erste auslieferbare Version abdeckt, und zwei bis drei Dinge, die sie bewusst nicht tut.
- 7Timebox und Budgetrahmen: wie viel Zeit und Geld den ersten Go/No-Go-Entscheidungspunkt kauft, nicht das ganze Projekt.
Die zwei Felder, die die eigentliche Arbeit leisten: Problem und Metrik
Problembeschreibung und Erfolgsmetrik tragen das ganze Briefing, und genau dort versteckt sich vage Sprache. Das Umschreibe-Muster ist immer gleich: von Aktivität zu Ergebnis, von Adjektiv zu Zahl.
| Vage Version | Version mit echter Antwort |
|---|---|
| „Mit KI den Kundensupport verbessern“ | „Support-Antworten dauern im Schnitt 8h; 30% der Tickets sind Wiederholungsfragen, die unsere Doku bereits beantwortet“ |
| „Effizienz in der Auftragsbearbeitung steigern“ | „Manuelle Auftragsprüfungen kosten 4 FTE; fehlerbedingte Nacharbeit betrifft 6% der Aufträge“ |
| „Erfolg: Der Chatbot funktioniert gut“ | „Erfolg: 25% der Tier-1-Tickets abgefangen bei CSAT >= heutiger Baseline, gemessen über 4 Wochen“ |
| „Erfolg: Das Modell ist genau“ | „Erfolg: Prognosefehler (MAPE) sinkt von 22% auf unter 12% auf einem zurückgehaltenen Quartal“ |
Datenlage, Rahmenbedingungen, Stakeholder: die unglamourösen Felder, die über Machbarkeit entscheiden
In diesen drei Feldern werden Projekte tatsächlich gewonnen oder verloren, und für jedes lohnt sich eine Checkliste, bevor das Briefing als fertig gilt.
- 1Datenzugriffs-Test: Kann jemand diese Woche eine echte Stichprobe ziehen? Braucht der Zugriff eine zweimonatige Integration oder eine Rechtsprüfung, ist genau das der wahre kritische Pfad des Projekts.
- 2Label-Check: Braucht der Use Case gelabelte Beispiele, wer labelt dann, in welcher Qualität, zu welchen Kosten? „Wir labeln nebenbei“ ist ein Warnsignal, kein Plan.
- 3Quellen der Rahmenbedingungen: Zu jeder Grenze notieren, woher sie stammt. Grenzen ohne Quelle sind oft Präferenzen und verhandelbar; echte (DSGVO, Branchenregulierung, vertragliche SLAs) nicht.
- 4Veto-Runde: Den One-Pager vor dem Kickoff Recht/Compliance, Security und, wo relevant, dem Betriebsrat zeigen. 30 Minuten Lektüre jetzt schlagen eine Launch-Blockade später.
- 5Betreiber-Frage: Benennen, wer das System zwölf Monate nach Launch verantwortet. Lautet die Antwort „das Projektteam“, gibt es noch keine Antwort.
Ein ausgefülltes Miniaturbeispiel
Ein illustrativer One-Pager für ein fiktives mittelständisches E-Commerce-Unternehmen, verdichtet. Beachten Sie, was er nicht enthält: keine Modellnamen, keine Framework-Entscheidungen, die kommen später und leiten sich aus diesem Dokument ab.
| Feld | Inhalt (verdichtet) |
|---|---|
| Geschäftsproblem | Retourengründe sind Freitext; die Kategorisierung für den Einkauf bindet 2 FTE und hinkt 6 Wochen hinterher, Sortimentsentscheidungen laufen also auf veralteten Daten |
| Erfolgsmetrik | Kategorisierungs-Verzug von 6 Wochen auf unter 1 Tag; für den Einkauf nutzbare Kategorie-Genauigkeit >= 90% gegenüber menschlicher Baseline |
| Datenlage | Rund 1,8 Mio. historische Retouren-Kommentare in der Shop-DB (fiktive Zahl), unlabeled; 10.000 menschlich kategorisierte Zeilen aus einem Audit von 2024; personenbezogene Daten müssen maskiert werden |
| Rahmenbedingungen | Nur EU-Hosting (Unternehmens-Policy); Kosten unter 0,02 EUR pro klassifizierter Retoure (Margenrechnung); kein kundensichtbarer Output in v1 |
| Stakeholder | Sponsorin: Leiterin Einkauf; Nutzer:innen: 4 Category Manager; Betrieb: Data-Team-Lead; Veto: DSB und Betriebsrat |
| Nicht-Ziele | Keine automatisierten Erstattungsentscheidungen; keine Lieferanten-Reports in v1 |
| Timebox | 6 Wochen und ein fixes Pilotbudget bis zum Go/No-Go mit gemessener Genauigkeit auf Live-Daten |
Typische Fehler, die Briefings leise scheitern lassen
- 1Das Briefing erst nach der Anbieter- oder Modellwahl schreiben, dann wird das Dokument zur Rechtfertigung statt zum Entscheidungswerkzeug.
- 2Eine Metrik ohne Ist-Wert durchgehen lassen: Ein Ziel ohne Baseline kann nicht scheitern, und deshalb auch nicht gelingen.
- 3„Datenlage: gut“ akzeptieren, ohne dass jemand eine Stichprobe gezogen hat; Optimismus über Daten ist der teuerste Optimismus in KI-Projekten.
- 4Das Stakeholder-Feld mit Abteilungen statt Namen füllen; Abteilungen sitzen nicht in Workshops und geben keine Launches frei, Menschen tun das.
- 5Das Briefing als Einmal-Artefakt behandeln: Es sollte an jedem Phasen-Gate erneut geprüft und aktualisiert werden, wenn die Realität davon abweicht.
