KI-Workshops: Warum „User-Feedback“ allein Ihr Projekt ruinieren kann

Willkommen bei IT for Business. Ich bin Mirko Peters. Wir sind IT-Dienstleister für den Mittelstand, und hier geht es nicht um Marketing-Hype, sondern um echte IT-Entscheidungen zu Infrastruktur, Cloud, Security und Architektur aus der Praxis. Wenn Sie Verantwortung für die IT tragen, Entscheidungen treffen oder Dienstleister bewerten müssen, dann sind Sie hier genau richtig. Vernetzen Sie sich auch gerne mit mir auf LinkedIn, falls Sie sich zu diesen Themen direkt austauschen wollen. Ich freue mich immer über Impulse aus der realen Betriebswelt.

Hier ist die Frage, die fast niemand stellt, bevor ein KI-Workshop überhaupt beginnt: Wer entscheidet später eigentlich über den Betrieb, den Datenfluss, die Berechtigungen und die laufenden Kosten? In vielen Unternehmen sammeln die Fachbereiche erst einmal fleißig Wünsche und schnelle Ideen für Anwendungsfälle. Das fühlt sich im ersten Moment produktiv an, ist aber oft nur die halbe Wahrheit. Es wird nämlich selten geklärt, wer die Zielarchitektur verantwortet, wie die Security eingebunden wird und was im harten Alltag aus der Lösung werden soll.

User-Feedback ist wichtig, aber betrachten Sie es bitte nur als frühes Signal und niemals als alleinige Entscheidungsgrundlage. Ohne klare Leitplanken landen Sie schneller bei einer unkontrollierten Schatten-KI oder einem teuren Vendor Lock-in, als Ihnen lieb ist. Bleiben Sie kurz dran, denn heute schauen wir uns an, wie Sie KI-Workshops so aufsetzen, dass am Ende belastbare Entscheidungen stehen und nicht nur eine gut gemeinte Wunschliste. Bevor wir über die Methoden sprechen, müssen wir jedoch einen grundlegenden Denkfehler aus dem Weg räumen.

Abschnitt 1: Der Grundfehler, User-Feedback mit Projektsteuerung zu verwechseln

Seien wir ehrlich: Ihre Nutzer wissen am besten, wo es im Arbeitsalltag hakt. Sie zeigen Ihnen ganz genau die Reibungspunkte, die Doppelerfassungen und die unnötigen Schleifen in den Prozessen auf. Genau für diesen Input brauchen Sie die Kollegen auch. Was Nutzer in der Regel jedoch nicht mitbringen, ist die Verantwortung für das Betriebsmodell, die Integrationsrisiken oder die spätere Support-Struktur. Das ist kein Vorwurf an die Mitarbeiter, sondern schlichtweg nicht deren Aufgabe im Unternehmen.

Genau hier liegt das Risiko, denn viele verwechseln gutes User-Feedback mit echter Projektsteuerung. Wenn zehn Leute im Workshop begeistert fordern, dass sie eine KI für E-Mails oder Protokolle brauchen, dann haben Sie erst einmal nur ein Signal. Mehr nicht. Sie wissen zwar, wo der Schmerz sitzt, aber Sie wissen noch nicht, ob die Daten überhaupt nutzbar sind oder ob vertrauliche Inhalte verarbeitet werden dürfen. Zudem bleibt ungeklärt, welches System am Ende den Kopf hinhalten muss, wenn etwas schiefgeht.

Klartext: User-Feedback zeigt Symptome, aber keine Architektur. Wenn Mitarbeiter berichten, dass sie täglich Informationen aus drei verschiedenen Systemen mühsam zusammensuchen müssen, ist das eine wertvolle Information. Daraus folgt aber noch lange nicht, dass ein Copilot oder ein externer Chatbot die richtige Antwort auf dieses Problem ist. Dazwischen liegen nämlich einige unangenehme Fragen zu Datenzugriffen, Rechtekonzepten und dem Logging. Diese kritischen Punkte werden in vielen Workshops erstaunlich zuverlässig ignoriert.

