KI 2026 intern ausrollen, ohne Shelfware zu produzieren

Fast jedes Unternehmen weiß inzwischen, dass KI dem Team echte Arbeit abnehmen kann. Deutlich weniger schaffen es, dass es auch hängenbleibt. Das übliche Ergebnis eines internen Rollouts ist ein Chatbot, dem niemand traut, ein Tool, das niemand öffnet, oder ein Pilot, der nie in Produktion geht. An der Technologie liegt es selten. Der Grund ist, dass echter interner Mehrwert drei Dinge gleichzeitig braucht: Wissen über deinen Prozess, das richtige Tooling und die Engineering-Leistung, um es bezahlbar und compliant zu betreiben. Das ist der Plan, mit dem wir KI in einem Team zum Laufen bringen, in der Reihenfolge, in der wir ihn anwenden.

Engineering- und Prozess-Perspektive, kein Vendor-Pitch. Hier geht es darum, KI intern einzuführen, und das ist eine andere Aufgabe als ein KI-Produkt für deine Kunden zu bauen. Wenn dein Ziel ist, dein eigenes Team zu entlasten, sind das die Schritte, auf die es ankommt.

Warum bleiben die meisten internen KI-Rollouts stecken?

Drei Fehlermuster tauchen immer wieder auf, und keines davon ist ein schlechtes Modell:

• Der falsche Prozess wurde automatisiert. Ein Team greift sich eine sichtbare statt einer wertvollen Aufgabe oder automatisiert einen Schritt, den ein Formular oder eine Regel längst günstig erledigt hat. Der Output funktioniert und ändert nichts.
• Niemand verantwortet das laufende System. Ein Proof of Concept wird vorgeführt, es wird applaudiert, und danach gibt es kein Monitoring, keine Guardrails und niemanden, dessen Job es ist, es korrekt zu halten. Es verrottet still.
• Kosten oder Compliance kippen es spät. Die Rechnung skaliert schlechter als erwartet, oder jemand aus der Rechtsabteilung fragt, wohin die Daten gehen, und das Projekt stoppt, nachdem das Budget schon ausgegeben ist.

Jedes davon ist vermeidbar, aber nur, wenn du den Rollout als Prozess- und Engineering-Problem behandelst, nicht als Tool-Einkauf.

Beginne damit, den Prozess zu mappen, nicht das Tool zu wählen

Der erste Schritt ist nicht die Wahl eines Modells oder eines Anbieters. Er besteht darin, aufzuschreiben, wie die Arbeit heute tatsächlich abläuft, Schritt für Schritt, und zu bewerten, wo KI wirklich Zeit spart und wo sie nur eine Schicht hinzufügt. Das ist unspektakulär, und es ist das mit Abstand wirkungsvollste, was du tun kannst.

Das ehrliche Ergebnis einer guten Prozess-Map ist oft eine kürzere Liste als die, mit der du gestartet bist. Manche Schritte bleiben besser bei einem Menschen, einer Regel-Engine oder einem einfachen Skript. Den falschen Schritt zu automatisieren, ist die Art, wie interne KI-Projekte scheitern, die am Demo-Tag wie ein Erfolg aussieht. Der Sinn des Mappings zuerst ist, die Schritte zu finden, bei denen eine falsche Antwort günstig abzufangen ist und das Volumen hoch genug, um zu zählen.

"Das teuerste interne KI-Projekt ist das, das einen Schritt automatisiert, den du hättest in Ruhe lassen sollen. Mappe den Prozess, bevor du ein Modell anfasst."

Wie hältst du interne KI-Kosten vorhersehbar?

Interne Nutzung skaliert anders als eine Demo. Ein Tool, das über fünf Testläufe gratis wirkt, wird zu einem echten Posten, wenn das ganze Team es täglich nutzt. Die Kostendisziplin ist dieselbe, die wir bei produktiven KI-Builds anwenden:

• An das günstigste fähige Modell routen. Die meisten internen Aufgaben brauchen nicht dein teuerstes Modell. Ein semantischer Router schickt die triviale Mehrheit an ein kleines oder Open-Weight-Modell und reserviert das Frontier-Modell für die schwere Minderheit.
• Kontext managen, nicht nur Tokens. Dem Modell bei jedem Call ein ganzes Dokument oder die gesamte History zu schicken, ist die häufigste Verschwendungsquelle. Schicke pro Schritt den kleinsten korrekten Kontext.
• Cachen und batchen, was sich wiederholt. Interne Workflows wiederholen sich weit stärker als kundenseitige, was Caching ungewöhnlich wirksam macht. Alles, was keine sofortige Antwort braucht, kann im Batch laufen.

