Im Frühjahr schickte uns eine Gründerin ein Briefing für eine KI-Pipeline, die eingehende Rechnungen lesen und ohne menschliches Zutun buchen sollte. Zwei Tage Prozessaufnahme mit ihrem Team zeigten elf feste Prüfungen und Nachschlagevorgänge plus eine einzige Ermessensentscheidung, die ihre leitende Buchhalterin in Sekunden traf.
Der Bau, der live ging, enthielt kein Modell. Ein n8n-Flow liest jede Rechnung aus dem Postfach und gleicht den Absender mit der Lieferantentabelle in PostgreSQL 16 ab. Er stellt den Buchungsvorschlag in die Buchhaltungs-Queue. Alles, was eine Prüfung nicht besteht, landet auf einer Prüfliste, die die Buchhalterin jeden Morgen abarbeitet. Vier Monate nach dem Start verarbeitet der Kunde rund 4.000 Rechnungen im Monat bei zwei Fehlleitungen insgesamt, beide in der Prüfung abgefangen.
Dieses Muster wiederholt sich in unseren Discovery-Terminen, die wir von Berlin aus führen, mit Senior-Entwicklern in unseren Hubs in den VAE und Pakistan im Rücken. Ein fester Anteil kommt mit KI im Titel und verlässt den Termin als schlichte Automatisierung im Scope. Niemand in diesen Terminen fühlt sich mit der kleineren Lösung abgespeist. Der nüchterne Bau kostet weniger und geht früher live. Im Betrieb bricht er seltener.
Wenn im Briefing KI steht und im Prozess Regeln stecken
Der Rechnungsfall ist typisch, also lohnt es sich, ihn aufzuschlüsseln. Das Briefing verlangte Software, die Rechnungen liest und Lieferanten bei Abweichungen anschreibt. Lesen hieß am Ende: Felder aus Belegen ziehen, die fast alle denselben strukturierten Export aus zwei Buchhaltungstools trugen. Ein Parser erledigte das, die wenigen Sonderformate gingen in die Prüfung. Entscheiden hieß: vier feste Buchungsregeln, die die Buchhalterin in einer halben Stunde diktierte. Anschreiben hieß: eine Erinnerungsmail mit der Rechnung im Anhang.
Kein Schritt in dieser Kette brauchte ein System, das rät. Jeder Schritt hatte eine vorab definierte richtige Antwort, also hatte jeder Fehler eine Adresse: die exakte Prüfung, die die Rechnung abgelehnt hatte. Das ist das ganze Argument für schlichte Automatisierung. Gleicher Input erzeugt gleichen Output, und das Protokoll nennt den Schritt, der gehandelt hat. So ein System lässt sich billiger testen und billiger betreiben. Monate später können Sie noch erklären, was es getan hat, weil der Beleg im Log steht statt in einem Transkript aus Modellbegründungen.
Solche Systeme liefert unser Workflow-Automatisierungs-Service am häufigsten aus. Ein Auslöser, ein Satz Prüfungen, ein Abgleich gegen das führende System, eine Aktion, eine Log-Zeile. Die Bauteile sind Jahrzehnte alt. Was das Projekt gelingen lässt, ist die Sorgfalt in der Aufnahme: bei der Person sitzen, die die Arbeit macht, bis jede Verzweigung in ihrem Kopf als Bedingung aufgeschrieben ist, die eine Maschine auswerten kann.
Diese Projekte bekommen ihre KI-Etikett aus einem unschuldigen Grund. Gründerinnen und Gründer beschreiben einen Schmerz, der echt ist und Geld kostet, und Anbieter beantworten ihn mit dem neuesten Werkzeug. Der Schmerz im Rechnungsfall waren vierzig Stunden manuelle Buchung im Monat. Die Kur war vierzig Stunden Aufnahme plus drei Wochen Bau. Kein Teil dieser Kur brauchte ein Modell. Eines hinzuzufügen hätte ein gelöstes Problem in eine Dauerbaustelle verwandelt.
Die Prüfung, die bei uns vor jedem Modell läuft
Landet ein Briefing mit KI im Titel auf unserem Tisch, laufen immer dieselben Checks. Jeder Check nimmt eine Gruppe von Schritten aus der Modellkandidatur. Die meisten Schritte scheitern am ersten.
Wie stark streut der Input?
Dieser Check streicht die meisten Modellausgaben. Ein Modell verdient seine Kosten bei Input, den niemand vollständig vorhersehen kann: Freitext-Mails in gemischten Sprachen oder PDFs von einem Lieferanten, den Sie noch nie gesehen haben. Regeln verdienen ihre Kosten überall sonst: Kommt der Input strukturiert oder aus einem festen Satz von Systemen, erledigt Code das genauer zu einem Bruchteil der Laufkosten.
Der Rechnungsfall ist an diesem Check auf die bestmögliche Art gescheitert. Belege, die für das menschliche Auge unordentlich wirkten, stellten sich als zwölf Varianten desselben Formulars heraus. Das ist eine Nachschlagetabelle, kein Trainingsdatensatz. Lieferantenmails in einem verwandten Projekt bestanden den Check, weil sie in jeder erdenklichen Formulierung eintrafen. Dort arbeitet ein Modellschritt zur Klassifikation in einem sonst festen Flow.
Wie schlimm ist eine falsche Antwort?
Manche Fehler sind umkehrbare Ärgernisse. Ein falsch abgelegter Newsletter, ein Ticket in der falschen Queue, ein Entwurf, der einen weiteren Durchgang braucht. Ein Schritt mit Wahrscheinlichkeiten ist dort vertretbar, solange ein Mensch oder eine Regel das Ergebnis prüft, bevor es zählt.
Andere Fehler sind falsche Zahlungen oder falsche Einträge in Unterlagen, die später eine Behörde liest. Dort braucht es deterministisches Verhalten und einen Prüfpfad, der genau zeigt, welche Bedingung gegriffen hat. Ein Modelltranskript leistet das nicht, weil es festhält, was das Modell über seine Begründung sagt, statt des Mechanismus, der die Handlung erzeugt hat. Wo Fehlkosten hoch sind, lassen wir den Schritt im Code, auch wenn ein Modell ihn schneller erledigen könnte. Wir schreiben das in der Discovery so auf. Kunden widersprechen dem gelegentlich. Der Widerspruch endet, sobald wir fragen, wer die erste falsche Zahlung unterschreibt.
Wie oft läuft das?
Das Volumen entscheidet über die Wirtschaftlichkeit. Ein Modellschritt kostet Tokens bei jedem Lauf plus wöchentliche menschliche Aufmerksamkeit für die Review-Queue und neue Validierung nach Upgrades. Bei einigen hundert Vorgängen pro Woche ist diese Last tragbar, bei Hunderttausenden von Läufen drückend. Dort gewinnt ein deterministischer Flow mit Grenzkosten nahe null um Größenordnungen.
Drift wächst mit dem Volumen mit. Ein Modellschritt, der einen von zweihundert Vorgängen falsch einordnet, ist eine Kuriosität im Wochenbericht und ein Aufräumprojekt bei einer Million Transaktionen im Monat. Regeln driften nicht: Der Flow, den Sie im März getestet haben, ist der Flow, der im Oktober läuft. Es sei denn, jemand hat ihn geändert. Dann nennt die Versionsverwaltung den Namen.
Wie schlichte Automatisierung in der Praxis aussieht
Ein schlichter Flow hat wenige Teile, und nur die Aufnahme verlangt echtes Nachdenken. Der Auslöser beobachtet ein Postfach, einen Ordner, einen Webhook oder einen Zeitplan. Prüfungen gleichen die Felder gegen feste Bedingungen ab, während ein Abgleich den Vorgang mit dem führenden System verbindet, dem ERP oder CRM, das bereits die Wahrheit hält. Die Aktion schreibt dann das Ergebnis oder verschickt die Nachricht nach Vorlage. Das Protokoll hält fest, was auf jeder Stufe passiert ist, und die Prüfliste sammelt alles, was die Checks nicht unterbringen konnten.
Unsere Bauten nutzen n8n oder schlichten Code, je nachdem, wer den Flow später pflegt. Dahinter steht meist PostgreSQL. Der Rechnungs-Flow brauchte drei Wochen von der Aufnahme bis zum Produktivbetrieb, inklusive der Prüfmaske, die die Buchhalterin jeden Morgen nutzt. Diese Maske unterschätzen Teams gern: Fünfzehn Minuten am Tag darauf ersetzten vierzig Stunden manuelle Buchung im Monat. Die Liste selbst ist zugleich der Testdatensatz für jeden künftigen Modellschritt.
Ältere Systeme machen dieses Bild unordentlicher. Viele Prozesse, die wir automatisieren, sitzen auf Software ohne Schnittstelle. Dann steht zuerst die unglamouröse Integrationsarbeit an, meist Exportroutinen und ein Konnektor. Solche Aufträge starten oft als Software-Modernisierung und enden als Automatisierung.
Wo wir trotzdem ein Modell holen
Nichts davon macht uns zu Modellgegnern. Wir liefern regelmäßig Modellschritte aus, und manche Probleme haben keine gute deterministische Antwort. Eingehende Anfragen lesen, die in jeder Sprache eintreffen, und entscheiden, worum es jeweils geht, gehört einem Modell. Genauso das Herausziehen von Positionen aus einem Beleglayout, das Sie noch nie gesehen haben. Berichtstexte aus strukturierten Quelldaten können ebenfalls einen nutzen, mit einem Menschen, der den Entwurf freigibt.
Die Disziplin liegt im Zuschnitt. Das Modell bekommt einen Schritt, nie den ganzen Flow. Der Schritt sitzt hinter derselben Prüfliste wie die Regeln. Diese Form, ein deterministischer Flow mit einem Modellschritt darin und einer menschlichen Freigabe dahinter, ist die Architektur des größten Teils unserer KI-Automatisierungs-Lieferung. Wo genau die Grenze verläuft, haben wir im Vergleich von Agenten gegen schlichte Workflows ausführlich beschrieben: Streuung, die Regeln nicht fassen, ist das Einzige, worin ein Modell strikt besser ist. Kaufen Sie das Modell nur für diese Streuung.
Der Preis ist Pflege, die Regeln nie brauchen. Prompts verlangen Nacharbeit, wenn die Trefferquote rutscht, und Anbieter-Upgrades ändern Verhalten ohne zu fragen. Jemand besitzt den Evaluierungsdatensatz aus echten Eingaben mit bekannten richtigen Ergebnissen, oder niemand kann sagen, ob der Schritt schlechter wurde. Diese Verpflichtung gehen wir ein, wo der Schritt sie verdient.
Die laufenden Kosten im direkten Vergleich
Die Tabelle unten verdichtet den Vergleich, den wir in Discovery-Terminen aufzeichnen. Die letzten beiden Zeilen überraschen Käufer am meisten.
| | Schlichter Flow | Modellschritt | | Kosten pro Lauf | Nahe null | Tokens plus Prüfzeit | | Gleicher Input zweimal | Gleiches Ergebnis | Ergebnis kann abweichen | | Fehlerhinweis | Exakte Stelle im Log | Transkript plus Deutung | | Verhalten über Zeit | Stabil bis zur Änderung | Driftet, braucht neue Tests |
Die Baukosten gewinnt, wer enger zuschneidet. Die Laufkosten sind der Punkt, an dem die Wege dauerhaft auseinandergehen: Der schlichte Flow läuft auf Infrastruktur, die Sie ohnehin bezahlen, und ändert sich erst mit einer Änderung. Der Modellschritt misst Tokens bei jedem Lauf und Aufmerksamkeit jede Woche. Kein einzelner Betrag davon erschreckt irgendwen. Zusammen bilden sie einen Dauerposten, den die meisten Anbieterangebote verschweigen. Darum schreiben wir ihn vor dem Kickoff auf.
Auch die Umkehrbarkeit unterscheidet sich. Benimmt sich ein schlichter Flow daneben, lesen wir das Log und korrigieren die Bedingung. Die betroffenen Vorgänge laufen sauber erneut durch. Ein abgerutschter Modellschritt schickt Sie auf die Suche über Prompts und beigezogenen Kontext, während sich auf Anbieterseite lautlos etwas verschoben haben kann. Eine Wiederholung kann trotzdem ein anderes Ergebnis liefern.
Erst nüchtern starten, dann Intelligenz dort ergänzen, wo sie sich rechnet
Die Reihenfolge, die wir empfehlen, folgt aus allem oben. Bringen Sie zuerst den deterministischen Flow live und messen Sie, was er leistet: zurückgeholte Stunden, Fehlerquote, Durchlaufzeit, Prüfminuten pro Tag. Das Protokoll zeigt Ihnen dann genau, welche Fälle sich Regeln entziehen, mit echten Beispielen daran. Kommt aus diesem Beleg ein klar umrissener Schritt mit echter Input-Streuung zum Vorschein, geben Sie diesem Schritt ein Modell und behalten Sie die Freigabe. Kommt kein solcher Schritt zum Vorschein, besitzen Sie ein fertiges System zu flachen Laufkosten, und die KI-Budgetzeile kann zurück ins Geschäft.
Diese Reihenfolge hält jede künftige Option offen: Die Prüfliste wird zum Testdatensatz und das Log zur Spezifikation. Ein Modell, das in sechs Monaten dazukommt, startet mit Belegen statt mit einem leeren Blatt.
Wenn Sie einen Prozess vor Augen haben und nicht einordnen können, auf welcher Seite der Linie er liegt, ist das ein normaler Stand und eine gute Discovery-Frage. Unsere Termine laufen von Berlin aus, mit Senior-Entwicklern im Rücken. Die Antwort ist manchmal ein kleinerer Bau, als Sie angefragt haben. Schicken Sie uns den Prozess, und wir sagen Ihnen, welche Schritte in Code gehören und ob ein Schritt ein Modell verdient.
Häufige Fragen
Woran erkennen wir, ob unser Prozess überhaupt KI braucht?
Schreiben Sie den Prozess Schritt für Schritt mit der Person auf, die ihn heute ausführt. Lässt sich jeder Schritt als feste Prüfung oder Nachschlagevorgang formulieren, deckt schlichte Automatisierung ihn ab, und ein Modell fügt Kosten hinzu, ohne die Trefferquote zu erhöhen. Erfordern ein oder zwei Schritte das Lesen von Freitext oder Entscheidungen, die sich festen Regeln entziehen, sind genau diese Schritte Kandidaten für ein Modell in einem sonst deterministischen Flow.
Was kostet schlichte Workflow-Automatisierung im Vergleich zu einem LLM-Schritt?
Ein deterministischer Flow kostet die einmalige Bauleistung und danach pro Lauf fast nichts, weil er auf Infrastruktur läuft, die Sie ohnehin bezahlen. Ein LLM-Schritt fügt pro Lauf Token-Kosten hinzu plus laufende Pflege: Jemand muss den Evaluierungs-Testdatensatz aus echten Fällen aktuell halten und die Review-Queue besetzen, und jedes Anbieter-Upgrade erzwingt eine neue Validierungsrunde. Bei einigen hundert Vorgängen pro Woche ist das tragbar, bei Hunderttausenden von Läufen bestimmt es die Rechnung.
Können wir später KI ergänzen, wenn wir schlicht starten?
Ja, und diese Reihenfolge ergibt meist das bessere System. Der deterministische Flow liefert gemessene Fehlerquoten und ein Protokoll, das genau zeigt, welche Fälle sich Regeln entziehen. Jedes Modell, das Sie später ergänzen, bekommt damit eine klar umrissene Aufgabe und einen Testdatensatz aus echten Fehlerfällen. Wer mit dem Modell startet, zahlt für Raten bei Schritten, die Regeln gratis erledigt hätten.
Gilt der EU AI Act, wenn unser Workflow ohne KI läuft?
Ein Workflow aus festen Regeln und Nachschlagevorgängen enthält kein KI-System im Sinne des Gesetzes, also greifen dessen Pflichten für diesen Workflow nicht. Das Gesetz wird an dem Tag relevant, an dem Sie einen Modellschritt ergänzen, vor allem dort, wo dessen Ergebnis Einstellung, Kredit, Sicherheit oder Zugang zu Leistungen berührt. Bleibt der deterministische Kern sauber vom Modellschritt getrennt, wird diese spätere Einordnung deutlich einfacher.
