Das Problem ist selten das fehlende Tool. Es ist die fehlende Aufgabenklarheit davor.

Arbeitslogik vor Tool-Logo

Im Buch „Smarter Arbeiten mit KI“ haben Sie das Prinzip kennengelernt: Erst den Vorgang klären, dann das Werkzeug wählen. Dieser Bonus-Artikel übersetzt das Prinzip in einen konkreten Entscheidungsbaum für die Tools, die 2025/2026 in der Praxis dominieren: ChatGPT, Claude, Gemini, Microsoft Copilot und Code-Assistenten.

Drei Fragen klären 80 Prozent aller Toolentscheidungen — bevor Sie einen einzigen Tab öffnen.

Die drei Fragen vor dem ersten Klick

1. Was muss am Ende vorliegen?

Ein Entwurf, eine Tabelle, eine Entscheidungsvorlage, ein Code-Snippet? Ohne konkreten Output ist jedes Tool Spielerei. Schreiben Sie den Satz: „Am Ende liegt vor: …“

2. Welche Daten sind beteiligt?

Geht es um interne Strategie, Kundennamen, Verträge — oder um öffentlich zugängliche Inhalte? Diese Antwort bestimmt, ob ein Consumer-Chat, ein Enterprise-Tenant oder gar kein Cloud-Modell infrage kommt. Compliance ist kein Bremsklotz. Es ist der Filter vor dem ersten Prompt.

3. Wie oft kommt diese Aufgabe vor?

Einmal im Quartal? Ein guter Prompt reicht. Täglich, immer gleich? Dann lohnt ein Workflow, ein Custom GPT oder ein Claude Project — mit Review-Pflicht.

Der Montagmorgen-Test: Können Sie die Aufgabe in zwei Sätzen erklären, ohne ein Markenname zu nennen? Wenn nicht, ist das Problem noch nicht reif für die Toolwahl.

Tool-Klassen statt Marken-Duell

Statt Logos zu vergleichen, hilft eine einfache Einteilung in drei Klassen:

• Allzweck-Assistenten (ChatGPT, Claude, Gemini im Browser): Formulieren, Strukturieren, Varianten erstellen, Erklären — wenn Datenlage und Policy es erlauben.
• Eingebettete Assistenten (Microsoft Copilot in M365, Gemini in Google Workspace): Gewinnen, wenn Quelle und Ablage im gleichen Ökosystem liegen. Weniger Copy-Paste, mehr Kontext aus Dateien — sofern Governance stimmt.
• Spezial- und Code-Assistenten (GitHub Copilot, Cursor, Codex): Lohnen bei wiederkehrenden technischen oder datenlastigen Schritten. Nicht für jede E-Mail.

Praxisregel: Maximal zwei Allzweck-Kanäle pro Rolle. Ein eingebetteter Kanal, wenn der Arbeitgeber ihn vorgibt. Alles andere nur mit Pilot-Freigabe.

Wer die Klasse für einen Vorgang kennt, trifft Montagmorgen schneller die richtige Wahl — ohne neue Schulung bei jedem Modellwechsel.

Der Entscheidungsbaum im Überblick

Folgen Sie diesen Schritten für jede neue Aufgabe:

• Aufgabe und Output klar? Nein → Briefing schreiben, kein Tool öffnen. Ja → weiter.
• Personenbezogene oder vertrauliche Daten? Ja → nur freigegebener Enterprise-Kanal oder gar nicht. Nein → weiter.
• Wo liegt die Quelle? M365 / SharePoint → Microsoft Copilot prüfen. Google Workspace → Gemini eingebettet prüfen. Lose Dateien / Web → Allzweck nach Policy.
• Art der Arbeit? Formulieren, Struktur, Varianten → Allzweck-Assistent. Lange PDFs, viele Quellen → Modell mit großem Kontext. Tabellen, wiederkehrende Transformationen → Code-Assistent. Mehrere Schritte ohne Mensch → Agent nur mit Review-Gates und Stopp-Regel.
• Tägliche Wiederholung? Ja → Workflow oder Custom GPT. Nein → ein guter Prompt reicht.

Vom Baum zur Routine

Wählen Sie eine Aufgabe pro Woche aus, die der Baum lösen soll. „Meeting-Protokoll aus Stichpunkten“ ist ein Use Case. „KI allgemein nutzen“ ist keiner.

Messen Sie vor dem Einsatz: Wie viele Minuten oder Rückfragen kostet diese Aufgabe heute? Nach zwei Wochen vergleichen. Ohne Zahl bleibt Toolwahl Meinung.

Alle vier Wochen ein kurzer Review: Welcher Ast des Baums wurde nie genutzt? Streichen Sie Lizenzen, die niemand braucht.

Neue Modelle erscheinen monatlich. Ihr Baum bleibt stabil, wenn er Aufgabenarten beschreibt — nicht Versionsnummern.

Buchbezug und nächster Schritt

Im Buch haben Sie gelernt, wie Prompts strukturiert werden. Dieser Baum ist die Schicht davor: Er klärt, welches Tool den Prompt überhaupt bekommen soll. Führen Sie eine echte Aufgabe aus der letzten Woche durch den Baum — und notieren Sie Output, Risiko und Wiederholung je in einem Satz. Das ist der Kalenderanker für Ihre persönliche Tool-Policy.

Weiterführende Quellen

• OpenAI — ChatGPT Produktübersicht und Enterprise-Optionen
• Anthropic — Claude: Fähigkeiten und Sicherheitsrahmen
• Google Workspace — Gemini für Unternehmen (Deutsch)

Dieser Praxisvergleich setzt voraus, dass Sie das Buch bereits gelesen haben und die Grundlogik kennen: Prompt-Qualität schlägt Tool-Qualität fast immer. Trotzdem ist die Frage berechtigt, wo die drei großen Allzweck-Assistenten wirklich unterschiedlich stark sind.

Fair testen: gleiche Aufgabe, drei Fenster

Ein Tool-Vergleich ist nur fair, wenn alle drei dasselbe Briefing bekommen. Schreiben Sie vor dem Test: Rolle, Zielgruppe, Länge, Tabu-Wörter, ein Beispielsatz. Identisch in alle drei Tools kopieren.

Bewerten Sie den Output anhand messbarer Kriterien: Review-Zeit in Minuten, Anzahl der Korrekturen, Rückfragen im Team. Nicht anhand von „klingt irgendwie besser“.

Wichtig: Notieren Sie Datum und Modellversion. Modelle ändern sich schnell. Ohne Datum ziehen Sie später falsche Schlüsse.

Ein holpriger Entwurf, der schnell zu korrigieren ist, kann besser sein als glatter Text mit versteckten Faktenfehlern — besonders bei Zahlen und Namen.

ChatGPT: Breite, Custom GPTs, Integration

ChatGPT bleibt für viele Teams der Standard-Einstieg: schnelle Varianten, Erklärungen, Brainstorming. Custom GPTs lohnen, wenn ein Team dieselbe Vorlage, denselben Ton und dieselben Quell-Regeln immer wieder braucht.

Stärke: das Ökosystem. Kollegen finden leichter Hilfe, wenn ein Standard-Tool etabliert ist.