Das typische Muster im Mittelstand sieht oft so aus: Der Workshop startet mit viel Energie, die Stimmung ist hervorragend und nach einer Stunde ist das Whiteboard voll mit Use Cases. Was dabei auf der Strecke bleibt, sind die harten Fakten wie Datenquellen, Rollenverteilungen, SLAs und der spätere Support. Man spricht ausführlich über den Nutzen, aber niemand fragt, wer nachts den Fehler sucht, wenn der Prozess plötzlich kippt. Das wirkt im Termin zwar effizient, wird aber im weiteren Projektverlauf extrem teuer.

Bei KI ist dieses Vorgehen sogar noch gefährlicher als bei klassischer Software. KI arbeitet mit Wahrscheinlichkeiten und unscharfen Ergebnissen, statt mit festen, starren Regeln. Modelle verhalten sich nicht immer identisch, was neue Anforderungen an die Ergebniskontrolle stellt. Dazu kommen sensible Datenströme und laufende Nutzungskosten, die eine völlig andere Logik als eine einmalige Lizenzzahlung verfolgen. Wenn Sie das im Workshop nicht sauber einordnen, bauen Sie kein hilfreiches Werkzeug, sondern eine Blackbox in Ihre Infrastruktur ein.

Betrachten Sie es wie bei einer Hausrenovierung. Die späteren Bewohner können Ihnen präzise sagen, wo sie mehr Licht oder Stauraum benötigen, was auch völlig berechtigt ist. Wenn jedoch niemand prüft, wo die tragenden Wände verlaufen oder ob man im Wartungsfall überhaupt noch an die Leitungen herankommt, planen Sie an der Realität vorbei. Bei KI-Workshops passiert genau das ständig, nur eben auf digitaler Ebene. Da versteckt sich das eigentliche Risiko für Ihr Budget und Ihre Stabilität.

Was ist also der wahre Wert von User-Feedback? Es dient als Input für die Priorisierung und hilft dabei, die Akzeptanz im Team sicherzustellen. Es zeigt Ihnen auf, welche Stellen im Alltag wirklich schmerzen und wo eine neue Lösung überhaupt einen messbaren Vorteil bringen würde. Was es ausdrücklich nicht leisten kann, ist die Auswahl der Technologie oder die Architekturfreigabe für den produktiven Einsatz. Dafür benötigen Sie andere Rollen und eine ganz andere Flughöhe in der Betrachtung.

Sobald Sie diese Ebenen sauber trennen, wird die nächste Frage entscheidend: Wer muss eigentlich mit an den Tisch, damit aus losen Ideen am Ende tragfähige Entscheidungen werden?

Abschnitt 2: Wer am Tisch sitzen muss, damit aus dem Workshop kein Blindflug wird

Wenn die Zielsetzung steht, folgt die unangenehme, aber notwendige Frage: Wer muss eigentlich mit an den Tisch? Hier ist die eigentliche Frage, die Sie sich stellen sollten: Wer trägt das Risiko, wenn das System später produktiv läuft? Genau daraus ergibt sich die Besetzung. Es geht nicht um Organigramme, nicht um Gewohnheit und schon gar nicht darum, wer gerade zufällig Zeit hat.

Im deutschen Mittelstand reicht es für einen belastbaren KI-Workshop nicht aus, wenn nur der Fachbereich und ein externer Moderator zusammensitzen. Sie brauchen eine Runde, die die spätere Betriebsrealität abbildet. Das bedeutet mindestens den betroffenen Fachbereich, die IT-Architektur sowie Security oder Datenschutz. Je nach Anwendungsfall gehören auch der Betriebsrat, die Prozessverantwortlichen und jemand mit echter Budgetgewalt dazu. Fehlt eine dieser Rollen, fehlt Ihnen später ein entscheidendes Puzzleteil im Live-Betrieb.

