Budget für ein KI-Pilotprojekt planen: Kostenblöcke und Reserve

Ein KI-Pilotprojekt scheitert selten am Budget selbst – es scheitert daran, dass das Budget von Anfang an unvollständig war. Ein Angebot für Konzeption und Entwicklung liegt vor, wirkt seriös kalkuliert, und trotzdem reicht das Geld am Ende nicht. Der Grund ist fast immer derselbe: Das Budget hat nur die Posten erfasst, die eine externe Rechnung ausweist. Interne Zeit, Datenaufbereitung, laufende Modellkosten nach dem ersten Test und eine Reserve für Unvorhergesehenes fehlen – nicht aus Nachlässigkeit, sondern weil sie in keinem Angebot auftauchen und deshalb leicht übersehen werden.

Dieser Artikel gehört zum Themen-Cluster KI-Kosten & ROI und richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die ein KI-Pilotprojekt budgetieren – vor der Ausschreibung, vor dem ersten Angebotsvergleich oder vor der internen Freigabe. Er beantwortet konkret: Welche Budgetblöcke gehören hinein, wie viel Reserve ist sinnvoll, was leistet das eigene Team, wie schätzt man Modellkosten realistisch, und welche Kriterien begrenzen, wann ein Pilot gestoppt wird.

Begriffe und Abgrenzung

Pilotbudget ist die Summe aus allen Kosten, die entstehen, bis eine Entscheidung über Weiterführung, Anpassung oder Abbruch getroffen werden kann – nicht nur der Preis für die technische Umsetzung. Ein Pilot, der nur die Entwicklungskosten budgetiert, ist finanziell nicht vollständig geplant, auch wenn das Angebot dafür sauber ist.

Einmalige Kosten entstehen einmalig bis zum Go-live: Konzeption, Entwicklung, Integration, Datenaufbereitung, Tests. Laufende Kosten entstehen wiederkehrend während und nach dem Piloten: Modell- und API-Nutzung, Lizenzen, Hosting, Wartung. Interne Kosten sind die Arbeitszeit der eigenen Mitarbeitenden – sie werden selten in Euro budgetiert, sind aber ökonomisch genauso real wie eine externe Rechnung.

Wichtig ist die Abgrenzung zum ausgereiften Projekt: Ein Pilot ist zeitlich und im Umfang begrenzt und hat ein definiertes Ende mit Entscheidung. Sein Budget muss deshalb nicht die Kosten eines Rollouts über das ganze Unternehmen abdecken – aber es muss vollständig genug sein, um am Ende eine belastbare Entscheidung zu ermöglichen, statt aus Geldmangel vorzeitig abgebrochen zu werden.

Welche Budgetblöcke gehören hinein?

Ein realistisches Pilotbudget deckt vier Blöcke: einmalige Umsetzungskosten, laufende Kosten, interne Zeit und eine Reserve. Die folgende Vorlage zeigt typische Posten je Block – als Startpunkt für die eigene Kalkulation, nicht als fertige Zahl, weil Umfang, Integrationstiefe und Anbieterwahl von Fall zu Fall stark variieren.

Eigene Budget-Vorlage Philogic Labs für ein abgegrenztes KI-Pilotprojekt in einem KMU. Die Bandbreiten sind grobe Orientierungswerte aus Projekterfahrung, keine Zusage – die tatsächlichen Kosten hängen von Scope, Datenlage und Integrationstiefe ab.

Kostenblock	Typische Posten	Wer budgetiert es meist?	Häufigster Fehler
Einmalig – Konzeption	Anforderungsklärung, Prozessanalyse, Use-Case-Definition	Externer Dienstleister oder intern	Wird oft übersprungen, um „schneller” zum Prototyp zu kommen
Einmalig – Entwicklung/Integration	Aufbau der Lösung, Anbindung an bestehende Systeme, Tests	Externer Dienstleister, meist als Angebot	Integrationsaufwand in gewachsene Systeme wird unterschätzt
Einmalig – Datenaufbereitung	Sichtung, Bereinigung, Strukturierung von Daten für den Piloten	Intern, teils extern unterstützt	Fehlt im Angebot komplett, taucht erst während des Projekts auf
Laufend – Modell-/API-Nutzung	Kosten pro Anfrage oder Token, abhängig vom Volumen	Meist gar nicht vorab budgetiert	Wird erst nach dem ersten Testmonat sichtbar
Laufend – Lizenzen/Hosting	Plattform- oder Tool-Abonnements, Serverkosten	Extern vorgegeben, meist bekannt	Kalkuliert für den Piloten, nicht für den späteren Betrieb
Intern – Fachbereich	Anforderungsklärung, Testdaten, Abnahme, Testnutzung	Fast nie in Euro budgetiert	Zeitaufwand wird „nebenbei” eingeplant, verzögert den Piloten
Intern – IT/Datenschutz	Anbindung, Zugriffsrechte, Prüfung von Anbieter und Auftragsverarbeitung	Fast nie in Euro budgetiert	Wird erst kurz vor Go-live einbezogen
Reserve	Puffer für Unvorhergesehenes (siehe nächster Abschnitt)	Selten überhaupt vorgesehen	Kein Puffer eingeplant, Pilot wird bei erster Abweichung gestoppt