Schwäche: ohne Quellenpflicht halluziniert auch das beste Modell bei Nischenfakten. Bei Verträgen und Kennzahlen gilt unverändert: menschliche Endkontrolle.

Praktische Regel: ChatGPT dort einsetzen, wo der Vorgang lose Dateien, Web-Recherche oder plattformübergreifende Texte betrifft — und Policy es erlaubt. Für M365-lastige Organisationen konkurriert ChatGPT direkt mit Copilot. Entscheidung: pro Datenquelle, nicht pro Sympathie.

Claude: Lange Dokumente, Tonfall, Projects

Claude überzeugt viele Teams bei langen Eingaben und sorgfältiger Formulierung. Claude Projects sind Arbeitsbereiche mit Dateien, Stilregeln und wiederkehrenden Anweisungen — vergleichbar mit Custom GPTs, aber mit eigenem Kontext- und Dateimodell. Vor dem Einsatz: Tenant und Datenverarbeitungsvertrag prüfen.

Besonders geeignet für: Policy-Texte, sensible interne Memos, Situationen, wo ein falscher Ton teurer ist als eine schlechte Marketing-Überschrift.

Projects lösen das „immer wieder dasselbe Briefing eingeben“-Problem — wenn der Datenweg genehmigt ist.

Gemini: Google Workspace, Kontext, Long Context

Gemini gewinnt, wenn Kalender, Docs und Mail bereits in Google Workspace liegen. Weniger Copy-Paste, mehr Dateikontext — sofern die Admin-Einstellungen stimmen.

Gemini Advanced und große Kontextfenster helfen bei umfangreichen PDF-Sammlungen. Trotzdem gilt: Quellenangaben lesen, Stichproben ziehen, nicht blind übernehmen. Ein Modell, das viel lesen kann, erfindet nicht seltener — es schreibt nur überzeugender.

Wenn Ihr Unternehmen nur eine Cloud erlaubt, ist der Vergleich theoretisch. Dann lohnt es mehr, den genehmigten Kanal zu optimieren als drei parallele Abos zu verwalten.

Vergleichstabelle für den Arbeitsalltag

Entscheidung ohne Feature-Jagd

Das Ergebnis eines echten Vergleichs ist eine Tabelle: Use Case, Gewinner, Review-Regel, Stopp-Kriterium. Kein Slide mit Logos.

Teilen Sie im Team: „Für Protokolle nutzen wir X, für Angebotsentwürfe Y.“ Maximal zwei Allzweck-Tools, nicht fünf.

Schulen Sie nicht auf Tastenkürzel, sondern auf Briefing-Qualität und Review. Das skaliert über Modellwechsel hinweg. Wer das versteht, überlebt Vendor-Updates ohne Panik — und spart Abos, die nur in der Demo glänzten.

Buchbezug und nächster Schritt

Das Buch hat Ihnen gezeigt, wie gute Prompts strukturiert sind. Dieser Vergleich hilft Ihnen zu entscheiden, welchem Tool Ihr nächster Prompt gehört. Wählen Sie diese Woche einen konkreten Use Case aus Ihrem Alltag. Schreiben Sie ein Briefing. Testen Sie es in zwei Tools mit identischem Text. Notieren Sie Review-Zeit und Korrekturen — dann haben Sie eine ehrliche Grundlage, keine Bauchgefühl-Entscheidung.

Weiterführende Quellen

• Anthropic — Offizielle Modell-Updates und Fähigkeitsbeschreibungen
• OpenAI Enterprise — Datenschutz- und Compliance-Informationen
• Google Workspace Gemini — Einbettung in bestehende Workflows

Für Wissensarbeiter ohne Entwicklerrolle ist das verlockend — und riskant zugleich. Wann lohnt sich der Einstieg wirklich?

Die Grundregel: Wiederholung schlägt Neugier

Code-Assistenten lohnen, wenn ein Schritt wiederkehrt, messbar ist und das Review klarer ist als das manuelle Klicken. Nicht, wenn Sie „mal schauen, was KI mit meinen Daten macht“.

Im Buch haben Sie gelernt, zwischen Prompt und Workflow zu unterscheiden. Code-Assistenten sind ein Schritt weiter: Sie bauen einen Workflow, der ohne Sie läuft. Das erhöht den Nutzen — und die Fehlerfläche.

Sinnvoller Einsatz: wöchentlich gleicher CSV-Import, gleiche Spaltenoperation, gleiches PDF-Muster auswerten. Aufwand über zehn Minuten, Implementierung unter einem Tag.

Nicht sinnvoll: eine Formatierung, die Sie in zwei Minuten per Hand erledigen. Der Assistent kostet mehr Zeit als der Klick.

Harte Grenze: Sobald Skripte in ERP, CRM oder Buchhaltung schreiben, sind IT und Change-Management Pflicht — nicht optional.

Der Montagmorgen-Test für Code-Piloten

Können Sie den Vorgang in zwei Sätzen erklären, ohne technische Begriffe? Wenn ja, können Sie ihn auch im Prompt beschreiben. Wenn nicht, wird das Skript zur Blackbox — und Blackboxen in Kennzahlen sind teurer als manuelles Klicken.

Zweiter Test: Kann ein Kollege das Skript mit einer anderen Beispieldatei ausführen und das Ergebnis erklären — ohne Sie anzurufen? Wenn nicht, ist das Wissen gefangen. Das ist ein Risiko beim Urlaub, nicht nur ein Komfortproblem.

Dokumentieren Sie Eingabe, Ausgabe und mögliche Fehlerfälle in drei Sätzen. Das reicht für den Teamtransfer.

Risiken, die Nicht-Entwickler unterschätzen

Stille Fehler in Zeile 47

Code-Assistenten optimieren auf „läuft einmal durch“ — nicht auf Ihre Sonderfälle in der letzten Zeile. Stichproben lesen, Summen prüfen, Randfälle testen. Ein Satz im Briefing wie „Sonderfall: leere Zeilen und Nullwerte als Flag setzen, nicht löschen“ spart Stunden Korrekturen im Nachgang.

Personenbezogene Daten in Code-Kontexten

Firmen-Codex-Tenant und interne Richtlinien lesen, bevor Skripte auf echten Daten laufen. Private Repositories mit Kundendaten sind ein Compliance-Thema — auch wenn das Tool clever ist.

Bibliotheksversionen und Umgebungen

„Bei mir hat es funktioniert“ hilft dem Team nicht, wenn pandas- oder openpyxl-Versionen abweichen. Eine requirements.txt oder eine klare Laufumgebungsbeschreibung gehört zur Übergabe.

Rollback vor dem ersten Lauf

Originaldatei unangetastet lassen. Output in neuem Ordner ablegen. Nie inplace ohne Backup. Das ist keine Vorsichtsmaßnahme für Anfänger — das ist die Bedingung für jeden Pilot.

Codex vs. GitHub Copilot: zwei Wege, eine Disziplin

Codex (OpenAI) adressiert zunehmend agentenartige Code-Aufgaben in Repositories — für Analysten oft über Browser oder IDE-Plugin, wenn IT-seitig freigegeben.

GitHub Copilot sitzt nah an Commit und Pull Request — stark, wenn das Team ohnehin Git nutzt. Für reine Excel-Nutzer oft zu viel Infrastruktur.

