Es gibt eine Frage, die in keinem KI-Angebot steht und die trotzdem über Ihre Kosten der nächsten drei Jahre entscheidet: Wer verdient daran, wenn Ihr Prozess mehr Tokens verbraucht als nötig? Bei den Modellanbietern lautet die Antwort: sie selbst. Bei uns lautet sie: niemand. Dieser Unterschied ist keine Marketing-Nuance — er führt zu einer völlig anderen Architektur.
Das Interesse, über das niemand spricht
Ein KI-Modellanbieter rechnet pro Token ab. Jedes zusätzliche Kontextfenster, jeder überflüssige Denkschritt, jede Schleife, in der das Modell sich selbst korrigiert, ist für ihn Umsatz. Das ist kein böser Wille, sondern schlicht das Geschäftsmodell. Aber es bedeutet: Der Anbieter, dessen Technik Sie einsetzt, hat kein wirtschaftliches Interesse daran, dass Ihr Prozess sparsam läuft. Er hat das gegenteilige.
Stellen Sie sich einen Handwerker vor, der nach Stunden abrechnet und gleichzeitig selbst entscheidet, wie viele Stunden die Aufgabe braucht. Sie würden ihm nicht unterstellen, dass er trödelt — aber Sie würden auch nicht erwarten, dass er von sich aus nach dem schnellsten Weg sucht. Genau in dieser Konstellation stehen Unternehmen, die ihre Prozesse direkt auf ein Modell aufsetzen und das Modell alles machen lassen, was irgendwie geht.
Cortexion steht anders da. Unsere Pläne sind Festpreise pro Nutzer und Monat mit einem Token-Kontingent, und im Pay-as-you-go-Modus reichen wir die Token-Kosten der Modellanbieter 1:1 weiter — ohne Aufschlag. Wir verdienen also keinen Cent zusätzlich, wenn Ihr Prozess das Zehnfache verbrennt. Im Gegenteil: Jeder Token, den wir einsparen, verlängert die Reichweite Ihres Kontingents, hält Ihre Automatisierung wirtschaftlich und sorgt dafür, dass Sie im nächsten Jahr noch Kunde sind. Unser Interesse und Ihres zeigen in dieselbe Richtung. Deshalb bauen wir Prozesse anders.
Die einfache Regel: KI ist ein Werkzeug für Urteilsvermögen — nicht für Buchhaltung
Wenn Sie einen typischen Geschäftsprozess in seine Einzelschritte zerlegen, stellen Sie fast immer dasselbe fest: Der überwiegende Teil ist vollkommen eindeutig. Daten holen, Format umwandeln, Pflichtfelder prüfen, Summe bilden, Frist berechnen, in ein System schreiben, eine Benachrichtigung verschicken. Das sind Aufgaben mit genau einer richtigen Antwort. Sie brauchen kein Sprachmodell — sie brauchen Code.
Nur ein kleiner Teil des Prozesses erfordert wirklich das, was KI kann: unstrukturierte Sprache verstehen, mit Kontext bewerten, sinnvoll formulieren, in Grauzonen entscheiden. Diesen Teil bekommt das Modell. Den Rest nicht.
Was in Code gehört
- Daten holen und schreiben: CRM, ERP, Buchhaltung, Postfach, Datenbank, Webhook — jede Schnittstelle ist deterministisch ansprechbar.
- Formate umwandeln: CSV, JSON, XML, ZUGFeRD, PDF-Text, Datumsformate, Zeichensätze.
- Validieren: IBAN-Prüfsumme, USt-ID-Format, Pflichtfelder, Wertebereiche, Dublettenabgleich.
- Rechnen: Netto, Steuer, Rabatte, Währungsumrechnung, Zahlungsziele, Fristen, Skonto.
- Verzweigen nach klaren Regeln: „Betrag über 5.000 Euro braucht Zweitfreigabe", „Lieferant auf Sperrliste", „Land außerhalb der EU".
- Wiederholen, sortieren, filtern, zusammenführen: alles, was mit Listen zu tun hat.
- Zustellen: Mail, Ticket, Chat-Nachricht, Dateiablage, Signaturlauf.
Was das Modell bekommt
- Unstrukturiertes verstehen: Freitext-Mails, gescannte Belege ohne festes Layout, handschriftliche Notizen, Protokolle.
- Mit Kontext bewerten: Wie dringend ist diese Anfrage? Ist der Kunde verärgert? Welche der 40 Kategorien passt, obwohl keine Regel greift?
- Formulieren: Antwortentwürfe, Zusammenfassungen, Berichtstexte, Angebotsbausteine.
- Uneindeutiges zuordnen: Kostenstelle bei ungewöhnlicher Leistungsbeschreibung, Zuständigkeit bei querliegender Anfrage.
Die Faustregel dahinter passt in einen Satz: Wenn Sie die Regel aufschreiben können, schreiben Sie sie als Code. Wenn Sie sie nur beschreiben können, nehmen Sie die KI. Eine KI, die eine Mehrwertsteuer ausrechnet, ist ein sehr teurer Taschenrechner — und einer, der in seltenen Fällen falsch rechnet.
Ein Rechenbeispiel: derselbe Prozess, zwei Bauweisen
Nehmen Sie einen Rechnungseingang mit 2.000 Belegen im Monat. Der Prozess ist immer gleich: Beleg lesen, Felder erkennen, prüfen, Kostenstelle zuordnen, Freigabe steuern, ins Buchhaltungssystem übergeben. Zwei Wege führen dorthin.
Variante A — „Die KI macht alles"
Jeder Beleg wandert vollständig in ein Spitzenmodell. Es soll die Felder erkennen, die Summen nachrechnen, die Plausibilität prüfen, die Kostenstelle bestimmen, die Freigaberegel anwenden und die Buchungszeile formulieren. Klingt elegant, ist schnell gebaut — und schickt für jeden einzelnen Beleg das gesamte Dokument plus Regelwerk plus Beispiele durch das teuerste Modell im Haus. Plus die Wiederholungen, wenn das Ergebnis nicht sauber strukturiert zurückkommt.
Variante B — Code first, KI gezielt
Die Textextraktion läuft deterministisch. Bekannte Lieferanten mit festem Rechnungslayout werden per Regel ausgelesen — das sind erfahrungsgemäß die meisten. Das Modell bekommt nur die Belege, die wirklich unklar sind, und auch dann nur den relevanten Ausschnitt statt des kompletten Dokuments. Prüfsummen, Steuerlogik, Dublettencheck, Freigabeschwelle und Übergabe ans Buchhaltungssystem macht Code. Ein Spitzenmodell kommt nur dort zum Einsatz, wo tatsächlich ein Urteil gefällt werden muss.
| Beispielrechnung, 2.000 Belege/Monat | Variante A | Variante B |
|---|---|---|
| Aufrufe an ein Spitzenmodell | 2.000 | rund 300 |
| Kontext je Aufruf | ca. 12.000 Tokens (ganzes Dokument) | ca. 6.000 Tokens (nur der unklare Teil) |
| Zusätzliche Aufrufe an ein kleines Modell | — | 2.000 × ca. 1.200 Tokens |
| Volumen auf dem teuren Modell | ca. 24 Mio. Tokens | ca. 1,8 Mio. Tokens |
| Rechenfehler bei Summen | möglich, muss stichprobenhaft geprüft werden | ausgeschlossen, Code rechnet |
| Laufzeit je Beleg | Sekunden | Millisekunden, außer bei den unklaren Fällen |
Die Zahlen sind eine illustrative Modellrechnung mit offengelegten Annahmen, kein gemessener Benchmark — Ihr Belegmix verschiebt sie in beide Richtungen. Die Größenordnung bleibt aber stabil: Das Volumen auf dem teuren Modell sinkt um den Faktor zehn bis zwanzig, und weil Spitzenmodelle je Token ein Vielfaches kleiner Modelle kosten, schlägt genau dieser Posten am Ende auf die Rechnung durch.
Der interessante Teil ist nicht die Ersparnis an sich. Der interessante Teil ist, dass Variante B gleichzeitig das bessere Ergebnis liefert.
Warum weniger KI auch bessere Prozesse macht
1. Determinismus statt „meistens richtig"
Code liefert bei gleichem Input immer dasselbe Ergebnis. Ein Sprachmodell ist statistisch — es liefert meistens dasselbe. Bei einer Formulierung ist „meistens" völlig in Ordnung. Bei einer Rechnungssumme, einem Zahlungsziel oder einer Freigabeschwelle ist „meistens" ein Kündigungsgrund. Jeder Schritt, den Sie aus dem Modell herausholen, wird von einer Wahrscheinlichkeit zu einer Zusage.
2. Testbarkeit
Eine Regel im Code können Sie mit Testfällen absichern und beim nächsten Release erneut prüfen. Ein Prompt können Sie nur beobachten. Wenn der Modellanbieter sein Modell aktualisiert, ändert sich Verhalten, das Sie nie angefasst haben — bei Code passiert das nicht.
3. Tempo
Ein Modellaufruf dauert Sekunden, eine Codezeile Mikrosekunden. Bei 2.000 Belegen ist das der Unterschied zwischen einem Nachtlauf und einem Vormittag. Und bei Prozessen, die im Kundenkontakt laufen — Anfrage rein, Antwort raus — entscheidet er darüber, ob sich das Ganze überhaupt live anfühlt.
4. Nachvollziehbarkeit
Einer Wirtschaftsprüferin oder einer Aufsichtsbehörde können Sie eine Regel zeigen. Ein Prompt-Ergebnis können Sie nur nachträglich plausibilisieren. Je mehr Entscheidungslogik in überprüfbarem Code liegt, desto entspannter ist Ihr Umgang mit Dokumentationspflichten — Stichwort EU AI Act und interne Revision.
5. Datenschutz durch Datensparsamkeit
Was nie an ein Modell geht, müssen Sie auch nicht absichern. Wenn Code die Kundennummer prüft und nur der unklare Freitext ans Modell geht, verlässt schlicht weniger personenbezogene Information den engen Kreis. Das ist gelebte Datenminimierung nach Art. 5 DSGVO und macht Ihre Datenschutz-Dokumentation spürbar schlanker.
6. Ressourcen
Jeder eingesparte Token ist eingesparte Rechenzeit in einem Rechenzentrum — mit allem, was daran hängt: Strom, Kühlung, Hardware. Ein Prozess, der 90 Prozent seiner Modellaufrufe nicht braucht, ist nicht nur billiger, er ist auch der ehrlichere Beitrag zu jeder Nachhaltigkeitsstrategie als jede Absichtserklärung.
Modell-Routing: nicht jeder Schritt braucht das teuerste Modell
Die zweite Stellschraube nach „Code oder KI" ist „welche KI". In der Praxis sind die meisten Modellaufrufe in einem Prozess simpel: Klassifizieren, Extrahieren, Zusammenfassen, Sortieren. Dafür ein Spitzenmodell zu nehmen, ist so, als würden Sie den Umzug mit dem Sportwagen machen.
In Cortexion wählen Sie das Modell pro Schritt. Die Standardaufgaben laufen auf schnellen, günstigen Modellen wie GPT-5.4 oder Gemini 3.5 Flash. Der eine Schritt in der Kette, an dem es wirklich auf Präzision ankommt — die schwierige Vertragsklausel, die knifflige Zuordnung — bekommt Claude Opus 5. Und was am Ende jemand liest, formuliert Claude Fable 5. Diese Aufteilung ist kein Kompromiss, sondern schlicht die richtige Werkzeugwahl — und sie ist der Grund, warum dieselbe Automatisierung bei uns ein Vielfaches günstiger läuft als bei einem Setup, in dem alles durch ein einziges großes Modell fließt.
Kostentransparenz ist die Kontrolle darüber
Sparsamkeit, die man nicht messen kann, ist eine Behauptung. Deshalb schreibt Cortexion für jeden Lauf einer Automatisierung einen vollständigen Trace mit: welcher Schritt, welches Modell, wie viele Tokens, wie lange, welche Kosten. Sie sehen nicht nur die Monatsrechnung, sondern den Beleg pro Prozessschritt — inklusive Kostenobergrenzen und Warnschwellen, bevor etwas aus dem Ruder läuft.
Das ist auch der praktische Hebel für die Optimierung: Wenn ein Schritt auffällig teuer ist, sehen Sie das sofort und können ihn umbauen — kleineres Modell, kürzerer Kontext oder eben ganz in Code. Ein Anbieter, der Ihnen den Verbrauch nicht pro Schritt zeigt, hat dabei selten ein Oberflächen-Problem. Er hat ein Interessens-Problem.
Die fünf Fragen an jeden Automatisierungsanbieter
- Verdienen Sie an meinem Token-Verbrauch? Wird mit Aufschlag abgerechnet oder zum Einkaufspreis durchgereicht? Die Antwort sagt Ihnen, in welche Richtung der Anbieter optimiert.
- Welche Schritte in einem Beispielprozess laufen deterministisch, welche über ein Modell? Lassen Sie sich einen konkreten Workflow zeigen. Wer auf diese Frage ins Schwimmen gerät, hat alles ins Modell gelegt.
- Kann ich pro Schritt das Modell wählen — auch ein kleines? Ohne diese Wahl ist jede Kostendiskussion theoretisch.
- Sehe ich Kosten pro Lauf und pro Schritt, mit Limit und Warnung? Ohne Messung keine Steuerung.
- Was passiert mit meinen Prozessen, wenn die Token-Preise steigen? Die Antwort führt direkt zur Architekturfrage — wir haben sie im Beitrag zu Vendor-Lock-in bei KI ausführlich durchgerechnet.
Was das für den Mittelstand konkret heißt
Es geht bei alldem nicht um Sparsamkeit als Tugend. Es geht um Skalierbarkeit. Ein Prozess, der pro Vorgang wenige Cent kostet, lässt sich auf alle 50.000 Vorgänge im Jahr ausrollen. Ein Prozess, der pro Vorgang einen Euro kostet, bleibt für immer ein Pilotprojekt mit 200 ausgewählten Fällen — und genau daran scheitern die meisten KI-Initiativen im zweiten Jahr. Nicht an der Technik, sondern daran, dass die Wirtschaftlichkeitsrechnung beim Hochskalieren kippt.
Wer den teuren Teil klein hält, dreht diese Logik um: Das KI-Budget hört auf, der Engpass zu sein. Dann entscheiden Sie nach Nutzen, welche Prozesse Sie automatisieren — nicht nach Tokenpreis. Wie Sie dabei methodisch vorgehen, haben wir im Leitfaden zu Automatisierung und Workflow Schritt für Schritt beschrieben. Und bauen müssen Sie das längst nicht mehr selbst: Seit Kurzem entstehen diese Prozesse in Cortexion direkt aus einer Beschreibung im Chat — nachzulesen unter Prozesse automatisieren ohne Programmieren.
Fazit
KI ist der teuerste Baustein jeder Automatisierung und gleichzeitig fast nie der größte Teil des Problems. Wer beides zusammendenkt, kommt zwangsläufig zu einer Architektur, in der Code die Arbeit macht und das Modell das Urteil beisteuert. Das ist günstiger, schneller, prüfbarer und datensparsamer — und es funktioniert auch dann noch, wenn sich die Preise am Modellmarkt drehen.
Dass wir so bauen, ist keine Bescheidenheit. Es ist die logische Folge daraus, dass wir am Token nichts verdienen: Wir haben schlicht kein Interesse daran, dass Ihr Prozess mehr KI benutzt als er braucht. Buchen Sie eine 30-Minuten-Demo — bringen Sie einen Prozess mit, und wir zeigen Ihnen an Ihrem eigenen Beispiel, welcher Teil davon ein Modell braucht und welcher nicht.