KI im Unternehmen einführen: Schritt für Schritt

Ein Team testet bereits einen KI-Textdienst, ein Softwareanbieter schaltet eine neue Assistenzfunktion frei und die Geschäftsführung möchte noch im laufenden Quartal einen eigenen KI-Anwendungsfall sehen. Was fehlt, ist eine gemeinsame Entscheidung: Welche Daten dürfen verarbeitet werden, welcher Prozess soll sich verbessern, wer prüft Ergebnisse und was geschieht, wenn die Funktion falsch liegt? Wer KI im Unternehmen einführen will, muss diese Fragen vor dem produktiven Einsatz beantworten.

Eine tragfähige Einführung besteht nicht aus einem einzigen Großprojekt. Sie führt einen abgegrenzten Anwendungsfall durch klare Entscheidungspunkte: Problem bestätigen, Ist-Ablauf messen, Daten und Risiken prüfen, Lösung auswählen, mit realen Fällen testen, kontrolliert integrieren und erst danach skalieren. Jeder Schritt erzeugt ein konkretes Ergebnis, auf dessen Grundlage das Unternehmen fortfahren, nachbessern oder stoppen kann.

SW Business Solutions begleitet diese Einführung von der Prozessanalyse bis zum laufenden System. Dabei kann vorhandene Standardsoftware erweitert, ein externer KI-Dienst angebunden oder eine individuelle Anwendung entwickelt werden. Entscheidend ist, dass KI nicht als isoliertes Werkzeug neben den Fachsystemen steht, sondern in einen nachvollziehbaren betrieblichen Ablauf eingebettet wird.

Schritt 1: Einen konkreten betrieblichen Engpass beschreiben

Der Einstieg beginnt nicht mit einem Modellnamen, sondern mit einer wiederkehrenden Arbeitssituation. Ein Kundenservice verteilt eingehende Nachrichten manuell. Die Buchhaltung überträgt Rechnungsdaten in das ERP. Techniker durchsuchen mehrere Ordner nach der passenden Arbeitsanweisung. Der Vertrieb erstellt ähnliche Angebotsbausteine immer wieder neu. Solche Situationen sind genauer als die allgemeine Forderung, „mit KI effizienter zu werden“.

Für den ausgewählten Vorgang werden Start und Ende festgelegt. Wo kommt eine Information an? Welche Arbeitsschritte folgen? Welches Ergebnis gilt als abgeschlossen? Wer übernimmt heute welche Entscheidung? Welche Ausnahmefälle treten auf? Eine Prozessskizze mit echten Beispielen genügt zunächst. Sie verhindert, dass das Projekt nur den sichtbaren Einzelschritt optimiert und danach an einer manuellen Übergabe hängen bleibt.

Das Ergebnis dieses Schritts ist eine kurze Problembeschreibung. Sie enthält Nutzergruppe, Häufigkeit, heutige Bearbeitung, erkennbare Fehler und die gewünschte Verbesserung. „Kundenanfragen schneller beantworten“ wird beispielsweise zu: „Eingehende Service-E-Mails sollen mit Kundenzuordnung, Anliegen und Dringlichkeit als prüfbarer Vorgang im Ticketsystem erscheinen.“

Schritt 2: Den Ausgangszustand mit betriebseigenen Werten erfassen

Ohne Ausgangsmessung lässt sich später kaum beurteilen, ob die KI entlastet. Für den ausgewählten Ablauf werden deshalb reale Vorgänge betrachtet. Relevant können Bearbeitungszeit, Liegezeit, Rückfragen, Korrekturen, nicht zuordenbare Fälle oder verspätete Übergaben sein. Die Kennzahl richtet sich nach dem Engpass.

Eine Messung muss nicht monatelang dauern. Sie sollte aber Standard- und Ausnahmefälle enthalten. Wenn Rechnungen mit einer bekannten Vorlage schnell erfasst werden, fremdsprachige Gutschriften jedoch viel Nacharbeit erzeugen, darf ein Durchschnitt beide Gruppen nicht verdecken. Für die spätere Abnahme werden solche Fallklassen getrennt dokumentiert.

