KI-Projekte scheitern nicht am Modell. Sie scheitern an dem, was darunter liegt.

In den letzten Monaten habe ich mit einer ganzen Reihe mittelständischer Unternehmen über KI-Einführungen gesprochen. Produktionsbetriebe, Ingenieurbüros, spezialisierte Dienstleister. Was alle gemeinsam haben: Sie wissen, dass sie handeln müssen. Was keiner offen sagt: Die meisten haben schon einen ersten Versuch hinter sich, der still und leise im Sand verlaufen ist.

Die Erzählung lautet dann: „Wir haben das mal probiert, war irgendwie noch nicht so weit." Oder: „Der Anbieter hat uns was verkauft, das in der Demo lief, aber bei uns nicht." Oder einfach Schweigen.

Ich möchte hier eine These ausformulieren, die sich aus zwei Dekaden in Konzernstrukturen und inzwischen etlichen Proof-of-Concepts mit Mittelständlern für mich verfestigt hat: KI-Projekte scheitern im Mittelstand selten am Modell oder an der Rechenleistung. Sie scheitern an dem, was darunter liegt. Und genau deshalb ist der kleine, ehrliche Proof of Concept kein Nice-to-have, sondern der einzige sinnvolle Einstieg.

Was wirklich bremst

Bevor ich zu konkreten Beispielen komme, eine nüchterne Bestandsaufnahme, wo die Reibung in aller Regel sitzt.

So weit die Diagnose, die sich in fast jedem Discovery-Gespräch bestätigt. Jetzt zu den Beispielen, an denen das konkret wird.

Beispiel 1: Der Patent-PoC, der etwas ganz anderes zeigte als geplant

Ein klassischer Use Case, den ich bei AImation in Varianten regelmäßig sehe: Ein Unternehmen möchte seine eigene Patentlandschaft und die des Wettbewerbs systematisch auswerten lassen. Auf den ersten Blick eine typische KI-Aufgabe: Texte analysieren, Cluster bilden, Trends erkennen. Moderne Sprachmodelle liefern dafür auf Anhieb beeindruckende Ergebnisse in der Demo.

Der PoC, den wir aufsetzen, ist bewusst klein: ein definierter Technologiebereich, ein paar hundert Patentschriften, eine konkrete Fragestellung. Zeitrahmen: vier bis sechs Wochen.

Was dabei meistens passiert, hat wenig mit der KI zu tun. In den ersten Tagen wird klar, dass die interne Patentdatenbank drei verschiedene Nummernsysteme parallel führt, entstanden aus unterschiedlichen Firmenübernahmen. Zwei Fachbereiche haben unabhängig voneinander an derselben Frage gearbeitet, mit unterschiedlichen Begriffen. Die Rechtsabteilung meldet sich und will wissen, ob externe KI-Dienste überhaupt mit diesen Dokumenten in Berührung kommen dürfen.

Ohne diesen PoC hätte der Kunde ein Budget für ein „Patent-KI-System" freigegeben, das mit hoher Wahrscheinlichkeit in exakt den oben genannten Hürden stecken geblieben wäre. Mit dem PoC weiß er vorher, was zu tun ist. Und was nicht.

Beispiel 2: Die multimodale Ablage, die ein Organisationsproblem offenlegte

Ein zweites Muster, das ich immer wieder sehe: Ein Mittelständler hat über Jahre technische Dokumentationen, Prüfberichte, Herstellerunterlagen, Fotos von Anlagen, handschriftliche Notizen und gescannte Altpläne angesammelt. Die Bedienung verteilt sich auf verschiedene Systeme, zunehmend aber auch auf das Gedächtnis einzelner Mitarbeiter. Wenn einer davon in Rente geht, entsteht ein spürbares Loch.

Die Wunsch-Story lautet: „Wir wollen eine KI, die unsere gesamte Wissensbasis durchsuchbar macht: auch die Fotos, auch die gescannten PDFs, auch die handschriftlichen Protokolle." Technisch ist das heute mit moderner multimodaler KI grundsätzlich machbar. Modelle lesen Bilder, extrahieren Text aus schlechten Scans, verstehen Tabellen.

Was der PoC in diesem Fall zeigt, ist selten ein technisches Problem:

• 1Niemand im Haus hat eine belastbare Antwort darauf, welche Dokumente überhaupt noch aktuell sind.
• 2Zwei Abteilungen führen dasselbe Prüfprotokoll in zwei Versionen, und niemand kann sagen, welche stimmt.
• 3Einige Dokumente dürfen aus rechtlichen Gründen überhaupt nicht in ein KI-System einfließen.
• 4Die betroffenen Mitarbeiter haben Vorbehalte, wenn ihr implizites Erfahrungswissen plötzlich „abfragbar" werden soll.

Der PoC löst diese Probleme nicht. Aber er bringt sie zum ersten Mal auf einen Tisch, an dem sie bearbeitet werden können. Bevor sechs- oder siebenstellige Budgets auf eine Lösung geworfen werden, die an genau diesen Punkten scheitern würde.

Warum der PoC das richtige Werkzeug ist

Beide Geschichten haben dieselbe Pointe. Der PoC ist nicht in erster Linie ein technisches Bauprojekt. Er ist ein Diagnose-Instrument: für den Zustand der Daten, die Belastbarkeit der Prozesse, die Haltung des Teams und die Compliance-Realität.

Genau das ist der Grund, warum ich bei AImation konsequent vom PoC ausgehe, statt mit einer großen Strategie zu starten. Eine Strategie, die auf ungeprüften Annahmen über die eigenen Daten, Prozesse und Menschen aufsetzt, ist in einem sich monatlich verändernden KI-Umfeld bestenfalls Theater.

Deshalb wird der Discovery-Schritt bei uns nie übersprungen. Bevor ein PoC aufgesetzt wird, schauen wir uns an, welche Tools tatsächlich im Einsatz sind, wie Daten fließen, wo sie liegen und welche Prozesse betroffen sind. Die Hälfte der späteren Reibung ist damit schon sichtbar, bevor die erste Zeile Code geschrieben wird.

Was das für Sie konkret heißt

Wenn Sie in einem mittelständischen Unternehmen Verantwortung für Digitalisierung, IT oder eine Fachabteilung tragen und gerade überlegen, wo Sie mit KI ansetzen:

Was bleibt

KI im Mittelstand gewinnt am Ende nicht, wer das modernste Modell hat. Sondern wer das Fundament sauber gebaut hat, auf dem diese Modelle arbeiten können.

Wer jetzt einen konkreten Usecase auswählt, einen kleinen PoC startet und das dabei entstehende Wissen im Team verankert, baut etwas auf, das sich nicht kaufen lässt. Keine Beraterpräsentation liefert das. Kein Whitepaper. Nur das eigene Tun.

Alles andere ist ein teures Luftschloss.