KI im Unternehmen: In 90 Tagen vom Pilotprojekt zum Betrieb

KI im Unternehmen einzuführen sollte einen klar abgegrenzten Arbeitsablauf innerhalb eines Prüfzeitraums von 90 Tagen messbar verbessern – mit einer benannten verantwortlichen Person und einem funktionierenden Ersatzverfahren. Am Anfang steht die Aufgabe: Daten und Zugriffe klären, den passenden Umsetzungsweg wählen und in einem Pilotprojekt gegenüber dem bestehenden Prozess nachweisen, dass sich eine breitere Einführung lohnt. Der Termin markiert einen Entscheidungspunkt. Er ist kein Freibrief, einen Ablauf freizugeben, der die Prüfungen nicht besteht.

Was bedeutet es, KI zu implementieren?

KI-Implementierung bedeutet, aus einem genehmigten Anwendungsfall einen Prozess zu machen, den Menschen betreiben, messen und pflegen können. Ein funktionierendes Modell ist dabei nur ein Baustein. Hinzu kommen Daten, deren Nutzung erlaubt ist, die Einbindung in den bestehenden Arbeitsablauf, geschulte Prüfer, Verfahren für den Fehlerfall und eine Person, die auch nach dem Start die Verantwortung trägt.

Ein Pilotprojekt lässt sich mit einer Generalprobe vergleichen. Eine überzeugende Szene sagt wenig aus, wenn der Regisseur jede Zeile vorsagen muss. Ein Arbeitsablauf ist bereit für den nächsten Schritt, wenn die vorgesehenen Nutzer ihre Aufgaben erledigen und Probleme bewältigen können, ohne dass der Entwickler danebensteht.

Auch Microsoft zählt in seinem Leitfaden zur KI-Einführung Vorbereitung, Menschen und Überwachung zur Implementierung. Der entscheidende Unterschied: Es geht nicht nur darum, von einer KI eine Antwort zu erhalten, sondern darum, mit dem gesamten Prozess ein fachlich akzeptiertes Ergebnis zu erzielen.

Steht das Geschäftsziel noch nicht fest, hilft der Leitfaden zur KI-Strategie, es zu klären. Sobald es vereinbart ist, folgt der nächste Auftrag: nachweisen, dass ein konkreter Arbeitsablauf funktioniert.

Die Empfehlungen der Quellen wurden am 28. Oktober 2026 geprüft. Der folgende Zeitplan und die Abnahmeprüfungen sind Vorschläge für die betriebliche Praxis. Die Rechenbeispiele sind hypothetisch und stammen nicht aus einem realen Einsatz.

KI im Unternehmen einführen: Sieben Schritte in 90 Tagen

Der Zeitplan soll Entscheidungen herbeiführen und Abhängigkeiten sichtbar machen. Der nächste Schritt folgt erst, wenn die Nachweise ausreichen – auch wenn dafür der Umfang kleiner werden oder der Pilot länger laufen muss.

Die vorgeschlagene Abfolge setzt einen klar begrenzten Arbeitsablauf voraus, der bestehende Systeme und verfügbare KI-Funktionen nutzt. Sie ist keine Zusage, im selben Zeitraum umfangreiche Datenprobleme zu beheben, ein neues Modell zu trainieren oder ein System mit schwerwiegenden möglichen Auswirkungen freizugeben. Sobald die Aufgabe feststeht, sollten Datenzugriff, Beschaffung und Prüfungen durch Fachleute eingeplant werden.

Eine Person kann mehrere Rollen übernehmen. Trotzdem braucht jede Verantwortung einen Namen, eingeplante Arbeitszeit und die nötigen Befugnisse. Die künftige Betriebsverantwortung sollte schon zu Beginn feststehen; im letzten Schritt wird bestätigt, dass diese Person tatsächlich übernehmen kann.

1. Eine Aufgabe mit eindeutigem Abschluss wählen

Geeignet ist eine wiederkehrende Aufgabe, deren Eingaben, akzeptables Ergebnis und fachliche Verantwortung sich klar benennen lassen. Der erste Einsatzbereich sollte klein genug sein, um ihn gründlich zu prüfen, und häufig genug vorkommen, um im Pilotprojekt aussagekräftige Nachweise zu liefern.

Für die Leitung eines Supportteams ist „den Kundenservice mit KI verbessern“ zu weit gefasst. Eine brauchbare Abgrenzung lautet: Antworten auf übliche Produktfragen anhand genehmigter Hilfeartikel entwerfen und jeden Entwurf anschließend einem Supportmitarbeiter zur Prüfung vorlegen. Entscheidungen über Erstattungen, Kontoänderungen, vertragliche Zusagen und das Versenden der Antworten bleiben außerhalb dieses Rahmens.

