10 typische Fehler bei der KI-Einführung im Mittelstand: Was uns fünf Jahre gescheiterte Projekte gelehrt haben

Warum diese Liste 2026 zählt

Fünf Jahre Mittelstands-KI-Projekte haben genug gescheiterte Pilote produziert, um eine kleine Bibliothek zu füllen. Dieselben Muster wiederholen sich quer über Unternehmen, Branchen und Budgets. Die Technologie ist fast nie das Problem. Die Fehler passieren früher - in Scoping, Sponsorship, Daten und Governance - bevor das erste Modell überhaupt aufgerufen wird.

Gartner prognostiziert, dass 60 Prozent der KI-Projekte bis Ende 2026 wegen unzureichender Datenfundamente abgebrochen werden¹. Über 40 Prozent der Agentic-AI-Projekte werden bis Ende 2027 abgebrochen². Bitkom-Daten speziell zum deutschen Mittelstand zeigen ein ähnliches Muster: rund 60 Prozent der Pilote erreichen die Produktionsskalierung nie⁶. Die Fehler sind nicht zufällig. Sie clustern sich um dieselben zehn Patterns, gemacht von erfahrenen Teams in gut geführten Unternehmen.

Dieser Artikel geht die zehn Fehler einzeln durch - wie sie in der Praxis aussehen, warum kluge Teams sie trotzdem machen und wie man jeden konkret vermeidet. Vor dem nächsten KI-Projekt lesen. Vor der nächsten Anbieter-Unterschrift wieder lesen.

Fehler 1: Kein definiertes Geschäftsergebnis

Das Projekt startet mit „wir müssen was mit KI machen" und wird nie konkreter. Es gibt ein Budget, einen Steuerkreis, manchmal sogar einen ausgewählten Anbieter - aber keine messbare Antwort auf die Frage „was bedeutet Erfolg?" in Zahlen.

Wie es in der Praxis aussieht

• Der Projektplan listet Fähigkeiten, keine Ergebnisse - „ChatGPT für das Team einführen", „einen KI-Chatbot bauen", „Microsoft Copilot evaluieren". Nichts davon ist ein Ergebnis.
• Erfolgskriterien tauchen nach dem Pilot auf, nicht davor - das Team rationalisiert nachträglich, was der Pilot produziert hat, in eine erfolgreich klingende Story.
• Keine Baseline-Messung existiert - niemand weiss, wie viele Stunden pro Woche der Kandidaten-Prozess heute kostet, also kann niemand beweisen, dass die KI etwas spart.
• Die CFO-Frage wird nie beantwortet - „was ist das Projekt dem Geschäft in Euro über drei Jahre wert?" bekommt nur narrative Antworten.

Warum kluge Teams diesen Fehler machen

Ergebnisse zu definieren ist harte Arbeit. Sie erfordert, einen konkreten Prozess zu wählen, mit den Leuten zu reden, die ihn machen, den Status quo zu messen und sich auf eine Zahl festzulegen. Das ist unangenehm. Vage Projekte fühlen sich sicherer an, weil sie kein Ziel verfehlen können - aber sie können auch keines treffen.

Wie vermeiden

• Einen Prozess wählen, kein Portfolio - Ausnahmebehandlung in der Lieferantenrechnungs-Verarbeitung, RFQ-Vergleich für eine konkrete Kategorie, Kundenservice-Triage für die Top-20-Prozent-Fälle.
• Den Status quo in Zahlen messen - Stunden pro Woche, Ausnahmequote, Bearbeitungszeit pro Vorgang. Was sich nicht messen lässt, kann KI nicht verbessern.
• Erfolgsmetrik vor jeder Toolauswahl definieren - 30 Stunden Einkäufer-Zeit pro Woche zurückgewonnen, Ausnahmequote von 22 auf unter 8 Prozent, Audit-Vorbereitungszeit von 3 Wochen auf 4 Tage.
• Einen Mess-Termin setzen - 90 Tage nach Produktiv-Go-Live werden die Metriken gegen die Baseline geprüft. Bestanden oder nicht, nicht narrativ.

