Die 3-Schritt-Methode: So finden Sie KI-Potenziale, die sich wirklich rechnen

Willkommen bei IT for Business. Ich bin Mirko Peters.

Wir sind IT-Dienstleister für den Mittelstand. Hier geht es nicht um Marketing-Hype oder bunte Produkte, sondern um echte IT-Entscheidungen. Wir sprechen über Infrastruktur, Cloud, Security und Architektur direkt aus der Praxis. Wenn Sie Verantwortung für die IT tragen, Budgets freigeben oder Dienstleister bewerten müssen, sind Sie hier genau richtig. Vernetzen Sie sich für einen fachlichen Austausch auch gerne mit mir auf LinkedIn, ich freue mich immer über Impulse aus dem echten Geschäftsalltag.

Seien wir ehrlich: Die meisten Unternehmen starten bei KI am völlig falschen Ende. Man sieht eine beeindruckende Demo, testet kurz einen Assistenten und glaubt, das Projekt sei damit schon auf dem Weg. Genau hier fängt das Problem meistens an. Zu diesem Zeitpunkt sind Prozesse, Daten und Verantwortlichkeiten oft noch gar nicht sauber geklärt. Ein schneller Pilot wirkt auf den ersten Blick günstig, aber die Rechnung kommt später. Teuer wird es nämlich dann, wenn die Day-2-Operations anfangen, die Nacharbeiten explodieren und niemand mehr sagen kann, wer den Betrieb eigentlich verantwortet.

In dieser Folge gehen wir das Thema nüchtern an. Ich stelle Ihnen eine Drei-Schritt-Methode vor, die nicht auf Hochglanz-Folien gut aussieht, sondern im täglichen Betrieb tatsächlich tragen soll. Wir schauen uns die Prozess-Inventur an, machen den Architektur-Check und werfen einen Blick auf eine harte ROI-Rechnung. Dabei sprechen wir auch über das Thema Data Cleansing, das in vielen Gesprächen erst auftaucht, wenn das Budget bereits angekratzt ist. Erst wenn klar ist, wo die Arbeit in Ihrem Unternehmen wirklich hängen bleibt, lohnt sich der Blick auf KI überhaupt.

Abschnitt 1: Der Denkfehler vor jedem KI-Projekt, vom Tool zur Prozessfrage

Der typische Einstieg im Mittelstand folgt oft einem riskanten Muster. Jemand aus dem Fachbereich hat eine glatte Oberfläche in einer zwanzigminütigen Anbieter-Demo gesehen, woraufhin die Aufgabe mit der Bitte um eine kurze Prüfung bei der IT landet. Dieses „mal eben prüfen“ ist der direkte Einstieg in spätere Mehrkosten. Man unterstellt damit nämlich stillschweigend, dass das eigentliche Problem lediglich das fehlende Tool sei.

Klartext: KI ist kein Selbstzweck und auch kein isolierter Anwendungsfall. KI ist eine Betriebsform für klar umrissene Aufgaben. Sie ersetzt niemals die notwendige Vorarbeit, bei der Sie festlegen, was überhaupt entschieden, klassifiziert oder geprüft werden soll. Wenn eine Aufgabe fachlich unscharf bleibt, kann auch das teuerste Modell daraus keinen stabilen Prozess machen. Architektur schlägt hier jedes Tool, denn ohne Fundament bauen Sie nur ein digitales Kartenhaus.

Deshalb ist die richtige Reihenfolge entscheidend. Erst kommt die Augmentation, dann die Automatisierung. Das bedeutet, wir unterstützen zuerst die Mitarbeitenden bei klar begrenzten Tätigkeiten, bevor wir später ganze Abläufe automatisieren. Dieser Weg ist billiger, besser kontrollierbar und vor allem ehrlicher. Sie sehen so viel schneller, ob der fachliche Nutzen überhaupt existiert. Ein Assistent, der bei der Recherche oder bei Entwürfen hilft, ist oft ein sinnvoller Einstieg, während ein vollautomatischer Prozess ohne saubere Leitplanken meist nur eine ambitionierte PowerPoint-Fantasie bleibt.

