Die beliebteste Empfehlung bei KI-Implementierung ist immer noch falsch: erst ein Pilot, dann ein Tool, dann hoffen, dass der Rest des Unternehmens nachzieht. In der Praxis entsteht so nur eine weitere Insel neben ERP, CRM und Finance, nicht ein produktiver Betriebsmodus. In Österreich setzen zwar 69 % der Unternehmen KI zumindest in Pilotprojekten ein, doch nur 8 % haben KI bereits unternehmensbreit skaliert und erzielen messbare Effizienzsteigerungen, wie die aktuelle EY-Analyse zeigt (EY KI Readiness Check 2026). Genau dort scheitern die meisten Vorhaben, an der Anbindung an Kernprozesse, an Governance und an der Frage, wer die Verantwortung trägt.
Wer KI in regulierten Legacy-Umgebungen ernst nimmt, muss anders denken. Nicht als Chat-Experiment, sondern als Integrationsprojekt mit sauberer Systemgrenze, nachvollziehbaren Freigaben und einer Architektur, die Schreiben, Lesen und Auditierung trennt. Ohne das bleibt KI nett im Demo-Modus und teuer im Betrieb.
Inhaltsverzeichnis
- Warum KI Pilotprojekte in der Produktion scheitern
- Identifikation der richtigen Wertschöpfungshebel
- Daten und Systemvorbereitung für Legacy Umgebungen
- Auswahl von Modellen und Tooling ohne Lock in
- Sicherheit und Governance als Enabler
- Rollout Strategie und Change Management
Warum KI Pilotprojekte in der Produktion scheitern
Ein Pilot belegt nur, dass ein Modell in einem kontrollierten Rahmen brauchbare Antworten liefert. Er sagt noch nichts darüber aus, ob eine KI-Implementierung in ERP, CRM oder Finance mit Rollen, Freigaben, Logging und Rückschreiben stabil läuft.
Praxisregel: Sobald ein Use Case an Stammdaten, Berechtigungen oder Freigaben vorbeigeht, bleibt er ein Test.
Das klassische Muster ist schnell erzählt. Ein Fachbereich testet ein Chat-Interface, die Antworten wirken im Demo-Setup überzeugend, und beim Übergang in den Alltag brechen die Abhängigkeiten auf. Dann hängen Freigaben im Fachprozess, Daten kommen aus unterschiedlichen Systemen, und niemand klärt sauber, wer den Fehler im Zielsystem verantwortet. Genau daran scheitern viele Vorhaben in regulierten Legacy-Umgebungen.
Ein typischer Fehlschlag ist ein Assistent, der Rechnungen plausibel klassifiziert, im Test aber nie an ein ERP zurückschreibt, weil die Freigabe im Fachbereich, die Protokollierung im Audit-Log und die Systemberechtigung nie zusammen gedacht wurden. Solange nur die Oberfläche funktioniert, bleibt der operative Nutzen theoretisch. Genau deshalb ist die Frage der Production Readiness so wichtig, denn sie trennt einen belastbaren Betrieb von einer gut aussehenden Demo. Wer diese Grenze ignoriert, erzeugt Vorführungen, aber keine Entlastung im Tagesgeschäft.
Identifikation der richtigen Wertschöpfungshebel
Gute KI-Implementierung beginnt mit dem Prozess, der echten Geschäftswert bringt. Wer zuerst das Modell auswählt, optimiert oft auf Sichtbarkeit statt auf Wirkung. In regulierten Legacy-Umgebungen zählt aber nicht, was sich gut vorführen lässt, sondern was in ERP, CRM oder Finance sauber läuft und sich verantworten lässt.
Wo der Hebel wirklich liegt
Analysten bei Microsoft sehen das KI-Potenzial in Österreich vor allem in wenigen Sektoren konzentriert. Vier Sektoren, Herstellung von Waren, Handel, Finanz- und Versicherungswesen sowie freiberufliche und technische Dienstleistungen, stehen gemeinsam für 54,9 % des gesamten KI-Potenzials in Österreich (Microsoft Studie zu KI-Potenzial in Österreich). Für die Praxis heißt das, der Hebel verteilt sich nicht gleichmäßig über das Unternehmen.
Wer in einem mittelständischen Umfeld eine lange Ideensammlung vor sich hat, sollte nicht nach dem lautesten Use Case sortieren, sondern nach drei Fragen:
- Marge: Wo frisst jeder manuelle Schritt direkt Geld oder Zeit?
- Automatisierbarkeit: Welche Tätigkeiten folgen klaren Regeln oder wiederholen sich häufig?
- Datenverfügbarkeit: Wo liegen die nötigen Daten bereits in einem System, statt in Mails und Excel-Dateien zu verstreuen?
Backoffice, Buchhaltung und regulierte Leistungserbringung liefern oft mehr als sichtbare Assistenzfunktionen. Dort sind Prozesse stabiler, Daten strukturierter und der Effekt auf Durchlaufzeit oder Fehlerquote leichter nachweisbar.
Der Blick auf die Prozesskette ist wichtiger als der Blick auf ein einzelnes Tool. Ein Use Case, der keinen sauberen Anschluss an ERP, CRM oder Finance hat, bleibt ein Inselprojekt. Wer an eine bestehende Kette andockt, kann Freigaben, Prüfungen und Rückschreiben von Anfang an mitdenken.
Was in Österreich oft zu spät priorisiert wird
Viele Organisationen priorisieren zuerst Marketing oder Wissensarbeit, obwohl der stärkere Hebel in operativen Abläufen liegt. Genau hier trennt eine saubere Scoping-Phase belastbare Vorhaben von teuren Nebenprojekten. Erst wenn klar ist, welcher Prozess wirklich belastet, lohnt sich der Bau einer Connector-Architektur und eines produktiven MCP-Layers.
Praktischer Filter: Wenn ein Use Case keinen Besitzer, keine Datenquelle und keinen Zielprozess hat, ist er nicht bereit für den Pilot.
Wer so filtert, vermeidet Fehlinvestitionen in Assistenzfunktionen, die sich leicht demonstrieren lassen, aber kaum skalieren. Ziel ist nicht mehr KI im Unternehmen, sondern KI in den Prozessschritten, in denen Kosten, Risiko oder Durchlaufzeit entstehen.
Daten und Systemvorbereitung für Legacy Umgebungen
Legacy-Umgebungen scheitern selten an der Idee. Sie scheitern an der Kopplung. BMD, DATEV, Navision oder Exact laufen in vielen Unternehmen zuverlässig, aber nicht in einer Form, die ein LLM direkt und sicher versteht. Deshalb braucht es eine Connector-Architektur mit einer klaren Zwischenschicht.
Die Brücke zwischen LLM und Altsystem
Der erste Schritt ist die Bestandsaufnahme. Welche Systeme halten fachlich relevante Daten, welche dürfen lesen, welche dürfen schreiben, und wo entstehen die gefährlichen Schattenwege über CSV-Exports, manuelle Kopien oder E-Mail-Freigaben? Erst danach lohnt sich die technische Integration.
Dann folgt das Enterprise Model Context Protocol, kurz MCP, als definierte Zugriffsschicht. Dort wird festgelegt, welche Kontexte ein Modell sehen darf, wie Daten strukturiert übergeben werden und welche Aktionen nur nach Freigabe ausgelöst werden. Ohne solche Grenzen wird ein LLM nicht „intelligent“, sondern nur ungebremst.
Die technische Reihenfolge in der Praxis ist meist klar:
- Legacy-Systeme identifizieren. Nicht nur die Kernsysteme, auch angrenzende Excel-, Ticket- und DMS-Strukturen.
- Kontexte definieren. Welche Objekte, Felder und Prozesszustände braucht der Agent wirklich?
- API-Gateway und Connectoren implementieren. Hier entstehen die kontrollierten Lese- und Schreibpfade.
- Datenfluss validieren. Erst dann zeigt sich, ob Berechtigungen, Protokollierung und Rückschreiben funktionieren.
Wer die Architektur ernst nimmt, trennt technische Kopplung von fachlicher Logik. Genau das verhindert, dass jedes Modell-Update sofort zum Integrationsprojekt wird. In der Praxis heißt das auch, dass Lesezugriffe oft schneller produktiv werden als Schreibzugriffe, weil das Risiko anders gelagert ist.
Für Unternehmen mit mehreren Migrationen lohnt sich ein Blick auf IT-Systemintegration mit 19 Jahren Erfahrung, weil dort sichtbar wird, wie viel von einer sauberen Voranalyse abhängt. Wer die Modernisierungsschicht sauber aufsetzen will, findet einen hilfreichen Rahmen auch in der Legacy Modernization Strategy.
Warum Datenqualität der eigentliche Engpass bleibt
Statistik Austria nennt für Unternehmen ohne KI-Erfahrung als Hürden fehlende Fachkompetenz, rechtliche Unsicherheiten, Inkompatibilität mit bestehender Ausstattung und Probleme mit Datenverfügbarkeit oder Datenqualität (Statistik Austria 2023). In Legacy-Umgebungen ist das kein Nebensatz, sondern der Normalfall.
Wer daraus die falsche Konsequenz zieht und sofort ein Modell auswählt, baut auf unsauberem Fundament. Besser ist ein kurzer Audit vor dem ersten produktiven Prompt. Welche Stammdaten sind verlässlich, welche Prozesse sind stabil, und wo braucht es vor der KI erst Datenbereinigung oder Prozessnormalisierung?
Ein Modell kann nur mit dem arbeiten, was das System wirklich hergibt. Schlechte Daten werden nicht clever, nur weil ein LLM davor sitzt.
Genau deshalb sind Custom Connectors und MCP-Layer so wichtig. Sie machen Daten zugänglich, kontrollierbar, protokollierbar und organisatorisch anschlussfähig.
Auswahl von Modellen und Tooling ohne Lock in
In regulierten Legacy-Umgebungen entscheidet nicht die Marke des Modells, sondern die Frage, ob ERP, CRM und Finance später noch austauschbar angebunden werden können. Wer die Wahl auf Claude, ChatGPT oder Gemini verengt, prüft meist das falsche Kriterium. Wichtiger ist, ob Architektur und Betrieb mehrere Modelle tragen, ohne dass alles an einer Plattform hängt.
Cross Model statt Einheitswette
Eine Cross-Model-Strategie gehört im Enterprise-Kontext zur Grundausstattung. Sie senkt die Abhängigkeit von einem Anbieter, erlaubt die Zuordnung nach Aufgabe und verhindert, dass ein technischer oder kommerzieller Engpass den gesamten Betrieb blockiert. Für strukturierte Extraktion kann ein anderes Modell sinnvoll sein als für lange Kontextfenster oder Assistenzaufgaben im Fachbereich.
Die eigentliche Bindung entsteht oft nicht im Modell, sondern in der Tooling-Ebene. Wenn Connectoren, Skills und Integrationslogik beim Anbieter liegen, wird jeder Wechsel teuer und riskant. Besitzt das Unternehmen diese Schicht selbst, bleibt es handlungsfähig. Genau dort entstehen die meisten Lock-in-Effekte, in den Integrationen, Laufzeitabhängigkeiten und Freigabewegen.
| Kriterium | Geschlossene SaaS-Lösungen | Offene MCP- und Connector-Architektur |
|---|---|---|
| Modellwahl | Oft an einen Anbieter gebunden | Wechsel zwischen mehreren Modellen möglich |
| Integrationskontrolle | Begrenzte Sicht auf Datenflüsse | Eigene Regeln für Lesen, Schreiben und Freigaben |
| Betrieb | Schnell startklar, aber stark vorgeprägt | Mehr Setup, dafür an bestehende Prozesse anpassbar |
| Wechselkosten | Hoch, wenn Workflows wachsen | Niedriger, weil die Schicht beim Kunden liegt |
| Governance | Teilweise vorgegeben, teils unflexibel | Kontroll- und Audit-Logik intern steuerbar |
Was in der Praxis zählt
Tooling muss im Alltag tragen, nicht nur im Demo-Setup. Wer ERP, CRM und Finance anbinden will, braucht eine Schicht, die Kontext, Berechtigungen und Rückschreiben sauber verwaltet. Per-Seat-Lizenzen oder geschlossene Ökosysteme wirken am Anfang bequem, werden aber schnell zum Kosten- und Kontrollproblem, sobald der Rollout breiter wird.
Eine offene Architektur passt besser zu heterogenen Systemlandschaften, weil sie auf Integrationsfähigkeit statt auf Oberflächenkomfort baut. Das ist weniger spektakulär, aber in der Produktion meist die belastbarere Wahl. Gerade im Mittelstand trennt das oft einen Proof of Concept von einem System, das sich dauerhaft betreiben lässt.
Specialty Tokens ist in diesem Feld eine Option, wenn ein Team Connectoren, MCP-Anbindung und produktionsnahe Agenten selbst besitzen will, statt sie in einer fremden Plattform zu verlieren. Der Wert liegt nicht in der Oberfläche, sondern in der kontrollierten Anschlussfähigkeit an bestehende Systeme.
Entscheidungsregel: Wenn die Architektur keinen Anbieterwechsel aushält, ist sie zu eng für einen produktiven Rollout.
Sicherheit und Governance als Enabler
Viele Projekte behandeln Datenschutz und Cybersicherheit wie ein spätes Prüfthema. In regulierten Prozessen entscheidet genau das darüber, ob ein Agent überhaupt schreiben darf. Governance ist daher keine Bremse, sondern die Bedingung für produktiven Einsatz.
Warum Governance vor Geschwindigkeit kommt
Die österreichische Studie zu Entscheider:innen zeigt den Punkt klar. Als größte Hindernisse für die operative Verankerung wurden Datenschutz- und Rechtsfragen (50 %) sowie Datensicherheit und Cybersicherheit (46 %) genannt (E3 Magazin Studie). Wer KI in Finance oder CRM ausrollt, stößt genau dort auf die harte Grenze zwischen Pilot und Betrieb.
Für Schreibzugriffe braucht es deshalb Freigabeprozesse, Rollenmodelle und Protokollierung, bevor der erste Agent eine Buchung ändert oder einen Kundendatensatz anfasst. Ein Agent darf in solchen Umgebungen nicht frei handeln. Er braucht klare Grenzen, besonders bei Änderungen an Buchungen, Dokumentenstatus oder Stammdaten.
Die Trennung von Datenzugriff und Handlungskompetenz macht den Unterschied. Ein System kann lesen, ohne zu ändern. Es kann Vorschläge vorbereiten, ohne sie auszuführen. So wird Governance technisch prüfbar und bleibt nicht nur eine Policy auf Papier.
Was technisch abgesichert sein muss
Ein praxistauglicher Rahmen ist im Security Governance Framework gut beschrieben, weil dort technische Kontrollen und Organisationsstruktur zusammen gedacht werden.
Die wichtigsten Kontrollen sind nüchtern, aber wirksam:
- Rollen und Berechtigungen: Wer darf sehen, wer darf vorbereiten, wer darf freigeben?
- Audit-Trails: Jede Aktion braucht Nachvollziehbarkeit, nicht nur das Ergebnis.
- Incident Response: Ein Fehler muss stopbar und rückrollbar sein.
- Datenresidenz und Zugriffskontrolle: Bei sensiblen Workflows darf die Architektur nicht beliebig sein.
Wer diese Schicht sauber baut, reduziert Kontrollverlust für die Fachbereiche. Genau das beschleunigt den Rollout. Compliance läuft dann nicht neben dem System her, sondern steckt in seiner Laufzeitlogik.
Rollout Strategie und Change Management
Die Skalierung scheitert oft nicht am Modell, sondern am Betrieb. Ein KI-System verändert erst dann etwas, wenn Fachbereiche, IT und Führung dieselben Regeln für Nutzung, Freigabe und Eskalation tragen. In regulierten Legacy-Umgebungen wie ERP, CRM oder Finance zählt genau diese gemeinsame Linie, weil ein Connector nur dann nützt, wenn der Prozess dahinter funktioniert.
Upskilling vor breiter Freigabe
Statistik Austria nennt den Mangel an KI-Kompetenzen als zentrales Umsetzungshemmnis. Unternehmen geben auch an, KI nicht zu nutzen, weil ihnen das nötige Know-how fehlt (APIA Data zu KI Skills Barriere). In der Praxis ist das meist kein reines Trainingsthema, sondern ein Strukturproblem. Teams wissen oft nicht, was sie übergeben sollen, wer Änderungen prüft und wie neue Workflows dokumentiert werden.
Kurze, wiederholbare Training Sprints funktionieren deshalb besser als einmalige Schulungen. Fachbereiche lernen dabei, wo ein Agent nur Vorschläge liefert und wo menschliche Freigabe nötig bleibt. IT-Teams lernen, wie Connectoren, Protokolle und Ausnahmen im Alltag gepflegt werden, ohne dass der Betrieb ins Stocken gerät.
Was im Rollout wirklich hilft
Ein brauchbarer Rollout baut auf drei Dingen auf:
- Pattern Playbook. Wiederverwendbare Muster für Freigaben, Rückschreiben und Eskalationen.
- Interne Agenten. Kleine, klar umrissene Workflows statt überladener Universal-Agenten.
- Verantwortungsübergabe in Stufen. Erst begleiten, dann überwachen, dann freigeben.
So entsteht Vertrauen, weil niemand ein black box System bedienen muss. Die Fachseite sieht, was der Agent tut. Die IT sieht, wo Logs und Berechtigungen greifen. Die Führung erkennt, dass der Rollout nicht von einzelnen Personen abhängt, die im Ausnahmefall alles manuell retten.
Betriebsfähigkeit entscheidet am Ende über Akzeptanz. Wenn ein Unternehmen seine Connectoren, Skills und Governance intern beherrscht, wird KI Teil der normalen Prozesslandschaft. Specialty Tokens unterstützt diesen Schritt mit Implementierung, Integrationsschicht und produktionsnahen Agenten für bestehende Systemumgebungen.
Wenn Sie KI-Implementierung in ERP, CRM oder Finance nicht als Demo, sondern als Betriebsmodell aufsetzen wollen, besuchen Sie Specialty Tokens. Dort geht es um Connectoren, MCP-Schichten und produktionsreife Agenten für reale Legacy-Umgebungen.