KI-Pilot zum Scheitern designen: Die acht Belastungsproben vor dem Budget-Entscheid

777 Sekunden. So lange lief ein Agent in meinem eigenen Recherche-System einmal für eine einzige Antwort: 13 Minuten, in denen er dieselbe tote Webseite vier Mal ansteuerte und jedes Mal den vollen 30-Sekunden-Timeout verbrannte. Im Demo-Skript wäre das nie passiert. Im Demo-Skript hatte er immer funktioniert.

Genau diese Lücke steht vor jedem Budget-Entscheid. Der KI-Pilot lief, die Demo hat die Geschäftsleitung überzeugt, jetzt soll Geld gesprochen werden. Und dieser Entscheid hat, richtig gestellt, fünf legitime Ausgänge: bauen, kaufen, nachbessern, verschieben oder stoppen. Alle fünf sind Erfolge, wenn sie auf Evidenz beruhen. Die Frage ist nur, worauf sie ruhen: auf Applaus oder auf Zahlen und Traces.

Meine These: Ein Pilot, der nicht scheitern kann, kann nichts beweisen. Designen Sie Ihren KI-Piloten zum Scheitern, mit Ausnahme-Fällen, Berechtigungs-Kanten, hässlichen Dokumenten und dem zweiten gleichzeitigen Nutzer, bevor Sie das Budget entscheiden. Das ist kein Defätismus, sondern Falsifikation: Nur ein Pilot, der scheitern darf, kann bestehen. Der Rest dieses Artikels ist die Landkarte, woran er scheitern können muss. Es sind acht Belastungsproben, gruppiert in drei Fragen, die ein Entscheider ohnehin stellt: Kann das System richtig antworten? Kann es sicher betrieben werden? Und kann die Organisation es tragen?

Warum beweist ein perfekter KI-Pilot nichts?

Ein KI-Pilot, der nur den Happy Path zeigt, beweist nicht, dass das System in Produktion funktioniert, sondern nur, dass die Demo funktioniert. Produktionsreife hängt an mehreren Dimensionen zugleich: Daten, Berechtigungen, Ausnahmen, Integration, Betrieb, Messung und Organisation. Ein Pilot, der die schwächste Dimension nicht findet, liefert keine Entscheidungsgrundlage.

Der Fehler ist so verbreitet, dass er in meinem eigenen Architektur-Framework als Standardfehler katalogisiert ist: Eine funktionierende Demo wird mit einer produktionsreifen Lösung verwechselt. Die präziseste Fassung des Gegenmittels stammt aus Googles ML-Test-Score-Rubrik: 28 konkrete Tests in vier Kategorien (Daten, Modellverhalten, Infrastruktur, Monitoring), aggregiert über das Minimum der Kategorien statt über den Durchschnitt. Die Begründung ist Produktionserfahrung: Im Betrieb bricht genau die Dimension, die niemand beobachtet hat. Ein brillantes System ohne Monitoring ist deshalb kein brillantes System.

