KI im Unternehmen einführen: Roadmap für echte Wirkung

Viele österreichische Unternehmen haben denselben Zwischenstand erreicht: Mitarbeitende testen ChatGPT oder andere LLMs, schreiben damit Texte, prüfen Dokumente und holen sich Ideen für Auswertungen. Gleichzeitig werden Rechnungen weiterhin manuell aus E-Mails in Finance-Systeme übertragen, Vertriebsdaten bleiben im CRM unvollständig und Freigaben wandern zwischen Excel, Slack und Postfach hin und her. Der Chat spart in einzelnen Aufgaben Zeit, aber der eigentliche Prozess bleibt unverändert.

Genau dort entscheidet sich, ob KI im Unternehmen einführen nur ein Innovationsthema bleibt oder messbare Wirkung erzeugt. Österreich lag 2025 bei 30 % KI-Nutzung unter Unternehmen mit mindestens zehn Beschäftigten, gegenüber 20 % im EU-Durchschnitt, wie Statistik Austria zur IKT-Nutzung 2025 berichtet. Der nächste Engpass ist deshalb nicht mehr der erste Versuch. Es geht um die kontrollierte Verbindung von KI mit ERP, CRM, Finance und bestehenden Freigabeprozessen.

Inhaltsverzeichnis

• Warum KI im Unternehmen oft im Chat stecken bleibt
  • Der Chat ist eine Oberfläche, kein Prozess
  • Wo der reale Hebel liegt
• Strategie und Leadership Buy-in richtig verankern
  • Mit einem kontrollierten Problem starten
  • Go und No-Go nach dem Pilot
• Technische Architektur mit MCP und Systemintegration aufbauen
  • Connectoren als wiederverwendbare Bausteine
  • Client Ownership statt verdeckter Abhängigkeit
• Datenschutz Governance und EU Residency sicher umsetzen
  • Datenzugriff in Klassen und Rollen ordnen
  • EU AI Act in den Betrieb übersetzen
• Teams befähigen und Einführung im Sprint skalieren
  • Vom Muster zur eigenständigen Umsetzung
• Erfolg messen und KI nachhaltig im Unternehmen verankern
  • Ein umsetzbarer 90-Tage-Plan

Warum KI im Unternehmen oft im Chat stecken bleibt

Ein typischer Mittelständler erhält eine Eingangsrechnung als PDF. Eine Person öffnet den Anhang, liest Lieferant und Betrag aus, sucht den Kreditor im ERP, prüft die Kostenstelle, trägt Daten ein und schickt den Vorgang zur Freigabe weiter. Ein Chatbot kann den Inhalt der Rechnung zwar zusammenfassen. Er ändert aber nichts daran, dass jemand den Prozess danach manuell ausführen muss.

Dasselbe Muster zeigt sich im Vertrieb. Ein Team lässt sich Kundenmails formulieren, doch die Gesprächsinformationen landen nicht zuverlässig im CRM. Operations erzeugt eine Analyse, aber die daraus abgeleitete Aufgabe wird nicht im Backoffice angelegt. Die KI liefert einen Text oder eine Empfehlung, während die Organisation weiterhin Übergaben, Kopieren und Nachkontrollen betreibt.

Der Chat ist eine Oberfläche, kein Prozess

Isolierte Chat-Nutzung scheitert nicht zwingend an der Qualität des Modells. Sie scheitert daran, dass Kontext, Berechtigungen und nächste Aktionen außerhalb des Chats liegen. Ein Mitarbeitender muss Daten zusammensuchen, Ergebnisse bewerten und sie wieder in mehrere Systeme übertragen. Damit entstehen Medienbrüche, neue Fehlerquellen und eine zusätzliche Kontrollschicht.

Die österreichischen Zahlen zeigen diese Lücke deutlich. Zwar nutzten 2025 bereits 30 % der Unternehmen KI, doch nur 4 % hatten KI vollständig in ihre Kernprozesse integriert. 60 % bewerteten die Integration als nicht sehr fortgeschritten, und nur 8 % planten den Einsatz in allen Kernprozessen, laut Statistik Austria zur Digitalisierung österreichischer Unternehmen.

Wo der reale Hebel liegt

Produktive Use Cases beginnen mit einem wiederkehrenden Engpass, nicht mit einem Modellnamen. Besonders geeignet sind Abläufe, bei denen Mitarbeitende Informationen aus mehreren Quellen zusammenführen, Regeln anwenden und anschließend eine klar definierte Aktion auslösen müssen:

• Finance: Rechnungen klassifizieren, Buchungsvorschläge vorbereiten und Freigaben mit Belegen verknüpfen.
• CRM: Kundenanfragen aus E-Mail oder Slack in strukturierte Vorgänge überführen und nächste Schritte anlegen.
• Operations: Lieferanteninformationen, Aufträge und interne Aufgaben aus fragmentierten Systemen koordinieren.
• Backoffice: Dokumente prüfen, Pflichtfelder erkennen und Vorgänge nach definierten Regeln weiterleiten.

Der Unterschied zwischen Demo und Betrieb ist die letzte Meile. Ein interner Agent muss nicht nur eine Antwort formulieren, sondern den richtigen Datensatz lesen, seine Berechtigung prüfen, eine Aktion ausführen und jeden relevanten Schritt protokollieren. Erst dadurch wird KI zu einem Bestandteil des Geschäftsprozesses.

Österreichische Unternehmen stehen dabei nicht am Anfang, aber auch noch nicht am Ziel. Bei kleinen Betrieben mit 10 bis 49 Beschäftigten lag die KI-Nutzung 2025 bei 18 %, bei mittleren Unternehmen bei 29 % und bei grossen Unternehmen bei 50 %, wie die Auswertung zur österreichischen KI-Nutzung zusammenfasst. Der sinnvolle Startpunkt ist deshalb eine Roadmap, die Prozesswirkung, Systemintegration und Governance gemeinsam plant.

Strategie und Leadership Buy-in richtig verankern

Die Auswahl des ersten Use Cases entscheidet über die Glaubwürdigkeit des gesamten Vorhabens. Ein generischer KI-Assistent erzeugt Aufmerksamkeit, aber selten einen belastbaren Nutzennachweis. Besser ist ein Prozess, der häufig vorkommt, manuelle Arbeit bindet, klare Eingangsdaten hat und ein überprüfbares Ergebnis liefert.

Mit einem kontrollierten Problem starten

Beginne nicht mit der Frage, welches Modell eingesetzt werden soll. Prüfe zuerst:

1. Wo entstehen wiederkehrende Übergaben? Suche nach Aufgaben zwischen E-Mail, ERP, CRM, DMS und Tabellen.
2. Welche Arbeit folgt festen Regeln? Je klarer die Prüf- und Freigabelogik, desto leichter lässt sich ein Pilot abgrenzen.
3. Wer trägt das Ergebnis? Finance, Operations oder Sales müssen fachlicher Owner sein, nicht nur die IT.
4. Welche Daten dürfen verwendet werden? Der Zugriff muss vor dem ersten Test geklärt sein.
5. Welche Aktion soll am Ende erfolgen? Eine Buchung, ein CRM-Eintrag, eine Freigabevorlage oder eine Eskalation ist messbarer als ein allgemeines Qualitätsversprechen.

Definiere für den Startprozess einen Ausgangswert, eine Zielrichtung und eine Qualitätsgrenze. Das können Bearbeitungsdauer, manuelle Übergaben, Korrekturaufwand, Fehlklassifizierungen oder die Vollständigkeit von Datensätzen sein. Nicht jede Kennzahl muss sofort monetarisiert werden. Sie muss aber zeigen, ob der Prozess nach dem Pilot besser kontrollierbar und effizienter läuft.

Praktische Regel: Ein Pilot ohne fachlichen Owner ist eine technische Demonstration. Ein Pilot mit Owner, Freigabegrenze und Abbruchkriterium ist ein Entscheidungsinstrument.

Leadership Buy-in entsteht, wenn die Entscheidung nicht als offene Technologiewette präsentiert wird. Zeige den konkreten Prozess, die betroffenen Rollen, die erwartete Veränderung und die Risiken. Der Betriebsrat, Datenschutz, Legal und Informationssicherheit gehören früh an den Tisch, besonders wenn Mitarbeitendendaten, Leistungsinformationen oder automatische Entscheidungen betroffen sind.

Ein Use-Case-Backlog hilft, Begeisterung zu ordnen. Jeder Eintrag enthält Prozess, Datenquellen, gewünschte Aktion, Verantwortliche, Risiko, Integrationsaufwand und Messgrösse. Die Roadmap für eine KI-Strategie kann dabei als ergänzende Orientierung dienen, entscheidend bleibt aber die Verbindung mit den tatsächlichen Systemen und Rollen im Unternehmen.

Go und No-Go nach dem Pilot

Nach dem Test sollte die Entscheidung nicht auf einer Demo beruhen. Prüfe stattdessen:

• Go: Die fachliche Qualität ist ausreichend, die Aktion lässt sich sicher ausführen, Nutzer akzeptieren den Ablauf und die Kennzahlen bewegen sich in die gewünschte Richtung.
• Nachbesserung: Der Use Case ist sinnvoll, aber Datenqualität, Berechtigungen oder Ausnahmebehandlung verhindern den stabilen Betrieb.
• No-Go: Der Nutzen bleibt unklar, der Prozess ist zu variabel oder das Risiko lässt sich mit vertretbarem Aufwand nicht beherrschen.

Die WKO nennt als zentrale Hürden rechtliche Unsicherheiten mit 39 %, Vertraulichkeitsfragen zu Unternehmensdaten mit 37 %, Vorbehalte von Mitarbeitenden mit 27 % und fehlende Kompetenzen mit 26 %, laut WKO-Studie 2026. Diese Punkte gehören in die Pilotentscheidung, nicht in eine spätere Risikoablage.

Technische Architektur mit MCP und Systemintegration aufbauen

Ein produktiver KI-Prozess braucht eine kontrollierte Schicht zwischen LLM und Kernsystemen. Ohne diese Schicht erhält ein Modell entweder zu viel Zugriff oder zu wenig Kontext. Im ersten Fall entsteht ein Sicherheitsproblem, im zweiten bleibt der Agent auf Vorschläge beschränkt.

Ein Enterprise MCP Layer kann diese Vermittlung übernehmen. Er stellt standardisierte Werkzeuge und Datenzugriffe bereit, prüft Identität und Berechtigung, begrenzt Aktionen und schreibt relevante Ereignisse in ein Audit-Log. Das LLM entscheidet dann nicht frei über beliebige Systemzugriffe. Es arbeitet mit klar definierten Tools, deren Eingaben, Ausgaben und Berechtigungen bekannt sind.

Connectoren als wiederverwendbare Bausteine

Ein Connector ist mehr als eine API-Verbindung. Er muss fachliche Objekte, Fehlerfälle und Berechtigungen abbilden. Für ein ERP gehören dazu etwa Lieferanten, Rechnungen, Bestellungen, Kostenstellen und Buchungsentwürfe. Im CRM sind Kunden, Kontakte, Aktivitäten und Verkaufschancen relevant. Finance verlangt zusätzlich Nachvollziehbarkeit, Freigabelogik und saubere Trennung von Lesen und Schreiben.

In der Praxis unterscheiden sich Systeme stark. BMD, DATEV, Navision, Exact und weclapp bringen eigene Datenmodelle, Schnittstellen und Betriebsbedingungen mit. Bei Legacy- oder On-Prem-Systemen kann ein Connector über vorhandene APIs, sichere Middleware oder klar begrenzte Import- und Exportprozesse arbeiten. Das Ziel ist nicht, jedes alte System zu ersetzen. Das Ziel ist, seine relevanten Fähigkeiten sicher für einen Prozess verfügbar zu machen.

Ein belastbares Integrationsmuster sieht so aus:

• Kontext laden: Der Agent ruft nur die für den Vorgang erforderlichen Daten ab.
• Regeln prüfen: Rollen, Datenklassifizierung und fachliche Bedingungen werden vor der Aktion bewertet.
• Aktion vorbereiten: Das System erstellt einen Entwurf oder eine strukturierte Änderung.
• Freigabe auslösen: Bei sensiblen oder irreversiblen Aktionen bestätigt eine berechtigte Person.
• Ergebnis protokollieren: Eingaben, verwendete Tools, Entscheidungen und Systemantworten bleiben nachvollziehbar.

Client Ownership statt verdeckter Abhängigkeit

Unternehmen sollten Connectoren, Skills und Konfigurationen selbst besitzen und warten können. Das verhindert, dass jede Prozessänderung an einen einzelnen Anbieter gebunden bleibt. Eine Plattform kann die Verwaltung vereinfachen, darf aber nicht zur Black Box werden.

Für die Orchestrierung reicht ein Chatfenster ebenfalls nicht aus. Ein interner Agent kann eine E-Mail klassifizieren, in Slack eine Rückfrage stellen, im ERP einen Entwurf erzeugen und im CRM eine Aktivität anlegen. Jede Station braucht definierte Zustände und Fehlerpfade. Wenn ein System nicht erreichbar ist oder ein Pflichtfeld fehlt, muss der Agent sauber stoppen und den Vorgang an eine zuständige Person übergeben.