Fehler 2: Falscher erster Use Case

Der erste Use Case ist entweder zu einfach, um zu zählen, oder zu schwer, um zu gelingen. Zu einfach: das Projekt produziert ein funktionierendes System, das 4 Stunden pro Monat spart, was niemand ausserhalb des Projekts bemerkt. Zu schwer: der Use Case berührt strategische Entscheidungen, regulierte Prozesse oder drei Abteilungen, die sich nicht einig sind, was das Ziel ist - und das Projekt ertrinkt in Scope.

Wie es in der Praxis aussieht

• Das Team wählt den einfachsten verfügbaren Use Case - Marketing-Texte entwerfen, Meeting-Notizen zusammenfassen, LinkedIn-Posts generieren. Demonstriert Fähigkeit; produziert keine Geschäftswirkung.
• Oder das Team wählt den strategischsten Use Case - automatisiertes Pricing, autonome Kreditentscheidungen, End-to-End-Bedarfsplanung. Klingt wichtig; kollabiert unter abteilungsübergreifender Politik und regulatorischem Gewicht.
• Wie auch immer, das zweite Projekt startet nie - weil das erste entweder nicht genug Begeisterung erzeugt hat oder zu viel Vertrauen verbrannt hat.

Das Profil des richtigen ersten Use Case

• Signifikanter Schmerz - 15 plus Stunden pro Woche menschliche Zeit, Ausnahme-Backlog, verfehlte SLAs, Audit-Stress.
• Begrenzter Scope - ein Prozess, ein Team, eine Produktfamilie. Nicht drei Abteilungen, die zusammenarbeiten.
• Akzeptable Datenqualität - die Daten, auf denen der Agent argumentiert, sind sauber genug zum Start.
• Williger Fachbereichs-Sponsor - der betroffene Abteilungsleiter will, dass das Projekt gelingt, und hilft, Probleme zu unblocken.
• Sichtbares Ergebnis in 90 Tagen - eingesparte Stunden, reduzierte Fehler, gekürzte Zykluszeit. Zahlen, die im nächsten Quartals-Review auftauchen.

Fehler 3: Datenqualität ignoriert

Der grösste Erfolgsindikator. 70 Prozent der Hersteller nennen Datenqualität als grösstes Implementierungshindernis⁸. Gartner sagt: 60 Prozent der KI-Projekte werden bis Ende 2026 wegen unzureichender Datenfundamente abgebrochen¹. Der Agent argumentiert auf den Daten, die er sieht. Sind die Daten falsch, fehlend oder inkonsistent, erbt der Agent das Problem - und verstärkt es im Massstab.

Wie es in der Praxis aussieht

• Im MES fehlen 20 Prozent Ausschussgründe - der Agent kann Qualitätsmuster, zu denen er keine Daten sieht, nicht lernen.
• Lieferantenstamm hat Duplikate und veraltete Kontakte - der Agent kann Rechnungen nicht zuverlässig Lieferanten zuordnen.
• Zeitstempel in der BDE sind um Stunden falsch - Schichtplan-Rebalancing produziert Unsinn.
• Freitextfelder enthalten Abkürzungen, die nur die Senior-Einkäuferin versteht - der Agent liest, aber interpretiert nicht.

Wie vermeiden

• Den Datensatz, auf dem der Agent argumentieren wird, vor der Festlegung prüfen - 50 bis 100 historische Datensätze sampeln, Vollständigkeit, Genauigkeit, Konsistenz bewerten.
• Eine Datenqualitäts-Schwelle definieren - 95 Prozent Vollständigkeit auf kritischen Feldern, Genauigkeit gegen Quellbelege validiert.
• Die schmerzhaftesten Lücken zuerst reparieren - strukturierte Duplikatslöschung, Pflichtfelder erzwungen, Freitextfelder kuratiert.
• Einen anderen Use Case wählen, wenn die Daten in 30 Tagen nicht zu reparieren sind - der Agent macht aus schlechten Daten keine guten Entscheidungen.

Fehler 4: Tool-First statt Process-First

