KI Pilotprojekt wirtschaftlich bewerten in 12 Wochen

Ein KI-POC, der eine Demo erzeugt, ist noch keine Investition, die sich rechnet. Wer ein KI Pilotprojekt wirtschaftlich bewerten will, muss vor dem ersten Sprint entscheiden, welcher messbare Geschäftseffekt entstehen soll, wer ihn verantwortet und wann das Vorhaben gestoppt wird. Andernfalls entstehen hohe Cloud-, Entwicklungs- und Abstimmungskosten für einen Prototypen, den niemand in den operativen Prozess übernimmt.

Das Problem ist selten das Modell. Es sind fehlende Ausgangswerte, unklare Produktverantwortung und eine Bewertung, die sich auf technische Kennzahlen beschränkt. Eine Trefferquote von 92 Prozent ist betriebswirtschaftlich wertlos, wenn Mitarbeitende die Ergebnisse nicht nutzen, die Bearbeitungszeit nicht sinkt oder Risiken im Freigabeprozess den Rollout verhindern.

Das Pilotprojekt beginnt nicht mit dem Use Case

Viele Teams starten mit der Frage: Was kann Generative AI für uns tun? Die bessere Frage lautet: Welcher Engpass belastet Umsatz, Marge, Risiko oder operative Kapazität spürbar genug, dass eine Lösung Priorität verdient?

Ein brauchbarer KI-Use-Case hat drei Eigenschaften. Erstens ist der Prozess heute messbar. Zweitens kann ein Team die neue Lösung in seinen Arbeitsalltag integrieren. Drittens liegt der wirtschaftliche Nutzen im Einflussbereich eines verantwortlichen Bereichsleiters. Fehlt eine dieser Bedingungen, wird aus dem Pilotprojekt schnell Forschung auf Kosten des Tagesgeschäfts.

Nehmen wir einen Supportprozess mit hohem Anfragevolumen. Ein Assistent kann Antworten vorschlagen, Fälle klassifizieren oder Informationen aus Verträgen extrahieren. Entscheidend ist aber nicht, ob das Large Language Model überzeugend formuliert. Entscheidend ist, ob sich die durchschnittliche Bearbeitungszeit pro Fall reduziert, die Erstlösungsquote steigt oder weniger Vorgänge an teure Fachexperten eskaliert werden.

Diese Logik gilt ebenso für Vertrieb, Recruiting, Einkauf, Softwareentwicklung und Compliance. KI ist kein isoliertes Feature. Sie verändert einen Prozess, eine Rollenverteilung und oft auch ein Risikoprofil. Genau dort liegt der Business Case.

KI Pilotprojekt wirtschaftlich bewerten: Die Baseline zuerst

Ohne Baseline ist jede Nutzenrechnung Wunschdenken. Erheben Sie vor dem Bau die aktuelle Leistung des Prozesses über einen ausreichend großen Zeitraum. Bei saisonalen Schwankungen reichen zwei gute Wochen nicht. Bei seltenen, aber kritischen Vorgängen ist eine qualitative Prüfung zusätzlich nötig.

Die Baseline sollte mindestens Volumen, Bearbeitungszeit, Vollkosten, Fehler- oder Eskalationsquote und relevante Qualitätsindikatoren enthalten. Ergänzen Sie eine klare Definition, was als erfolgreicher Vorgang zählt. Sonst verbessert das Team später genau die Kennzahl, die am leichtesten zu beeinflussen ist, nicht diejenige mit wirtschaftlicher Relevanz.

Für die Rechnung braucht es vier Größen:

• Bruttonutzen: eingesparte Arbeitszeit, vermiedene Fehlerkosten, zusätzlicher Umsatz oder geringeres Risiko.
• Realisierungsgrad: der Anteil dieses Potenzials, der tatsächlich gehoben wird, nachdem Adoption, Ausnahmen und Freigaben berücksichtigt sind.
• Einmalinvestition: Produktführung, Fachkonzeption, Entwicklung, Datenaufbereitung, Security-Prüfung, Integration und Change-Aufwand.
• Laufende Kosten: Modellnutzung, Infrastruktur, Monitoring, Qualitätssicherung, Support und Weiterentwicklung.

Die Formel ist einfach: Nettoeffekt pro Jahr = Bruttonutzen mal Realisierungsgrad minus laufende Kosten. Der Payback ergibt sich aus Einmalinvestition geteilt durch monatlichen Nettoeffekt. Die Qualität der Entscheidung hängt jedoch an den Annahmen, nicht an der Formel.

Ein Beispiel: Ein Team bearbeitet 30.000 Standardanfragen pro Jahr. Jede Anfrage bindet im Schnitt acht Minuten. Vollkosten von 42 Euro pro Stunde ergeben einen theoretischen Aufwand von 168.000 Euro. Der Assistent spart im Test fünf Minuten bei 60 Prozent der Fälle. Das theoretische Potenzial liegt bei 63.000 Euro. Wenn wegen Kontrollaufwand, Urlaubsvertretungen und unvollständiger Nutzung nur 55 Prozent realisiert werden, bleiben rund 34.650 Euro. Davon gehen jährliche Betriebs- und Qualitätskosten ab. Erst dann ist sichtbar, ob sich eine Integration für 80.000 Euro in einem akzeptablen Zeitraum amortisiert oder ob der Scope kleiner werden muss.

Diese Rechnung schützt vor zwei Fehlern: künstlich aufgeblähten Einsparungen und dem reflexhaften Abbruch eines Vorhabens, das erst bei höherem Volumen wirtschaftlich wird.