Ein Enterprise-Automation-Ansatz mit MCP ist besonders dann sinnvoll, wenn mehrere Teams dieselben Integrationsmuster verwenden. Die technische Architektur sollte von Anfang an Multi-Modell-Betrieb, EU-Residency, zentrale Protokollierung und klare Verantwortlichkeit für Connectoren unterstützen.

Datenschutz Governance und EU Residency sicher umsetzen

Governance darf kein PDF sein, das nach dem Pilot in einem Intranet-Ordner verschwindet. Sie muss als technischer und organisatorischer Kontrollpunkt im Prozess sichtbar werden. Mitarbeitende sollen erkennen können, welche Daten ein Agent verwenden darf, welche Aktionen eine Freigabe benötigen und wer für das Ergebnis verantwortlich ist.

Datenzugriff in Klassen und Rollen ordnen

Beginne mit einer Datenklassifizierung, die im Alltag anwendbar ist. Öffentliche Informationen, interne Arbeitsdaten, vertrauliche Unternehmensdaten und besonders schützenswerte personenbezogene Informationen brauchen unterschiedliche Regeln. Ein Agent für allgemeine Produkttexte darf nicht automatisch auf Personalakten, Gehaltsdaten oder vollständige Kundendossiers zugreifen.

Das Berechtigungskonzept sollte sich an bestehenden Rollen orientieren. Ein Finance-Agent erhält beispielsweise Zugriff auf Rechnungsdaten und Kontierungsinformationen, aber nicht auf beliebige CRM-Notizen. Schreibaktionen werden enger gefasst als Lesezugriffe. Für jede Aktion müssen Zweck, Datenquelle, Nutzerrolle, Freigabeweg und Aufbewahrung des Protokolls definiert sein.

Ein Audit-Log dokumentiert nicht nur, dass ein Agent aktiv war. Es sollte nachvollziehbar sein, welcher Nutzer den Vorgang ausgelöst hat, welche Daten verwendet wurden, welches Modell und welches Tool beteiligt waren, welche Entscheidung getroffen wurde und ob ein Mensch freigegeben hat. So wird aus Governance ein Betriebsmechanismus für Fehlersuche, interne Kontrollen und Haftungsfragen.

EU AI Act in den Betrieb übersetzen

In Österreich gelten seit 1. Februar 2025 Schulungs- und Compliance-Pflichten für verbotene KI-Systeme. Unternehmen müssen Mitarbeitende nachweislich im Umgang mit KI schulen. Je nach Risikoklasse kommen Transparenz-, Dokumentations- und Risikomanagementpflichten hinzu, wie die österreichische Unternehmensinformation zum EU AI Act erläutert.

Praktisch braucht jedes produktive KI-System einen verantwortlichen Owner, eine dokumentierte Risikoeinstufung und einen definierten Review-Zyklus. Schulungen sollten nicht bei Prompting enden. Mitarbeitende müssen wissen, welche Daten sie eingeben dürfen, wie Ergebnisse geprüft werden und wann ein Vorgang eskaliert.

Datenschutz, Legal und Betriebsrat sollten Freigabekriterien gemeinsam festlegen. Eine kurze, verständliche Checkliste beschleunigt Projekte stärker als eine abstrakte Richtlinie. Wer zusätzlich die Datenschutzerklärung lesen möchte, findet dort einen konkreten Referenzpunkt für den Umgang mit personenbezogenen Daten. Ein ergänzender Security-Governance-Rahmen hilft, technische Kontrollen und organisatorische Verantwortlichkeiten zusammenzuführen.

Teams befähigen und Einführung im Sprint skalieren

Technik allein skaliert keine KI-Initiative. Teams müssen verstehen, welche Aufgaben ein Agent übernimmt, welche Entscheidungen bei ihnen bleiben und wie sie Fehler melden. Ein wirksames Rollout-Modell verbindet deshalb Training, eingebettete Umsetzung und regelmässige Reviews.

Ein Leadership-Training sollte Geschäftsziele, Risikoappetit, Investitionslogik und Verantwortlichkeiten klären. Engineers brauchen dagegen konkrete Muster für Connectoren, Tool-Schemas, Berechtigungen, Monitoring und Fehlerbehandlung. Fachbereiche lernen am eigenen Prozess. Diese Trennung ist wichtig, weil ein Management-Workshop keinen produktionsfähigen Connector baut und ein technisches Training keine Mitbestimmungsfrage löst.

Vom Muster zur eigenständigen Umsetzung