Das Team startet mit „lasst uns Microsoft Copilot evaluieren" oder „lasst uns eine KI-Agent-Plattform wählen", bevor ein einziger Prozess gemappt ist. Das Tool wird basierend auf Demos und anbieter-getriebenen RFP-Prozessen ausgewählt. Dann sucht das Team nach Use Cases, die das Tool kann - was immer eine kleinere Menge ist als die Use Cases, die wirklich zählen.

Warum Tool-First sich richtig anfühlt (und falsch ist)

• Es fühlt sich wie Fortschritt an - Anbieter-Demos, Verträge, Kick-off-Meetings, alles sichtbare Aktivität.
• Es vermeidet harte interne Arbeit - Prozess-Mapping, Stakeholder-Abstimmung, Daten-Audits sind unangenehm.
• Es verankert Denken um Tool-Fähigkeiten - das Team beantwortet „was könnte das Tool für uns tun?" statt „welcher Prozess braucht welches Tool?".
• Es produziert Wechselkosten ab Tag eins - bis das Team merkt, dass das Tool falsch ist, ist der Vertrag unterschrieben und sechs Monate Schulung investiert.

Die Process-First-Sequenz

1. Den Prozess mit dem grössten Schmerz identifizieren (Fehler 2 gut gemacht).
2. Den Prozess Ende-zu-Ende mappen - Eingaben, Ausgaben, Entscheidungspunkte, Ausnahmetypen, Systemberührungen. Die Karte ist das Artefakt, nicht das Foliendeck.
3. Definieren, wie Erfolg aussieht in messbaren Begriffen (Fehler 1 gut gemacht).
4. Datenqualität auditieren auf dem Kandidaten-Prozess (Fehler 3 gut gemacht).
5. Jetzt das Tool auswählen - gegen die tatsächlichen Anforderungen, die aus Schritten 1 bis 4 entstanden sind. Das richtige Tool ist selten das mit der lautesten Demo.

Fehler 5: IT-geführt statt Fachbereichs-geführt

Die IT führt das Projekt. Die IT wählt den Anbieter. Die IT definiert die Anforderungen. Der Fachbereich, der den betroffenen Prozess besitzt, wird informiert, gelegentlich konsultiert, ist aber nie Sponsor. Das Ergebnis ist ein technisch funktionierendes System, das ein Problem löst, das der Fachbereich nicht hat.

Wie es in der Praxis aussieht

• Der Projekt-Sponsor ist der CIO, nicht der Operations-Leiter - die Leute, deren Arbeit betroffen ist, sind nachgelagert.
• Anforderungen werden von IT-Business-Analysten geschrieben - basierend auf dokumentierten Prozessen, nicht der echten Realität.
• User Acceptance Testing passiert am Ende - durch Nutzer, die nicht im Scoping waren.
• Nach Go-Live stagniert die Adoption - das System läuft; die Nutzer nutzen es nicht.

Das richtige Ownership-Muster

• Fachbereichs-Sponsor - der Abteilungsleiter, dessen Team den Agenten nutzen wird. Besitzt die Erfolgsmetrik. Hat Budget-Hoheit.
• Prozess-Owner - die Person, deren Team den Prozess heute macht. Weiss, wo die echten Ausnahmen sind. Validiert die Prozesskarte.
• IT-Partner - Integration, Sicherheit, Governance, Datenzugriff. Essenziell, aber nicht der Lead.
• Externer Umsetzungspartner (falls genutzt) - Implementierung, aber berichtet an Fachbereichs-Sponsor, nicht IT.

Fehler 6: Kein Human-in-the-Loop

Der Agent handelt autonom bei Entscheidungen, die geprüft werden sollten. Eine falsche Entscheidung - eine versehentlich versendete Kunden-E-Mail, ein falsch bezahlter Lieferantenbetrag, ein freigegebenes Qualitätslos, das hätte gehalten werden müssen - und das Vertrauen kollabiert schneller, als es je aufgebaut war. Nach diesem einen Versagen wird jede weitere Agent-Entscheidung infrage gestellt, das Projekt wird leise gedrosselt, und der zweite Agent wird nie genehmigt.