Der Fachbereich bringt dabei etwas ein, das kein Berater liefern kann: den echten Prozessschmerz und die Ausnahmen im Alltag. Hier wird definiert, was als Ergebnis überhaupt akzeptabel ist. Gerade bei KI ist das entscheidend, denn sonst bauen Sie ein System, das zwar formal funktioniert, aber an den Sonderfällen scheitert, die jeder Sachbearbeiter nach zwei Minuten erkennt.

Die IT-Architektur schaut dagegen auf einen ganz anderen Horizont. Dort geht es um Integrationsfähigkeit, Berechtigungen, Logging und die Exit-Strategie. Klartext: Die IT muss beantworten, ob der Anwendungsfall in die vorhandene Landschaft passt oder ob Sie gerade anfangen, eine neue Insel zu bauen. Viele Workshops blenden das aus, weil Architektur weniger spannend klingt als ein schneller Demo-Effekt, aber genau da versteckt sich das Risiko.

Security und Datenschutz prüfen unterdessen keine Bequemlichkeit, sondern Datenarten und Schutzbedarf. Das ist keine Verhinderungsrolle, sondern die Instanz, die früh klärt, ob ein Fall überhaupt tragfähig ist. Wenn personenbezogene Daten oder interne Kalkulationen betroffen sind, brauchen Sie diese Prüfung am Anfang und nicht erst, wenn Sie mit viel Aufwand zurückrudern müssen.

Beim Betriebsrat wird in vielen Unternehmen leider erst reagiert, wenn das Projekt praktisch schon fertig gedacht ist. Das ist meist ein Fehler, denn sobald ein System Leistung vergleichbar macht, betreten Sie das Feld der Mitbestimmung. Eine frühe Einbindung ist hier deutlich sauberer als ein später Konflikt, bei dem plötzlich alles auf Pause steht. Das ist kein Nebenthema, sondern gehört zur harten Projektwirklichkeit in Deutschland.

Dann gibt es noch die Prozessverantwortlichen, die oft fälschlicherweise mit dem Fachbereich in einen Topf geworfen werden. Diese Leute müssen sagen können, wo Abhängigkeiten zu Vorprozessen bestehen und was passiert, wenn ein Schritt ausfällt. Ohne diese Sicht bauen Sie leicht an einem Teilprozess herum und übersehen dabei völlig, dass der eigentliche Engpass zwei Stufen weiter liegt.

Schließlich brauchen Sie jemanden aus der Geschäftsleitung für verbindliche Prioritäten. KI-Workshops scheitern oft nicht an Ideenmangel, sondern an einer Art Innovationsfolklore, bei der alle das Thema interessant finden, aber niemand hart entscheidet. Wenn diese Entscheidungskompetenz am Tisch fehlt, produzieren Sie am Ende keine Richtung, sondern nur wohlformulierte Unverbindlichkeit.

Lassen Sie uns das kurz zuspitzen: Ohne diese Rollen bekommen Sie keinen Workshop, sondern eine moderierte Illusion. Es sieht nach Fortschritt aus, weil viele bunte Zettel an der Wand kleben, aber es fehlt das, was später trägt: Verantwortung und ein realistisches Betriebsbild. Jetzt wird es interessant, denn selbst mit den richtigen Leuten scheitern viele Formate an der falschen Reihenfolge der Themen.

Abschnitt 3: Die falsche Reihenfolge ruiniert den Workshop, nicht die Idee

Der nächste Fehler sitzt tiefer, denn viele Unternehmen arbeiten trotz richtiger Besetzung die Themen falsch ab. Oft startet man direkt mit Tools oder lose formulierten Use Cases. Jemand schlägt einen Assistenten vor, ein anderer nennt einen Bot, und nach zwanzig Minuten wird schon über Anbieter diskutiert. Das klingt modern, ist aber fachlich schief, denn die saubere Reihenfolge lautet: erst Zielbild, dann Prozess, dann Daten, dann Risiko und erst ganz am Ende das Tool.