Auch qualitative Probleme gehören dazu. Mitarbeiter können beschreiben, an welcher Stelle Informationen fehlen, welche Entscheidung Erfahrungswissen benötigt oder welche Eingabe regelmäßig falsch verstanden wird. Daraus entstehen konkrete Testfälle und Anforderungen an die Benutzeroberfläche.

Am Ende stehen Ausgangswerte und ein Zielkorridor. Eine erfundene branchenübliche Einsparquote hilft nicht. Das Unternehmen legt fest, welche messbare Veränderung den Pilot rechtfertigt und welche Verschlechterung nicht akzeptabel wäre.

Schritt 3: Bereits genutzte KI und vorhandene Verträge erfassen

Viele Unternehmen beginnen nicht bei null. Mitarbeiter verwenden öffentliche KI-Dienste, Softwareprodukte enthalten generative Funktionen und einzelne Abteilungen haben eigene Testzugänge. Vor einem neuen Projekt wird deshalb ein einfaches KI-Inventar erstellt.

Für jede bekannte Anwendung werden Zweck, Nutzer, Anbieter, verarbeitete Daten, angebundene Systeme, Vertrag und verantwortliche Person notiert. Dabei zeigt sich häufig, dass dieselbe Funktion mehrfach beschafft oder ohne geregelte Datenfreigabe genutzt wird. Diese Bestandsaufnahme dient nicht dazu, jeden Versuch zu verbieten. Sie schafft eine Grundlage für gemeinsame Regeln und verhindert parallele Insellösungen.

Ein neuer Anwendungsfall wird ebenfalls in dieses Inventar aufgenommen. Dadurch bleiben Modell, Schnittstellen, Datenarten, Freigaben und Ausweichweg auch nach dem Projekt nachvollziehbar. Änderungen an Anbieter oder Funktionsumfang lassen sich später dem richtigen Prozess zuordnen.

Schritt 4: Prüfen, ob KI überhaupt die passende Technik ist

Nicht jeder digitale Engpass benötigt KI. Eine feste Wenn-dann-Regel, eine Datenbankabfrage oder ein normaler Workflow ist oft zuverlässiger und günstiger. KI wird interessant, wenn unstrukturierte Sprache, Dokumente, Bilder oder komplexe Muster verarbeitet werden müssen und eine vollständig deterministische Regel nicht ausreicht.

Der Anwendungsfall wird deshalb in Teilaufgaben zerlegt. Bei einer Kundenanfrage kann KI das Anliegen klassifizieren und einen Antwortentwurf erstellen. Die Kundennummer wird über eine eindeutige Zuordnung ermittelt. Vertragsstatus und Preise kommen aus dem CRM oder ERP. Der Versand benötigt gegebenenfalls eine Freigabe. Nur die unscharfen Aufgaben werden der KI übertragen.

Der praktische Leitfaden zu KI im Mittelstand erläutert Technologien, Beschaffungswege und Betriebsmodelle im Zusammenhang. Für die konkrete Entscheidung bietet der Go-/No-Go-Check für KI-Prozesse ein Raster aus Datenlage, Fehlerfolgen, Prüfbarkeit und Integration.

Das Ergebnis ist eine klare Aufgabenverteilung zwischen KI, normaler Softwarelogik und Mensch. Diese Grenze wird später nicht nur in einem Konzept beschrieben, sondern technisch durch Rechte und Freigaben umgesetzt.

Schritt 5: Den Anwendungsfall priorisieren und begrenzen

Ein erster Pilot sollte relevant genug sein, um echten Nutzen zu zeigen, aber klein genug, um Fehler zu verstehen. Geeignet ist häufig ein wiederkehrender Vorgang mit klarer Eingabe, prüfbarer Ausgabe und einem Mitarbeiter, der das Ergebnis bereits heute kontrolliert.

Der Umfang wird ausdrücklich begrenzt. Eine Dokumentenverarbeitung kann zunächst nur eine Rechnungsart eines Lieferantenkreises erfassen. Eine Wissenssuche startet mit freigegebenen Anleitungen einer Produktgruppe. Ein Kundenservice-Assistent bereitet Antworten für zwei häufige Anliegen vor, versendet sie aber nicht selbst.