Wo Human-in-the-Loop essenziell ist

• Kundenkommunikation - E-Mails, Vertragsänderungen, Streitfall-Antworten. Eine falsche Nachricht landet öffentlich.
• Finanzaktionen über einer Schwelle - Lieferantenzahlungen, Kreditentscheidungen, grosse Bestellungen.
• Sicherheits- und qualitätskritische Entscheidungen - Lot freigeben, 8D unterschreiben, Abweichung genehmigen.
• Regulatorische Meldungen - LkSG, CSDDD, Steuermeldungen. Fehler haben rechtliche Folgen.
• Alles, was Mitarbeiter betrifft - Performance-Flags, Schicht-Overrides, Schulungs-Zuweisungen.

Wie Human-in-the-Loop richtig designen

• Entscheidungsschwellen explizit definieren - welcher Wert, welches Risikolevel, welcher Aktionstyp triggert Genehmigung.
• Dem Menschen vollen Kontext geben, nicht nur die Empfehlung - was der Agent fand, was er erwog, welche Alternativen er verwarf, warum.
• Genehmigung schnell machen - ein Klick im System, kein separater Workflow-Tool.
• Jede Genehmigung und jeden Override loggen - die Override-Muster werden zur nächsten Runde Trainingsdaten.
• Autonomie graduell ausbauen - mit voller Prüfung starten, auf Schwellen-basierte Prüfung erweitern, nie volle Autonomie ohne explizite Geschäfts-Freigabe.

Fehler 7: Anbieter-Lock-in unterschätzt

Der Vertrag wird für die Plattform unterschrieben, die am besten gedemoed hat. Zwei Jahre später leben die Daten im Anbieter-Format, die Prompts und Tool-Konfigurationen sind anbieter-spezifisch, die Integrationen sind massgeschneidert auf die Anbieter-API, und das Team hat 18 Monate operative Erfahrung in einem einzigen Anbieter-Mindset. Wechseln ist theoretisch möglich und praktisch unmöglich.

Wie sich Anbieter-Lock-in zeigt

• Daten-Lock-in - Ihre operativen Daten sitzen in der Anbieter-Cloud. Export ist vertraglich möglich, operativ schwer.
• Konfigurations-Lock-in - Prompts, Tool-Definitionen, Agent-Workflows sind im proprietären Format.
• Integrations-Lock-in - die Integrationen zu SAP, CRM, DMS wurden für die Anbieter-API gebaut. Anbieter wechseln heisst, alle neu zu schreiben.
• Skill-Lock-in - Ihr Team ist auf das Anbieter-Tooling geschult. Wechsel heisst Umschulung.
• Pricing-Lock-in - SaaS-Preiserhöhungen bei Verlängerung sind heute standardmässig 10 bis 20 Prozent jährlich, Anbieter wie Salesforce und ServiceNow drücken 15 bis 25 Prozent durch¹². Wechselkosten wachsen mit der Nutzung.

Wie auf Ersetzbarkeit designen

• Auf EU-Deployment-Optionen bestehen - EU-Cloud oder On-Premise. Reduziert Compliance-Risiko und US-Cloud-Act-Exposition.
• Offene Datenformate verwenden, wo möglich - JSON, Markdown, strukturiertes CSV. Anbieter-spezifische Binärformate für operative Daten vermeiden.
• Agent-Logik in portablen Abstraktionen bauen - Prompts und Tool-Definitionen, die mit vertretbarem Aufwand über Plattformen übersetzen.
• Datenrückgabe-Klauseln verhandeln - explizite vertragliche Zusagen zu Datenexport-Format und -Zeit am Vertragsende.
• Jährlich ein Gedankenexperiment fahren - wenn wir diesen Anbieter nächstes Quartal verlassen müssten, was würde es kosten? Die Zahl quantifiziert das angesammelte Lock-in.

Fehler 8: Compliance als Nachgedanke

