Individuelle KI-Lösungen sind meistens die falsche Antwort — und manchmal die einzige

Wer sich heute nach KI für den eigenen Betrieb umsieht, bekommt zwei Antworten, und beide können falsch sein. Die eine lautet: Nehmen Sie ein fertiges Werkzeug, alles andere ist Geldverbrennung. Die andere lautet: Nur individuelle KI-Lösungen bringen einen echten Vorsprung. Welche der beiden für Sie gilt, hängt an drei Eigenschaften Ihres Prozesses — und die lassen sich in einer halben Stunde prüfen, lange bevor jemand ein Angebot schreibt.

Standardsoftware scheitert dort, wo Ihre Daten unstrukturiert liegen

Fertige KI-Werkzeuge sind gut in allem, was allgemein ist. Ein Text soll kürzer werden, eine E-Mail höflicher, eine Tabelle erklärt: dafür braucht niemand eine Eigenentwicklung. Das Modell kennt die Aufgabe aus Millionen ähnlicher Fälle.

Schwierig wird es an der Stelle, an der die Aufgabe Wissen verlangt, das nur bei Ihnen liegt. Welche Zuschläge gelten für welchen Kunden. Wie ein Bauteil in Ihrem Nummernkreis heißt. Was in der Preisliste von 2019 stand, auf die sich ein Rahmenvertrag noch bezieht. Dieses Wissen steht selten in einer Datenbank. Es steht in PDF-Anhängen, in gescannten Lieferscheinen, in E-Mail-Verläufen und in den Köpfen von drei Leuten, die seit zwanzig Jahren da sind.

Ein Standardwerkzeug kommt an diese Daten nicht heran. Sie können ihm die Information bei jeder einzelnen Anfrage von Hand mitgeben — genau das tun viele Betriebe gerade, und es ist der Punkt, an dem die Begeisterung nach ein paar Wochen kippt. Sobald Sie merken, dass Sie dem Werkzeug ständig dieselben Firmendaten nachreichen, ist die Grenze erreicht.

Der teuerste Teil eines KI-Projekts ist die Anbindung, nicht das Modell

Es hält sich hartnäckig die Vorstellung, ein KI-Projekt bestehe im Wesentlichen darin, ein Modell auszuwählen. Tatsächlich ist das der kleinste Posten. Der Aufwand entsteht davor und danach.

Davor: Die Daten müssen erreichbar sein. Ein ERP mit dokumentierter Schnittstelle ist ein anderer Fall als eine Branchensoftware, deren Hersteller seit Jahren nicht mehr erreichbar ist. Dokumente müssen lesbar sein — ein gescanntes Fax ist kein Text, sondern ein Bild, aus dem erst einer werden muss.

Danach: Das Ergebnis muss irgendwo landen, wo damit weitergearbeitet wird. Eine KI, die ein Angebot entwirft, das dann jemand aus einem Chatfenster kopiert, hat den Prozess nicht verkürzt, sondern verlängert. Nützlich wird sie erst, wenn der Entwurf im richtigen System als Entwurf steht, mit der richtigen Nummer, im richtigen Status.

Wenn Sie Angebote vergleichen, achten Sie deshalb weniger darauf, welches Modell jemand vorschlägt, und mehr darauf, ob im Angebot steht, welche Systeme angebunden werden und ob es dafür Schnittstellen gibt. Fehlt dieser Teil, ist die Zahl darunter geraten.

Drei Fragen entscheiden, ob sich Eigenentwicklung rechnet

Bevor über Technik gesprochen wird, lässt sich die Frage fast immer an drei Punkten klären.

Läuft der Prozess oft genug? Automatisierung amortisiert sich über Wiederholung. Ein Vorgang, der zweimal im Monat vorkommt, lohnt keine Eigenentwicklung, egal wie lästig er ist. Ein Vorgang, der täglich dutzendfach läuft, lohnt sie fast immer — auch dann, wenn er einzeln betrachtet nur Minuten kostet.

