Laufende KI-Kosten senken: Warum nicht jeder Schritt KI braucht

Eine Automatisierung läuft, das Team ist zufrieden, und trotzdem steigt die Rechnung jeden Monat: beim KI-Anbieter, bei n8n oder Make, manchmal bei beiden. Wir sehen das in der Praxis regelmäßig. Der Grund ist selten das Modell selbst, sondern fast immer die Planung: KI erledigt Aufgaben, die gewöhnlicher Programmcode schneller, günstiger und zuverlässiger erledigen würde. Dieser Artikel zeigt, woher laufende KI-Kosten kommen, wie du entscheidest, wo KI wirklich nötig ist, und rechnet das an einem typischen Beispiel durch: der Verarbeitung von Eingangsdokumenten.

Woher die laufenden Kosten kommen

Bei KI-Prozessen bezahlst du an zwei Stellen:

• Beim KI-Anbieter nach Verbrauch, gemessen in Token, also Textbausteinen. Bezahlt wird alles, was das Modell liest, und alles, was es schreibt. Ausgabe-Token sind dabei meist fünfmal so teuer wie Eingabe-Token. Bilder kosten ebenfalls Token, und eine gescannte Seite als Bild ist deutlich teurer als derselbe Inhalt als Text.
• Bei der Automatisierungsplattform, und zwar je nach Anbieter ganz unterschiedlich: n8n berechnet in der Cloud jede Ausführung eines kompletten Workflows, egal wie viele Schritte er hat. Make rechnet seit August 2025 in Credits ab, grundsätzlich einen pro ausgeführtem Modul, KI-Module verbrauchen mehr. Zapier zählt jeden erfolgreichen Aktionsschritt als Task.

Daraus ergeben sich die drei typischen Kostentreiber: zu viele Aufrufe (jeder Teilschritt einzeln an die KI), zu viel Kontext (bei jedem Aufruf wird das ganze Dokument erneut mitgeschickt) und zu große Modelle (das Standardmodell für alles, auch für Aufgaben, die ein kleines Modell oder gar keins erledigt).

Das eigentliche Problem: KI als Allzweckwerkzeug

Viele Automatisierungen entstehen heute so: Jemand beschreibt einem KI-Assistenten den gewünschten Ablauf, und der Assistent entwirft einen Workflow. Das Ergebnis funktioniert, ist aber oft so gebaut, wie ein Sprachmodell denkt: Jeder Schritt wird an ein Sprachmodell gegeben. Datum aus einer Rechnung lesen? KI. Summe prüfen? KI. Prüfen, ob eine IBAN gültig ist? KI. Dateinamen vergeben? KI.

Ähnlich ist es mit dem Versprechen „100 % automatisiert“. Das kann stimmen, nur heißt es nicht, dass 100 % der Arbeit von KI erledigt werden sollten. Automatisierung bedeutet zunächst nur, dass kein Mensch eingreifen muss. Ob ein Schritt per Regel, per Programmcode oder per KI erledigt wird, ist eine eigene Entscheidung, und genau diese Entscheidung wird ohne saubere Planung, also ohne Orchestrierung, oft gar nicht getroffen.

Dabei hat KI für solche Aufgaben echte Nachteile: Sie kostet bei jedem Aufruf Geld, braucht Sekunden statt Millisekunden und liefert nicht immer dasselbe Ergebnis. Bei Rechenaufgaben kann sie sich sogar irren (Halluzination). Klassischer Code dagegen kostet nach der Entwicklung praktisch nichts pro Durchlauf, ist schnell und verhält sich immer gleich.

Faustregel: Code oder KI?

Aufgabe	Besser mit Code	Besser mit KI
Daten mit festem Format (Datum, Betrag, IBAN, Rechnungsnummer)	✓ Muster, Prüfziffern, Formatregeln
Rechnen und prüfen (Summen, Steuer, Abgleich mit Bestellung)	✓ immer exakt
Bekannte Absender und gleichbleibende Layouts	✓ Vorlagen und Regeln
Strukturierte Daten (XML, JSON, Schnittstellen)	✓ direkt auslesen
Freitext verstehen, Absicht erkennen		✓
Unbekannte Layouts, handschriftliche Notizen, uneinheitliche Formulierungen		✓
Zusammenfassen, Formulieren, Übersetzen		✓
Unklare Fälle einordnen		✓ mit Prüfung durch einen Menschen

