Zugriff auf Daten ist nicht dasselbe wie Vertrauen in Daten. Ein Unternehmen kann auf drei Systeme zugreifen und trotzdem nicht wissen, welches davon stimmt. Genau das passiert, wenn ein CRM, ein ERP und ein Servicesystem denselben Kunden unterschiedlich erfassen: Die KI bekommt drei Wahrheiten und entscheidet sich für eine, ohne dass jemand merkt, welche.
Viele Systeme, die seit Jahren laufen, wurden nie für maschinellen Zugriff gebaut. Keine API, keine strukturierten Ausgaben, oft nicht einmal eine Dokumentation. Die Folge sind manuelle Zwischenschritte, die jeden Automatisierungsgewinn von Anfang an auffressen.

KI-Anwendungsfälle entstehen iterativ, durch ständiges Nachjustieren. Systeme, die nur zwei, drei Mal im Jahr ein Release bekommen, bremsen diesen Prozess aus. Was im klassischen IT-Betrieb als stabil galt, wird im KI-Kontext zum Hemmschuh.
Legacy-Systeme haben einen schlechten Ruf, oft zu Unrecht. In ihnen steckt jahrzehntelange Fachlogik: Sonderregeln, Ausnahmen, betriebliches Erfahrungswissen, das nirgendwo sonst dokumentiert ist. Wer ein System ablöst, ohne diese Logik zu verstehen, wirft das operative Gedächtnis der Firma weg, nicht nur alten Code.
Solange eine KI nur chattet, ist eine falsche Antwort ärgerlich, aber harmlos. Sobald sie auf interne Systeme zugreift, Daten liest oder Prozesse auslöst, wird sie zu einem privilegierten Akteur im Unternehmen, mit denselben Anforderungen an Rollen, Berechtigungen und Protokollierung wie ein Mensch. In der Praxis wird dieser Schritt regelmässig übersprungen, weil er weniger sichtbar ist als das KI-Modell selbst.
Keiner dieser sechs Punkte ist ein Technologieproblem im engeren Sinn. Es sind Grundlagenarbeiten, die unspektakulär sind und sich nicht gut in einer Produktdemo zeigen lassen. Genau deshalb werden sie übersprungen. Wer sie trotzdem zuerst angeht, investiert nicht in ein KI-Projekt, sondern in die Voraussetzung dafür, dass aus diesem Projekt mehr wird als ein gut aussehender Pilot.