Für beide gilt: Starten Sie mit „liest CSV, schreibt bereinigtes CSV“ — nicht mit „baut mir ein Dashboard“. Kommentieren Sie im Prompt Geschäftsregeln explizit: „Umsatz netto, Spalte D, negative Werte als Flag markieren, nicht löschen.“

Erfolgreiche Prompts gehören in eine Workflow-Notiz: Version, Owner, Änderungsgrund. Sonst stirbt das Wissen, wenn eine Person kündigt.

Übergabe und Betrieb

Ein Pilot ohne Betriebsplan ist ein Einzeltrick. Vier Felder auf einer Karte reichen:

• Owner: Wer pflegt das Skript, wenn sich das CRM-Feld ändert?
• Frequenz: Wöchentlich, täglich, bei Bedarf?
• Stopp-Kriterium: Wenn der wöchentliche Gewinn unter fünf Minuten fällt — abschalten.
• Logbuch: Datum, Eingabedatei, Auffälligkeiten — für Audit und für das zukünftige Ich.

Schulung in 30 Minuten: Ablauf zeigen, nicht Python lehren. Ziel ist Bedienung und Prüfung — kein Programmier-Kurs.

Manchmal ist Power Query oder ein Export-Profil die ehrlichere Lösung. Das ist kein Scheitern. Das ist Arbeitslogik vor Tool.

Buchbezug und nächster Schritt

Das Buch hat Ihnen gezeigt, wie Sie Routinen mit KI aufbauen. Code-Assistenten sind eine Verlängerung davon — für strukturierte, wiederholbare Datenschritte. Identifizieren Sie diese Woche eine Tabellenaufgabe, die mindestens wöchentlich anfällt. Messen Sie den aktuellen Aufwand. Dann starten Sie einen Pilot — ausschließlich auf einer Kopie, mit dokumentiertem Briefing und einer Stichproben-Prüfung als Abnahmekriterium.

Weiterführende Quellen

• GitHub Copilot — offizielle Dokumentation für Einstieg und Compliance
• OpenAI Platform — Code-Generierung: Möglichkeiten und Grenzen
• BSI — KI im Unternehmenseinsatz: Empfehlungen für sichere Nutzung

Agenten sind keine magischen Mitarbeiter. Sie sind mehrstufige Automatisierung mit höherem Schadenspotenzial als ein einzelner Prompt.

Was Agenten wirklich tun

Ein Agent plant Teilaufgaben, ruft Tools auf, liest Dateien, klickt Oberflächen — je nach Produkt. Jeder zusätzliche Schritt kann falsch abbiegen, ohne dass Sie es sofort sehen.

Die Cowork-Metapher hilft bei der Kommunikation im Team. Bei der Haftung nicht: Sie bleiben verantwortlich für Versand, Zahlen und personenbezogene Daten — auch wenn ein Modell geklickt hat.

Vergleichen Sie Agenten mit Makro plus Checkliste — nicht mit einem menschlichen Projektmitglied. Jeder zusätzliche autonome Schritt verdoppelt nicht nur das Tempo, sondern auch die Fehlerfläche.

Der Montagmorgen-Test: Können Sie jeden Zwischenschritt erklären, bevor etwas nach außen geht? Wenn nicht, fehlt ein Gate.

Vier Pflichtfelder vor jedem Agenten-Einsatz

Planen Sie Agenten wie ein Mini-Projekt. Diese vier Punkte schriftlich festhalten — bevor der erste Lauf startet:

• Startbedingungen: Welche Eingabe, welche Quelle, welcher Zeitpunkt?
• Erlaubte Aktionen: Nur lesen, oder auch schreiben? Kein Mail-Versand ohne explizite Freigabe.
• Verbotene Aktionen: Löschen, Preisänderungen, Vertragsversand — alle ohne IT-Freigabe gesperrt.
• Abbruchkriterium: Was stoppt den Agenten? Maximale Laufzeit, maximale Dateianzahl, oder ein bestimmtes Ergebnis?

Zwischenergebnisse müssen sichtbar sein — nicht nur der Endoutput. Wer den Pfad nicht sieht, kann nicht korrigieren.

Sinnvolle Einsätze im Teamalltag

Wo Agenten funktionieren:

• Recherche in öffentlichen Quellen mit Quellenliste als Output
• Entwürfe aus vordefinierten Templates nach nummerierter Checkliste
• Abarbeiten eines definierten Workflows in einer Testumgebung

Wo Sie vorsichtig sein sollten:

• Kalender managen, Mails beantworten, CRM pflegen — hoher Schaden bei Fehlklick, oft besser halbautomatisch.

Wo Agenten ohne IT-Freigabe nichts verloren haben:

• Zugriff auf Produktivsysteme, Löschen, Preisänderungen, Vertragsversand

Teamregel: ein Pilot-Agent pro Quartal, ein Owner, ein Review-Termin. Nicht zehn Bastelagenten parallel.

Review-Design: drei Gates als Minimum

Für jeden Agenten-Einsatz gilt dasselbe Review-Schema wie für einen Junior-Mitarbeiter — weil das Modell ebenfalls auf Junior-Niveau Fehler macht:

• Gate 1 nach Plan: Stimmt die Aufgabenteilung? Ist das Briefing vollständig?
• Gate 2 nach Recherche: Stimmen die Quellen? Sind Halluzinationen erkennbar?
• Gate 3 vor Output: Ton, Zahlen, Namen — alles geprüft?

Zeitbox einplanen: 25 Minuten Agent, 10 Minuten Mensch. Verhindert das endlose „noch mal versuchen“.

Wenn der Output zu glatt ist: gezielt nach Quellen und Unsicherheiten fragen. Halluzination liebt Selbstsicherheit.

Abbrüche dokumentieren: Warum gestoppt? Was fehlte im Briefing? Das verbessert den nächsten Lauf mehr als ein neues Modell.

Skalierung: vom Pilot zur SOP

Erfolgreiche Agenten werden zu Standardarbeitsanweisungen: Briefing-Vorlage, erlaubte Tools, verbotene Daten, Beispiel-Output — eine Seite.

KPI formulieren: nicht „Agent lief X Mal“, sondern eingesparte Minuten minus Review-Minuten. Das ist die ehrliche Rechnung.

Stop-Kriterium: Zwei kritische Fehler → Agent pausieren, Briefing überarbeiten. Keine Ausnahmen.

Skeptiker im Team gewinnen Sie mit einem sicheren, begrenzten Use Case — nicht mit der spektakulärsten Demo. Montagmessbarkeit schlägt Hype im Quartalsreview.

Buchbezug und nächster Schritt

Im Buch haben Sie Prompt-Routinen aufgebaut. Agenten sind die nächste Stufe — aber nur dort, wo Ihr Prompt täglich gleich läuft und die Fehlerfolgen begrenzt sind. Definieren Sie diese Woche einen begrenzten Agenten-Use-Case: Sandbox, Leserechte, drei Gates schriftlich. Nach fünf Läufen: KPI und Fehlerbild dokumentieren. Dann entscheiden, ob skaliert oder gestoppt wird.

Weiterführende Quellen

• Anthropic — Aktuelle Informationen zu Claude-Agenten und Sicherheitsrahmen
• Microsoft Learn — Microsoft 365 Copilot: Governance und Rollout-Leitfaden
• BSI — Empfehlungen für den sicheren Einsatz von KI-Systemen in Unternehmen

