KI-Pilot planen: vom Use Case zum belastbaren Go/No-Go
Ein guter KI-Pilot ist kein kleines KI-Projekt. Er ist ein kontrolliertes Experiment mit einer konkreten Geschäftsfrage.
Die falsche Ausgangsfrage lautet:
„Welches Modell oder Tool sollen wir ausprobieren?“
Die bessere Frage lautet:
„Welche Annahme müssen wir mit möglichst wenig Aufwand beweisen oder widerlegen, bevor wir weiter investieren?“
Damit wird aus einem Innovationsprojekt eine belastbare Entscheidungsgrundlage.
Die kurze Version: ein KI-Pilot in 10 Schritten
- konkreten Nutzer und Prozess wählen,
- Problem und Nutzenhypothese formulieren,
- Scope eng begrenzen,
- reale Datenquellen identifizieren,
- Datenschutz, Rechte und Sicherheitsgrenzen klären,
- minimale Zielarchitektur skizzieren,
- reale Testfälle definieren,
- messbare Erfolgskriterien festlegen,
- Pilot mit echten Nutzern testen,
- Go/No-Go anhand der Evidenz entscheiden.
Wenn diese zehn Punkte klar sind, ist die Tool-Wahl meist deutlich einfacher.
1. Nicht mit „KI“ beginnen, sondern mit einer Aufgabe
Ein Use Case ist nicht:
- „Chatbot für das Unternehmen“
- „Wir brauchen RAG“
- „Copilot für alle“
- „Agenten einführen“
Ein belastbarer Use Case beschreibt eine konkrete Aufgabe.
Beispiel:
Zu breit:
„Ein Wissensassistent für den Kundenservice.“
Besser:
„Servicemitarbeiter sollen für Produktgruppe X die aktuelle technische Richtlinie finden, eine belegte Antwort erhalten und direkt zur Originalquelle springen können.“
Damit werden Nutzer, Daten, Ergebnis und Qualitätsanforderung sichtbar.
2. Die Nutzenhypothese explizit machen
Der Pilot braucht eine falsifizierbare Annahme.
Beispiel:
Wenn Servicemitarbeiter Richtlinien über einen RAG-Assistenten mit Quellenbezug finden, sinkt der Suchaufwand und die Zahl nicht belegbarer Antworten bleibt unter einer vorab definierten Grenze.
Die Hypothese sollte beantworten:
- Was wird besser?
- Für wen?
- In welchem Prozess?
- Was wäre ein messbarer Erfolg?
- Welche Fehler wären nicht akzeptabel?
Ohne diese Formulierung kann am Ende fast jede Demo als „Erfolg“ interpretiert werden.
3. Scope radikal begrenzen
Der schnellste Weg, einen Pilot zu ruinieren, ist zu viel Scope.
Typische Scope-Grenzen:
- eine Abteilung,
- ein Dokumentbestand,
- ein Prozess,
- eine Sprache,
- ein konkreter Nutzerkreis,
- nur Lesen statt Schreiben,
- keine Vollautomatisierung,
- nur ein integriertes Zielsystem.
Beispiel:
Nicht „KI für HR“, sondern:
„RAG für freigegebene HR-Richtlinien in Österreich, nur lesend, mit Quellenangabe, für HR-Sachbearbeiter.“
Das ist testbar.
4. Daten zuerst prüfen
Bevor Architektur gebaut wird, sollte man die echten Daten ansehen.
Fragen:
- Wo liegt die relevante Information?
- Gibt es mehrere Versionen?
- Wer ist fachlicher Owner?
- Wie aktuell sind die Daten?
- Welche Dateiformate existieren?
- Welche Rechte gelten?
- Gibt es sensible oder personenbezogene Inhalte?
- Wie oft ändern sich die Quellen?
Viele Piloten scheitern, weil die Datenrealität erst nach dem technischen Build sichtbar wird.
Für RAG-Projekte hilft der Guide RAG-Datenquellen anbinden.
5. Rechte und Risiken früh klären
Ein Pilot sollte nicht nur mit künstlichen Testdaten funktionieren, wenn der spätere Use Case reale Unternehmensdaten braucht.
Zu klären sind unter anderem:
- welche Daten verarbeitet werden,
- welche Nutzer Zugriff haben,
- welche Systeme beteiligt sind,
- welche Anbieter Daten verarbeiten,
- ob Inhalte repliziert werden,
- wie Logs behandelt werden,
- welche Freigaben erforderlich sind.
Für RAG gilt zusätzlich: Berechtigungen müssen im Retrieval erhalten bleiben. Siehe RAG-Berechtigungen & Security Trimming.
Die technische Einordnung ersetzt keine Rechtsberatung.
6. Minimalarchitektur statt Zielplattform
Ein Pilot braucht keine vollständige Enterprise-Plattform.
Er braucht die kleinste Architektur, die die zentrale Hypothese realistisch testet.
Beispiel für RAG:
Quelle → Ingestion → Search/Vector Index → Retrieval → LLM → kleine Nutzeroberfläche
Noch nicht zwingend nötig:
- Multi-Region,
- vollständige Self-Service-Plattform,
- Dutzende Connectoren,
- komplexe Agent-Orchestrierung,
- große Admin-Konsole.
Aber: Die Architektur darf die kritischen Risiken nicht künstlich ausblenden. Wenn Berechtigungen später entscheidend sind, sollten sie bereits im Pilot vorkommen.
7. Reale Testfälle vor dem Build definieren
Ein KI-Pilot wird deutlich besser, wenn die Evaluation vor der Implementierung beginnt.
Sammeln Sie 20–50 reale Fälle, abhängig vom Use Case.
Für jeden Fall:
- Eingabe / Frage,
- erwartetes Ergebnis,
- erwartete Quelle,
- kritische Fehler,
- gegebenenfalls Nutzerrolle.
Beispiel:
| Testfrage | Erwartung | |---|---| | Welche Reisekostenregel gilt aktuell? | aktuelle Richtlinie + Quelle | | Welche Freigabe braucht Betrag X? | korrekter Prozessschritt | | Frage ohne belegte Antwort | System sagt nachvollziehbar „nicht genug Evidenz“ | | Nutzer ohne HR-Recht fragt nach HR-Dokument | kein vertraulicher Treffer |
Das ist wesentlich aussagekräftiger als „wir haben ein paar Prompts ausprobiert“.
8. Erfolgskriterien festlegen
Die Metriken hängen vom Use Case ab.
Typische Kategorien:
Business
- Bearbeitungszeit,
- Task Completion,
- Zahl manueller Schritte,
- Nutzungsrate,
- Rückfragen.
Qualität
- fachliche Korrektheit,
- Retrieval Recall,
- Groundedness,
- Citation Accuracy,
- Fehlerklassen.
Betrieb
- Latenz,
- Kosten pro Aufgabe,
- Fehlerrate,
- Aktualität der Daten.
Sicherheit
- Unauthorized Retrieval,
- falsche Tool Calls,
- Permission Violations.
Wichtig:
Nicht jede Metrik braucht einen perfekten Zielwert. Aber die Go/No-Go-Entscheidung braucht vorher definierte Grenzen.
9. Mit realen Nutzern testen
Ein Pilot, den nur Entwickler oder Projektteam testen, beweist wenig über den echten Workflow.
Reale Nutzer zeigen:
- ob Fragen anders formuliert werden,
- ob Quellen verständlich sind,
- ob die Antwort in den Prozess passt,
- wo Vertrauen fehlt,
- welche Fehler tatsächlich relevant sind.
Ein kleines, gut ausgewähltes Testteam ist wertvoller als ein breiter Rollout ohne Messung.
10. Go/No-Go explizit entscheiden
Am Ende sollte nicht die Frage stehen:
„Hat es uns gefallen?“
Sondern:
Go
- Nutzenhypothese bestätigt,
- kritische Qualität erreichbar,
- Daten- und Rechtepfad tragfähig,
- Integration realistisch,
- Betrieb wirtschaftlich plausibel.
Iterate
- Nutzen grundsätzlich bestätigt,
- einzelne technische oder organisatorische Engpässe lösbar,
- klare nächste Hypothese vorhanden.
No-Go
- Nutzen zu gering,
- Daten ungeeignet,
- kritische Qualität nicht erreichbar,
- Integration unverhältnismäßig,
- Risiko oder Betrieb nicht tragfähig.
Ein No-Go kann ein erfolgreicher Pilot sein, wenn er früh eine teure Fehlentscheidung verhindert.
Beispiel: 4-Wochen-KI-Pilot
Nicht jeder Pilot braucht vier Wochen. Aber als Planungsgerüst:
Woche 1 – Scope & Baseline
- Use Case,
- Daten,
- Nutzer,
- Risiken,
- Eval-Set,
- Ausgangsprozess messen.
Woche 2 – Minimaler Build
- Kernpipeline,
- Datenintegration,
- UI/Workflow,
- Logging,
- erste Tests.
Woche 3 – Qualität & Integration
- Fehlerklassen analysieren,
- Retrieval/Prompts/Tools verbessern,
- Rechte prüfen,
- reale Nutzer testen.
Woche 4 – Evidenz & Entscheidung
- Eval gegen Baseline,
- Kosten/Latenz,
- Failure Map,
- Produktionslücken,
- Go/Iterate/No-Go.
Pilot vs. PoC vs. MVP
Die Begriffe werden oft vermischt.
| Begriff | Primäre Frage | |---|---| | PoC | Ist es technisch grundsätzlich möglich? | | Pilot | Funktioniert es im begrenzten realen Einsatz? | | MVP | Ist das kleinste nutzbare Produkt für echte Nutzung vorhanden? | | Production Readiness | Kann es zuverlässig und verantwortbar betrieben werden? |
Ein KI-Pilot sollte näher am realen Prozess sein als ein PoC, aber noch bewusst begrenzt bleiben.
Was nicht in einen guten Pilot gehört
Typische Anti-Patterns:
- zuerst Tool auswählen, dann Problem suchen,
- zu viele Use Cases gleichzeitig,
- nur Demo-Daten,
- keine echten Nutzer,
- keine Baseline,
- keine Abbruchkriterien,
- Governance komplett auf später verschieben,
- Vollautomatisierung im ersten Schritt,
- „erfolgreich“, weil eine Antwort beeindruckend klang.
KI-Pilot-Canvas
Für die erste Planung reichen diese zwölf Felder:
- Nutzer
- Aufgabe
- aktueller Prozess
- Nutzenhypothese
- Datenquellen
- Berechtigungen
- kritische Risiken
- Pilot-Scope
- Architektur
- Testfälle
- Erfolgskriterien
- Go/No-Go-Regel
Das lässt sich in einem Workshop auf eine belastbare Entscheidungsgrundlage bringen.
Wann ein Workshop sinnvoller ist als sofortiger Build
Wenn mehrere Use Cases konkurrieren oder Daten, Scope und Erfolgskriterien noch unklar sind, spart ein kurzer strukturierter Workshop oft mehr Zeit als ein vorschneller Prototyp.
Mein KI-Workshop vom Use Case zum Pilot ist genau dafür gedacht: priorisieren, Daten und Risiken klären, Pilot definieren.
Wenn die Zielarchitektur selbst noch offen ist, passt KI-Beratung & AI Solution Architecture.
Wenn Scope und Architektur stehen und der Pilot gebaut werden soll, geht es weiter mit RAG-Implementierung & KI-Integration.
Nach dem Pilot: Production Readiness
Ein erfolgreicher Pilot ist noch kein Go-live.
Vor Produktion sollten zusätzlich geprüft werden:
- Regressionen,
- Monitoring,
- Rollen und Ownership,
- Security,
- Permission Boundaries,
- Failure Handling,
- Last,
- Kosten,
- Rollback,
- Datenaktualität.
Dafür ist AI Production Readiness der nächste Schritt.
Sie haben mehrere KI-Ideen, aber noch keinen belastbaren ersten Pilot?
→ Use Cases priorisieren und Pilot definieren