KI-Automation selbst bauen oder beauftragen?

Die Entscheidung zwischen Eigenbau und Dienstleister hängt daran, wer die Automation nach dem ersten erfolgreichen Lauf fachlich und technisch betreibt. Ein schneller Prototyp beantwortet diese Frage nicht. Entscheidend für die Auswahl sind der vorhandene Prozess, interne Fähigkeiten, verfügbare Zeit, Schnittstellen und die Folgen eines Ausfalls.

Ein Unternehmen kann die technische Umsetzung einkaufen und trotzdem für Anforderungen, Datenfreigaben und fachliche Abnahme verantwortlich bleiben. Ebenso bedeutet Eigenbau nicht, dass jedes Bauteil selbst entwickelt wird. Häufig werden bestehende Dienste verbunden. Die eigentliche Entscheidung lautet deshalb: Welche Aufgaben übernimmt das Team selbst, welche werden beauftragt und wie funktioniert die Übergabe?

Der folgende Vergleich verwendet einen fiktiven Ablauf zur Bearbeitung von Serviceberichten. Alle Stunden und Preise sind reine Rechenannahmen. Für die Auswahl einzelner Werkzeuge ergänzt ihn der Beitrag über Chatbot, API und Workflow-Plattformen.

Den Liefergegenstand vor der Baufrage festlegen

Im Beispiel sollen eingehende Serviceberichte gelesen, Pflichtangaben geprüft und strukturierte Entwürfe für das bestehende System vorbereitet werden. Die Automation darf keine Kundenanschreiben versenden und keine Rechnungen auslösen. Unklare Angaben landen in einer Prüfliste. Eine Fachperson bestätigt den Entwurf vor der Übernahme.

Diese Beschreibung begrenzt den Auftrag. Ohne sie vergleichen Teams häufig einen kleinen internen Prototyp mit einem Angebot für einen vollständigen Betrieb. Der scheinbare Preisunterschied entsteht dann teilweise aus unterschiedlichen Leistungen. Ein fairer Vergleich enthält dieselben Eingänge, Ergebnisse, Ausnahmefälle und Betriebsanforderungen.

Zum Liefergegenstand gehören deshalb auch die Fehlerwege. Was passiert bei einer beschädigten Datei, einem nicht erreichbaren Dienst oder einem widersprüchlichen Bericht? Wer erkennt, dass ein Vorgang offen bleibt? Wenn diese Fragen fehlen, ist die Kalkulation noch keine belastbare Beschaffungsentscheidung.

Eine hilfreiche Vorarbeit ist ein einseitiger Auftrag mit erlaubten Eingaben, gewünschtem Ergebnis, ausgeschlossenen Aktionen und Abnahmekriterien. Die Anleitung zum Prüfen eines KI-Projektauftrags bietet dafür einen passenden Ausgangspunkt.

Welche Aufgaben auch beim Einkauf intern bleiben

Der Fachbereich muss erklären, was ein richtiges Ergebnis ist. Dazu gehören Beispiele, Gegenbeispiele und die Entscheidung über Ausnahmen. Ein Dienstleister kann bei dieser Arbeit unterstützen. Er kann die fachliche Verantwortung aber nicht allein aus einer allgemeinen Formulierung wie "Berichte intelligent verarbeiten" ableiten.

Die IT beziehungsweise die zuständige technische Rolle klärt Zugänge, Schnittstellen und Betriebsgrenzen. Datenschutz und Informationssicherheit werden dort eingebunden, wo Daten und Risiken es verlangen. Die Zuständigkeiten richten sich nach dem Unternehmen. Dieser Artikel erfindet keine Pflichtrolle für jeden kleinen Betrieb.

Das NIST AI RMF Playbook, Bereich Govern behandelt unter anderem Verantwortlichkeiten und Risiken durch Drittanbieter. Es ist ein freiwilliger Orientierungsrahmen. Für die Beschaffung ist daraus relevant: Ein externer Baustein braucht weiterhin eine interne Einordnung in den eigenen Betrieb.

Im Beispiel benennt das Unternehmen eine fachlich verantwortliche Person für die Serviceberichte und eine technische Ansprechperson für Zugänge und Störungen. Fehlt eine dieser Zuständigkeiten, verschwindet die Arbeit nicht durch den Einkauf. Sie taucht später als offene Rückfrage oder unbetreuter Fehler wieder auf.

Eine Make-or-buy-Matrix mit Ausschlussgründen

Eine Bewertungsmatrix hilft, wenn sie konkrete Nachweise enthält. Allgemeine Noten wie "interne Kompetenz: gut" sind zu ungenau. Besser ist eine beobachtbare Aussage: "Zwei Personen können den bestehenden Workflow anhand der Dokumentation neu einrichten und einen fehlgeschlagenen Lauf wieder aufnehmen."