Der Agent ist gebaut. Dann fragt jemand „erfüllt das die DSGVO?" - und die Antwort verlangt Architekturänderungen, die das Go-Live um Monate verzögern. Oder der Betriebsrat erfährt vom Projekt von einem Kollegen und erhebt Einwände, die in der Planungsphase hätten adressiert werden müssen. Im Voraus ignorierte Compliance ist die teuerste Form von Compliance.

Die Compliance-Karte für Mittelstands-KI-Projekte 2026

• DSGVO - Verarbeitung personenbezogener Daten verlangt Rechtsgrundlage, dokumentierten Zweck, Datensparsamkeit, Löschrechte. Der Agent muss in einer DSGVO-konformen Umgebung laufen.
• EU-KI-Verordnung - vollständig anwendbar ab August 2026. Risikoklassifikation, Transparenz für begrenztes Risiko, Doku für Hochrisiko. Die meisten Beschaffungs- und operativen Agenten sind begrenztes Risiko; HR-nahe Agenten können Hochrisiko sein.
• Betriebsrat - Mitbestimmungsrechte für technische Systeme, die Mitarbeiterleistung überwachen. Früh informieren.
• LkSG / CSDDD - falls der Agent Lieferketten-Sorgfaltspflichten unterstützt, Prozess für den Jahresbericht dokumentieren.
• GoBD - buchhaltungs- und steuerrelevante Daten müssen auditierbar sein. Das Agent-Log ergänzt, ersetzt aber nicht den Audit-Trail des System of Record.
• NIS-2 und IT-Sicherheitsgesetz - Cybersicherheits-Anforderungen, besonders für KRITIS-Betreiber.
• US-Cloud-Act-Exposition - falls der Agent personenbezogene Daten auf US-gehostetem SaaS verarbeitet, Risiko und Massnahmen dokumentieren.

Fehler 9: Pilot bleibt Pilot

Der Pilot launcht, generiert initiale Ergebnisse, wird in einem Führungsmeeting gefeiert - und dann nichts. Sechs Monate später läuft der Pilot immer noch auf 10 Prozent Volumen, kein Skalierungsplan existiert, das Team ist zu anderen Prioritäten weitergezogen. Der Pilot wird zur permanenten Demo.

Warum Pilote stecken bleiben

• Kein Skalierungsplan zu Beginn definiert - der Projektplan endete bei „Pilot live".
• Pilot-Erfolgsmetriken übersetzen nicht in Geschäfts-KPIs - „90 Prozent Genauigkeit auf Testfällen" bewegt das Operations-Dashboard nicht.
• Die operativen Veränderungen, die Skalierung verlangt, wurden nie vereinbart - die Leute, deren Arbeit sich bei Skalierung ändert, waren nicht eingebunden.
• Die nächste Phase hat kein Budget - der Pilot wurde finanziert; die Operationalisierung nicht.
• Die ROI-Story für die Skalierung fehlt - der Pilot bewies technische Fähigkeit; Skalierung verlangt einen CFO-tauglichen Business Case.

Wie Pilot-Fegefeuer vermeiden

• Skalierungsplan in Woche 1 definieren - was triggert Erweiterung, welches Budget ist nötig, wer genehmigt.
• Geschäfts-KPIs nutzen, nicht technische Metriken - eingesparte Stunden pro Woche, Ausnahmequote, Durchsatz. Zahlen, an denen Operations-Führung sich misst.
• Das betroffene Team in den Piloten einbinden, nicht erst danach - die Leute, deren Arbeit sich ändert, müssen ab Woche 1 Co-Owner sein.
• Phase-2-Budget abhängig von Metriken vorab genehmigen - wenn der Pilot sein Ziel erreicht, ist die nächste Phase automatisch finanziert.
• Hartes Pilot-Ende-Datum setzen - 12 bis 16 Wochen. Pilot läuft nur weiter, wenn Metriken validieren; sonst stoppen, nicht treiben lassen.

Fehler 10: Change Management ignoriert

Der Agent ist technisch perfekt. Er funktioniert, argumentiert gut, produziert gute Outputs. Die Nutzer waren nicht im Scoping, wurden zwei Tage vor Go-Live geschult und haben keinen Einfluss darauf, wie der Agent ihre Arbeit verändert. Nach Go-Live finden sie Wege, ihn zu umgehen, ihn zu ignorieren oder ihn leise zu sabotieren. Der Agent läuft; der Wert landet nie.

