Eigenes KI-Tool bauen statt kaufen: Chancen und Grenzen

Seit KI beim Programmieren mithilft, höre ich eine Frage immer öfter: Lohnt es sich überhaupt noch, Software zu kaufen, wenn ich sie mir doch selbst bauen lassen kann? Die ehrliche Antwort ist: Ja, selbst bauen ist heute ein echter Hebel. Ich baue meine eigenen Werkzeuge, vom Audit-Helfer bis zum kleinen Baustein neben dem ERP. Aber ich baue sie als jemand, der auch prüft. Und aus dieser Sicht sage ich Ihnen: Der schnelle Prototyp ist die eine Hälfte. Die andere Hälfte, Sicherheit, Tests und Datenarchitektur, entscheidet, ob Sie sich einen Vorteil bauen oder ein Risiko.

Was KI-gestützte Entwicklung heute wirklich kann

Der Sprung ist real. Ein kleines, auf Ihren Betrieb zugeschnittenes Werkzeug kostet heute Tage, nicht Monate. Ein Skript, das Auftragsdaten zieht und überfällige Rechnungen markiert. Ein Prototyp, der ein Bauteil fotografiert und Abweichungen meldet. Ein Helfer, der Bewerbungen vorsortiert. Solche Dinge sind für den Mittelstand in Reichweite gerückt, ohne dass Sie eine Softwareabteilung aufbauen müssen.

Ich mache das selbst. Meine Website, kleine Werkzeuge rund um Audit und Nachweise, Bausteine, die zwei Systeme miteinander reden lassen. Das Tempo ist beeindruckend. Ein Geschäftsführer, der vor einem Jahr für einen einzigen automatisierten Prozess ein Angebot im mittleren fünfstelligen Bereich bekommen hat, hat heute in einer Woche einen laufenden Prototyp. Das ist die gute Nachricht, und sie ist echt.

• Interne Helfer, die Daten aus vorhandenen Systemen zusammenführen und aufbereiten.
• Prototypen für eine konkrete Idee, bevor Sie viel Geld in ein fertiges Produkt stecken.
• Kleine Brücken zwischen Programmen, die kein Anbieter genau so verkauft.
• Auswertungen und Dashboards für Fragen, die nur Ihr Betrieb stellt.

Der Prototyp lügt Sie an

Jetzt kommt der Teil, den der Hype gern überspringt. Eine Demo, die auf Ihrem Bildschirm mit sauberen Testdaten funktioniert, ist noch kein System. Sie ist der schöne Fall. Die KI schreibt sehr gern den Code, der die Vorführung gelingen lässt. Sie schreibt nicht von allein den Code für den unschönen Dienstagvormittag, an dem die Daten krumm sind, zwei Nutzer gleichzeitig speichern und jemand ein Feld leer lässt, das nie leer sein sollte.

Zwischen Prototyp und Betriebsreife liegt genau die Arbeit, die man auf den ersten Blick nicht sieht. Und die drei Lücken, die ich am häufigsten finde, sind immer dieselben.

Sicherheit: der Teil, bei dem ich als Auditor hellhörig werde

Ein selbst gebautes Werkzeug, das Kunden- oder Personaldaten anfasst, braucht Zugriffsschutz, einen sicheren Ort für Passwörter und Schlüssel, und eine Protokollierung, wer wann was gesehen hat. KI-generierter Code lässt genau das oft von sich aus weg. Der Schlüssel steht im Klartext im Code. Es gibt keine Anmeldung. Es wird nichts mitgeschrieben. Im Kleinen fällt das nicht auf. Im Betrieb ist es ein offener Posten.

Nehmen Sie den Bewerbungs-Vorsortierer von oben. Sortiert er Bewerbungen und legt die Daten irgendwo ab, ohne Zugriffsschutz und ohne Löschkonzept, dann haben Sie kein Werkzeug gebaut, sondern ein Datenschutzproblem. Dasselbe gilt für die Sichtprüfung in der Fertigung, die nebenbei Bilder und Auftragsnummern speichert, und für den ERP-Baustein, der Zugang zu echten Umsätzen hat.

Ein Werkzeug, das Kundendaten anfasst, aber nicht protokolliert, wer wann was gesehen hat, ist im Audit kein Werkzeug. Es ist ein offener Posten.

Tests und Nachvollziehbarkeit: was der Hype weglässt

Ohne automatisierte Tests wissen Sie nach der nächsten Änderung nicht, ob Ihr Werkzeug noch das tut, was es soll. Und mit KI ändern Sie schnell viel. Sie bitten um eine kleine Anpassung, und im Hintergrund wird an drei anderen Stellen etwas umgeschrieben. Ohne Tests bricht das leise, und Sie merken es erst, wenn eine Zahl nicht mehr stimmt.

