Die meisten KI-Projekte, die wir bauen sollen, beginnen an der falschen Stelle. Jemand hat eine Demo gesehen oder eine Anbieterpräsentation über sich ergehen lassen und kommt ins erste Gespräch mit einer bereits ausgewählten Lösung: ein Chatbot oder ein Copilot für einen Prozess, den nie jemand aufgeschrieben hat. Dann fragen wir, was tatsächlich wehtut. Die Antwort ist fast nie das, worum gebeten wurde. Es sind die Rechnungen, die sich in einem gemeinsamen Postfach stapeln. Es sind die Leads, die zwei Tage unangetastet liegen, weil das Routing im Kopf einer einzigen Person lebt.
Dieser Beitrag beschreibt die Reihenfolge, die wir mit diesen Kunden durchgehen. Nichts daran ist originell. Sie funktioniert trotzdem – und das ist mehr, als wir über die meisten KI-Initiativen sagen können, die uns präsentiert werden.
Beginnen Sie mit einem Workflow, nicht mit einem Modell
Die richtige Einheit für ein erstes KI-Projekt ist ein Workflow: ein wiederholbarer Prozess mit klarem Anfang, klarem Ende und mindestens einer Person, die ihn hasst. Keine Abteilung. Nicht „Kundenservice". Eine konkrete, benennbare Sache – etwa die Vorsortierung von Lieferantenrechnungen oder das Routing eingehender Leads.
Die Modellauswahl ist ein Detail, das Sie in Woche drei klären. Wir haben an anderer Stelle argumentiert, dass sich die interessante Frage von den Modellen zu den Systemen um sie herum verlagert hat; die Käuferversion dieses Arguments ist einfacher. Claude und GPT-5.5 sind beide gut genug, um Felder aus einer Rechnung zu extrahieren. Keines von beiden sagt Ihnen, welcher Workflow Stunden verliert.
Ein guter erster Workflow hat vier Eigenschaften: Er läuft häufig (täglich oder wöchentlich, nicht quartalsweise), die Schritte lassen sich aufschreiben, ein Mensch prüft bereits das Ergebnis, und ein gelegentlicher Fehler ist ärgerlich statt katastrophal. Rechnungsvorsortierung erfüllt alle vier. Die Gehaltsabrechnung scheitert am letzten Punkt. Diese letzte Eigenschaft ist wichtiger, als die meisten erwarten – wir kommen darauf zurück.
Wenn niemand im Unternehmen den Workflow Schritt für Schritt beschreiben kann, ist das das eigentliche erste Problem – und kein Modell wird es lösen. Sie würden sich wundern, wie oft die Discovery-Woche mit einem Prozessdokument als wertvollstem Ergebnis endet.
Die 80-%-Faustregel: Automatisieren Sie den langweiligen Teil
Die 80/20-Aufteilung ist eine Arbeitsheuristik aus unseren eigenen Projekten, kein Naturgesetz. Über die Workflows hinweg, die wir automatisiert haben, sehen die langweiligen 80 % immer gleich aus: das Ding abholen, lesen, klassifizieren, die Felder extrahieren, weiterleiten, die Antwort entwerfen. In den harten 20 % steckt das Urteilsvermögen: der verärgerte Kunde, die Rechnung, zu der es keine Bestellung gibt, die Erstattungsanfrage, die die Richtlinien dehnt, der Anruf, für den jemand bezahlt wird.
Das Playbook lautet: Automatisieren Sie den langweiligen Teil und geben Sie die Ermessensfälle in einer sauberen Review-Queue an einen Menschen zurück. Hier verdienen wir uns als Agentur für KI-Automatisierung auch unser Geld: zu wissen, welche Teile ein Modell sein sollten und welche fünfzig Zeilen deterministischer Code. Lässt sich eine Regel aufschreiben, schreiben wir sie auf. „Jede Rechnung über 10.000 € braucht eine zweite Freigabe" ist ein if-Statement, kein Prompt. Modelle kommen dorthin, wo der Input auf Weisen variiert, die Regeln nicht erfassen: eine Freitext-E-Mail lesen, Positionen aus einem PDF-Layout extrahieren, das wir nie gesehen haben, beurteilen, ob ein Lead nach Klinikum oder nach Hobbybastler klingt.
Ein paar Beispiele aus echten Projekten – anonymisiert, aber mit ehrlichen Spannen.
Rechnungsvorsortierung
Ein Kunde im Bereich um die 50 Mitarbeiter hatte zwei Personen, die zusammen 15 bis 20 Stunden pro Woche damit verbrachten, Rechnungen zu öffnen, sie Bestellungen zuzuordnen, Summen ins Buchhaltungssystem zu tippen und Abweichungen per E-Mail hinterherzulaufen. Über die Rechnungsprojekte hinweg, die wir seit 2023 betreut haben, lag diese manuelle Last je nach Volumen zwischen 10 und 25 Stunden pro Woche.
Die automatisierte Version: Rechnungen kommen per E-Mail oder Scan an, OCR plus ein vision-fähiges Modell extrahiert die Felder, deterministischer Code gleicht gegen Bestellungen ab, und alles oberhalb eines Schwellenwerts oder unterhalb eines Konfidenzscores landet in einer Review-Queue. Die Menschen verbringen jetzt 1 bis 3 Stunden pro Woche mit Ausnahmen. Das Modell berührt nie eine Zahlung – es bereitet vor, ein Mensch genehmigt.
Lead-Routing
Eingehende Leads kamen über ein Website-Formular, ein generisches Postfach, Partnerempfehlungen und die gelegentliche Messe-Tabelle herein. Das Routing hing von einer Senior-Person, die alles las und weiterleitete – was bedeutete, dass Leads zwischen 4 Stunden und 2 Tagen warteten, wenn diese Person ausgelastet oder im Urlaub war.
Jetzt liest ein Modell jede Anfrage, klassifiziert sie nach Produktbereich und Dringlichkeit, reichert sie mit öffentlichen Unternehmensdaten an, weist sie der richtigen Person zu und hängt einen Entwurf der ersten Antwort an. Das Routing passiert in Minuten. Die Senior-Person liest nur noch, was das System als ungewöhnlich markiert. Was niemand vorhergesehen hatte: Die Antwortentwürfe wurden schneller angenommen als das Routing – weil das Schreiben der ersten Antwort der Schritt war, den die Vertriebsleute tatsächlich scheuten.
Berichtsentwürfe folgen demselben Muster. Ein monatlicher Betriebsbericht kostete früher eine Person einen halben bis einen ganzen Tag: Zahlen aus drei Systemen ziehen, in eine Präsentation kopieren, Diskrepanzen abgleichen und die Erzählung „was hat sich geändert und warum" schreiben. In den Reporting-Workflows, die wir automatisiert haben, lag der manuelle Aufwand zwischen 4 und 8 Stunden pro Bericht. Die automatisierte Version zieht die Zahlen über schlichte Integrationen und lässt ein Modell den ersten Entwurf der Erzählung schreiben; der Mensch redigiert 30 bis 60 Minuten. Die ehrliche Grenze: Das Modell ist gut in Prosa wie „Der Umsatz sank in Woche zwei, weil das Versandvolumen fiel", aber es hat keine Ahnung, welche der siebzehn Veränderungen den CEO tatsächlich interessiert. Dieses Urteil bleibt beim Menschen – darum nennen wir das Berichtsentwurf und nicht Berichtsautomatisierung.
Was Sie messen sollten
Messen Sie vorher und nachher. Wer das Vorher auslässt, kann das Nachher nie beweisen.
Gesparte Stunden sind die Zahl, die das Projekt bezahlt. Wir bestehen auf einer Baseline: Jemand begleitet den Workflow eine Woche lang und protokolliert echte Zeiten, keine Schätzungen. In unseren Baseline-Wochen unterschätzen Menschen systematisch die Aufgaben, die sie auf Autopilot erledigen – manchmal um die Hälfte.
Die Fehlerquote ist die Zahl, die Sie ehrlich hält. Ziehen Sie wöchentlich Stichproben der Ergebnisse und lassen Sie sie von einem Menschen bewerten. Hier verdient sich ein fester Testdatensatz seinen Platz: echte Inputs mit bekannt korrekten Outputs, die bei jeder Prompt-Änderung oder jedem Modellwechsel erneut gegen den Workflow laufen. Ohne ihn ist jede Änderung eine Vermutung, die sich als Fortschritt verkleidet.
Die Durchlaufzeit – vom Eingang bis zur Erledigung – ist die Zahl, die der Rest des Unternehmens spürt. Rechnungen, die fünf Tage lagen, werden jetzt an einem abgearbeitet. Leads, die über Nacht warteten, bekommen ihre Antwort vor dem Mittagessen.
Planen Sie auch die laufenden Kosten ein, denn sie sind real. Tokens sind pro Aufruf billig und summieren sich beim Volumen. Retrieval – wenn das Modell vor dem Antworten Ihre Dokumente durchsucht – fügt jeder Anfrage einen Such-Umweg und einen längeren Prompt hinzu: Die Latenz steigt, die Token-Kosten steigen, die Genauigkeit wird schwerer nachvollziehbar, und Sie pflegen jetzt ein zweites System. Nichts davon ist ein Grund, nicht zu bauen. Es ist ein Grund, die Kosten pro verarbeitetem Vorgang ab Tag eins zu messen, statt sie in Monat vier zu entdecken.
Wo erste KI-Projekte sterben
Die Fehlerbilder wiederholen sich über die Projekte hinweg, zu deren Rettung wir gerufen wurden. In aufsteigender Reihenfolge des verbrannten Geldes:
Chatbot zuerst
Der Chatbot ist die Oberfläche mit der höchsten Varianz und der schwierigsten Evaluierung, die Sie wählen können – und er stellt das Modell ab Tag eins direkt vor Ihre Kunden. Eine falsche Antwort geht direkt an den Kunden; es gibt keine Review-Queue und keinen Konfidenzschwellenwert, der sie abfängt. Unsere Regel: Beginnen Sie nicht mit einem Chatbot. Beginnen Sie dort, wo ein Mensch das Ergebnis bereits prüft, verdienen Sie Vertrauen in die Genauigkeit des Systems, und lassen Sie kundenorientierte Anwendungsfälle später kommen, wenn die Zahlen sie rechtfertigen.
Plattform zuerst
Das Enterprise-KI-Plattform-Pitch kommt früh: ein Vertrag, ein Anbieter, jeder Anwendungsfall gelöst. Was es tatsächlich liefert – in den Plattform-Rollouts, die wir bei Kunden miterlebt haben –, ist eine sechsmonatige Implementierung, bevor Ihr erster Workflow läuft, und ein Prozess, den Sie am Ende so verbiegen, dass er zu den Annahmen des Werkzeugs passt. Ein erster Workflow braucht einen API-Key, ein paar hundert Zeilen Glue-Code, einen Orchestrator wie n8n oder Make und eine Datenbank. Plattformen haben ihren Platz – ungefähr an dem Punkt, an dem Sie fünf funktionierende Automatisierungen und ein Governance-Problem haben. Nicht vorher.
Das dritte Fehlerbild ist leiser: der Pilot, der nie live geht, weil niemand definiert hat, was „live gehen" bedeutet. Wir legen die Kriterien in Woche eins fest: Liegt die Fehlerquote unter einem vereinbarten Wert und übersteigen die gesparten Stunden bis Woche acht eine vereinbarte Schwelle, geht das System in Produktion. Andernfalls stoppen wir – und der Kunde hat Wochen verloren, nicht Quartale. Ein Pilot ohne Abbruchkriterien ist keine Vorsicht. Er ist die Art, wie KI-Budgets sterben, während alle beschäftigt aussehen.
Ein realistischer 8-Wochen-Rollout
So sieht das bei uns aus, von Anfang bis Ende:
- Wochen 1–2: Discovery. Wir begleiten den Workflow, protokollieren Baseline-Stunden und Fehlerquote und vereinbaren die zu automatisierende Scheibe plus die Go/No-Go-Kriterien.
- Wochen 3–6: der Build. Das ist unser Sprint mit festem Umfang, etwa vier Wochen, mit einer funktionierenden Demo jeden Freitag – für die Menschen, die die Arbeit tatsächlich machen, nicht nur für den Sponsor.
- Woche 7: Parallelbetrieb. Alter Prozess und neues System Seite an Seite, jede Abweichung wird untersucht. Diese Woche ist nicht verhandelbar – hier entsteht das Vertrauen.
- Woche 8: Übergabe. Sie bekommen das Evaluierungs-Setup, ein Runbook, Zugang zu jedem Prompt und jedem Flow sowie eine Schulung. Wenn Ihr eigenes Team den Betrieb langfristig übernehmen soll, machen wir Build-Operate-Transfer; wenn wir ihn lieber weiterbetreiben sollen, machen wir auch das.
Die Teamform spielt hier eine Rolle. Die Projektleitung sitzt in Deutschland, das Senior-Engineering-Team arbeitet aus Pakistan, und die Lieferung läuft auf Englisch oder Deutsch – so sitzen ein Mittelstands-COO und ein Senior Engineer im selben Wochencall, ohne Stille-Post dazwischen. Was dieses Muster hervorbringt, sehen Sie in unseren Fallstudien.
Eins noch, weil es der Kompromiss ist, den die meisten Agenturen nicht schriftlich geben: Manchmal ist KI das falsche Werkzeug. Wenn Ihr Workflow null Toleranz für Varianz hat (Gehaltsabrechnung oder alles, was eine Aufsichtsbehörde liest), ist ein probabilistisches Modell das falsche Instrument – die richtige Antwort ist schlichte Automatisierung oder bessere Software. In den vergangenen zwei Jahren endete etwa ein Drittel der „KI-Projekte", die wir anbieten sollten, mit unserer Empfehlung, gar keine KI einzusetzen. Wir zählen diese zu unseren besten KI-Automatisierungsprojekten, weil der Kunde das Ergebnis bekam, ohne das Wissenschaftsprojekt.
Die Unternehmen, die im Moment echten Wert aus KI ziehen, sind nicht die mit dem ausgefallensten Modell oder dem größten Plattformvertrag. Es sind die, die einen schmerzhaften Workflow gewählt, den langweiligen Teil automatisiert, ehrlich gemessen und zu Ende gebracht haben. Wenn Sie diese erste Discovery-Woche auf Ihren eigenen Betrieb anwenden wollen, sprechen Sie mit uns.
Häufige Fragen
Was kostet ein erstes KI-Automatisierungsprojekt?
Bei uns landen Discovery plus ein erster Build mit festem Umfang typischerweise im unteren fünfstelligen Bereich. Unsere Stundensatzspanne liegt bei 25–49 $, die Bauphase läuft etwa vier Wochen, und der Umfang wird vor Beginn fixiert – die Zahl, die Sie freigeben, ist die Zahl, die Sie zahlen. Die laufenden Kosten (API-Tokens, Hosting, Monitoring) kommen separat und liegen beim Volumen eines einzelnen Workflows meist bei einigen hundert Dollar im Monat.
Brauchen wir saubere, geordnete Daten, bevor wir starten?
Nein. Sie brauchen Zugang zu den Systemen, die der Workflow berührt, und eine Person, die die Schritte erklären kann. Die Discovery-Woche existiert genau dafür, herauszufinden, in welchem Zustand Ihre Daten sind – und die meisten Workflows laufen mit unperfekten Daten problemlos, weil ein Mensch die Ergebnisse weiterhin prüft.
Was passiert, wenn die KI einen Fehler macht?
Das System ist um Fehler herum gebaut: Fälle mit niedriger Konfidenz oder hohem Wert landen in einer menschlichen Review-Queue, und alles Unumkehrbare wie Zahlungen genehmigt ein Mensch. Die Fehlerquote messen wir wöchentlich gegen einen festen Testdatensatz – Genauigkeitsprobleme tauchen so im Dashboard auf, bevor sie in Ihrem Betrieb auftauchen.
Sollten wir das intern bauen oder eine Agentur beauftragen?
Wenn Sie Entwickler mit produktiver LLM-Erfahrung und freie Kapazität haben, kann der interne Weg funktionieren. Die meisten 50-Personen-Unternehmen haben beides nicht. Deshalb sind unsere Projekte auf Übergabe ausgelegt: Sie bekommen den Code, das Evaluierungs-Setup und ein Runbook – und wenn Ihr eigenes Team den Betrieb nach dem Launch übernehmen soll, bieten wir Build-Operate-Transfer an.
