Inhalt
PERSÖNLICHE EINORDNUNG
Bei der Arbeit an UWM Private AI standen sehr schnell viele technische Möglichkeiten im Raum: lokale Modelle, Wissenssuche, Dokumentenanalyse, Projektgedächtnis, Prüfunterstützung und weitere Anwendungen. Genau an diesem Punkt wird ein KI-Projekt leicht unübersichtlich. Denn jede neue Funktion führt sofort zu neuen Werkzeugen, Modellen und Architekturfragen.
Für mich wurde deshalb eine andere Reihenfolge wichtiger: zuerst die konkrete Aufgabe sauber beschreiben und erst danach entscheiden, welche Technik dafür überhaupt benötigt wird. Im Teilprojekt „praktische KI-Anwendungen“ wurden mehrere mögliche Anwendungen getrennt betrachtet. Für einen möglichen Pilot rückten dabei nicht Modellnamen oder Benutzeroberflächen in den Mittelpunkt, sondern Fragen wie: Welche Unterlagen sollen durchsucht werden? Welche Quellenbelege müssen sichtbar sein? Welche Testfragen müssen beantwortet werden? Welche Daten dürfen verarbeitet werden und wer gibt ein Ergebnis frei?
Der Pilot ist in diesem Teilprojekt noch nicht als Betreiberentscheidung freigegeben und es liegen dort keine belastbaren Produktivergebnisse vor. Gerade deshalb ist die methodische Erkenntnis wichtig: Eine saubere Aufgabenbeschreibung verhindert, dass aus einer interessanten KI-Technik vorschnell eine Lösung für ein noch nicht ausreichend definiertes Problem wird.
Warum der Tool-First-Ansatz so verführerisch ist
Neue KI-Werkzeuge machen ihre Möglichkeiten unmittelbar sichtbar. Ein Modell kann Texte strukturieren, Dokumente zusammenfassen, Code erzeugen oder Fragen beantworten. Dadurch entsteht schnell der Impuls, zuerst eine Plattform auszuwählen und danach nach passenden Einsatzmöglichkeiten zu suchen.
Das kann für Experimente sinnvoll sein. Für einen belastbaren Unternehmenseinsatz reicht es jedoch nicht. Ein Tool beantwortet noch nicht die Fragen, welche Aufgabe verbessert werden soll, welche Daten verwendet werden dürfen, welche Qualität erwartet wird und wer ein Ergebnis fachlich freigibt. Genau diese Punkte bestimmen später, ob eine lokale Lösung, ein externer Dienst, RAG, eine einfache Suchfunktion oder möglicherweise gar keine KI die sinnvollste Lösung ist.
Der KI-Anwendungsfall ist die kleinste steuerbare Einheit
Ein guter KI-Anwendungsfall beschreibt nicht „wir wollen KI einsetzen“, sondern eine konkrete Arbeitssituation. Er verbindet eine Aufgabe mit Eingangsdaten, einem erwarteten Ergebnis, Qualitätskriterien, Verantwortlichkeiten und einer prüfbaren Grenze.
Beispiel: „Technische Dokumente schneller finden“ ist noch zu ungenau. Präziser wäre: „Ein berechtigter Fachanwender soll für eine definierte technische Frage relevante freigegebene Dokumente finden und zu jeder Antwort Quelle, Dokumentrevision und Fundstelle nachvollziehen können.“ Erst diese Formulierung macht sichtbar, was technisch wirklich erforderlich ist.
Einfach erklärt: Erst die Arbeit beschreiben, dann den Werkzeugkasten öffnen
Bei einer Werkstattaufgabe würde man normalerweise auch nicht zuerst irgendeine Maschine kaufen und anschließend überlegen, welches Bauteil damit hergestellt werden könnte. Zuerst wird geklärt, was gefertigt, geprüft oder repariert werden soll. Danach wählt man das passende Werkzeug.
Für KI gilt dasselbe Prinzip: Der Anwendungsfall beschreibt das Werkstück und die Qualitätsanforderung. Das KI-Modell, RAG, Datenbank, Cloud-Dienst oder lokale System sind Werkzeuge innerhalb der späteren Lösung.
Fünf Fragen, die vor der Toolauswahl beantwortet sein sollten
Bevor ein KI-Werkzeug ausgewählt wird, sollte der Anwendungsfall so weit beschrieben sein, dass technische Entscheidungen daran geprüft werden können. Dafür reichen häufig fünf Gruppen von Fragen.
1. Welche konkrete Aufgabe soll besser werden?
Nicht „Dokumentation mit KI“, sondern beispielsweise „zwei Revisionen eines technischen Dokuments vergleichen und Änderungen für einen Fachprüfer strukturiert hervorheben“. Je enger die Aufgabe beschrieben ist, desto besser lässt sich später testen, ob die Lösung wirklich hilft.
2. Welche Daten und Quellen werden benötigt?
Es muss klar sein, welche Dokumente, Datenbanken oder Eingaben erforderlich sind, wie aktuell sie sein müssen und ob sie verarbeitet werden dürfen. Bei technischem Unternehmenswissen gehören Herkunft, Revision und Freigabestatus häufig genauso zur Information wie der eigentliche Textinhalt.
3. Wie sieht ein brauchbares Ergebnis aus?
Eine KI-Antwort ist nicht allein deshalb gut, weil sie sprachlich überzeugend klingt. Vorab sollte feststehen, welche Informationen enthalten sein müssen, welche Quellen sichtbar sein sollen, welches Format erwartet wird und an welcher Stelle ein Mensch prüfen oder entscheiden muss.
4. Welche Fehler dürfen nicht unbemerkt bleiben?
Ein Anwendungsfall braucht Grenzen. Dazu gehören falsche Quellen, veraltete Revisionen, fehlende Berechtigungen, erfundene Aussagen oder die Verarbeitung ungeeigneter Daten. Je kritischer die Aufgabe, desto stärker müssen Prüf- und Freigabeschritte ausgeprägt sein.
5. Woran wird der Nutzen geprüft?
Ein Pilot sollte vor seinem Start wissen, was später bewertet wird. Das können beispielsweise Trefferqualität, Quellenrichtigkeit, Bearbeitungszeit, Anzahl notwendiger Korrekturen oder die Reproduzierbarkeit definierter Testfälle sein. Ohne vorher festgelegte Prüfkriterien lässt sich ein beeindruckender Demo-Effekt nur schwer von echtem Prozessnutzen unterscheiden.
AUS DER PRAXIS: VOM ANWENDUNGSKATALOG ZUM PRÜFBAREN PILOTKANDIDATEN
Ausgangslage: Im Teilprojekt „praktische KI-Anwendungen“ von UWM Private AI wurden mehrere mögliche Einsatzfelder gesammelt – unter anderem technische Dokumentensuche, Projektgedächtnis, Dokumentenanalyse und technische Prüfunterstützung.
Konkrete Aufgabe: Aus dieser Breite sollte ein Anwendungsfall so abgegrenzt werden, dass er später mit einem kleinen, kontrollierbaren Testbestand überprüft werden kann.
Vorgehen: Für einen möglichen ersten Pilot wurde eine technische Dokumentensuche mit nachvollziehbarem Quellenbeleg vorgeschlagen. Im Vordergrund stehen dabei nicht Modellname oder Oberfläche, sondern ein begrenzter Testkorpus, Referenzfragen mit erwarteten Antworten, Quellen- und Revisionsbezug, Rechteprüfung und menschliche Freigabe.
Entscheidungsstand: Dieser Pilot ist im betreffenden Teilprojekt bislang ein dokumentierter Vorschlag und noch keine Betreiberfreigabe. Eine Implementierung oder ein Pilot-Test wird für diesen Projektstand nicht behauptet.
Erkenntnis: Schon in der Konzeptphase lässt sich erkennen, welche Anforderungen später eine Toolauswahl bestimmen. Wenn Quellenbeleg, Datenkontrolle und nachvollziehbare Prüfung zwingend sind, werden manche technischen Optionen automatisch geeigneter oder ungeeigneter.
Übertragbarkeit: Nicht der konkrete UWM-Pilot ist allgemeingültig. Übertragbar ist die Methode: zuerst Aufgabe, Daten, Qualitätsziel und Prüfweg definieren – danach die Technik auswählen.
Erst danach werden Architektur und Tools vergleichbar
Wenn der Anwendungsfall beschrieben ist, wird die technische Auswahl deutlich sachlicher. Dann lässt sich beispielsweise prüfen, ob Daten das Unternehmen verlassen dürfen, ob das Modell lokal laufen muss, ob eine externe Wissensbasis benötigt wird, wie Quellen eingebunden werden und welche Schnittstellen vorhanden sein müssen.
Dadurch verschiebt sich die Diskussion von „Welches KI-Tool ist das beste?“ zu einer belastbareren Frage: „Welche technische Kombination erfüllt unseren konkreten Anwendungsfall mit vertretbarem Aufwand und kontrollierbarem Risiko?“ Das reduziert auch die Gefahr unnötiger Insellösungen, weil sich Werkzeuge an Prozess und Informationsfluss messen lassen müssen.
Ein einfacher Steckbrief für einen KI-Anwendungsfall
Für die erste Bewertung muss kein umfangreiches Lastenheft entstehen. Ein kompakter Steckbrief reicht oft aus, wenn er die entscheidenden Punkte eindeutig macht.
- Aufgabe: Welche konkrete Tätigkeit oder Entscheidung soll unterstützt werden?
- Nutzer: Wer arbeitet mit der Lösung und wer trägt fachliche Verantwortung?
- Eingangsdaten: Welche Informationen werden benötigt und welchen Schutzbedarf haben sie?
- Erwartetes Ergebnis: Was muss die Ausgabe enthalten – und was ausdrücklich nicht?
- Qualitätskriterien: Woran wird richtig, vollständig und brauchbar erkannt?
- Quellen-/Nachweisbedarf: Muss die Antwort auf Dokument, Revision oder Fundstelle zurückführbar sein?
- Freigabe: Welche Ergebnisse dürfen automatisiert weiterlaufen und wo entscheidet ein Mensch?
- Test: Mit welchen definierten Fällen wird der Nutzen vor einem breiteren Einsatz geprüft?
Wann ein Tool trotzdem am Anfang stehen darf
Exploration ist nicht falsch. Ein neues Modell oder eine neue Funktion kann bewusst getestet werden, um Fähigkeiten kennenzulernen und Ideen zu entwickeln. Problematisch wird es erst, wenn aus einem Technologieexperiment ohne Zwischenschritt ein produktiver Unternehmensprozess entstehen soll.
Der Übergang sollte deshalb klar sein: Experimentieren darf toolgetrieben sein. Ein betrieblicher Pilot braucht dagegen einen definierten Anwendungsfall, Prüfkriterien und Verantwortlichkeiten. Spätestens an dieser Grenze muss aus „Was kann dieses Tool?“ die Frage werden: „Welche unserer Aufgaben soll damit unter welchen Bedingungen zuverlässig unterstützt werden?“
Fazit: Die richtige KI-Frage beginnt nicht mit einem Produktnamen
Ein KI-Projekt wird nicht dadurch belastbar, dass früh ein leistungsfähiges Modell oder eine bekannte Plattform ausgewählt wird. Belastbar wird es, wenn eine konkrete Aufgabe so beschrieben ist, dass Daten, Qualität, Schutzbedarf, Verantwortlichkeit und Nutzen geprüft werden können.
Für UWM Private AI ist diese Reihenfolge zu einem wichtigen Arbeitsprinzip geworden: Der Anwendungsfall führt die technische Entscheidung – nicht umgekehrt. Damit bleibt auch die Möglichkeit offen, für unterschiedliche Aufgaben unterschiedliche Modelle, lokale oder externe Komponenten und andere Werkzeuge einzusetzen, ohne die gesamte Architektur an ein einzelnes Produkt zu binden.
Vorheriger Beitrag:
Artikel 011 – Prozesse sichtbar machen: Wo Wartezeiten, Doppelarbeit und Informationsverluste entstehen
Nächster Beitrag:
Artikel 013 – Produktdaten zwischen ERP, PIM und Shop: Wer führt welche Information?
KI-Anwendungsfälle strukturiert bewerten
UWM-FTBE betrachtet KI nicht isoliert als Softwarethema, sondern im Zusammenhang mit Prozess, Daten, Fachverantwortung und technischer Umsetzung. Ein klar abgegrenzter Anwendungsfall schafft die Grundlage, um lokale, externe oder hybride Lösungen sachlich zu vergleichen.
Quellen – Stand Oktober 2026
Für die allgemeine Methodeneinordnung wurde geprüft, dass das NIST AI Risk Management Framework die Festlegung und Dokumentation von Zweck, Nutzungskontext, Beteiligten, Auswirkungen und Prüfkriterien bereits in der MAP-Funktion vor die spätere Risikobewertung und technische Nutzung stellt. Die eigene UWM-FTBE-Projektgrundlage wird getrennt von externen Fachquellen geführt.
- NIST – Artificial Intelligence Risk Management Framework (AI RMF 1.0) – insbesondere MAP 1 / Kontext, Zweck und Einsatzbedingungen.
- NIST – AI RMF Playbook – freiwillige Handlungsvorschläge zu Govern, Map, Measure und Manage.
Geprüft am 10.10.2026. NIST weist darauf hin, dass AI RMF 1.0 derzeit überarbeitet wird. Der Beitrag ist keine Rechts- oder Normberatung.