Der KI-Zeitplan von 12 bis 18 Monaten ist ein Produkt des Beschaffungsprozesses

Fragen Sie einen Anbieter, wie lange das Deployment dauert, und Sie erhalten eine Spanne. Fragen Sie einen Enterprise-Einkäufer, womit er budgetiert hat, hören Sie oft 12 bis 18 Monate. Beide Zahlen sind ehrlich gemeint, und sie messen Unterschiedliches. Der Anbieter zählt die Konfiguration. Sie zählen die Zeit zwischen der Unterschrift und dem ersten autonom gelösten Ticket.

Die größere Zahl verdient einen genaueren Blick, denn sie ist keine Eigenschaft der Technologie. Der Zeitrahmen von 12 bis 18 Monaten, von dem die meisten Unternehmen ausgehen, ist ein Artefakt des Beschaffungsprozesses, keine Produktanforderung. Er entsteht, weil 3 Workstreams nacheinander statt gleichzeitig laufen.

Die 3 Verzögerungsfaktoren – und warum sie nacheinander ablaufen

Zuerst kommt die Anbieterauswahl. Anforderungen werden formuliert, Demos angesetzt, eine Shortlist entsteht, eine Entscheidung fällt. Erst dann beginnt das Security Review, denn niemand will Compliance-Prüfungen für 5 Anbieter durchführen, wenn 4 davon ohnehin verlieren. Danach startet die Integrationsplanung, weil es nach Verschwendung aussieht, Integrationen für einen Anbieter zu scopen, den man noch nicht gewählt hat.

Auf dem Papier ergibt das alles durchaus Sinn. Zusammengenommen entsteht jedoch ein ineffizienter Zeitplan, in dem sich nichts überschneidet. Die parallele Durchführung ist unbequem, denn sie bedeutet, Aufwand in Security Reviews für Anbieter zu stecken, die nicht gewinnen werden, und Integrationen zu scopen, die womöglich verworfen werden. Sie ist aber auch der mit Abstand größte Hebel für die Deployment-Dauer – und die verworfene Arbeit ist günstig im Vergleich zu einem verlorenen Quartal an Wertschöpfung durch die neuen Fähigkeiten.

Was passiert, wenn sich der Zeitplan dehnt

Gartner erwartet, dass bis Ende 2027 mehr als 40 % der Agentic-AI-Projekte eingestellt werden, und nennt als Gründe steigende Kosten, unklaren Geschäftswert und unzureichende Risikokontrollen. In derselben Analyse hält Gartner fest, dass die Integration von Agenten in Legacy-Systeme oft technisch komplex ist, Workflows stört und kostspielige Anpassungen erfordert.

Diese 2 Befunde beschreiben ein und dasselbe Fehlermuster. Projekte werden selten eingestellt, weil ein Modell im Test schwächelte. Sie werden eingestellt, weil die Integrationsarbeit immer weiter wuchs, während der Business Case auf Ergebnisse wartete, die ausblieben. Ein langer Zeitplan ist nicht einfach nur langsam – er schafft die Bedingungen, unter denen ein Abbruch zur rationalen Entscheidung wird.

Wo die Architektur jede Phase verlängert

Bei einem Migrationsmodell werden Artikel exportiert und umformatiert, die Taxonomie neu aufgebaut, die Ticket-Historie importiert, Berechtigungen neu zugeordnet und die Identitätsverwaltung neu verdrahtet, bevor die eigentliche Konfiguration überhaupt beginnt. Hinzu kommen Kosten, die niemand beziffert. Während der Migration ist Ihre Wissensdatenbank faktisch eine Baustelle: Das Team, das sie pflegt, hört entweder auf zu aktualisieren oder pflegt an 2 Stellen. Produkte werden ausgeliefert, Richtlinien ändern sich, und die migrierte Kopie ist auf eine Weise veraltet, die niemand bemerkt – bis ein Kunde die alte Antwort bekommt.