Die Grundregel lautet also: Code für alles, was sich als Regel beschreiben lässt, KI für alles, was Sprachverständnis braucht. Und wenn KI, dann das kleinste Modell, das die Aufgabe zuverlässig löst. In diese Richtung gehen auch die Anbieter selbst: Anthropic beschreibt in seiner Dokumentation als einen Weg, mit dem kleinen Modell zu beginnen und nur bei Bedarf aufzurüsten, OpenAI nennt in seinem Leitfaden zur Kostenoptimierung ausdrücklich, weniger Anfragen zu stellen, weniger Token zu verbrauchen und ein kleineres Modell zu wählen.

Beispiel: Dokumente automatisch verarbeiten

Nehmen wir einen typischen Fall: Ein Unternehmen bekommt Rechnungen, Lieferscheine und Verträge per E-Mail und Post. Sie sollen erkannt, ausgelesen, geprüft, abgelegt und bei Bedarf zusammengefasst werden. So sieht ein orchestrierter Ablauf aus, Schritt für Schritt:

1. Eingang und Format erkennen (Code): Welche Datei kommt an, PDF, Bild oder XML? Das ist eine einfache Prüfung, keine KI nötig.
2. E-Rechnungen direkt auslesen (Code): Seit dem 1. Januar 2025 müssen Unternehmen in Deutschland E-Rechnungen empfangen können, und ihr Anteil wächst mit den Übergangsfristen bis Ende 2027. XRechnung und ZUGFeRD enthalten die Rechnungsdaten als strukturiertes XML, bei ZUGFeRD ist laut Bundesfinanzministerium dieses XML maßgeblich, nicht das Bild des PDFs. Diese Daten liest Code direkt aus, etwa mit der Python-Bibliothek factur-x. Hier braucht es weder Texterkennung noch KI.
3. Text holen (Code): Digitale PDFs enthalten ihren Text bereits, pdfplumber liest ihn samt Tabellen aus. Gescannte Dokumente bekommen mit OCRmyPDF (auf Basis der Texterkennung Tesseract) eine Textebene, und das läuft lokal, ohne Kosten pro Seite. Für schwierige Vorlagen gibt es spezialisierte Dienste wie Mistral OCR 4.1 (Listenpreis 4 US-Dollar je 1.000 Seiten) oder Werkzeuge wie Docling, die Dokumente samt Aufbau in strukturierten Text umwandeln. Wichtig ist: Ab jetzt wird mit Text gearbeitet, nicht mehr mit Bildern.
4. Dokumentart bestimmen (erst Code, dann KI): Absenderadresse, Stichwörter wie „Rechnung“ oder „Lieferschein“ und bekannte Layouts ordnen den Großteil der Dokumente per Regel zu. Nur was übrig bleibt, geht an ein kleines Sprachmodell, und zwar nur der Anfang des Textes, nicht das ganze Dokument.
5. Daten auslesen (erst Code, dann KI): Für bekannte Absender genügen Vorlagen mit Mustern, zum Beispiel mit invoice2data. Datumsangaben in verschiedenen Schreibweisen erkennt dateparser, unscharfe Übereinstimmungen wie leicht abweichende Firmennamen findet RapidFuzz. Erst bei unbekannten Layouts liest ein kleines Modell die Felder aus, mit einem festen Ausgabeformat, damit Code das Ergebnis direkt weiterverarbeiten kann.
6. Prüfen (Code): Stimmt die Summe aus Nettobetrag und Steuer? Passt die Bestellnummer zu einer offenen Bestellung? Ist die IBAN gültig? Das sind Rechenaufgaben, und Rechnen kann Code exakt. Was die Prüfung nicht besteht, landet bei einem Menschen (Human in the Loop).
7. Ablegen und weitergeben (Code): Dateiname, Ordner, Übergabe an ERP oder Buchhaltung, alles nach festen Regeln.
8. Zusammenfassen (KI, gezielt): Ein Vertrag oder ein langes Schreiben soll in drei Sätzen erklärt werden? Das ist eine echte Sprachaufgabe, hier ist KI stark. Aber nur dort, wo eine Zusammenfassung gebraucht wird, nicht bei jeder Rechnung.