Wie Change-Management-Vernachlässigung aussieht

• Nutzer erfahren vom Projekt aus Ankündigungen, nicht aus Gesprächen - die Botschaft landet als „Eure Arbeit wird automatisiert", egal mit welcher Absicht.
• Schulung ist ein halbtägiges Event, kein eingebettetes Coaching - Nutzer vergessen innerhalb von zwei Wochen.
• Der Agent wird als Arbeit-ersetzend positioniert, nicht als Arbeit-erweiternd - Nutzer widerstehen Ersatz natürlich.
• Feedback-Loops sind nicht in den Betrieb eingebaut - Nutzer haben keinen Kanal, Agent-Fehler zu melden, Verbesserungen vorzuschlagen oder Frustration zu eskalieren.
• Performance-Metriken werden nicht angepasst - Nutzer werden weiter an KPIs gemessen, die der Agent jetzt beeinflusst, aber niemand hat die Ziele aktualisiert.

Change Management, das funktioniert

• Nutzer im Scoping einbinden - die Leute, deren Arbeit sich ändert, gestalten den Agenten mit. Ihr Wissen verbessert das Design und ihre Beteiligung reduziert späteren Widerstand.
• Den Agenten als Ergänzung framen, nicht als Ersatz - der Agent entfernt die langweilige, repetitive, ausnahmelastige Arbeit, damit das Team sich auf urteilsabhängige Arbeit konzentriert.
• Coachen, nicht schulen - eingebetteter Support im ersten Monat, kein einmaliges Schulungs-Event.
• Feedback-Loops in den täglichen Betrieb einbauen - 5 Minuten pro Tag für Nutzer, um Agent-Fehler zu markieren, Verbesserungen vorzuschlagen.
• Metriken an die neue Arbeit anpassen - wenn der Agent 70 Prozent der Routinefälle handhabt, sollten die KPIs widerspiegeln, dass das Team jetzt mehr Zeit auf den schwierigeren 30 Prozent verbringt.
• Das Team feiern, nicht den Agenten - das Team, das den Agenten gut nutzt, verdient die Anerkennung. Der Agent ist ein Werkzeug.

Wie alle 10 in 90 Tagen vermeiden

Die Fehler clustern sich. Unternehmen, die einen treffen, treffen meist mehrere. Unternehmen, die einen vermeiden, vermeiden meist die meisten. Der 90-Tage-Plan unten sequenziert die Vermeidungsarbeit so, dass jeder Fehler schwerer zu machen wird.

Wochen 1 bis 3: Scoping und Diagnose

• Drei Kandidaten-Prozesse wählen - messbarer Schmerz, begrenzter Scope, verfügbarer Fachbereichs-Sponsor.
• Fehler-2-Vermeidung anwenden - jeden auf Volumen, Ausnahmequote, Sponsor-Bereitschaft, Datenqualität bewerten.
• Erfolgsmetriken definieren für den gewählten Prozess - eingesparte Stunden, Ausnahmequote, Zykluszeit.
• Datenqualität auditieren - bei Audit-Versagen reparieren oder anderen Prozess wählen.
• Fachbereichs-Sponsor bestätigen - Abteilungsleiter, nicht IT.
• Datenschutzbeauftragte und Betriebsrat briefen - Woche 2, nicht Woche 12.
• Den Prozess Ende-zu-Ende mappen - das Artefakt, das alles spätere briefet.

Wochen 4 bis 8: Mit HITL und Ersetzbarkeit bauen

• Auf die Prozesskarte bauen - nicht auf die Anbieter-Demo.
• HITL-Schwellen explizit definieren - was triggert Genehmigung, wer genehmigt, wie schnell.
• Portable Abstraktionen verwenden - Prompts und Tool-Definitionen, die einen Anbieter-Wechsel überleben.
• EU-Deployment bestätigt - Daten verlassen den Perimeter nicht.
• Audit-Logging vorhanden - jede Agent-Aktion mit vollem Kontext geloggt.
• Gegen historische Fälle testen - echte Ausnahmen, keine synthetischen Testdaten.

