KI im Unternehmen einführen: Vom Pilot in den Betrieb.

Ein KI-Pilot ist schnell gebaut. Ein paar Wochen, eine motivierte Gruppe, ein Modell, das beeindruckende Antworten liefert, und eine Abschlusspräsentation mit zufriedenen Gesichtern. Dann passiert: nichts. Der Pilot läuft aus, die Lizenzen werden verlängert oder auch nicht, und ein halbes Jahr später beginnt der nächste. Das Problem ist selten die Technik. Es fehlt, was einen Versuch von einem Betrieb unterscheidet: ein Verantwortlicher, eine Messgröße, ein Budget für den laufenden Betrieb und Menschen, die ihre Arbeit tatsächlich anders machen. Dieser Beitrag geht die Entscheidungen durch, die zwischen Pilot und Betrieb liegen.

Pilot und Betrieb sind zwei verschiedene Projekte

Ein Pilot beantwortet die Frage: Kann das funktionieren? Der Betrieb beantwortet eine andere: Funktioniert es jeden Tag, für alle, zu vertretbaren Kosten, und merkt jemand, wenn nicht? Wer beides mit demselben Plan angeht, unterschätzt den zweiten Teil regelmäßig. Der größere Aufwand steckt erfahrungsgemäß nach dem Pilot: Anbindung an die echten Systeme, Berechtigungen, Fehlerbehandlung, Schulung, Support.

Deshalb gehört die Entscheidung über den Betrieb an den Anfang des Piloten, nicht an sein Ende. Vier Dinge sollten feststehen, bevor die erste Zeile konfiguriert wird:

• Ein Prozess, kein Werkzeug. „Wir testen Copilot“ ist kein Pilot. „Wir verkürzen die Prüfung von Eingangsrechnungen“ ist einer. Der Pilot hat einen Prozess, einen Prozessverantwortlichen und eine Ausgangslage in Zahlen.
• Ein Abbruchkriterium. Was muss am Ende erreicht sein, damit es weitergeht, und bei welchem Ergebnis hört man auf? Ein Pilot ohne Abbruchkriterium endet nie, er schläft ein.
• Ein Betriebsverantwortlicher. Wer kümmert sich, wenn das Modell nach einem Update anders antwortet, eine Schnittstelle bricht oder die Kosten steigen? Wird diese Person erst nach dem Pilot gesucht, wird sie meist nicht gefunden.
• Ein Betriebsbudget. Laufende Kosten für Lizenzen oder Nutzung, für Wartung und für Weiterentwicklung. Wer nur das Pilotbudget freigibt, hat den Betrieb nicht beschlossen.

Was im Betrieb anders ist

KI-Systeme verhalten sich nicht wie klassische Software. Dieselbe Frage kann zwei unterschiedliche Antworten erzeugen, und ein Modellwechsel beim Anbieter kann das Verhalten über Nacht ändern. Daraus folgen drei Pflichten, die im Pilot niemand vermisst: ein Satz von Testfällen mit bekannten richtigen Ergebnissen, gegen den jede neue Modellversion geprüft wird. Eine Stichprobenkontrolle im laufenden Betrieb, bei der Fachleute regelmäßig Ergebnisse gegenprüfen. Und ein definierter Rückfallweg: Was tun die Mitarbeitenden, wenn das System nicht verfügbar ist oder offensichtlich falsch liegt?

Anwendungsfälle, die sich rechnen

Die besten Anwendungsfälle sind selten die spektakulärsten. Sie haben drei Eigenschaften gemeinsam: hohes Volumen, klare Struktur und ein Mensch, der das Ergebnis ohnehin prüft. Dort spart KI Zeit, ohne dass Fehler unbemerkt durchrutschen. Beispiele aus Branchen, in denen DIGITALFEX arbeitet:

• Eingangsrechnungen und Belege. Erkennen, zuordnen, kontieren, Abweichungen zur Bestellung markieren. Hohe Stückzahl, klares Richtig und Falsch, und die Freigabe bleibt beim Menschen.
• Verträge und Bescheide auswerten. Fristen, Auflagen, Kündigungsrechte und Indexierungen aus Mietverträgen, Werkverträgen oder behördlichen Bescheiden ziehen und in eine Liste überführen, die jemand verantwortet. Der Bescheidwisser ist aus genau diesem Anwendungsfall entstanden.
• Mails und Dokumente ablegen. In projektgetriebenen Unternehmen liegt ein großer Teil der Projektkommunikation in persönlichen Postfächern. Mails dem richtigen Projekt zuzuordnen, ist eine Aufgabe, die Menschen ungern erledigen und KI zuverlässig vorbereitet. Daraus ist Mailzeit! entstanden.
• Wissen auffindbar machen. Fragen an Projekthandbücher, Richtlinien, Protokolle und technische Dokumentation stellen, mit Quellenangabe. Das funktioniert nur so gut wie die Ablage dahinter, und genau das ist oft die eigentliche Erkenntnis des Projekts.
• Berichte vorbereiten. Kommentare zu Abweichungen im Controlling-Bericht, Zusammenfassungen von Baustellenberichten, Entwürfe für Protokolle. Niemand schreibt mehr von null, sondern redigiert.

Schwächer sind Anwendungsfälle, bei denen niemand das Ergebnis prüft, bei denen ein Fehler teuer ist und selten auffällt, oder bei denen das Volumen so klein ist, dass sich die Einrichtung nie amortisiert. Ein Chatbot, der Kunden verbindliche Auskünfte gibt, fällt oft in die erste Kategorie. Eine KI-gestützte Auswertung, die zweimal im Jahr gebraucht wird, in die letzte.

Wenn ein Anwendungsfall vorgeschlagen wird, lohnt der Blick auf die Begründung:

Eigene Modelle oder Herstellerplattform?

Diese Frage taucht in fast jedem Strategiegespräch auf, meist als Gegensatz formuliert: Entweder man begibt sich in die Hände eines großen Anbieters, oder man betreibt eigene Modelle und bleibt unabhängig. In der Praxis ist es selten ein Entweder-oder.

Herstellerplattformen wie Microsoft 365 Copilot, Azure, Google oder die Dienste der großen Modellanbieter liefern die leistungsfähigsten Modelle, Betrieb ohne eigene Infrastruktur und schnellen Zugang zu neuen Versionen. Mit Datenverarbeitung in der EU und vertraglichen Zusagen zur Datennutzung sind sie für viele Unternehmen gut handhabbar. Der Preis ist Abhängigkeit: von Preismodellen, die sich ändern, von Modellversionen, die abgekündigt werden, und von Funktionen, die nur im eigenen Ökosystem laufen.

Offene Modelle, die sich auf eigener Hardware oder bei einem europäischen Hoster betreiben lassen, haben stark aufgeholt. Für eng umrissene Aufgaben wie Klassifizieren, Extrahieren oder Zusammenfassen reichen sie häufig aus. Ihr Vorteil: volle Kontrolle über Daten, Version und Kosten. Ihr Nachteil wird gern unterschätzt: Jemand muss sie betreiben, aktualisieren, absichern und überwachen. Für ein mittelständisches Unternehmen ohne eigenes Team dafür ist ein lokales Modell oft keine Unabhängigkeit, sondern eine neue Abhängigkeit, nämlich von der einen Person oder dem einen Dienstleister, der es versteht.

Wo die Abhängigkeit wirklich entsteht

Selten im Modell. Modelle lassen sich austauschen, wenn die Anwendung sauber gebaut ist. Die Abhängigkeit entsteht in der Integration: in Abläufen, die tief in eine Plattform eingebaut sind, in Daten, die nur dort indexiert sind, und in Arbeitsweisen, die sich an eine Oberfläche gewöhnt haben. Drei Regeln halten den Ausstieg offen:

• Eigene Daten bleiben in eigenen Systemen. Die KI greift darauf zu, aber die maßgebliche Kopie liegt nicht in einer Plattform, aus der man sie nur mühsam wieder herausbekommt.
• Zwischen Anwendung und Modell gehört eine Schicht, die den Anbieter austauschbar macht. Bei eigenen Lösungen ist das eine Frage der Architektur, nicht des Budgets.
• Die Testfälle gehören Ihnen. Wer einen Satz eigener Prüffälle hat, kann jedes neue Modell in Stunden bewerten und muss keinem Marketingversprechen glauben.

Eine pragmatische Faustregel: Standardarbeit in Office und Kommunikation auf der Plattform, die ohnehin im Haus ist. Kernprozesse mit sensiblen Daten oder hohem Volumen so bauen, dass das Modell austauschbar bleibt. Eigene Modelle erst dann, wenn Datenschutz, Kosten bei hohem Volumen oder eine sehr spezifische Aufgabe es verlangen, und wenn feststeht, wer sie betreibt.

Befähigung: Die Technik ist der kleinere Teil

Die häufigste Ursache für gescheiterte KI-Einführungen ist nicht ein schwaches Modell, sondern eine unveränderte Arbeitsweise. Lizenzen werden verteilt, eine Schulung zum Thema Prompts gehalten, und nach drei Monaten nutzt ein kleiner Kreis das Werkzeug intensiv, der Rest gelegentlich oder gar nicht. Das ist kein Versagen der Mitarbeitenden. Es ist das erwartbare Ergebnis, wenn niemand zeigt, wofür das Werkzeug in der eigenen Arbeit taugt. Was in der Praxis wirkt:

• Schulung nach Rolle, nicht nach Werkzeug. Die Buchhaltung braucht andere Beispiele als die Projektleitung. Eine Stunde mit drei Aufgaben aus dem eigenen Alltag bringt mehr als ein halber Tag allgemeine Einführung.
• Multiplikatoren in jedem Bereich. Eine Person pro Team, die etwas mehr Zeit bekommt, Anwendungen ausprobiert, Kollegen hilft und Rückmeldungen sammelt. Ohne diese Zeit im Kalender bleibt es beim guten Willen.
• Klare Regeln, was erlaubt ist. Welche Daten dürfen in welches Werkzeug, was muss geprüft werden, wer verantwortet das Ergebnis. Fehlen Regeln, weichen Mitarbeitende auf private Konten aus, und das Unternehmen weiß nicht mehr, wo seine Daten landen.
• Führung, die es selbst nutzt. Wenn die Geschäftsführung ihre Unterlagen weiterhin von Hand zusammenfasst, versteht jeder, wie ernst das Thema gemeint ist.
• Offen über Arbeitsplätze reden. Die Sorge ist da, ob sie ausgesprochen wird oder nicht. Wer klar sagt, welche Aufgaben sich verändern und wofür die gewonnene Zeit gedacht ist, nimmt ihr die Spitze. Den Betriebsrat früh einzubinden, spart Zeit und Misstrauen.

Seit Februar 2025 verlangt die EU-KI-Verordnung zudem, dass Unternehmen für ausreichende KI-Kompetenz der Mitarbeitenden sorgen, die mit KI-Systemen arbeiten. Das ist kein Grund für Pflichtschulungen von der Stange, aber ein guter Anlass, Befähigung als festen Teil der Einführung zu planen und zu dokumentieren.

Ergebnisse und Kosten messen

Nutzungszahlen sind keine Ergebnisse. Dass ein Großteil der Belegschaft ein Werkzeug im letzten Monat geöffnet hat, sagt nichts darüber, ob irgendetwas schneller, billiger oder besser geworden ist. Es ist die Kennzahl, die Anbieter am liebsten liefern, weil sie leicht zu erheben ist und meist gut aussieht. Belastbar wird die Messung in drei Schritten:

1. 01
   Ausgangslage vor dem Pilot erheben

   Wie lange dauert ein Vorgang heute, wie viele gibt es pro Monat, wie hoch ist die Fehler- oder Nacharbeitsquote? Ohne diese Zahlen lässt sich nach dem Pilot nur noch über Eindrücke reden.

2. 02
   Pro Anwendungsfall eine Messgröße

   Durchlaufzeit pro Rechnung, Anzahl übersehener Fristen, Zeit bis zur Antwort auf eine Anfrage. Eine Zahl, die der Prozessverantwortliche ohnehin versteht.

3. 03
   Vollkosten pro Vorgang

   Lizenzen oder Nutzungskosten, Einrichtung und Integration auf die Laufzeit verteilt, Betrieb, Kontrolle und Schulungszeit. Erst diese Summe, geteilt durch die Zahl der Vorgänge, ist vergleichbar mit dem, was der Vorgang heute kostet.

Ein Rechenbeispiel

Ein Unternehmen verarbeitet 600 Eingangsrechnungen im Monat. Erfassung und Kontierung dauern heute im Schnitt zwölf Minuten pro Rechnung, das sind 120 Stunden im Monat. Mit KI-gestützter Erfassung sinkt die Zeit auf vier Minuten, weil nur noch geprüft und korrigiert wird: 40 Stunden. Gewonnen sind 80 Stunden im Monat, rund eine halbe Stelle.

Ob sich das rechnet, entscheidet die Gegenseite: Was kosten Lösung, Integration und Betrieb pro Monat, und was geschieht mit den 80 Stunden? Fließen sie in Aufgaben, die bisher liegen blieben, in schnellere Monatsabschlüsse oder in Wachstum ohne zusätzliche Stelle, ist der Nutzen real. Verteilen sie sich unbemerkt im Tagesgeschäft, steht in keiner Rechnung eine Ersparnis. Diese Frage gehört vor den Start beantwortet, nicht danach.

Ein Punkt fehlt in Business Cases besonders oft: Nutzungsabhängige Kosten wachsen mit dem Erfolg. Was im Pilot ein paar Euro im Monat kostet, kann im Vollbetrieb mit allen Mitarbeitenden ein relevanter Posten werden. Kostenobergrenzen und ein monatlicher Blick auf die Verbrauchsdaten gehören deshalb zum Betrieb wie die Stichprobenkontrolle.

Eine Reihenfolge, die funktioniert

1. 01
   Bestandsaufnahme

   Wo wird KI heute schon genutzt, offiziell und inoffiziell? Welche Daten liegen wo, und wie sauber sind die Berechtigungen?

2. 02
   Zwei bis drei Anwendungsfälle auswählen

   Nach Volumen, Messbarkeit und Risiko, jeweils mit Ausgangslage, Verantwortlichem und Abbruchkriterium.

3. 03
   Regeln und Befähigung

   Nutzungsrichtlinie, Schulung nach Rolle, Multiplikatoren mit Zeitbudget.

4. 04
   Pilot mit Betriebsentscheidung

   Acht bis zwölf Wochen, gemessen gegen die Ausgangslage, mit einer Entscheidung am Ende: Betrieb, Anpassung oder Abbruch.

5. 05
   Betrieb und nächste Welle

   Testfälle, Stichproben, Kostenkontrolle. Erst wenn der erste Anwendungsfall stabil läuft, kommt der nächste.

Die ersten beiden Schritte deckt die KI-Standortbestimmung ab: in rund zwei Wochen von der Bestandsaufnahme zu priorisierten Anwendungsfällen mit Business Case und einer Roadmap, umsetzbar mit oder ohne DIGITALFEX.

Der häufigste Fehler

Mit dem Werkzeug anfangen statt mit dem Problem. Die Frage „Was können wir mit KI machen?“ führt zu Vorführungen. Die Frage „Welcher Prozess kostet uns heute am meisten Zeit, und würden wir einen Fehler darin bemerken?“ führt zu Ergebnissen. Wer mit der zweiten Frage beginnt, braucht weniger Piloten und bekommt mehr Betrieb.