Viele Unternehmen haben inzwischen KI ausprobiert. Weitaus schwieriger ist der nächste Schritt: aus einer überzeugenden Demo einen stabilen Arbeitsprozess zu machen.
Genau dort scheitern viele Vorhaben. Nicht, weil das Modell grundsätzlich zu schwach wäre, sondern weil die Voraussetzungen fehlen: Kommt die KI an die richtigen Daten? Darf sie diese Daten überhaupt sehen? Landet ihr Ergebnis wieder im CRM, ERP, Ticket-System oder Bericht? Wer ist fachlich verantwortlich? Und woran wird gemessen, ob das Projekt mehr ist als ein Experiment?
Ein Bericht über die globale McKinsey-Umfrage beschreibt diese Lücke deutlich: 88 % der Organisationen nutzen KI bereits in mindestens einer Geschäftsfunktion, aber fast zwei Drittel sind noch nicht über Experimente oder frühe Pilotprojekte hinausgekommen.[5] Anders gesagt: An KI-Versuchen mangelt es nicht. Was fehlt, ist ein sauberer Weg vom Proof of Concept, kurz PoC, in den operativen Alltag.
Nicht mit dem Modell anfangen, sondern mit dem Prozess
Die bessere Einstiegsfrage lautet nicht: „Welches KI-Tool kaufen wir?“ Sondern: „Welcher Prozess lohnt sich zuerst?“
Ein guter erster Use Case muss nicht der spektakulärste sein. Er sollte häufig vorkommen, messbar sein, auf vorhandene Daten zugreifen können und so gestaltet sein, dass Menschen die Ergebnisse prüfen oder korrigieren können.
Geeignete Startpunkte haben meist mehrere dieser Merkmale:
- Ein Team erledigt täglich oder wöchentlich wiederkehrende Aufgaben.
- Die benötigten Informationen liegen bereits in Dokumenten, CRM-Systemen, ERP-Systemen, Ticket-Tools, Data Warehouses oder internen Wissensdatenbanken vor.
- Der heutige Prozess hat einen klaren Schmerzpunkt: lange Suchzeiten, viel Copy-and-paste, uneinheitliche Antworten, Medienbrüche oder hohe Nacharbeit.
- KI-Ausgaben können geprüft, stichprobenartig kontrolliert, korrigiert oder an Menschen übergeben werden.
- Es gibt einen fachlichen Owner, der den Prozess ändern darf und für das Ergebnis einsteht.
Fehlen diese Bedingungen, entsteht schnell eine schöne Demo – aber kein belastbarer Nutzen im Betrieb.
Die 5 Schritte vom PoC zur Umsetzung
1. Das Vorhaben als messbares Geschäftsproblem formulieren
Ein Projekt mit dem Titel „KI einführen“ ist zu unscharf. Besser ist eine konkrete Beschreibung: Welche Nutzergruppe erledigt in welchem Prozess welche wiederkehrende Aufgabe? Wo hakt es heute? Welcher Kennwert soll sich verbessern?
Eine einfache Formulierung hilft:
Im Prozess A verbringt Rolle B jede Woche viel Zeit mit Aufgabe C. Wir wollen mithilfe von KI Kennzahl D vom heutigen Ausgangswert auf Zielwert X verbessern. Fachlicher Owner E verantwortet Prozessänderung und Erfolgskontrolle.
Vor dem Start sollten mindestens diese Fragen beantwortet sein:
- Wer nutzt die KI-Funktion regelmäßig?
- An welcher Stelle im bestehenden Arbeitsablauf wird KI eingebunden?
- Wie sieht der heutige Ausgangswert aus – etwa Bearbeitungszeit, Fehlerquote, Abschlussrate, Beschwerdequote oder manuelle Arbeitszeit?
- Geht es primär um Effizienz, Qualität, Umsatz, Kosten, Risiko oder Mitarbeitererlebnis?
- Wer darf entscheiden, dass sich der Prozess tatsächlich ändert?
Ohne fachlichen Owner und Baseline lässt sich ein PoC kaum bewerten – und noch schwerer skalieren.
2. Ein bis drei häufige, wiederholbare Use Cases auswählen
Für die erste Welle eignen sich Aufgaben mit hoher Frequenz, klarer Datenbasis und kontrollierbarem Fehlerrisiko. Typische Einstiege sind:
| Möglicher Use Case | Warum er sich als Startpunkt eignet | Erster sinnvoller KPI |
|---|---|---|
| Wissenssuche im Kundenservice | Antworten stammen oft aus FAQ, Produktdokumentation, Tickets oder internen Wissensdatenbanken | Durchschnittliche Bearbeitungszeit, Erstlösungsquote, Stichproben-Genauigkeit, Beschwerdequote |
| Interne Dokumenten-Q&A | Mitarbeitende suchen häufig nach Richtlinien, Prozessen, Produkt- oder Technikunterlagen | Suchzeit, Weiterleitungen an Experten, Annahmequote der Antwort |
| Berichts- und Meeting-Zusammenfassungen | Formate sind oft wiederkehrend, der Lese- und Verdichtungsaufwand ist hoch | Erstellungszeit, Nutzungsquote, Zahl der Korrekturschleifen |
| Extraktion aus Verträgen oder Belegen | Felder sind klar definiert, menschliche Prüfung lässt sich gut einbauen | Feldgenauigkeit, Prüfzeit, Nacharbeitsquote |
| Unterstützung in Vertrieb oder Einkauf | KI kann Daten sortieren, Angebote vergleichen, Entwürfe erstellen oder erste Vorschläge machen | Antwortzeit, Durchlaufzeit, Conversion Rate, eingesparte manuelle Arbeit |
Weniger geeignet für den Anfang sind hochriskante, sehr komplexe oder unklare Prozesse. Wenn Daten verstreut sind, der Ablauf nicht standardisiert ist oder Governance noch fehlt, sollte zuerst daran gearbeitet werden – nicht am nächsten KI-Modell.
3. Daten, Berechtigungen und Systemanbindung vor dem PoC prüfen
Die größte Hürde liegt oft nicht im Modell, sondern in der Frage, ob Daten sicher, korrekt und aktuell verfügbar sind. Talyx fasst eine RAND-Studie von 2024 zusammen, für die 65 erfahrene Data Scientists und Engineers befragt wurden. Als häufige Ursachen für das Scheitern von KI-Projekten nennt die Studie unter anderem missverstandene Problemdefinitionen, unzureichende Trainingsdaten, eine technologiegetriebene statt problemgetriebene Herangehensweise, mangelhafte Infrastruktur und Aufgaben, die für den gewählten Ansatz zu schwierig sind.[4]
Vor einem PoC sollten Unternehmen deshalb klären:
- Wo liegen die Daten? In Dateiablagen, CRM, ERP, Ticket-Systemen, Data Warehouses – oder auf einzelnen Laufwerken?
- Wie gut sind sie? Sind Informationen veraltet, doppelt, unvollständig oder uneinheitlich formatiert?
- Wie werden Berechtigungen gesteuert? Dürfen unterschiedliche Abteilungen, Rollen oder Standorte unterschiedliche Inhalte sehen?
- Wie aktuell sind die Daten? Antwortet die KI auf Basis der neuesten Version oder auf Grundlage alter Dokumente?
- Lässt sich das Ergebnis zurückspielen? Kommt die KI-Ausgabe wieder in Ticket, CRM, Bericht, Freigabeprozess oder Dokumentation an?
- Ist Auditierbarkeit möglich? Kann nachvollzogen werden, wer gefragt hat, was die KI geantwortet hat und wer die Ausgabe übernommen oder korrigiert hat?
Wenn Daten nicht erreichbar sind, bleibt selbst ein starkes Modell eine Präsentationslösung. Wenn Berechtigungen unklar sind, hängt das Projekt später an Sicherheit, Datenschutz, Compliance oder Revision.
4. Einen kleinen PoC bauen – aber im echten Workflow
Ein PoC sollte mehr sein als ein Demonstrator im Meetingraum. Sinnvoller ist ein erster produktnaher Prototyp: echte Nutzer, echte Daten, echter Arbeitsablauf – mit klaren Kriterien für Erfolg, Ausbau und Stopp.
Ein PoC mit Aussicht auf Betrieb beantwortet mindestens diese Fragen:
- Wo wird die KI ausgelöst: im Kundenservice-Tool, in Slack oder Teams, im CRM, im Intranet oder in einem bestehenden Fachsystem?
- Wer prüft die Ausgabe?
- Welche Fälle müssen zwingend an Menschen übergeben werden?
- Wie melden Nutzer Fehler zurück?
- Wer korrigiert Daten, Regeln oder Prompts nach einer Fehlermeldung?
- Welche Aufgaben darf KI nur unterstützen, aber nicht automatisch abschließen?
- Ab welchem KPI-Wert wird skaliert – und ab welchem Wert wird gestoppt?
Der Punkt ist nicht, zu beweisen, dass KI eine Antwort erzeugen kann. Der Punkt ist, zu beweisen, dass sie in einem vorhandenen Arbeitsprozess stabil genutzt wird und eine relevante Kennzahl verbessert.
5. Erst nach Governance-Freigabe skalieren
KI zu skalieren bedeutet nicht, einfach mehr Lizenzen auszurollen. Jede neue Abteilung bringt neue Datenquellen, neue Berechtigungen, andere Prozessvarianten, zusätzliche Compliance-Fragen und eigene KPIs mit.
Besonders vorsichtig sollten Unternehmen werden, wenn KI von Suche, Zusammenfassung und Textentwurf in Richtung autonomerer AI Agents rückt. Die McKinsey-Umfrage 2025 zeigt: In keiner einzelnen Funktion berichten mehr als 10 % der Befragten, dass AI Agents bereits skaliert eingeführt wurden.[2] McKinsey nennt außerdem Sicherheits- und Risikothemen als wichtigste Hürde bei der Skalierung agentischer KI; Ungenauigkeit und Cybersicherheit gehören weiterhin zu den am häufigsten genannten KI-Risiken.[
8]
Ein robuster Ausbau sieht eher so aus:
- KI unterstützt zunächst beim Suchen, Strukturieren, Zusammenfassen und Entwerfen.
- Menschen bleiben im Prozess, prüfen Ergebnisse und dokumentieren Fehler sowie Sonderfälle.
- Erst wenn Genauigkeit, Prozessstabilität, Berechtigungen und Auditierbarkeit reif genug sind, werden risikoarme Schritte automatisiert.
- Vor jeder Ausweitung auf eine neue Abteilung werden Daten, Berechtigungen, rechtliche Anforderungen, Sicherheit, Datenschutz und Revision erneut geprüft.
KPI: Nicht nur Modellgenauigkeit messen
Viele KI-Projekte messen zu eng. Eine hohe Modellgenauigkeit hilft wenig, wenn der Prozess weiterhin langsam ist, Nutzer das Ergebnis nicht übernehmen oder manuelle Nacharbeit steigt.
Besser ist ein KPI-Set, das vom heutigen Ausgangswert ausgeht und mehrere Ebenen abdeckt:
| KPI-Typ | Mögliche Kennzahlen | Geeignete Einsatzfelder |
|---|---|---|
| Effizienz | Durchschnittliche Bearbeitungszeit, Durchlaufzeit, manuelle Minuten pro Fall, Zeit bis zum Bericht | Kundenservice, Reporting, Belege, Dokumenten-Q&A |
| Qualität | Stichproben-Genauigkeit, Annahmequote, Nacharbeitsquote, Beschwerdequote | Serviceantworten, Vertragsextraktion, Textentwürfe |
| Nutzung | Wöchentlich aktive Nutzer, abgedeckte Aufgaben, Wiederverwendung, Rückfragen an Experten | Interne Assistenten, Wissenssuche, Abteilungstools |
| Geschäftsergebnis | Conversion Rate, Antwortgeschwindigkeit, Fallabschlussrate, Kosten pro Fall | Vertrieb, Kundenservice, Einkauf, Operations |
| Risiko und Governance | Eskalationsquote, Policy-Verstöße, Ausnahmen bei sensiblen Daten, Audit-Feststellungen | Hochriskante Daten, externe Kommunikation, agentische KI |
Am Anfang braucht es nicht viele Kennzahlen. Aber sie müssen mit dem Prozess verbunden sein. Wenn ein PoC nur zeigt, dass KI Text erzeugt, aber nicht, dass Arbeit schneller, besser, günstiger oder kontrollierter wird, ist er noch keine Umsetzung.
Warum KI-Projekte oft nicht landen
1. Erst Tool kaufen, dann Problem suchen
Viele Initiativen starten mit einer Anbieter-Demo oder einem viel diskutierten Modell. Am Ende entsteht eine Funktion, die beeindruckend wirkt, aber im Alltag niemand wirklich braucht. Die von Talyx zusammengefasste RAND-Studie nennt eine technologiegetriebene statt problemgetriebene Herangehensweise als eine häufige Ursache für das Scheitern von KI-Projekten.[4]
2. Das Problem ist nicht gemeinsam definiert
Wenn Fachbereich, IT, Management, Recht und Sicherheit jeweils ein anderes Ziel verfolgen, zieht das Projekt in verschiedene Richtungen. Der Fachbereich will Bearbeitungszeit senken, die IT optimiert Modellwerte, das Management erwartet Kosteneffekte, Compliance sieht Risiken. Missverstandene Problemdefinitionen gehören ebenfalls zu den von Talyx beschriebenen Ursachen.[4]
3. Daten und Systeme sind nicht verbunden
KI kann nur begrenzt helfen, wenn sie nicht auf die richtigen Dokumente, Kundendaten, Tickets oder Transaktionsdaten zugreifen kann. Und wenn Ergebnisse nicht zurück in CRM, ERP, Dokumentenablage oder Ticket-System fließen, bleibt für Nutzer manuelle Nacharbeit. Auch unzureichende Infrastruktur wird in der Zusammenfassung der RAND-Ergebnisse als häufiger Grund für das Scheitern genannt.[4]
4. Der PoC verändert keine echte Arbeit
Hohe KI-Nutzung bedeutet noch keine Skalierung. Laut einem Bericht über McKinsey-Daten nutzen zwar 88 % der Organisationen KI in mindestens einer Geschäftsfunktion, fast zwei Drittel stecken aber noch in Experimenten oder frühen Piloten fest.[5] Ohne echten Workflow, fachlichen Owner und messbare KPIs bleibt ein PoC oft eine Demo.
5. Governance kommt zu spät
Sicherheit, Datenschutz, Compliance, Revision und Berechtigungen lassen sich nicht kurz vor dem Go-live „dranschrauben“. Bei agentischer KI ist das besonders kritisch, weil autonomere Systeme klarere Daten- und Handlungsspielräume, menschliche Kontrolle und Verantwortlichkeiten benötigen. McKinsey beschreibt Sicherheits- und Risikothemen als wichtigste Hürde bei der Skalierung von agentic AI.[8]
Entscheidungshilfe: Was zuerst, was später?
| Eher zuerst angehen | Besser zunächst zurückstellen |
|---|---|
| Häufige, wiederkehrende Aufgaben | Seltene Sonderfälle, die nur wenige Male pro Jahr auftreten |
| Daten sind digital und die Quelle ist klar | Daten liegen verstreut in persönlichen Dateien, E-Mails oder informellem Wissen |
| Regeln sind relativ klar, Antworten nachvollziehbar | Problemdefinition ist unklar, Abteilungen widersprechen sich |
| Fehler können geprüft und korrigiert werden | Fehler hätten unmittelbar schwere rechtliche, finanzielle oder Sicherheitsfolgen |
| Es gibt einen fachlichen Owner mit Veränderungsmandat | Nur IT oder Beratung treiben das Thema, der Fachbereich bleibt passiv |
| KPIs sind messbar: Zeit, Qualität, Kosten, Beschwerden | Es geht nur allgemein um „Innovation“ oder „mehr KI“ |
Die rechte Spalte bedeutet nicht, dass ein Use Case nie geeignet ist. Sie bedeutet: Erst Daten, Prozess, Verantwortung und Governance klären – dann KI einsetzen.
Eine kurze Checkliste vor dem Start
Vor jedem KI-Projekt helfen diese zehn Fragen:
- Welches konkrete Geschäftsproblem wird gelöst?
- Wie sieht der heutige Ausgangswert aus – Zeit, Fehlerquote, Kosten oder Beschwerden?
- Wer ist fachlicher Owner und darf den Prozess ändern?
- Tritt das Problem wirklich häufig genug auf?
- Sind die nötigen Daten vorhanden, zugänglich und aktualisierbar?
- Sind Berechtigungen, Datenschutz, Recht, Sicherheit und Audit-Anforderungen geklärt?
- In welches reale System oder welchen Workflow fließt die KI-Ausgabe?
- In welchen Fällen ist Human-in-the-loop zwingend?
- Welche KPI-Schwellen definieren Erfolg, Skalierung und Stopp?
- Gelten Daten, Prozess und Risiken auch noch, wenn eine zweite Abteilung hinzukommt?
Fazit: Erst einen Prozess belastbar machen, dann skalieren
Enterprise AI wird nicht dadurch erfolgreich, dass ein Unternehmen möglichst früh ein großes Modell einkauft. Erfolgreich wird sie, wenn ein klarer Prozess besser funktioniert als vorher.
Das Modell ist wichtig, aber es ist nicht die ganze Umsetzung. Entscheidend sind nutzbare Daten, klare Berechtigungen, ein veränderbarer Workflow, kontrollierte Risiken, ein verantwortlicher Fachbereich und KPIs, die echten Wert zeigen. Wer zuerst einen Prozess sauber zum Laufen bringt, hat eine Grundlage für Skalierung. Wer nur PoCs sammelt, bleibt im Experimentiermodus.