Einige Punkte sind keine verrechenbaren Vorlieben, sondern Stoppsignale. Fehlende Berechtigung zur Datenverarbeitung lässt sich nicht durch einen günstigen Preis ausgleichen. Ebenso ist eine nicht verfügbare notwendige Schnittstelle kein kleiner Nachteil in einer Gesamtpunktzahl. Solche Bedingungen werden vor einer gewichteten Bewertung geklärt.

Die Matrix ist ein eigenes Entscheidungswerkzeug. Sie liefert keine objektive Punktzahl für alle Unternehmen. Das Team muss Gewichte und Ausschlussgründe anhand seiner tatsächlichen Fehlerkosten festlegen.

Die Vollkosten mit denselben Positionen rechnen

Die Kalkulation enthält einmalige und laufende Arbeit. Beim Eigenbau gehören Analyse, Entwicklung, Tests, Dokumentation und Übergabe dazu. Im Betrieb folgen Überwachung, Änderungen und Störungsbearbeitung. Beim Dienstleister werden neben dem Angebotspreis auch interne Abstimmungen und laufende externe Leistungen berücksichtigt.

Im fiktiven Beispiel benötigt der Eigenbau zunächst 60 interne Stunden. Für die Vergleichsrechnung setzt das Unternehmen einen internen Bewertungsansatz von 80 Euro je Stunde an. Das ergibt 4.800 Euro. Zusätzlich werden über zwölf Monate jeweils vier Stunden Betreuung angesetzt: 48 Stunden oder 3.840 Euro. Zusammen sind das 8.640 Euro, zuzüglich gesondert erfasster Lizenzen und Nutzungskosten.

Das externe Vergleichsangebot beträgt im Beispiel 6.500 Euro für die definierte Umsetzung und 200 Euro monatlich für einen konkret beschriebenen Support. Hinzu kommen 15 interne Stunden für Abstimmung und Abnahme, also 1.200 Euro nach demselben Bewertungsansatz. Über zwölf Monate ergeben sich damit 10.100 Euro, ebenfalls zuzüglich der separat betrachteten Nutzungskosten.

Diese Rechnung behauptet keine Marktpreise. Sie zeigt die Struktur eines Vergleichs. Vor allem sind intern bewertete Stunden nicht automatisch zusätzliche Auszahlungen. Die wirtschaftliche Entscheidung muss erklären, welche andere Arbeit diese Stunden verdrängen und welche Ausgaben tatsächlich entstehen.

Die Annahmen einem Belastungstest unterziehen

Im Beispiel erscheint Eigenbau zunächst günstiger. Verdoppelt sich der laufende Betreuungsaufwand von vier auf acht Stunden pro Monat, steigt die interne Rechnung um weitere 3.840 Euro. Das verändert den Vergleich. Umgekehrt kann ein externer Änderungswunsch zusätzliche Kosten auslösen, die der Supportpreis nicht abdeckt.

Deshalb werden mindestens die unsicheren Positionen variiert: Pflegeaufwand, Fallmenge, Änderungsbedarf und interne Verfügbarkeit. Der Zweck ist keine scheinbar präzise Zukunftsprognose. Das Team erkennt, von welchen Annahmen seine Entscheidung besonders stark abhängt.

Bei der Fallmenge reicht ein Tokenpreis allein nicht. Fehlgeschlagene Läufe, erneute Versuche und manuelle Prüfungen gehören in den Aufwand pro nutzbarem Ergebnis. Die Anleitung zu KI-Kosten pro Ergebnis vertieft diese Rechnung.

Ein sinnvoller nächster Schritt ist ein begrenzter technischer Versuch für die unsicherste Position. Wenn die Schnittstelle das grösste Risiko ist, wird genau diese Verbindung getestet. Ein weiterer schöner Textentwurf löst dieses Risiko nicht.

Eigenbau braucht einen zweiten Bearbeiter

Eine intern entwickelte Automation ist verletzlich, wenn nur eine Person sie versteht. Das gilt auch dann, wenn eine visuelle Plattform den Aufbau einfach erscheinen lässt. Zugangsdaten, Ausnahmeregeln und Wiederanlaufverfahren müssen für berechtigte Kollegen auffindbar sein.

Ich empfehle einen Übernahmetest: Eine zweite Person richtet die Automation anhand der Dokumentation in einer geeigneten Testumgebung ein, verarbeitet einen Normalfall und behandelt einen bewusst eingebauten Fehler. Die erste Person beantwortet dabei keine undokumentierten Detailfragen. Jede solche Frage zeigt eine Lücke in der Übergabe.

Der Test prüft nicht, ob der Kollege dieselben persönlichen Arbeitsgewohnheiten hat. Er prüft, ob das System unabhängig vom Entwickler betreibbar ist. Wenn dafür grundlegende technische Fähigkeiten fehlen, braucht das Unternehmen entweder Qualifizierung oder einen anderen Betriebszuschnitt.

Dieser Aufwand gehört in die Entscheidung. Er entsteht nicht erst nach dem Projekt, sondern ist Teil eines nutzbaren Eigenbaus. Der Beitrag zur Betriebsübergabe eines KI-Piloten beschreibt die dazugehörigen Nachweise.