Die kursierenden Schlagzeilen-Quoten zu gescheiterten KI-Projekten taugen dagegen wenig als Präzisionsaussagen; sie sind je nach Quelle Prognosen, Selbstauskünfte oder eng definierte Sonderfälle. Die belastbarste Messung ist nüchterner und schlimm genug: In der Befragung von S&P Global 451 Research (1'006 IT- und Fachverantwortliche, Feldzeit Oktober bis November 2024) gaben 42 Prozent der Unternehmen an, die Mehrheit ihrer KI-Initiativen abgebrochen zu haben, gegenüber 17 Prozent im Vorjahr. Im Schnitt wurden 46 Prozent der Proof of Concepts vor der Produktion verworfen.

Der Befund, der daraus eine Design-Aufgabe macht, steckt in der Ursachenforschung. RAND spricht von über 80 Prozent gescheiterten KI-Projekten («by some estimates») und nennt als Wurzeln durchweg Dinge, die vor dem Entscheid prüfbar gewesen wären: das Problem falsch verstanden, die Daten unzureichend, die Infrastruktur unterschätzt, die Technologie dem Problem übergestülpt. Die grossen Fehlschläge waren im Rückblick fast immer sichtbar, bevor das Geld floss. Man hätte nur hinschauen müssen.

Der richtig designte Pilot ist genau das Instrument, das diese erkennbaren Risiken sichtbar macht, wenn er darf. (Karl Popper hätte am KI-Einkauf seine Freude gehabt: Eine These, die nicht scheitern kann, ist keine These. Ein Pilot auch nicht.) Dieselbe Beweis-Logik gilt übrigens für die Offerte des Anbieters; fünf Fragen entlarven ein fragiles KI-Angebot, und der Pilot ist das Instrument, das die Antworten darauf überprüfbar macht.

Was muss ein KI-Pilot testen, damit er in Produktion hält? Die Landkarte

Ein aussagekräftiger KI-Pilot testet acht Dinge: (1) echte Dokumente in echtem Volumen und echter Frische, (2) Ausnahme-Fälle und Enthaltungsverhalten, (3) eine Messlatte aus gelabelten Testfragen mit Rollback-Schwelle, (4) Berechtigungen und den zweiten gleichzeitigen Nutzer, (5) die Integration ins Zielsystem inklusive Schreibpfad, (6) Laufzeit und Kosten bei realem Volumen, (7) Adoption und Nutzungsverhalten über Wochen, (8) Governance, Datenschutz und Betriebsverantwortung. Die meisten Piloten testen nur einen Teil der ersten Gruppe, auf kuratiertem Material.

Die acht Proben beantworten drei Fragen, in dieser Reihenfolge:

• Kann es richtig antworten? Echte Dokumente, Enthaltung, Messlatte (Proben 1–3).
• Kann es sicher betrieben werden? Berechtigungen, Integration, Last und Kosten (Proben 4–6).
• Kann die Organisation es tragen? Adoption, Governance und Betrieb (Proben 7–8).

Warum die dritte Gruppe nicht weggelassen werden darf, dafür liefert BCGs 10-20-70-Faustregel die Denkhilfe: 10 Prozent des Transformations-Erfolgs hängen an Algorithmen, 20 Prozent an Technologie und Daten, 70 Prozent an Menschen und Prozessen. Das ist Beratungs-Erfahrung, keine Studie, und taugt nicht als bewiesene Ausfall-Verteilung. Als diagnostische Linse taugt es sehr wohl: Viele Piloten übergewichten die sichtbare Technik und untergewichten genau die Rollout-Faktoren, an denen Projekte später dokumentiert hängen bleiben — Berechtigungen, Betrieb, Kosten, Adoption, Verantwortung. Auch der NIST-Risikostandard AI RMF verlangt im Kern nichts anderes: Der Deployment-Entscheid soll auf kartierten Risiken beruhen, nicht auf einer gelungenen Demo.

Und damit die Grössenordnung von Anfang an stimmt: Für ein Schweizer KMU muss der Pilot klein genug sein, um in Wochen zu laufen, und echt genug, um Risiko freizulegen. Ein 50-Personen-Treuhandbüro fährt acht Wochen lang einen Piloten auf 300 echten Mandats-PDFs inklusive der gescannten Altbestände, mit zwei Sachbearbeitern unterschiedlicher Berechtigungsstufe, zwanzig vorab gelabelten Fragen und einer Rollback-Schwelle im Auftrag. Das ist kein Grossprojekt; es ist derselbe Pilot wie vorher, nur mit Erlaubnis zu scheitern.

Welcher Pilot ist es überhaupt? Fünf Typen, ein Raster

«KI-Pilot» ist keine homogene Kategorie, und die acht Proben wiegen je nach Typ unterschiedlich. Vor dem Design gehört deshalb eine Einordnung, die in Offerten oft fehlt:

• Microsoft 365 Copilot Rollout: An Antwortqualität und Modellverhalten (Proben 1–3) können Sie wenig ändern; dafür entscheiden der zweite Nutzer, Adoption und Governance (Proben 4, 7, 8) fast alles. Das Exposure-Assessment vor dem Go-live ist hier die wichtigste Einzelmassnahme.
• Copilot-Studio-Agent: Die Berechtigungsprobe wird konkret konfigurierbar — und damit prüfbar: Copilot Studio kennt drei Authentifizierungsmodi (keine Authentifizierung, Microsoft-Authentifizierung, manuelle Authentifizierung) mit direkt unterschiedlichen Konsequenzen dafür, wer mit dem Agenten sprechen kann und ob Nutzer-Tokens für berechtigungs-getrimmte Zugriffe verfügbar sind. Dazu kommen Connector-Scopes und Enthaltungsverhalten (Proben 2, 4, 5).
• Eigenbau-RAG oder -Agent (Microsoft Foundry / Azure): Alle acht Proben gelten voll; die Antwortqualitäts-Gruppe (1–3) und der Betrieb unter Last (6) sind hier am teuersten zu übersehen, weil Pipeline- und Index-Entscheide Fundament sind.
• Power-Platform-Automation mit KI-Schritten: Integration und Governance (Proben 5, 8) dominieren; die Enthaltungsprobe gilt an jedem einzelnen KI-Schritt, der eine Weiche stellt.
• Eingebettete KI im Fachprodukt (ERP, CRM, DMS): Die Technik-Proben liegen weitgehend beim Anbieter — Ihre Messlatte (Probe 3), die Adoption (7) und das Betriebsmodell (8) bleiben trotzdem vollständig bei Ihnen.

Das Raster bleibt in allen fünf Fällen dasselbe; nur die Beweislast verschiebt sich zwischen Ihnen und dem Anbieter. Welcher Use Case überhaupt welche Architektur verdient, ist der Entscheid davor.

Kann es richtig antworten? Proben 1 bis 3

Probe 1: Echte Dokumente, echtes Volumen, echte Frische

Demos schönen die Datenlage in drei Richtungen zugleich. Erstens die Qualität: kuratierte PDFs statt gescannter Verträge, Tabellen-Dokumente und zweisprachiger Ablagen. Zweitens das Volumen: 50 Dokumente sagen nichts über 50'000, denn Retrieval-Präzision, Index-Kosten und Ingestion-Dauer skalieren nicht linear. Drittens die Frische: Wer aktualisiert den Index, und was passiert bei drei Wochen Rückstand? Ein Pilot, der auf handverlesenem Material läuft, hat alle drei Fragen bereits wegdefiniert.

Wie gross die Lücke zwischen kuratiert und echt sein kann, illustriert ein Praktiker-Bericht aus der Anbieter-Prüfung: von rund 95 Prozent Demo-Genauigkeit auf rund 68 Prozent auf 500 echten Kunden-Tickets — eine Einzelbeobachtung, keine Studie, aber exakt die Lücke, die kuratierte Korpora verstecken. Und zur Ehrlichkeit gehört die eigene Lücke: Die Ranking-Qualität über Deutsch und Englisch hinweg ist bei uns dokumentiert ungemessen. Genau deshalb gehören bilinguale Testfragen in jeden Piloten dieser Art.

Die Test-Rezeptur ist unspektakulär:

• 1 gescanntes Vertrags-PDF, 1 Tabellen-Dokument, 1 veralteter Dokumentstand, je 3 Fragen auf Deutsch und Englisch
• den Korpus auf realistische Grösse aufblasen, bevor Sie Antwortqualität bewerten
• eine Frage stellen, deren Antwort nur im veralteten Stand steht

Der Architektur-Entscheid, den diese Probe früh und günstig informiert: Dokument-Pipeline, Chunking-Strategie und Index-Design sind Fundament-Entscheide. Nach dem Piloten revidieren heisst neu bauen. Der Pilot beantwortet, ob Standard-Extraktion reicht oder Document Intelligence nötig ist, ob ein Index genügt und welche Ingestion-Frequenz bezahlbar ist. Die Architektur-Tiefe dahinter liefert RAG, das in Produktion hält.

Probe 2: «Weiss ich nicht» ist ein Feature

Verlangen Sie von Ihrem KI-Piloten eine Enthaltungs-Quote. Ein System, das auf Ausnahme-Fragen zu 100 Prozent antwortet, ist kein gutes System. Es ist ein ungeprüftes.

Dass das keine Techniker-Spitzfindigkeit ist, hat ein kanadisches Tribunal 2024 vorgerechnet: Es hielt Air Canada für eine Kulanz-Regel haftbar, die ihr Chatbot frei erfunden hatte — 650.88 kanadische Dollar Schadenersatz wegen negligent misrepresentation, plus Zinsen und Gebühren, insgesamt gut 812 Dollar. Das Argument der Airline, der Chatbot sei eine eigene rechtliche Einheit und für seine Aussagen selbst verantwortlich, wies das Tribunal als bemerkenswerte Eingabe zurück. Die Summe ist klein, der Grundsatz nicht: Wer das System betreibt, haftet für seine Worte. Eine saubere Enthaltung ist deshalb auch ein Haftungs-Schutz, kein Komfort-Verzicht.

Wie Enthaltung als Architektur aussieht, statt als Prompt-Zeile, zeigt unsere eigene Degradations-Leiter; sie ist implementiert, die Produktions-Validierung steht noch aus. Erst passt das System den Plan an (Websuche als Fallback, breitere Suchanfrage), dann greift ein mechanischer Fallback, dann hält es an und begründet den Halt. Das erklärte Nicht-Ziel steht wörtlich in der Doku: «Never: System produces hallucinated garbage.»

1. 1Maximal 2 Replan-Versuche, danach Halt mit Begründung statt Endlosschleife.
2. 2Interne Fragen fallen nie auf die Websuche zurück; im Zweifel gilt fail_gracefully.
3. 3Die Antwort-Synthese blockiert auf leerer Evidenz: keine Antwort ohne Quellen.
4. 4Jeder Halt trägt einen Grund, den der Nutzer sieht, und mehrdeutige Fragen eskalieren an den Menschen.

Zwei Nuancen gehören dazu. Erstens die Kalibrierung: Zu viel Enthaltung ist auch ein Fehlschlag; ins Test-Set gehören beide Fehlerrichtungen — Fragen, die beantwortet werden müssen, und Fragen, die enthalten werden müssen. Zweitens die Oberfläche: Sie muss Fehlzustände zeigen können. Wir haben eine Status-Anzeige mit rund 900 Zeilen Code gelöscht, weil sie Fortschritt erfand («Found 16 sources» bei null tatsächlichen URLs). Wenn die Oberfläche nur Erfolg anzeigen kann, verwechseln Stakeholder Streaming-Theater mit Evidenz.

Der Architektur-Entscheid: Enthaltung, Halt-Gründe und Eskalation an Menschen sind Architektur-Konstrukte. Der Pilot beantwortet, wo die Grenze zwischen «System antwortet», «System fragt nach» und «System bricht ab» liegen muss. Warum Enthaltung Halluzination schlägt und wie die Eskalation an Menschen mechanisch funktioniert, führen zwei eigene Artikel aus.

Probe 3: Die Messlatte mit Rollback-Schwelle

Ohne Messlatte ist «es funktioniert» eine Stimmung. Drei Artefakte machen daraus eine Aussage, und alle drei gehören als Deliverable in den Pilot-Auftrag.

Erstens ein gelabeltes Frage-Set: 30 bis 50 Testfragen mit erwartetem Ergebnis pro Frage, inklusive der Muss-Scheitern-Fälle (Berechtigung verweigert, falsche Sprache, hässliches PDF, ausserhalb der Domäne). Wer es genauer will, misst Ranking-Qualität mit Metriken wie NDCG; das Stichwort genügt hier. Zweitens eine Vorher-Baseline: Welcher Ist-Wert (Zeit pro Aufgabe, Fehlerquote, Qualität) muss geschlagen werden? Drittens eine schriftliche Rollback-Schwelle: Welches Ergebnis zu welchem Zeitpunkt löst den Rückbau aus?

Wozu die dritte, zeigt der öffentlichste Gegenbeweis der letzten Jahre: Klarna ersetzte Service-Rollen durch KI, räumte 2025 tiefere Qualität ein und stellte wieder Menschen ein. Die Kurskorrektur ehrt die Firma; der Fehler lag früher. Eine vorab vereinbarte Qualitäts-Schwelle hätte aus der öffentlichen Kehrtwende einen geplanten Prozess gemacht. Ohne Schwelle ist jeder Rückbau ein Gesichtsverlust, und Gesichtsverluste werden aufgeschoben, bis sie teuer sind.

Dass Messung keine Kür ist, sagt die Minimum-Logik aus der Landkarte: Monitoring und Regressions-Tests sind in Googles Rubrik eine der vier gleichberechtigten Kategorien — ein System ohne Messung fällt durch, egal wie gut die Demo war. Im Microsoft-Stack ist das Werkzeug dafür inzwischen eingebaut: Microsoft Foundry führt Observability als Dreiklang aus Evaluation, Monitoring und Tracing, inklusive Groundedness- und Relevanz-Metriken für RAG. Ein Anbieter, der auf dieser Plattform baut und trotzdem kein Eval-Datenset vorlegen kann, hat eine Erklärung offen.

Und hier steht unsere eigene, unbequemste Selbstkritik. Das interne Audit unseres Retrieval-Systems formuliert es wörtlich: «You don't have a baseline today, which means every change is invisible.» Wir haben Falsifikationspfade gebaut, weil Demos gelogen haben; den Eval-Harness sind wir noch schuldig, ein bewusster Ship-vs-Measure-Trade-off mit dokumentiertem Plan. Ich kenne den Preis des Tunings im Blindflug also aus erster Hand, und genau deshalb steht diese Probe im Raster.

Der Architektur-Entscheid: Tracing und Evaluations-Infrastruktur sind Teil der Lösung, nicht des Projekt-Abschlussberichts. Welche Werkzeuge das im Microsoft-Ökosystem leisten, ist das Messwerkzeug-Kapitel dazu.

Kann es sicher betrieben werden? Proben 4 bis 6

Probe 4: Der zweite Nutzer, gleichzeitig

Der zweite Nutzer ist der meistvergessene Testfall im KI-Pilot. Demos laufen mit dem Champion-Account, der alles sehen darf; berechtigungs-getrimmte Suchen und Parallelität kommen im Skript nicht vor. Dabei ist genau hier der kanonische, KMU-relevante Fall dokumentiert: Microsoft 365 Copilot macht alles auffindbar, worauf ein Nutzer technisch Zugriff hat, und verwandelt damit gewachsenen Berechtigungs-Wildwuchs in durchsuchbare Exposition. Der springende Punkt fürs Pilot-Design: Microsoft dokumentiert das Risiko selbst und liefert mit der Deployment-Guidance «Secure and govern Microsoft 365 Copilot» (vormals als «Oversharing Blueprint» geführt) ein Pre-Deployment-Assessment mit; Microsoft Purview adressiert dieselbe Risikoklasse mit DSPM für KI, Sensitivity Labels und DLP. Das Risiko ist also vor dem Go-live prüfbar, nicht erst danach entdeckbar.

Die zweite Hälfte der Probe ist Parallelität, und dazu habe ich eine Narbe. Ein Multi-Source-Lauf in unserem System meldete «Erfolg», grüner Status, plausible Antwort, und hatte still 19 Quellen verloren. Der Mechanismus war banal: Zwei parallele Knoten schrieben in dasselbe Quellen-Register, beide lasen den leeren Stand, beide schrieben ihren vollen zurück, der letzte gewann. Kein Fehler im Log, keine Warnung; aufgefallen ist der Verlust erst an Zitaten, die ins Leere liefen. Sequenziell, mit einem einzigen Nutzer, war dieser Bug unsichtbar; er existierte nur unter Gleichzeitigkeit, also genau in der Bedingung, die kein Demo-Skript herstellt. Die Lehre für jeden Piloten: Erfolgs-Status und Vollständigkeit sind nicht dasselbe, und Parallelität ist ein Testfall, kein Skalierungs-Detail für später.

Daraus folgt der Pilot-Test, drei Prüfungen: gleiche Frage, zwei Identitäten, gleichzeitig. Erstens sieht jeder nur, was er darf. Zweitens wird ein leerer Treffer nicht heimlich durch ein Service-Konto «gerettet». Drittens geht unter Parallellast nichts still verloren. Dazu gehört ein Exposure-Assessment auf dem echten Tenant als Pilot-Deliverable, nicht als Empfehlung im Schlussbericht — und bei Copilot-Studio-Piloten die schriftliche Antwort auf die Frage, welcher Authentifizierungsmodus konfiguriert ist und warum.

Der Architektur-Entscheid dahinter ist nicht nachrüstbar: Per-User-Autorisierung (On-Behalf-Of, ACL-Trimming) muss ab Tag 1 in der Architektur sein; der spätere Umbau von einem Service-Konto auf Per-User-Identität ist faktisch ein Neubau. Warum der Agent nur sehen darf, was der Nutzer sehen darf, ist ein eigenes Kapitel.

Probe 5: Wohin geht das Resultat?

Jede Chat-Demo endet dort, wo die Arbeit beginnt. Die Antwort erscheint im Fenster, alle nicken, und niemand testet, wie sie in den Prozess kommt: ins ERP, ins DMS, in die Freigabe-Kette. Produktionsreife verlangt eine wiederholbare Übergabe statt improvisierter Copy-Paste-Brücken, und genau diese Dimension blendet das Demo-Format strukturell aus.

Der teuerste dokumentierte Beleg: Das MD Anderson Cancer Center schrieb rund 62 Millionen US-Dollar ab für ein Watson-basiertes System, das nie an einem Patienten eingesetzt wurde — publik geworden 2017 durch einen Audit-Bericht, der unter anderem ungelöste Integrationsfragen dokumentierte, während die Organisation mitten in einem Plattformwechsel ihrer Klinik-IT steckte. Eine Grossorganisation, gewiss; die Grössenordnung ist nicht übertragbar, die Mechanik schon. Die Pilot-Frage daraus passt in einen Satz: Welche unserer geplanten Plattform-Wechsel brechen diese Lösung?

Auf dem Weg ins Zielsystem liegt zudem die kritischste Grenze des ganzen Themas: lesen versus schreiben. Ein Assistent, der Antworten liefert, und ein Akteur, der Datensätze anlegt, Mails versendet oder Buchungen auslöst, sind zwei verschiedene Risikoklassen mit verschiedener Governance. Unser eigenes System endet heute bewusst am Lese-Pfad, gerade weil der Schreibpfad die Freigabe-Frage erzwingt, die wir noch nicht formal beantwortet haben. Ein Anbieter, der diese Grenze gar nicht thematisiert, hat sie vermutlich auch nicht gezogen.

Für den Piloten heisst das: mindestens einen End-to-End-Durchstich definieren, von der Frage bis zum Artefakt im Zielsystem, und sei der letzte Schritt ein manuell bestätigter. Sonst testet der Pilot ein Fragment. Der Architektur-Entscheid: Schnittstellen, Freigabe-Punkte und Rollback gehören ins Design, bevor gebaut wird — der Pilot beantwortet, wo die KI-Verantwortung endet, welches System führend bleibt und welche bekannten Plattform-Wechsel die Lösung überleben muss.

Probe 6: Zeit und Kosten unter echter Last

Zeit für die Auflösung des Intros. Der 777-Sekunden-Lauf war kein Modell-Fehler; das Modell hat schlicht getan, was man es liess. Ein Web-Agent erwischte eine URL, die nicht mehr antwortete, versuchte es erneut, und niemand hatte ihm gesagt, wann Schluss ist: vier Anläufe auf dieselbe tote Adresse, jeder 30 Sekunden Timeout, 13 Minuten für eine Antwort. Es war ein Fehler fehlender Betriebsgrenzen, und der Fix war entsprechend unglamourös: ein Circuit Breaker, ein Scrape-Budget pro Knoten, eine Blacklist für gescheiterte URLs.

Demos verbergen diese Fehlerklasse strukturell, denn Tail-Latenz und Kosten-Ausreisser existieren nur über viele Läufe. Ein gelungener Lauf beweist nichts über den 95. von 100; darum gehört die p95-Laufzeit (die Zeit, die 95 von 100 Läufen unterschreiten) als Metrik in den Piloten, nicht der eine Screenshot mit der schnellen Antwort. Dasselbe gilt für Drittanbieter-Grenzen: Rate Limits und Quoten treffen einen erst bei Volumen, und manche tarnen sich dann als Content-Filter. Woher Laufzeit architektonisch kommt, ist die Vertiefung dazu.

Für den Entscheider kommt die Kostenachse dazu, und hier ist die Analysten-Lage eindeutig: Gartner warnt seit Herbst 2024, dass Organisationen ohne Verständnis der GenAI-Kosten-Skalierung Kalkulationsfehler von 500 bis 1'000 Prozent machen, und empfiehlt ausdrücklich Proof of Concepts, die testen, wie Kosten skalieren, nicht nur, ob die Technologie funktioniert. Pilot-Budget ist Projektbudget; Produktion ist Stückkosten mal Volumen. Der Pilot misst darum Kosten pro Lauf bei einfachem Volumen und rechnet auf das Fünf- und Zehnfache hoch. Was die Microsoft-Optionen kosten, hat eine eigene Mechanik.

Eine Ehrlichkeits-Kante zum Schluss: Unser p95-Ziel von unter drei Minuten ist genau das, ein Ziel, keine Messung. Verlangen Sie diese Unterscheidung auch von Ihrem Anbieter: Welche Zahlen in der Offerte sind gemessen, welche sind Hoffnung? Der Architektur-Entscheid: Laufzeit-Budgets, Retry-Caps, Provider-Fallbacks und Kosten-Alarme sind tragende Konstrukte, keine Feinschliff-Optionen.

Kann die Organisation es tragen? Proben 7 und 8

Probe 7: Adoption ist messbar, Begeisterung nicht

Die dominante Todesursache von KI-Rollouts ist organisatorisch: ein unklarer Use Case, ein unverändertes Workflow-Design, schwindende Management-Aufmerksamkeit. RANDs Ursachen-Taxonomie führt dieselbe Liste an, mit dem missverstandenen oder falsch kommunizierten Problem an erster Stelle.

Dass Begeisterung dabei nichts beweist, ist selbst gemessen: In einer Gartner-Befragung vom Juni 2024 unter 132 IT-Verantwortlichen nannten 98 Prozent ihre Mitarbeitenden begeistert von Microsoft 365 Copilot, aber nur 6 Prozent hatten den Piloten abgeschlossen und planten aktiv die breite Einführung. Das messbare Muster dahinter beschreiben Praktiker-Berichte übereinstimmend: Die Nutzung spitzt sich um Woche 6 bis 8 zu und fällt danach auf ein tiefes Plateau, wenn sich der Arbeitsablauf nicht ändert — ein Praktiker-Muster, keine kontrollierte Studie. Ein Pilot, der nur die Launch-Woche misst, misst folglich Neugier, nicht Adoption.

Wie wenig die Lizenz über die Nutzung sagt, zeigt das grösste öffentlich dokumentierte Natural Experiment: Im Copilot-Versuch der britischen Regierung Ende 2024 — 20'000 Angestellte in 12 Organisationen, anonymisierte Nutzungsdaten von 14'500 — erreichte Microsoft 365 Copilot in Teams in der Spitze 71 Prozent Adoption, in Excel 23 Prozent. Gleiche Plattform, gleiche Lizenz, gleicher Konzern dahinter: Die Nutzung folgt dem Use Case, nicht der Beschaffung. Und die begleitende Evaluation des Department for Business and Trade fand trotz selbstberichteter Zeitersparnis von durchschnittlich 26 Minuten pro Tag keinen schlüssigen, messbaren Produktivitätsgewinn. Selbstauskunft ist keine Baseline — auch das ein Argument für Probe 3.

Für das Pilot-Design folgt daraus ein kompaktes Rezept:

• 3 bis 5 intakte Team-Kohorten statt verstreuter Freiwilliger
• Führungskräfte nutzen das Werkzeug sichtbar an echter Arbeit
• Wochen-Retention pro Aufgabe als Metrik, nicht vergebene Lizenzen
• Pilotdauer mindestens acht Wochen, damit die Klippe sichtbar werden kann

Der Implementations-Entscheid: Ob das Werkzeug in den bestehenden Arbeitsort gehört (Teams, Outlook) oder als eigene Oberfläche besteht, entscheidet der Use Case, und der Pilot liefert die Nutzungsdaten pro Aufgabe, die diese Oberflächen-Frage tragen. KI dort, wo gearbeitet wird, behandelt sie in voller Tiefe.

Probe 8: Wer betreibt es am Tag 400?

Governance ist ein Gate, kein Anhang, und für Schweizer KMU ist die wichtigste Klarstellung amtlich: Nach Auskunft des EDÖB ist das geltende Datenschutzgesetz auf KI-gestützte Datenbearbeitung direkt anwendbar. Es gibt keine Schonfrist bis zu einem künftigen KI-Gesetz; die Pflichten gelten am Tag des Go-live. Wer Betriebe in Deutschland hat, kennt das zweite Gate: Die Mitbestimmung nach BetrVG §87 kann einen Rollout unabhängig vom Nutzen blockieren, wenn das System Verhalten oder Leistung überwachen kann. Beide Klärungen gehören in den Piloten, nicht in die Woche nach der Beschaffung. Wie teuer das Aufschieben wird, hat dieselbe Gartner-Befragung beziffert: 40 Prozent der Organisationen verzögerten ihren Copilot-Rollout um drei Monate oder mehr, weil ungeklärtes Data Oversharing sie einholte.

Dann die Frage, die kein Demo beantwortet: Wer beobachtet das System am Tag 400? Wer reagiert auf einen Vorfall, wer pflegt Prompts, Indizes und Modell-Updates, und was passiert, wenn der externe Partner geht? Diese laufende Pflege ist ein realer, wiederkehrender Kostenblock, der in kaum einer Offerte steht — verlangen Sie ihn beziffert, bevor Sie unterschreiben. Der NIST-Risikostandard zieht daraus die formale Konsequenz: Verantwortlichkeiten, dokumentierte Deployment-Entscheide und Incident-Antwort gehören vor den Betrieb, als Querschnitts-Funktion, nicht als Schlusskapitel. Im Microsoft-Stack heisst das konkret: Purview-Audit-Logs und Retention auch für Prompts und Antworten, Datenklassifizierung vor dem Anschluss der Quellen, ein benannter Owner mit Stellvertretung.

Das letzte Deliverable dieser Probe ist unbequem und darum wertvoll: Abbruchkriterien, schriftlich, bevor die Begeisterung sie verwässert. Welche Messwerte beenden das Projekt? Ein Pilot mit schriftlichen Abbruchkriterien kann scheitern. Genau das macht ihn beweisfähig.

Der Entscheid dahinter ist organisatorisch: Betreibbarkeit ist ein Design-Kriterium. Der Pilot beantwortet, welches Betriebsmodell der Use Case verlangt (intern, Partner, Managed) und ob die Organisation es tragen kann. Wie KI den Berater überlebt und was revDSG und FINMA für regulierte Branchen konkret verlangen, sind die beiden Vertiefungen.

Welche Nachweise Sie im Microsoft-Stack verlangen können

Die acht Proben sind werkzeug-neutral; im Microsoft-Ökosystem lassen sie sich aber in konkrete, vorzeigbare Artefakte übersetzen. Verlangen Sie sie beim Anbieter oder beim eigenen Projektteam — jede Zeile ist in Stunden lieferbar, wenn die Arbeit gemacht wurde, und in Wochen nicht, wenn sie fehlt:

Das Pilot-Brief: Ihr Falsifikations-Design auf einer Seite

Ein aussagekräftiger KI-Pilot definiert vor dem Start: 10 Happy-Path- und 10 Ausnahme-Fragen mit erwartetem Ergebnis, zwei gleichzeitige Nutzer mit unterschiedlichen Berechtigungen, einen End-to-End-Durchstich ins Zielsystem, fünf Failure-Metriken (Enthaltungs-Quote, Halt-Gründe, Leertreffer-Quote, p95-Laufzeit, Kosten pro Lauf), eine Vorher-Baseline mit Rollback-Schwelle, mindestens acht Wochen Laufzeit mit Kohorten-Messung sowie schriftliche Nicht-Ziele und Abbruchkriterien.

Als Auftragsdokument sieht das so aus:

• Korpus (Probe 1): echte Dokumente in realistischer Grösse, inklusive Scans, Tabellen, veralteter Stände, Deutsch und Englisch
• Fragen (Proben 2 und 3): 10 Happy-Path- plus 10 Ausnahme-Fragen mit erwartetem Ergebnis. Muster für Ausnahme-Fragen: eine Frage, deren Antwort in einem Dokument liegt, das der Testnutzer nicht sehen darf; eine englische Frage zu einem deutschen Vertrag; eine Frage zu einem veralteten Dokumentstand; eine rein interne Frage, die nicht im Web landen darf; eine Frage ausserhalb der Domäne, die enthalten werden muss
• Nutzer (Probe 4): User A und User B mit unterschiedlichen Berechtigungen, gleichzeitig; Exposure-Assessment auf dem echten Tenant
• Durchstich (Probe 5): mindestens ein End-to-End-Pfad bis zum Artefakt im Zielsystem
• Failure-Metriken (Proben 2 und 6): Enthaltungs-Quote, Halt-Gründe, Leertreffer-Quote, p95-Laufzeit, Kosten pro Lauf bei einfachem, fünffachem, zehnfachem Volumen
• Messlatte (Probe 3): Vorher-Baseline und schriftliche Rollback-Schwelle
• Dauer und Kohorten (Probe 7): mindestens acht Wochen, 3 bis 5 intakte Teams, Wochen-Retention pro Aufgabe
• Governance (Probe 8): Datenschutz-Klärung, allenfalls Mitbestimmung, Betriebsmodell ab Tag 400
• Schriftlich: Nicht-Ziele und Abbruchkriterien

Die Struktur ist übertragbar; die Beispiel-Fragen sind Muster, Ihre Domäne liefert die echten. Für das Treuhandbüro aus der Landkarte heisst das: dieselben 300 Mandats-PDFs, dieselben zwei Sachbearbeiter, dieselben acht Wochen — nur jetzt mit dem Brief als Auftrag statt einer Demo als Versprechen.

Das Pilot-Brief hat einen Doppelnutzen: Es taugt als Anbieter-Test. Ein Anbieter, der diese Proben ablehnt («das Demo-Environment ist dafür nicht eingerichtet»), hat die fünf Fragen aus dem Angebots-Check schon beantwortet.

Vom Applaus zur Entscheidung: Build, Buy, Improve, Postpone oder Stop

Nach einem Piloten, der scheitern durfte, hat der Budget-Entscheid die fünf Ausgänge aus dem Intro, und alle fünf sind Erfolge, wenn sie auf Evidenz beruhen. Auch «Postpone» und «Stop». Auch «kein KI, ein klassischer Workflow reicht». Genau das unterscheidet einen Piloten von einer verlängerten Demo: Eine Verkaufsveranstaltung kennt nur einen Ausgang.

Kaufen gehört ausdrücklich dazu. Die viel diskutierte MIT-Studie zum «GenAI Divide» ist methodisch umstritten und ihre Schlagzeilen-Quote taugt nicht als Fakt; ein Befund verdient trotzdem Beachtung, als Richtung, nicht als Gesetz: Eingekaufte, spezialisierte Werkzeuge erreichten in den berichteten Daten deutlich häufiger den produktiven Einsatz als Eigenbauten. Der Punkt dieses Artikels ist also nicht Kauf-Vermeidung, sondern Kauf-Disziplin, und der richtig designte Pilot ist diese Disziplin in Auftragsform.

Ein letztes Kaufsignal: Ein seriöser Anbieter hat eine Liste behandelter und offener Fehlerarten — und die offenen stehen drin. Verlangen Sie diese Liste; wer nur behandelte Fehler kennt, hat noch nicht gesucht. Wir führen eine solche Liste über das eigene System, und sie ist der Grund, warum dieser Artikel existiert: Unser System war genau der Pilot, von dem er handelt. Es glänzte im Showcase und zerbrach an den dokumentierten Ausnahmen — dem 13-Minuten-Lauf, den still verlorenen Quellen, der erfundenen Fortschritts-Anzeige —, bevor die Falsifikationspfade gebaut waren. Die acht Proben sind das Raster, das ich damals gern gehabt hätte.

Wenn Sie die Proben nicht selbst aufsetzen oder die Resultate nicht selbst einordnen wollen, holen Sie sich vor dem Budget-Entscheid einen unabhängigen Blick: Ein Review vor dem Budget-Entscheid kostet einen Bruchteil eines gescheiterten Builds, und das Prüfraster dafür halten Sie jetzt in der Hand. Es gilt ausdrücklich auch für PowerLeap selbst.

Der Kreis schliesst sich beim Satz aus dem Intro: Ein Pilot, der nicht scheitern kann, kann nichts beweisen. Der Pilot, der an acht Proben scheitern durfte und bestanden hat, ist die einzige Demo, die etwas beweist. Ihr nächster Schritt kostet kein Budget: Nehmen Sie das Pilot-Brief, setzen Sie Ihre Domäne ein, und legen Sie es dem nächsten Anbieter, oder Ihrem eigenen Projektteam, auf den Tisch.