Viele KI-Projekte scheitern nicht an der Technik, sondern an einem unklaren Start. Ein Team probiert mehrere Werkzeuge gleichzeitig, misst keinen Ausgangswert und kann nach einigen Wochen weder Nutzen noch Risiko belegen. Ein guter KI-Einsatzplan im Team dreht diese Reihenfolge um: Erst wird ein konkretes Problem beschrieben, dann ein begrenzter Pilot aufgebaut und erst nach belastbaren Ergebnissen über den Rollout entschieden.
Der folgende Sieben-Schritte-Plan ist für österreichische Unternehmen gedacht, die KI praktisch testen wollen, ohne sofort einen ganzen Bereich umzustellen. Er trennt Pilot und Produktion, schützt reale Daten und macht Erfolg sowie Abbruch messbar. Rechtliche Pflichten hängen vom konkreten System und Verwendungszweck ab; bei sensiblen oder folgenreichen Anwendungen sind die zuständigen Fachstellen früh einzubinden.
Warum ein enger Pilot besser ist als ein großer KI-Vorsatz
„Wir müssen etwas mit KI machen“ klingt nach Aufbruch, liefert aber kein prüfbares Ziel. Ein begrenzter Anwendungsfall ist wesentlich stärker: „Wir testen, ob ein freigegebener Assistent aus öffentlichen Produktunterlagen brauchbare Entwürfe für interne Wissensfragen erstellt.“ Damit lassen sich Daten, Nutzergruppe, Qualitätsmaßstab und erwarteter Vorteil bestimmen.
Die WKO empfiehlt in ihren aktuellen KI-Tipps für KMU, Status quo und Ziele zu klären und mit Pilotprojekten in einem begrenzten Bereich zu beginnen, bevor unternehmensweit ausgerollt wird. Genau dafür dient der Einsatzplan: Er verwandelt eine vage Idee in ein kontrolliertes Experiment mit einer echten Entscheidung am Ende.
Schritt 1: Ein Problem mit Ausgangswert auswählen
Der Pilot beginnt nicht beim Tool, sondern bei einer wiederkehrenden Aufgabe. Geeignet sind Prozesse, die häufig genug vorkommen, eine klare Ausgabe haben und im Test keine unmittelbaren Schäden verursachen. Beispiele sind erste Gliederungen, interne Zusammenfassungen freigegebener Dokumente, Kategorisierung unkritischer Anfragen oder Entwürfe für Lernmaterial.
Vor dem ersten KI-Test wird der heutige Ablauf gemessen. Wie lange dauert die Aufgabe? Wie viele Korrekturen sind nötig? Welche Fehler kommen vor? Wie zufrieden sind die Beteiligten? Eine kleine Stichprobe von zehn bis zwanzig realen, datenschutzgerecht vorbereiteten Fällen reicht häufig für einen Ausgangswert. Ohne Baseline wird jede spätere Zeitersparnis zur Schätzung.
Eine gute Problemformulierung enthält vier Elemente:
- die konkrete Aufgabe,
- die heutige Belastung oder Qualitätslücke,
- die betroffene Nutzergruppe und
- die Grenze dessen, was nicht automatisiert werden soll.
Beispiel: „Das Supportteam benötigt durchschnittlich zwölf Minuten für einen internen Antwortentwurf. Der Pilot soll die Entwurfszeit senken, ohne Kundendaten an ein nicht freigegebenes System zu übertragen und ohne Antworten automatisch zu versenden.“
Schritt 2: Zweck, Risiko und Beteiligte abgrenzen
Ein allgemeines Sprachmodell kann viele Aufgaben erfüllen. Für die Bewertung zählt jedoch der konkrete Einsatz. Die RTR-Übersicht zu Risikostufen von KI-Systemen erklärt den risikobasierten Ansatz des AI Act und weist darauf hin, dass Einstufung und Pflichten vom Verwendungszweck abhängen. Ein Textentwurf für interne Schulung ist anders zu behandeln als ein System, das Bewerberinnen und Bewerber bewertet.
Das Pilotblatt sollte daher festhalten:
- Was darf das System im Test tun?
- Welche Entscheidung bleibt vollständig beim Menschen?
- Welche Datenarten sind erlaubt, anonymisiert oder ausgeschlossen?
- Wer ist vom Ergebnis betroffen?
- Werden Inhalte intern genutzt oder extern sichtbar?
- Welche Teams müssen zustimmen oder beraten?
Bei Beschäftigtendaten, Recruiting, Leistungsbewertung oder Überwachung sind HR, Datenschutz und gegebenenfalls Betriebsrat keine spätere Kontrollstation, sondern Teil der Planung. Verbotene Praktiken oder mögliche Hochrisiko-Anwendungen gehören nicht in einen improvisierten Teamtest.
Schritt 3: Werkzeug und Datenweg vor dem Test prüfen
Erst jetzt werden mögliche Werkzeuge verglichen. Der Funktionsumfang ist nur ein Kriterium. Ebenso wichtig sind Vertrag, Speicherorte, Zugriffssteuerung, Protokollierung, Löschmöglichkeiten, Nutzung von Eingaben für Training, Unterauftragnehmer und Änderungen der Bedingungen. Ein kostenloser Dienst kann für öffentliche Ideensammlung ausreichen und für interne Unterlagen völlig ungeeignet sein.
Zeichnen Sie den Datenweg auf einer Seite: Woher kommt die Eingabe? Wer bereitet sie vor? An welchen Dienst wird sie übertragen? Wo wird der Output gespeichert? Wer kann darauf zugreifen? Wann wird er gelöscht? Diese Skizze deckt oft offene Fragen auf, die in einer Produktpräsentation unsichtbar bleiben.
Für den Pilot gilt Datenminimierung. Statt komplette Kundenakten zu verwenden, werden synthetische oder konsequent anonymisierte Testfälle bevorzugt. Wenn echte Daten zwingend nötig erscheinen, muss genau begründet und geprüft werden, warum. Die WKO beschreibt in ihren Hinweisen zu kundenbezogenen Daten, dass Rechtsgrundlage, Vertraulichkeit und Information der Betroffenen sorgfältig zu beachten sind.
Schritt 4: Testfälle und Qualitätsmaßstab vorbereiten
Ein KI-Pilot ist kein freies Herumprobieren. Das Team erstellt vorab einen Testkatalog, der leichte, typische und schwierige Fälle enthält. Auch bekannte Problemfälle gehören dazu: mehrdeutige Formulierungen, veraltete Informationen, Dialekt, widersprüchliche Angaben oder Eingaben, die das System zu unzulässigen Schlüssen verleiten könnten.
Für jeden Testfall wird eine erwartete Qualität beschrieben. Bei einem Antwortentwurf können die Kriterien Faktenrichtigkeit, Vollständigkeit, verständliche Sprache, passender Ton, Quellen und Freiheit von personenbezogenen Daten sein. Eine einfache Skala von null bis zwei pro Kriterium macht Ergebnisse vergleichbar:
- 0: unbrauchbar oder riskant,
- 1: mit wesentlicher Nacharbeit nutzbar,
- 2: nach normalem Fachreview nutzbar.
Der Referenzwert entsteht aus menschlich erstellten Ergebnissen derselben Fälle. Wichtig ist nicht, ob die KI „kreativ“ wirkt, sondern ob der gesamte Prozess einschließlich Kontrolle besser wird.
Schritt 5: Den Pilot mit klaren Rollen durchführen
Ein kleiner Pilot braucht mindestens vier Verantwortlichkeiten, die in einem KMU auch von zwei Personen abgedeckt werden können:
- Pilotverantwortung: hält Umfang, Termine und Entscheidungen zusammen.
- Fachreview: bewertet Inhalte anhand der vereinbarten Kriterien.
- Tool- und Datenschutzprüfung: überwacht Konfiguration, Zugriffe und Datenweg.
- Anwendung: bearbeitet Testfälle und dokumentiert Aufwand sowie Auffälligkeiten.
Der Test läuft in einem definierten Zeitraum, zum Beispiel vier Wochen. Die Nutzerzahl bleibt klein. Niemand darf den Pilot still in einen Produktivprozess erweitern. Externe Nachrichten, Personalentscheidungen oder Vertragsfolgen werden nicht automatisch ausgelöst.
Fehlen noch gemeinsame Grundregeln, hilft der jobspot.at-Leitfaden zur KI-Richtlinie im Unternehmen. Für die tägliche Aufgabenverteilung ergänzt ihn die KI-Checkliste für Führungskräfte. Der Pilot muss diese Entscheidungen nicht neu erfinden, sondern konkret für seinen Anwendungsfall anwenden.
Vor dem Start erhalten alle Beteiligten eine kurze anwendungsbezogene Schulung. Artikel 4 des AI Act stellt bei KI-Kompetenz unter anderem auf technisches Wissen, Erfahrung und Einsatzkontext ab. Für den Pilot heißt das praktisch: Das Team kennt Grenzen des Systems, erlaubte Daten, Qualitätskriterien, Eskalationsweg und Stopprecht.
Schritt 6: Nutzen, Fehler und Arbeitsaufwand gemeinsam auswerten
Nach jedem Testfall werden wenige, aber aussagekräftige Werte erfasst:
- Zeit für Vorbereitung, KI-Nutzung und Nachkontrolle,
- Qualitätspunkte je Kriterium,
- Zahl und Art kritischer Fehler,
- Anteil vollständig verworfener Outputs,
- Rückmeldungen der Anwenderinnen und Anwender,
- Vorfälle oder Beinahe-Vorfälle bei Daten und Sicherheit.
Die Nachbearbeitungszeit ist besonders wichtig. Ein Entwurf in zehn Sekunden spart nichts, wenn ein Experte danach zwanzig Minuten für Quellen- und Faktenkorrektur braucht. Ebenso kann ein kleiner Zeitgewinn dennoch sinnvoll sein, wenn Qualität und Zugänglichkeit deutlich steigen.
Die Auswertung trennt systematische von zufälligen Fehlern. Wiederholt erfundene Quellen, Benachteiligung bestimmter Gruppen oder nicht kontrollierbare Datenabflüsse sind keine Optimierungsdetails. Sie können ein Abbruchgrund sein. Der österreichische Praxisleitfaden Digitale Verwaltung und Ethik zeigt mit Entscheidungsbaum und ethischer Checkliste, wie technische Chancen mit Transparenz, Grundrechtsschutz und menschenzentrierter Gestaltung verbunden werden können. Diese Prinzipien sind auch außerhalb der Verwaltung nützliche Prüffragen.
Schritt 7: Go, Anpassung oder Stopp entscheiden
Am Ende steht eine bewusste Entscheidung, kein schleichender Dauerpilot. Drei Ergebnisse sind möglich:
Go mit kontrolliertem Rollout
Der Pilot erfüllt Mindestqualität, Nutzen und Schutzanforderungen. Für den Rollout werden Nutzergruppen, Schulung, Support, Zugriffsrechte, Reviewrhythmus und verantwortliche Stelle festgelegt. Der produktive Prozess erhält weiterhin Qualitätskontrollen und ein Überwachungsdatum.
Anpassen und erneut testen
Der Nutzen ist erkennbar, aber einzelne Kriterien werden verfehlt. Dann wird genau eine wesentliche Variable geändert, etwa Datenvorbereitung, Promptvorlage, Modell, Fachreview oder Einsatzgrenze. Danach folgt ein neuer begrenzter Test. Werden mehrere Dinge gleichzeitig geändert, ist die Wirkung nicht mehr zuzuordnen.
Stoppen
Der Prozess wird beendet, wenn Risiken nicht beherrschbar sind, Ergebnisse unzuverlässig bleiben oder der Kontrollaufwand den Nutzen übersteigt. Ein Stopp ist kein Innovationsversagen. Er schützt Ressourcen und liefert Wissen für einen besser geeigneten Anwendungsfall.
Halten Sie die Entscheidung auf einer Seite fest: geprüfter Zweck, Testumfang, wichtigste Messwerte, erkannte Risiken, Bedingungen und verantwortliche Freigabe. Bei einem Go gehört auch dazu, welche Annahmen weiterhin gelten müssen. Wechselt etwa das Modell, der Datenweg oder die Nutzergruppe, ist die alte Freigabe nicht automatisch ausreichend. Bei einer Anpassung wird dokumentiert, welches Problem durch die Änderung gelöst werden soll. Bei einem Stopp werden Zugänge, Testdaten und temporäre Integrationen kontrolliert entfernt. So endet der Pilot technisch und organisatorisch sauber, und ein späteres Team muss dieselben Fragen nicht von vorne beantworten.
Der kompakte Vier-Wochen-Plan
Woche 1: Problem und Rahmen
Baseline messen, Zweck und Nicht-Ziele festlegen, Beteiligte bestimmen, Datenklassen prüfen und einen ersten Risikoscreen durchführen. Ergebnis ist ein freigegebenes Pilotblatt.
Woche 2: Vorbereitung
Werkzeug prüfen, sicheren Zugang konfigurieren, Testdaten vorbereiten, Bewertungsschema erstellen und das kleine Pilotteam schulen. Noch findet keine produktive Nutzung statt.
Woche 3: Kontrollierter Test
Die vorbereiteten Fälle werden bearbeitet. Zeit, Qualität, Fehler und Rückmeldungen werden unmittelbar dokumentiert. Kritische Abweichungen stoppen den Test bis zur Klärung.
Woche 4: Entscheidung
Ergebnisse mit der Baseline vergleichen, Betroffene anhören, offene Risiken bewerten und Go, Anpassung oder Stopp beschließen. Die Entscheidung enthält Verantwortliche, Bedingungen und nächsten Prüftermin.
Praxisbeispiel: Interne Stellenanzeigen prüfen
Ein österreichischer Betrieb möchte Stellenanzeigen verständlicher und inklusiver formulieren. Der Pilot soll vorhandene, bereits freigegebene Ausschreibungen auf schwer verständliche Sätze und unklare Anforderungen hinweisen. Er darf keine Bewerbungen analysieren und keine Auswahlentscheidung treffen.
Das Team misst zuerst die bisherige Bearbeitungszeit und definiert Kriterien: Fakten dürfen nicht verändert, Muss- und Kann-Anforderungen nicht vertauscht und keine neuen Leistungen versprochen werden. Zwanzig anonymisierte Anzeigen bilden den Testkatalog. HR prüft jeden Output, dokumentiert Korrekturen und vergleicht ihn mit einer menschlichen Überarbeitung.
Nach vier Wochen sinkt die reine Entwurfszeit, doch das System streicht gelegentlich fachlich notwendige Begriffe. Der Pilot wird nicht sofort ausgerollt. Stattdessen erhält er eine festere Vorlage und eine zwingende Prüfung der Anforderungslisten. Dieses Ergebnis ist wertvoll, weil es eine konkrete Schwachstelle zeigt, bevor echte Stellenanzeigen ungeprüft veröffentlicht werden.
Sieben typische Pilotfehler
- Das Team wählt ein Tool, bevor das Problem beschrieben ist.
- Der Pilot verwendet echte sensible Daten, obwohl Testdaten ausreichen würden.
- Es gibt keine Baseline und damit keinen belegbaren Nutzen.
- Nur einfache Fälle werden getestet; Grenzfälle bleiben unsichtbar.
- Nachkontrolle und Schulungszeit fehlen in der Kostenrechnung.
- Ein Testoutput löst schon produktive Entscheidungen aus.
- Der Pilot hat kein Enddatum und keine Abbruchkriterien.
Häufige Fragen zum KI-Einsatzplan
Wie groß sollte das Pilotteam sein?
So klein wie möglich und so vielfältig wie nötig. Oft reichen drei bis sechs Personen aus Fachbereich, Anwendung und Schutzfunktionen. Entscheidend sind repräsentative Fälle und klare Rollen, nicht eine große Teilnehmerzahl.
Kann ein Pilot mit einem kostenlosen Tool starten?
Nur wenn Vertrag, Datenverarbeitung und geplanter Zweck passen. Für öffentliche, künstlich erzeugte Testdaten kann das möglich sein. Vertrauliche oder personenbezogene Informationen gehören nicht automatisch in ein kostenloses Angebot.
Wann ist eine KI-Anwendung hochriskant?
Das lässt sich nicht allein aus dem Produktnamen ableiten. Zweck, Einsatzmodalitäten und die im AI Act genannten Bereiche sind entscheidend. Die RTR bietet dazu Übersichten; bei Unsicherheit sollte der konkrete Fall qualifiziert geprüft werden.
Was bleibt nach einem erfolgreichen Pilot?
Ein produktiver Einsatzplan mit Verantwortlichen, freigegebenem Zweck, Schulung, Datenregeln, Qualitätsgates, Support, Vorfallsweg und Reviewtermin. Ein Pilotbericht allein ist noch kein sicherer Betrieb.
Fazit: Erst belegen, dann skalieren
Ein guter KI-Einsatzplan hält den Test klein und die Entscheidung groß. Er verbindet ein echtes Arbeitsproblem mit Baseline, Risikoscreen, sicheren Daten, repräsentativen Testfällen und messbarer Qualität. Dadurch sieht ein Team nicht nur, was das Werkzeug erzeugt, sondern ob der gesamte Arbeitsablauf besser und verantwortbar wird.
Wählen Sie für den Start eine häufige, klar abgrenzbare Aufgabe ohne automatische Folgen für Menschen. Messen Sie zehn Fälle im heutigen Prozess und definieren Sie danach Erfolg sowie Abbruch. Dieser erste Schritt ist unspektakulär, aber er trennt einen belastbaren Pilot von einer teuren Produktdemo.