Dieser Artikel ist keine Lizenz-Werbung. Er liefert zwölf konkrete Prüfpunkte für IT, Führung und Fachbereich — mit dem Ziel, Copilot montagsmessbar zu machen.

Was Copilot wirklich tut — und was nicht

Copilot liest, was der Nutzer lesen darf. Falsche Berechtigungen werden durch Copilot sichtbarer — nicht kleiner. Wer Ordner mit „Jeder darf alles“ hat, entdeckt das spätestens beim Pilot. Aufräumen ist günstiger vor dem Rollout als danach.

Copilot verstärkt vorhandene Datenhygiene. Es ersetzt sie nicht.

Datenlage und Berechtigungen: vor dem ersten Prompt

Prüfen Sie SharePoint- und Teams-Berechtigungen, bevor der Pilot startet. Sensitive Labels, DLP und Conditional Access sind Voraussetzungen — keine Folgeprojekte.

EU-Datenresidenz und Tenant-Region dokumentieren. Die Führungsebene fragt danach, bevor sie Lizenzen freigibt — bereiten Sie den einen klärenden Satz vor.

Testfrage für das Pilot-Team: Wenn Copilot jetzt alle SharePoint-Ordner durchsucht — würde dabei etwas auftauchen, das niemand mehr finden wollte? Das ist kein KI-Problem. Das ist ein Berechtigungsproblem, das die KI sichtbar macht.

IT und Fachbereich teilen eine gemeinsame Checkliste vor dem ersten Prompt: Berechtigung, Label, Scope, Review-Person.

Use Cases in M365: wo Copilot wirklich hilft

• Teams: Meeting-Zusammenfassung mit Action Items — wenn Aufzeichnung und Policy erlaubt sind.
• Outlook: Entwurf aus Thread-Kontext — Review vor dem Senden, besonders bei externen Empfängern.
• Word / PowerPoint: Struktur und Kürzen — keine Fakten aus dem Nichts für regulierte Texte.
• Excel: Formeln erklären und Entwürfe erstellen — Zahlen immer gegen die Originalquelle prüfen.

Copilot Studio und Agenten nur mit Naming, Owner und Stopp-Kriterium — sonst entsteht Wildwuchs in der eigenen Tenant.

Vergleichen Sie Copilot nicht mit „dem besten Modell“, sondern mit „weniger Reibung am bestehenden Ablageort“. Wenn die Quelle außerhalb von M365 liegt, ist ein Allzweck-Assistent mit Daten-Gate oft ehrlicher.

Outlook-Entwürfe brauchen eine explizite Regel: keine Verbindlichkeit ohne menschliche Freigabe. Im Briefing und in der Schulung.

Governance: Rollen und Verantwortlichkeiten

Drei Rollen, eine klare Aufgabe:

• IT: Tenant-Einstellungen, Logging, erlaubte Plugins, Ausschluss sensibler Sites.
• Führung: Ein Kommunikationssatz — wofür ja, wofür nein. Kein „nutzt mal alles“.
• Fachbereich: Briefing-Standards und Review. Qualität kommt aus dem Vorgang, nicht aus dem Modell.

Champions pro Abteilung: maximal zwei. Nicht zwanzig unkoordinierte KI-Enthusiasten, die unterschiedliche Schatten-Tools zeigen.

Champions sind keine Lizenz-Verkäufer. Sie moderieren Briefing-Qualität und Review — mit Review-Pflicht und KPI, nicht mit Begeisterung.

Monatlicher Review: Tickets, Fehlmail, Zeitersparnis. Nicht Login-Zahlen. Wer nur Klicks misst, kauft Lizenzen für Gewohnheit — nicht für Vorgangswert.

Die zwölf Checkpunkte

• 1 — Berechtigungen bereinigt
• 2 — Labels / DLP aktiv
• 3 — EU-Region dokumentiert
• 4 — Pilot-Use-Case benannt
• 5 — Review vor externem Versand
• 6 — Meeting-Aufzeichnung policy-konform
• 7 — Excel-Zahlen stichprobenartig geprüft
• 8 — Keine Kundendaten parallel in Consumer-Tools
• 9 — Agenten benannt und begrenzt
• 10 — Logging mit IT abgestimmt
• 11 — KPI: Zeit oder Fehlerquote, nicht Klicks
• 12 — Stopp nach 90 Tagen ohne messbaren Nutzen

Kommunizieren Sie diese Liste als eine Seite — kein 40-Seiten-Konzept. Montagmorgen: Kann die Führung einen Live-Use-Case zeigen, nicht nur eine Folie?

Nach 90 Tagen ohne messbaren Nutzen: Lizenzen prüfen, nicht mehr Features kaufen.

Buchbezug und nächster Schritt

Das Buch hat Ihnen gezeigt, wie Routinen mit KI entstehen. Copilot ist der eingebettete Kanal für Teams, die bereits in M365 arbeiten. Definieren Sie diese Woche einen Pilot-Use-Case mit einem Pilot-Team: Berechtigungen prüfen, KPI festlegen, Review-Person benennen. Nach 90 Tagen entscheiden — skalieren, anpassen oder Lizenzen reduzieren. Das ist der Unterschied zwischen Betrieb und Dauerpilot.

Weiterführende Quellen

• Microsoft Learn — Microsoft 365 Copilot: Überblick und Rollout-Leitfaden (Deutsch)
• Microsoft Purview — DLP und Datenschutz in M365 (Deutsch)
• BfDI — Künstliche Intelligenz und Datenschutz: Behördliche Orientierungshilfe

Im Buch haben Sie gelernt: Arbeitslogik vor Tool. Diese Regel entscheidet auch hier. Nicht jede KI-Aufgabe braucht einen Workflow. Aber wer nur einzelne Prompts sammelt, skaliert nie über sich selbst hinaus.

Der Montagmorgen-Test

Stellen Sie sich eine konkrete Frage: Werden Sie dieselbe Aufgabe in drei Wochen erneut erledigen — mit demselben Briefing und ähnlichem Input? Wenn ja, ist Standardisierung prüfenswert. Wenn nein, reicht ein guter Prompt.

Ein Angebotsentwurf für einen Stammkunden mit fester Struktur: Workflow-Kandidat. Eine Ideen-Runde für die nächste Kampagne mit wechselnden Rahmenbedingungen: Prompt reicht — und ein guter reicht besser als ein schlechter Workflow.

Wann der Prompt die richtige Wahl ist

Prompts sind stark bei seltenen, kreativen oder stark kontextabhängigen Aufgaben. Brainstorming, ungewöhnliche Einwände im Kundengespräch, eine einmalige Jahrespräsentation — hier kostet Standardisierung mehr, als sie bringt.

Qualität kommt aus dem Briefing, nicht aus dem Modell. Rolle, Ziel, Format, ein Negativbeispiel und Länge — fünf Zeilen, klar formuliert. Das schlägt jedes teure Modell mit vagem Input.

Speichern Sie bewährte Prompts in einer persönlichen Snippet-Sammlung. Aber: Prompts ohne regelmäßigen Review werden toxisch. Ein veralteter Ton in Kundenmails kostet mehr als gar kein Prompt. Einmal pro Monat die fünf meistgenutzten Snippets prüfen — noch korrekt? Noch erlaubt?

