KI-Beratung oder eigenes KI-Team: Wie Sie entscheiden

Die Entscheidung lautet in Wahrheit nicht „Beratung oder eigenes Team“. Sie ist eine Frage der Reihenfolge: Was müssen Sie wissen, bevor Sie bereit sind, dafür jemanden fest einzustellen? Unternehmen, die zuerst einstellen und später validieren, haben am Ende teure Spezialisten, die einen Use Case pflegen, nach dem niemand gefragt hat. Unternehmen, die dauerhaft alles auslagern, mieten am Ende eine Fähigkeit, die sie eigentlich besitzen wollten.

Dieser Leitfaden vergleicht beide Wege anhand der sieben Faktoren, die tatsächlich den Ausschlag geben, ergänzt den Mittelweg, den die meisten europäischen Mittelständler am Ende wählen, und endet mit einer Zuordnung Ihrer Situation zum nächsten Schritt. Er geht davon aus, dass Sie ein mittelständisches Unternehmen aus dem Gesundheitswesen, der Fertigung oder einer vergleichbar regulierten Branche sind und Ihr erstes oder zweites ernsthaftes KI-System erwägen.

Sollten Sie eine KI-Beratung beauftragen oder ein eigenes KI-Team aufbauen?

Beauftragen Sie eine KI-Beratung, solange das Problem noch eine Frage ist, und bauen Sie ein eigenes KI-Team auf, sobald daraus Routine geworden ist. Der Grund liegt nicht in der Qualität der Leute: Ein eigenes Team ist eine feste Verpflichtung, die Sie im Voraus eingehen, ein Mandat dagegen eine variable, die gegen einen definierten Scope läuft. Bevor ein Use Case validiert ist, wissen Sie noch nicht, welche Spezialisten Sie brauchen, eine Einstellung legt Sie also auf eine Vermutung fest. Sobald ein System produktiv läuft und sich rechnet, dreht sich die Rechnung um: Ein festes Team verteilt sich über viele Projekte und sammelt Domänenwissen an, das keine externe Partei erreicht. Der folgende Vergleich zeigt, wie sich beide Wege in den Faktoren unterscheiden, die reale Fälle entscheiden, inklusive Mittelweg, denn genau den wählen die meisten mittelständischen Unternehmen tatsächlich.

Zwei Zeilen entscheiden die meisten realen Fälle: die Zeit bis zum ersten produktiven Use Case und das Hiring-Risiko. Der Rest ist in der Regel verhandelbar.

Worauf legt Sie ein eigenes KI-Team tatsächlich fest?

Ein eigenes KI-Team legt Sie auf Fixkosten fest, die sofort anfallen, und auf nutzbaren Output, der deutlich später einsetzt; in der Lücke zwischen diesen beiden Zeitpunkten sitzt die meiste Enttäuschung. Ein minimal tragfähiges Team besteht meist aus drei Personen: einem Data Scientist, einem Machine-Learning-Engineer und jemandem, der die Daten-Pipelines verantwortet, denn eine Person für alle drei Rollen ist eher ein Single Point of Failure als ein Team. Senior-Machine-Learning-Leute zu finden dauert im deutschen und im weiteren europäischen Markt Monate, Kündigungsfristen kommen hinzu, und neue Mitarbeitende brauchen Zeit mit Ihren Daten und Ihrer Domäne, bevor ihr Output belastbar ist. Dann muss jemand sie führen: eine KI-kundige Führungskraft, die Prioritäten setzt und Nein sagt, also eine zweite Einstellung, die die meisten Pläne stillschweigend auslassen. Nichts davon spricht gegen den Aufbau eines Teams. Es spricht dagegen, eines aufzubauen, bevor die Arbeit existiert, die es rechtfertigt, denn das Team, das Sie einstellen, wird die Roadmap definieren, die es braucht, um ausgelastet zu bleiben.

Wann ein eigenes Team klar richtig ist

Bauen Sie intern auf, wenn KI das Produkt ist und nicht eine unterstützende Funktion, wenn bereits mehrere Systeme laufen und einen stetigen Strom an Arbeit erzeugen, oder wenn Datenrestriktionen externen Zugriff tatsächlich unpraktikabel machen. In diesen Fällen verteilen sich die Fixkosten auf genug Projekte, um gegenüber einzelnen Mandaten zu gewinnen, und das Domänenwissen wächst kumulativ.

Das Fehlermuster, das Sie vermeiden sollten

Der teure Fehler ist, gegen einen nicht validierten Use Case einzustellen. Das Team kommt an, stellt fest, dass die Daten die ursprüngliche Idee nicht tragen, und schwenkt auf etwas um, das seine Existenz rechtfertigt. Sie haben dann ein fähiges Team, eine Roadmap, die vom Einstellen statt von der Strategie geformt ist, und einen Budgetverantwortlichen, der fragt, was sich geändert hat.