Zuerst muss das Geschäftsproblem präzise auf den Tisch. „Wir wollen etwas mit KI machen“ ist kein Ziel, sondern ein Stimmungsbild. Die Frage ist: Welcher konkrete Engpass soll verschwinden oder welche Entscheidung soll schneller werden? Solange das unscharf bleibt, diskutieren Sie später über teure Lösungen für Probleme, die Sie noch gar nicht sauber beschrieben haben.

Danach kommt der Prozess an die Reihe, und zwar so detailliert, dass die kritischen Entscheidungspunkte sichtbar werden. Wo hängen manuelle Schleifen drin und wo wird heute mühsam korrigiert? Überlegen Sie mal, wie oft ein KI-Fall plötzlich an Bedeutung verliert, wenn man sieht, dass gar nicht die Texterstellung das Problem ist, sondern die fachliche Freigabe zwei Schritte später. Da wird es riskant, wenn man zu früh an der falschen Stelle automatisiert.

Als Nächstes müssen Sie die Datenrealität prüfen, also das, was tatsächlich vorhanden ist. Woher kommen die Daten, wie sauber sind sie und lassen sie sich später auch wieder löschen? Viele Workshops tun so, als seien Daten einfach da, weil sie irgendwo im System liegen. Aber Datenbestand ist nicht gleich Datenverwendbarkeit, und zwischen beidem liegt meist mehr Arbeit, als man im ersten Workshop hören möchte.

Dann gehört die Risikoklasse auf den Tisch, um die nötigen Leitplanken festzulegen. Braucht es eine menschliche Freigabe und welche Ergebnisse dürfen niemals automatisch in den Prozess zurücklaufen? Das ist keine akademische Übung. Wenn Sie diese Governance-Fragen nicht früh klären, diskutieren Sie am Ende über Tempo, obwohl Sie die Kontrollmechanik für den Ernstfall noch gar nicht gebaut haben.

Erst danach sollten Sie über die Zielarchitektur und das Betriebsmodell sprechen. Ob Cloud oder On-Premise ist keine Glaubensfrage, sondern eine Frage der operativen Stabilität. Architektur schlägt Tools – das ist nicht kompliziert, es wird oft nur unnötig kompliziert erklärt. Wenn diese Punkte stehen, lohnt sich erst die Priorisierung, was sofort pilotierbar ist und was im Moment einfach nicht tragfähig erscheint.

Ein guter Pilot hat klare Annahmen und feste Prozessgrenzen. Wird diese Reihenfolge ignoriert, kippt der Workshop fast zwangsläufig in Richtung Schatten-KI. Teams wollen Probleme lösen, die zentrale Klärung dauert zu lange, und plötzlich werden private Accounts für Einzeltools genutzt. Kurzfristig wirkt das pragmatisch, aber mittelfristig entsteht daraus eine Sammlung isolierter Entscheidungen, die hinten und vorne nicht zusammenpassen.

Genau so entstehen diese berüchtigten Frankenstein-Integrationen. Jede Abteilung löst einen Teil für sich, und im Demo-Termin sieht alles brauchbar aus, aber niemand verantwortet das große Ganze. Später hängt ein Prozess an fünf verschiedenen Tools und unklaren Zuständigkeiten. Dann wird aus einem Workshop, der eigentlich Orientierung schaffen sollte, der Startpunkt für neue, teure Komplexität. Und genau hier müssen wir über die echten Kosten im laufenden Betrieb sprechen.

Abschnitt 4: Die echten Kosten stehen nicht im Prompt, sondern im Betrieb

Seien wir ehrlich – der teure Teil bei KI ist selten der erste Testlauf. So ein Pilotprojekt ist oft sogar so günstig, dass es fast harmlos wirkt. Ein Team spielt ein bisschen mit einem Assistenten herum, baut einen Prototypen und plötzlich läuft ein Fachprozess gefühlt schneller. Genau hier schnappt die Falle zu. Man glaubt, das Thema wirtschaftlich im Griff zu haben, nur weil der Einstieg wenig gekostet hat. Aber das ist ein Trugschluss. Die eigentliche Rechnung wird Ihnen erst präsentiert, wenn aus der Spielerei ein verlässlicher Betrieb werden soll.