Die Grundregel: Jede Zeile, die aktuell mit „macht die IT/der Fachbereich schon nebenbei” beantwortet wird, gehört trotzdem ins Budget – notfalls mit einem geschätzten Zeitwert statt einer Euro-Zahl. Sonst fehlt sie in der Entscheidung, ob der Pilot sich gelohnt hat.

Wie viel Reserve ist sinnvoll?

Eine belastbare pauschale Prozentzahl für die Reserve gibt es nicht – zu unterschiedlich sind Ausgangslage, Datenqualität und Integrationstiefe von Projekt zu Projekt. Was sich aus meiner Projekterfahrung sagen lässt: Bei einem eng abgegrenzten Piloten auf Basis bestehender Modelle, mit vorhandenen digitalen Daten und ohne tiefe Systemintegration, ist eine Reserve von etwa 15 bis 25 Prozent des kalkulierten Budgets eine realistische Orientierung. Bei unklarer Datenlage, geplanter Anbindung an gewachsene Bestandssysteme oder wenn der Use Case zum ersten Mal im Unternehmen umgesetzt wird, ist eher der obere Rand oder mehr angemessen.

Die Bitkom-Erhebung von Anfang 2026 unterstreicht, warum eine Reserve überhaupt sinnvoll ist: 33 Prozent der KI-nutzenden Unternehmen berichten, dass die tatsächlichen Kosten deutlich höher ausfielen als zuvor erwartet. Das ist kein Kalkulationsfehler Einzelner, sondern ein wiederkehrendes Muster – und genau dafür ist eine eingeplante Reserve da, statt eine Nachforderung zur Überraschung werden zu lassen.

Wichtig ist, wofür die Reserve nicht gedacht ist: für einen größeren Scope „weil es gerade so gut läuft”. Eine Reserve, die während des Piloten stillschweigend in zusätzlichen Funktionsumfang fließt, ist keine Reserve mehr, sondern ein Scope-Zuwachs ohne eigene Freigabe. Wird sie gebraucht, sollte klar sein, wofür – und wenn sie am Ende nicht gebraucht wird, ist das ein gutes Zeichen für die Kalkulation, kein Grund, sie trotzdem auszugeben.

Was wird intern erbracht?

Der am häufigsten unterschätzte Budgetblock ist nicht die Modellnutzung, sondern die eigene Arbeitszeit. Typischerweise fällt intern an:

• Anforderungsklärung, bevor überhaupt entwickelt wird – wer diesen Schritt an einen externen Dienstleister komplett delegiert, bekommt oft eine Lösung, die technisch funktioniert, aber am tatsächlichen Prozess vorbeigeht.
• Bereitstellung und Prüfung von Testdaten – jemand aus dem Fachbereich muss wissen, wo die relevanten Daten liegen, und beurteilen können, ob eine KI-Ausgabe auf dieser Basis plausibel ist.
• Testnutzung und Feedback während der Pilotphase – ohne echte Nutzung durch die Menschen, die den Prozess kennen, misst du am Ende nicht, ob die Lösung im Alltag funktioniert, sondern nur, ob eine Demo funktioniert.
• Abnahme von Zwischenständen – kurze, aber wiederkehrende Termine, in denen Ergebnisse bewertet und Richtung korrigiert wird.
• IT-seitige Anbindung – Zugriffsrechte, Schnittstellen, Prüfung von Anbieter und Auftragsverarbeitung nach DSGVO.

Diese Posten in Euro zu beziffern ist unüblich, aber sinnvoll – zumindest als grober Zeitwert mit internem Stundensatz. Sonst entsteht der Eindruck, ein Pilot koste „nur” die externe Rechnung, während in Wahrheit ein erheblicher Teil des Gesamtaufwands intern anfällt. Das ist auch der Grund, warum ein Pilot ohne benannten, mit realem Zeitbudget ausgestatteten Owner im Fachbereich strukturell gefährdet ist: Die interne Zeit ist eingeplant, aber niemand hat sie tatsächlich frei.