Bevor der Prozess verändert wird, sollten reale Fälle durch den bisherigen Ablauf begleitet werden. Dabei werden Auslöser, benötigte Informationen, ausgeführte Schritte, Übergaben und der Zeitpunkt erfasst, an dem die Aufgabe als abgeschlossen gilt. Warten Anfragen auf fehlende Informationen, kann schnelleres Formulieren die eigentliche Verzögerung unberührt lassen.

Ein kurzer Steckbrief zum Arbeitsablauf sollte Folgendes festhalten:

• Anfang und Ende: Was löst die Aufgabe aus, und welches Ergebnis gilt als akzeptiert?
• Geeignete Fälle: Welche Anfragen gehen in den Pilotbetrieb, welche bleiben im bisherigen Prozess?
• Befugnisse: Was darf die KI lesen, vorschlagen und ändern, und was verlangt eine menschliche Entscheidung?
• Abnahme: Woran erkennt eine prüfende Person akzeptable, nachbesserungsfähige und unbrauchbare Ergebnisse?
• Verantwortung: Wer entscheidet, ob sich das Ergebnis verbessert hat, und wer bearbeitet Ausnahmen?

Bei Antwortentwürfen im Support könnte der Bewertungsmaßstab korrekte Anweisungen, eine passende Quelle, den Verzicht auf unbelegte Zusagen und eine geeignete Eskalation verlangen, wenn die Quelle keine Antwort liefert. Ein geschliffener Ton gleicht keine falsche Auskunft zu Kontoregeln aus.

Typischer Fehler: Mit jeder attraktiven Vorführung wächst die Aufgabe. Ein Assistent für Antwortentwürfe erhält schleichend die Erlaubnis, Streitfälle zu entscheiden oder Datensätze zu ändern.

So lässt sich das erkennen: Die fachlich verantwortliche Person und ein Mitarbeiter aus dem Tagesgeschäft ordnen unabhängig voneinander eine gemischte Auswahl aktueller Fälle als innerhalb oder außerhalb des vorgesehenen Rahmens ein. Abweichungen werden vor der Entwicklung geklärt. Gibt es keine Einigkeit darüber, was das System bearbeiten soll, ist die Abgrenzung noch nicht tragfähig.

Beispiele für die KI-Einführung: So klein wie sinnvoll beginnen

Ein Gründer im Dienstleistungsbereich könnte mit internen Besprechungszusammenfassungen beginnen, deren Aufgabenpunkte vor dem Teilen geprüft werden. Im Finanzbereich könnten Rechnungsfelder ausgelesen werden, während die Zahlungsfreigabe getrennt bleibt. Ein allein arbeitender Entwickler könnte eingehende Anfragen zunächst vorhandenen Warteschlangen zuordnen lassen, bevor er einen Agenten baut, der seine nächsten Schritte selbst auswählt und ausführt.

Das sind mögliche Entwürfe, keine Zusagen, dass ein bestimmtes Produkt diese Aufgaben zuverlässig erfüllt. Vorrang sollte der Ansatz haben, für den Nachweise zugänglich sind, Fehler sich rückgängig machen lassen und eine prüfende Person erklären kann, was „korrekt“ bedeutet. Ein bestehender regelbasierter Prozess sollte erhalten bleiben, wenn er die Aufgabe bereits ausreichend gut löst.

2. Daten und Zugriffe prüfen, bevor das Modell angebunden wird

Die benötigten Informationen müssen für diesen Arbeitsablauf nutzbar sein, und ihre Verwendung muss erlaubt sein. Für eine eng begrenzte Aufgabe müssen nicht sämtliche Unternehmensdaten bereinigt werden. Es muss aber feststehen, auf welche Quellen sich die Aufgabe verlassen darf.

Im Supportbeispiel sind die freigegebene Hilfesammlung, die Verantwortlichen für die einzelnen Richtlinien und die Regeln zu bestimmen, nach denen ein Artikel als aktuell oder überholt gilt. Eine frühere Antwort ist nicht allein deshalb maßgeblich, weil sie in einem geschlossenen Ticket steht. Sie kann eine einmalige Ausnahme, eine abgelaufene Regelung oder private Informationen einer anderen Person enthalten.

Für die ausgewählten Quellen braucht es eine Dokumentation der Daten und Zugriffe. Dazu gehören Speicherort, verantwortliche Person, erlaubter Zweck, zugelassene Nutzergruppen, Anforderungen an die Aktualität, Aufbewahrungsregeln und das Verfahren zum Entziehen des Zugriffs. Werden Informationen in einen Suchindex, einen Cache oder Protokolle kopiert, müssen auch diese abgeleiteten Datenbestände erfasst werden.

