Wie du ein KI-Automatisierungsprojekt zuschneidest, damit es dich nicht auffrisst

"Kannst du was bauen, das die hier liest und ins System einträgt?"

Das ist der ganze Auftrag. So sieht ein KI-Automatisierungsprojekt meistens aus, wenn es ankommt. Neun Wörter, eine Geste Richtung Ordner, und die Erwartung, dass du bis Freitag eine Zahl nennst.

Diese neun Wörter verbergen rund sechs verschiedene Fragen, und jede davon ist eine Stelle, an der das Projekt still 40 Stunden überzieht. Nicht weil der KI-Teil schwer wäre. Der KI-Teil ist meistens die einfachste Woche des Ganzen. Es überzieht, weil niemand aufgeschrieben hat, was "liest die hier" bedeutet, wem die Daten gehören, was passiert, wenn es falsch liegt, und wer den Kopf hinhält, wenn das Modell, auf dem es läuft, in elf Monaten abgeschaltet wird.

Ich verkaufe diese Arbeit. Ich betreibe eine Ein-Personen-Agentur in Augsburg und baue Claude-Code-Skills und Automatisierungen für Kunden, überwiegend in den USA. Das ist also keine Warnung von der Seitenlinie. Es ist die Liste der Dinge, die ich inzwischen schriftlich festhalte, bevor ich ein Angebot mache, denn sie wegzulassen ist der Weg, ein Discovery-Projekt kostenlos zu machen und die Deadline eines Build-Projekts dranzuhängen.

Lieber zum Ausdrucken? Lade das komplette Scoping-Arbeitsblatt als PDF — 9 Seiten, der vollständige Sechs-Fragen-Katalog, ohne Login.

Die Fehlerquoten-Zahlen, die dir zitiert werden

Irgendwer im Verkaufsgespräch wird dir eine Statistik zitieren. Meistens "95% der KI-Projekte scheitern". Bevor du sie wiederholst oder in Panik gerätst, schau nach, woher sie kommt.

Die 95% stammen aus The GenAI Divide: State of AI in Business 2025 der NANDA-Initiative des MIT. Es ist keine begutachtete MIT-Studie, und sie sagt nicht, dass 95% der KI-Projekte scheitern. Sie sagt, dass 95% der betrachteten Pilotprojekte innerhalb von rund sechs Monaten keine messbare Wirkung auf die Gewinn- und Verlustrechnung gezeigt haben. Die Belegbasis sind 52 Führungskräfteinterviews, eine Befragung von rund 150 Verantwortlichen und eine Sichtung von etwa 300 öffentlichen Einsätzen, und der Bericht selbst nennt seine Interviewbefunde richtungsweisend statt aus Unternehmensberichten gezogen. Kostenersparnis, Durchlaufzeit, Abwanderung: nichts davon zählte. Die ehrliche Version lautet, dass in einer kleinen Menge selbstberichteter Interviews die meisten Piloten in sechs Monaten die GuV nicht bewegt hatten. Weniger dramatisch. Auch wahr.

Die Zahl, die ich tatsächlich nutzen würde, kommt von 451 Research von S&P Global Market Intelligence, deren Voice-of-the-Enterprise-AI-Befragung über 1.000 Organisationen in Nordamerika und Europa abdeckt: Der Anteil der Unternehmen, die die meisten ihrer KI-Initiativen aufgeben, ist im Jahresvergleich von 17% auf 42% gestiegen, und die durchschnittliche Organisation hat 46% ihrer Proof-of-Concepts vor der Produktion verworfen. Auch selbstberichtet, aber tausend Unternehmen schlagen 52 Interviews, und Aufgeben ist etwas, das Leute über sich selbst korrekt beantworten können.

Dann Gartner, das am 25. Juni 2025 prognostiziert hat, dass bis Ende 2027 über 40% der agentischen KI-Projekte wegen eskalierender Kosten, unklarem Geschäftsnutzen und unzureichenden Risikokontrollen abgebrochen werden. Achte auf die Zeitform: Das ist eine Prognose, keine Messung, und wer sie als beobachtete Fehlerquote zitiert, zitiert sie falsch. Nützlich sind die drei Ursachen, die sie benennt. Kosten, Unklarheit und Risiko. Nicht, dass die Technik nicht funktioniert. Alle drei sind Scoping-Probleme.