Ab diesem Punkt reden wir nämlich nicht mehr über einen schicken Prompt oder eine bunte Oberfläche. Jetzt geht es um Lizenzen, API-Gebühren, die Integration in Ihre Legacy-Systeme und Themen wie Monitoring, Security oder Governance. Das sind CAPEX und OPEX in einer Größenordnung, die viele Fachbereiche am Anfang überhaupt nicht auf dem Schirm haben. Ein Test kostet fast nichts, aber ein tragfähiger Betrieb verlangt Planung, klare Zuständigkeiten und eine Menge Disziplin.

In meinen Workshops fällt mir immer wieder auf, dass die Teilnehmer fast nie nach den Dingen fragen, die später den Aufwand treiben. Kaum jemand erkundigt sich von sich aus nach Logging, Rollback-Szenarien, dem nächsten Modellwechsel oder einem sauberen Berechtigungsmodell. Das ist menschlich, weil diese Punkte nicht den aktuellen Schmerz im Prozess lindern, sondern „nur“ die Betriebsfähigkeit sichern. Doch genau hier entscheidet sich, ob Sie eine echte Infrastruktur aufbauen oder nur einen netten Versuch mit eingebautem Verfallsdatum starten.

Bei klassischer Software konnten Sie Unsauberkeiten in der Architektur oft noch eine Zeit lang kaschieren. Bei KI fliegt Ihnen das deutlich schneller um die Ohren, weil die Qualität hier nicht statisch bleibt. Antworten verändern sich, die Datenlage verschiebt sich und die Kosten schwanken massiv mit der Nutzung. Betrachten Sie die Day-2-Operations daher nicht als technischen Nachtrag, sondern als den eigentlichen Prüfstein für Ihr Vorhaben. Wer überwacht die Fehlerraten, wer erkennt einen „Drift“ in der Qualität und wer merkt, wenn das System fachlich schlechter wird, obwohl technisch noch alles grün leuchtet? Da trennt sich die Demo vom echten Betrieb.

Oft landen Unternehmen dann in den typischen Kostenfallen, weil Standards fehlen und jedes Team ein eigenes Tool für denselben Zweck nutzt. Was im ersten Meeting nach Tempo aussah, wird später zur teuren Dauerbaustelle bei der Nachintegration. Wenn ein Anbieter erst einmal tief in Ihren Prozessen sitzt, merken Sie oft zu spät, wie schmerzhaft ein Wechsel wäre. Ein Vendor Lock-in ist kein reines Vertragsthema, sondern ein Architekturfehler, den man am Anfang ignoriert und im laufenden Betrieb teuer bezahlt.

Ein Punkt wird dabei besonders gern verdrängt: Schatten-KI entsteht meistens nicht aus böser Absicht, sondern ist die logische Folge einer schlechten Workshopführung. Wenn offizielle Formate nur Ideen sammeln, statt belastbare Entscheidungen zu liefern, helfen sich die Fachbereiche eben selbst. Die Leute wollen ihre Probleme heute lösen und nicht erst in neun Monaten, also nutzen sie private Accounts oder Browser-Erweiterungen. Die IT darf das Chaos dann später aufräumen, und dieses Aufräumen ist am Ende des Tages fast nie günstig.

Was bedeutet das konkret für Sie? Bevor Sie einen Use Case freigeben, brauchen Sie drei klare Bilder: ein Betriebsbild, ein Datenbild und ein Kostenbild. Das Betriebsbild klärt, wer das System überwacht und im Fehlerfall eingreift, während das Datenbild die Herkunft und den Schutzbedarf der Informationen regelt. Das Kostenbild zeigt Ihnen schließlich nicht nur die Einstiegshürde, sondern die langfristigen Folgen für Pflege und Anpassung. Wenn eines dieser Bilder fehlt, entscheiden Sie im Nebel.