Das Ergebnis: Die KI kommt nur noch an zwei, drei Stellen zum Einsatz, und dort mit kleinen Textausschnitten statt ganzen Seitenbildern.

Ein Hinweis zu den Bibliotheken: Wer PDFs mit PyMuPDF verarbeiten möchte, sollte die Lizenz kennen. PyMuPDF steht unter der AGPL; für geschlossene Software oder einen Online-Dienst braucht man eine kommerzielle Lizenz des Herstellers oder eine Alternative wie pdfplumber (MIT-Lizenz).

Was das in Zahlen bedeutet

Eine Beispielrechnung mit 2.000 Dokumenten im Monat, je zwei Seiten. Die Annahmen sind bewusst einfach gehalten: Eine Seite als Bild entspricht rund 1.600 Token, ein Arbeitsauftrag an das Modell rund 1.000 Token, eine Antwort rund 300 Token. Gerechnet wird mit den Listenpreisen der Anbieter (Stand Oktober 2026, in US-Dollar, ohne Steuern) und nur mit den reinen Modellkosten.

Variante	Aufbau	Modellkosten pro Monat
A: alles per KI, mittleres Modell	Jedes Dokument geht als Bild viermal an Claude Sonnet 5.5 (2 $/10 $ je Mio. Token): erkennen, auslesen, prüfen, zusammenfassen	rund 91 $
B: alles per KI, kleines Modell	Derselbe Ablauf mit Claude Haiku 5.5 (0,10 $/0,50 $ je Mio. Token)	rund 4,60 $
C: orchestriert	Texterkennung lokal, Regeln und Vorlagen zuerst; etwa ein Drittel der Dokumente braucht ein kleines Modell für die Auslese (als Text), jedes zehnte eine Zusammenfassung	unter 1 $
D: orchestriert, Modell lokal	Wie C, aber das kleine Modell läuft auf eigener Hardware (siehe unten)	0 $ für das Modell, dafür Hardware, Strom und Wartung

Zwei Dinge zeigt die Rechnung. Erstens: Schon die Wahl des Modells macht einen Unterschied um den Faktor 20. Zweitens: Die größte Ersparnis bei C kommt nicht nur vom Preis, sondern davon, dass die meisten Schritte gar nicht mehr an ein Modell gehen. Dazu kommen Vorteile, die in der Tabelle nicht stehen: Code-Schritte laufen in Millisekunden, liefern immer dasselbe Ergebnis und rechnen exakt. Und weil die Plattform je nach Anbieter pro Ausführung, Modul oder Schritt abrechnet, sinken mit weniger KI-Schritten oft auch die Plattformkosten, bei Make etwa verbrauchen die eigenen KI-Module von Make mehr Credits als gewöhnliche Module.

Ehrlich gesagt: Bei wenigen hundert Dokumenten im Monat sind die reinen Modellkosten auch bei Variante A überschaubar. Teuer wird es mit dem Volumen, mit großen Modellen als Standard und mit langen Dokumenten. Und wer nur auf die Modellkosten schaut, übersieht die Kosten für Fehler: Eine falsch ausgelesene Summe, die erst in der Buchhaltung auffällt, kostet mehr als jeder Token.

Weitere Hebel gegen steigende Kosten