Kann jemand den Prozess vollständig beschreiben? Das ist die Hürde, an der nach meiner Erfahrung die meisten Vorhaben hängenbleiben. Nicht an der Technik, sondern daran, dass drei Abteilungen drei verschiedene Antworten darauf geben, was eigentlich passieren soll. Ein Prozess, den niemand aufschreiben kann, lässt sich auch nicht automatisieren. Diese Klärung ist keine Vorarbeit zum Projekt, sie ist der teuerste und wertvollste Teil davon — und sie zahlt sich selbst dann aus, wenn am Ende gar keine Software gebaut wird.

Braucht der Prozess Daten, die kein Standardprodukt kennt? Wenn die Antwort nein ist, kaufen Sie ein Abo und sparen sich den Rest. Wenn sie ja ist, geht es weiter — dann allerdings mit der Frage, wie diese Daten erreichbar werden.

Bedingung	Trifft zu	Trifft nicht zu	Empfehlung
Der Prozess läuft oft genug	täglich dutzendfach	zweimal im Monat	Ohne Wiederholung amortisiert sich keine Eigenentwicklung
Jemand kann den Prozess vollständig beschreiben	eine Person schreibt ihn auf	drei Abteilungen, drei Antworten	Erst klären, dann bauen — das ist der teuerste Teil
Der Prozess braucht Daten, die kein Standardprodukt kennt	das Wissen steckt in Ihren Systemen	die Aufgabe ist allgemein	Trifft es nicht zu: Abo kaufen und Geld sparen

Drei Mal ja heißt: Eigenentwicklung lohnt sich vermutlich. Zwei Mal ja heißt: erst den fehlenden Punkt klären. Ein Mal ja heißt: lassen Sie es.

Bei vier von zehn Anfragen, die mich erreichen, lautet meine Empfehlung am Ende: Abo kaufen, nicht entwickeln lassen.

Die Dauer hängt an den Schnittstellen, nicht an der Nutzerzahl

Maßgeblich für den Aufwand ist nicht, wie viele Menschen mit einem System arbeiten, sondern wie viele Schnittstellen es hat und wie es um die Dokumentation steht. Beides multipliziert sich durch alle Phasen.

Merkmal	Klein	Mittel	Groß	Sehr groß
Systemtyp	Insellösung	Abteilungssystem	Kernsystem eines Bereichs	Zentrales Kernsystem des Betriebs
Schnittstellen	0–1	2–3	3–5	5–10
Nutzer	unter 15	15–50	50–150	150–500
Dokumentation	vorhanden oder System trivial	lückenhaft	überwiegend fehlend	fehlend, Entwickler nicht mehr im Haus
Beispiel	Access-Datenbank, Excel-Konstrukt, Terminplaner	CRM-Eigenbau, Lagerverwaltung, Zeiterfassung	Warenwirtschaft, Auftragsabwicklung, Filialsystem	Gewachsenes ERP mit Produktion, Delphi- oder VB-Altanwendung als Firmenrückgrat

Daraus ergeben sich die folgenden Zeiträume bis zum produktiven Testbetrieb in Wochen — Richtwerte aus meinen Projekten, keine Branchenstatistik:

Phase	Klein	Mittel	Groß	Sehr groß
Analyse und Assessment	2–4 (inkl. Konzept)	2–4	4–7	6–10
Konzept und Zielarchitektur	—	2–4	4–8	8–14
Umsetzung und Datenmigration	2–6	6–12	12–22	22–42
Test bis produktiver Testbetrieb	1–2	2–4	4–8	9–14
Gesamt	5–12	12–24	24–45	45–80
Anteil der Analyse an der Gesamtdauer	ca. 25 %	ca. 17 %	ca. 16 %	ca. 14 %

Bei kleinen Systemen sind Assessment und Zielarchitektur derselbe Arbeitsschritt: Bei einer Insellösung ohne Schnittstellen fällt die Entscheidung über das Zielbild meist in derselben Sitzung, in der das Altsystem aufgenommen wird. Ein eigener Konzeptzyklus mit Freigabeschleife würde hier mehr Termine kosten, als er an Klarheit bringt.