Anschließend wird eine tatsächliche Anfrage durch den geplanten Ablauf geführt. Kann die Anwendung den passenden freigegebenen Artikel abrufen? Kann sie die aktuelle Richtlinie von einer älteren Fassung unterscheiden? Sieht die prüfende Person genügend Quellenkontext, um den Entwurf zu beurteilen? Was geschieht, wenn die Quelle fehlt oder widersprüchlich ist?

IBMs Leitfaden zur Implementierung führt Datenqualität und Zugänglichkeit als eigenen Umsetzungsschritt auf. Konkret wird dieser Schritt durch Tests mit den Benutzeridentitäten und Dokumenten, die später im Arbeitsablauf vorkommen. Eine Vorführung mit einem Administratorkonto reicht dafür nicht.

Generative KI implementieren: Zugriffsregeln gehören nicht nur in den Prompt

Generative KI erzeugt Inhalte, etwa einen Antwortentwurf. Relevante Dokumente geben ihr Material für diese Aufgabe. Sie ersetzen aber nicht die Kontrolle darüber, welche Dokumente sie überhaupt erhält.

Zugriffe müssen durch Berechtigungen in Anwendung und Datenspeicher durchgesetzt werden. Die Anweisung „keine geschützten Informationen preisgeben“ ersetzt keine technische Sperre gegen unbefugten Abruf. Ein Ablauf für Antwortentwürfe sollte nur die tatsächlich benötigten Aktionen zulassen. Die Grenze zum Versenden muss die Anwendung durchsetzen.

Typischer Fehler: Die Vorführung funktioniert mit einem privilegierten Konto. Gewöhnliche Nutzer erhalten dagegen unvollständige Antworten oder können Informationen abrufen, die sie niemals sehen dürften.

So lässt sich das erkennen: Die Tests werden sowohl mit einem berechtigten Nutzer als auch mit einem Nutzer durchgeführt, dem der Zugriff verweigert werden muss. Ein freigegebenes Testdokument muss für Letzteren unzugänglich bleiben. Anschließend werden das Entfernen des Dokuments oder der Entzug der Berechtigung über den gesamten Abrufweg geprüft. Auch das vorgeschriebene Verhalten abgeleiteter Datenbestände und bestehender Sitzungen gehört dazu. Ein einzelner erfolgreicher Test liefert einen Nachweis für diesen Fall, keinen Beleg für umfassende Sicherheit.

Sind Verantwortung, erlaubte Nutzung oder brauchbare Daten noch ungeklärt, hilft die Prüfung der KI-Einsatzbereitschaft, die offenen Aufgaben zuzuweisen. Bis die Zugriffe geklärt sind, bleibt der Pilot auf genehmigtes Beispielmaterial beschränkt.

3. Kaufen, konfigurieren oder entwickeln: Für alle gilt derselbe Test

Die einfachste Lösung ist die richtige, wenn sie die Abnahme-, Zugriffs- und Betriebsanforderungen des Arbeitsablaufs erfüllt. Kandidaten sollten anhand der eigenen Fälle und Rahmenbedingungen verglichen werden, bevor die Entscheidung für einen Umsetzungsweg fällt.

KI-Implementierung: Ein Entscheidungsrahmen für den Umsetzungsweg

Kaufen, wenn ein vorhandenes Produkt zur Aufgabe passt und seine Kontrollmechanismen die Prüfungen bestehen. Für den Supportablauf müssen dafür die tatsächliche Quellenanbindung, die Bedienung bei der Prüfung, Berechtigungen, Ergebnisprotokollierung und das Ersatzverfahren geprüft werden. Der Nachteil liegt in der Abhängigkeit vom Verhalten des Anbieters und den verfügbaren Konfigurationsmöglichkeiten. Ein Feature auf einer Vertriebsfolie belegt noch nicht, dass es zum eigenen Prozess passt.

Konfigurieren, wenn das Produkt grundsätzlich geeignet ist, der freigegebene Arbeitsablauf aber Anpassungen braucht. Das können Anweisungen, Quellenauswahl, Weiterleitungsregeln und Prüfschritte sein. So lässt sich unnötige Individualsoftware vermeiden. Konfiguration bleibt dennoch Logik, die gepflegt werden muss. Jemand muss sie versionieren, Änderungen testen und ihre Quellenanbindungen funktionsfähig halten.

