Selbst bauen oder kaufen? Teil 2

Teil II unserer Serie zu KI-gestützter Software-Entwicklung

Im ersten Teil ging es darum, was ein selbstgebautes Tool besser kann als eine gekaufte Lösung. Jetzt zur anderen Hälfte.

Vorweg, damit kein falscher Eindruck entsteht: Das ist keine Liste, mit der wir jemandem den Eigenbau ausreden möchten. Wir sehen bei unseren Kunden, wie KI-Werkzeuge in der Personalplanung oder in Betriebsabläufen Effizienzgewinne und Vereinfachungen bringen und finden sie gut. Es geht vielmehr um die Posten, die beim ersten Überschlagen fast immer fehlen, weil sie nicht am Anfang anfallen, sondern später.

Das Bauen ist der günstige Teil

Ein Tool zu bauen kostet heute ein Wochenende. Es zu betreiben kostet die nächsten Jahre.

Dazwischen liegen Server, Backups und mindestens einmal im Jahr ein Test, ob sich so ein Backup überhaupt zurückspielen lässt, sollte der Notfall mal eintreten. Updates der Bausteine, die in der Software Platz finden, oder Anpassungen, wenn sich im Betrieb was ändert. Einarbeitung neuer Kollegen oder Support für die eigenen Leute, wenn zu Arbeitsbeginn irgendwas nicht geht. Das läuft weiter, auch wenn das Projekt Eigenbau schon lange nicht mehr spannend ist. Das ist genau der Teil, den man bei einem Anbieter wie CrewBrain mitbezahlt.

Wenn die Person geht

Erinnerung zurück an die Excel mit Makros aus Teil I. Ein selbstgebautes Tool gehört faktisch der Person, die es gebaut hat. Wechselt sie den Betrieb oder die Abteilung, oder fällt sie mal länger aus, steht das Unternehmen womöglich vor einer Software, deren innere Abläufe kein anderer versteht. Freilich kann KI auch dem Nachfolger die Software erklären, geradestehen tut sie aber nicht dafür.

„Es läuft“ ist nicht „es ist sicher“

Das ist der Punkt, der uns als Softwareanbieter seit der Entwicklung leistungsstarker KI stets beschäftigt hat.

Sicherheit war für uns allerdings nie ein KI-Thema, sondern von Anfang an Grundlage. Wer die Daten von zehntausenden Menschen verwaltet, stellt sich bei jeder neuen Funktion zuerst dieselben Fragen: Wer darf das sehen, wo liegen die Daten, und was passiert, wenn etwas schiefgeht. Das ist keine Fleißarbeit, sondern schlicht Pflicht als Softwareanbieter.

Was KI daran verändert hat, ist nicht das Prinzip, sondern das Tempo. Code entsteht heute schneller, als ihn jemand anschauen kann – und genau da entsteht die Lücke.

Das lässt sich auch beziffern. Veracode testet seit 2023 regelmäßig, wie sicher Code ist, den KI-Modelle schreiben. In ihrem Bericht im März 2026 halten sie fest, dass zwar über 95 % des Codes syntaktisch korrekt sind, aber er nur in ca. 55 % der Fälle sicher ist. Und diese Quote hat sich seit Beginn der Testung nicht signifikant weiterentwickelt, während die Modelle funktional aber deutlich besser geworden sind.

Am schlechtesten schneiden die Fehlerarten ab, die man an einem laufenden System schwer sieht, z. B. Eingaben von Nutzern, die Schaden anrichten können. Für ein internes Werkzeug ohne heikle Daten ist das verkraftbar. Für etwas mit Login, das womöglich sogar aus dem freien Internet erreichbar ist und Personaldaten beheimatet, eher weniger.

Schnell gebaut ist nicht gleich stabil

Im DORA-Report 2025 geben 90 % der Befragten an, KI bei der Arbeit zu nutzen, und über 80 % empfinden sich damit als produktiver.

Ein Zusammenhang bleibt aber negativ, nämlich der zur Stabilität. Der schier hochvolumige KI-Output führt zu mehr Störungen, insbesondere wenn die Sicherungsnetze fehlen. Damit sind automatische Tests, eine saubere Versionsverwaltung und natürlich direktes Feedback, wenn etwas bricht, gemeint. Die Kernaussage des Reports: KI repariert kein Team, sondern verstärkt, was ohnehin schon da ist.

