In vielen österreichischen Unternehmen läuft KI gerade genau dort, wo sie am wenigsten verändert: neben der Arbeit. Ein Team nutzt ChatGPT für Formulierungen, die Buchhaltung bleibt in Excel hängen, das CRM wird weiter manuell gepflegt, und im ERP entstehen dieselben Handoffs wie vorher. Das wirkt modern, bringt aber operativ wenig. Eine tragfähige KI-Strategie beginnt nicht beim Tool, sondern bei Prozessen, Daten und Verantwortung.
Gerade im Mittelstand sehe ich immer wieder denselben Bruch. Die Geschäftsführung will schnelle Entlastung, die Fachbereiche wollen nichts kaputt machen, und die IT soll plötzlich alles sicher integrieren. Genau dort entscheidet sich, ob KI ein Assistenz-Tool bleibt oder in ERP, CRM und Accounting echten Nutzen liefert. Für Österreich ist das besonders relevant, weil die öffentliche Linie seit der Veröffentlichung der KI-Strategie der Bundesregierung am 15. November 2018 klar auf Forschung, Kompetenz und Transfer zielt, nicht auf isolierte Experimente (Bundesregierung, KI-Strategie).
Inhaltsverzeichnis
- Warum die meisten KI-Projekte im Mittelstand scheitern
- Geschäftsziele und Use Cases definieren
- Daten- und System-Audit als Fundament
- Architektur mit MCP-Layer und Connectoren aufbauen
- Governance und Compliance als Skalierungsvoraussetzung
- Rollout-Roadmap und Change-Management verbinden
- Die ersten 90 Tage konkret umsetzen
Warum die meisten KI-Projekte im Mittelstand scheitern
Ein typisches Szenario: Ein Unternehmen führt ein Chat-Tool ein. Die Mitarbeitenden testen es für Texte, E-Mails und Zusammenfassungen, nach ein paar Wochen sinkt die Nutzung wieder. Die eigentlichen Engpässe, Freigaben, Stammdatenpflege, Rechnungsprüfungen oder Angebotsprozesse, laufen unverändert weiter. Dann entsteht schnell der falsche Eindruck, KI funktioniere nicht, obwohl nur die falsche Ebene adressiert wurde.
Das Problem liegt selten beim Modell. Datenqualität, Datenverfügbarkeit und das Commitment des Top-Managements zählen in Unternehmensbefragungen zu den zentralen Treibern für KI im Mittelstand. Genau diese drei Faktoren fehlen in vielen Projekten, wenn KI als separate Spielwiese betrieben wird. Wer KI Strategie entwickeln ernst meint, muss deshalb die operative Einbettung von Anfang an mitdenken.
Isolierte Piloten lösen keine Prozessprobleme
Ein Pilot, der nicht an ERP, CRM oder Buchhaltung andockt, erzeugt meistens nur eine gute Demo. Der Nutzen bleibt dann auf Textgenerierung, Zusammenfassungen oder einzelne Recherchen begrenzt. Für die Organisation zählt aber, ob ein Vorgang schneller, sauberer und nachvollziehbarer wird.
Praktische Regel: Wenn ein KI-Use-Case keinen Schritt in einem realen Prozess ersetzt, entschärft oder automatisiert, ist er wahrscheinlich nur ein Demo-Fall.
Wer sich im Bau- oder Projektumfeld bewegt, kennt dieses Muster besonders gut. Ein praxisnaher Einstiegspunkt ist die Übersicht zu Bau-Software mit GAEB und KI, weil dort sichtbar wird, wie eng fachliche Datenstrukturen und Automatisierung zusammenhängen. Genau dort liegt die eigentliche KI-Frage, nicht im Chatfenster.
Fehlendes Management-Commitment bremst alles aus
Ohne klare Führung wird KI schnell zum Nebenthema zwischen Tagesgeschäft und IT-Roadmap. Dann fehlen Prioritäten, Ressourcen und die Entscheidung, welche Prozesse wirklich umgebaut werden sollen. Die Praxis in österreichischen und deutschen Mittelstandsunternehmen zeigt seit Jahren dasselbe Muster, erfolgreiche KI-Vorhaben brauchen eine Linie von oben, nicht nur Begeisterung in einzelnen Teams.
Mangelnde Datenreife stoppt Skalierung
Selbst gute Modelle scheitern, wenn Stammdaten widersprüchlich sind, Zugriffe unklar bleiben oder relevante Informationen in Silos stecken. Dann lässt sich nichts zuverlässig automatisieren, weil die Organisation der Maschine nicht genug vertrauen kann. Wer KI nicht zuerst auf Daten-Audit, Systemzugriffe und saubere Prozessanbindung stellt, baut auf unsicherem Fundament.
Geschäftsziele und Use Cases definieren
Bevor irgendein Modell ausgewählt wird, braucht das Unternehmen eine klare Antwort auf eine einfache Frage. Welches Geschäftsergebnis soll sich durch KI verbessern? Ohne diese Antwort bleibt jede Initiative beliebig, und Priorisierung wird zur Bauchentscheidung.
Von Prozessärger zu messbaren Zielen
Der beste Einstieg sind wiederkehrende, datenintensive oder fehleranfällige Abläufe. Dazu kommen manuelle Handoffs, also Übergaben zwischen Abteilungen, Systemen oder Personen, die heute Zeit kosten und Fehler erzeugen. Genau dort lohnt es sich, genauer hinzuschauen, weil sich Nutzen meist schneller nachweisen lässt.
Die Azure-Strategie empfiehlt, Automatisierungschancen in solchen Prozessen zu identifizieren, Kundenfeedback aus Supporttranskripten und NPS-Kommentaren zu sammeln und für jeden Use Case Ziel, gewünschtes Ergebnis und Erfolgsmetrik festzulegen (Microsoft Azure AI Strategy). Das ist in Österreich besonders nützlich, weil viele Fachbereiche sehr konkrete Engpässe kennen, aber keine saubere Formulierung dafür haben.
Ein brauchbarer Filter für echte Use Cases
Ein Use Case ist dann gut, wenn er drei Fragen überlebt. Erstens, ist der Prozess häufig genug, damit sich der Aufwand lohnt. Zweitens, liegen die relevanten Daten überhaupt vor. Drittens, kann das Ergebnis später in den Alltag integriert werden, statt nur separat angezeigt zu werden.
Ein Use Case ohne klaren Besitzer endet oft als Prototyp ohne Wirkung.
So priorisieren Teams sauberer:
- Geschäftsproblem benennen: Was genau kostet Zeit, Geld oder Qualität?
- Gewünschtes Ergebnis festlegen: Was muss nachher besser laufen?
- Erfolgsmetrik definieren: Woran erkennt das Team, dass es besser läuft?
- Technische Machbarkeit prüfen: Gibt es Daten, Schnittstellen und Prozesszugang?
- Abhängigkeiten klären: Wer muss im Alltag mitziehen?
Gute Use Cases kommen oft aus dem Alltag
Die stärksten Ideen kommen selten aus einer Innovationsfolie. Sie kommen aus Support-Transkripten, Rückfragen in der Buchhaltung, fehlerhaften Freigaben oder manuellen Doppelarbeiten. Wer dort systematisch sucht, findet meist weniger spektakuläre, aber wirtschaftlich sinnvollere Anwendungsfälle.
Für ki strategie entwickeln heißt das: Nicht mit der Technologie beginnen, sondern mit einer klaren Liste von Geschäftsproblemen. Erst wenn Nutzen, Datenlage und Prozessbezug zusammenpassen, lohnt sich die technische Vertiefung.
Daten- und System-Audit als Fundament
Wer ki strategie entwickeln will, muss zuerst wissen, wo Daten entstehen, wie sie durch die Organisation laufen und wo sie auf dem Weg unbrauchbar werden. In der Praxis zeigt sich genau dort die Schwachstelle, oft noch bevor das erste Modell überhaupt ausgewählt ist. Repräsentative Befragungen im DACH-Raum bestätigen, dass Datenqualität und Datenverfügbarkeit zu den entscheidenden Treibern zählen. Der eigentliche Aufwand liegt darin, die eigene Systemlandschaft nüchtern offenzulegen, statt sich auf Annahmen zu verlassen.
Was im Audit wirklich geprüft werden muss
Ein brauchbares Audit schaut nicht nur auf Datenbanken, sondern auf die gesamte Prozesskette. Welche Quelle ist führend, wo entstehen Dubletten, welche Felder werden wirklich gepflegt, und welche Systeme tauschen Daten sauber aus. Genau an dieser Stelle wird sichtbar, ob KI später in ERP-, CRM- und Accounting-Prozesse eingebettet werden kann oder nur als separates Zusatztool läuft.
Legacy- und On-Premise-Stacks wie BMD, DATEV, Navision oder Exact sind im DACH-Mittelstand Alltag. Das Problem ist selten die Technik an sich. Das Problem ist, dass Integrationen, Berechtigungen und Datenmodelle oft nicht so vorbereitet sind, dass ein KI-System sie im Betrieb zuverlässig nutzen kann.
Der Audit braucht drei klare Blickwinkel
Ein gutes Team prüft die Lage entlang von drei Fragen:
- Datenqualität: Sind Werte vollständig, konsistent und korrekt?
- Datenverfügbarkeit: Wer darf zugreifen, wie aktuell sind die Daten, und liegen sie in einer Form vor, die sich technisch verwenden lässt?
- Systemlandschaft: Wo sitzen die Prozesse, welche Schnittstellen existieren, und wo fehlen sie?
Genau deshalb zählt ein sauberer Blick auf die Architektur mehr als der Vergleich des nächsten Modells. Wenn die operativen Systeme nicht ordentlich angebunden sind, bleibt jede Automatisierung anfällig. In einem laufenden Unternehmen entscheidet nicht das LLM allein, sondern die Fähigkeit, einen Vorgang sicher durch die bestehenden Systeme zu ziehen.
Für die Ablage und Weiterentwicklung technischer Zielbilder ist ein interner Überblick zu Data Warehouse Solutions hilfreich, weil dort Datenhaltung, Zugriff und spätere Auswertbarkeit zusammen gedacht werden.
Einmal ehrlich auf die Machbarkeit schauen
Vor der Budgetfreigabe sollte das Team klar sehen, was heute schon funktioniert und was nicht. Das spart teure Umwege. Wer früh erkennt, dass ein Freigabeprozess nur halb digital ist oder ein CRM nur lückenhaft gepflegt wird, plant KI realistischer und baut sie später stabiler ein.
Für Prüfungen, Testumgebungen und die saubere Trennung von Workflows nutzen manche Teams auch externe Verifikations- oder Staging-Lösungen, etwa bei SMS- oder Identity-Checks, bevor sie produktive Prozesse koppeln. Für den Start hilft ein Blick auf virtual number for SMS verification, nicht als KI-Thema, sondern als Beispiel dafür, wie wichtig kontrollierte Systemzugänge in Integrationsprojekten sind.
Architektur mit MCP-Layer und Connectoren aufbauen
Wenn die Datenlage klarer wird, geht es an die Architektur. Genau hier scheitern viele Vorhaben, weil sie zu früh auf ein einzelnes Tool setzen und zu spät auf Governance, Schnittstellen und Betrieb achten. Ein MCP-Layer schafft die sichere, governte Zugriffsschicht zwischen Modellen und Unternehmenssystemen.
Warum der MCP-Layer den Unterschied macht
Der Model Context Protocol, kurz MCP, hilft dabei, KI nicht als isolierte Oberfläche, sondern als kontrollierte Zugriffsschicht zu denken. Modelle sprechen damit nicht direkt mit allen Systemen, sondern über definierte Connectoren und klar begrenzte Rechte. Das reduziert Wildwuchs und macht Auditierbarkeit überhaupt erst vernünftig möglich.
Praxisregel: Wer den Zugriff auf ERP, CRM und Finance nicht explizit trennt, baut keine Architektur, sondern eine Gefahr.
Ein sauberer Aufbau trennt drei Ebenen. Erstens die KI-Systeme und Modelle, zweitens den MCP-Layer als Zugriffsschicht, drittens die Connectoren zu ERP, CRM und Datenbanken. Darüber liegt Governance und Security als durchgehende Kontrolle, nicht als nachträgliches Kontrollkästchen.
Connectoren machen Legacy-Systeme nutzbar
Gerade in österreichischen und deutschen Mittelstandsunternehmen liegt viel Wert in gewachsenen Systemen. Diese Systeme müssen nicht ersetzt werden, um KI-fähig zu werden. Sie brauchen sichere Connectoren, die Daten lesbar machen, Schreibzugriffe steuern und Geschäftsregeln respektieren.
Dazu kommt die Frage nach Cross-Model-Betrieb. Teams arbeiten oft nicht nur mit einem Modell, sondern je nach Aufgabe mit Claude, ChatGPT oder Gemini. Das ist sinnvoll, wenn der Zugriff auf Daten und Prozesse im eigenen Stack bleibt und nicht vom einzelnen Anbieter abhängt.
Der interne Überblick zu Application Intelligence Platform passt hier gut, weil er die Verbindung zwischen Applikationen, Datenzugriff und produktionsnaher KI denkt. Genau diese Verbindung fehlt vielen Unternehmen noch.
Agents nur dort einsetzen, wo Workflows wirklich laufen
Interne Agents und AI Coworker bringen erst dann Wert, wenn sie mehr tun als Texte schreiben. Sie können wiederkehrende Back-office-Schritte, E-Mail-Anstösse oder Slack-basierte Freigaben orchestrieren, aber nur, wenn die Daten- und Rechtekette sauber ist. Sonst wird der Agent zum riskanten Zwischenlayer ohne echte Kontrolle.
Das Video zeigt eine passende technische Einordnung der Architektur:
<iframe width="100%" style="aspect-ratio: 16 / 9;" src="https://www.youtube.com/embed/4a4lX02EZuM" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>EU-Residenz, Client-Eigentum an Connectoren und ein eigener MCP-Layer sind keine Details. Sie entscheiden darüber, ob das Unternehmen später flexibel bleibt oder in eine neue Abhängigkeit rutscht.
Governance und Compliance als Skalierungsvoraussetzung
Viele Teams behandeln Governance wie einen Punkt, den man später klärt. In der Praxis ist sie oft die Eintrittskarte, damit KI überhaupt in operative Prozesse darf. Die österreichische Bundesregierung hat KI mit ihrer Strategie der Bundesregierung für Künstliche Intelligenz als politischen Rahmen für Innovation, Forschung und Anwendung verankert, und genau daraus ergibt sich für Unternehmen ein klarer Erwartungshorizont (BMIMI, Strategie der Bundesregierung für KI).
Governance schützt nicht nur, sie beschleunigt auch
Sobald KI in Finance, Operations oder Kundenprozesse eingreift, braucht es nachvollziehbare Freigaben, Protokolle und klare Verantwortlichkeiten. Wer das vor dem Rollout sauber festlegt, reduziert spätere Abstimmungsschleifen und nimmt dem Fachbereich viel Unsicherheit. Genau dort liegt der Hebel.
Unternehmensbefragungen zeigen, dass Top-Management-Commitment zu den drei entscheidenden Treibern für KI zählt. Governance funktioniert deshalb nicht als IT-Dokument, sondern als Führungsentscheidung. Wenn die Leitung nicht klar vorgibt, welche Risiken akzeptabel sind und welche nicht, bleibt KI ein Einzelversuch ohne Skalierung.
Audit-Trails müssen von Anfang an mitgedacht werden
In regulierten Prozessen braucht jede KI-Entscheidung eine Spur. Das heisst nicht, jede Ausgabe manuell zu kontrollieren. Es heisst, dass jede relevante Entscheidung später nachvollziehbar sein muss, mit den genutzten Daten, dem handelnden Agenten, der Freigabe und dem, was im System passiert ist.
So wird Governance praktisch:
- Rollen definieren: Wer darf konfigurieren, prüfen und freigeben?
- Protokollierung festlegen: Welche Aktionen werden revisionssicher gespeichert?
- Datenzugriffe begrenzen: Wer sieht was, und auf welcher Grundlage?
- Modellnutzung steuern: Welche Modelle sind für welche Aufgaben erlaubt?
- Ausnahmeprozess bauen: Wie werden Sonderfälle behandelt?
Compliance wird erst dann zur Bremse, wenn sie nachträglich angeklebt wird.
Für österreichische Unternehmen ist die klare Linie wichtig, dass KI-Strategie nicht nur Technik, sondern Standortfrage ist. Wer Governance sauber aufsetzt, kann später schneller skalieren, weil Fachbereiche und Revision die Lösung eher akzeptieren. Ein sinnvoller Einstieg in die organisatorische Seite ist ein strukturierter Rahmen wie bei KI-Schulung für Unternehmen, denn Führungskräfte und Engineering brauchen unterschiedliche Lernpfade, aber dieselbe Sprache.
Rollout-Roadmap und Change-Management verbinden
Ein Rollout scheitert selten an der Technik allein. In mittelständischen Unternehmen sehe ich viel öfter, dass ein gutes Modell im Pilotbetrieb bleibt, weil Alltag, Zuständigkeiten und Schulung nicht mitziehen. Fortschritt entsteht dort, wo Teams neue Arbeitsweisen direkt im Tagesgeschäft testen, anpassen und erst dann verbreitern.
Kleine Einheiten, klare Routinen, sichtbarer Fortschritt
Der Einstieg gehört in ein klar begrenztes Pilotprojekt. Dafür braucht es einen überschaubaren Use Case, einen Connector, einen Eigentümer im Fachbereich und einen technischen Ansprechpartner. Erst wenn dieser Ablauf im echten Prozess trägt, lohnt sich die Ausweitung.
Die Schulungs- und Change-Seite gehört von Anfang an dazu. Ein interner Einstieg über KI-Schulung für Unternehmen passt an dieser Stelle gut, weil Leadership und Engineering unterschiedliche Lernpfade brauchen. Führungskräfte brauchen Sicherheit bei Prioritäten, Risiken und Entscheidungen, Engineers brauchen wiederholbare Muster für Architektur, Logging und Freigaben, und beide Seiten brauchen dieselbe Sprache.
Was in der Praxis funktioniert
Kurze Training-Sprints wirken oft besser als lange Programme mit offener Agenda. Ein Sprint kann die Führung auf Zielbild, Risiken und Governance ausrichten, während das technische Team Connectoren, Prompt-Patterns und Prüfabläufe baut. Danach müssen beide Seiten im gleichen Review-Rhythmus bleiben, sonst entstehen wieder zwei Welten.
- Leadership Sprint: Ziele, Risiken, Prioritäten und Entscheidungswege klären.
- Engineering Sprint: Architektur, Connectoren und Logging umsetzen.
- Pattern Playbook: Wiederkehrende Muster dokumentieren, damit Teams nicht jedes Mal bei null anfangen.
- Async Execution: Aufgaben zwischen den Reviews eigenständig vorantreiben.
- Wöchentliche Reviews: Blocker entfernen, Scope nachschärfen, Ergebnisse prüfen.
Die operative Einbettung entscheidet am Ende mehr als der Pilot selbst. Ein Agent, der sauber mit ERP, CRM oder Accounting verbunden ist, verändert Arbeitsschritte, Freigaben und Verantwortlichkeiten. Genau dort zeigt sich, ob ein Unternehmen KI nur testet oder wirklich in die Abläufe integriert.
Skalierung heißt nicht nur mehr Use Cases
Skalierung bedeutet, dass ein funktionierendes Muster wiederholbar wird. Erst dann trägt es in weitere Abteilungen, weitere Systeme und weitere Geschäftsbereiche hinein. Erfahrungen aus Mittelstandsprojekten zeigen, dass Fortschritt entsteht, wenn Teams neue Arbeitsweisen direkt im Alltag testen und verbessern. Genau an dieser Stelle trennt sich ein einzelner Piloterfolg von einer echten KI Strategie entwickeln-Initiative.
Ein Team wird nicht AI-native, weil es viele Tools kennt. Es wird AI-native, weil es wiederholbare Arbeitsmuster beherrscht.
Die ersten 90 Tage konkret umsetzen
Die ersten drei Monate entscheiden, ob das Thema in Bewegung kommt oder wieder versandet. Deshalb braucht es einen engen Takt mit klaren Verantwortlichkeiten, statt einer offenen Innovationsagenda. Das Ziel ist ein produktiver Start, nicht ein perfekter Grossentwurf.
Woche für Woche vom Use Case zur Integration
In den ersten zwei Wochen sollte das Team die wichtigsten Geschäftsprobleme priorisieren und ein erstes Zielbild festziehen. Dazu gehören Status quo, Datenlage, Prozessgrenzen und eine klare Entscheidung, welcher Use Case als Pilot dient. Ohne diese Entscheidung zerfasert alles.
In Woche drei bis sechs steht das Daten- und System-Audit im Mittelpunkt. Das Team prüft, welche Datenquellen wirklich nutzbar sind, wo Zugriffe fehlen und welcher erste Connector technisch machbar ist. Danach folgt ein enger Prototyp mit klarer Erfolgsmessung.
Woche sieben bis zehn dienen der produktiven Einbettung. Hier wird der erste Agent oder Automatisierungsschritt in einen realen Back-office-Prozess gebracht, mit Logging, Freigaben und einem Verantwortlichen im Fachbereich. Der Rest ist kein Nebensatz, sondern Betrieb.
Die Deliverables müssen messbar sein
- Ein priorisierter Use Case: mit Geschäftsproblem, Ziel und Metrik.
- Ein dokumentiertes Daten-Audit: mit Quellen, Lücken und Risiken.
- Ein erster Connector: an ein reales ERP-, CRM- oder Finance-System.
- Ein produktiver Workflow: mit Protokollierung und klarer Zuständigkeit.
- Ein Review-Rhythmus: für Adoption, Qualität und nächste Erweiterung.
Wer jetzt richtig startet, spart später Wochen
Ein gutes Startteam verbindet Strategie, Implementierung und Adoption in einer Verantwortung. Genau so vermeiden Unternehmen die nächste Insellösung. Wenn die ersten 90 Tage sauber laufen, entsteht aus einem begrenzten Pilot schnell eine belastbare Roadmap für die ganze Organisation.
Specialty Tokens unterstützt Unternehmen dabei, KI direkt in ERP-, CRM- und Finance-Prozesse einzubauen, mit Training, Connectoren, MCP-Layer und produktionsnahen Agents. Wenn du KI Strategie entwickeln in deinem Unternehmen nicht als Chat-Pilot, sondern als operative Transformation angehen willst, schau dir Specialty Tokens an und sprich mit einem Team, das Strategie, Umsetzung und Adoption gemeinsam denkt.