Ein Pattern Playbook hält wiederverwendbare Entscheidungen fest. Dazu gehören Namenskonventionen für Tools, Regeln für Human-in-the-Loop, Standardfelder im Audit-Log, Umgang mit Timeouts und Kriterien für Rollback. Dadurch startet nicht jedes Team mit einer neuen Architektur.

Embedded-Implementationssprints bringen diese Muster direkt in den Arbeitsalltag. Ein Engineer arbeitet mit Finance oder Operations am echten Prozess, baut den Connector, testet Ausnahmefälle und bespricht die Ergebnisse im Wochenreview. Async Execution hält Entscheidungen, offene Punkte und Testergebnisse transparent, ohne jeden Schritt in Meetings zu verlagern.

Change Management wird konkret, wenn Mitarbeitende an einem begrenzten Workflow sehen, was sich ändert. Benenne Champions in den Fachbereichen, gib ihnen Zeit für Rückfragen und veröffentliche auch gescheiterte Versuche. Vertrauen entsteht nicht durch die Behauptung, dass KI fehlerfrei arbeitet, sondern durch sichtbare Grenzen und schnelle Korrekturen.

Die österreichische Fachstudie zu KMU nennt geringe strategische Ausrichtung, unzureichende technische Infrastruktur, niedrige KI-Kompetenz und unausgereifte ethische Governance als kritische Hürden, wie der Practitioner Report zu KI in österreichischen KMU beschreibt. Trainingsprints adressieren Kompetenz und Strategie. Implementationssprints zeigen, ob Infrastruktur und Governance unter realen Bedingungen tragen.

Erfolg messen und KI nachhaltig im Unternehmen verankern

Ein produktiver Agent ist kein abgeschlossenes Projekt. Er wird Teil eines Betriebsmodells mit Ownership, Monitoring und regelmässiger Verbesserung. Wer nur die Anzahl gestarteter Piloten misst, belohnt Aktivität statt Wirkung.

Messe deshalb drei Ebenen getrennt. Auf Prozessebene zählen Durchlaufzeit, manuelle Übergaben, Ausnahmequote und Datenvollständigkeit. Auf Qualitätsebene prüfst du fachliche Korrektheit, notwendige Nachbearbeitung und Freigabequote. Auf Betriebsebene beobachtest du Fehlermeldungen, Berechtigungsverletzungen, Kostenkontrolle und die Verfügbarkeit der angebundenen Systeme.

Ein umsetzbarer 90-Tage-Plan

Tage 1 bis 30: Wähle einen Prozess, benenne Owner und dokumentiere den Ist-Ablauf. Klassifiziere die Daten, definiere Rollen, kläre die erlaubten Aktionen und lege die Messgrössen fest.

Tage 31 bis 60: Baue den Connector, richte den MCP Layer ein und führe den Agenten zunächst mit Entwürfen oder verpflichtender Freigabe aus. Teste Normalfälle, fehlende Daten, widersprüchliche Informationen und nicht verfügbare Systeme.

Tage 61 bis 90: Bewerte die Ergebnisse mit dem Fachbereich, Legal, Datenschutz und IT. Entscheide anhand der Go-, Nachbesserungs- oder No-Go-Kriterien über den Ausbau. Dokumentiere das Muster so, dass ein weiteres Team nicht bei null beginnen muss.

Ownership muss nach dem Rollout eindeutig bleiben. Der Fachbereich verantwortet die Prozesslogik, IT oder Engineering die Connectoren und den MCP Layer, Legal und Datenschutz die Kontrollanforderungen. Ein gemeinsames Review prüft Änderungen an Datenquellen, Modellen, Berechtigungen und Geschäftsregeln.

Die Ausgangslage rechtfertigt dieses Vorgehen. Laut Statistik Austria zur KI-Nutzung 2025 nutzten 30 % der österreichischen Unternehmen KI, während viele Unternehmen noch keine belastbare Roadmap für die Einführung haben. Wer jetzt nur weitere Chats verteilt, vergrössert die Tool-Landschaft. Wer einen kontrollierten Prozess integriert, baut ein wiederverwendbares Fundament für Finance, CRM und Operations.

Specialty Tokens unterstützt Unternehmen mit Training Sprints für Leadership und Engineers, individuellen Connectoren für ERP-, CRM- und Finance-Systeme sowie einem verwalteten Enterprise MCP Layer für sichere, auditierbare Automatisierung. Besuchen Sie Specialty Tokens, wenn Sie KI aus dem Chat in produktive Kernprozesse bringen und gemeinsam mit Senior Engineers einen konkreten Rollout starten möchten.