Niemand hat vereinbart, was "funktioniert" heißt

Eine Automatisierung, die in 80% der Fälle richtig liegt, ist je nach Aufgabe entweder ein Triumph oder ein Totalausfall, und niemand entscheidet vorher, welches von beiden. So kommt es, dass ihr bei der Demo feststellt, dass du und der Kunde die ganze Zeit verschiedene Projekte im Kopf hattet.

Eingehende E-Mails mit 80% in drei Kategorien sortieren? Wirklich in Ordnung. Eine Nachricht landet im falschen Ordner, jemand verschiebt sie, das Leben geht weiter. Zahlungsbeträge aus Rechnungen mit 80% extrahieren? Das ist jede fünfte Zahl falsch, in der Buchhaltung, und das ist schlechter als nutzlos: Jetzt muss jemand alle prüfen, und genau diese Arbeit solltest du beseitigen.

Der Scope braucht also ein Abnahmekriterium, in Zahlen, vor dem Bauen vereinbart. Etwa so: Gemessen an einer Stichprobe von 200 echten Dokumenten, die der Kunde liefert, extrahiert das System die sechs benannten Felder in mindestens 95% der Fälle korrekt und markiert statt zu raten, wenn die Konfidenz niedrig ist. Drei Dinge leisten dort die Arbeit. Die Stichprobe sind echte Kundendaten, keine von dir ausgesuchten Beispiele. Die Felder sind benannt, sodass "es sollte auch die Bestellnummer erwischen" eine Änderungsanforderung ist und keine Annahme. Und die Markierungsklausel macht ein ehrliches "ich weiß es nicht" zu korrektem Verhalten statt zu einem Fehler.

Schreib auch die Zählmethode auf, denn "95% genau" ohne Nenner ist ein Streit, der nur darauf wartet: ein falsches Feld von sechs, ist das Dokument dann 0% oder 83%?

Und sei deutlich, in welcher Kategorie die Aufgabe liegt. Wenn in 5% der Fälle falsch zu liegen sowohl inakzeptabel als auch unentdeckbar ist, sag das im Gespräch, denn manchmal ist die richtige Antwort, dass das gar nicht vollständig automatisiert werden sollte. Die Hälfte meines ehrlichen Flussdiagramms, ob du einen KI-Berater brauchst, ist eigentlich diese Frage in Verkleidung.

Die Daten sind immer schlechter, als der Kunde gesagt hat

Immer. Nicht meistens. Ich habe kein einziges Mal die Daten eines Kunden geöffnet und gedacht "oh, das ist sauberer als beschrieben".

Was man dir sagt: "Das ist alles im CRM, ziemlich standardisiert." Was da ist: Exporte aus zwei CRMs, weil sie 2023 migriert und nie fertig geworden sind, eine Tabelle, die die Büroleiterin privat führt, weil sie dem CRM nicht traut, Datumsangaben in drei Formaten, Firmennamen mit und ohne GmbH, gescannte PDFs, die Fotos von Papier sind, und 200 Datensätze, in denen jemand die Telefonnummer ins Notizfeld geschrieben hat.

Das heißt nicht, dass der Kunde lügt. Niemand hat seine Daten seit Jahren am Stück angeschaut, und die Person, die sie dir beschreibt, beschreibt den ordentlichen Teil, den sie anfasst.

Die Lösung ist kein größerer Puffer in deiner Schätzung. Es ist eine separate, bezahlte, festgeschriebene Discovery-Phase vor dem Angebot für den Bau. Ein bis zwei Wochen: Du bekommst einen echten Export, profilierst ihn und lieferst ein kurzes Dokument, das sagt, was drin ist, welcher Anteil so nutzbar ist, was Aufräumen kosten würde und welche realistische Genauigkeitsobergrenze auf diesem Input gilt. Der Kunde bezahlt dafür und besitzt das Ergebnis. Wenn er danach geht, hat er Wert bekommen und du wurdest bezahlt.

Zwei Klauseln gehören dazu. Das Angebot für den Bau gilt nur gegen den in der Discovery profilierten Datensatz, präzise genug beschrieben, um ihn zu identifizieren. Und Datenbereinigung ist ausgeschlossen, sofern nicht separat angeboten. Sonst absorbierst du die Bereinigung, still, um Mitternacht, kostenlos.

"Häng es einfach an unser System"