Woran erkennen Sie nun sinnvolle Kandidaten für ein Projekt? Erstens brauchen wir eine hohe Wiederholung und zweitens klare Eingaben. Drittens müssen erkennbare Qualitätsregeln vorliegen und viertens muss der Aufwand messbar sein. Wenn ein Vorgang hundertmal im Monat ähnlich abläuft, lohnt sich der Blick auf eine technische Lösung. Wenn dagegen jeder Fall individuell aussieht und wesentliche Entscheidungen nur im Kopf einzelner Mitarbeiter fallen, wird es schwierig.

Genau da versteckt sich das Risiko. Prozesse mit Medienbrüchen, Excel-Listen und ewigem Mail-Pingpong eignen sich selten für einen schnellen Start. Nicht weil KI dort technisch unmöglich wäre, sondern weil Sie zuerst die operative Unordnung automatisieren würden. Diese Unordnung kommt Ihnen im Betrieb zuverlässig teuer zu stehen. Betrachten Sie es wie eine Haus-Renovierung, bei der jemand sofort den schicken Anbau plant, obwohl niemand weiß, wo die tragenden Wände verlaufen. Der Entwurf sieht gut aus, aber später reißen Sie alles wieder auf, weil die Grundlage gefehlt hat. Die Suche nach KI-Potenzialen beginnt daher nicht mit einer Wunschliste, sondern mit einer nüchternen Inventur Ihrer tatsächlichen Arbeit.

Abschnitt 2: Schritt 1, Prozess-Inventur, wo KI im Betrieb überhaupt angreifen darf

Wenn Sie belastbare KI-Anwendungsfälle finden wollen, starten Sie nicht mit einem Workshop voller Post-its und Fantasiebegriffe. Nehmen Sie stattdessen Ihre Prozesslandkarte zur Hand und schauen Sie gezielt auf die Bereiche, in denen Tag für Tag viel manuelle Arbeit durch das Unternehmen läuft. Interessant sind hier vor allem die Stellen, an denen sich Zeitverluste über die Wochen tatsächlich aufsummieren.

Oft sind es nicht die lautesten Wünsche aus den Abteilungen, sondern die stillen Fresser von Kapazität, die den größten Hebel bieten. Klassisches Copy-Paste zwischen verschiedenen Systemen gehört ebenso dazu wie die ständige Dokumentensuche oder das händische Vorsortieren von Tickets. Auch das Klassifizieren von Posteingängen, das Erstellen von Zusammenfassungen oder das Prüfen von Daten gegen bekannte Regeln sind typische Muster, die heute oft noch mühsam zwischen Mail, DMS, ERP und Excel pendeln. Solche Abläufe finden Sie fast überall, nur spricht selten jemand offen darüber, weil viele Teams ihre Behelfslösungen längst für normal halten.

Was bedeutet das konkret für Sie? Gehen Sie pro Prozess vier nüchterne Fragen durch, um die Spreu vom Weizen zu trennen. Erstens: Wie oft passiert das eigentlich? Zweitens: Wie standardisiert läuft es wirklich ab? Drittens: Welche Daten werden dafür gebraucht und liegen diese Informationen verlässlich vor? Viertens: Was passiert, wenn das Ergebnis einmal falsch ist? Diese vier Fragen bringen Ihnen mehr Klarheit als jede bunte Tool-Demo, weil Sie damit sofort zwischen technischer Spielerei und einem echten Betriebshebel unterscheiden können.

Dabei reicht es nicht aus, nur die reine Bearbeitungszeit zu erfassen, sondern Sie müssen auch die Liegezeiten und den Aufwand für Nacharbeit oder Eskalationen messen. In vielen mittelständischen Unternehmen steckt der eigentliche Schaden nicht in der Dateneingabe selbst, sondern in der Wartezeit davor und in der Korrektur danach. Genau dort sitzt oft das größte Potenzial, was zwar wenig spektakulär klingt, aber wirtschaftlich den entscheidenden Unterschied macht.

Seien wir ehrlich: Ein Prozess kann extrem lästig sein, ohne deshalb wirtschaftlich interessant zu sein. Wenn sich drei Kollegen über ein nerviges Formular ärgern, ist das noch lange kein Business Case für ein KI-Projekt. Wenn aber jeden Monat hunderte Vorgänge durchlaufen, wichtige Entscheidungen hängen bleiben und Fachkräfte ihre Zeit mit Sortieren statt mit Prüfen verbringen, dann haben wir einen Kandidaten, den man ernst nehmen sollte.

