IBM watsonx im Unternehmen einführen: 6 Schritte

Ein KI-Pilot ist schnell demonstriert. Die eigentliche Bewährungsprobe beginnt, wenn Ergebnisse in Prozesse, Fachentscheidungen oder SAP-nahe Abläufe einfließen und nachvollziehbar bleiben müssen. Wer IBM watsonx im Unternehmen einführen will, sollte deshalb nicht bei einem Modell oder Chat-Interface beginnen, sondern bei Verantwortlichkeiten, Datenflüssen und einem klar abgegrenzten Geschäftszweck.

watsonx kann als Plattform für KI-Entwicklung, Datenbereitstellung und Governance unterschiedliche Anforderungen zusammenführen. Daraus entsteht aber nicht automatisch ein produktiver Nutzen. Gerade in mittelständischen Unternehmen und größeren Organisationen hängen Qualität, Akzeptanz und regulatorische Sicherheit davon ab, wie konsequent der Einsatz in bestehende IT- und Betriebsstrukturen eingebettet wird.

IBM watsonx im Unternehmen einführen: Vom Use Case zum Betrieb

Ein belastbares Einführungsprojekt folgt einer anderen Logik als ein isolierter Proof of Concept. Der Proof zeigt, ob eine Aufgabe technisch grundsätzlich lösbar ist. Der produktive Einsatz muss zusätzlich klären, welche Daten verwendet werden dürfen, wer Ergebnisse fachlich verantwortet, wie Änderungen kontrolliert werden und was bei fehlerhaften oder unvollständigen Antworten geschieht.

Die IBM watsonx Plattform bietet dafür je nach Ausprägung Funktionen für die Entwicklung und Nutzung von KI-Modellen, die Datenbasis sowie das Governance-Management. Ob alle Komponenten benötigt werden, hängt vom Anwendungsfall und von der vorhandenen Datenarchitektur ab. Ein Unternehmen mit etabliertem Data Lake und klaren MDM-Prozessen hat andere Ausgangsbedingungen als eine Organisation, deren relevante Informationen noch in SharePoint-Strukturen, SAP-Transaktionen und lokalen Fachanwendungen verteilt liegen.

1. Einen Prozess mit messbarer Wirkung auswählen

Der erste Use Case sollte weder der spektakulärste noch der allgemeinste sein. Geeignet sind Aufgaben mit wiederkehrenden Bearbeitungsschritten, ausreichend verfügbaren Daten und einer klaren fachlichen Ergebnisdefinition. Beispiele sind die Recherche in technischen oder regulatorischen Dokumentationen, die strukturierte Vorprüfung von Serviceanfragen oder die Unterstützung bei der Analyse von Abweichungen in Beschaffungs- und Lieferprozessen.

Entscheidend ist die Abgrenzung: Welche Eingaben verarbeitet das System, welches Ergebnis liefert es und welcher Mitarbeitende prüft oder entscheidet anschließend? Bei einem Assistenzsystem für den Einkauf kann watsonx etwa Informationen aus freigegebenen Verträgen und Richtlinien zusammenführen. Die Freigabe einer Bestellung bleibt jedoch ein geregelter Fachprozess. Diese Trennung schützt vor falschen Erwartungen und macht den Nutzen messbar, etwa über Bearbeitungszeit, Rechercheaufwand oder Fehlerquote.

2. Datenflüsse vor der Modellkonfiguration prüfen

Die häufigste Ursache für unzuverlässige KI-Ergebnisse ist nicht das Modell, sondern eine unklare Datenbasis. Vor einer Anbindung müssen Herkunft, Aktualität, Qualität und Zugriffsrechte der verwendeten Informationen dokumentiert sein. Das gilt besonders dann, wenn SAP-Stamm- und Bewegungsdaten mit Dokumenten, Wissensdatenbanken oder externen Quellen kombiniert werden.