Der ausgewiesene Analyseanteil steigt dadurch in der kleinsten Klasse rechnerisch auf rund ein Viertel. Das ist kein Widerspruch zu den 14 bis 17 Prozent der größeren Klassen, sondern eine Folge der Zusammenlegung: Dort sind Assessment und Konzept getrennt ausgewiesen und ergeben zusammen ebenfalls etwa 25 bis 30 Prozent der Gesamtdauer.

Ein Teil dieser Zeit ist übrigens keine Arbeit, sondern Warten: Entscheidungszyklen auf Kundenseite, in denen die Analyse ruht.

Der EU AI Act verschiebt die Rechnung bei einigen Anwendungsfällen

Seit 2024 gilt in der EU ein einheitlicher Rechtsrahmen für KI-Systeme. Er sortiert Anwendungen nach Risiko, und diese Einstufung wirkt sich unmittelbar auf den Aufwand aus. Die Pflichten treten gestaffelt in Kraft — der folgende Abschnitt gibt den Stand von August 2026 wieder.

Der Großteil dessen, was im Mittelstand gebaut wird, fällt in die niedrigste Stufe: Angebote entwerfen, Dokumente einordnen, Anfragen vorsortieren. Hier geht es im Wesentlichen um Transparenz — Menschen müssen wissen, dass sie es mit einem KI-System zu tun haben, und Mitarbeitende, die damit arbeiten, brauchen eine Einweisung.

Anders liegt der Fall, sobald ein System über Menschen entscheidet oder Entscheidungen vorbereitet: Bewerbungen vorsortieren, Kreditwürdigkeit bewerten, Leistung von Beschäftigten beurteilen. Solche Anwendungen gelten als hochriskant und bringen Dokumentations-, Protokollierungs- und Aufsichtspflichten mit sich, die den Aufwand deutlich erhöhen.

Für die Entscheidung heißt das: Klären Sie die Einstufung, bevor Sie entwickeln lassen. Ein Anwendungsfall, der sich bei niedrigem Risiko klar rechnet, kann sich als hochriskantes System nicht mehr rechnen. Das ist keine juristische Feinheit, sondern ein Posten in der Kalkulation.

Ein Projekt beginnt mit einem Prozess, nicht mit einem Modell

Ich fange deshalb nicht mit Technik an, sondern mit einem Fit-Check, der nur zwei Dinge tut: den Prozess so aufschreiben, dass alle Beteiligten dasselbe darunter verstehen, und prüfen, ob die nötigen Daten überhaupt erreichbar sind. Am Ende steht eine Empfehlung — auch dann, wenn sie lautet, dass sich das Vorhaben nicht lohnt. Der Fit-Check ist kostenpflichtig und wird bei einem Auftrag auf den Projektpreis angerechnet.

Ein Beispiel aus der Praxis: Ein Veranstalter verwaltete Adressen und Buchungen in einer Access-Anwendung, Frontend und Backend beides Access, zehn Benutzer. Neue Funktionen einzubauen war kaum noch vertretbar — jede Änderung barg das Risiko, dass die Anwendung anschließend nicht mehr läuft, und Entwickler-Wissen über das System gab es nicht mehr im Haus. Ich habe die Anwendung auf eine Web-Oberfläche mit MS-SQL-Server-Backend umgestellt, gehostet im eigenen Haus. Vom Workshop-Tag vor Ort bis zum Ausrollen vergingen rund zehn Wochen: eine Woche Intensivanalyse, vier Wochen Umstellung samt Datenmigration, drei Wochen Testphase beim Kunden mit zwei Mitarbeitenden, eine Woche Nachbesserung, eine Woche Retest, ein Tag Schulung für alle Anwender.

Das Ergebnis des Fit-Checks ist ein Dokument, mit dem sich das Vorhaben umsetzen lässt, auch von jemand anderem. Mir ist ein abgesagtes Projekt lieber als eines, das nach acht Monaten in einer Schublade endet. Was ich übernehme und was ausdrücklich nicht, steht auf der Seite Über uns.

Weitere Beiträge dazu, wann sich eigene Software gegenüber Standardprodukten rechnet, sammle ich unter Individualentwicklung; einen Überblick über alle Themen gibt die Blogübersicht.