Damit das Ganze nicht zu abstrakt bleibt, hilft eine einfache Prüfmatrix mit sechs harten Fragen. Welchen Nutzen hat der Fall wirklich? Auf welche Daten greifen wir zu? Wie hoch ist der Aufwand für Integration und Betrieb? Welche Compliance-Risiken gehen wir ein? Und die wichtigste Frage: Wie kommen wir wieder aus der Nummer raus, wenn das Modell oder die Kosten nicht mehr passen? Das ist keine Bürokratie, sondern schlichte Mindesthygiene für eine vernünftige Investition.

Klartext: Wenn ein Use Case im Workshop zwar gut klingt, aber im Betrieb nicht tragfähig ist, dann ist er schlicht nicht reif. Er ist nicht „spannend“ oder „ausbaufähig“, er ist einfach nicht bereit für den Einsatz. Diese Erkenntnis spart Ihnen im Zweifel mehr Geld als jeder überhastete Pilotversuch, der später in der Realität stecken bleibt. Bleiben Sie kurz dran, denn jetzt schauen wir uns an, wie man so einen Workshop so aufbaut, dass er genau diese harten Entscheidungen vorbereitet.

Abschnitt 5: So strukturieren Sie einen KI-Workshop, der zu Entscheidungen führt

Wenn Sie einen Workshop aufsetzen wollen, der echte Ergebnisse liefert, beginnt die eigentliche Arbeit lange vor dem Termin. Sie brauchen vorab eine Stakeholder-Matrix, ein klar definiertes Zielproblem und einen ehrlichen Blick auf Ihre Systemlandschaft. Legen Sie außerdem Ausschlusskriterien fest, damit Sie Fälle, bei denen die Datenqualität nicht reicht oder der Schutzbedarf zu hoch ist, gar nicht erst diskutieren. Diese Vorarbeit verhindert, dass Ihr Termin in zwanzig verschiedene Richtungen gleichzeitig läuft und am Ende nur Zeit frisst.

Lassen Sie uns das kurz zerlegen: Der Termin selbst sollte nicht mit einer lockeren Ideensammlung starten, sondern mit klaren Leitplanken. Zielsetzung, Budgetrahmen und Erfolgskriterien gehören an den Anfang, damit jeder im Raum weiß, woran wir den Erfolg messen. Wenn die IT in Risiken denkt, während der Fachbereich nur den Nutzen sieht und die Geschäftsführung auf das Budget starrt, reden alle aneinander vorbei. Ohne diesen Rahmen diskutieren Sie am Ende drei verschiedene Projekte gleichzeitig, ohne es zu merken.

Der Fachbereich braucht keine abstrakten Wunschlisten, sondern muss konkrete Prozessfälle auf den Tisch legen. Fragen Sie gezielt: Welcher Vorgang dauert zu lange, wo passieren ständig Fehler und an welcher Stelle wird Arbeit doppelt gemacht? Mit solchen realen Schmerzpunkten können Sie arbeiten, während allgemeine Aussagen über „mehr Effizienz“ höchstens eine Powerpoint-Folie füllen. Effizienz ist kein Plan, sondern ein Ergebnis sauberer Architektur.

Parallel dazu müssen IT und Security sofort mit am Tisch sitzen und prüfen, statt erst zwei Wochen später ein Veto einzulegen. Während der Prozess beschrieben wird, klären die Experten im gleichen Zug, ob die Architektur passt und wie die Daten fließen sollen. Diese Gleichzeitigkeit macht den Unterschied zwischen einem Workshop, der Orientierung schafft, und einem, der nur kurzfristige Euphorie produziert. Das ist der Moment, in dem Sie die Spreu vom Weizen trennen.

