Kurze Antwort: KI-Projekte scheitern zu 60–80 % an organisationalen, nicht technischen Faktoren. Die häufigsten Fehler: kein dedizierter Prozessverantwortlicher, Mitarbeiter erst beim Rollout informieren, Widerstand ignorieren statt verstehen, und Erfolg nur an Lizenznutzung messen. Wer diese Fehler kennt, kann sie umgehen.
Warum KI-Projekte wirklich scheitern
Ein Werkzeug wird beschafft, eingeführt, erklärt — und dann kaum genutzt. Dieses Muster kennt fast jede Führungskraft. Bei KI-Projekten potenziert es sich: Die Erwartungen sind höher, die Unsicherheit im Team ist größer, und die Veränderung ist tiefgreifender als bei einem neuen CRM-System.
Studien zu Digitalisierungsprojekten zeigen konsistent: 60 bis 80 % scheitern nicht an der Technologie, sondern an der Organisation. Fehlende Verantwortlichkeiten, unklare Kommunikation, ignorierter Widerstand. Was bei klassischen IT-Projekten gilt, gilt bei KI noch stärker — weil KI in viele bestehende Abläufe eingreift und Fragen aufwirft, die über Technik hinausgehen: Wer entscheidet noch? Was wird von mir erwartet? Was passiert, wenn KI einen Fehler macht?
Die gute Nachricht: Diese Fehler sind bekannt, sie sind wiederholbar — und sie sind vermeidbar. Hier sind die sieben, die ich in KMU immer wieder beobachte.
Die 7 Fehler im Detail
01
KI als IT-Projekt behandeln
Die IT beschafft das Tool, die IT führt ein, die IT schullt — und die Fachabteilung wartet auf die Übergabe. Ergebnis: Das Tool ist da, aber niemand aus dem Fachbereich fühlt sich verantwortlich. Nutzung bleibt aus oder beschränkt sich auf Enthusiasten.
Lösung: Prozessverantwortung liegt im Fachbereich, IT unterstützt. Vom ersten Tag an.
02
Mitarbeiter erst beim Rollout informieren
Wenn Mitarbeiter von der KI-Einführung erfahren, wenn alles schon entschieden ist, entsteht Misstrauen. "Die machen das sowieso, ohne uns zu fragen." Das ist kein Widerstand gegen KI — das ist Widerstand gegen Missachtung.
Lösung: Frühzeitig kommunizieren, bevor Tools ausgewählt werden. Auch wenn noch nichts feststeht.
03
Widerstand als Problem statt als Information behandeln
"Der Herr Müller ist halt gegen alles Neue." Widerstand hat fast immer einen Grund: Angst vor Kontrolle, Unsicherheit über die eigene Rolle, schlechte Erfahrungen mit früheren Projekten. Wer Widerstand wegdrückt, verliert wertvolle Information — und den Mitarbeiter langfristig.
Lösung: Bedenken aktiv sammeln und öffentlich adressieren — nicht wegargumentieren.
04
Erfolg nur an Lizenznutzung messen
"90 % der Lizenzen werden genutzt" klingt gut — sagt aber nichts darüber aus, ob die KI-Nutzung die Arbeit verbessert. Nutzung ist kein Ergebnis. Prozesszeit, Fehlerquote, Entscheidungsqualität — das sind Ergebnisse.
Lösung: Vom ersten Tag an 2–3 konkrete Wirkungsindikatoren definieren, nicht Nutzungsquoten.
05
Führung zieht sich nach dem Kickoff zurück
Der Geschäftsführer eröffnet das Kickoff-Meeting, dann übernimmt das Projektteam. Signal ans Unternehmen: Das ist ein Projekt auf mittlerer Ebene, kein strategisches Vorhaben. Die Mitarbeiter lesen das korrekt und priorisieren entsprechend.
Lösung: Führung zeigt regelmäßige Präsenz — kurze Updates, sichtbare Nutzung selbst, Fragen stellen.
06
Schulung als Einmal-Event planen
Ein 2-Stunden-Workshop bei Einführung, und dann ist "Schulung erledigt". KI-Tools entwickeln sich schnell, Nutzungsszenarien wachsen, neue Mitarbeiter kommen dazu. Wer Schulung als Einmal-Event versteht, hat innerhalb von 3 Monaten veraltetes Wissen im Team.
Lösung: Wiederkehrende kurze Update-Formate einplanen — 30 min monatlich genügt.
07
Keine Governance — weder für Erfolg noch für Fehler
Was passiert, wenn die KI eine falsche Empfehlung gibt? Wer trägt Verantwortung, wenn ein KI-gestützter Prozess einen Fehler produziert? Wenn diese Fragen nicht vorab geklärt sind, entsteht nach dem ersten Incident Verwirrung, Schuldzuweisungen — und oft: Vertrauensverlust in die gesamte Initiative.
Lösung: Vor dem Go-live einen einfachen Governance-Rahmen definieren: Rollen, Eskalationswege, Dokumentationspflichten.
Was erfolgreiche KMU stattdessen tun
Die Unternehmen, bei denen KI-Einführungen tatsächlich wirken, teilen keine technischen Gemeinsamkeiten — sie teilen organisationale. Sie behandeln die Einführung als Veränderungsprojekt, nicht als Beschaffungsvorgang. Sie kommunizieren früher als nötig. Und sie messen Wirkung statt Nutzung.
Was funktioniert
Pilotgruppe aus freiwilligen Frühanwendern bilden → interne Multiplikatoren nutzen → Bedenken öffentlich adressieren → Wirkung früh sichtbar machen → Governance vor dem Go-live klären. Das ist kein Enterprise-Aufwand. Das ist strukturiertes Vorgehen mit Augenmaß.
Die Rolle der Führungskraft im KI-Change
Führungskräfte müssen keine KI-Experten werden. Aber sie müssen drei Dinge tun: Richtung geben (Warum machen wir das?), Sicherheit geben (Was ändert sich für euch — und was nicht?) und sichtbar bleiben (ich nutze das selbst, ich frage nach, ich interessiere mich für Rückmeldung).
Wenn Führung das nicht leistet, füllt sich das Vakuum mit Gerüchten, Angst und Abwarten. Das ist kein Führungsversagen — das ist ein strukturelles Problem, das sich mit klarer Kommunikation lösen lässt.
Führungs-Checkliste
Vor dem Start: Warum dieses Projekt jetzt? Was ändert sich konkret? Wer ist Prozessverantwortlicher? Während des Projekts: Bin ich sichtbar? Adressiere ich Bedenken öffentlich? Nach dem Rollout: Messen wir Wirkung? Gibt es einen Governance-Rahmen für Fehler?
Krótka odpowiedź: Projekty AI upadają w 60–80% z powodów organizacyjnych, nie technicznych. Najczęstsze błędy: brak właściciela procesu, informowanie pracowników dopiero przy wdrożeniu, ignorowanie oporu i mierzenie sukcesu tylko liczbą licencji. Kto zna te błędy, może ich uniknąć.
Dlaczego projekty AI naprawdę upadają
Narzędzie zostaje zakupione, wdrożone, wyjaśnione — a potem ledwo używane. Ten wzorzec zna niemal każdy lider. W projektach AI się wzmacnia: oczekiwania są wyższe, niepewność w zespole większa, a zmiana głębsza niż przy nowym systemie CRM.
Badania projektów cyfryzacyjnych pokazują konsekwentnie: 60–80% nie upada z powodu technologii, lecz z powodu organizacji. Brak odpowiedzialności, niejasna komunikacja, zignorowany opór. To co dotyczy zwykłych projektów IT, przy AI ma jeszcze większe znaczenie.
7 błędów w szczegółach
01
Traktowanie AI jako projektu IT
IT kupuje, wdraża i szkoli — a dział merytoryczny czeka na przekazanie. Efekt: narzędzie jest, ale nikt w dziale nie czuje odpowiedzialności za jego użycie.
Rozwiązanie: Odpowiedzialność za proces leży w dziale merytorycznym. IT wspiera — od pierwszego dnia.
02
Informowanie pracowników dopiero przy wdrożeniu
Gdy pracownicy dowiadują się o AI dopiero po podjęciu wszystkich decyzji, pojawia się nieufność. To nie jest opór wobec AI — to opór wobec bycia pominiętym.
Rozwiązanie: Komunikować wcześnie — zanim wybrane zostaną narzędzia. Nawet jeśli nic nie jest jeszcze pewne.
03
Traktowanie oporu jako problemu, nie jako informacji
Opór prawie zawsze ma przyczynę: strach przed kontrolą, niepewność co do własnej roli, złe doświadczenia z poprzednich projektów. Kto opór odpycha, traci cenną informację — i pracownika.
Rozwiązanie: Aktywnie zbierać obawy i publicznie je adresować — nie odpierać argumentami.
04
Mierzenie sukcesu tylko liczbą licencji
"90% licencji jest używanych" brzmi dobrze — ale nic nie mówi o tym, czy AI poprawia pracę. Użycie to nie wynik.
Rozwiązanie: Od pierwszego dnia zdefiniować 2–3 konkretne wskaźniki efektu, nie wskaźniki użycia.
05
Kierownictwo wycofuje się po kickoffie
Prezes otwiera spotkanie inauguracyjne, potem przejmuje zespół projektowy. Sygnał dla firmy: to projekt średniego szczebla, nie inicjatywa strategiczna.
Rozwiązanie: Widoczna obecność kierownictwa — krótkie aktualizacje, własne użycie narzędzia, zadawanie pytań.
06
Szkolenie jako jednorazowe wydarzenie
Dwugodzinny warsztat przy wdrożeniu i "szkolenie gotowe". Narzędzia AI rozwijają się szybko, scenariusze użycia rosną. W ciągu 3 miesięcy wiedza w zespole jest przestarzała.
Rozwiązanie: Zaplanować regularne krótkie formaty aktualizacyjne — 30 minut miesięcznie wystarczy.
07
Brak governance — ani dla sukcesu, ani dla błędów
Co się dzieje, gdy AI da błędną rekomendację? Kto ponosi odpowiedzialność? Jeśli te pytania nie są wyjaśnione przed uruchomieniem, po pierwszym incydencie pojawia się zamieszanie i utrata zaufania.
Rozwiązanie: Przed uruchomieniem zdefiniować prosty ramowy model governance: role, ścieżki eskalacji, obowiązki dokumentacyjne.
Co robią skuteczne MŚP
Firmy, w których wdrożenia AI rzeczywiście działają, nie mają technicznych wspólnych mianowników — mają organizacyjne. Traktują wdrożenie jako projekt zmiany, nie jako zakup. Komunikują wcześniej niż konieczne. I mierzą efekt, nie użycie.
Co działa
Pilotowa grupa ochotniczych wczesnych użytkowników → wewnętrzni multiplikatorzy → publiczne adresowanie obaw → wczesne uwidocznienie efektów → governance przed uruchomieniem. To nie jest wysiłek korporacyjny. To strukturalne podejście z wyczuciem proporcji.
Short answer: AI projects fail 60–80% of the time due to organisational, not technical, factors. The most common mistakes: no dedicated process owner, informing employees only at rollout, ignoring resistance, and measuring success by licence usage. Knowing these mistakes means you can avoid them.
Why AI Projects Really Fail
A tool is procured, introduced, explained — and then barely used. Almost every leader knows this pattern. With AI projects, it amplifies: expectations are higher, team uncertainty is greater, and the change runs deeper than a new CRM system.
Research on digitalisation projects consistently shows: 60 to 80% fail not because of the technology, but because of the organisation. Missing accountability, unclear communication, ignored resistance. What applies to classic IT projects applies even more to AI — because AI touches existing workflows and raises questions that go beyond technology: Who still decides? What's expected of me? What happens when AI makes a mistake?
The 7 Mistakes in Detail
01
Treating AI as an IT project
IT procures, implements, and trains — and the business unit waits for handover. Result: the tool exists, but no one in the business unit feels responsible. Usage remains low or limited to enthusiasts.
Fix: Process ownership sits in the business unit; IT supports. From day one.
02
Informing employees only at rollout
When employees hear about AI once everything is already decided, distrust forms. This isn't resistance to AI — it's resistance to being left out.
Fix: Communicate early — before tools are selected. Even when nothing is decided yet.
03
Treating resistance as a problem rather than information
Resistance almost always has a reason: fear of surveillance, uncertainty about one's role, bad experiences from past projects. Suppressing resistance loses valuable information — and the employee long-term.
Fix: Actively collect concerns and address them publicly — don't argue them away.
04
Measuring success only by licence usage
"90% of licences are used" sounds good — but says nothing about whether AI is improving work. Usage is not an outcome.
Fix: Define 2–3 concrete impact indicators from day one, not usage rates.
05
Leadership withdraws after the kickoff
The CEO opens the kickoff meeting, then the project team takes over. Signal to the organisation: this is a middle-management project, not a strategic initiative. Employees read that correctly and prioritise accordingly.
Fix: Leadership shows regular presence — brief updates, visible personal use, asking questions.
06
Treating training as a one-off event
A 2-hour workshop at launch, and then "training is done". AI tools evolve fast, use cases grow, new employees join. Within 3 months, team knowledge is outdated.
Fix: Plan recurring short update formats — 30 minutes monthly is sufficient.
07
No governance — for successes or failures
What happens if AI gives a wrong recommendation? Who is responsible when an AI-assisted process produces an error? If these questions aren't clarified before launch, the first incident causes confusion, blame — and loss of trust.
Fix: Define a simple governance framework before go-live: roles, escalation paths, documentation requirements.
What Successful SMEs Do Instead
Companies where AI implementations actually deliver don't share technical commonalities — they share organisational ones. They treat introduction as a change project, not a procurement exercise. They communicate earlier than necessary. And they measure impact, not usage.
What works
Build a pilot group of volunteer early adopters → use internal multipliers → address concerns publicly → make impact visible early → clarify governance before go-live. This isn't enterprise effort. It's structured, proportionate thinking.
The Leadership Role in AI Change
Leaders don't need to become AI experts. But they need to do three things: give direction (Why are we doing this?), give security (What changes for you — and what doesn't?) and stay visible (I use this myself, I ask questions, I care about feedback).
When leadership doesn't deliver this, the vacuum fills with rumours, fear and wait-and-see. That's not a leadership failure — it's a structural problem that clear communication can solve.
Réponse courte : Les projets d'IA échouent dans 60 à 80 % des cas pour des raisons organisationnelles, et non techniques. Les erreurs les plus fréquentes : absence de responsable de processus dédié, collaborateurs informés seulement au moment du déploiement, résistance ignorée au lieu d'être comprise, et succès mesuré uniquement par l'utilisation des licences. Connaître ces erreurs permet de les éviter.
Pourquoi les projets d'IA échouent vraiment
Un outil est acquis, déployé, expliqué — puis à peine utilisé. Presque tous les dirigeants connaissent ce schéma. Avec les projets d'IA, il s'amplifie : les attentes sont plus élevées, l'incertitude au sein de l'équipe est plus grande, et le changement est plus profond que pour un nouveau système CRM.
Les études sur les projets de transformation numérique montrent de manière constante : 60 à 80 % échouent non pas à cause de la technologie, mais à cause de l'organisation. Responsabilités manquantes, communication floue, résistance ignorée. Ce qui vaut pour les projets IT classiques vaut encore plus pour l'IA — car l'IA touche de nombreux processus existants et soulève des questions qui dépassent la technique : qui décide encore ? Qu'attend-on de moi ? Que se passe-t-il si l'IA commet une erreur ?
La bonne nouvelle : ces erreurs sont connues, elles sont récurrentes — et elles sont évitables. Voici les sept que j'observe régulièrement dans les PME.
Les 7 erreurs en détail
01
Traiter l'IA comme un projet IT
L'IT acquiert l'outil, l'IT le déploie, l'IT forme — et le métier attend la passation. Résultat : l'outil est là, mais personne côté métier ne s'en sent responsable. L'utilisation reste faible ou limitée aux enthousiastes.
Solution : la responsabilité du processus relève du métier, l'IT accompagne. Dès le premier jour.
02
Informer les collaborateurs seulement au moment du déploiement
Lorsque les collaborateurs découvrent l'introduction de l'IA alors que tout est déjà décidé, la méfiance s'installe. Ce n'est pas de la résistance à l'IA — c'est de la résistance au fait d'être mis à l'écart.
Solution : communiquer tôt — avant même la sélection des outils. Même si rien n'est encore décidé.
03
Traiter la résistance comme un problème plutôt que comme une information
La résistance a presque toujours une raison : peur du contrôle, incertitude quant à son propre rôle, mauvaises expériences avec des projets antérieurs. Réprimer la résistance, c'est perdre une information précieuse — et le collaborateur à long terme.
Solution : recueillir activement les préoccupations et les traiter publiquement — ne pas les balayer par des arguments.
04
Mesurer le succès uniquement par l'utilisation des licences
« 90 % des licences sont utilisées » sonne bien — mais ne dit rien sur l'amélioration réelle du travail grâce à l'IA. L'utilisation n'est pas un résultat.
Solution : définir dès le premier jour 2 à 3 indicateurs d'impact concrets, et non des taux d'utilisation.
05
La direction se retire après le lancement
Le dirigeant ouvre la réunion de lancement, puis l'équipe projet prend le relais. Signal envoyé à l'entreprise : il s'agit d'un projet de niveau intermédiaire, pas d'une initiative stratégique. Les collaborateurs le comprennent bien et priorisent en conséquence.
Solution : la direction montre une présence régulière — mises à jour brèves, utilisation personnelle visible, questions posées.
06
Considérer la formation comme un événement ponctuel
Un atelier de 2 heures au lancement, et la « formation est réglée ». Les outils d'IA évoluent rapidement, les cas d'usage se multiplient, de nouveaux collaborateurs arrivent. En 3 mois, les connaissances de l'équipe sont obsolètes.
Solution : prévoir des formats courts récurrents de mise à jour — 30 minutes par mois suffisent.
07
Pas de gouvernance — ni pour les succès, ni pour les erreurs
Que se passe-t-il si l'IA donne une recommandation erronée ? Qui assume la responsabilité lorsqu'un processus assisté par l'IA produit une erreur ? Si ces questions ne sont pas clarifiées avant le lancement, le premier incident provoque confusion, accusations — et souvent une perte de confiance dans l'ensemble de l'initiative.
Solution : définir avant le lancement un cadre de gouvernance simple : rôles, voies d'escalade, obligations de documentation.
Ce que font les PME qui réussissent
Les entreprises où l'introduction de l'IA produit réellement des résultats ne partagent pas de caractéristiques techniques communes — elles partagent des caractéristiques organisationnelles. Elles traitent le déploiement comme un projet de changement, et non comme un achat. Elles communiquent plus tôt que nécessaire. Et elles mesurent l'impact, pas l'utilisation.
Ce qui fonctionne
Constituer un groupe pilote de premiers utilisateurs volontaires → utiliser des multiplicateurs internes → traiter publiquement les préoccupations → rendre l'impact visible rapidement → clarifier la gouvernance avant le lancement. Ce n'est pas un effort d'entreprise. C'est une approche structurée et proportionnée.
Le rôle du dirigeant dans la conduite du changement lié à l'IA
Les dirigeants n'ont pas besoin de devenir des experts en IA. Mais ils doivent faire trois choses : donner une direction (Pourquoi faisons-nous cela ?), donner de la sécurité (Qu'est-ce qui change pour vous — et qu'est-ce qui ne change pas ?) et rester visibles (j'utilise cela moi-même, je pose des questions, je m'intéresse aux retours).
Lorsque la direction ne remplit pas ce rôle, le vide se comble de rumeurs, de peur et d'attentisme. Ce n'est pas un échec du leadership — c'est un problème structurel qu'une communication claire peut résoudre.
Checklist pour les dirigeants
Avant le démarrage : Pourquoi ce projet maintenant ? Qu'est-ce qui change concrètement ? Qui est responsable du processus ? Pendant le projet : Suis-je visible ? Est-ce que je traite les préoccupations publiquement ? Après le déploiement : Mesurons-nous l'impact ? Existe-t-il un cadre de gouvernance pour les erreurs ?
Führung & Steuerung
Führungsstruktur-Check
Wie gut ist Ihre Führungsstruktur aufgestellt? 8 Fragen, 5 Minuten, konkrete Handlungsempfehlungen — kostenlos, kein Login.
Führungsstruktur prüfen →
VON DARIUSZ ŻALIK — PASSEND ZU DIESEM ARTIKEL
AŻ
ÜBER DIE AUTORIN
Anja Żalik
Senior Partner — Struktur & Operational Excellence
Anja kennt den Moment, wenn Führungskräfte spüren, dass die Organisation nicht mehr steuerbar ist.