Nach der Erfassung folgt die Einordnung, wobei ich die Kandidaten grob in drei Gruppen unterteilen würde. Die erste Gruppe ist Low Risk, also Vorgänge mit wenig Personenbezug und überschaubarem Schaden bei Fehlern. Danach kommt die mittlere Komplexität, bei der eine Fachprüfung zwingend erforderlich ist, weil Ergebnisse zwar vorbereitet, aber niemals blind übernommen werden dürfen. Die dritte Gruppe ist das Hochrisiko, was regulierte oder sicherheitskritische Abläufe betrifft, bei denen Fehler sofort rechtliche oder operative Folgen haben.

Für den Einstieg im Mittelstand tauchen immer wieder ähnliche Felder auf, wie etwa die Rechnungsverarbeitung, da hier Volumen und Prüfregeln meist gut bekannt sind. Dazu kommen die Ticket-Vorsortierung, die interne Wissenssuche oder automatisierte Angebotsentwürfe. Solche Fälle sind deshalb so attraktiv, weil sie häufig genug vorkommen und sich der Aufwand vor und nach der Optimierung sehr präzise messen lässt.

Andere Themen sollten Sie dagegen bewusst nach hinten schieben. Strategische Entscheidungen oder das HR-Scoring sind viel zu heikel für die erste Welle. Auch unstrukturierte Sonderfreigaben enden meist in einem Sumpf aus Ausnahmen, die eine KI kaum sinnvoll abbilden kann. Da wird es riskant, sowohl fachlich als auch regulatorisch, weshalb sicherheitskritische Freigaben kein Feld für einen schnellen Einstieg sind.

Das Ziel dieser Inventur ist es nicht, eine endlose Wunschliste zu produzieren. Am Ende benötigen Sie eine priorisierte Shortlist mit vielleicht fünf bis zehn Fällen, die sich vernünftig vergleichen und bewerten lassen. Fünf gut beschriebene Kandidaten schlagen fünfzig lose Ideen aus einem Innovationsworkshop jederzeit. Sobald diese Liste steht, kommen wir zu dem Teil, über den Anbieter im Verkaufsgespräch ungern sprechen: die Architektur.

Abschnitt 3: Schritt 2, Architektur-Check, ob der Use Case tragfähig und betreibbar ist

Jetzt kommen wir an den Punkt, an dem viele KI-Vorhaben leise aus dem Ruder laufen. Das passiert meistens nicht im Prompt oder im Modell selbst, sondern im technischen Unterbau. Hier ist die eigentliche Frage: Wo liegen Ihre Daten, wer darf darauf zugreifen und wie kommt ein KI-System kontrolliert an diese Informationen heran, ohne dass Sie sich neue Risiken einkaufen?

Dafür brauchen Sie zuerst eine ehrliche Bestandsaufnahme Ihrer Quellen, also nicht nur das ERP-System, wie es auf dem Papier steht. Schauen Sie, wo die Informationen wirklich stecken, ob im DMS, auf Fileshares, in Postfächern oder in alten Fachanwendungen. Und dann folgt die unbequeme Anschlussfrage, ob es dafür belastbare Schnittstellen gibt oder ob der Prozess heute nur durch manuelle Exporte und Anhänge am Leben gehalten wird.

Ein Use Case wirkt oft plausibel, solange man nur auf die Oberfläche schaut. Im echten Betrieb zeigt sich dann häufig, dass die relevanten Daten zwar da, aber völlig verteilt oder nur mit technischen Tricks erreichbar sind. Genau dann kippt ein gut gedachter Anwendungsfall in mühsame Handarbeit mit neuer Verpackung um. Ohne vernünftige APIs und klare Datenflüsse wird aus der geplanten Automatisierung nur eine zusätzliche Schicht, die später niemand mehr warten kann oder will.

Schauen Sie deshalb nicht nur auf die reine Verfügbarkeit, sondern vor allem auf die Datenqualität. Vollständigkeit ist dabei nur der Anfang, denn Korrektheit und Aktualität folgen sofort dahinter. Dazu kommen Dubletten oder widersprüchliche Stammdaten, die das System verwirren können. Was nützt Ihnen der intelligenteste Assistent, wenn die Hälfte der Infos in unstrukturierten PDFs steckt und die Berechtigungen im Unternehmen über Jahre historisch gewachsen sind?