Zur Begrenzung gehören Ausschlüsse. Handschriftliche Dokumente, bestimmte Vertragsfälle, fremde Sprachen oder sicherheitskritische Anfragen können zunächst in den bisherigen Prozess gehen. Diese Grenzen erscheinen in der Benutzeroberfläche und in der Betriebsdokumentation. Sie dürfen nicht nur dem Projektteam bekannt sein.

Das Ergebnis dieses Schritts ist ein Anwendungsfall-Steckbrief mit Ziel, Nutzergruppe, Ein- und Ausgabe, Quellen, ausgeschlossenen Fällen, verantwortlicher Rolle und gewünschter Prozesswirkung.

Schritt 6: Datenquellen, Qualität und Berechtigungen klären

Nun wird für jedes benötigte Datum bestimmt, aus welchem System es stammt und wer es sehen darf. Kundendaten können im CRM liegen, Vertragsinformationen im Dokumentenmanagement, Artikel und Preise im ERP. Eine KI-Anwendung benötigt nicht automatisch Zugriff auf den gesamten Bestand.

Die fachliche Bedeutung der Felder wird geprüft. Stimmen Kunden- und Vorgangskennungen überein? Was bedeutet ein Status in jedem System? Welche Dokumentversion ist gültig? Wie werden Korrekturen und Löschungen übernommen? Bei Freitexten ist zu klären, ob sie bestätigtes Wissen oder bloße Arbeitsnotizen enthalten.

Die Datenbasis für KI im Unternehmen muss für den Pilot nicht vollständig bereinigt sein. Bekannte Lücken müssen aber sichtbar sein und dürfen nicht durch Schätzungen des Modells verdeckt werden. Ein fehlender Vertragsstatus führt dann zu einer Rückfrage oder manuellen Prüfung, nicht zu einer erfundenen Annahme.

Berechtigungen greifen bereits beim Abruf. Ein Mitarbeiter darf über die KI keine Dokumente finden, die er im Quellsystem nicht öffnen könnte. Technische Konten erhalten nur die Rechte, die der Anwendungsfall benötigt. Schreibrechte werden getrennt von Leserechten vergeben.

Schritt 7: Datenschutz, Sicherheit und regulatorische Rolle einordnen

Vor dem technischen Pilot wird festgehalten, welche personenbezogenen, vertraulichen oder geschäftskritischen Daten verarbeitet werden. Zweck, Rechtsgrundlage, Datenminimierung, Empfänger, Speicherort, Löschung und mögliche Auftragsverarbeitung sind zu prüfen. Bei Beschäftigtendaten oder Leistungsbezug können zusätzliche arbeitsrechtliche und mitbestimmungsbezogene Fragen entstehen.

Informationssicherheit betrachtet weitere Risiken. Können Eingaben vertrauliche Informationen an einen ungeeigneten Dienst übertragen? Darf Inhalt aus einer E-Mail Werkzeugaktionen auslösen? Wie werden Zugangsschlüssel gespeichert? Welche Protokolle entstehen? Was passiert bei einem Ausfall oder einer Kompromittierung des Anbieters?

Die EU-KI-Verordnung unterscheidet Rollen, Einsatzzwecke und Risikokategorien. Welche Pflichten gelten, muss für das konkrete System geprüft werden. Außerdem benötigt das beteiligte Personal eine zum Einsatz passende KI-Kompetenz. Eine allgemeine Schulungsfolie ersetzt keine Einweisung in Datenregeln, Fehlergrenzen und Freigaben des tatsächlichen Prozesses.

Das Ergebnis ist keine pauschale Freigabe „für KI“. Es ist eine dokumentierte Entscheidung für den beschriebenen Anwendungsfall, seine Daten, Nutzer und Grenzen. Bei rechtlich oder fachlich anspruchsvollen Fällen werden entsprechende Fachstellen einbezogen.

Schritt 8: Standardprodukt, Integration oder Eigenentwicklung auswählen