Wie schätzt man Modellkosten?

Modell- und API-Kosten sind der Budgetposten, der sich vorab am schlechtesten seriös beziffern lässt – und genau deshalb der, bei dem am häufigsten mit erfundenen Pauschalzahlen gearbeitet wird. Die tatsächlichen Kosten hängen von drei Faktoren ab: dem Nutzungsvolumen (wie viele Anfragen, wie viele Vorgänge pro Tag oder Monat), der Größe und Komplexität des verwendeten Modells sowie der Länge von Ein- und Ausgaben pro Anfrage.

Der belastbarste Weg, diese Kosten zu schätzen, ist kein Rechenmodell auf Basis von Preislisten allein, sondern ein kurzer, realistisch dimensionierter Testzeitraum: eine begrenzte Zahl echter Vorgänge durch das System laufen lassen und die tatsächlich abgerechneten Kosten pro Vorgang beobachten. Daraus lässt sich das erwartete Volumen hochrechnen – deutlich zuverlässiger als eine Schätzung, die nur auf dem offiziellen Preis pro Token basiert und die tatsächliche Nutzungslänge im eigenen Anwendungsfall ignoriert.

Zwei Praxishinweise dazu: Erstens variieren die Kosten je nach Aufgabentyp stark – ein kurzer Klassifikationsschritt kostet pro Vorgang etwas völlig anderes als ein langer, dokumentbasierter Zusammenfassungs-Workflow. Zweitens ändern Anbieter ihre Preise und Modellgenerationen häufiger, als viele Budgetplanungen berücksichtigen; ein Modellkostenposten, der einmal geschätzt und dann für die gesamte Projektlaufzeit fortgeschrieben wird, ist selten noch aktuell, wenn der Pilot in Produktion geht.

Welche Exit-Kriterien begrenzen Kosten?

Ein Budget ohne Exit-Kriterien ist offen nach oben – nicht weil jemand bewusst überzieht, sondern weil ohne definierten Stopppunkt niemand den formalen Anlass hat, ein laufendes Projekt anzuhalten. Sinnvolle Exit-Kriterien werden vor Projektstart festgelegt und typischerweise an drei Größen festgemacht:

• Kostendeckel: ein absoluter Euro-Betrag, bei dessen Überschreitung eine explizite Neuentscheidung fällig ist – nicht automatischer Abbruch, aber automatischer Prüfpunkt.
• Zeitgrenze: ein Zeitpunkt, zu dem ein belastbares Zwischenergebnis vorliegen muss. Kein Ergebnis zu diesem Termin ist selbst ein Ergebnis und ein Anlass zur Entscheidung.
• Qualitätsschwelle: eine vorab definierte Mindestqualität (etwa Fehlerquote oder Nutzerakzeptanz), unterhalb derer der Pilot gestoppt oder grundlegend angepasst wird, statt mit sinkender Erwartung weiterzulaufen.

Diese Kriterien gehören ins Budget, weil sie es begrenzen: Ein Pilot mit klarem Kostendeckel und klarer Zeitgrenze kann realistisch kalkuliert werden, weil das Worst-Case-Szenario bekannt ist. Ein Pilot ohne diese Grenzen hat kein Budget, sondern eine Absichtserklärung – die Kosten laufen so lange weiter, wie niemand aktiv „Stopp” sagt, und genau das passiert in der Praxis selten von allein.

Umsetzung: So kommst du zur Budgetzahl

Praktisch empfiehlt sich diese Reihenfolge, statt direkt eine Gesamtsumme zu schätzen:

1. Scope eng fassen. Ein Prozess, ein Team, ein klar formulierter Use Case – je enger der Scope, desto verlässlicher die Kostenschätzung in jedem Block.
2. Alle acht Zeilen der Budget-Vorlage durchgehen, auch die, die „eigentlich klar” sind. Für jede Zeile: gibt es eine Zahl, eine Bandbreite oder zumindest einen benannten Verantwortlichen, der sie noch schätzen muss?
3. Interne Zeit mit Stundensatz bewerten, auch wenn sie nicht extern abgerechnet wird – sonst fehlt sie in der Gesamtsicht.
4. Modellkosten über einen kurzen Testzeitraum ermitteln, nicht nur über Preislisten.
5. Reserve festlegen – 15 bis 25 Prozent als Orientierung bei überschaubarem Scope, mehr bei Unsicherheit in Daten oder Integration.
6. Exit-Kriterien schriftlich fixieren, bevor das Budget final freigegeben wird – nicht danach.
7. Verantwortlichkeit pro Budgetzeile benennen. Eine Zahl ohne Verantwortlichen bleibt in der Praxis meist Schätzung statt Steuerungsgröße.