Für jeden Datenfluss sollten Projektteams nachvollziehen können, welche Daten in die Lösung gelangen, wie sie aufbereitet werden und wo sie gespeichert oder protokolliert werden. Sensible Daten, personenbezogene Informationen und Geschäftsgeheimnisse benötigen eine passende Schutzbedarfsbewertung. Nicht jeder fachlich interessante Datenbestand ist für einen KI-Anwendungsfall freigegeben.

In SAP-nahen Landschaften kommen zusätzliche Fragen hinzu: Werden Daten nur lesend bereitgestellt? Erfolgt ein Zugriff über freigegebene Schnittstellen? Wie werden Berechtigungen aus dem führenden System berücksichtigt? Eine KI-Lösung darf kein paralleles, unkontrolliertes Berechtigungsmodell schaffen. Belastbare Datenarchitektur bedeutet hier auch, fachliche Schlüssel, Versionen und Gültigkeitszeiträume korrekt zu behandeln.

3. Architektur und Integrationsgrenzen bewusst festlegen

watsonx kann in eine hybride Unternehmensarchitektur eingebunden werden. Trotzdem ist vor dem Aufbau zu entscheiden, wo Daten verarbeitet werden, wie Identitäten angebunden werden und welche Systeme produktiv integriert werden sollen. Diese Entscheidungen betreffen Betrieb, Informationssicherheit, Kostensteuerung und spätere Erweiterbarkeit gleichermaßen.

Für einen ersten produktiven Anwendungsfall ist eine klar begrenzte Integration häufig sinnvoller als ein breiter Plattformausbau. Ein Dokumentenassistent kann zunächst auf einen geprüften, versionierten Wissensbestand zugreifen. Erst wenn Qualität und Nutzungsverhalten belastbar bewertet sind, sollte die Einbindung weiterer Quellen oder transaktionaler Prozesse folgen.

Besondere Vorsicht ist geboten, wenn KI-Ergebnisse Folgeaktionen auslösen sollen, etwa Änderungen in Stammdaten, Tickets oder Bestellungen. Zwischen generierter Empfehlung und schreibendem Zugriff gehört in vielen Fällen eine fachliche Prüfung. Die technische Möglichkeit zur Automatisierung ersetzt keine Freigabelogik. Gerade bei kritischen SAP-Prozessen sind Rollenmodelle, Protokollierung und Rückfallverfahren Bestandteil der Lösung, nicht nachgelagerte Dokumentation.

4. Governance als Arbeitsprozess etablieren

KI-Governance wird oft auf Richtlinien reduziert. Für den Betrieb reicht das nicht aus. Projektteams benötigen konkrete Entscheidungen: Wer ist für den Use Case fachlich verantwortlich? Wer verantwortet Datenqualität und Zugriffsfreigaben? Wer genehmigt Änderungen an Prompts, Wissensquellen, Modellen oder Integrationen? Und welche Stelle bewertet Risiken vor dem produktiven Einsatz?

watsonx.governance kann Prozesse zur Dokumentation, Überwachung und Bewertung von Modellen unterstützen. Die Plattformfunktion ersetzt jedoch keine unternehmensweite Verantwortungsstruktur. Sinnvoll ist ein schlankes, aber verbindliches Steuerungsmodell mit fachlichem Owner, technischem Owner, Datenverantwortung, Informationssicherheit und Compliance-Einbindung. Bei höherem Risiko müssen auch Datenschutz und die Anforderungen des EU AI Act frühzeitig eingeordnet werden.

Die rechtliche Bewertung konkreter Sachverhalte, etwa zur Rollenverteilung nach EU AI Act oder zur datenschutzrechtlichen Zulässigkeit einzelner Verarbeitungen, ist von der technischen Umsetzung zu trennen. Bei Bedarf kann hierfür die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH eingebunden werden. Für das Projekt bedeutet das: Technische Nachweise, Datenflussdokumentation und Betriebsregeln müssen so vorliegen, dass eine rechtliche Einordnung überhaupt belastbar möglich ist.

5. Qualität testen wie eine produktive Fachfunktion