Wochen 9 bis 12: Begrenztes Deployment mit Feedback

• 20 Prozent des Volumens in Produktion - Parallellauf mit dem bestehenden Prozess für zwei Wochen.
• Tägliche Nutzer-Feedback-Kanäle - 5 Minuten pro Schicht zum Markieren von Problemen.
• Wöchentliche Prüfung jeder Eskalation und Korrektur - die Daten füttern Agent-Verbesserung.
• Gegen Baseline messen - die in Woche 1 definierten Metriken.
• Vorab genehmigter Phase-2-Trigger - wenn Metriken validieren, ist Skalierung finanziert.

Wie Superkind hineinpasst

Superkind baut individuelle KI-Agenten für den Mittelstand mit einem expliziten Anti-Fehler-Playbook. Die 10 Fehler sind keine Checkliste, die wir gelegentlich anwenden - sie sind, wie wir jedes Projekt ab Woche 1 strukturieren.

Wie wir Projekte gegen die 10 Fehler strukturieren

• Definiertes Geschäftsergebnis - jedes Projekt startet mit einer messbaren Erfolgsmetrik und einer Baseline-Zahl, nicht mit einem Capability-Versprechen.
• Richtiger erster Use Case - wir sagen Nein zu Use Cases, die zu einfach oder zu schwer sind. Lieber das Projekt zurückstellen als den falschen ersten Agenten bauen.
• Datenqualitäts-Audit - Woche-1-Lieferobjekt. Wenn die Daten versagen, machen wir das Problem sichtbar, bevor wir Build-Arbeit berechnen.
• Process-First-Build - der Agent wird um die echte Prozesskarte gebaut, nicht um Anbieter-Demos. Erst mappen, dann bauen.
• Fachbereichs-geführte Ownership - der betroffene Fachbereich ist Projekt-Owner. IT ist kritischer Partner.
• HITL by design - Genehmigungs-Schwellen, Eskalations-Flüsse und Audit-Logs sind Teil der Architektur, kein Add-on.
• Ersetzbarkeit eingebaut - EU-Deployment, portable Abstraktionen, offene Datenformate. Sie können uns verlassen; viele unserer Kunden haben es nicht, aber sie könnten.
• Compliance früh gebrieft - Woche-2-Gespräch mit Datenschutzbeauftragten und Betriebsrat. Nicht beim Go-Live.
• Vorab genehmigter Skalierungsplan - Phase-2-Trigger und -Budget in Woche 1 vereinbart. Pilot-Fegefeuer strukturell vermieden.
• Nutzer gestalten den Agenten mit - Prozess-Owner und Endnutzer im Scoping. Feedback-Loops im täglichen Betrieb.

Verwandte Artikel

• Warum 95% aller KI-Projekte im Mittelstand scheitern - und was die anderen 5% anders machen
• Prozesse zuerst digitalisieren, dann KI einsetzen: Warum KI kaputte Abläufe nicht heilt
• Deine KI ist nur so gut wie deine Daten: Warum Datenqualität der Hauptgrund für gescheiterte KI-Projekte ist
• Der 12-Monats-KI-Fahrplan für den Mittelstand: Vom ersten Piloten zum KI-nativen Unternehmen
• KI-Adoption im Mittelstand: Wie deutsche KMU vom ersten Pilotprojekt zum unternehmensweiten Einsatz kommen

Häufige Fragen

Henri Jung

Co-Founder bei Superkind

Co-Founder von Superkind, wo er KMUs und Konzernen hilft, individuelle KI-Agenten einzuführen, die wirklich zu der Art und Weise passen, wie Teams arbeiten. Henri brennt dafür, die Lücke zwischen dem, was KI kann, und dem Wert, den sie in echten Unternehmen schafft, zu schliessen. Er glaubt, dass der Mittelstand alles hat, um in KI führend zu sein - er braucht nur den richtigen Ansatz.