"Einfach" trägt in diesem Satz eine tragende Last. Andere Formulierungen dieser Art habe ich in einer Liste von Kundensätzen gesammelt, die bedeuten, dass Scope Creep schon begonnen hat, und dieser gehört ganz nach oben.

Was sich "ihr System" als herausstellt, grob nach Häufigkeit: ein SaaS-Produkt mit dokumentierter API, was der gute Fall ist. Eines, dessen API hinter einem Partnerprogramm oder einer Preisstufe liegt, die der Kunde nicht hat. Eine API mit undokumentierten Ratenbegrenzungen, die du im Produktivbetrieb entdeckst. Ein On-Premise-System, dessen Anbieter vierstellig für eine Integrationsberatung nimmt. Ein System ohne API, bei dem die echte Antwort ein nächtlicher CSV-Abwurf ist. Und die, die wehtut: eine API, die existiert, hinter einer IT-Abteilung, die sechs Wochen und eine Sicherheitsprüfung braucht, um Zugangsdaten auszugeben.

Die letzte ist überhaupt nicht technisch, und sie sprengt mehr Liefertermine als alles andere auf der Liste. Mit besserem Code kannst du das nicht beheben.

Benenne die Integrationsfläche also ausdrücklich. Nicht "Integration mit dem CRM des Kunden", sondern: Integration mit HubSpot über die v3-CRM-API, mit Zugangsdaten, die der Kunde bis zu einem benannten Datum bereitstellt, für diese benannten Objekte und diese Operationen. Ergänze eine Klausel, die Zugangsdaten, Lizenzstufen und Gebühren Dritter zur Verantwortung des Kunden macht, wobei sich der Zeitplan Tag für Tag verschiebt, wenn der Zugang zu spät kommt. Nicht als Strafe. Als das, was verhindert, dass du eine Verzögerung ausbadest, gegen die du machtlos warst. Und schreib auf, was passiert, wenn sich die Integration als unmöglich herausstellt, denn Discovery ist die Phase, in der ein neuer Zuschnitt noch billig sein sollte.

Jeder Sonderfall kommt als "das sollte es natürlich auch können"

Das Wort "natürlich" ist das Erkennungszeichen. Der Kunde hält diesen Fall für so normal, dass es ihm nie in den Sinn kam, ihn zu erwähnen, und deswegen hat er auch ehrlich das Gefühl, nichts Neues zu verlangen.

Rechnungen in mehreren Währungen. Dokumente in einer zweiten Sprache. Der Lieferant, der alles als Handyfoto schickt. Gutschriften, die aussehen wie Rechnungen mit umgedrehtem Vorzeichen. Der Quartalsstapel, der als ein 400-seitiges PDF statt als 400 Dateien kommt. Jedes davon ist ein echter Arbeitstag, manchmal drei, und jedes kommt als Fehler gerahmt statt als Funktion.

Du kannst nicht jeden Sonderfall vorab aufzählen, und das ist auch nicht das Ziel. Das Ziel ist eine Grenze, sodass alles außerhalb sichtbar außerhalb ist. Das heißt, dein Scope beschreibt das Eingabeuniversum statt der Ausgabe: einseitige, digital erzeugte PDFs, auf Deutsch oder Englisch, von der in der Discovery bereitgestellten Lieferantenliste, eine Rechnung pro Datei. Alles, was nicht passt, geht in die Ausnahmeschlange statt verarbeitet zu werden.

Diese letzte Klausel verändert das Gespräch. Ein nicht behandelter Sonderfall ist kein Fehler mehr, sondern das System, das sich wie spezifiziert verhält, und die Abdeckung zu erweitern wird zu einer bepreisten Änderungsanforderung gegen eine schriftliche Basis. Ich war schon auf der falschen Seite einer Nachverhandlung nach der Lieferung, und die Klausel, die mich gerettet hat, funktionierte genau deswegen, weil sie konkret genug war, um langweilig zu sein.

Und plan eine Sonderfall-Reserve in den Bau ein: eine feste Anzahl Tage für Fälle, die im Pilot auftauchen, eingepreist. Wenn diese Tage aufgebraucht sind, sind weitere Fälle Änderungsanforderungen. Der Kunde sieht eine echte Zahl, und niemand fühlt sich überfallen.

Die menschliche Prüfung ist die Lieferleistung, nicht der Notnagel