Erst jetzt werden Produkte und technische Wege verglichen. Eine bereits in der Fachsoftware enthaltene KI-Funktion kann geeignet sein, wenn Daten, Rechte und Arbeitsablauf dort bleiben. Ein separates Standardwerkzeug ist schnell verfügbar, erzeugt aber möglicherweise manuelle Kopierwege. Eine API-Integration bringt die KI-Funktion in eine vorhandene Anwendung. Eine individuelle Lösung verbindet Modelle, Fachlogik und Oberfläche für den konkreten Prozess.

Für den Vergleich werden nicht nur Funktionslisten betrachtet. Entscheidend sind unterstützte Datenquellen, Berechtigungen, Export, Protokollierung, Modell- und Anbieterwechsel, Verfügbarkeit, Kostenmodell und Betrieb. Ein überzeugender Testchat sagt wenig darüber aus, ob das Produkt einen Vorgang im ERP sicher aktualisieren kann.

Der Artikel zum Vergleich von fertigem KI-Tool und eigener KI-Lösung vertieft diese Entscheidung. SW Business Solutions kombiniert bei Bedarf Standardkomponenten mit individueller KI-Integration, statt unnötig eine komplette Plattform neu zu entwickeln.

Das Ergebnis ist eine Architekturentscheidung mit bekannten Abhängigkeiten. Dazu gehört auch, welche Teile austauschbar bleiben und welche Funktionen dauerhaft an einen Anbieter gebunden wären.

Schritt 9: Testfälle und Abnahmekriterien vor der Umsetzung festlegen

Ein Pilot benötigt einen Testbestand, bevor die erste produktionsnahe Version entsteht. Die Fälle kommen aus dem realen Prozess und enthalten häufige Vorgänge, seltene Ausnahmen, unvollständige Eingaben, widersprüchliche Daten und absichtlich ungeeignete Anfragen.

Für jeden Fall wird beschrieben, welches Ergebnis zulässig ist. Bei einer Klassifikation können mehrere Kategorien vertretbar sein, solange eine unklare Nachricht an einen Mitarbeiter geht. Bei einer Wissensantwort werden erwartete Quellen und unzulässige Aussagen festgehalten. Bei einem Agenten wird jede erlaubte und verbotene Werkzeugaktion geprüft.

Abnahmekriterien trennen technische und fachliche Qualität. Technisch zählen unter anderem Verfügbarkeit, Laufzeit, Fehlerbehandlung und korrekte Systemübergaben. Fachlich zählen richtige Zuordnung, Quellenbezug, Korrekturaufwand und sichere Eskalation. Zusätzlich wird der Prozessnutzen gegen den in Schritt 2 gemessenen Ausgangszustand verglichen.

Ein Test muss auch die Nicht-Antwort erlauben. Wenn Daten fehlen oder die Anfrage außerhalb des freigegebenen Umfangs liegt, ist eine klare Übergabe besser als eine plausible Erfindung.

Schritt 10: Einen isolierten Prototyp mit echten Prozessdaten bauen

Der erste Prototyp sollte die kritischsten Annahmen prüfen. Bei einer Wissenssuche sind das möglicherweise Quellenqualität und Rechtefilter. Bei Dokumenten geht es um Erkennung und Feldvalidierung. Bei einem Agenten stehen Werkzeugrechte und Zustandsübergänge im Vordergrund.

Testdaten müssen den späteren Fällen entsprechen, dürfen aber nicht unkontrolliert in Entwicklungsumgebungen gelangen. Je nach Zweck werden Daten anonymisiert, synthetisch erzeugt oder in einer abgesicherten Umgebung verarbeitet. Synthetische Beispiele allein genügen nicht, wenn reale Dokumente stark variieren.

Der Prototyp schreibt zunächst nicht in führende Systeme. Er erzeugt einen Entwurf oder simuliert die geplante Aktion. Dadurch kann das Team Modell, Datenaufbereitung und Oberfläche ändern, ohne produktive Vorgänge zu beschädigen.