Klartext zu Legacy-Systemen: Wenn Ihre Kernanwendung keine saubere Anbindung zulässt, müssen Sie sehr genau rechnen. Sonst bauen Sie lediglich eine schöne Fassade vor einen Prozess, der intern weiter durch händische Nachpflege am Tropf hängt. Das sieht in einer Demo zwar modern aus, produziert im Alltag aber genau die Frankenstein-Integrationen, die Ihre IT-Abteilung später vor unlösbare Probleme stellen.

Auch die Betriebsform ist keine reine Glaubensfrage zwischen Cloud und On-Premise. Sie müssen hier nüchtern auf die Datenklasse, das Lastprofil und den Integrationsaufwand schauen. Wenn Sie stark schwankende Lasten haben, kann die Cloud sinnvoll sein, während sensible Daten oder enge regulatorische Vorgaben oft für eine Private Cloud sprechen. Entscheidend ist am Ende nicht, was gerade modern klingt, sondern was sich technisch und rechtlich dauerhaft tragen lässt.

Damit sind wir beim Thema Datenschutz. Prüfen Sie für jeden Anwendungsfall die Rechtsgrundlage und klären Sie vorab, ob der Anbieter Ihre Daten für eigene Trainingszwecke nutzt. Das ist keine juristische Dekoration, sondern gehört direkt in die Architekturentscheidung, weil sich daraus die technischen Vorgaben für die Speicherung ergeben. Ein Löschkonzept und ein sauberes Rollenmodell müssen von Anfang an Teil der Planung sein.

Aus Sicht der IT-Sicherheit, etwa mit Blick auf NIS2, wird die Sache noch etwas ernster. Ein KI-System ist kein nettes Spielzeug, sondern ein eigenes Risikoobjekt in Ihrer Infrastruktur. Sie müssen die Lieferkette und die Abhängigkeiten genau prüfen, um bei Vorfällen reaktionsfähig zu bleiben. Überlegen Sie mal, was passiert, wenn ein kritischer Ablauf plötzlich stillsteht, weil ein externer Dienst nicht verfügbar ist. Wenn Sie darauf keine Antwort haben, ist der Use Case schlicht noch nicht betriebsreif.

Ein weiterer Punkt, der oft unterschätzt wird, ist die sogenannte Schatten-KI. In vielen Unternehmen nutzen Mitarbeiter längst informell verschiedene Browser-Tools, was aber noch lange keine geordnete Governance darstellt. Ein freigeschaltetes Tool ersetzt weder eine klare Datenklassifikation noch technische Leitplanken. Wenn Ihr Dienstleister an dieser Stelle abwinkt und behauptet, das sei alles schnell erledigt, sollten Sie lieber zweimal hinschauen.

Bei kritischen Prozessen benötigen Sie zudem immer einen „Human-in-the-loop“. Das bedeutet nicht, dass ein Mensch am Ende nur noch pro forma einen Knopf drückt, sondern dass Ausnahmen und die Qualitätskontrolle bewusst in menschlicher Hand bleiben. Die KI bereitet vor und sortiert vor, aber der Mensch übernimmt dort, wo Kontext und echte Verantwortung nicht automatisierbar sind.

Am Ende dieses Architektur-Checks sollten Sie für jeden Anwendungsfall eine einfache Ampel vergeben. Grün bedeutet, dass Zugriff, Rechte und Betriebsmodell beherrschbar sind. Gelb zeigt an, dass Sie bei den Schnittstellen oder der Datenqualität noch Hausaufgaben machen müssen. Rot heißt schlicht, dass das Risiko aktuell zu groß ist. Erst wenn dieses Fundament stabil steht, können wir die Frage stellen, die für die Geschäftsführung am Ende wirklich zählt: Rechnet sich das Ganze überhaupt?

Abschnitt 4: Schritt 3, harte ROI-Rechnung statt Bauchgefühl und Demo-Effekt