Wenn zwei Kollegen denselben Prompt dreimal nachfragen: Das ist kein Zeichen für Hilfsbereitschaft. Das ist das Signal für einen Workflow.

Wann ein Workflow lohnt

Workflows lohnen, wenn drei Bedingungen gleichzeitig erfüllt sind: Wiederholung (täglich oder wöchentlich), mehrere Ausführende, und ein klar definiertes Output-Format. Protokoll aus Meeting-Notizen, Ticket-Zusammenfassungen, strukturierte Angebotsvorlagen — das sind Workflow-Kandidaten.

Welches Werkzeug? Custom GPTs oder Claude Projects, wenn Stil, Checklisten und Firmendateien hinterlegt werden sollen. Power Automate oder Zapier, wenn der Trigger in M365 oder Google liegt — also Mail, Liste oder Teams-Kanal. Skripte über Codex, wenn Datenschritte dominieren.

Jeder Workflow braucht drei Dinge: einen Owner, eine Versionsnummer und ein Review-Datum. Ohne diese drei Angaben ist kein Workflow ein Betrieb — es ist eine Demo, die mit dem Urlaub ihres Erstellers stirbt.

Starten Sie klein: ein Schritt automatisiert, der Rest menschlich. Ein klarer KPI: zum Beispiel Minuten bis zum versandfertigen Protokoll. Dann messen, dann skalieren.

Die Grenze zum Agenten

Agenten sind Workflows mit mehr Entscheidungsspielraum — und entsprechend mehr Risiko. Die Regel ist einfach: erst Workflow fünf Mal ohne Korrektur stabil, dann Agenten-Schritt erwägen. Nicht umgekehrt.

Wer Agenten auf instabile Prozesse setzt, kauft sich schnellere Fehler, nicht schnellere Arbeit. Jeder autonome Schritt braucht einen definierten Stopp und einen dokumentierten Rollback — besonders bei Kundenkontakt.

Wenn Ihr Workflow häufig abbricht, ist das Briefing zu breit. Schneiden ist die Lösung — nicht ein Agent draufsetzen.

Entscheidung auf einer Seite

Dokumentieren Sie für jede wiederkehrende Aufgabe: Was ist die Aufgabe? Wie häufig? Prompt oder Workflow — und warum? Welches Tool? Welcher KPI? Wann ist der nächste Review?

Eine Seite im Team-Wiki, geteilt als „Betriebsanweisung KI“. Alle vier Wochen: noch gültig? Modell gewechselt? Policy neu? Workflows ohne messbaren Nutzen abschalten — Wartung frisst Glaubwürdigkeit schneller als jede schlechte Präsentation.

Der Test für gute Dokumentation: Kann ein Vertretungskollege den Ablauf aus dieser einen Seite ausführen — am Montagmorgen, ohne Rückfragen? Wenn nicht, ist es Heldenwissen, kein Betrieb.

Das Buch gibt Ihnen die Werkzeuge. Dieser Artikel gibt Ihnen die Entscheidungsregel: Einmalig und kreativ? Prompt. Wiederkehrend und im Team? Workflow. Noch nicht fünf Mal stabil? Kein Agent.

Weiterführende Quellen

• OpenAI — Prompt Engineering Guide (EN)
• Make — Workflow Automation Guide (EN)
• Microsoft — Erste Schritte mit Power Automate (DE)

Das Buch gibt Ihnen das Prinzip: Arbeitslogik vor Tool. Dieser Artikel gibt Ihnen das Werkzeug dazu — eine Use-Case-Karte für die vier Kernbereiche der Wissensarbeit: Dokumente, Meetings, Recherche und Kommunikation.

Die Karte beantwortet nicht „Was ist alles möglich?“ Sie beantwortet: „Was machen wir Montag — wofür?“

Dokumente und Texte

Typische Aufgaben: Memos, Angebote, Protokolle, Präsentations-Storylines. Der Output ist Text mit klarer Struktur — kein Faktenabruf ohne Quellangabe.

Risiko: mittel bis hoch bei Verträgen, HR-Dokumenten oder Angeboten mit Preiszusagen. Hier gilt: Enterprise-Kanal und Vier-Augen-Prinzip — keine Ausnahme, auch wenn der Entwurf überzeugend klingt.

Wichtigste Regel für Texte: KI formuliert, Mensch liefert die Fakten mit Quelle. Ein falsch automatisch generierter Preis in einem Kundenangebot kostet mehr als zehn Minuten länger manuell schreiben. Review vor Versand ist kein bürokratischer Zusatzschritt — er ist der eigentliche Wert.

KPI-Beispiel: Minuten bis zum versandfertigen Entwurf. Oder: Anzahl Rückfragen im internen Review. Beides ist messbar, beides zeigt, ob KI wirklich hilft.

Meetings und Zusammenarbeit

Typisch: Teams- oder Zoom-Notizen zu Protokoll, Action Items und Follow-up-Mail. Das Ziel: Protokoll in 15 Minuten statt 45 — messbar, nicht gefühlt.

Risiko: Meeting-Zusammenfassungen berühren personenbezogene Gesprächsinhalte. Das braucht zwei getrennte Freigaben: Aufzeichnungsrecht und KI-Policy. Nicht eine, nicht „die gilt doch sowieso“ — zwei explizite Haken.

Tool-Klasse: Copilot in Teams bei M365-Umgebung. Sonst: Allzweck-Modell mit anonymisierten Stichpunkten — niemals heimlich Transkripte in einem Consumer-Account verarbeiten.

Protokoll-Review rotierend verteilen. Wer immer dieselbe Person prüft, baut Abhängigkeit — nicht Betrieb. KI-Protokolle scheitern meistens nicht am Stil, sondern an falschen Action Items. Vergleichen Sie KI-Output immer mit der Beschlussliste, nicht mit sprachlicher Schönheit.

Recherche und Analyse

Typisch: Marktüberblick, Vergleichsoptionen, Zusammenfassung langer PDFs, technische Erklärungen. Das Risiko: erfundene Quellen, veraltete Daten, Selbstsicherheit durch Menge.

Regel ohne Ausnahme: Jede Kernaussage bekommt einen Link — oder sie wird gestrichen. Keine Zahlen aus dem Chat ohne Gegenprüfung. Große PDF-Mengen verführen zu Selbstsicherheit, die ein Modell mit „Research“ im Namen nicht deckt. Stichprobe lesen bleibt Pflicht.

Nützliches Format für Recherche-Output: Tabelle mit vier Spalten — Behauptung, Quelle, Datum, Vertrauen. Vom Modell generieren, vom Menschen prüfen. Struktur zwingt zu Ehrlichkeit; Fließtext versteckt Lücken.

Interne Recherche nur im freigegebenen Tenant. „Kurz in Consumer“ ist kein Shortcut — es ist ein Datenrisiko. Ein Satz in der Karte für das gesamte Team genügt.

Die Karte pflegen

Hängen Sie die Karte dort, wo das Weekly stattfindet — digital oder physisch. Sie ist kein Poster. Sie ist ein Steuerungsmittel. Ohne regelmäßiges Update veraltet sie zur Legende.