Die Kostenmechanik behandeln wir ausführlich in wie du LLM-Token-Kosten 2026 senkst. Das Prinzip für einen internen Rollout ist einfacher: kalkuliere die Kosten, bevor du baust, damit das Projekt nicht an einer überraschenden Rechnung stirbt.

Wann erzwingt Compliance lokale oder Open-Weight-Modelle?

Für viele interne Use Cases ist der Blocker nicht die Fähigkeit, sondern wohin die Daten gehen. Wenn der Workflow personenbezogene Daten, regulierte Akten oder irgendetwas berührt, das du nicht an eine Drittanbieter-API schicken kannst, ist die Antwort meist, ein Open-Weight- oder lokales Modell in deiner eigenen Umgebung zu betreiben.

Von Anfang an gemacht, ist das eine Design-Entscheidung, kein Kompromiss: die Daten verlassen das Haus nie, du bleibst im Einklang mit DSGVO und EU AI Act, und du behältst den Kostenvorteil von Open-Weight-Modellen. Als nachträglicher Einfall gemacht, ist es ein Umbau. Die Compliance-Frage ist fast immer lösbar. Sie muss nur gestellt werden, bevor die Architektur steht, nicht danach.

Bau es produktionsreif, oder bau es nicht

Ein Pilot, dem man in Produktion nicht trauen kann, ist keine Ersparnis, sondern eine Wartungslast mit gutem Marketing. Der Unterschied zwischen einer Demo und einem Tool, das das Team wirklich entlastet, ist das unspektakuläre Gerüst:

• Guardrails, damit eine falsche Antwort abgefangen wird, bevor sie einen Kunden oder ein Buchungskonto erreicht.
• Monitoring, damit du siehst, wenn die Qualität driftet, statt es aus einer Beschwerde zu erfahren.
• Runbooks und Handover, damit die Leute, die es täglich betreiben, es verstehen und reparieren können.

Hier ist auch Wissenstransfer entscheidend. Ein Rollout, der dein Team in die Lage versetzt, das Setup selbst zu betreiben und zu erweitern, ist ein Asset. Einer, den nur der externe Anbieter versteht, ist eine Abhängigkeit, für die du ewig zahlst.

Warum mit einem Workshop starten und nicht mit einem Build?

Der risikoärmste Einstieg in interne KI ist Bildung, kein Vertrag. Ein Workshop oder Vortrag, idealerweise mit jemandem, der sowohl deine Domäne als auch das Tooling kennt, gibt einem Team ein realistisches Bild davon, was KI für ihre konkrete Arbeit kann und was nicht, und eine Shortlist dessen, was sich zu automatisieren lohnt. Es ist günstig, es ist schnell, und es bringt die Prozess-Map fast als Nebeneffekt ans Licht.

Von dort aus ist der Done-for-you-Build eine kleinere, besser zugeschnittene Entscheidung, weil du schon weißt, welchen Prozess du ins Visier nimmst und warum. Diese zweistufige Form, erst lernen, dann bauen, ist der Kern davon, wie wir AI Enablement betreiben. Denselben Workshops-First-Ansatz haben wir mit SKD Dresden genutzt, wo das ehrliche Ergebnis der Sessions war, die Ideen auszuschließen, die sich nicht ausgezahlt hätten.

In welcher Reihenfolge solltest du das ausrollen?

Die Sequenz, die wir abarbeiten, risikoärmster und wirkungsvollster Schritt zuerst:

1. Bilden. Ein Workshop oder Vortrag, um das Team auf das Realistische auszurichten und Kandidaten-Prozesse ans Licht zu bringen.
2. Prozess mappen. Die echten Schritte aufschreiben und bewerten, wo KI sich auszahlt. Ausschließen, was nicht automatisiert werden sollte.
3. Kosten- und Compliance-Check. Modellklasse, Routing und ob Datenresidenz lokale oder Open-Weight-Modelle erzwingt, vor dem Bauen entscheiden.
4. Einen Workflow durchgängig bauen. Einen einzigen hochwertigen Prozess wählen und ihn mit Guardrails und Monitoring ausliefern, nicht als Pilot.
5. Übergeben und befähigen. Dokumentieren, das Team schulen, das ihn betreibt, und entscheiden, ob du laufende Wartung oder volle Eigenverantwortung willst.
6. Auf Beweis ausbauen. Das erste funktionierende Setup und seine gemessene Ersparnis nutzen, um das nächste zu rechtfertigen, statt vorab das Meer auszuschöpfen.

Schritte eins und zwei kosten sehr wenig und verhindern die teuersten Fehler. Schritte drei bis sechs sind, wo die Entlastung sich wirklich aufsummiert.