Selbst entwickeln, wenn eine notwendige Anforderung offenbleibt und das entstehende System dauerhaft verantwortet werden kann. Eine besondere Freigabekette oder eine ungewöhnliche Integration kann Eigenentwicklung rechtfertigen. Einen Arbeitsablauf zu bauen heißt nicht automatisch, ein Modell zu trainieren. Es kann bedeuten, Berechtigungen, Informationsabruf, Prüfung und Protokollierung um einen bestehenden Modelldienst herum zu entwickeln. Damit geht die Verantwortung für Integrationsfehler, Aktualisierungen und Support einher.

Anthropic empfiehlt in seinen Entwicklungshinweisen zu Agenten, mit der einfachsten wirksamen Lösung zu beginnen und Komplexität nur bei begründetem Bedarf hinzuzufügen. Für die Umsetzung bedeutet das: Ein vorhersehbarer Ablauf aus Entwurf und Prüfung braucht kein Modell, das sich seine eigene Vorgehensweise ausdenkt.

Die Kandidaten auf der engeren Auswahlliste erhalten dieselben genehmigten Beispielfälle, denselben Bewertungsmaßstab und dieselben Kontrollanforderungen. Dazu gehören schwierige Eingaben, nicht verfügbare Quellen, gewöhnliche Nutzerberechtigungen und ein Dienstausfall. Ebenso muss geklärt werden, wie sich relevante Aufzeichnungen exportieren und die Arbeit fortsetzen ließen, wenn die Zusammenarbeit endet.

Wird ein Umsetzungspartner beauftragt, gehören diese Prüfungen neben Dokumentation und Übergabe zu den vertraglich vereinbarten Leistungen. Ein Partner kann Umsetzungskapazität bereitstellen. Das Unternehmen braucht weiterhin jemanden, der das Ergebnis abnimmt und den laufenden Prozess verantwortet.

Typischer Fehler: Eine überzeugende Vorführung gibt den Ausschlag. Fehlende Integrationen oder unerfüllte Zugriffsanforderungen fallen erst nach der Zusage auf.

So lässt sich das erkennen: Jeder Kandidat muss mit demselben Bewertungsmaßstab einen schlanken, durchgängigen Ablauf demonstrieren: von einer berechtigten Anfrage bis zum geprüften Ergebnis und einem Fehlerfall, aus dem der Betrieb wiederhergestellt werden kann. Offene Anforderungen werden ausdrücklich festgehalten. Ein Kandidat mit einer kritischen Lücke besteht die Prüfung nicht deshalb, weil seine Texte besser klingen.

4. Den Pilotbetrieb mit dem bisherigen Prozess vergleichen

Ein Pilotprojekt soll zeigen, ob der vorgeschlagene Arbeitsablauf die Arbeit unter festgelegten Bedingungen verbessert. Dafür braucht es einen Vergleichsprozess, repräsentative Fälle und Abnahmekriterien, die feststehen, bevor die Ergebnisse vorliegen.

Der bestehende Prozess sollte frühzeitig erfasst werden, während Datenfragen und Umsetzungswege noch geklärt werden. Diese Ausgangsmessung bildet die Vergleichsbasis. Für sie gelten dieselben Definitionen wie später für den Pilotbetrieb. Google Cloud empfiehlt in seinen Hinweisen zur Erfolgsmessung, diese Basis zu erheben und die Messung vor dem Start zu planen.

Bei Antwortentwürfen im Support werden der aktive Arbeitsaufwand bis zur akzeptierten Antwort, die gesamte Zeit bis zum Abschluss, die Qualität nach dem festgelegten Bewertungsmaßstab und die Gründe für Eskalationen erfasst. Zum aktiven Aufwand gehören Lesen, Prüfen, Bearbeiten und Fehlerkorrektur. Die Gesamtzeit umfasst zusätzlich Wartezeiten. Ein schnelleres Modell kann daher durchaus mit einer langsameren Antwort an den Kunden einhergehen.

Die Vergleichsmethode muss zur Arbeit passen. Soweit möglich, werden vergleichbare geeignete Fälle zufällig dem bisherigen Prozess oder der KI-Unterstützung zugeteilt. Beeinflussen Fälle einander – etwa innerhalb desselben Kundengesprächs –, bleiben die zusammengehörigen Fälle in derselben Gruppe. Ist nur ein Vorher-nachher-Vergleich möglich, müssen Änderungen bei Personal, Arbeitsaufkommen und Zusammensetzung der Anfragen dokumentiert werden. Sie begrenzen die Sicherheit, mit der sich das Ergebnis der KI zuschreiben lässt.