An diesem Punkt trennt sich die Spreu vom Weizen. Hier entscheidet sich, ob wir über eine ernsthafte Investition sprechen oder nur über Technikbegeisterung. Sobald ein Use Case fachlich sinnvoll wirkt und die Architektur nicht beim ersten Hinsehen auseinanderfällt, kommt die Frage, die im Mittelstand niemand lange vertagen kann. Was bringt das Projekt konkret, was kostet es wirklich und wann sehen wir davon etwas auf dem Konto oder zumindest bei den freien Kapazitäten?

Seien wir ehrlich: Genau hier wird oft unsauber gerechnet. Viele Business Cases starten mit diesen typischen, vagen Produktivitätsversprechen wie zehn Prozent schneller oder zwanzig Prozent effizienter. Das klingt auf einer Folie ordentlich, hilft Ihnen bei der Freigabe durch die Geschäftsführung aber wenig. Rechnen Sie stattdessen lieber pro Prozessschritt und pro Rolle. Schauen Sie sich genau an, wer heute was wie lange macht, wie oft das vorkommt und wie hoch die Fehlerquote ist. Erst wenn Sie definieren, was sich davon realistisch durch KI verändert, entsteht eine Zahl, mit der man arbeiten kann.

Der direkte Nutzen liegt meist in ein paar greifbaren Blöcken, wobei die Zeiteinsparung nur der offensichtlichste Teil ist. Dazu kommen geringere Fehlerquoten, kürzere Durchlaufzeiten und die Fähigkeit, Volumen sauberer zu skalieren, ohne sofort neues Personal einstellen zu müssen. Wenn Sie diese Effekte nicht getrennt ausweisen, vermischen Sie die Argumente und verlieren an Glaubwürdigkeit. Die Geschäftsführung will wissen, welcher Teil wirklich Geld spart, wo das Risiko sinkt und wo das Team einfach nur entlastet wird.

Auf der Kostenseite beginnt dann die unangenehme Arbeit, denn es reicht nicht, nur die Lizenzkosten anzusetzen. Kopieren Sie nicht einfach das Angebot des Anbieters in eine Tabelle, sondern legen Sie die verdeckten Aufwände offen auf den Tisch. Denken Sie an die Datenbereinigung, die Schnittstellen, die Fachtests und den späteren Betrieb inklusive Monitoring. Gerade die Nachsteuerung wird gern unterschlagen, obwohl sie im Alltag fast immer nötig ist. Ein Modell läuft nicht einfach los und bleibt über Monate stabil, wenn sich Dokumente, Eingaben oder Regeln im Unternehmen ändern.

Das Thema Data Cleansing ist dabei regelmäßig die größte Kostenfalle. Das liegt meist nicht daran, dass jemand schlecht gearbeitet hätte, sondern daran, dass Stammdaten und Formate über Jahre wild gewachsen sind. Historisch gewachsen heißt im Klartext: Niemand wollte das Thema bezahlen, solange der Betrieb irgendwie lief. Sobald KI ins Spiel kommt, fällt diese Rechnung plötzlich auf den Tisch. Dann merken Sie, dass Lieferanten unterschiedlich benannt sind oder fachlich gleiche Informationen in drei Systemen anders aussehen. Wenn Sie diesen Block kleinrechnen, bauen Sie Ihren Business Case auf Sand.

Deshalb reicht der Blick auf die Einmalkosten bei weitem nicht aus. Sie brauchen die TCO, also die Gesamtkosten über die gesamte Laufzeit. Dazu gehören Lizenzen, der API-Verbrauch, der Support und der interne Aufwand für das Change Management. Auch kleine, nutzungsbasierte Kosten können im Volumen gefährlich kippen, wenn ein Prozess später breiter ausgerollt wird oder die Anwender das System intensiver nutzen als geplant. Solche Effekte sieht man in der Demo nie, im Monatsreport nach sechs Monaten aber sehr wohl.

Für die Bewertung empfehle ich Ihnen, immer mit drei Szenarien zu arbeiten: vorsichtig, realistisch und optimistisch. Das dient nicht dazu, künstlich Spannung zu erzeugen, sondern bildet die Unsicherheit sauber ab. Im vorsichtigen Szenario kalkulieren Sie mit höherem Aufwand und langsamerem Qualitätsgewinn, während Sie im optimistischen Szenario Skaleneffekte einplanen dürfen. Eine Punktlandung vorzutäuschen, wirkt in der IT-Strategie selten seriös.

