Einen KI-Implementierungspartner nach Referenzen und Portfolio zu wählen, sagt Ihnen, ob der Partner bauen kann. Es sagt fast nichts darüber aus, ob Sie das Gebaute nach dem Ende des Projekts selbst betreiben können. Die entscheidende Frage ist einfacher: Was hinterlässt der Partner? Unternehmen, die langfristig den größten Nutzen aus der Implementierung ziehen, haben Partner gewählt, die Kompetenz übertragen haben – keine Partner, die Abhängigkeit aufgebaut haben.
Einen Partner für den Aufbau eines KI-Agent-Systems zu wählen gleicht der Auswahl eines Spezialisten: Referenzen prüfen, bisherige Projekte ansehen, Angebote vergleichen. Diese Signale sagen Ihnen, ob der Partner liefern kann. Sie sagen fast nichts darüber aus, ob Sie das System nach dem Projektende selbst betreiben können.
Die zweite Frage ist die entscheidende für den langfristigen Wert – und die meisten Auftraggeber stellen sie erst, wenn sie bereits in einer Abhängigkeit stecken, die sie nicht erwartet haben.
Wie die meisten Unternehmen Implementierungspartner bewerten – und was sie dabei übersehen
Die Standardbewertung umfasst drei Bereiche: technische Kompetenz (mit welchen Tools arbeitet der Partner?), Portfolio (was haben sie für ähnliche Unternehmen gebaut?) und Kosten.
Keines dieser Kriterien zeigt, ob der Partner Wissen überträgt oder Zugang behält. Es sind angebotsseitige Signale – Belege, dass der Partner die Arbeit erledigen kann. Sie sagen nichts über das nachfrageseitige Ergebnis aus: ob Ihr Unternehmen das System nach dem Projektende selbst betreiben, anpassen und erweitern kann.
Menlo Ventures stellte fest, dass 76 % der KI-Anwendungsfälle in Unternehmen heute extern vergeben statt intern gebaut werden – gegenüber 53 % im Jahr 2024.[¹] Mit der Verlagerung von internen Teams zu externen Partnern ist die Partnerwahl zum wichtigsten Faktor für KI-Ergebnisse geworden – mehr als die Tool-Auswahl, mehr als die Use-Case-Selektion. Eine falsche Tool-Entscheidung lässt sich korrigieren. Aus einer Abhängigkeitsstruktur auszusteigen ist deutlich schwieriger.
| Bewertungssignal | Was es zeigt | Was es nicht zeigt |
|---|---|---|
| Technische Zertifikate | Technische Fähigkeit des Partners | Ob er plant, diese zu übertragen |
| Portfolio bisheriger Projekte | Umsetzungserfahrung | Wie die Exit-Struktur dieser Projekte war |
| Angebotspreis | Kosten für den Build | Kosten im zweiten Jahr bei eingebauter Abhängigkeit |
| Referenzkunden | Allgemeine Zufriedenheit | Ob diese Kunden das System heute selbst betreiben können |
Die fehlende Frage an jede Referenz: „Wenn Sie heute ohne Ihren Partner eine Änderung am System vornehmen wollten – könnten Sie das?" Diese Antwort ist aussagekräftiger als jedes Portfolio-Review.
Welche Kriterien tatsächlich Implementierungsqualität vorhersagen
Technische Qualifikationen und Portfolio sind notwendig, aber nicht hinreichend. Diese fünf Kriterien zeigen, ob die Projektstruktur Ihrem Unternehmen auch nach dem Ende des Projekts nützt.
Branchenwissen. Nicht allgemeine KI-Expertise, sondern spezifische Vertrautheit mit Ihren Abläufen. Ein Partner, der Agent-Systeme für Marketingagenturen gebaut hat, weiß, dass kundenspezifische Ton-Anforderungen existieren, dass CRM-Daten oft inkonsistent sind und dass Freigabefristen je nach Kunde variieren. Einem Partner ohne diesen Kontext müssen Sie ihn während Ihres Projekts beibringen – auf Ihre Kosten. Fragen Sie konkret: Für welche Unternehmen in diesem Bereich haben Sie bereits gebaut, und welche Komplikationen sind dabei am häufigsten aufgetreten?
Wissenstransfer. Das wichtigste Kriterium. Fragen Sie direkt: Welche Dokumentation erhalten wir am Ende des Projekts? In welchem Format – ein geteiltes Dokument, eine aufgezeichnete Einführung, ein kommentierter Code? Welche Schulungen bieten Sie unserem Team an? Die Antwort zeigt, ob Wissenstransfer Teil des Modells ist oder nicht. Ein Partner, der antwortet: „Sie können uns jederzeit für Support kontaktieren", signalisiert, dass Abhängigkeit – nicht Kompetenz – der geplante Exit ist.
Integrationsumfang. Die meisten Agent-Systeme verbinden sich mit mehreren bestehenden Tools – CRM, E-Mail, Kalender, Projektmanagement, Kommunikationsplattformen. Anzahl, Qualität und Edge-Case-Behandlung der Integrationen bestimmen, wie viel des Werts vom System abhängt und wie viel vom laufenden Partnereinsatz. Fragen Sie: Welche Integrationen sind im Build-Umfang enthalten? Was passiert, wenn eine davon ihre API ändert – ist das abgedeckt oder wird es separat berechnet?
Definition des Post-Launch-Supports. Es gibt einen erheblichen Unterschied zwischen einem Partner, der „Post-Launch-Support" anbietet, und einem, der genau definiert, was dieser Support umfasst. Offene Support-Formulierungen schaffen ein laufendes Abrechnungsverhältnis, dessen Umfang der Partner nachträglich festlegt. Verlangen Sie den Post-Launch-Umfang schriftlich: Was ist inbegriffen, wie lange, welche Reaktionszeiten sind garantiert, was fällt außerhalb des definierten Umfangs?
Exit-Bedingungen. Was gehört Ihnen am Ende des Projekts? Die gesamte Konfiguration und der Code? Zugang zu Prompts und Workflow-Logik? Die API-Verbindungen? Ein Partner, der das Projekt so strukturiert, dass laufende Beteiligung erforderlich – nicht optional – ist, profitiert von Ihrer Unfähigkeit, ohne Probleme zu wechseln. Klären Sie die Eigentumsrechte explizit im Vertrag, bevor die Arbeit beginnt.
Die Abhängigkeitsfalle – wie sie aussieht, bevor Sie darin sitzen
Ein Partner, der Wissenstransfer nicht vertraglich definiert, landet standardmäßig bei Abhängigkeit. Jeder Wartungsanruf, jede Prompt-Anpassung, jede Integrationsänderung wird abgerechnet – nicht weil der Partner unehrlich ist, sondern weil Wissenstransfer nie vereinbart wurde.
Abhängigkeit entsteht meist nicht durch schlechte Absicht. Sie entsteht durch vagen Leistungsumfang. Das Projekt ist auf die Lieferung eines funktionierenden Systems ausgerichtet. Wissenstransfer wird nie explizit erwähnt. Die Dokumentation bleibt dünn. Das Team des Partners erledigt die Integrationsarbeit intern. Am Ende des Projekts funktioniert das System – und der Kunde hat kein klares Bild davon, wie es funktioniert oder wie er es ändern könnte.
Sechs Monate später ändert das CRM seine API. Oder ein neuer Workflow muss hinzugefügt werden. Oder die Prompts müssen angepasst werden, weil sich das Geschäft verändert hat. Jede dieser Änderungen erfordert den Partner – und jede wird zu seinem Stundensatz oder gegen einen offenen Wartungsvertrag abgerechnet.
Die Struktur fühlt sich wie Support an. Sie funktioniert als Exit-Barriere, die von Anfang an in den Projektumfang eingebaut wurde.
Das früheste Warnsignal ist ein Angebot, das sehr spezifisch ist, was gebaut wird, aber vage bleibt, was übertragen wird. Partner verkaufen den Build – diese Spezifität ist zu erwarten. Vagheit beim Transfer ist das Diagnosesignal. Fragen Sie direkt in der Evaluierungsphase: Wenn wir dieses System in einem Jahr selbst anpassen oder einem internen Team übergeben wollten – was wäre dafür nötig? Die Antwort zeigt die beabsichtigte Struktur des Verhältnisses.
Einen vollständigen Überblick darüber, was eine gute Implementierung in jeder Phase beinhaltet, finden Sie in what a real AI agent implementation involves.
Was der erste Projektauftrag umfassen sollte
Ein gut konzipierter KI-Agent-Auftrag deckt sechs Elemente schriftlich ab, bevor die Arbeit beginnt.
Die Workflow-Definition. Eine präzise Beschreibung des automatisierten Prozesses: Was löst den Agent aus, welche Aktionen führt er aus, welche Entscheidungen trifft er eigenständig, und was erfordert menschliche Freigabe. Ohne diese Grundlage driftet der Umfang und damit der Build.
Die Integrationsliste. Jedes Tool, mit dem sich das System verbindet – welche Systeme, welche APIs, welche Daten fließen wohin. Diese Liste definiert auch die Wartungsoberfläche: Jede Integration ist eine Abhängigkeit, die unabhängig brechen kann.
Dokumentations-Deliverables. Welche Dokumentation der Auftraggeber am Ende erhält – als benanntes, konkretes Ergebnis. Dies sollte die Workflow-Logik, die Prompt-Struktur, die Integrationskonfiguration und bekannte Edge Cases und Fehlermodi umfassen. Wenn Dokumentation kein benanntes Deliverable im Angebot ist, gehen Sie davon aus, dass sie nicht zum Umfang gehört.
Schulung. Wie der Partner das Betriebswissen an Ihr Team überträgt. Mindestens: eine Einführung in die Funktionsweise des Systems, wie Agent-Outputs zu überprüfen sind, wie Prompts bei Bedarf angepasst werden können, und wie mit häufigen Fehlermodi umzugehen ist.
Launch-Kriterien. Wie beide Seiten wissen, dass das System funktioniert. Was der Agent tun soll, in welchem Umfang, mit welcher Genauigkeit. Ohne vereinbarte Launch-Kriterien ist „fertig" das, was der Partner entscheidet.
Out-of-Scope-Definition. Was der Auftrag explizit nicht abdeckt. Diese Grenze verhindert Scope Creep während des Builds und unerwartete Abrechnungen danach.
Warnsignale in der Angebotsphase
Die meisten Probleme mit Implementierungspartnern sind sichtbar, bevor der Vertrag unterschrieben wird.
Kein Dokumentations-Deliverable benannt. Wenn das Angebot beschreibt, was gebaut wird, aber Dokumentation nicht als konkretes Ergebnis aufführt, wird sie keine Priorität haben. Bitten Sie darum, sie explizit hinzuzufügen. Wenn der Partner sich widersetzt oder sie als unnötig darstellt, ist das ein Diagnosesignal.
Vage Post-Launch-Bedingungen. „Laufender Support verfügbar" ist kein Leistungsumfang. Ein definierter Post-Launch-Umfang – was ist inbegriffen, wie lange, zu welchem Preis – sollte im Angebot stehen. Offene Support-Formulierungen begünstigen den Partner.
Stundensatz-Abrechnung für den Build. Festpreisverträge richten den Anreiz des Partners auf effiziente Lieferung aus. Stündliche Abrechnung für den Build-Abschnitt verlagert das gesamte Lieferrisiko zum Auftraggeber. Wenn das Angebot auf Stundenbasis ist, fragen Sie nach einer Budget-Einschätzung und einem klaren Auslöser für Umfangs-Review-Gespräche.
Referenzen ohne Spezifika. „Wir haben mit Hunderten von Unternehmen gearbeitet" ist keine Referenz. Bitten Sie um zwei oder drei konkrete Kunden aus Ihrer Branche – mit der Erlaubnis, diese direkt zu kontaktieren. Fragen Sie diese Referenzen: Können Sie das System heute ohne den Partner ändern?
Kein Eigentumssprachregelung. Wenn geistiges Eigentum, Konfigurations-Eigentumsrechte oder Ihre Möglichkeit, das System zu einem anderen Anbieter zu migrieren, im Angebot nicht angesprochen wird, gehen Sie von Ambiguität aus. Klären Sie es schriftlich vor der Unterzeichnung.
Beide Partner liefern ein System. Nur einer lässt Sie es selbst betreiben.
Menlo Ventures stellte fest, dass KI-Projekte zu 47 % die Produktionsphase erreichen – fast doppelt so oft wie traditionelle SaaS-Implementierungen mit 25 %.[¹] Der Konvertierungsvorteil kommt von der Anpassungsfähigkeit von KI an spezifische Workflows. Aber die Produktionsphase ist nicht das Ende der Geschichte. Unternehmen, die langfristig am meisten von der Implementierung profitieren, können das System anpassen, verbessern und erweitern – ohne jedes Mal den Partner zu rufen.
Der richtige Implementierungspartner macht das möglich. Der falsche macht es teuer. Der Unterschied ist im Leistungsumfangsdokument sichtbar, bevor die Arbeit beginnt – wenn Sie wissen, worauf Sie achten müssen.
Lesen Sie before you hire für die Vorbereitung auf das erste Implementierungsgespräch, und implementation timeline für den konkreten Ablauf vom Scoping bis zum Go-Live.
Häufig gestellte Fragen
Worauf sollte ich bei der Wahl eines KI-Implementierungspartners achten? Die fünf maßgeblichen Kriterien sind: branchenspezifisches Wissen, ein definierter Wissenstransfer-Plan, eine benannte Integrationsliste mit Wartungsbedingungen, ein schriftlicher Post-Launch-Umfang und explizite Exit-Bedingungen bezüglich Eigentum. Technische Qualifikationen sind wichtig – aber sie sagen aus, ob ein Partner bauen kann, nicht ob Sie das Ergebnis betreiben können.
Woran erkenne ich, ob ein KI-Implementierungspartner Abhängigkeit aufbaut? Warnsignale: Dokumentation bleibt beim Partner intern, Ihr Team wird nicht geschult, jede Änderung erfordert den Partner, und der Vertrag definiert nicht, was Ihnen bei Projektende gehört. Fragen Sie direkt: „Was wäre nötig, wenn wir dieses System in einem Jahr selbst anpassen wollten?" Die Antwort ist die aufschlussreichste Frage in der Bewertungsphase.
Wie lange dauert eine KI-Agent-Implementierung typischerweise? Ein Standard-Workflow geht in zwei bis vier Wochen von der Konzeption bis zum Go-Live. Die KI-Konfiguration dauert Tage; Integrationen mit bestehenden Tools füllen den Rest. Builds mit mehreren Systemen können sechs bis acht Wochen dauern. Der Zeitplan sollte im Leistungsumfang stehen.
Was kostet eine KI-Agent-Implementierung realistischerweise? Ein definierter Workflow-Build liegt typischerweise zwischen 1.000 und 15.000 €, abhängig von Komplexität und Integrationsanzahl. Laufende Betreuung wird separat abgerechnet. Vereinbaren Sie einen Festpreis für den Build und einen schriftlichen Umfang für den Post-Launch-Support vor der Unterzeichnung.
Quellenangaben
- Menlo Ventures. (2025). „2025: The State of Generative AI in the Enterprise." Menlo Ventures. https://menlovc.com/perspective/2025-the-state-of-generative-ai-in-the-enterprise/ — Quelle für: 76 % der KI-Anwendungsfälle in Unternehmen werden extern vergeben (gegenüber 53 % in 2024); 47 % KI-Konvertierungsrate in Produktion vs. 25 % für traditionelle SaaS.
- CIO / Lenovo. (2025). „What to look for in an AI implementation partner." CIO. https://www.cio.com/article/4089704/what-to-look-for-in-an-ai-implementation-partner.html — Quelle für: Lenovo-Studie mit 2.920 IT- und Business-Entscheidungsträgern; Unternehmen sind stark auf professionelle Dienstleistungspartner für KI-Implementierungen angewiesen.