Beispiele zur Anpassung des Arbeitsablaufs bleiben von den Fällen getrennt, an denen er bewertet wird. Ein zurückgehaltener Testsatz besteht aus Fällen, die eigens für die Bewertung reserviert sind und nicht wiederholt in die Anpassung einfließen. Er sollte gewöhnliche Anfragen ebenso enthalten wie schwierige Fälle: fehlende Informationen, widersprüchliche Quellen, ungewöhnliche Formulierungen und Fragen, die das freigegebene Material nicht beantworten kann.

Der Pilot wird in kontrollierten Schritten durchgeführt:

1. 1

   Genehmigte historische Fälle erneut durchspielen

   Der Kandidat bearbeitet frühere Fälle, ohne Aktionen im laufenden Betrieb auszuführen. Eine fachkundige Person bewertet sie anhand der festgelegten Kriterien. Dabei wird geprüft, ob die abgerufenen Belege passten, ob der Entwurf sie korrekt verwendete und ob das System Anfragen ohne ausreichende Grundlage angemessen ablehnte oder eskalierte.

2. 2

   Live-Eingaben beobachten, ohne die Ergebnisse zu verändern

   Im Schattenbetrieb verarbeitet der Kandidat erlaubte Live-Vorgänge, während der bestehende Prozess für das Ergebnis verantwortlich bleibt. Geprüft werden fehlende Eingaben, Latenz, nicht verfügbare Abhängigkeiten und unerwartete Falltypen. Auch der Schattenbetrieb erfordert die entsprechende Berechtigung zur Datennutzung.

3. 3

   Eine begrenzte Nutzergruppe mit KI unterstützen

   Geschulte Mitarbeiter nutzen den Kandidaten innerhalb des vereinbarten Rahmens. Antworten an Kunden bleiben von einer menschlichen Freigabe abhängig. Erfasst werden versuchte und ausgelassene Nutzung, Fehler, Prüfung, Korrektur und Endergebnis. Informationen zur Konfiguration und zu Quellenversionen müssen ausreichen, um ein Ergebnis nachträglich untersuchen zu können.

Vor dem unterstützten Einsatz werden die Entscheidungsregeln vereinbart: erforderliche Qualität, akzeptabler Aufwand, maximal tolerierte Verzögerungen und Fehler, bei denen der Arbeitsablauf sofort pausiert. Im vorliegenden Beispiel, das nur Entwürfe vorsieht, sollten eine unbefugte Offenlegung oder ein Versand ohne Freigabe eine Unterbrechung und Untersuchung auslösen. Ein schwerwiegender Fehler darf nicht in einem Durchschnittswert verschwinden.

Typischer Fehler: Begeisterte Nutzer wählen einfache Fälle aus, der Entwickler behebt Fehler unbemerkt, und im Bericht tauchen nur erfolgreiche Entwürfe auf.

So lässt sich das erkennen: Jeder geeignete Fall wird mit dem Pilotprotokoll abgeglichen – auch dann, wenn die KI nicht genutzt wurde oder versagt hat. Hilfe durch den Entwickler zählt als Arbeitsaufwand. Eine andere Person als der Entwickler prüft das Bewertungsverfahren und eine Stichprobe der Entscheidungen.

Es gibt weder eine allgemeingültige Stichprobengröße noch einen Genauigkeitswert, der jeden KI-Arbeitsablauf sicher macht. Welche Nachweise erforderlich sind, hängt von der Vielfalt der Fälle, der Schwere möglicher Fehler und der für die Entscheidung nötigen Präzision ab. Liefert ein selten genutzter Arbeitsablauf im Prüfzeitraum nicht genügend Nachweise, muss der Pilot verlängert oder eine engere menschliche Kontrolle beibehalten werden.

5. Den gesamten Arbeitsablauf messen und entscheiden

Bewertet wird die Verbesserung über alle geeigneten Fälle hinweg, einschließlich Nichtnutzung, Prüfung und Ersatzverfahren. Eine einzelne Aufgabe kann mit KI deutlich schneller werden, während der Gewinn für den gesamten verantworteten Prozess viel kleiner ausfällt.

Das zeigt folgende hypothetische Berechnung mit vergleichbarer Fallzusammensetzung und demselben Qualitätsmaßstab. Angenommen wird, dass alle Fälle nach gegebenenfalls nötigen Korrekturen am Ende akzeptiert werden; dieser Aufwand ist in den Zeiten enthalten. Die Qualitätszahlen beziehen sich auf die erste Prüfung. Es handelt sich um Annahmen zur Veranschaulichung, nicht um einen Benchmark oder ein berichtetes Kundenergebnis.