Ein KI-System wird nicht allein durch einen erfolgreichen Demo-Dialog abgenommen. Erforderlich sind fachlich definierte Testszenarien mit typischen, unvollständigen und kritischen Eingaben. Dazu gehören auch Fälle, in denen die Lösung keine Antwort geben sollte, weil Quellen fehlen, Berechtigungen nicht ausreichen oder die Fragestellung außerhalb des vorgesehenen Anwendungsbereichs liegt.

Die Bewertung braucht nachvollziehbare Kriterien. Bei einem Rechercheassistenten können Quellenbezug, Vollständigkeit, Aktualität, sprachliche Eindeutigkeit und die korrekte Kennzeichnung von Unsicherheit bewertet werden. Bei Klassifikations- oder Prognoseanwendungen treten weitere Kennzahlen hinzu. Welche Schwellenwerte angemessen sind, hängt vom Prozessrisiko ab. Für eine interne Wissensrecherche gelten andere Maßstäbe als für eine Entscheidung mit Auswirkungen auf Versorgung, Qualität oder Compliance.

Testmanagement sollte außerdem Änderungen abdecken. Neue Dokumente, geänderte Berechtigungen oder eine Anpassung des Modells können Ergebnisse sichtbar verändern. Deshalb gehören Testfälle, Freigabestatus und Ergebnisprotokolle in einen wiederholbaren Release-Prozess. Das schafft revisionssicheres Reporting und verhindert, dass sich eine anfangs geprüfte Lösung schrittweise vom freigegebenen Zustand entfernt.

6. Betrieb, Monitoring und Skalierung von Anfang an planen

Der Go-Live ist kein Endpunkt, sondern der Beginn der eigentlichen Steuerung. Fachbereiche müssen wissen, wie sie fehlerhafte Antworten melden, wer Incidents priorisiert und wann eine Funktion eingeschränkt oder abgeschaltet wird. IT-Teams benötigen Transparenz über Nutzung, Antwortzeiten, Kosten und technische Fehler. Datenverantwortliche müssen erkennen können, wenn Quellen veralten oder ihre Qualität sinkt.

Ein sinnvoller Betriebsplan definiert daher Servicezeiten, Supportwege, Eskalationen, Änderungsfenster und regelmäßige Qualitätsprüfungen. Bei geschäftskritischen Integrationen gehören Cutover-Planung und Rückfalloptionen dazu. Wird die KI-Lösung parallel zu einer S/4HANA-Transformation eingeführt, müssen Abhängigkeiten zu Stammdatenharmonisierung, Berechtigungskonzepten und Testzyklen früh sichtbar gemacht werden. Andernfalls wird ein zusätzlicher technischer Baustein zum Risiko im Go-Live.

Erst auf dieser Grundlage lohnt sich die Skalierung auf weitere Use Cases. Wiederverwendbar sind nicht nur technische Komponenten, sondern vor allem freigegebene Datenzugänge, Rollenmodelle, Testmethoden und Governance-Entscheidungen. Das senkt den Aufwand je Folgeprojekt, ohne die fachliche Prüfung zu standardisieren, wo sie individuell bleiben muss.

Der sinnvolle Einstieg ist kein Großprogramm

Für viele Unternehmen ist ein strukturierter Quick Check oder Workshop der angemessene Start. Dabei lässt sich ein priorisierter Use Case gegen Datenlage, Architektur, Prozessrisiko und Betriebsfähigkeit prüfen. Das Ergebnis sollte keine abstrakte KI-Roadmap sein, sondern eine Entscheidungsgrundlage mit Integrationsbild, Verantwortlichkeiten, offenen Risiken und einem realistischen Umsetzungsschnitt.

watsonx-Einführung operativ vorbereiten

Quteco strukturiert den Einstieg in IBM watsonx mit Quick Checks und Workshops, die Use Case, Datenflüsse, SAP-Integration, Governance und Betriebsanforderungen gemeinsam betrachten. Bei der anschließenden Umsetzung können technische Projektsteuerung, Testmanagement und produktionsnahe Einführungsarbeit verbunden werden. Der entscheidende nächste Schritt ist eine belastbare Abgrenzung: Was soll die Lösung im ersten Betriebsrelease verlässlich leisten und was ausdrücklich noch nicht?