Und hier ist das, was Leute überrascht, die noch keine davon ausgeliefert haben: Die Gestaltung des Human-in-the-Loop ist meistens der größte Teil der tatsächlichen Arbeit.

Die Extraktion ist ein Prompt und etwas Verrohrung. Der Rest ist: wie ein Ergebnis mit niedriger Konfidenz sichtbar wird, wer es sieht, in welcher Oberfläche, wie er es korrigiert, wie die Korrektur zurück ins führende System kommt, wer benachrichtigt wird, wenn sich die Schlange staut, und was passiert, wenn der Prüfer im Urlaub ist.

Jedes davon ist eine Designentscheidung mit einer Abhängigkeit auf Kundenseite. Lass sie aus dem Scope, und du baust sie trotzdem, in den letzten zwei Wochen, unbezahlt, denn ohne sie funktioniert die Automatisierung nicht.

Der Prüf-Workflow gehört also als eigener Posten mit eigenem Preis in die Lieferliste. Benenne die Oberfläche, ob das ein Slack-Freigabeablauf, ein Adminbildschirm oder eine E-Mail-Zusammenfassung ist. Benenne die prüfende Rolle, und lass den Kunden die tatsächliche Person benennen. Definiere, was "erledigt" heißt und was passiert, wenn es das nicht ist.

Und sag laut, was das mit der Personalstärke macht, denn die meisten Kunden erwarten immer noch, dass sie auf null geht. Realistisch verschiebst du jemanden davon, alles zu machen, dahin, die 10% zu prüfen, die das System markiert hat. Das ist ein echter Effizienzgewinn, für den es sich zu zahlen lohnt. Es ist nur nicht die Demo, die sie gesehen haben, und was passiert, nachdem ein CEO eine KI-Demo gesehen hat, ist dieselbe Lücke vom anderen Ende her.

Der Wartungsschwanz, den niemand einpreist

Eine Automatisierung ist keine Website. Eine Website baust du, übergibst sie, und sie rendert weiter. Eine Automatisierung sitzt auf Infrastruktur, die sich unter ihr verändert, ob jemand den Code anfasst oder nicht.

Anthropic sagt mindestens 60 Tage Vorlauf zu, bevor ein öffentlich veröffentlichtes Modell abgeschaltet wird, und das ist das gute Ende der Branche. Sechzig Tage sind höflich und zugleich nicht sehr lang, wenn der Kunde ein Änderungsfenster planen, die Genauigkeit gegen seine Abnahmekriterien neu prüfen und eine Freigabe einholen muss. Modelle werden auf echten Zeitplänen abgeschaltet, und 2026 hat schon mehrere weit verbreitete aus der API genommen. Wenn deine Automatisierung ein Modell festnagelt, gehört jemandem die Neuvalidierung, wenn dieses Modell verschwindet.

Das ist einer von vier beweglichen Teilen. Tokenpreise ändern sich. Ratenbegrenzungen und API-Bedingungen ändern sich. Und der Prozess des Kunden ändert sich, und das ist der heimtückischste: Sie ergänzen ein Feld in einem Formular, oder ein neuer Lieferant kommt mit einem anderen Format dazu, und die Automatisierung fängt an, still falsch zu liegen, auf eine Art, die einen Monat lang niemand bemerkt.

Prompt-Drift ist ebenfalls real und weniger mystisch, als es klingt. Der Prompt verfällt nicht; die Eingaben verschieben sich oder das Modell darunter ändert sich, und derselbe Prompt produziert auf denselben Daten andere Ausgaben. Deswegen ist das Genauigkeitskriterium, das du am Anfang verhandelt hast, auch dein Wartungswerkzeug. Lass dieselbe 200-Dokumente-Stichprobe quartalsweise laufen, und du hast eine Zahl statt eines Gefühls.

Der Scope endet also mit einer ausdrücklichen Antwort auf "wem gehört das an Tag 91". Entweder ein Retainer, der Modellwechsel, Überwachung, eine vierteljährliche Genauigkeitsprüfung und eine bestimmte Zahl Supportstunden abdeckt, oder eine saubere Übergabe, bei der der Kunde die Verantwortung übernimmt und du genau dokumentierst, was er übernommen hat. Das Zweite ist legitim. Es muss nur aufgeschrieben sein, so wie eine Checkliste zur Website-Übergabe, sonst wird "wir dachten, du kümmerst dich darum" das Thema von Monat vier.