• Das passende Modell je Aufgabe: kleine Modelle für Routine, große nur für Schwieriges. Ein vorgeschalteter LLM-Router kann das automatisch verteilen.
• Zwischenspeichern (Caching): Wiederkehrende Teile eines Auftrags, etwa lange Anweisungen oder Vorlagen, speichern die Anbieter zwischen. Bei Anthropic kostet das erneute Lesen aus dem Zwischenspeicher nur einen Bruchteil des normalen Eingabepreises, bei OpenAI ebenfalls.
• Stapelverarbeitung (Batch): Was nicht sofort fertig sein muss, etwa die nächtliche Verarbeitung, kostet bei Anthropic, OpenAI und Google über die Batch-Schnittstelle 50 % weniger.
• Weniger Kontext: Nur den Textausschnitt schicken, den das Modell wirklich braucht, und Text statt Bild, wo immer möglich.
• Feste Ausgabeformate: Wenn das Modell ein festes Format liefert, entfallen Nachfragen und Korrekturschleifen.
• Budgetgrenzen und Messung pro Schritt: Nur wer weiß, welcher Schritt wie viel kostet, kann gezielt optimieren. Obergrenzen schützen vor Ausreißern, etwa wenn ein Fehler eine Schleife auslöst.

Mehr zu Kosten und einer Beispielrechnung für den laufenden Betrieb findest du auf unserer Seite Kosten & Tagessätze.

Freie Modelle lokal betreiben

Eine weitere Möglichkeit: Das Sprachmodell läuft gar nicht beim Anbieter, sondern auf eigener Hardware, als lokales Modell. Dann fallen keine Kosten pro Aufruf an, und die Dokumente verlassen das Unternehmen nicht. Gerade für die Schritte aus unserem Beispiel, also Dokumente einordnen und Felder aus Text auslesen, braucht es oft kein großes Modell.

Die Werkzeuge: Am einfachsten ist Ollama (MIT-Lizenz). Es lädt Modelle mit einem Befehl und kann Antworten in ein festes JSON-Format zwingen, sodass Code sie direkt weiterverarbeitet. Darunter arbeitet llama.cpp (MIT). Für einen Server mit vielen gleichzeitigen Anfragen gibt es vLLM (Apache-2.0). LM Studio ist eine Oberfläche zum Ausprobieren; es ist seit Juli 2025 auch beruflich kostenlos, hat aber eigene Nutzungsbedingungen und läuft auf dem Mac nur mit Apple-Chips.

Die Modelle: Mit offenen Gewichten (Open Weights) und freier Lizenz gibt es inzwischen eine gute Auswahl in Größen, die auf einem normalen Arbeitsplatzrechner oder einem kleinen Server laufen, alle mit Apache-2.0- oder MIT-Lizenz und damit auch geschäftlich nutzbar:

• Ministral 3 von Mistral (3, 8 und 14 Milliarden Parameter, Deutsch ausdrücklich unterstützt, mit JSON-Ausgabe),
• Gemma 4 von Google (unter anderem 12 und 31 Milliarden Parameter),
• Qwen3.5 von Alibaba (unter anderem 4, 9 und 27 Milliarden Parameter),
• Granite 4.2 von IBM (3, 8 und 30 Milliarden Parameter, Deutsch unterstützt),
• Phi-4 von Microsoft (14 Milliarden Parameter, MIT),
• gpt-oss-20b von OpenAI, das laut Hersteller mit 16 GB Speicher auskommt.

Ein Blick in die Lizenz lohnt sich trotzdem: Nicht jedes „offene“ Modell ist frei nutzbar. Metas Llama 4 etwa steht unter einer eigenen Lizenz, die für die multimodalen Modelle Unternehmen mit Sitz in der EU ausschließt.

Die Hardware: Als Faustregel braucht ein Modell in der üblichen 4-Bit-Fassung gut ein halbes Gigabyte Speicher je Milliarde Parameter, dazu kommt Platz für den Kontext. Ein 8-Milliarden-Modell belegt in Ollama rund 6 GB, ein 14-Milliarden-Modell rund 9 GB, ein 24-Milliarden-Modell rund 15 GB. Auf älteren Rechnern ohne passenden Grafikprozessor oder Apple-Chip läuft das spürbar langsamer, für einen nächtlichen Stapel reicht es oft trotzdem.

