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. Genau deshalb halte ich den kleinen, ehrlichen Proof of Concept für den einzig sinnvollen Einstieg.
Was wirklich bremst
Bevor ich zu konkreten Beispielen komme, eine nüchterne Bestandsaufnahme, wo die Reibung in aller Regel sitzt.
Datenzustand
Was auf PowerPoint-Folien als sauberer „Data Lake" steht, ist in der Realität oft eine gewachsene Landschaft aus SharePoint-Ablagen, Netzlaufwerken, veralteten Excel-Listen und mehreren Versionen derselben Wahrheit. Niemand ist offiziell zuständig.
Demo versus Skalierung
Im kleinen Pilot-Chat wirkt das Modell souverän. Im produktiven Betrieb tauchen Halluzinationen dort auf, wo vorher keine waren, weil plötzlich Sonderfälle kommen, die in der Demo nicht vorkamen. Was auf zehn Testdokumenten funktioniert, stößt auf zehntausend an Grenzen.
Compliance-Wand
DSGVO, EU AI Act, interne IT-Security, Haftungsfragen. Sicherheit und Recht gehören von Tag eins zur eigentlichen Konstruktionsaufgabe, nicht zum Feinschliff am Ende. Wer das ignoriert, baut ein Luftschloss.
Faktor Mensch
Das technisch beste Werkzeug bleibt ungenutzt, wenn das Team nicht mitgenommen wurde. Widerstand hat selten mit bösem Willen zu tun. Meistens steckt Unsicherheit dahinter, die berechtigte Sorge, den eigenen Arbeitsplatz oder das vertraute Selbstverständnis zu verlieren.
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.
Was dieser PoC wirklich lieferte
- → Die KI-Komponente war in zwei Wochen lauffähig.
- → Die anderen vier Wochen gingen in Datenhygiene, Abstimmung und ein sauberes Setup mit Claude über AWS Bedrock in Frankfurt.
- → Am Ende lag ein ehrliches Bild vor: welche Datenquelle führend wird, welche Schnittstellen gebraucht werden, wer zuständig ist.
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 funktioniert vor allem als 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:
01 Widerstehen Sie der Versuchung, mit einer großen Strategie zu starten.
Das ist der teuerste und langsamste Weg zu scheitern. Wählen Sie eine konkrete, begrenzte Frage aus, die heute Zeit oder Geld frisst, und setzen Sie einen PoC dazu auf.
02 Planen Sie ein, dass die ersten zwei Wochen Überraschungen bringen.
Datenprobleme, Zuständigkeitslücken, Compliance-Fragen, Skepsis im Team: Genau das ist der Wert des PoCs, kein Zeichen für den falschen Anbieter. Er zeigt Ihnen das Haus, bevor Sie es umbauen.
03 Rechnen Sie mit schmutzigen Daten, sich ändernden Anforderungen und langsamer Compliance.
Ein ehrliches KI-Audit am Anfang spart am Ende sechsstellige Fehlbeträge. Das gilt für den Mittelständler genauso wie für den Konzern. Ich habe die Abkürzungsversuche über viele Jahre aus der Nähe erlebt.
Was bleibt
Am Ende gewinnt im Mittelstand, wer das Fundament sauber gebaut hat, auf dem die Modelle arbeiten können. Das modernste Modell allein reicht dafür nicht.
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. Das leistet keine Beraterpräsentation und kein Whitepaper, nur das eigene Tun.
Alles andere ist ein teures Luftschloss.
Häufige Fragen zu KI-Projekten im Mittelstand
In fast jedem Discovery-Gespräch zeigt sich dasselbe Muster: Das Modell ist selten das Problem, das Fundament darunter schon. Daten in verschiedenen Systemen ohne klare Zuständigkeit, Compliance-Fragen, die niemand vorab gestellt hat, und ein Team, das nicht mitgenommen wurde. Das sind die drei häufigsten Stopper. Die Technologie selbst ist dabei oft die kleinste Baustelle.
Ein PoC ist ein kleines, zeitlich begrenztes Experiment mit einem konkreten Lernziel, typischerweise 4 bis 6 Wochen, ein klar umrissener Usecase, ein definiertes Ergebnis. Der Vorteil: Er liefert die ehrliche Antwort auf die Frage, was in Ihrem Unternehmen mit Ihren Daten und Ihren Prozessen wirklich funktioniert. Was auf Anhieb in der Demo läuft, tut das in der Praxis oft nicht. Der PoC macht diesen Unterschied sichtbar, bevor große Budgets freigegeben werden.
Compliance gehört für uns von Anfang an zur eigentlichen Konstruktionsaufgabe, nicht zum nachträglichen Umbau am Ende. Wir empfehlen für den DACH-Mittelstand self-hosted Lösungen: Claude über AWS Bedrock mit Frankfurt-Region, n8n für Automatisierung, lokale Speicherung. Damit bleiben Daten in Ihrer Kontrolle und verlassen die EU nicht. Der genaue Setup hängt von Ihrer Situation ab, dafür ist das Discovery-Gespräch da.
Im Discovery schauen wir uns an, welche Tools tatsächlich im Einsatz sind, wie Daten fließen, wo sie liegen und welche Prozesse betroffen sind. Das dauert in der Regel ein bis zwei Workshops. Die Hälfte der späteren Reibung ist damit schon sichtbar, bevor die erste Zeile Code geschrieben wird. Dieser Schritt wird bei uns nie übersprungen.
Weil KI-Fähigkeiten sich monatlich weiterentwickeln. Eine Strategie, die auf ungeprüften Annahmen über Daten, Prozesse und Team aufbaut, ist in diesem Umfeld bestenfalls Theater. Bis eine große Roadmap umgesetzt ist, hat sich die Technologie bereits verändert. Ein konkreter PoC über vier bis sechs Wochen liefert in der Hälfte der Zeit mehr belastbare Erkenntnisse als drei Beraterpräsentationen.
Welcher Usecase macht bei Ihnen als erstes Sinn?
Im ersten Gespräch schauen wir gemeinsam, welcher Usecase bei Ihnen als erstes Sinn ergibt und wie ein PoC konkret aussehen könnte. 30 Minuten. Kostenlos. Ohne Verkaufspitch.
Erstgespräch buchen