Warum Festpreis auf einem undefinierten Datensatz dich Geld kostet

Festpreis ist nicht der Feind. Festpreis auf etwas, das du nicht gemessen hast, schon.

Dein Aufwand bei diesen Projekten skaliert mit der Unordnung von Daten, die du noch nicht gesehen hast, und Unordnung hat einen langen Ausläufer. Deine Schätzung basiert auf den sauberen Beispielen, die der Kunde geschickt hat, denn auf die war er stolz. Deine Lieferung geht gegen alles. Dort einen Festpreis zu nennen ist kein Selbstvertrauen, es ist, dem Kunden eine kostenlose Option auf deine Zeit zu schreiben.

Drei Strukturen, die in einem Angebot tatsächlich funktionieren.

Erst Discovery, dann Festpreis. Phase eins ist eine bezahlte Discovery zum Festpreis über ein bis zwei Wochen mit dokumentiertem Ergebnis. Phase zwei ist ein danach kalkulierter Festpreis-Bau, gültig gegen die in Phase eins profilierten Daten. Der Kunde bekommt seine Kostensicherheit, einen Schritt später als gewünscht. Das ist mein Standard, und es verkauft sich leicht, weil Phase eins klein genug ist, um sie ohne Gremium freizugeben.

Phasenweise Lieferung mit echtem Go/No-Go. Pilotier einen Dokumenttyp zum Festpreis, gemessen am Genauigkeitskriterium, dann eine separate bepreiste Phase zur Erweiterung der Abdeckung. Schreib ins Angebot, dass der Kunde nach dem Piloten aufhören kann. Das liest sich als Selbstvertrauen und nimmt den Druck, alles in Phase eins zu stopfen.

Aufwand nach Zeit mit Deckel und Zwischenprüfung. Für wirklich explorative Arbeit: stundenweise, mit einer Obergrenze und einer verpflichtenden Prüfung bei 50% des Budgets, an der beide Seiten aussteigen können. Schwerer an jemanden zu verkaufen, der eine Zahl will. Der ehrliche Satz lautet, dass die gewünschte Zahl Wissen voraussetzt, das keiner von euch beiden hat, ihr könnt es also entweder in einer kleinen bezahlten Phase herausfinden oder die Unsicherheit in einen größeren Festpreis einpreisen. Die meisten wählen die kleine Phase.

Was ich komplett meiden würde: Festpreis für "automatisiert unsere Rechnungsverarbeitung", ohne Genauigkeitskriterium, ohne Datenprofil und ohne benannte Integration. Das ist kein Scope, das ist ein Ergebnis, und Ergebnisse haben keine Grenze. Sei auch misstrauisch gegenüber einer Automatisierung, die so dünn ist, dass sie eigentlich ein geplantes Skript mit einem Modellaufruf darin ist, denn die werden zu Automatisierungspreisen verkauft und als teure Cronjobs geliefert.

Was ich inzwischen tatsächlich mache

Das Scoping von KI-Automatisierungsprojekten läuft bei mir inzwischen auf sechs Fragen hinaus, schriftlich beantwortet, bevor es einen Baupreis gibt: was als funktionierend gilt und wie es gemessen wird, welche Daten von wem profiliert wurden, woran genau es angebunden wird und wer den Zugang liefert, was innerhalb der Eingabegrenze liegt und was in die Ausnahmeschlange geht, wer die Ausgabe prüft und wo, und wem es nach der Übergabe gehört.

Das ist nicht clever. Es ist nur so, dass jede davon, unbeantwortet, zwischen einer Woche und der gesamten Marge wert ist.

Ich tue nicht so, als würden Projekte dadurch nach Plan laufen. Ich werde weiterhin überrascht, und die letzten Überraschungen sind der Grund, warum es manche dieser Klauseln gibt, was eine andere Art ist zu sagen, dass ich für sie bezahlt habe. Was die sechs Fragen ändern, ist die Art der Überraschung: von etwas, das du absorbierst, zu etwas, das du neu zuschneidest.

Wenn du ein KI-Automatisierungsprojekt abwägst und eine zweite Meinung zum Scope willst, bevor du unterschreibst, oder wenn du die Discovery lieber ordentlich machst als zu raten: Das ist die Art Sache, die ich mache. Kein Versprechen, dass deine Daten überdurchschnittlich sind. Sind sie nicht.