Worauf legt Sie die Arbeit mit einer KI-Beratung tatsächlich fest?

Eine KI-Beratung legt Sie auf einen Scope und einen Zeitplan fest statt auf Headcount, und genau deshalb passt sie zu einem unbewiesenen Use Case und schlecht zu einem ausgereiften. Sie bekommen Leute, die vergleichbare Systeme bereits gebaut haben, der erste produktive Use Case ist also Wochen entfernt statt Quartale, und wenn sich die Idee als untragfähig erweist, hören Sie auf. Was Sie stattdessen übernehmen, ist Abhängigkeitsrisiko: Wenn nichts dokumentiert ist und niemand auf Ihrer Seite am Bau beteiligt war, geht das Wissen mit dem Ende des Mandats. Das ist ein Vertragsproblem und kein grundsätzlicher Mangel. Dokumentation, Übergabe und Ihre eigenen Engineers an der Seite des externen Teams legen Sie im Scope fest, und ein Partner, der sich dagegen sträubt, sagt Ihnen damit etwas Nützliches. Bewerten Sie ein Mandat danach, ob es Sie fähiger zurücklässt, nicht nur danach, ob es liefert.

Was in den Scope gehört

Benennen Sie die Liefergegenstände, die das Mandat überdauern: die Übertragung von Code und Modellgewichten, eine Architekturdokumentation, Runbooks für das produktive System und namentlich benannte Personen auf Ihrer Seite, die Teil des Baus sind. Ohne diese haben Sie ein Ergebnis gekauft und keine Fähigkeit, was in Ordnung ist, wenn es so gewollt war, und teuer, wenn nicht.

Wie fällt diese Entscheidung im Gesundheitswesen aus?

Im Gesundheitswesen entscheidet meist nicht die fachliche Fähigkeit, sondern der geregelte Zugang zu Daten. Eine Klinik oder ein Medizinsoftware-Unternehmen, das ein eigenes Team gegen einen Partner abwägt, fragt in Wahrheit: Wer darf Patientendaten anfassen, auf welcher vertraglichen Grundlage, und wer kann das hinterher nachweisen? Gesundheitsdaten sind besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO, eine Verarbeitung in großem Umfang erfordert in der Regel eine DSFA (Datenschutz-Folgenabschätzung), und wenn das System die Diagnostik unterstützt, kann es zusätzlich ein reguliertes Medizinprodukt sein. Ein eigenes Team umgeht den Auftragsverarbeitungsvertrag vollständig, was ein echter Vorteil ist. Ein Partner kann innerhalb dieses Rahmens arbeiten, aber nur mit dokumentierter Grundlage, begrenztem Zugriff und Audit-Logging, und für ein erstes Projekt lautet die pragmatische Antwort oft: identifizierbare Daten bleiben in Ihrer Umgebung, das externe Team arbeitet auf anonymisierten oder synthetischen Daten, bis der Fall bewiesen ist. Unsere KI-Praxis für das Gesundheitswesen beschreibt die Rahmenbedingungen im Detail, und es lohnt sich zu lesen, wo sich DSGVO und EU AI Act überschneiden, bevor Sie sich für einen der beiden Wege entscheiden.

Wie fällt diese Entscheidung in der Fertigung aus?

In der Fertigung entscheidet meist die Anlage und nicht das Modell. Ein System zur Sichtprüfung oder für Predictive Maintenance steht und fällt mit Linienzugang, Sensordatenqualität, der Integration in SPS und MES und der Frage, ob Bediener ihm genug vertrauen, um danach zu handeln, und nichts davon löst derjenige, der das Modell schreibt. Das spricht beim ersten System für ein Mandat, denn ein externes Team, das bereits in Produktionslinien integriert hat, findet in Wochen die Randbedingungen, die eine interne Neueinstellung über Monate entdeckt. Für ein eigenes Team spricht es später, sobald die Integrationsmuster etabliert sind und die Arbeit zu einem stetigen Strom neuer Linien und neuer Fehlerklassen wird statt zu einer Forschungsfrage. Entscheidend ist das Verhältnis von Modellierung zu Integration: Wenn die Integration überwiegt, und das tut sie meistens, schlägt Domänenzugang die Rekrutierung von Spezialisten. Unsere KI-Praxis für die Fertigung beschreibt diese Arbeit.

Welcher Weg passt zu Ihrer Situation?

Ordnen Sie Ihre Situation dem nächsten Schritt zu und nicht einer Philosophie, denn dasselbe Unternehmen braucht für verschiedene Use Cases oft verschiedene Antworten. Vier Situationen decken die meisten Fälle ab:

