Die Beschaffungsfalle bei Enterprise-KI
Die Demo hat die Ausschreibung gewonnen
Die siegreiche Demo war sauber. Ein Nutzer stellte eine Frage, das System antwortete mit Quellenangaben, die Oberfläche schlug die nächste Aktion vor, und das Dashboard zeigte prognostizierte Einsparungen mit der Selbstgewissheit, die man sonst nur von Flughafenarchitektur kennt. Das Beschaffungsteam hatte seine Arbeit so erledigt, wie es der Prozess vorsah. Anforderungen wurden erhoben, Anbieter bewertet, Sicherheitsfragebögen ausgefüllt, rechtliche Klauseln verhandelt, und die ausgewählte Lösung wirkte wie die leistungsfähigste Option. Jeder konnte auf die Akte zeigen und sagen, dass das Verfahren eingehalten worden war.
Sechs Monate später war das Verfahren immer noch korrekt und der Betrieb erschöpft. Die Datenkonnektoren funktionierten mit Beispieldaten, kämpften aber mit dem echten Archiv. Die Antwortqualität war in der Umgebung des Anbieters gut und im internen Arbeitsablauf inkonsistent. Die menschliche Prüfung dauerte länger als erwartet, weil niemand den Aufwand für den Nachweis einkalkuliert hatte. Der Lieferant hatte eine Roadmap, der Käufer hatte Ausnahmen, und der Betrieb hatte eine Warteschlange von Problemen, die nicht in die ursprüngliche Anforderungstabelle passten. Nichts war betrügerisch. Nichts war schockierend. Der Beschaffungsprozess hatte eine KI-Fähigkeit gekauft und nur teilweise die Bedingungen, unter denen diese Fähigkeit zu Arbeit werden konnte.
Das ist die Beschaffungsfalle bei Enterprise-KI. Der Kaufprozess ist darauf ausgelegt, Produkte zu vergleichen, rechtliche Risiken zu reduzieren, Kosten zu kontrollieren und Fairness zu dokumentieren. Das sind legitime Ziele. Aber der Wert von KI entsteht in der unübersichtlichen Mitte zwischen Produkt und Organisation: Datenzugriff, Neugestaltung von Arbeitsabläufen, Erfassung von Nachweisen, Schulung der Nutzer, Ausnahmebehandlung, Modellaktualisierungen, Sicherheitslage, Integrationsschulden, Prüfungsanforderungen, Feedbackschleifen und Verantwortung für Ergebnisse. Wenn die Beschaffung das sichtbare Produkt bewertet und die Betriebsbedingungen als Implementierungsdetail behandelt, kauft die Organisation ein Versprechen und erhält ein Projekt.
Die Falle besteht nicht darin, dass Käufer töricht sind. Die meisten Käufer arbeiten mit übernommenen Vorlagen und echtem Druck. Sie sollen Innovation ermöglichen, Risiken reduzieren, schnell handeln, Kosten kontrollieren, Sicherheit gewährleisten, Vorschriften respektieren und später keine Schuld zugewiesen bekommen, eine kompakte Stellenbeschreibung mit der emotionalen Bandbreite eines Lochers. Die Falle ist strukturell: Enterprise-KI wird wie Software beschafft, verhält sich aber wie ein Betriebsmodell.
Output zu kaufen ist nicht dasselbe wie ein Ergebnis zu kaufen
Unternehmenskäufer fragen häufig, ob das System die Ausgabe erzeugen kann: Zusammenfassung, Klassifizierung, Empfehlung, Extraktion, Entwurf, Risikokennzeichnung, Suchergebnis, Analyse, Workflow-Aktion. Das ist eine berechtigte Frage und zugleich die kleine Frage. Die größere Frage ist, ob die Organisation diese Ausgabe in ein Ergebnis mit Verantwortung verwandeln kann. Wer erhält sie. Was wird damit getan. Welche Belege werden gesehen. Wann darf sie abgelehnt werden. Was geschieht, wenn sie falsch ist. Wie wird der Fehler behoben. Wem gehört die Kennzahl, nachdem der Anbieter den Raum verlassen hat.
Eine KI-Zusammenfassung ist kein Ergebnis. Ein Sachbearbeiter, der eine verifizierte Zusammenfassung nutzt, um eine schnellere, besser dokumentierte Entscheidung zu treffen, kann ein Ergebnis sein. Ein Risikoscore ist kein Ergebnis. Ein Triage-Prozess, der Fälle fair weiterleitet, Gründe dokumentiert und Ausnahmen behandelt, kann ein Ergebnis sein. Eine Chatbot-Antwort ist kein Ergebnis. Eine reduzierte Supportlast ohne Irreführung von Kunden, ohne Verlust von Eskalationswegen und ohne unsichtbare Haftung kann ein Ergebnis sein. Die Beschaffung muss den Weg von der erzeugten Ausgabe zum institutionellen Verhalten kaufen.
Dieser Weg führt durch mehrere Abteilungen. Die Rechtsabteilung kümmert sich um Befugnis und Haftung. Die Sicherheitsabteilung kümmert sich um Zugriff und Isolierung. Datenteams kümmern sich um Herkunft und Qualität. Der Betrieb kümmert sich um Warteschlangen und Personal. Die Finanzabteilung kümmert sich um Kosten und Nutzenrealisierung. Die Personalabteilung kann sich um Arbeitsgestaltung kümmern. Die Compliance kümmert sich um Belege. Die Nutzer kümmern sich darum, ob das System hilft oder sie stillschweigend für maschinelle Vermutungen verantwortlich macht. Eine Ausschreibung, die diese Belange als Abnahmekästchen statt als Gestaltungsinput behandelt, erzeugt elegante Unterlagen und eine fragile Einführung.
Diese Unterscheidung verändert auch die Preisgestaltung. Ein günstiges Werkzeug, das teure Prüfung, manuelle Datenaufbereitung, kundenspezifische Integration, zusätzliche Governance, unklare Belege und hohen Support erfordert, kann teuer sein. Ein teureres Werkzeug mit stärkerem Export, Beobachtbarkeit, Rollendesign, Datenverträgen und Aktualisierungskontrollen kann im Betrieb günstiger sein. Die Beschaffung kann das nicht erkennen, wenn sie den Lizenzpreis vergleicht und den Rest als Implementierung bezeichnet. Die Implementierung ist der Ort, an dem KI-Projekte ihre Rechnungen ansammeln.
Die Checkliste wächst um das falsche Zentrum herum
Die Unternehmensbeschaffung liebt Checklisten, weil Checklisten Ordnung und Verteidigungsfähigkeit schaffen. Unterstützt das System Single Sign-on. Verschlüsselt es Daten. Stellt es Prüfprotokolle bereit. Unterstützt es unsere Sprache. Integriert es sich in Dokumentensysteme. Bietet es rollenbasierte Zugriffssteuerung. Hat es eine Geschichte zur Modell-Governance. Unterstützt es Berichterstattung. Diese Fragen sind nützlich. Das Problem ist, dass ein Ja eine große Fläche verbergen kann.
Ja zu Prüfprotokollen kann rohe technische Protokolle bedeuten, die Fachinterpretation erfordern, nicht fallbezogene Belege, die von der Compliance genutzt werden können. Ja zu Integration kann bedeuten, dass eine API existiert, nicht dass das unübersichtliche Inhaltsmodell des Käufers verstanden wird. Ja zu rollenbasierter Zugriffssteuerung kann Rollen im Produkt bedeuten, nicht die Ausrichtung am Befugnismodell der Organisation. Ja zu Export kann bedeuten, dass Daten als flache Dateien ohne Herkunftsnachweis abgegeben werden. Ja zu menschlicher Aufsicht kann einen Genehmigen-Button bedeuten. Unternehmens-KI ist der Bereich, in dem auf viele Ja-Antworten ein Zeig es mir unter unschönen Bedingungen folgen sollte.
Die Checkliste sollte um operative Fragen herum wachsen. Welche Belege müssen überleben. Welche Datenquellen sind maßgeblich. Welche Felder sind zu veraltet. Welche Anwendungsfälle erfordern deterministische Aufzeichnungen. Welche Aktionen benötigen menschliche Genehmigung. Welche Fehler erfordern Benachrichtigung. Welche Änderungen erfordern eine Neubewertung. Welche Abhängigkeiten vom Anbieter sind akzeptabel. Welche Ausstiegsrechte sind nicht verhandelbar. Welche Teams müssen ihr Verhalten ändern. Welche Kontrollen werden vor dem Produktivstart getestet. Eine Produktcheckliste ohne Betriebsmodell ist eine Einkaufsliste für eine Küche, die niemand vermessen hat.
There is an odd comfort in vague requirements. They keep the tender broad, reduce conflict and let everyone imagine that their concern is included. Unfortunately, vague requirements do not disappear after award. They reincarnate as change requests, delays, disputes and steering group slides with increasingly careful verbs. Specificity feels slower before contract. It is often much faster after.
Risk transfer is often theatre
Procurement processes try to transfer risk. Contracts, warranties, indemnities, service levels, certifications, insurance, data processing terms. These matter. Mature buying needs them. But enterprise AI creates risks that cannot be fully transferred because they live in the buyer's context. The supplier can provide a tool, safeguards, support and evidence. The buyer owns the data, workflow, authority, user behaviour, escalation path, and decision that adopts the output. A contract cannot outsource judgement that happens inside the institution.
This is where some organisations become overconfident. The vendor passed security review. The model has documentation. The terms cover data protection. The service has uptime commitments. Good. Now who decides whether a low-confidence answer may be used in a high-impact case. Who notices when users stop reviewing. Who handles a customer challenge. Who validates that training examples match real work. Who pauses the system when policy changes. If the answer is the supplier, the buyer may be buying a governance fantasy. If the answer is nobody, the buyer has bought a future incident.
Risk transfer also creates perverse incentives when buyers ask suppliers to accept responsibility for things only the buyer can control. The supplier responds with exclusions, cautious configuration, inflated pricing or vague commitments. The buyer responds with more clauses. Eventually the contract becomes a padded room around a workflow nobody has designed. Very safe on paper. Less useful on Tuesday.
A better approach is risk allocation. Name the risk. Assign the part the supplier can control. Assign the part the buyer must operate. Define shared tests. Define evidence. Define escalation. Define pause rights. Define change control. This is less satisfying than pretending risk has been exported in a zip file. It is also closer to reality, a stubborn feature of successful operations.
The pilot is not the purchasing unit
Viele KI-Käufe in Unternehmen beginnen mit einem Pilotprojekt. Das ist vernünftig. Pilotprojekte verringern Unsicherheit und helfen Teams beim Lernen. Die Beschaffungsfalle tritt auf, wenn das Pilotprojekt zur Bewertungseinheit wird. Ein Pilotprojekt wird oft durch erfahrene Nutzer, kuratierte Daten, direkte Aufmerksamkeit des Anbieters, lockere Integration, vorübergehende Governance und ein Publikum geschützt, das bereit ist, raue Kanten zu verzeihen. Die Produktion ist anders. Die Produktion hat Volumen, Personalfluktuation, Audits, Randfälle, Sicherheitsbeschränkungen, Support-Tickets, Aufbewahrungsregeln, geänderte Prioritäten und Nutzer, die nicht am inspirierenden Kickoff teilgenommen haben.
Ein Pilotprojekt sollte daher Produktionsannahmen testen, nicht nur die Produktfähigkeit. Können normale Nutzer den Arbeitsablauf abschließen. Hält die Antwortqualität bei echten Daten stand. Wie viel Prüfzeit ist erforderlich. Welche Datensätze werden für das Audit benötigt. Welche Ausnahmen sind häufig. Welche Integrationspunkte sind fragil. Was passiert, wenn eine Quelle veraltet ist. Kann das System richtig ablehnen. Kann die Organisation es ohne Anbieter-Ingenieure im Chat den ganzen Tag unterstützen. Wenn diese Fragen bis nach der Skalierungsgenehmigung aufgeschoben werden, ist das Pilotprojekt Theater mit besseren Snacks.
Die Beschaffungseinheit sollte ein kontrollierter Betriebsausschnitt sein. Ein Ausschnitt umfasst den Anwendungsfall, Datenquellen, Befugnis, Nutzer, Prüfverfahren, Nachweise, Supportmodell, Änderungsprozess und Ausstiegspfad. Er ist enger als eine Strategie und größer als eine Demo. Er kann sinnvoll bewertet werden, weil er die Dinge enthält, die Wert schaffen, und die Dinge, die Kosten verursachen. Wenn der Ausschnitt funktioniert, bedeutet Skalierung, ein bekanntes Muster zu wiederholen und anzupassen. Wenn nur das Werkzeug funktioniert, bedeutet Skalierung, die Organisation eine Abhängigkeit nach der anderen zu entdecken.
Deshalb sollten Pilotkennzahlen langweilige Zahlen enthalten. Prüfminuten pro Fall. Prozentsatz korrigierter Ausgaben. Fälle, die wegen fehlender Nachweise abgelehnt wurden. Fehler bei veralteten Quellen. Anzahl der Eskalationen. Gründe für Nutzerabweichungen. Vollständigkeit der Exporte. Vorfälle, die Anbieter-Support erfordern. Zeit, um eine angefochtene Ausgabe zu erklären. Diese Kennzahlen sind weniger glamourös als Produktivitätssteigerung. Sie sind auch die Zahlen, die bestimmen, ob Produktivität überlebt.
Datenzugriff ist keine Verbinderliste
Beschaffungsdokumente fragen oft, mit welchen Systemen sich das Produkt verbindet. Das ist notwendig und unzureichend. Ein Verbinder ist eine Tür. Er sagt Ihnen nicht, ob der Raum beschriftete Regale, aktuelle Datensätze, rechtmäßigen Zugriff, konsistente Kennungen, brauchbare Dokumente, beibehaltenen Kontext oder einen Boden enthält. Unternehmensdaten warten selten höflich. Sie haben Altfelder, doppelte Datensätze, PDFs mit Geheimnissen, SharePoint-Archäologie, abteilungsspezifische Taxonomien, fehlende Eigentümer und Dateien namens final, weil Optimismus erneuerbar ist.
Der Käufer muss verstehen, was das KI-System von Daten benötigt, nicht nur, wo die Daten leben. Benötigt es vollständige Dokumente oder extrahierte Felder. Benötigt es den aktuellen Stand oder historische Momentaufnahmen. Benötigt es berechtigungsbewusstes Abrufen. Benötigt es Herkunftsnachweise. Benötigt es strukturierte Beschriftungen. Benötigt es Löschweitergabe. Benötigt es Schwellenwerte für Datenqualität. Benötigt es menschliche Korrektur. Jeder Bedarf ändert Integrationskosten und Governance. Ein Verbinder, der diese Bedürfnisse ignoriert, ist nur ein Schlauch. Schläuche sind nützlich. Sie sind auch der Grund, warum Keller überfluten.
Datenzugriff hat rechtliche und soziale Dimensionen. Ein System kann eine Quelle technisch lesen und dennoch nicht das Recht haben, sie für Modelltraining, Analytik, Mitarbeiterüberwachung oder automatisierte Entscheidungsunterstützung zu nutzen. Nutzer können einem Repository für einen Zweck vertrauen und Einwände erheben, wenn dessen Inhalte zu Treibstoff für einen anderen werden. Beschaffung, die fragt, ob wir uns verbinden können, bevor sie fragt, ob wir nutzen dürfen, schafft künftige Überraschungen. Überraschung ist ein schlechter Mechanismus für Einwilligung.
Zu gutem KI-Einkauf gehört daher eine Daten-Due-Diligence, und zwar vor der Vergabe oder zumindest vor der Skalierung. Stichproben aus dem unübersichtlichen Korpus ziehen. Extraktion testen. Berechtigungen prüfen. Duplikate messen. Veraltete Felder identifizieren. Datenverantwortliche benennen. Aufbewahrungsfristen und Einwilligungen prüfen. Verstehen, welche Daten nicht bewegt werden können. Die Bereinigung bepreisen. Wenn sich diese Arbeit wie eine Verzögerung des Kaufs anfühlt, denken Sie daran, dass der Kauf später ohnehin auf dasselbe Durcheinander gestoßen wäre, nur mit einem Vertrag in der Hand.
Änderungskontrolle ist das Produkt
Enterprise-KI bleibt nicht stehen. Modelle werden aktualisiert. Prompts ändern sich. Retrieval-Indizes werden neu aufgebaut. Richtlinien verschieben sich. Datenquellen ziehen um. Nutzer entdecken Randfälle. Sicherheitsregeln werden verschärft. Neue Vorschriften kommen hinzu. Das System, das die Beschaffung bestanden hat, ist nicht das System, das die Organisation ein Jahr später betreiben wird. Änderungskontrolle ist daher kein administrativer Overhead rund um das Produkt. Sie ist Teil des Produkts.
Die Beschaffung sollte fragen, wie Verhaltensänderungen vorgeschlagen, getestet, genehmigt, kommuniziert, zurückgerollt und nachgewiesen werden. Kann der Käufer ein Modell-Update verzögern? Können Prompt-Änderungen versioniert werden? Können Retrieval-Änderungen verglichen werden? Können Richtlinienbündel fixiert werden? Kann der Anbieter Release-Notizen liefern, die sich auf das operative Risiko beziehen und nicht auf Marketing-Poesie? Können Fälle mit hoher Auswirkung vor der Freigabe einem Regressionstest unterzogen werden? Kann die Organisation sehen, welche Fälle von einer Änderung betroffen waren? Ohne diese Rechte hat der Käufer kein System gekauft. Er hat Bewegung abonniert.
Interne Änderungen sind genauso wichtig wie Änderungen des Anbieters. Eine Abteilung ändert ein Formular. Ein Richtlinienteam überarbeitet Leitlinien. Ein Datenteam ändert einen Feldnamen. Eine Führungskraft verändert die Personalausstattung. Eine Rechtsauslegung verschiebt sich. KI-Systeme sitzen quer zu diesen Grenzen, sodass kleine interne Änderungen die Ergebnisse verschieben können. Die Beschaffung kann das nicht allein lösen, aber sie kann das Betriebsmodell verlangen, das Bewegung erkennt und steuert. Wenn jede Änderung als lokale Verbesserung eines anderen behandelt wird, wird der KI-Workflow zu einem Flur, in dem Türen ständig in Menschen hinein aufgehen.
Gute Änderungskontrolle gibt Innovation einen Weg. Sie blockiert keine Updates. Sie macht Updates nachvollziehbar. Teams können Modelle und Workflows schneller verbessern, wenn sie wissen, wie sie testen, genehmigen und wiederherstellen können. Das Gegenteil von Änderungskontrolle ist nicht Agilität. Es ist ungesteuertes Abdriften mit einem Release-Kalender.
Nutzer sind keine Adoptionsziele
Beschaffung behandelt Nutzer häufig als Adoptionsziele. Man schult sie, kommuniziert Vorteile, misst Nutzung, feiert Vorreiter, beseitigt Hindernisse. Einiges davon ist nützlich. Aber Nutzer sind auch Kontrollpunkte, Fachexperten und Frühwarnsysteme. Wenn sie dem System misstrauen, könnte dies Widerstand gegen Veränderung sein. Sie könnten aber auch erkennen, dass dem Workflow Belege, Autorität, Zeit oder Reparaturmöglichkeiten fehlen. Ein Beschaffungsprozess, der Nutzer hauptsächlich als zu Überzeugende sieht, wird die Informationen übersehen, die sie tragen.
Bevor Sie kaufen, sprechen Sie mit den Menschen, deren Arbeit die KI-Ausgabe aufnehmen wird. Fragen Sie, welche Belege sie für ihr Handeln benötigen. Welche Fälle gefährlich sind. Welche Datenfelder unzuverlässig sind. Welche Ausnahmen Zeit kosten. Welche Entscheidungen sie nicht delegieren würden. Welche Fehler peinlich, schädlich oder illegal wären. Welche Teile des aktuellen Prozesses informell sind, weil das formale System die Realität nie gelernt hat. Diese Antworten sind kein Widerstand gegen Veränderung. Sie sind Anforderungen mit Fingerabdrücken.
Nach dem Kauf sollte Nutzerfeedback in Änderungsmanagement und Belege einfließen. Korrekturen, Übersteuerungen, Eskalationen und Ablehnungsgründe sollten gemessen und diskutiert werden. Wenn Nutzer das System ignorieren, finden Sie heraus, ob es falsch, langsam, unvertraut, schlecht platziert, nicht an Anreizen ausgerichtet oder einfach weniger nützlich ist als die Beschaffungserzählung. Nutzung allein ist ein schwaches Wertmaß. Menschen nutzen schlechte Systeme, wenn sie dazu gezwungen werden, und meiden gute Systeme, wenn der umgebende Prozess sie dafür bestraft, Urteilsvermögen einzusetzen.
Nutzer verdienen auch Klarheit. Wenn KI-Ausgabe beratend ist, sagen Sie das. Wenn sie erforderlich ist, sagen Sie, wer die Entscheidung besitzt. Wenn Übersteuerungen willkommen sind, bestrafen Sie sie nicht als Abweichung. Wenn Belege verpflichtend sind, geben Sie Zeit, sie zu prüfen. Unternehmens-KI scheitert, wenn Nutzer zu menschlichen Puffern zwischen einem selbstbewussten Werkzeug und einer unklaren Institution werden. Das ist keine Adoption. Das ist Isolierung.
Der Exittest sollte vor dem Einstieg stattfinden
Exit ist die am meisten vernachlässigte Beschaffungsanforderung, weil niemand am Anfang über das Ende sprechen möchte. Doch Exit ist der Punkt, an dem Käufermacht real wird. Kann die Organisation mit Daten, Metadaten, Prompts, Konfigurationen, Evaluierungsaufzeichnungen, Audit-Logs, Nutzerfeedback, Modellausgaben, Korrekturpfaden und Löschbelegen abwandern, und zwar intakt. Kann sie das System abschalten, ohne die Fähigkeit zu verlieren, vergangene Entscheidungen zu erklären. Kann sie zu einem anderen Werkzeug migrieren, ohne Mitarbeiter zu bitten, das Gedächtnis der Institution Seite für Seite abzufotografieren.
Der Exittest sollte praktisch sein. Vor der Skalierung exportieren Sie einen repräsentativen Ausschnitt. Stellen Sie ihn woanders wieder her. Prüfen Sie Kennungen, Zeitstempel, Herkunft, Berechtigungen, Anhänge, Korrekturen und Entscheidungsaufzeichnungen. Verifizieren Sie, dass Belege lesbar bleiben. Prüfen Sie, ob die Vertragssprache der technischen Realität entspricht. Wenn der Export langsam, verlustbehaftet oder von maßgeschneiderter Lieferantenarbeit abhängig ist, bepreisen Sie diese Abhängigkeit. Hoffnung ist keine Exit-Strategie. Sie ist eine Stimmung mit schlechter Versionskontrolle.
Exit-Rechte verbessern auch die aktuelle Beziehung. Wenn Daten und Aufzeichnungen portabel sind, konkurrieren Lieferanten über Service und Wert statt über Gefangenschaft. Käufer werden weniger ängstlich gegenüber ehrlicher Bewertung. Interne Teams können mit Ersatz im Hinterkopf gestalten. Die Architektur wird sauberer, weil Bedeutung explizit sein muss. Exit ist kein Pessimismus. Es ist Hygiene.
Es gibt ein Beschaffungssprichwort, das darauf wartet, geschrieben zu werden: Kaufen Sie nie ein KI-System, das Sie nicht verlassen können, ohne zu vergessen, warum Sie es genutzt haben. Es ist zu lang für einen Becher, was wahrscheinlich zum Besten ist. Becher haben im Büroalltag schon genug zu verantworten.
Der Falle entkommen
Der Beschaffungsfalle zu entkommen erfordert keine heroische Neuerfindung. Es erfordert, den Mittelpunkt des Einkaufs vom Produkt auf das Arbeitssystem zu verlagern. Definieren Sie den Anwendungsfall präzise. Testen Sie echte Daten frühzeitig. Kalkulieren Sie den Prüfaufwand ein. Verlangen Sie Nachweise, die institutionelle Fragen beantworten. Behandeln Sie Änderungskontrolle als primäre Anforderung. Kaufen Sie Ausstiegsrechte. Beziehen Sie Nutzer als Fachexperten ein. Weisen Sie Verantwortung für Ergebnisse zu. Messen Sie Korrekturaufwand und Ausnahmelast. Lassen Sie Anbieter das System unter widrigen Bedingungen zeigen, denn widrige Bedingungen sind der Ort, an dem Unternehmenssoftware den Großteil ihres Lebens verbringt.
Das macht die Beschaffung anfangs weniger ordentlich. Es bringt Konflikte an die Oberfläche, die Checklisten zuvor verborgen haben. Datenverantwortliche werden Verpflichtungen entdecken. Die Rechtsabteilung wird betriebliche Details benötigen. Die Sicherheitsabteilung wird Nachweise verlangen. Der Betrieb wird Personal anfordern. Die Finanzabteilung wird Kosten sehen, die zuvor im Verborgenen lauerten. Gut. Versteckte Kosten sind immer noch Kosten, nur selbstgefällig.
Das Ziel ist nicht, den Einkauf dauerhaft zu verlangsamen. Es geht darum, den Einkauf ehrlich genug zu machen, damit die Umsetzung vorankommen kann. Ein klarer Betriebsvertrag reduziert spätere Auseinandersetzungen. Ein getesteter Datenpfad reduziert Integrationsüberraschungen. Ein realistisches Prüfmodell reduziert Adoptionsrituale. Ein funktionierender Ausstieg reduziert Angst. Beschaffung wird zu einem Weg, die Bedingungen für Wertschöpfung zu schaffen, statt zu einem Ritual, das das überzeugendste Versprechen auswählt.
Die Siegerdemo in der Eingangsgeschichte war nicht falsch. Sie war unvollständig. Sie zeigte die Antwort, nicht die Institution um die Antwort herum. Die Beschaffung von Unternehmens-KI muss lernen, diese institutionsbezogene Ebene zu kaufen: die unspektakulären Rechte, Aufzeichnungen, Rollen, Tests und Ausstiege, die aus einer Fähigkeit gesteuerte Arbeit machen. Andernfalls wird die Ausschreibung weiterhin Systeme auswählen, die bei der Vergabe fertig wirken und erst real werden, nachdem alle bereits vertraglich gebunden sind. Das ist eine teure Art zu lernen, was eine bessere Frage früher hätte herausfinden können.