KI-Angebot prüfen: fünf Fragen, die ein fragiles Angebot entlarven

Die Demo hat überzeugt, die Offerte liegt auf dem Tisch, und niemand in Ihrer Firma kann beurteilen, ob das System den ersten Betriebsmonat übersteht. Wer in dieser Lage ein KI-Angebot prüfen will, greift meist zu Referenzen, Preisvergleich und Bauchgefühl. Zwei Befunde zeigen, warum das nicht reicht. Air Canada haftete im Februar 2024 für die Kulanzregel, die sein Chatbot frei erfunden hatte — nicht das Modell wurde verurteilt, sondern der Betreiber. Und laut der 451-Research-Umfrage von S&P Global (n=1'006, erhoben Ende 2024) sprang der Anteil der Firmen, die die Mehrheit ihrer KI-Initiativen abbrechen, innert Jahresfrist von 17 auf 42 Prozent; im Schnitt wurden 46 Prozent der Proof of Concepts vor der Produktion verworfen. Als grösste Hindernisse nennen die Befragten Kosten, Datenschutz und Sicherheit.

Solche Fälle beweisen nicht, dass ein Fragebogen jedes Scheitern verhindert hätte. Sie zeigen etwas Bescheideneres und Nützlicheres: Die teuersten KI-Risiken stecken selten im Modell. Sie stecken in fünf Architektur-Entscheiden, die eine Offerte fast nie ausweist — Wo lebt der Zustand? Wer hält die Berechtigungen zur Abfragezeit? Was passiert bei der ersten Ausnahme? Wer betreibt das System am Tag 91? Was kostet der Ausstieg? Genau dort muss ein Angebot prüfbar werden. Davor steht allerdings eine Frage 0, die alles Weitere erst sinnvoll macht: Ist das, was die Demo zeigt, überhaupt echt — live, auf Ihren Daten, heute? Und prüfbar heisst: pro Frage ein Artefakt — ein beschriftetes Diagramm, ein Live-Lauf, ein Runbook, eine Vertragsklausel. Ein Artefakt macht Bluffen nicht unmöglich, aber teuer und nachprüfbar; eine Zusicherung kostet den Anbieter nichts. (Ob der Use Case überhaupt einen Agenten verdient, ist der Entscheid davor; hier geht es um die Offerte, die schon auf dem Tisch liegt.)

Warum die übliche Checkliste Sie nicht schützt

Der übliche Prüfweg für eine KI-Offerte ist ein Fragebogen mit Zusicherungen. Genau dieser Weg hat einen dokumentierten Konstruktionsfehler: Zusicherungen sind bluffbar. Die US-Handelsaufsicht FTC hat im September 2024 mit der Aktion «Operation AI Comply» eine Reihe von Anbietern belangt; der wiederkehrende Befund war fast immer derselbe: Fähigkeits-Claims ohne Test-Evidenz dahinter. Der «Robo-Anwalt» DoNotPay hatte die Qualität seiner Rechtsdokumente schlicht nie geprüft. «AI Washing» ist damit keine Polemik mehr: Überzeichnete KI-Claims fallen unter die ganz gewöhnliche Irreführungslogik des Lauterkeitsrechts — und Aufsichtsbehörden wenden sie an.

Die Werkzeuge, mit denen Firmen KI-Anbieter bewerten, sind darauf schlecht vorbereitet. Security-Fragebögen im Stil von SIG oder CAIQ gelten selbst in der Sicherheitsbranche als schwach: selbstdeklariert, eine Momentaufnahme, kaum überprüfbar, ausgefüllt unter dem Anreiz, Ja zu sagen. Und das europäische Vorzeige-Instrument, die EU-Modellvertragsklauseln für KI-Beschaffung (MCC-AI, aktualisiert im März 2025), klammert Abnahme, Zahlung, Fristen und Haftung ausdrücklich aus. Also genau die Hebel, an denen die teuersten dokumentierten Fälle gescheitert sind.

Die Konsequenz ist ein Prinzipwechsel, kein längerer Fragebogen. Verlangen Sie zu jeder Frage ein Artefakt. «Kein Problem» kann jeder sagen. Ein Identitäts-Diagramm mit der Identität auf jedem Pfeil kann zwar auch gefälscht werden — aber es kostet Arbeit, es lässt sich gegen die Live-Umgebung halten, und es fällt bei der ersten Rückfrage auseinander, wenn niemand die Architektur tatsächlich gebaut hat.

Für welches KI-Angebot gilt welche Frage?

Nicht jede KI-Beschaffung ist ein Custom-Projekt. Ein Microsoft-365-Copilot-Rollout, ein Low-Code-Agent aus Copilot Studio, eine massgeschneiderte Agent-Plattform und ein Drittanbieter-SaaS sind vier verschiedene Einkaufssituationen — die fünf Fragen gelten für alle, aber nicht gleich tief:

Zwei Vorfragen gehören vor jede der fünf: Erstens die Datenreife — ein SharePoint, der seit Jahren als Ablagefriedhof dient, wird durch keinen Agenten besser, und «Welche Datenquellen sind überhaupt geeignet?» ist billiger vor dem Vertrag geklärt als danach. Zweitens das Schadenpotenzial des Use Case: Ein interner Reglement-Bot und ein kundengerichteter Agent, der verbindliche Aussagen macht, haben völlig verschiedene Haftungsprofile. Kalibrieren Sie die Prüftiefe daran, nicht am Preis der Offerte.

Frage 0 gilt für alle vier Situationen ungekürzt — eine Fähigkeit, die es nicht gibt, hat keine Architektur, die man prüfen könnte. Die fünf Fragen danach folgen alle demselben Dreischritt: Wie klingt die Ausweich-Antwort? Wie sieht eine ernsthafte Antwort aus? Welches Artefakt verlangen Sie?

Frage 0: Ist das Gezeigte überhaupt echt?

Bevor Sie eine einzige Architektur-Frage stellen, prüfen Sie den Anspruch selbst. Verlangen Sie den Live-Lauf auf Ihrem eigenen Material — fünfzig echte Dokumente, heute, im Meeting — und den Evaluations-Report hinter jeder Qualitätsaussage: Datensatz, Methode, Version, Datum. Wer «branchenführende Genauigkeit» sagt, aber keinen Messbericht vorlegen kann, hat nicht gemessen. Genau das war der wiederkehrende Befund der FTC-Fälle: nicht schlechte Messwerte, sondern gar keine.

Der Markt gibt dieser Frage ihre Dringlichkeit. Gartner nennt das Muster «Agent Washing»: Von Tausenden Anbietern, die agentische KI bewerben, liefern nach Gartner-Schätzung nur rund 130 sie tatsächlich. Und die Lücke zwischen Demo und Realität hat eine dokumentierte Grössenordnung: In einem Praxisfall aus der Anbieter-Evaluation fiel die Genauigkeit von rund 95 Prozent in der Demo auf 68 Prozent auf 500 echten Tickets des Kunden — ein Einzelfall, keine Statistik, aber die Mechanik dahinter ist strukturell: Demos laufen auf kuratierten Daten. Deshalb ist die Weigerung, Ihre Dokumente live zu verarbeiten, selbst schon das Ergebnis der Prüfung.

Zwei Ansprüche gehören zusätzlich schriftlich fixiert. Erstens der Mensch-Anteil: Die SEC belangte Presto Automation, weil dessen «KI»-Drive-Thru wesentlich von ausgelagerten menschlichen Agenten abhing; bei Builder.ai bestand die «KI»-App-Fabrik zu weiten Teilen aus Entwicklern. Fragen Sie also wörtlich: «Welcher Anteil des gelieferten Resultats läuft über Menschen auf Ihrer Seite — als Zahl, im Vertrag?» Zweitens die Roadmap-Grenze: «Das kommt in Q3, ist aber praktisch schon da» ist die Ausweich-Formel schlechthin. Verlangen Sie die schriftliche Liste, was heute ausgeliefert ist; Roadmap-Positionen gehören in den Vertrag nur als Meilensteine mit Abnahmekriterien.

Die Frage gilt auch für Dienstleister, nicht nur für Produkte. Deloitte Australien musste im Oktober 2025 einen Teil eines 440'000-Australdollar-Berichts zurückerstatten, nachdem erfundene Quellenangaben und ein erfundenes Gerichtszitat aufgeflogen waren; dass GPT-4o für die Kernanalyse eingesetzt worden war, stand erst in der korrigierten Fassung. Die Frage an jeden Integrator und Berater lautet seither: «Nutzen Sie selbst generative KI für unsere Deliverables — und welcher Verifikationsprozess gilt, mit wessen Unterschrift?»

Das Artefakt: der Live-Lauf auf fünfzig eigenen Dokumenten im Meeting, der Evaluations-Report mit Datensatz und Datum, die schriftliche Liste «heute ausgeliefert vs. Roadmap» und der Mensch-Anteil als Vertragszahl.

Frage 1: Wo lebt der Zustand?

Verlangen Sie ein Bild mit vier Boxen: flüchtiger Sitzungszustand, dauerhafte Konversations-Historie, dauerhafter Prozess- und Workflow-Zustand, und das führende Geschäftssystem. Die Namen der Speicher dahinter sind austauschbar; die vier Ebenen sind es nicht. Ein seriöser Anbieter sagt Ihnen für jede Information, in welcher Box sie liegt und welche Haltbarkeitsgarantie gilt. Wer die vier Boxen nicht zeichnen kann, hat die Entscheidung nie getroffen.

«Der Chat» fühlt sich wie eine Datenbank an und ist keine. In meiner eigenen Teams-Plattform sehen die vier Ebenen konkret so aus — als Beispiel, nicht als Norm:

Die vierte Zeile ist die wichtigste, und sie gilt für jeden Angebotstyp — auch für einen Copilot-Rollout ohne eigene Datenbank: Der Chat-Thread ist nicht Ihr System of Record. Was eine Nutzerin freigibt, muss in einer prüfbaren Tabelle oder einem Export landen, nicht in einer Sprechblase. Die Frage an den Anbieter lautet dann: «Wo landet ein freigegebenes Arbeitsergebnis, und wie finde ich es in einem Jahr wieder?» Warum das so ist, vertieft der Artikel zum Chat-Thread als System of Record.

Dass diese Trennung kein Schema-Ästhetizismus ist, habe ich in Produktion gelernt. Meine Plattform liefert finale Agent-Antworten über einen Echtzeit-Kanal aus, und in einer frühen Version erzeugte der Server die Konversations-ID erst beim Eintreffen der ersten Nachricht. Resultat: eine Race-Condition. Die fertige Antwort kam gelegentlich an, bevor die Routing-ID existierte, und wurde verworfen; die Nutzerin sah nichts. Der Symptom-Fix wäre ein Wiederholungsversuch gewesen. Die Architektur-Antwort war, dass der Client die ID erzeugen und besitzen muss, bevor der erste Aufruf passiert; mein Server lehnt heute jeden Aufruf ohne diese ID mit einem Fehler ab. Identität für Echtzeit-Routing muss vor der ersten Anfrage feststehen, nicht mittendrin ausgehandelt werden.

Zustand ist auch die technische Ursache hinter einem der meistzitierten Abbruch-Befunde. Der MIT-NANDA-Report vom August 2025 — dessen Schlagzeile «95 Prozent der GenAI-Piloten scheitern» präzise gelesen «kein messbarer Effekt in der Erfolgsrechnung» bedeutet, nicht «technisch kaputt» — beschreibt eine «Lernlücke» als Kernproblem: Werkzeuge, die Kontext nicht behalten und sich dem Arbeitsablauf nicht anpassen, werden schlicht nicht mehr benutzt.

Das Artefakt: das Vier-Boxen-Bild, pro Box mit Haltbarkeitsgarantie und der Angabe, was beim Ablauf des Caches mit laufender Arbeit passiert.

Frage 2: Wer hält die Berechtigungen zur Abfragezeit?

«Es respektiert die SharePoint-Berechtigungen» ist nie ein Fakt, sondern eine Kette. Indexierung, Firmensuche und eigene Uploads laufen typischerweise unter drei verschiedenen Identitäten. Verlangen Sie ein Diagramm mit der Identität auf jedem Pfeil, vom Nutzer über die App und die Suche bis zum Sprachmodell, und dazu das Berechtigungs-Assessment, das der Anbieter vor dem Go-live auf Ihrer Umgebung fährt.

In meinem eigenen System sehen die drei Ketten so aus:

Drei Vertrauensmodelle auf einer Produktoberfläche. Ein Anbieter, der das in einem Satz zusammenfasst, hat die Kette nicht gezeichnet. Meine erste Version filterte die Suchtreffer übrigens in der App: eine Berechtigungsliste pro Dokument, abgeglichen gegen die Nutzer-ID. Das zerbrach an SharePoint-Gruppen und vererbten Berechtigungen; heute übernimmt der Suchdienst das Trimming nativ, und die App ist nicht mehr die Sicherheitsgrenze. In einer Demo wäre dieser Unterschied nie aufgefallen: Dort sehen alle alles, und alles wirkt korrekt. Die Mechanik dahinter behandeln die Artikel zum ACL-Trimming und zu Teams SSO und On-Behalf-Of.

Kaufen Sie kein Custom-System, sondern einen Microsoft-365-Copilot-Rollout, stellt sich dieselbe Frage in anderer Form: Welche SharePoint-Sites sind überexponiert? Welche Sensitivity Labels und DLP-Regeln greifen tatsächlich? Welche Gäste, verwaisten Gruppen und «Jeder mit dem Link»-Freigaben sind im Scope? Und wer fährt das Assessment vor dem Rollout? Der Hintergrund ist der prominenteste dokumentierte Fall: Microsoft 365 Copilot macht Berechtigungswildwuchs im Tenant durchsuchbar, in der Fachdiskussion als Copilot Oversharing bekannt. Microsoft publiziert dagegen ein eigenes Blueprint gegen Oversharing mit Assessment-Schritten vor dem Rollout. Das Bemerkenswerte daran: Wenn der Hersteller selbst ein Vorab-Assessment dokumentiert, ist «das merken wir dann im Betrieb» keine zulässige Antwort mehr. Der Fehler ist vor dem Go-live testbar.

Ehrlichkeit auf der eigenen Scorecard: Netzwerk-Isolation über Private Endpoints und eine DLP-Anbindung sind bei mir Roadmap, nicht ausgelieferter Standard. Für Schweizer KMU kommt die rechtliche Klammer dazu: Der EDÖB hält fest, dass das revidierte Datenschutzgesetz auf KI-gestützte Datenbearbeitung direkt anwendbar ist. Daraus folgen konkrete Beschaffungsfragen, keine Grundsatzdebatte: Wo sitzen die Subprozessoren, und in welcher Region wird verarbeitet — auch für Logs und Embeddings? Werden Prompts oder Dateien für das Training von Modellen genutzt, und wo steht das im Vertrag statt in der FAQ? Wer dokumentiert automatisierte Einzelentscheidungen, falls das System welche trifft? Die schnellste Praxisprobe dazu stammt aus der DACH-Datenschutzpraxis: Verlangen Sie den vollständigen Auftragsverarbeitungsvertrag innert 24 Stunden. Wer stattdessen von «branchenüblichen Standardklauseln» spricht oder ein NDA vorschaltet, hat Ihnen bereits geantwortet.

Berührt Ihr Einsatz den EU-Markt, kommt eine zweite Klammer dazu: Ab August 2026 treffen Betreiber von Hochrisiko-Systemen eigene Pflichten nach Artikel 26 des AI Act — und erfüllen können Sie die nur mit Artefakten, die der Anbieter liefern muss: Gebrauchsanweisung, Risikoklassifikation, Beschreibung der Logging-Fähigkeit. Verlangen Sie sie vor dem Vertrag; «das liefern wir beim Onboarding» heisst, es existiert noch nicht. (Stand Juli 2026; die Fristen sind durch den «Digital Omnibus» in Bewegung — die Artefakte bleiben dieselben.) Und Vorsicht vor dem stillen Rollentausch: Wer ein System wesentlich anpasst oder unter eigenem Namen betreibt, kann vom Betreiber zum Anbieter mit vollen Anbieter-Pflichten werden — «unser Anbieter ist compliant» macht Sie nicht compliant. Die schnellste Probe der Auditierbarkeit kostet dabei wieder nur einen Satz: «Exportieren Sie jetzt ein Audit-Log.»

Das Artefakt: das Identitäts-Diagramm mit jedem Pfeil beschriftet, das Exposure-Assessment vor Go-live mit Go/No-Go-Kriterien, der volle AVV innert 24 Stunden — und ein live exportiertes Audit-Log.

Frage 3: Was passiert bei der ersten Ausnahme?

Verlangen Sie den Durchlauf des leeren Treffers: Was sieht die Nutzerin, wenn die Suche nichts Relevantes findet? Ein robustes System hat deterministische Gates: begrenzte Wiederholungen, ein explizites «Ich weiss es nicht» und eine Eskalation an Menschen. «Der Agent regelt das» ist keine Antwort, sondern die teuerste Zeile der Offerte.

Demos leben vom Happy Path. Produktion trifft leere Indizes, Dokumente aus der falschen Domäne, ablaufende Authentifizierungen und Rate Limits. Der Satz, der die Spreu trennt, lautet: Instruktionen sind keine Kontrollgrenze. «Wir haben dem Agenten gesagt, er soll Fehler sauber behandeln» ist ein Wunsch an ein Sprachmodell, kein Mechanismus. Das gilt für einen Copilot-Studio-Flow genauso wie für eine Custom-Plattform — dort heisst die Frage: Welches Topic greift beim Fehlschlag, und wann wird an einen Menschen übergeben?

Wie Mechanismen aussehen, zeige ich am eigenen System. Mein Executor erkennt kritische Fehlschläge deterministisch und plant maximal zweimal neu; danach hält er mit begründetem Halt an, statt endlos zu schleifen. Ein Relevanz-Gate prüft, ob die gefundene Evidenz überhaupt zur Frage passt, und verweigert die Antwort-Synthese, wenn sie es nicht tut (die Schwelle dafür ist ein getunter Parameter, keine validierte Konstante). Eine Regel blockiert den Ausweich-Griff zur Websuche, wenn die Anfrage interne Daten betrifft.

Zwei Ausnahme-Klassen verdienen eigene Pfade. Menschliche Freigaben laufen bei mir als dauerhafte Unterbrechung über den Checkpointer, überleben also auch einen Neustart. Und eine OAuth-Anmeldung für einen Connector lässt sich mitten in einem laufenden Workflow strukturell nicht abschliessen; das System erkennt den Fall, bittet die Nutzerin, sich im Chat zu authentifizieren, und startet danach neu. Explizit gestalteter Hand-off statt Kampf gegen die Plattform.

Das Gegenbeispiel hat inzwischen Rechtsgeschichte geschrieben. Air Canadas Chatbot erfand eine rückwirkende Kulanzregel für Trauerfall-Tarife; das kanadische Tribunal sprach dem Kunden rund 812 kanadische Dollar zu (inklusive Zinsen und Gebühren) und wies die Verteidigung, der Chatbot sei eine eigene rechtliche Entität, als «remarkable submission» zurück. (Im Juristenenglisch ist das keine Auszeichnung.) Der Betrag war klein, das Prinzip nicht: Der Betreiber haftet für die Worte seines Systems, und eine Anbieter-Haftungsklausel war offenbar nicht im Spiel.

Eine Ausnahme-Klasse fehlt darüber hinaus in fast jeder Offerte: die schleichende. Das System fällt nicht aus, es wird nur schlechter als der Mensch, den es ersetzt hat. Klarnas CEO räumte 2025 öffentlich ein, dass die KI-Kundenbetreuung «lower quality» lieferte, und stellte wieder Menschen ein — der prominenteste Rückzieher des Jahres 2025, und er war absehbar: Vor dem Go-live war nie eine Qualitätsgrenze gegen die menschliche Baseline definiert worden. Die Frage, die dort niemand gestellt hat, gehört in Ihr Meeting: «Welche gemessene Qualität, gegen welche Baseline, löst den Rollback aus — und auf wessen Kosten?» «Schauen wir mal, wie es performt» ist keine Antwort. Die Baseline wird vor dem Go-live vereinbart oder nie.

Das Artefakt: die Ausnahme-Zustandsmaschine als Skizze (Halt-Gründe, Wiederholungs-Limits, Eskalationspfad), ein kleines Testset mit Ablehnungsfällen — Fragen, auf die die richtige Antwort «Ich weiss es nicht» lautet —, die vor Go-live vereinbarte Qualitäts-Baseline mit Rollback-Schwelle, und die Haftungsklausel für falsche Aussagen gegenüber Ihren Kunden.

Frage 4: Wer betreibt es am Tag 91?

Verlangen Sie die Verantwortungsmatrix für Monat 7: Wer pflegt Prompts, Indizes, Integrationen und Modell-Updates, mit benannten Rollen, Stunden und Preis? Ein grünes Azure-Dashboard sagt nichts über Antwortqualität, Index-Frische oder ablaufende Connector-Authentifizierung. «Microsoft managed das» gilt nur, solange nichts Eigenes im Spiel ist — und ein Copilot-Studio-Agent mit fünf Connectoren ist bereits etwas Eigenes.

Dieselbe Frage hat eine kaufmännische Seite, die in Offerten am häufigsten fehlt: Wer bezahlt den Token- und Connector-Verbrauch, und wer prüft monatlich, ob er explodiert? Wer aktualisiert die Wissensquellen, wenn das Reglement ändert? Wer testet nach einem Modell-Update, ob die Antworten noch stimmen — und kann er das Vorher/Nachher-Eval des letzten Updates bei einem Bestandskunden zeigen? Und wer ist am Montagmorgen erreichbar, wenn der HR-Agent falsche Ferienansprüche beantwortet? Jede dieser Fragen braucht einen Namen und einen Preis, keinen Absatz über «Hypercare».

Zum Preis selbst gehört das Jahr-zwei-Szenario, durchgerechnet vor der Unterschrift: die volle Rechnung bei einfacher, fünffacher und zehnfacher der erwarteten Nutzung, jede Komponente — inklusive der Lizenz- und Plattform-Voraussetzungen, die nicht im Angebotspreis stehen — plus eine echte, anonymisierte Rechnung eines Kunden Ihrer Grösse. Das ist keine Pedanterie: Gartner beziffert den Rechenfehler von Käufern, die die Kostenskalierung nicht verstehen, auf 500 bis 1'000 Prozent, und agentische Workloads verbrauchen das Fünf- bis Dreissigfache der Token eines einfachen Chats pro Aufgabe — bei Anbietern, denen Gartner gleichzeitig mangelnde Transparenz über die eigene Token-Abrechnung attestiert. «Consumption hängt vom Usage ab» ist die Ausweich-Antwort; die ernsthafte ist ein Spreadsheet, das Sie behalten dürfen. (Die Preis-Mechanik dahinter vertieft ein eigener Artikel; hier geht es darum, ob der Anbieter sie für sein eigenes Produkt beherrscht.)

Der Massstab für eine ernsthafte Antwort ist nicht Perfektion, sondern dokumentierte Ehrlichkeit. Meine eigene Umgebung entsteht vollständig aus Infrastruktur-Code, ausgerollt über vier sequenzierte Pipelines. Daneben existiert trotzdem ein Dokument mit manuellen Schritten: App-Registrierungen, Berechtigungs-Grants, eine Bootstrap-Reihenfolge, die eine Pipeline strukturell nicht automatisieren kann, weil die Datenbank-Rolle existieren muss, bevor die erste Migration unter Managed Identity laufen darf. Der Punkt ist nicht, dass dieser manuelle Kern existiert. Der Punkt ist, dass er dokumentiert ist statt versteckt. Fragen Sie den Anbieter wörtlich: «Welche manuellen Portal-Schritte bleiben nach Ihrem ‹vollautomatisierten› Deployment übrig?»

Die unbequemste Zeile in meinem eigenen Betriebs-Kapitel: Es gibt kein Evaluations-Harness. Prompt-Tuning ohne Regressions-Messung ist Raten mit Selbstvertrauen, und genau so benenne ich es. Auch eine per-Treffer-Audit-Spur fehlt derzeit auf Datenbank-Ebene. Stellen Sie dem Anbieter die Frage, an der ich selbst scheitere: «Gibt es ein gelabeltes Test-Set, das Prompt-Änderungen vor dem Deployment prüft?» Was solche Messwerkzeuge im Microsoft-Ökosystem leisten, zeigt der Artikel zu Tracing und Evals.

Was passiert, wenn niemand diese Fragen stellt, hat die University of Texas 2016 auditieren lassen: MD Anderson gab rund 62 Millionen Dollar für IBM Watson aus, ohne dass das System je an einem Patienten eingesetzt wurde. Der Audit fand Zahlungen ohne Abnahmekriterien, Honorare knapp unter den Genehmigungsschwellen des Boards und keinen Integrationspfad zur längst beschlossenen Migration des Kliniksystems. Kein Modellproblem weit und breit; ein Beschaffungs- und Betriebsproblem. Die schärfste Lehre daraus passt in eine einzige Vertragsfrage: «Welche Zahlung hängt an welchem Abnahmekriterium?» Dass sich Anbieter darauf einlassen können, ist belegt — es gibt öffentlich dokumentierte Modelle, die pro gelöster Kundeninteraktion abrechnen, nach dem Motto «wenn unsere KI nicht funktioniert, werden wir nicht bezahlt». Wer nicht einmal einen Meilenstein an ein Kriterium binden will, sagt Ihnen damit, wie sicher er sich seiner Sache ist. Und stellen Sie die MD-Anderson-Frage in Ihrer eigenen Fassung: «Wir migrieren System X in achtzehn Monaten — welche unserer Plattform-Änderungen brechen Ihr System, und was kostet die Re-Integration?»

Budgetieren Sie den Betrieb als eigenen Posten: Ohne Pflege von Prompts, Indizes, Connector-Authentifizierung und Kostenmonitoring ist das System nach dem Go-live nicht fertig, sondern nur unbeaufsichtigt. Als Daumenregel — eine Praktiker-Schätzung, keine Studie — kursieren 17 bis 30 Prozent der Baukosten pro Jahr; selbst die halbe Bandbreite gehört ins Budget. Wie eine Lösung den Berater überlebt, der sie gebaut hat, ist ein eigener Architekturentscheid.

Das Artefakt: die RACI-Tabelle für Monat 7 (inklusive Kosten-Verantwortung), das Kostenmodell für einfache, fünffache und zehnfache Nutzung, das Runbook-Inhaltsverzeichnis heute, und das Monitoring live gezeigt mit der Frage «Was hat es in den letzten 90 Tagen konkret gefangen?».

Frage 5: Was kostet der Ausstieg?

Der Ausstiegspreis wird beim Einstieg festgelegt. «Kein Lock-in» ist eine Behauptung; verlangen Sie Infrastruktur-Code, Datenmodell, Index-Feldkarte und Repository-Zugriff im Vertrag, und führen Sie den Daten-Export noch während der Evaluation selbst aus. Dann beurteilen Sie Lock-in Komponente für Komponente statt als Ja oder Nein.

Dass Anbieter verschwinden, ist keine Paranoia, sondern dokumentierte Marktgeschichte der Jahre 2023 bis 2025: Olive AI abgewickelt, Babylon Health insolvent, Forward geschlossen, Builder.ai kollabiert. Builder.ai hatte über 450 Millionen Dollar eingesammelt und den Umsatz gegenüber Kreditgebern um rund 300 Prozent überzeichnet; nach der Insolvenz mussten Kunden gemäss Presseberichten kurzfristig klären, ob und wie sie überhaupt an ihren eigenen Code und ihre Projektstände kommen. Die Substanz-Frage dahinter ist stellbar, bevor man Kunde wird: Wer auditiert Sie? Wie viele zahlende Kunden unseres Profils, welcher Umsatztrend — notfalls unter NDA? Builder.ai hatte seit 2023 keinen Finanzchef, und die Zweifel am «KI»-Kern standen seit 2019 in der Wirtschaftspresse — beides öffentlich auffindbar, während jede Wachstumsfrage im Verkaufsgespräch überzeugend beantwortet wurde. Merken Sie sich dazu eine Rückfrage: «Wir sind gut finanziert» ist keine Antwort — Builder.ai war es auch. Die richtige Frage lautet: «Was halten wir in der Hand, wenn Sie in 90 Tagen weg sind?» Bemerkenswert ist auch die Gegenrichtung: Im Fall des Sicherheits-Anbieters Evolv verordnete die FTC Kündigungsrechte für Schulkunden als Abhilfe für überzeichnete KI-Fähigkeiten. Ausstiegsrechte sind damit kein Vertrags-Boilerplate mehr, sondern ein regulatorisch anerkanntes Korrektiv.

Lock-in ist dabei selten «falsche Cloud», sondern eine Frage der Komponenten — und bei Low-Code-Lösungen steckt die Exit-Reibung oft gar nicht im Code, sondern in Umgebungen, Flows, Connector-Konfigurationen und dem Dataverse-Schema. Bei meinem eigenen System ist die Bilanz gemischt, und ich halte sie bewusst so fest: Portabel sind der Infrastruktur-Code, das Standard-Schema des Workflow-Checkpointers und die PostgreSQL-Exporte. Echt gekoppelt sind der geteilte Sitzungszustand mit Copilot Studio, das als Connector-Zugang dient, und das massgeschneiderte dreistufige Suchindex-Schema; ein Wechsel der Suchmaschine wäre ein Re-Indexierungs-Projekt, kein Konfigurationsschalter. Diese Kopplung war ein bewusster Tausch (Connector- und Dataverse-Zugang gegen Exit-Reibung). Genau diese Sorte Ehrlichkeit dürfen Sie vom Anbieter verlangen: nicht «kein Lock-in», sondern die Liste, was portabel ist und was klebt.

Zum Ausstieg gehört mehr als Daten. Klären Sie im Vertrag, wem beim Vertragsende was gehört und was dann passiert: Prompts und System-Instruktionen, Eval- und Testdatensätze, Connector-Konfigurationen und Mapping-Tabellen, Gesprächs- und Auditdaten, die Rechte an generierten Artefakten — plus den Lösch- und Rückgabeprozess und eine bezifferte Unterstützungspflicht beim Übergang. «Alles gehört Ihnen» stimmt dabei fast immer für die Daten und fast nie für die Konfiguration; die Probe kostet einen Satz: «Zeigen Sie die exportierte Konfiguration eines Bestandskunden.» Die Personenmonate für einen Ausstieg kann ich für mein System nicht seriös beziffern, und die meisten Anbieter können es auch nicht. Machen Sie daraus die Vertragsfrage: Wer die Schätzung schriftlich verweigert, hat sie nie gerechnet. Und die wirksamste Einzelprobe kostet Sie einen Satz: «Führen Sie den Export jetzt aus. Wir warten.»

Das Artefakt: der Export-Lauf während der Evaluation, eine Escrow- oder Transition-Klausel, und Infrastruktur-Code, Datenmodell, Index-Feldkarte und Repository-Zugriff als Vertragsbestandteil.

Meine eigene Scorecard: an der ersten Frage scheitere ich selbst

Ein Fragebogen, den der Autor nicht auf sich selbst anwendet, ist Marketing. Hier ist meine Ampel für die eigene Plattform, Stand: 8. Juli 2026.

Einmal Rot, einmal Gelb bis Rot, zweimal Gelb: Ich falle an der Frage durch, die ich Ihnen als erste empfehle — die Live-Demo könnte ich liefern, den Messbericht dahinter nicht. Das ist kein Understatement-Theater, sondern der Kern des Arguments: Die FTC-Fälle wurden durchwegs dort geführt, wo Claims ohne Test-Evidenz im Raum standen. Meine Einschätzung: Ein Anbieter, der diese Fragen verstanden hat, kann gar nicht überall grün sein, weil mindestens eine ehrliche Roadmap-Zeile existiert. Wer Ihnen einen makellosen Fragebogen zurückgibt, hat ihn nicht verstanden oder nicht ernst gemeint. Dieselbe Falsifikations-Haltung eine Stufe früher, beim Pilotprojekt, beschreibt der Artikel KI-Pilot zum Scheitern designen.

Wo Fragen aufhören, und was sie bewusst nicht abdecken

Zur Ehrlichkeit dieses Artikels gehört seine eigene Grenze: Fragebögen erzeugen falsche Sicherheit, wenn man sie als Beweis nimmt. Die Kritik an Assurance-Formaten trifft auch diesen hier, und einen Nachweis, dass irgendein Evaluations-Raster die Beschaffungs-Ergebnisse messbar verbessert, gibt es nicht. Das Argument ist mechanistisch: Artefakte sind schwerer zu bluffen als Zusicherungen. Der Beweis liegt ausserhalb des Meetings, in vier Instrumenten: ein Pilot auf Ihren eigenen Daten mit vorab vereinbarten Erfolgskriterien und Kosten-Messung, ein Vertrag, der Abnahme an Zahlung bindet, Referenzen ab Monat 12 im Betrieb, und der ausgeführte Export-Test. Wer ein formelleres Gegenstück sucht: Rahmenwerke wie das NIST AI Risk Management Framework oder ISO/IEC 42001 decken dieselben Governance-Flächen systematischer ab; das Gate und die fünf Fragen sind deren beschaffungstaugliche Kurzfassung — mit demselben Vorbehalt.

Drei Prüfflächen der KI-Beschaffung lasse ich hier bewusst weg. Ob das System auf Ihren Dokumenten dauerhaft die versprochene Qualität liefert, klärt kein Meeting — Frage 0 ist das Gate, nicht der Beweis; den liefert ein Pilot, der scheitern darf, mit vorab vereinbarten Erfolgskriterien und Kosten-Messung. Was der Betrieb im zweiten Jahr bei echtem Volumen kostet, hat eine eigene Preis-Mechanik. Und ob Ihre Daten überhaupt reif für das Vorhaben sind, ist die Vorfrage aus dem Anfang dieses Artikels — sie gehört auf Ihre Seite des Tisches, nicht auf die des Anbieters.

Zum Schluss die Einordnung, die vor Zynismus schützt: Kaufen ist nicht der Fehler. Der vielzitierte MIT-NANDA-Befund zeigt neben der Schlagzeile auch, dass eingekaufte Speziallösungen etwa doppelt so oft den produktiven Einsatz erreichen wie interne Eigenbauten. Der Fragebogen hat zudem eine freundliche Nebenwirkung: Er zeigt auch, wann gar kein Bau nötig ist. Ein Anbieter, der sagt «für diesen Fall reicht Microsoft 365 Copilot, bauen Sie nichts», hat Frage 4 und Frage 5 soeben mit Bestnote beantwortet.

Der Fragebogen zum Mitnehmen

Das Gate und die fünf Fragen für Ihr nächstes Anbieter-Meeting, je mit dem Artefakt, das die Antwort beweist.

Frage 0 — vor allen anderen: Ist das Gezeigte echt? Lassen Sie die Demo jetzt auf fünfzig eigenen Dokumenten laufen; verlangen Sie den Eval-Report und die schriftliche Liste «heute ausgeliefert vs. Roadmap».

1. 1Wo lebt der Zustand? Verlangen Sie das Vier-Boxen-Bild mit Haltbarkeitsgarantien.
2. 2Wer hält die Berechtigungen zur Abfragezeit? Verlangen Sie die Identität auf jedem Pfeil und das Exposure-Assessment vor Go-live.
3. 3Was passiert bei der ersten Ausnahme? Verlangen Sie den Durchlauf des leeren Treffers, die Zustandsmaschine und die Qualitäts-Baseline mit Rollback-Schwelle.
4. 4Wer betreibt es am Tag 91? Verlangen Sie die RACI-Tabelle für Monat 7 — inklusive Kosten-Verantwortung —, das Kostenmodell bei zehnfacher Nutzung und das Runbook-Inhaltsverzeichnis.
5. 5Was kostet der Ausstieg? Führen Sie den Export jetzt aus; Infrastruktur-Code, Datenmodell, Index-Feldkarte und die Rechte an Prompts und Eval-Sets gehören in den Vertrag.

Und die Übersetzungstabelle für die Sätze, die Sie hören werden:

So sieht das Meeting damit aus: Sie legen die Tabelle neben die Offerte, beginnen mit dem Live-Lauf auf Ihren eigenen Dokumenten, stellen dann die fünf Fragen wörtlich und notieren pro Frage, ob ein Artefakt kommt oder ein Adjektiv. Ein guter Anbieter wird aufatmen; endlich prüft jemand das, was er tatsächlich gebaut hat. Ein fragiles Angebot wird an dieser Stelle sehr wortreich. Beides ist ein Ergebnis, und beides erklärt den Preis: Wer die fünf Fragen ernsthaft beantwortet, kann selten der Billigste sein. Wer der Billigste ist, hat sie meist nicht beantwortet.

Wenn Sie die Antworten bekommen, aber nicht beurteilen können, holen Sie sich vor dem Budget-Entscheid eine unabhängige Zweitmeinung: Ein Review der Offerte kostet einen Bruchteil eines gescheiterten Builds, und den Prüfraster dafür halten Sie jetzt in der Hand. Das Gate und die fünf Fragen passen auf eine A4-Seite. Nehmen Sie sie mit ins nächste Meeting.