1. Die Chance ist unklar, oder Sie sind unsicher, ob die Daten sie tragen. Beginnen Sie mit einem AI Readiness Audit. Er sagt Ihnen, welcher Use Case den Aufbau wert ist und ob Ihre Daten ihn tragen, bevor Sie sich auf eine Einstellung oder ein Mandat festlegen. In dieser Phase einzustellen ist der teuerste Weg, es herauszufinden.
2. Der Use Case ist definiert, aber unbewiesen. Fahren Sie einen klar abgegrenzten Proof of Value: ein schmales System, eine vorher gemessene Baseline, ein Schwellenwert, den jemand unterschrieben hat, und die Erlaubnis aufzuhören. Unsere Leistungspakete enthalten genau diesen Zuschnitt.
3. Sie haben etwas in Produktion und brauchen jemanden, der es verantwortet. Hier passt ein Fractional AI Lead: Senior-Verantwortung für Roadmap, Architektur und Anbieterentscheidungen, ohne eine Führungskraft in Vollzeit einzustellen, während Ihre eigenen Engineers bauen.
4. KI ist zentral und die Auslastung ist durchgehend. Bauen Sie das eigene Team auf und erwägen Sie, externe Unterstützung für die Spezialarbeit zu behalten, die keine feste Stelle rechtfertigt. Wenn Sie den Übergang begleitet haben wollen: Wir strukturieren Mandate so, dass sie übergeben und nicht verlängert werden.

Wenn Sie zwischen den ersten beiden stehen: die Bereitschaft zu prüfen kostet weniger als zu raten, und Sie sollten wissen, welchen Return Sie realistisch erwarten können, bevor Sie eine der beiden Optionen dimensionieren.

Ändert sich die richtige Antwort mit dem Wachstum?

Die richtige Antwort ändert sich für ein Unternehmen, das KI aktiv einführt, etwa einmal im Jahr, und genau deshalb ist es der eigentliche Fehler, sie als dauerhafte Identitätsentscheidung zu behandeln. Ein realistischer Pfad verläuft so: ein Audit, um den Use Case zu finden, ein externes Team, um ihn zu beweisen, ein Fractional AI Lead, der ihn verantwortet, während Ihre Engineers ihn lernen, und ein festes Team, sobald die Auslastung dauerhaft genug ist, um es zu beschäftigen. Jeder Schritt sollte den nächsten günstiger machen, und der Test für den vorherigen Schritt lautet, ob er Sie fähiger zurückgelassen hat statt abhängiger. Unternehmen, die direkt zum festen Team springen, zahlen die Validierung meist trotzdem, nämlich in Form eines ersten Jahres, in dem kompetent das Falsche gebaut wird. Das zu vermeiden ist vor allem eine Frage der Reihenfolge, was auch das Thema von den fünf Fehlern ist, die Unternehmen bei der KI-Integration machen.

Häufig gestellte Fragen

Wie lange dauert es, ein eigenes KI-Team aufzubauen?

Länger, als die meisten Pläne annehmen, sobald Sie Suche, Kündigungsfristen und die Monate einrechnen, bis ein neues Team gemeinsam produktiv ist. Besonders Senior-Machine-Learning-Einstellungen sind schwer zu finden und leicht wieder zu verlieren, weshalb das erste Projekt meist nicht auf das Team warten kann.

Heißt der Einsatz einer Beratung, dass wir nie eigene Fähigkeiten aufbauen?

Nur wenn das Mandat so gebaut ist. Eine gute Konstruktion stellt Ihre Engineers an die Seite des externen Teams und macht Dokumentation und Übergabe zu ausdrücklichen Liefergegenständen. Wissenstransfer entsteht nicht durch Nähe, sondern weil ihn jemand in den Scope geschrieben hat.

Wem gehören Code und Modelle, die wir von einer Beratung bauen lassen?

Demjenigen, den der Vertrag nennt, und genau deshalb gehört die Frage in den Scope und nicht in eine Annahme. Verlangen Sie bei Lieferung die Übertragung des Codes, der trainierten Modellgewichte und der Architekturdokumentation. Ein Partner, der sich darauf nicht festlegen kann, bietet Ihnen Zugang zu einem System an, nicht dessen Eigentum.

Was ist das Risiko, zu früh intern aufzubauen?

Das Risiko besteht darin, für einen Problemzuschnitt einzustellen, den Sie noch nicht definiert haben. Teams, die vor der Validierung des ersten Use Case rekrutiert werden, bauen häufig kompetent das Falsche, und die Kosten sind nicht nur Gehälter, sondern auch die Roadmap, mit der diese Einstellungen ihr eigenes Aufgabenfeld absichern.

Ist das Hybridmodell nur ein Kompromiss?

Das Hybridmodell ist meist die stärkste Option und kein Mittelweg. Externe Senior-Steuerung mit interner Umsetzung bringt die Architekturentscheidungen früh auf den richtigen Stand, während sich das Wissen dort ansammelt, wo es langfristig liegen muss, was keines der beiden reinen Modelle allein erreicht.