Testen, ob es reicht: Ob ein freies Modell für deine Aufgabe genügt, zeigt nur ein Test mit echten Daten. Bewährt hat sich: 50 bis 100 typische Dokumente auswählen, für jedes die richtigen Werte festhalten und dann Feld für Feld vergleichen, was das lokale Modell und zum Vergleich ein kleines Cloud-Modell liefern. Gemessen werden Trefferquote, Zeit pro Dokument und die Fälle, in denen das Modell unsicher ist. Liegt das lokale Modell gleichauf, ist die Entscheidung einfach. Reicht es nicht, hilft oft ein etwas größeres Modell oder eine bessere Vorbereitung des Textes, bevor man zur Cloud wechselt.

Ehrlich gerechnet: Kostenlos ist auch ein lokales Modell nicht. Hardware, Strom, Einrichtung, Updates und Überwachung kosten Geld und Zeit. Es lohnt sich vor allem bei hohem Volumen, bei sensiblen Daten oder wenn ohnehin passende Hardware vorhanden ist.

Datenschutz und EU AI Act: Für den Datenschutz ist der lokale Betrieb ein echter Vorteil. Die Daten gehen an keinen KI-Anbieter, es gibt keine Auftragsverarbeitung dafür und keine Übermittlung in Drittländer. Die Datenschutzkonferenz der deutschen Aufsichtsbehörden hält in ihrer Orientierungshilfe zu KI fest, dass „technisch geschlossene Systeme“ aus Datenschutzsicht vorzugswürdig sind. Beim EU AI Act dagegen ändert der Ort nichts: Die Pflichten hängen an deiner Rolle und am Einsatzzweck, nicht daran, wo das Modell läuft. Wer ein lokales Modell einsetzt, muss genauso für KI-Kompetenz im Team sorgen, Transparenzpflichten einhalten und bei Hochrisiko-Einsätzen, etwa in der Personalauswahl, die strengen Anforderungen erfüllen. Auch die Ausnahme der Verordnung für Systeme unter freien Lizenzen (Art. 2 Abs. 12) ist kein Freibrief: Sie gilt nicht für Hochrisiko-Systeme und nicht für die Fälle aus Art. 5 und 50, und ob sie für den eigenen betrieblichen Einsatz überhaupt greift, ist nicht abschließend geklärt. Mehr dazu auf unserer Seite EU AI Act.

Fazit

KI ist ein starkes Werkzeug, aber kein Ersatz für saubere Planung. Die günstigste und zuverlässigste Automatisierung ist die, bei der jeder Schritt mit dem passenden Mittel erledigt wird: Regeln und Code für alles, was sich beschreiben lässt, KI für das, was Sprachverständnis braucht, und ein Mensch für die Fälle, in denen etwas unklar ist. So bleiben die Kosten planbar, und die Ergebnisse werden besser.

Ein zweites Praxisbeispiel mit echten Zahlen, KI-Produktbilder per eigener App statt Plattform-Abo, findest du im Artikel KI-Produktbilder: Warum das Abo teurer war als die eigene Lösung. Wie das in der Praxis aussieht, zeigt unser Fallbeispiel Automatisierte Dokumentenverarbeitung für einen Logistikdienstleister, bei dem das Sprachmodell lokal im Unternehmen läuft. Wenn bei dir schon KI-Prozesse oder Automatisierungen laufen und die Kosten steigen, schauen wir sie uns gemeinsam an: Wir analysieren bestehende Abläufe, zeigen, welche Schritte per Code günstiger und zuverlässiger laufen, und setzen die Optimierung auf Wunsch um. Mehr dazu unter KI-Beratung oder direkt im kostenlosen Erstgespräch.

Stand: Oktober 2026. Preise sind Listenpreise der Anbieter laut ihren Preisseiten (Anthropic, OpenAI, Google, Mistral, n8n, Make, Zapier), Lizenzen und Größen laut den Modellkarten und Projektseiten, abgerufen am 10. Oktober 2026; sie ändern sich regelmäßig. Zitat der Datenschutzkonferenz: Orientierungshilfe „Künstliche Intelligenz und Datenschutz“, Version 1.0 vom 6. Mai 2024.