Ebenso wichtig ist der Break-even, der nicht nur als vage Hoffnung am Ende einer Präsentation stehen darf. Definieren Sie vor dem Pilotprojekt, ab wann sich der Einsatz trägt und woran Sie das konkret messen. Legen Sie außerdem klare Abbruchkriterien fest. Wenn die Qualität oder der Integrationsaufwand die gesetzten Grenzen reißen, muss das Projekt gestoppt oder neu geschnitten werden. Sonst wird aus einem Pilotversuch ein Prestigevorhaben, das niemand mehr beenden will, obwohl es nur Geld verbrennt.

Ein guter Referenzrahmen für solche Rechnungen ist oft die Rechnungsverarbeitung. Hier sind Volumen, Felder und Liegezeiten meist halbwegs messbar, sodass Sie prüfen können, wie stark die Erfassung und Prüfung wirklich entlastet werden. Man sieht dort schnell, wie viele Klärfälle übrig bleiben und welche Fehlerkosten im alten Prozess steckten. Genau deshalb ist dieser Bereich ein vernünftiger Ausgangspunkt, da sich die Wirkung hier eher belegen lässt als bei rein strategischen Aufgaben.

Nur auf die reine Einsparung zu schauen, wäre trotzdem zu kurz gesprungen. Die Auditierbarkeit und das geringere Betriebsrisiko haben ebenfalls einen hohen Wert für das Unternehmen. Wichtig ist nur, dass Sie diese Punkte getrennt ausweisen und nicht in eine diffuse Gesamtrendite werfen. Sonst wird aus einer belastbaren Kalkulation wieder reine Folienlogik. Wenn Sie das sauber aufbauen, haben Sie am Ende keinen KI-Traum, sondern eine Investitionsvorlage mit prüfbaren Annahmen.

Abschnitt 5: Pilot sauber aufsetzen, damit aus einem PoC kein teures Missverständnis wird

Wenn der Use Case sinnvoll ist und die Rechnung stimmt, beginnt die eigentliche Bewährungsprobe in Form des Piloten. Hier machen viele Unternehmen den Fehler, dass sie entweder zu groß oder zu künstlich starten. Ein Pilot muss klein sein, aber operativ echt. Verzichten Sie auf Laborsetups mit Musterdaten und geschönten Bedingungen. Sie brauchen einen begrenzten Live-Prozess mit echten Daten und klaren Grenzen, der sich im harten Alltag beweisen muss.

Setzen Sie sich dafür ein nüchternes Zielbild für einen Zeitraum von acht bis zwölf Wochen. Ein Prozess, ein Verantwortlicher und definierte Datenquellen reichen am Anfang völlig aus. Sobald Sie versuchen, mehrere Prozesse gleichzeitig zu testen, verschwimmen Ursache und Wirkung. Dann weiß am Ende niemand mehr, ob das Problem im Modell, in den Berechtigungen oder schlicht in der Organisation lag. Lassen Sie uns das Rauschen ausblenden und uns auf das Wesentliche konzentrieren.

Legen Sie die Messgrößen unbedingt vor dem Start fest und nicht erst nach vier Wochen, wenn die ersten Diskussionen aufkommen. Die Bearbeitungszeit und die First-pass-Quote sind hier entscheidend. Es geht um die Frage, wie viele Fälle ohne manuelle Nacharbeit durchlaufen. Achten Sie auch auf die Nutzerakzeptanz, denn wenn der Fachbereich das System nicht ernst nimmt oder heimlich Umgehungswege baut, haben Sie keinen Pilot, sondern eine teure Pflichtübung.

Ebenso kritisch ist das Thema Fallback. Wenn die Qualität kippt oder ein Anbieter ausfällt, muss der Prozess kontrolliert weiterlaufen können. Das ist kein Luxus, sondern IT-Grundhygiene. Wer einen Live-Prozess auf ein neues KI-System setzt, ohne den Rückweg definiert zu haben, testet nicht seine Innovationskraft, sondern lediglich seine Leidensfähigkeit. Architektur schlägt Tools, und das gilt besonders für den Notfallplan.