Die Teilmenge mit KI-Unterstützung benötigt in diesem Beispiel 25% weniger aktiven Arbeitsaufwand: Der Rückgang von 12 auf 9 Minuten spart pro unterstütztem Fall 3 Minuten. Über den gesamten Arbeitsablauf beträgt die Verringerung jedoch 15%, weil die übrigen Fälle weiterhin manuell bearbeitet werden.

Die Rechnung lautet: 60 × 9 + 40 × 12 = 1,020 Minuten. Gegenüber den 1,200 Minuten der Ausgangsmessung werden damit über die 100 geeigneten Fälle hinweg 180 Minuten oder 3 Stunden frei. Das belegt weder finanzielle Einsparungen noch beweist der kleine Unterschied bei den Qualitätszahlen eine Qualitätsverbesserung.

In der Entscheidungsdokumentation werden Ergebnis, Aufwand, Nutzung und Fehler gemeinsam festgehalten. In diesem Beispiel wurden 60% der geeigneten Fälle mit KI unterstützt. Bevor die übrigen Fälle als Widerstand der Nutzer gewertet werden, müssen ihre Gründe untersucht werden: Fehlende Quellen, ungeeignete Anfragen oder eine langsamere Prüfung können erklären, warum die Unterstützung nicht genutzt wurde.

Ergebnisse sollten sowohl insgesamt als auch nach aussagekräftigen Falltypen und Nutzergruppen betrachtet werden. Ein guter Durchschnitt kann schlechte Leistungen bei einer wichtigen Anfragekategorie verdecken. Offene oder verspätete Fälle gehören ebenfalls in die Prüfung. Wer nur abgeschlossene Arbeit misst, kann einen wachsenden Rückstau übersehen.

Das AI Risk Management Framework Playbook des National Institute of Standards and Technology empfiehlt, das Verhalten im Einsatz mit den Nachweisen vor der Einführung zu vergleichen und menschlichen Prüfern klare Verantwortlichkeiten zuzuweisen. Beim Übergang in den Alltag müssen die Messdefinitionen unverändert bleiben.

Typischer Fehler: Der Bericht zählt erzeugte Ausgaben, rechnet die erfolgreiche Teilmenge hoch oder macht aus geschätzter Zeitersparnis unmittelbar eine finanzielle Rendite.

So lässt sich das erkennen: Das Ergebnis wird mit allen geeigneten Fällen und sämtlichem erforderlichen Arbeitsaufwand neu berechnet. Qualität und schwerwiegende Fehler werden anschließend gesondert geprüft. Der Leitfaden zum KI-ROI hilft, sobald bewertet werden soll, wie frei gewordene Kapazität die Ausgaben oder die betriebliche Leistung verändert.

Am Ende steht eine Entscheidung: den geprüften Einsatzbereich erweitern, einen benannten Mangel beheben und erneut testen, die Messung zur Klärung offener Fragen verlängern oder aufhören. Jede Entscheidung braucht eine Begründung und eine verantwortliche Person. „Weiter experimentieren“ ist kein brauchbares Pilotergebnis, solange unklar bleibt, welche Frage damit beantwortet werden soll.

6. Schrittweise ausrollen und den Rückweg offenhalten

Es sollte jeweils nur eine wesentliche Dimension erweitert werden, damit nachvollziehbar bleibt, was sich verändert hat. Mehr Nutzer, andere Fälle, eine weitere Geschäftseinheit und größere Handlungsbefugnisse sind getrennte Änderungen, die jeweils eigene Nachweise verlangen.

Im Supportbeispiel erhält die nächste Nutzergruppe dieselben freigegebenen Anfragetypen und Prüfregeln. Neue Sprachen, neue Quellensammlungen und automatischer Versand sollten nicht gleichzeitig hinzukommen. Ein erfolgreicher Pilot in einem engen Rahmen bestätigt nicht automatisch die Eignung dieser Erweiterungen.

Die Schulung muss Fehlerfälle abdecken, nicht nur den reibungslosen Ablauf. Jeder Mitarbeiter sollte eine unbelegte Aussage erkennen, Belege prüfen, einen Entwurf ablehnen und die Anfrage manuell weiterleiten können. Kontrollmechanismen gehören dorthin, wo gearbeitet wird. Eine separate Schulungsfolie kann die Anwendung nicht daran hindern, eine Antwort zu versenden.

Vor der Erweiterung wird ein Ausfall oder eine absichtlich nicht verfügbare Quelle durchgespielt. Dabei ist zu bestätigen, dass Anfragen mit genügend Kontext für die Weiterbearbeitung in der manuellen Warteschlange ankommen, die Verantwortung erkennbar bleibt und dieselbe Anfrage nicht versehentlich doppelt bearbeitet wird. Bei Abläufen mit Auswirkungen auf externe Systeme muss feststehen, wie bereits ausgeführte Aktionen erkannt und korrigiert werden. Ein Modell abzuschalten macht weder eine E-Mail noch eine Datenbankänderung rückgängig.