Neue Zeile hinzufügen: erst nach einem 14-Tage-Pilot mit einer messbaren Zahl. Ungenutzte Tool-Spalten streichen. Alle sechs Wochen eine Policy-Zeile aktualisieren — nicht die ganze Karte neu erfinden.

Leere Zeile mit Vermerk „noch nicht geprüft“ ist ehrlicher als ein Tool-Logo aus einer Demo-Begeisterung. Neue Kollegen tragen in Woche eins eine echte Kartenzeile mit Zahl ein — das ist praxistauglicher als jeder Workshop ohne Folgeaktion.

Übersicht: Use-Case-Karte

Protokoll aus Meeting-Notizen — Risiko: Mittel (PII, Ton) — Tool: Copilot Teams oder Allzweck — Review: Beschlüsse und Action Items — KPI: Minuten bis Versand

Angebotsentwurf — Risiko: Hoch (Kunde, Preis) — Tool: Allzweck oder M365 — Review: Zahlen und Verbindlichkeit — KPI: Rückfragen im Team

Marktrecherche extern — Risiko: Mittel (Quellen) — Tool: Research-Modus oder Gemini — Review: Links und Datum — KPI: Zeit bis Einseiter

Präsentationsstruktur — Risiko: Niedrig — Tool: Allzweck — Review: Story und Zielgruppe — KPI: Iterationen bis Freigabe

Wählen Sie aus dem Buch drei Use Cases, die Sie im letzten Monat tatsächlich bearbeitet haben. Tragen Sie Risiko, Tool-Klasse und Review-Fokus in zehn Minuten ein. Dann starten Sie mit einem — mit KPI, mit Termin.

Weiterführende Quellen

• Google Gemini für Workspace — Produktivitätsübersicht (DE)
• Microsoft Copilot für M365 — Übersicht (DE)
• GDPR.eu — Was ist die DSGVO? (EN, Kurzübersicht)

Das 14-Tage-Format dreht den Spieß um: ein Tool, ein Use Case, eine Baseline, ein Review-Termin. Kein Webinar-Enthusiasmus, keine offenen Fragen am Tag 15. Eine schriftliche Entscheidung: skalieren, anpassen oder stoppen.

Im Buch haben Sie das Prinzip kennengelernt. Hier ist das Protokoll für die Umsetzung.

Tag 1–3: Vorbereitung

Wählen Sie einen Use Case, der weh tut. Nicht „KI ausprobieren“ — sondern eine konkrete Aufgabe, die Sie jede Woche Zeit kostet: Protokoll aus Meeting-Notizen, strukturierter Angebotsentwurf, Recherche-Einseiter für Entscheidungsvorlage.

Briefing: eine Seite. Input, Output, Ton, Tabus, Beispiel. Dieser Stand bleibt 14 Tage unverändert. Nicht anpassen, weil Tag 3 suboptimal war.

Baseline: drei Durchläufe ohne KI oder mit dem alten Prozess. Minuten zählen, Rückfragen zählen, Fehler zählen. Machen Sie ein Foto von der Tabelle mit Datum. In vier Wochen erinnert niemand mehr, wie langsam es wirklich war — jetzt dokumentieren, nicht am Tag 14 raten.

Bevor Sie starten: Datenschutz-Gate prüfen. Welche Daten fließen in das Tool? Liegt ein AV-Vertrag vor? Im Zweifel: zuerst klären, dann starten.

Kalender: täglich 20 Minuten Test, Tag 14 Review mit einem Stakeholder — Termin jetzt blocken. Ein Test ohne Publikum ist ein Hobby. Mit Review-Termin wird er eine Betriebsentscheidung.

Tag 4–10: Durchführung

Jeden Werktag denselben Vorgang mit dem Tool bearbeiten. Logbuch: eine Zeile pro Tag — Datum, Minuten für die Aufgabe, Minuten für Review, eine Auffälligkeit. Excel reicht.

Kein Feature-Wechsel mid-test. Kein Modellwechsel. Wenn der Output schlechter wird: Briefing einmal schärfen, Version notieren — nicht heimlich das Tool tauschen und am Tag 14 sagen „hat nicht funktioniert“.

Tag 7: Peer-Check. Ein Kollege liest einen Output blind — ohne zu wissen, ob KI oder Mensch. Qualität zählt, nicht Begeisterung. Schlechte Outputs sammeln und aufheben — sie sind besseres Lernmaterial als zehn Erfolgsgeschichten ohne Beleg.

Wichtig: KI spart oft Schreiben, kann aber Review-Zeit erhöhen. Rechnen Sie beides mit ein — sonst lügt die Bilanz.

Tag 11–14: Auswertung

Rechnung aufmachen: Baseline-Durchschnitt gegen Test-Durchschnitt, inklusive Review-Minuten. Ehrlich. Keine Ausreißer rausrechnen, die das Ergebnis schöner machen.

Drei Optionen — und nur drei:

• Skalieren: einen Vorgang mit Owner und KPI als Routine übernehmen, Kalenderanker setzen, Transfer-Checkliste aus dem Buch nutzen
• Anpassen: Briefing überarbeiten, einen weiteren 14-Tage-Lauf mit Änderungen
• Stoppen: Lizenz nicht ausrollen, Lessons Learned in fünf Sätzen ins Wiki — damit das Team denselben Test nicht ein Quartal später mit neuem Logo wiederholt

Keine vierte Option „noch zwei Wochen schauen“. Das ist keine Entscheidung — das ist aufgeschobene Verantwortung.

Nach dem Skalieren: frühestens vier Wochen warten, bevor der nächste Test beginnt. Routine vor dem nächsten Experiment — das ist der Unterschied zum Tool-Zoo.

Typische Fehler

Zu breiter Use Case: „alles mit KI testen“ scheitert immer. Ein Vorgang, ein KPI.

Kein Review eingebaut: Schneller Unsinn ist kein Gewinn. Review-Zeit gehört zur Rechnung.

Paralleltest: zwei Tools, eine Woche — am Ende wissen Sie nicht, was gewirkt hat. Ein Tool, ein Test.

IT nicht informiert: Datenrisiko und nachträglicher Stopp kosten mehr als zwei Tage Wartezeit vor dem Start.

Kein Stakeholder-Review am Tag 14: Der Pilot verpufft ohne Entscheidung. Manchmal zeigt der Test nicht, dass das Tool fehlt — sondern dass der Prozess kaputt ist. Dann Prozess reparieren, nicht Abo Nr. 8 kaufen.

Fehler öffentlich im Team teilen macht den nächsten Test besser. Wer nur Siegergeschichten zeigt, wiederholt die gleichen Fallen im nächsten Quartal.

Starten Sie morgen: Use Case und KPI festlegen. Baseline in drei Durchläufen messen. Kalender für 14 Tage und den Review-Termin blocken. Das reicht für den Anfang.

Weiterführende Quellen

• Harvard Business Review — How to Get the Most Out of AI Tools at Work (EN)
• OpenAI — Best Practices for Prompt Engineering (EN)
• Bitkom — KI in Unternehmen: Leitfäden und Studien (DE)

Das ist der Tool-Zoo. Er entsteht nicht aus böser Absicht. Er entsteht, wenn das Lesen nicht in Betrieb übergeht.