Bei allem, was Geld berührt oder Entscheidungen trifft, ist das keine Kür. Ein ERP-naher Baustein, der Rechnungen anfasst, muss nachvollziehbar bleiben. Wer eine Bewerbung aussortiert, muss begründbar bleiben. Nachvollziehbarkeit ist nicht mein Steckenpferd als Auditor, sie steckt in GoBD und in ISO-Managementsystemen als Anforderung. Ein Werkzeug, das eine Entscheidung trifft, die niemand nachvollziehen kann, ist im ISO-42001-Sinn genau die Art von KI, die man nicht ungeprüft laufen lassen sollte.

Datenarchitektur: wo aus dem Prototyp die Altlast wird

Das war mein eigener teuerster Lernmoment: Prototyp top, Architektur vergessen. Die Daten liegen erst mal irgendwie da, Hauptsache, die Demo läuft. Keine saubere Trennung, kein Plan, wie man später umzieht. Ein halbes Jahr später hängt der halbe Betrieb an diesem Werkzeug, und niemand traut sich mehr, etwas zu ändern, weil bei jeder Änderung etwas anderes kaputtgeht. Aus dem schnellen Gewinn ist eine neue Abhängigkeit geworden, diesmal von Ihrem eigenen Provisorium.

Budder bei die Fische: Die Datenarchitektur ist der Unterschied zwischen einem Werkzeug, das mit Ihnen wächst, und einem, das Sie in zwei Jahren teuer ablösen müssen. Sie entsteht nicht von allein, weil eine KI schnell tippt. Sie entsteht, weil jemand vorher überlegt, wem die Daten gehören, wie sie strukturiert sind und wie man sie wieder herausbekommt.

Selbstgebaut heißt nicht ungeprüft

Sobald Sie ein Werkzeug bauen, wird es Teil Ihrer IT- und KI-Landschaft, ob es auf einer Liste steht oder nicht. In einem ISO-42001- oder 27001-Audit ist der selbst gebaute Bewerbungs-Vorsortierer oder die eigene Sichtprüfung kein Bastelprojekt mehr, sondern ein System, das Daten verarbeitet und manchmal Entscheidungen trifft. Es gehört in Ihr Verzeichnis, mit einem Verantwortlichen, einem Zweck und einer Risiko-Einordnung. Werkzeuge, die niemand aufgeschrieben hat, sind Schatten-IT. Und Schatten-IT ist genau das, was im Audit und im Ernstfall hochgeht.

Das ist keine Bürokratie um ihrer selbst willen. Es ist der Unterschied zwischen der Aussage, man setze KI verantwortlich ein, und dem Nachweis, dass man es tut. Eine einzige Zeile, was das Werkzeug tut, welche Daten es anfasst, wer verantwortlich ist und ob es getestet wurde, macht aus einem privaten Skript ein prüfbares Betriebsmittel. Und sie sorgt dafür, dass Sie eine Antwort haben, wenn jemand fragt: Wer hat eigentlich entschieden, dass diese Bewerbung rausfliegt?

Build oder Buy: wie ich entscheide

Das ist keine Glaubensfrage, sondern eine Einordnung. Kaufen Sie, wenn das Problem gelöst, reguliert und Standard ist. Lohnbuchhaltung, der Kern der Finanzbuchhaltung, alles, wo Anbieter seit Jahren Haftung und Pflege übernehmen. Da bauen Sie nichts nach, das wäre teuer verschenkte Zeit.

Bauen Sie, wenn es um Ihren spezifischen Prozess geht, um Ihren Vorsprung, um eine Brücke, die niemand genau so verkauft, und wenn die Daten bei Ihnen bleiben sollen. Aber behandeln Sie das selbst gebaute Werkzeug dann wie jeden anderen Lieferanten: mit denselben Fragen nach Sicherheit, Prüfbarkeit und Datenhoheit, die Sie einem externen Anbieter stellen würden. Der einzige Unterschied ist, dass der Lieferant jetzt Sie sind.

• Für Buy spricht: Standardproblem, regulierter Bereich, Haftung und Wartung wichtiger als Eigenheiten.
• Für Build spricht: Ihr eigener Prozess, ein echter Wettbewerbsvorteil, Datenhoheit, eine Lücke zwischen Systemen.
• Gegen Build spricht: niemand im Haus, der das Werkzeug danach pflegt und verantwortet.

KI-gestützte Entwicklung ist ein echter Hebel für den Mittelstand, kein Spielzeug. Aber der Hebel wirkt nur, wenn Sie die zweite Hälfte der Arbeit nicht als Beiwerk behandeln. Der Prototyp ist geschenkt. Die Betriebsreife müssen Sie sich verdienen.