Weiter überwacht werden dieselben Ergebnis- und Aufwandskennzahlen wie im Pilotprojekt. Hinzu kommen Betriebssignale, die Fehler erklären: Verfügbarkeit abhängiger Dienste, Wartezeiten, Aktualität der Quellen, manuelle Eingriffe und Störungsmeldungen. Für jede Meldung, die eine Handlung verlangt, braucht es einen Empfänger und eine festgelegte Reaktion.

Typischer Fehler: Der Erfolg des Piloten hing von besonders erfahrenen Prüfern oder ständiger Unterstützung durch den Entwickler ab. Die nächste Gruppe kann ihn nicht wiederholen.

So lässt sich das erkennen: Ein Mitarbeiter außerhalb der ursprünglichen Pilotgruppe bearbeitet mit Schulungsunterlagen und Betriebshandbuch einen schwierigen Fall sowie die Wiederherstellungsübung. Beobachtet wird ohne Hilfestellung. Fehlende Anweisungen, Kontrollmechanismen oder Kapazitäten werden behoben, bevor weitere Nutzer hinzukommen.

Die Entscheidung zur Erweiterung hält den zusätzlichen Einsatzbereich, die geprüften Nachweise, die freigebende Person sowie Bedingungen für Unterbrechung und Wiederaufnahme fest. Der bisherige Prozess bleibt verfügbar, bis das Ersatzverfahren mit der Arbeitslast erprobt wurde, die es möglicherweise übernehmen muss.

7. Den Arbeitsablauf in die dauerhafte Betriebsverantwortung übergeben

Die betriebsverantwortliche Person muss den Nutzen des Arbeitsablaufs auch nach Abschluss des Umsetzungsprojekts sichern können. Dafür braucht sie Befugnisse, Supportkapazität und ein Änderungsverfahren. Eine E-Mail mit der Nachricht, das Projekt sei abgeschlossen, reicht nicht.

Die fachliche Verantwortung bleibt bei der Person, die für das Ergebnis einsteht. Im Supportbeispiel nimmt die Supportleitung die Antwortqualität und die Serviceleistung ab. Eine technisch verantwortliche Person kümmert sich um Integrations- und Konfigurationsfehler; die Quellenverantwortlichen pflegen das freigegebene Wissen. Vertretungen müssen benannt werden, ebenso die Zuständigkeit, wenn die üblicherweise verantwortliche Person nicht erreichbar ist.

Die Übergabedokumentation sollte Folgendes enthalten:

• Den freigegebenen Aufgabenrahmen, die Nutzergruppen und die erlaubten Aktionen.
• Die Ausgangsmessung, Bewertungsfälle, Bewertungskriterien, jüngsten Ergebnisse und bekannten Einschränkungen.
• Speicherorte der Quellen, Verantwortliche, Anforderungen an die Aktualisierung und Verfahren zum Entziehen von Zugriffen.
• Angaben zu Konfiguration und Abhängigkeiten, die ausreichen, um Änderungen untersuchen zu können.
• Überwachung, Ansprechpartner bei Störungen, Befugnisse zum Pausieren und Neustarten sowie Anweisungen zur Wiederherstellung des Betriebs.
• Schulung, eingeplante Supportzeit und den nächsten Termin zur Überprüfung des Betriebs.

Die MANAGE-Empfehlungen von NIST behandeln die Befugnis, ein System zu umgehen oder zu deaktivieren, ebenso wie Überwachung, Wiederherstellung nach Störungen und Änderungsmanagement. Für den konkreten Arbeitsablauf müssen diese Aufgaben benannten Personen zugeordnet werden.

Modellaktualisierungen, überarbeitete Anweisungen, veränderte Quellensammlungen und neue Integrationen sind Änderungen, die das Ergebnis beeinflussen können. Bevor eine geänderte Konfiguration breiter eingesetzt wird, muss sie die einschlägigen Bewertungen durchlaufen. Anschließend wird ihr Verhalten im laufenden Betrieb beobachtet. Steuert ein Anbieter eine Aktualisierung, die sich nicht zurückhalten lässt, muss feststehen, wie sie erkannt, ihre Wirkung bewertet und der betroffene Arbeitsablauf bei Bedarf ausgesetzt wird.

Die KI-Einführung endet nicht mit dem Start