Der Betriebsmodus ist die Antwort. Nicht mehr Werkzeuge — weniger, dafür mit klaren Regeln, Routinen und einem Rhythmus, der auch ohne Enthusiasmus weiterläuft.

Drei Ebenen, eine Seite

Ebene 1 — Regeln: Daten-Gate, erlaubte Tool-Klassen, Review vor Versand. Das sind die Leitplanken. Ohne sie raten Kollegen täglich neu.

Ebene 2 — Routinen: Wöchentlicher Use Case, monatlicher Review, quartalsweise Lizenz-Prüfung. Nicht als Projekt — als feste Kalendertermine.

Ebene 3 — Kultur: Fehler aktualisieren das Briefing, nicht die Personalakte. Wer Fehler bestraft, bekommt Schatten-Tools — Kollegen, die einfach nichts mehr melden. Das ist teurer als jeder Fehler.

Diese drei Ebenen gehören auf eine Seite im Wiki. Nicht in ein 60-seitiges Governance-Dokument, das niemand öffnet. Eine Seite, ein KI-Ansprechpartner pro Abteilung, ein Versionsdatum.

Nach dem Buch direkt umsetzen: Ersten Kalendertermin für einen echten Use Case blocken. Nicht nach dem nächsten Kapitel — nach diesem.

Den Tool-Zoo verhindern

Maximal zwei Allzweck-Kanäle pro Rolle — jedes weitere nur mit IT-Freigabe und Begründung. Nicht weil Innovation schlecht ist. Sondern weil drei parallele Allzweck-Tools für dieselbe Aufgabe keine Innovation sind — sie sind Koordinationsverlust.

Neues Tool: erst 14-Tage-Test, dann schriftliche Entscheidung. Keine Ausnahme, auch nicht für das Tool, das gerade auf der Titelseite einer Fachzeitschrift war.

Lizenzen ohne Login-Aktivität im letzten Monat: kündigen oder schriftlich begründen, warum weiter gezahlt wird. Quartalsweise mit IT prüfen. Das ist keine Bürokratie — das ist Respekt vor dem Budget.

Custom GPTs und Claude Projects: Katalog mit Owner anlegen. Wer hat es gebaut? Wann wurde es zuletzt geprüft? Wildwuchs in privaten Workspaces ist eine Form von Tool-Zoo, die unsichtbar bleibt — bis die Person die Abteilung wechselt.

Shadow IT: anonyme Umfrage im Team, dann sichere Alternative anbieten. Wer nur verbietet, treibt den Einsatz in den Schatten. Vertrauen braucht eine Schiene, kein Schild.

Kommunikation nach außen und nach oben

Eine Folie für Führung: Wofür nutzen wir KI? Wofür bewusst nicht? Wie messen wir Nutzen? Wen fragen Mitarbeitende?

Erfolg kommunizieren als Zeit oder Fehlerreduktion — nicht als „Wir sind jetzt KI-first“. Konkrete Zahl, konkreter Vorgang. Führung, die das nicht in einer Minute erklären kann, hat noch keinen Betriebsmodus — nur ein Experiment mit Datum.

Skeptiker im Team: Review-Rolle anbieten, nicht überzeugen wollen. Wer prüft, ob KI-Output korrekt ist, liefert echten Wert. Das ist Qualitätssicherung, kein Widerstand.

Onboarding neuer Kollegen: Entscheidungsbaum, Use-Case-Karte, ein Briefing-Beispiel — 30 Minuten. Damit sind neue Mitarbeitende handlungsfähig, ohne auf den nächsten Workshop warten zu müssen.

Die nächsten 30 Tage

Woche 1: Tool-Zoo-Check durchführen. Wie viele Allzweck-Tools sind aktiv? Hat jedes einen Owner und einen KPI?

Woche 2: Use-Case-Karte befüllen, einen Pilot nach dem 14-Tage-Format starten.

Woche 3: Briefing-Standard und Review-Checkliste im Team teilen — eine Seite, nicht ein Framework.

Woche 4: Review mit KPI — skalieren oder streichen. Betriebsmodus-Dokument zwei Seiten, Version mit Datum, im Wiki veröffentlichen.

Wenn nach 30 Tagen alles läuft: Das nächste Ziel ist nicht Logo Nr. 12. Das nächste Ziel ist ein besseres Briefing für den Use Case, der am meisten genutzt wird.

Der Betriebsmodus ist fertig, wenn Führung ohne Folie erklären kann: welcher Vorgang, welches Tool, welche Zahl, welcher Stopp. Alles andere ist noch Experiment — ehrlich benennen und mit Datum im Wiki markieren.

Weiterführende Quellen

• Anthropic — Unternehmenskontext und Sicherheitsprinzipien (EN)
• Bitkom — KI-Praxisleitfaden für Unternehmen (DE)
• Harvard Business Review — Build a Culture of Responsible AI Use (EN)

Kernthese: Nicht mehr Werkzeuge, sondern weniger, dafür mit Review und Kalenderanker.

Tool-Zoo erkennen erkennt Zoo-Frühwarnzeichen. 30-Tage-Implementierung setzt 30-Tage-Routine. Buch-Bonus liefert Material zum Festhalten.

Betriebsmodus heißt: erlaubte Tool-Klassen, Standard-Briefings, KPI-Rhythmus, Stop-Regeln — nicht Dauer-Experiment.

Lesen Sie mit dem Team Tool-Zoo erkennen — eine Seite, drei Signale, ob der Zoo schon da ist.

Externer Impuls ohne neue App: anthropic.com/company — Kontext zu Anbietern, nicht Anlass für Abo Nr. 12.

Montagmorgen: Können Sie in 30 Sekunden sagen, welches Tool wofür — ohne „kommt drauf an“?

Vom Lesen zum Betrieb

Drei Ebenen

Ebene 1 — Regeln: Daten-Gate, Tool-Klassen, Review vor Versand.

Ebene 2 — Routinen: wöchentlicher Use Case, monatlicher Review, quartalsweise Lizenz-Prüfung.

Ebene 3 — Kultur: Fehler als Briefing-Update, nicht als Schuld — sonst Schatten-Tools.

Buch-Kapitel werden Checklisten, nicht Sammlung vergessener PDFs.

Ein „KI-Ansprechpartner“ pro Abteilung, nicht jeder für sich — Koordination schlägt Heldentum.

Kalenderanker: gleicher Wochentag, gleiche Dauer — Transfer aus 30-Tage-Implementierung.

Drei Ebenen — Regeln, Routinen, Kultur — auf einer Seite: Daten-Gate, Tool-Klassen, Review vor Versand; wöchentlicher Use Case, monatlicher Review; Fehler als Briefing-Update. Buch-Kapitel werden Checklisten, nicht PDF-Grab.

Ein KI-Ansprechpartner pro Abteilung koordiniert, statt zehn Helden mit Schatten-Tools. Kalenderanker aus Umsetzungs-Bonus: gleicher Tag, gleiche Dauer — sonst verpufft Transfer nach dem Lesen.

Lesen ersetzt nicht Betrieb: nach dem Buch sofort einen Vorgang wählen und in den Kalender legen. Ohne Termin bleibt SmartWork Theorie — Montagmessbarkeit beginnt mit dem ersten Weekly, nicht mit dem letzten Kapitel.