Bereits in dieser Phase werden Kosten und Laufzeiten gemessen. Ein Verfahren, das nur mit sehr langen Dokumentkontexten funktioniert, kann bei breiter Nutzung unwirtschaftlich werden. Ein kleineres Modell oder eine bessere Suche kann geeigneter sein als eine pauschal leistungsstärkere Modellklasse.

Schritt 11: Freigaben und Rückfallweg technisch umsetzen

Vor der Prozessintegration wird für jede Aktion festgelegt, ob die KI nur liest, einen Entwurf speichert, eine Bestätigung anfordert oder selbst ausführen darf. Diese Rechte werden in der Anwendung und den Zielsystemen erzwungen. Eine Formulierung im Prompt ist keine ausreichende Zugriffskontrolle.

Die Prüfoberfläche zeigt die relevanten Eingaben, Quellen und vorgeschlagenen Änderungen. Ein Mitarbeiter muss erkennen können, was sich durch seine Freigabe verändert. Korrekturen werden strukturiert erfasst, damit Fehler später nach Quelle, Modell, Regel oder Schnittstelle unterschieden werden können.

Der Rückfallweg gehört zum normalen Prozess. Ist der KI-Dienst nicht erreichbar, geht der Vorgang in eine sichtbare Warteschlange oder wird mit dem bisherigen Verfahren bearbeitet. Eine fehlgeschlagene Schreiboperation darf nicht als erfolgreich erscheinen. Wiederholungen benötigen eindeutige Vorgangskennungen, damit keine doppelten Tickets, Buchungen oder Nachrichten entstehen.

Das Ergebnis ist ein Ablauf, der auch ohne KI funktionsfähig bleibt. Diese Eigenschaft erleichtert später Wartung, Anbieterwechsel und kontrollierte Abschaltungen.

Schritt 12: Im Schattenbetrieb mit realen Vorgängen testen

Im Schattenbetrieb verarbeitet die neue Lösung reale Vorgänge parallel zum bisherigen Prozess, ohne das operative Ergebnis selbst festzulegen. Fachkräfte vergleichen Vorschlag und tatsächliche Bearbeitung. Sie dokumentieren nicht nur richtig oder falsch, sondern den Korrekturgrund.

Der KI-Schattenbetrieb sollte alle relevanten Fallklassen abdecken. Bleiben bestimmte Ausnahmen selten, werden sie gezielt ergänzt. Auch Systemausfälle, fehlende Rechte, veraltete Quellen und manipulierte Eingaben gehören in den Test.

Aus den Ergebnissen entstehen konkrete Änderungen. Häufige falsche Treffer können auf schlechte Metadaten hinweisen. Falsche Formulierungen trotz korrekter Quelle betreffen die Antwortlogik. Doppelte Vorgänge zeigen ein Integrationsproblem. Diese Ursachen dürfen nicht in einer allgemeinen Qualitätsquote verschwinden.

Erst wenn die festgelegten fachlichen und technischen Grenzen erreicht sind, erhält die Lösung produktive Rechte. Für bestimmte Fallgruppen kann der Schattenbetrieb länger bestehen bleiben.

Schritt 13: Mitarbeiter rollenbezogen vorbereiten

Nutzer benötigen keine allgemeine KI-Begeisterung, sondern Sicherheit im konkreten Arbeitsablauf. Sie müssen wissen, welche Fälle geeignet sind, welche Daten eingegeben werden dürfen, wie eine Ausgabe geprüft wird und wohin ein Fehler gemeldet wird.

Für Freigabeverantwortliche ist die Einweisung ausführlicher. Sie lernen, Quellen und vorgeschlagene Änderungen zu kontrollieren und dürfen eine Bestätigung nicht als bloßen Klick verstehen. Administratoren benötigen Kenntnisse zu Berechtigungen, Protokollen, Kosten und Ausfallwegen. Fachverantwortliche müssen Testfälle und Qualitätsgrenzen pflegen können.

Die Einführung erklärt auch, welche Aufgabe nicht automatisiert wird. Wenn der Kundenservice weiterhin die fachliche Antwort verantwortet, muss das klar benannt sein. Unklare Verantwortung führt entweder zu blindem Vertrauen oder dazu, dass Mitarbeiter jeden Entwurf vollständig neu erstellen und kein Nutzen entsteht.