Dieses Sicherungsnetz hat ein Wochenendprojekt jedoch nicht. Das ist auch kein Vorwurf an KI oder KI-Nutzung, sondern schlicht eine Aussage darüber, dass der erfolgreiche KI-Einsatz oft von der Umgebung abhängt, in der sie eingesetzt wird.

Das eigentliche Thema: sensible Daten

In einer Software wie CrewBrain liegen selten harmlose Daten, bei denen es egal wäre, ob sie öffentlich sind oder nicht. Adressen, Geburtsdatum, oft sogar Fotos von Ausweisen oder Zertifikaten und gestempelte Zeiten.

Solange das bei einem Anbieter wie CrewBrain liegt, gibt es einen Auftragsverarbeitungsvertrag, der regelt, wer wofür einsteht. Beim Eigenbau bleibt alles im eigenen Haus:

• Wie Daten geschützt sind, muss selbst dokumentiert werden und im Zweifel belegt werden können.
• Auskunft, Berichtigung und Löschung müssen technisch funktionieren. Ein gesetzeskonformes Löschkonzept besteht aus mehr als einem gelöscht-Häkchen.
• Bei einer Datenpanne gilt eine Meldefrist von 72 Stunden. Voraussetzung dafür ist, dass man sie überhaupt bemerkt. Große Anbieter wie CrewBrain haben dafür Protokollierungs- und Überwachungssysteme, aber ein Solo-Wochenendprojekt eher nicht.

Das Gesetz steht nicht still

Die Pflicht zur Arbeitszeiterfassung besteht in Deutschland bereits, und auf EU-Ebene schon länger. Wie sie künftig genau aussehen soll, ist aber weiter offen. Ein Referentenentwurf zur Reform des Arbeitszeitgesetzes sieht eine elektronische Erfassung mit gestaffelten Übergangsfristen vor, verabschiedet ist er bislang aber nicht.

Das ist aber nur ein Beispiel von vielen. Mindestlohn und dessen Dokumentation, Aufbewahrungsfristen, Regeln zur Personalüberlassung, Vorgaben aus Tarifverträgen: All das bewegt sich, mal in kleinen Schritten, mal in Großen.

Für uns ist das Alltag, weil wir es ohnehin für unsere Nutzer verfolgen müssen. Wer selbst baut, übernimmt diesen Job für sich allein, und zwar nicht einmalig beim Bauen, sondern dauerhaft.

Kleinkram, der später schmerzt

Zuletzt gibt es noch Dinge, die im ersten Entwurf gar nicht auffallen, danach aber jeden Monat ein bisschen kosten.

Feiertage, die sich in Bundesländern unterscheiden. Zeitzonen bei Tourneen in mehreren Ländern. Kein Empfang in Hallen. Wer darf welche Informationen im System sehen und wie? Eine Crew aus Hunderten, die am Samstag um 7 Uhr gleichzeitig zur Arbeit einchecken möchte und damit den Server überlastet. Ein Job, der ausversehen gelöscht wurde und wieder zurück muss.

Alles Punkte, die man lösen kann, aber jedes Mal wieder ein bisschen Zeit kosten.

Was man sich vor einer Eigenentwicklung fragen sollte

Statt einer Empfehlung geben wir lieber ein paar Fragen an die Hand, die man vor der Entscheidung einmal durchgehen sollte:

1. Wie viele personenbezogene Daten liegen am Ende in dem Tool?
2. Möchte oder kann ich die Verantwortung übernehmen, wenn sensible Personal- oder Geschäftsdaten durch einen Fehler unbefugt offenliegen?
3. Was passiert, wenn das Tool an einem Showtag unvorhergesehen ausfällt? Nur ärgerlich, oder auch teuer?
4. Wer macht weiter, wenn die Person, die das Tool gebaut hat, nicht mehr da ist?
5. Wer kümmert sich um Compliance, z. B. im Bereich Arbeitszeiterfassung?
6. Sind meine Betriebsabläufe wirklich so individuell, dass sie mit keiner Standardsoftware zu einem Großteil abgebildet werden können?
7. Gibt es Budget für den Betrieb der Software? Oder nur für den Bau?

Die Faustregel: Je mehr Personendaten und je teurer ein Ausfall, desto eher kaufen. Je kleiner der Nutzerkreis, desto eher selbst bauen.

Und ziemlich oft auch: beides.

Wo die Grenze zwischen selbstgebaut und gekauft verläuft und was wir als Anbieter tun, damit diese Kombi gut funktioniert, erfährst du in Teil III.