Buch-Kapitel zu Checklisten: je Kapitel „im Betrieb seit …“ — leere Zeilen sind ehrlich. Führung sieht Fortschritt ohne Tool-Zoo; Sie sehen, wo Transfer fehlt.

KI-Ansprechpartner rotiert jährlich — Wissen verteilen, Held:in vermeiden. Rotation zwingt Dokumentation — Arbeitslogik vor Tool überlebt Urlaub und Wechsel.

Zoo-Check-Signale aus dem Buch auf einer Karte — drei Haken. Ohne Karte wird es Gespräch ohne Ende — Montagmessbarkeit verlangt sichtbare Signale.

Tool-Zoo verhindern

Weniger ist Betrieb

Maximal zwei Allzweck-Kanäle pro Rolle — Rest mit IT-Freigabe.

Neues Tool nur mit 14-Tage-Test und schriftlicher Entscheidung — siehe Bonus 09.

Lizenzen ohne Login-Zahl im letzten Monat: kündigen oder neu begründen.

Kein „ich probier mal Claude und Gemini und Copilot“ für dieselbe Aufgabe — Entscheidungsbaum nutzen.

Custom GPTs / Projects: Katalog mit Owner — Wildwuchs stoppen.

Schatten-IT sichtbar machen: anonyme Umfrage, dann sichere Alternative — nicht nur Verbot.

Maximal zwei Allzweck-Kanäle pro Rolle — Rest nur mit IT-Freigabe. Neues Tool nur mit 14-Tage-Test und schriftlicher Entscheidung; Lizenzen ohne Login im letzten Monat kündigen oder begründen.

Schatten-IT: Umfrage, dann sichere Alternative — Verbot allein vergrößert Zoo. Custom-GPT-Katalog mit Owner; derselbe Use Case nicht in drei Fenstern — Entscheidungsbaum nutzen.

Zoo-Check quartalsweise wiederholen: neue Logos, neue Custom GPTs, neue Agenten — jedes Mal gleiche Fragen. Arbeitslogik vor Tool heißt auch: mutig abschalten, was niemand mehr nutzt, statt „vielleicht später“ zu zahlen.

Lizenzliste gegen Login-Log — anonymisiert, mit IT. Quartalsreview für Budget: zahlen wir für Gewohnheit oder für Vorgänge — Montagmessbarkeit für Geld, nicht nur Zeit.

Zwei-Allzweck-Regel im Wiki verlinken — bei jedem neuen Tool-Request. Ohne Link wird es zur Meinung — mit Link zur Entscheidung aus dem 14-Tage-Test.

Schatten-IT-Umfrage anonym, Ergebnis mit Alternative — nicht nur Verbot. Vertrauen sinkt bei Strafe ohne Ausweg — Betrieb braucht sichere Schiene.

Kommunikation nach außen

Führung und Kollegen

Eine Folie: wofür KI, wofür nicht, wie messen, wen fragen.

Erfolg als Zeit oder Fehler — nicht als „wir sind innovativ“.

Skeptiker einbinden: Review-Rolle wertschätzen — Qualitätssicherung, nicht Bremser.

IT und Legal als Partner kommunizieren — nicht als später Stopp.

Onboarding neuer Kollegen: Baum, Karte, Briefing-Beispiel — 30 Minuten.

Nach sechs Monaten: eine Erfolgsgeschichte mit Zahl — nicht zehn ohne KPI.

Eine Folie nach außen: wofür KI, wofür nicht, wie messen, wen fragen. Skeptiker als Review-Rolle wertschätzen — Qualität, nicht Bremser. IT und Legal als Partner, nicht als später Stopp.

Onboarding 30 Minuten: Baum, Karte, Briefing-Beispiel. Nach sechs Monaten eine Geschichte mit Zahl — zehn ohne KPI sind Marketing, kein Betrieb.

Kommunikation nach außen braucht ein Gegenbeispiel: wofür Sie KI bewusst nicht nutzen. Das schafft Vertrauen mehr als ein weiteres Demo-Video — und hält den Tool-Zoo klein, weil Erwartungen realistisch bleiben.

Kunden fragen nach Verlässlichkeit, nicht Logos — klare Grenze stärker als „überall KI“. Arbeitslogik vor Tool auch nach außen: keine KI in Vertragszusagen ohne Review.

30-Tage-Review im Kalender der Führung — nicht optional. Betriebsmodus ohne Termin verpufft — Montagmessbarkeit braucht den gleichen Respekt wie Umsatz-Review.

Nächstes Jahr Briefings verbessern — nicht Logo Nr. 12. Wenn das Team lacht über neues Tool, fehlt oft Review — nicht Intelligenz.

Der Betriebsmodus ist fertig, wenn Führung ohne Folie erklärt: welcher Vorgang, welches Tool, welche Zahl, welcher Stop — in unter einer Minute. Alles andere ist noch Experiment — ehrlich benennen und im Wiki mit Datum markieren.

Nächste 30 Tage

Implementierung statt Hype

Woche 1: Tool-Klassen und Zoo-Check mit Tool-Zoo erkennen.

Woche 2: Use-Case-Karte befüllen, einen Pilot starten.

Woche 3: Briefing-Standard und Review-Checkliste teilen.

Woche 4: Review mit KPI — skalieren oder streichen.

Dokument „Betriebsmodus KI“ — maximal zwei Seiten, Version mit Datum.

Arbeitslogik vor Tool: wenn alles läuft, kaufen Sie nächstes Jahr kein neues Logo — Sie verbessern Briefings.

30 Tage: Woche 1 Zoo-Check mit Tool-Zoo erkennen, Woche 2 Karte plus Pilot, Woche 3 Briefing-Standard, Woche 4 KPI-Review. Betriebsmodus-Dokument zwei Seiten mit Datum im Wiki.

Wenn alles läuft, nächstes Jahr Briefings verbessern — nicht Logo Nr. 12. Arbeitslogik vor Tool ist der Betriebsmodus, nicht die Dauer-Experiment-Phase.

Review-Termin nach 30 Tagen im Kalender blocken — mit Agenda: KPI, Streichen, Skalieren. Ohne Termin gewinnt der Alltag; mit Termin wird aus dem Buch ein Betriebsmodus, der auch ohne Enthusiasmus weiterläuft.

Betriebsmodus an Quartale koppeln: Zoo-Check, Karte, Briefings, Lizenzen — Rhythmus statt Stimmung. Arbeitslogik vor Tool wird Kalender, nicht Messe-Enthusiasmus.

Regeln-Ebene jährlich mit Legal — eine Stunde, Baum anpassen. Routinen-Ebene monatlich im Team — zehn Minuten reichen, wenn KPI vorliegt.

Kultur-Ebene: Fehler aktualisieren Briefing — nicht Personen beschämen. Sonst Schatten-Tools — Arbeitslogik vor Tool braucht psychologische Sicherheit.

1. Tool-Zoo-Check mit drei Signalen aus dem Buch durchführen.
2. Erlaubte Tool-Klassen schriftlich festlegen (max. zwei Allzweck).
3. Betriebsmodus-Dokument (2 Seiten) anlegen und veröffentlichen.
4. Einen 14-Tage-Test für den wichtigsten offenen Use Case starten.
5. 30-Tage-Implementierung (30-Tage-Implementierung) im Kalender blocken.