Externe Umsetzung braucht eine echte Übernahme

Bei einer Beauftragung muss klar sein, welche Konten, Konfigurationen und Dokumente das Unternehmen erhält. Ein Bildschirmvideo des laufenden Systems ersetzt keinen Zugang zur notwendigen Betriebsdokumentation. Ebenso beweist ein Exportknopf noch nicht, dass die Daten nach einem Anbieterwechsel verwendbar sind.

Im Beispiel wird vereinbart, dass der Dienstleister die Konfiguration, das Datenmodell, die Testfälle und die Störungsanleitung übergibt. Die internen Verantwortlichen führen anschliessend einen eigenen Übernahmelauf durch. Erst dabei zeigt sich, ob die gelieferten Unterlagen für den vereinbarten Betrieb ausreichen.

Nicht jede technische Komponente muss dem Unternehmen gehören. Entscheidend ist die transparente Vereinbarung: Welche Abhängigkeit bleibt bestehen? Was kostet sie? Welche Funktionen entfallen bei einer Kündigung? Welche Daten und Einstellungen lassen sich exportieren? Diese Fragen müssen vor der Beauftragung beantwortet werden.

Auch ein betreuter Dienst ist eine legitime Option. Dann lautet die Entscheidung bewusst, Betrieb einzukaufen. Sie darf nicht versehentlich entstehen, weil nach Projektende nur der Dienstleister einen Zugang besitzt.

Die Mischform gezielt nutzen

Eine häufig sinnvolle Option ist eine geteilte Umsetzung. Das interne Team beschreibt den Prozess und erstellt die fachlichen Testfälle. Ein externer Spezialist setzt die schwierige Schnittstelle um. Die laufende Pflege klar begrenzter Vorlagen bleibt intern, technische Änderungen folgen einem vereinbarten Verfahren.

Damit diese Aufteilung funktioniert, braucht jede Grenze einen Übergabepunkt. Wer bewertet einen neuen Dokumenttyp? Wer passt das Datenmodell an? Wer prüft, ob eine Änderung die Zielsystemintegration berührt? Ohne solche Regeln entsteht zwischen internem Team und Dienstleister eine Lücke, in der jeder auf den anderen wartet.

Im Servicebeispiel darf das interne Team Antworttexte ändern, aber keine neuen Pflichtfelder in die Übertragung aufnehmen. Diese Änderung verlangt einen gemeinsamen Test, weil das Zielsystem betroffen ist. Die Grenze wird in der Dokumentation festgehalten und anhand eines Beispiels erklärt.

Einen Abbruch vor dem grossen Auftrag ermöglichen

Bei einer unsicheren Schnittstelle empfehle ich einen getrennten Machbarkeitsschritt mit einem eigenen Ergebnis. Er muss zeigen, ob ein definierter Testvorgang gelesen, übertragen und im Ziel kontrolliert werden kann. Ein Präsentationstermin ist dafür kein ausreichendes Ergebnis.

Der anschliessende Auftrag hängt von diesem Nachweis ab. Scheitert der Versuch an einer fehlenden Berechtigung oder einer technischen Grenze, wird die Gesamtentscheidung neu bewertet. Die bereits gewonnenen Erkenntnisse bleiben dokumentiert. Das verhindert, dass ein Projekt allein wegen seiner bisherigen Kosten weitergeführt wird.

Auch beim Eigenbau wird eine solche Grenze gesetzt. Nach dem vereinbarten Versuch entscheidet die verantwortliche Person anhand der Ergebnisse über Fortsetzung, Anpassung oder Ende. Der Entwickler muss keinen vollständigen Betrieb improvisieren, nur weil ein erster Teil bereits funktioniert. Diese begrenzte Entscheidung schützt die verfügbare Arbeitszeit und macht den Vergleich zwischen interner und externer Umsetzung fairer.

Die Entscheidung auf einer Seite festhalten

Eine belastbare Entscheidung nennt den gewählten Umfang, die verantwortlichen Rollen, die wichtigsten Annahmen und die akzeptierten Abhängigkeiten. Sie enthält ausserdem einen Termin beziehungsweise Anlass für die erneute Prüfung. Das kann eine deutlich veränderte Fallmenge oder ein neuer Geschäftsprozess sein.

Für das fiktive Beispiel lautet das Ergebnis etwa: externe Umsetzung der Schnittstelle, interne Verantwortung für Fachregeln, zwölf Monate klar definierter Support und ein verpflichtender Übernahmetest. Die Entscheidung folgt dem vorhandenen Wissen und dem benötigten Betrieb. Sie ist keine allgemeine Empfehlung, jede KI-Automation einzukaufen.

Quellenstand: 22.10.2026. NIST liefert den genannten Governance-Bezug. Matrix, Kostenrechnung und Übernahmetests sind eigene methodische Vorschläge mit ausdrücklich fiktiven Zahlen.