Technische Qualität ist ein Gate, kein Business Case

Modellgüte, Antwortzeit und Kosten pro Anfrage sind zentrale Steuerungsgrößen. Sie ersetzen aber keine wirtschaftliche Bewertung. Ein günstiges Modell mit schlechter Antwortqualität erzeugt Nacharbeit. Ein sehr präzises Modell mit hohen Latenzen wird im Tagesgeschäft umgangen. Und ein Modell, das sensible Daten verarbeitet, kann ohne klare Zugriffs- und Governance-Architektur überhaupt nicht produktiv gehen.

Definieren Sie deshalb vor dem Start verbindliche Delivery-Gates. Nach vier Wochen sollte ein belastbarer Prototyp auf echten, bereinigten Beispieldaten zeigen, ob die Qualitätsuntergrenze erreichbar ist. Nach acht Wochen muss eine integrierte Teststrecke vorliegen: Rollen, Berechtigungen, Logging, Feedbackschleife und ein definierter Umgang mit fehlerhaften Antworten. Nach zwölf Wochen fällt eine Produktionsentscheidung auf Basis gemessener Nutzung und realer Prozesswirkung.

Für produktive Systeme gehören Kostenkontrolle und Betrieb in den Scope. Dazu zählen etwa Token-Budgets, Caching, Retrieval-Qualität, Prompt- und Modellversionierung, Monitoring von Fehlerraten sowie ein klarer Fallback in den bisherigen Prozess. Bei Anwendungen auf AWS, Kubernetes oder in bestehender SaaS-Architektur ist die Integration kein nachgelagerter Technikpunkt. Sie bestimmt maßgeblich die Gesamtkosten und die Zeit bis zur Wertschöpfung.

Nutzen entsteht nur bei echter Adoption

Die größte Differenz zwischen Business Case und Ergebnis entsteht häufig nicht im Modell, sondern beim Verhalten der Nutzer. Wenn Mitarbeitende die KI als zusätzliche Oberfläche wahrnehmen, entsteht Parallelbetrieb statt Entlastung. Wenn sie Ergebnissen blind vertrauen, steigt das Risiko. Wenn sie jede Antwort vollständig prüfen müssen, verschwindet der Effizienzgewinn.

Deshalb braucht ein Pilotprojekt einen klar abgegrenzten Nutzerkreis, einen Prozessowner und messbare Nutzungsziele. Nicht Anzahl der Logins, sondern Anteil der Vorgänge, die mit der Lösung bearbeitet werden, Zeitersparnis je Vorgang und Korrekturquote sind relevant. Ergänzen Sie kurze, verpflichtende Feedbackschleifen direkt im Workflow. So wird aus Einzelfeedback eine priorisierte Produktentscheidung.

Es kommt auf den Anwendungsfall an, wie viel Automatisierung sinnvoll ist. Bei internen Wissensfragen kann ein Assistent mit Quellenhinweisen früh produktiv sein. Bei Vertragsfreigaben, Bewerbervorauswahl oder regulatorischen Entscheidungen bleibt der Mensch zunächst in der Freigabe. Das reduziert zwar den kurzfristigen Automatisierungsgrad, kann aber den schnelleren und risikoärmeren Weg zur Produktion bedeuten.

Nicht den ROI schätzen, sondern die Entscheidung absichern

Ein Business Case ist keine Zusage des Teams, einen bestimmten ROI zu liefern. Er ist eine Hypothese mit transparenten Annahmen. Gute Führung macht diese Annahmen prüfbar und beendet Vorhaben, wenn die Fakten dagegen sprechen.

Dokumentieren Sie deshalb für jede Kennzahl eine Quelle, einen Messzeitraum, einen Verantwortlichen und eine Zielschwelle. Legen Sie außerdem fest, welche Erkenntnis zum Stopp führt: etwa eine Qualitätsquote unter dem Minimum, fehlender Datenzugang, eine nicht tragfähige Integrationsarchitektur oder eine Adoption, die trotz Prozessanpassung ausbleibt. Das ist kein Scheitern. Es verhindert, dass Budget monatelang an einen POC ohne Produktionsperspektive gebunden wird.

Umgekehrt darf ein Pilot nicht an zu engen Erwartungen sterben. Manche KI-Initiativen liefern ihren größten Wert erst, wenn Datenquellen konsolidiert, Prozesse standardisiert oder mehrere Teams angeschlossen sind. Dann sollte die erste Phase bewusst auf das wirtschaftlich kleinste tragfähige Produkt zielen. Beweisen Sie Wirkung in einem Prozess, bevor Sie Plattformansprüche finanzieren.

Bei xB Technologies wird diese Entscheidung nicht mit einer Abschlussfolie getroffen, sondern über eine steuerbare Delivery-Strecke: priorisierter Use Case, belastbare Baseline, produktionsfähige Architektur, messbare Nutzung und eine klare Go-, Scale- oder Stop-Entscheidung. Verantwortung endet nicht beim Workshop.

Der richtige nächste Schritt ist daher kein weiterer Ideation-Termin. Nehmen Sie den teuersten oder langsamsten Prozess mit ausreichend Daten, benennen Sie einen Owner und rechnen Sie die Wirkung konservativ durch. Wenn das Pilotprojekt dann in zwölf Wochen keine belastbare Entscheidung ermöglicht, war sein Scope zu groß, seine Verantwortung zu diffus oder sein Nutzen nie klar genug definiert.