Rückmeldungen werden in den Arbeitsablauf integriert. Eine Auswahl wie „falsche Quelle“, „Daten fehlen“, „Kategorie falsch“ oder „Formulierung ungeeignet“ ist hilfreicher als ein allgemeiner Daumen nach unten.

Schritt 14: Kontrolliert produktiv gehen

Der Produktivstart erfolgt nicht zwingend für alle Nutzer und Fälle gleichzeitig. Ein begrenztes Team, eine Produktgruppe oder eine Dokumentklasse erleichtert die Beobachtung. Autonome Aktionen bleiben zunächst enger als Entwurfsfunktionen.

Für den Start sind Verantwortliche und Erreichbarkeit geklärt. Technische Fehler landen nicht nur in einem Log, sondern bei einer benannten Person. Fachliche Fehler gehen an den Prozesseigentümer. Datenschutz- oder Sicherheitsvorfälle folgen dem vorhandenen Meldeweg des Unternehmens.

Ein Dashboard trennt Nutzung, technische Stabilität, fachliche Qualität und Prozesswirkung. Es zeigt beispielsweise Laufzeiten, nicht verarbeitete Vorgänge, Korrekturarten, Eskalationen und Nutzungskosten. Persönliche Ranglisten oder verdeckte Leistungsbewertung entstehen nicht als Nebenprodukt.

Änderungen an Modell, Prompt, Quelle oder Schnittstelle werden versioniert. Relevante Testfälle laufen vor der Freigabe erneut. Bei einer Verschlechterung kann die vorherige Version oder der manuelle Ablauf aktiviert werden.

Schritt 15: Nach dem Pilot über Stoppen, Verbessern oder Skalieren entscheiden

Ein Pilot ist erfolgreich, wenn er eine belastbare Entscheidung ermöglicht. Das kann auch bedeuten, die Idee nicht weiterzuverfolgen. Vielleicht ist die Datenaufbereitung unverhältnismäßig, ein Standardworkflow löst den Engpass einfacher oder die Korrekturquote bleibt für den Prozess zu hoch.

Bei einer Verbesserung wird die Ursache benannt. Fehlen Quellen, werden Inhalte gepflegt. Ist die Oberfläche unklar, wird die Prüfung vereinfacht. Scheitern Übergaben, wird die Integration stabilisiert. Ein Wechsel des Modells ist nur eine mögliche Maßnahme und nicht die Standardantwort auf jedes Problem.

Für die Skalierung werden Kosten, Kapazität, Support und neue Risikogrenzen geprüft. Ein Anwendungsfall, der für eine Abteilung funktioniert, wird nicht ungeprüft auf andere Daten und Rollen übertragen. Wiederverwendbar sind technische Bausteine, Testmethoden und Governance; die fachliche Freigabe bleibt an den jeweiligen Prozess gebunden.

Die Entscheidung wird mit den Ausgangswerten aus Schritt 2 begründet. So bleibt nachvollziehbar, welcher Nutzen tatsächlich erreicht wurde und unter welchen Bedingungen er gilt.

KI im Unternehmen einführen endet erst mit einem geregelten Betrieb

KI im Unternehmen einzuführen bedeutet, Verantwortung und Technik dauerhaft zu verbinden. Der produktive Betrieb benötigt einen Prozesseigentümer, technische Betreuung, wiederkehrende Qualitätsprüfung, Kostenkontrolle und einen geregelten Änderungsweg. Ohne diese Aufgaben altert eine gute Pilotlösung schnell.

Der nächste sinnvolle Schritt ist ein einzelner realer Vorgang. Dokumentieren Sie Eingang, Bearbeitung, Entscheidung, Ergebnis und die heute verwendeten Systeme. SW Business Solutions prüft mit Ihnen diesen Ablauf, grenzt eine geeignete KI-Funktion ab und entwickelt den Pilot einschließlich Integration, Prüfoberfläche und Rückfallweg. So entsteht kein zusätzlicher KI-Kanal, sondern ein belastbarer Bestandteil des bestehenden Unternehmensprozesses.