Sortieren Sie die Use Cases spätestens jetzt in drei Kategorien ein. Erstens: Fälle, die sofort als Pilot starten können, weil Daten und Risiken klar sind. Zweitens: Projekte, die erst ein Vorprojekt brauchen, um etwa Schnittstellen zu schaffen oder Verantwortlichkeiten zu klären. Drittens: Fälle, die Sie aktuell komplett verwerfen. Das klingt hart, aber ein Workshop, der nichts aussortiert, hat am Ende des Tages nicht entschieden, sondern nur eine Liste geschrieben.

Für jeden Fall, den Sie priorisieren, müssen die gleichen Pflichtfragen gelten. Woher kommen die Daten, wer prüft die Ergebnisse fachlich und wer übernimmt den Betrieb, wenn es hakt? Das ist keine Kür, sondern die Basis für alles Weitere. Wenn Sie diese Fragen im Workshop ignorieren, landen sie später als dringende E-Mails unter Zeitdruck auf Ihrem Schreibtisch, was die Qualität massiv verschlechtert. Besser wird eine schlechte Planung durch Eile nämlich selten.

Am Ende des Tages brauchen Sie keine gute Stimmung, sondern eine verbindliche Entscheidungsliste. Für jeden relevanten Fall muss feststehen, ob er pilotiert wird, wer die Verantwortung trägt und wie der nächste Architekturschritt aussieht. Genau daran erkennen Sie die Substanz Ihres Termins. Wenn alle den Raum mit dem Gefühl verlassen, es war ein „netter Austausch“, aber niemand weiß, was nun konkret beschlossen wurde, dann haben Sie wertvolle Zeit verschwendet.

Falls Ihnen das bekannt vorkommt: Sie sind nicht allein, aber es ist lösbar. Viele Unternehmen behandeln solche Formate immer noch wie eine unverbindliche Ideenbörse. Echte Fortschritte machen Sie aber erst dann, wenn der Workshop nicht mehr dazu dient, Begeisterung zu heucheln, sondern Ihre Entscheidungsfähigkeit zu stärken. Das klingt vielleicht etwas trocken, aber genau diese Nüchternheit bewahrt Sie vor teuren Frankenstein-Integrationen und unnötiger Nacharbeit.

Fazit: Gute Workshops sammeln nicht nur Zustimmung, sie sortieren Risiko

Seien wir ehrlich: Ein guter KI-Workshop muss mehr leisten, als nur die Nutzer abzuholen. User-Feedback ist wichtig, darf aber niemals das letzte Wort haben, wenn es um die langfristige Stabilität geht. Eine wirklich tragfähige Entscheidung entsteht erst dann, wenn Sie Fachbereich, IT, Security und das Betriebsmodell an einen Tisch bringen. Nur wenn diese Perspektiven frühzeitig zusammenfließen, wird aus einer vagen Idee am Ende eine saubere Architektur.

Prüfen Sie Ihren nächsten Workshop deshalb vorab auf drei Punkte: Haben Sie die richtigen Rollen dabei, stimmt die Reihenfolge und wurden die unbequemen Day-2-Fragen gestellt? Klären Sie den Betrieb, bevor Sie überhaupt über ein konkretes Tool diskutieren. Sprechen Sie mit Ihrem Team, bevor Sie unterschreiben, und stellen Sie zuerst die harten Fragen, nicht die bequemen.

Das war IT for Business.

Wenn Sie aus dieser Folge eines mitnehmen, dann hoffentlich das: Gute IT entscheidet sich nicht im Tool-Katalog, sondern in der Architektur und den strategischen Weichenstellungen davor. Wenn Ihnen diese Einordnung geholfen hat, abonnieren Sie den Podcast, damit Sie keine weiteren Folgen zu IT-Entscheidungen aus der Praxis verpassen. Falls Sie selbst gerade vor einer Modernisierung stehen, denken Sie daran: Stellen Sie die kritischen Fragen früh, nicht erst im laufenden Betrieb.

Bis zur nächsten Folge.