Den Exit sollten Sie genauso klar definieren wie den Erfolg. Unter welchen Bedingungen wird das Projekt beendet oder neu zugeschnitten? Wenn diese Entscheidung offenbleibt, entstehen diese typischen Zwischenzustände, die man aus vielen Unternehmen kennt. Technisch nie ganz fertig und fachlich nie ganz verworfen, belasten sie monatlich die Kostenstelle. Solche Projekte sterben selten einen schnellen Tod, sie ziehen sich einfach ewig hin.

In der Praxis scheitern Piloten übrigens oft nicht an der Technik, sondern an den Übergaben zwischen den Abteilungen. Der Fachbereich will Entlastung, die IT achtet auf den Betrieb und der Datenschutz prüft die Rechtsgrundlage. Wenn diese Gruppen nacheinander statt gemeinsam arbeiten, verlieren Sie wertvolle Wochen durch Reibungsverluste. Setzen Sie Fachbereich, IT und Security von Anfang an an einen Tisch, auch wenn das den Start etwas mühsamer macht.

Lassen Sie außerdem jede Regel und jede Korrektur sauber dokumentieren. Sonst lernt am Ende nur das Projektteam, aber nicht die gesamte Organisation. Das rächt sich spätestens beim Rollout, wenn das Wissen bei Urlaub oder Personalwechsel plötzlich weg ist. Wenn nur zwei Personen wissen, warum bestimmte Fälle manuell geprüft wurden, beginnt die nächste Runde der Improvisation.

Ein guter Pilot beweist nicht nur, dass eine Technik irgendwie funktioniert. Er zeigt vor allem, dass ein Prozess wartbar ist und die Zuständigkeiten klar verteilt sind. Er beweist, dass die Qualität geprüft werden kann und das Team nicht in Panik gerät, wenn der Idealfall einmal ausbleibt. Erst wenn diese Stabilität erreicht ist, sollten Sie über eine Skalierung sprechen. Vorher ist das Risiko schlicht zu hoch.

Wenn Sie bis hierhin sauber arbeiten, verliert das Thema KI viel von seinem Nebel. Dann ist es keine Bühne mehr für nette Demos, sondern eine normale, tragfähige Investitionsentscheidung. Es geht dann um Technik, Risiko und operative Verantwortung. Klartext: Die echten Kosten und Risiken zeigen sich erst hier, aber sie werden dadurch auch beherrschbar.

Fazit: Was Sie jetzt konkret mit Ihrem Team tun sollten

Das war IT for Business für heute.

Wenn Sie aus diesem Gespräch einen Gedanken mitnehmen, dann hoffentlich diesen: Gute KI-Projekte fangen niemals beim Tool an. Sie starten beim Prozess, der Architektur und einer wirklich belastbaren Rechnung. Alles andere ist nur teures Experimentieren ohne Fundament.

Gehen Sie morgen in Ihr Team und besprechen Sie drei ganz praktische Schritte. Suchen Sie sich zuerst drei Abläufe heraus, bei denen heute offensichtlich zu viel manuelle Arbeit liegen bleibt. Bauen Sie für diese Fälle eine einfache Architektur-Ampel auf und prüfen Sie Datenquellen, Risiken sowie die spätere Betriebsfähigkeit. Rechnen Sie dann für einen dieser Prozesse einen Business Case durch, aber bitte im vorsichtigen Szenario und nicht im optimistischen Wunschbild der Anbieter.

Sobald der nächste KI-Vorschlag auf Ihrem Tisch landet, sollten Sie sofort vier Punkte abfragen. Klären Sie, woher die Daten kommen, wie hoch das Risiko liegt, wer das System im Alltag betreibt und wie viel manuelle Nacharbeit am Ende wirklich übrig bleibt. Genau an dieser Stelle versteckt sich nämlich die eigentliche Entscheidung.

Falls Ihnen diese Folge weitergeholfen hat, abonnieren Sie den Podcast. So verpassen Sie keine weiteren Einordnungen zu IT-Entscheidungen direkt aus der Praxis. Wenn Sie selbst gerade vor einer Modernisierung stehen, stellen Sie die harten Fragen lieber frühzeitig und nicht erst, wenn das Kind im Betrieb schon in den Brunnen gefallen ist.

Wir hören uns in der nächsten Folge.