Bei einem Overlay-Modell verbindet sich der Agent mit den Systemen, die Sie bereits betreiben, liest Wissen dort, wo es liegt, und handelt über die Tools, die Ihr Team ohnehin nutzt. Nichts wird verschoben, also verkürzt sich die Integrationsphase, und der Stillstand entfällt. Dieselbe Logik gilt für Voice: Voice-to-Voice-Agenten verbinden sich mit Ihrer bestehenden Telefonie, statt zuerst eine Migration der Telefonanlage vorauszusetzen.

Die Abhängigkeitskette, die zu spät geplant wird

Wissen ist der sichtbare Teil. Im Rest der Kette steckt der eigentliche Aufwand der Integrationsplanung – deshalb ist ein früher Start wichtiger als ein schneller Abschluss.

• Identität. Der Agent muss wissen, mit wem er spricht. Damit wird er Teil Ihres Single Sign-on und Ihrer Kundenauthentifizierung – und landet in der Warteschlange Ihres Security-Teams.
• Berechtigungen. Ein Agent, der Anliegen löst, muss handeln dürfen. Jemand legt fest, welche Aktionen bei welchen Kontotypen bis zu welchen Schwellenwerten erlaubt sind und wofür ein Mensch nötig ist. Das ist eine Richtlinienfrage für Entscheider, kein Engineering-Ticket.
• Nachgelagerte Systeme. Eine Rückerstattung betrifft die Abrechnung. Eine Adressänderung betrifft das Order Management. Jede Anbindung ist für sich genommen unkompliziert, und jede hat einen Verantwortlichen, der im ursprünglichen Projektplan nicht vorkam.

Nichts davon verschwindet, egal mit welcher Architektur. Die Frage ist, ob Sie in Woche 1 damit beginnen oder erst nach Abschluss eines Datenprojekts.

Wie die verkürzte Variante aussieht

K1x ging live und erreichte innerhalb der ersten Woche 80 % autonome Lösungsquote. Kein Pilot in Woche 1 mit späterem Produktivbetrieb, sondern Lösungen in Woche 1. Papaya Pay erreichte in 3 Wochen 90 % autonome Lösungsquote. Über alle Enterprise-Deployments hinweg liegen im Schnitt 4 bis 6 Wochen zwischen Vertrag und Produktivbetrieb.

Diese Zeitrahmen sind nicht das Ergebnis außergewöhnlich gut vorbereiteter Kunden. So sieht es aus, wenn keine Migration auf dem kritischen Pfad liegt und sich die 3 Verzögerungsfaktoren überschneiden, statt sich hintereinander einzureihen.

Fragen, die den tatsächlichen Zeitplan offenlegen

• Liest der Agent unser Wissen direkt an der Quelle, oder braucht er eine Kopie?
• Wenn unser Team einen Artikel aktualisiert: Wie lange dauert es, bis sich die Antwort des Agenten ändert?
• Was muss migriert werden, bevor das erste Ticket autonom gelöst wird?
• Welche Integrationen sind heute nativ verfügbar, und welche werden während des Onboardings gebaut?
• Wie schnell hat ein Kunde bisher den Produktivbetrieb erreicht, und was hat ihn so schnell gemacht?

Haken Sie bei der letzten Frage nach. Schnelle Deployments haben meist eine gemeinsame Ursache – und ein Anbieter, der sie nicht benennen kann, hatte vielleicht eher Glück als die richtige Architektur.

Warum der Zeitplan die Strategie ist

Ein Deployment, das in Wochen live ist, ermöglicht Ihnen, die Resolution Rate anhand realer Volumina zu messen, solange die Budgetdiskussion noch offen ist. Eines, das Quartale braucht, liefert die ersten echten Daten erst nach der Entscheidung, die davon abhing. Diese Reihenfolge trennt – mehr als jeder Modell-Benchmark – die Programme, die verlängert werden, von denen, die abgeschrieben werden.

The 90-Day Pilot Scope beschreibt einen Referenzumfang, um die Lösungsquote vor einem breiten Rollout nachzuweisen – basierend auf dem Kapitel „Deployment Paradox“ des State of AI in CX 2026 Report .