Wer diese sieben Schritte durchläuft, hat am Ende kein perfektes Budget – das gibt es bei einem Piloten grundsätzlich nicht –, aber ein vollständiges: eines, das alle vier Kostenblöcke enthält und bei Abweichungen eine begründete Entscheidung statt einer bösen Überraschung ermöglicht.

Risiken & Grenzen

Ein sorgfältig geplantes Budget löst nicht jedes Problem. Ein paar ehrliche Einschränkungen:

• Kein Budget verhindert einen falschen Use Case. Wenn der gewählte Prozess für KI ungeeignet ist – etwa weil die Datenbasis fehlt oder deterministische Korrektheit gefordert ist –, hilft die beste Kalkulation nichts. Die Budgetplanung setzt einen sinnvoll gewählten Piloten voraus, sie ersetzt die Use-Case-Auswahl nicht.
• Modellkosten bleiben eine Schätzung, keine Garantie. Anbieterpreise und Nutzungsmuster ändern sich; ein einmal ermittelter Kostenwert pro Vorgang ist eine Momentaufnahme.
• Interne Zeit lässt sich schwer exakt beziffern. Ein Stundensatz für internes Zeitbudget ist eine Annäherung, keine buchhalterisch exakte Zahl – reicht aber, um die Größenordnung sichtbar zu machen.
• Garantierte Einsparungen oder Amortisationszeiten gibt es nicht. Wer sie verspricht, hat entweder ein Standardprodukt kalkuliert, das nicht auf deinen Fall passt, oder rechnet mit unbelastbaren Annahmen. Die Bitkom-Zahl, dass ein Drittel der Unternehmen von unerwartet höheren Kosten berichtet, zeigt, wie oft genau diese Erwartung enttäuscht wird.
• Datenschutzrechtliche und vertragliche Prüfung ersetzt dieses Budget-Template nicht. Auftragsverarbeitung, Lizenzbedingungen und AI-Act-Pflichten gehören vor Projektstart geklärt (Stand Juli 2026, keine Rechtsberatung) – unabhängig davon, wie gut das Budget kalkuliert ist.

Und eine Grenze dieses Artikels selbst: Er liefert ein Gerüst und Orientierungswerte, kein fertiges Zahlenwerk für dein konkretes Projekt. Wie hoch dein Pilotbudget tatsächlich ausfallen sollte, hängt an Scope, Datenlage, Systemlandschaft und Zielsetzung – das lässt sich nur am konkreten Fall seriös schätzen. Wenn du diese Einschätzung extern absichern willst: Unser Beratungsangebot mit Budget-, Scope- und ROI-Bewertung findest du auf der Startseite, und ein kostenloses Erstgespräch klärt in 45 Minuten den Rahmen. Wer die Grundkompetenz für solche Einschätzungen intern aufbauen will, findet dazu unser Angebot an Schulungen.

Checkliste: Budget für das KI-Pilotprojekt

1. Der Scope ist eng gefasst: ein Prozess, ein Team, ein klar formulierter Use Case.
2. Einmalige Kosten für Konzeption, Entwicklung, Integration und Datenaufbereitung sind separat aufgeführt.
3. Laufende Kosten für Modellnutzung, Lizenzen und Hosting sind eingeplant – auch über den Piloten hinaus.
4. Interne Zeit von Fachbereich und IT ist mit einem Stundensatz oder zumindest einer Zeitschätzung beziffert.
5. Modellkosten wurden über einen kurzen Testzeitraum ermittelt, nicht nur aus Preislisten geschätzt.
6. Eine Reserve von grob 15 bis 25 Prozent (mehr bei Unsicherheit) ist eingeplant und ihr Verwendungszweck klar begrenzt.
7. Ein Kostendeckel, eine Zeitgrenze und eine Qualitätsschwelle als Exit-Kriterien sind vor Projektstart schriftlich fixiert.
8. Jede Budgetzeile hat eine benannte verantwortliche Person.
9. Datenschutz- und Vertragsprüfung (Auftragsverarbeitung, Lizenzbedingungen) sind Teil der Planung, nicht ein Nachgedanke.
10. Das Budget wurde mit der Person durchgesprochen, die am Ende die Stopp-oder-Weiter-Entscheidung trifft.

Wie du die Rentabilität nach dem Piloten belastbar bewertest und welche Kostenarten in laufenden Projekten am häufigsten übersehen werden, vertiefen weitere Artikel im Themen-Cluster KI-Kosten & ROI.