Der Betrieb wird anhand tatsächlicher Ergebnisse und ungelöster Störungen überprüft. Neu entdeckte Fehlerfälle kommen in den Bewertungssatz. Veraltete Quellen werden entfernt. Entfällt der Nutzen oder übersteigt die Pflege die zugewiesene Kapazität, wird der Arbeitsablauf eingeschränkt oder stillgelegt.

Stellt ein KI-Kompetenzzentrum gemeinsame Zugänge, Bewertungsverfahren oder technische Unterstützung bereit, werden dessen Leistungen und der Eskalationsweg dokumentiert. Eine zentrale Funktion entbindet die vor Ort verantwortliche Person nicht von ihrer Verantwortung für den Geschäftsprozess.

Typischer Fehler: Das Projekt wird abgeschlossen, und alle gehen davon aus, dass sich jemand anderes um nachlassende Leistung, Quellenänderungen und Supportanfragen kümmert.

So lässt sich das erkennen: Die übernehmende Person bearbeitet anhand der Übergabeunterlagen eine simulierte Störung und eine vorgeschlagene Änderung, ohne dass der Entwickler die Reaktion vorgibt. Die Abnahme wird erst festgehalten, wenn diese Person die Zugriffe, Befugnisse und Kapazitäten besitzt, um die Aufgabe an Tag 91 zu erfüllen.

Was wird überschätzt, und wer sollte jetzt handeln?

Autonomie ist nicht automatisch das Ziel. Ein beaufsichtigter Arbeitsablauf, der zuverlässig nützliche Arbeit leistet, kann dauerhaft die richtige Lösung sein. Mehr Befugnisse sollte er erst erhalten, wenn die damit veränderten Folgen bewertet wurden.

Auch ein fertiges Produkt ist noch keine abgeschlossene Implementierung. Die Auswahl der Quellen, erlaubte Aktionen, Nutzerschulung und das Geschäftsergebnis bleiben in der eigenen Verantwortung. Ebenso ist erneutes Modelltraining kein automatisches Mittel gegen enttäuschende Ergebnisse. Vor der Wahl einer Abhilfe muss geklärt werden, ob der Fehler auf fehlende Belege, falschen Informationsabruf, Anweisungen, Integration oder die Übergabe an Menschen zurückgeht.

Verantwortliche im operativen Geschäft sollten jetzt handeln, wenn ein Ergebnis vereinbart, die Aufgabe abgegrenzt, die Datennutzung erlaubt und Zeit für die Ergebnisprüfung vorhanden ist. Als Nächstes entstehen der Steckbrief zum Arbeitsablauf und die Ausgangsmessung, danach die Nachweise für jede Freigabeentscheidung.

Gründer mit gesicherter Finanzierung sollten den Umfang begrenzen. Bevor weitere Abteilungen hinzukommen, braucht es eine nachweisbare Verbesserung im Betrieb. Zeit für Prüfer und Support muss ebenso finanziert werden wie die Entwicklung.

CTOs und Entwickler sollten mit mehr Autonomie warten, solange Berechtigungen, Beobachtbarkeit oder Wiederherstellung ungeklärt sind. Für einen allein arbeitenden Entwickler ist schon die begrenzte Wartungskapazität ein Grund, ein einfacheres System zu bevorzugen.

Einkaufsverantwortliche sollten Zusagen an Abnahmenachweise knüpfen. Es muss feststehen, wer Integrationen, Tests, Dokumentation und laufenden Support liefert. Eine attraktive Vorführung klärt diese Zuständigkeiten nicht.

Eine Abteilung, deren bestehender Prozess ihren Bedarf bereits deckt, kann ihn beibehalten. Eine KI-Initiative anderswo im Unternehmen ist kein Grund, einen funktionierenden Arbeitsablauf zu ersetzen.

Der erste Schritt am Montag

Die für den Arbeitsablauf verantwortliche Person, ein Mitarbeiter aus dem Tagesgeschäft und die technisch zuständige Person kommen zusammen und gehen aktuelle Fälle durch. Gemeinsam halten sie den Aufgabenrahmen und die Bewertungskriterien fest. Sie benennen die Quellenverantwortung, vereinbaren den Test erlaubter und verweigerter Zugriffe und beginnen, den bestehenden Prozess zu messen.

Der Entscheidungstermin für den Piloten und der Name der vorgesehenen betriebsverantwortlichen Person gehören in dasselbe Dokument. Bei dieser Prüfung geht es darum, ob die Nachweise den nächsten Schritt rechtfertigen – und welche konkreten Arbeiten noch fehlen, falls das nicht der Fall ist.

Praktische Leitfäden zum KI-Einsatz im Betriebsalltag gibt es im Newsletter.