KI im Unternehmen einführen: Roadmap vom Pilot zum Betrieb

Viele österreichische Unternehmen haben denselben Zwischenstand erreicht: Mitarbeitende testen ChatGPT oder andere Sprachmodelle, 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 Sie KI im Unternehmen einführen oder nur ein weiteres Werkzeug verteilen. Österreich lag 2025 bei 30 % KI-Nutzung unter Unternehmen mit mindestens zehn Beschäftigten, gegenüber 20 % im EU-Durchschnitt, wie Statistik Austria berichtet. Der Engpass ist also nicht mehr der erste Versuch, sondern die kontrollierte Verbindung von KI mit ERP, CRM, Finance und bestehenden Freigabeprozessen.

Dieser Leitfaden beschreibt den Weg vom ersten Use Case bis zum stabilen Betrieb: Auswahl, Architektur, Governance, Befähigung der Teams und ein 90-Tage-Plan. Welche Grundsatzentscheidungen davor stehen sollten, behandelt der Beitrag KI-Strategie entwickeln.

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 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. 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 an der Qualität des Modells. Sie scheitert daran, dass Kontext, Berechtigungen und nächste Aktionen außerhalb des Chats liegen. Mitarbeitende müssen Daten zusammensuchen, Ergebnisse bewerten und sie wieder in mehrere Systeme übertragen. Damit entstehen Medienbrüche, neue Fehlerquellen und eine zusätzliche Kontrollschicht.

Die Zahlen zeigen diese Lücke. Im EY KI Readiness Check 2026 setzen 69 % der befragten österreichischen Unternehmen KI zumindest in Piloten ein, aber nur 8 % haben sie unternehmensweit skaliert. Eine Tieto-Studie für Österreich kam 2026 zu dem Ergebnis, dass nur vier Prozent der Unternehmen KI vollständig in ihre Kernprozesse integriert haben.

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:

• 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 verteilten 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.

Den ersten Use Case richtig wählen

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

Beginnen Sie nicht mit der Frage, welches Modell eingesetzt werden soll. Prüfen Sie zuerst:

1. Wo entstehen wiederkehrende Übergaben? Suchen Sie 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.

Definieren Sie 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 in Euro umgerechnet 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.

Rückhalt der Führung entsteht, wenn die Entscheidung nicht als offene Technologiewette präsentiert wird. Zeigen Sie den konkreten Prozess, die betroffenen Rollen, die erwartete Veränderung und die Risiken. Betriebsrat, Datenschutz, Legal und Informationssicherheit gehören früh an den Tisch, besonders wenn Mitarbeitendendaten, Leistungsinformationen oder automatische Entscheidungen betroffen sind.

Go und No-Go nach dem Pilot

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

• Go: Die fachliche Qualität reicht, 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 auf Basis einer Befragung des Market Instituts als zentrale Hürden rechtliche Unsicherheiten (39 %), Fragen zur Vertraulichkeit von Unternehmensdaten (37 %), Vorbehalte bei Mitarbeitenden (27 %) und fehlende Kompetenzen (26 %), wie der WKO-Beitrag zur KI-Nutzung in Österreich zusammenfasst. Diese Punkte gehören in die Pilotentscheidung, nicht in eine spätere Risikoablage.

Technische Architektur mit MCP und Systemintegration

Ein produktiver KI-Prozess braucht eine kontrollierte Schicht zwischen Sprachmodell 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.

Das Model Context Protocol (MCP) ist ein offener Standard, über den Modelle definierte Werkzeuge und Datenquellen nutzen. Eine unternehmensweite MCP-Schicht stellt diese Werkzeuge bereit, prüft Identität und Berechtigung, begrenzt Aktionen und schreibt relevante Ereignisse in ein Audit-Log. Das Modell 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 eine saubere Trennung von Lesen und Schreiben.

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, sondern seine relevanten Fähigkeiten sicher für einen Prozess verfügbar zu machen. Mehr dazu im Beitrag zur Legacy-Modernisierung für ERP und CRM.

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.

Geschlossene SaaS oder offene Connector-Architektur

In der Praxis entsteht Lock-in selten 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 und kann je nach Aufgabe unterschiedliche Modelle einsetzen.

Geschlossene Lösungen sind nicht falsch. Für einen klar abgegrenzten Standardfall können sie der schnellere Weg sein. Sobald mehrere Systeme, Rollen und Freigaben zusammenkommen, trägt eine offene Architektur meist besser.

Eigentum statt verdeckter Abhängigkeit

Unternehmen sollten Connectoren, Skills und Konfigurationen selbst besitzen und warten können. Eine Plattform kann die Verwaltung vereinfachen, darf aber nicht zur Black Box werden. Jede Station eines Agenten 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 Architektur sollte von Anfang an Multi-Modell-Betrieb, EU-Datenresidenz, zentrale Protokollierung und klare Verantwortung für Connectoren unterstützen.

Datenschutz, Governance und EU AI Act

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, 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

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

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

Ein Audit-Log dokumentiert nicht nur, dass ein Agent aktiv war. Es zeigt, 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 Governance zu einem Betriebsmechanismus für Fehlersuche, interne Kontrollen und Haftungsfragen.

EU AI Act in den Betrieb übersetzen

Seit dem 2. Februar 2025 gelten die Verbote bestimmter KI-Praktiken nach Art. 5 AI Act. Ebenfalls seit diesem Datum verpflichtet Art. 4 Anbieter und Betreiber, für ausreichende KI-Kompetenz ihres Personals zu sorgen. Seit dem 2. August 2025 gelten zusätzlich die Pflichten für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck. Je nach Risikoklasse kommen für Ihre eigenen Anwendungen Transparenz-, Dokumentations- und Risikomanagementpflichten hinzu. Einen Überblick für österreichische Unternehmen gibt das Unternehmensserviceportal zum AI Act.

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. Ein ergänzender Security-Governance-Rahmen hilft, technische Kontrollen und organisatorische Verantwortlichkeiten zusammenzuführen.

Teams befähigen und die Einführung in Sprints 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äßige Reviews.

Ein Leadership-Training klärt Geschäftsziele, Risikoappetit, Investitionslogik und Verantwortlichkeiten. Engineers brauchen 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: 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.

Eingebettete Umsetzungssprints bringen diese Muster 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. Asynchrone Arbeit 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. Benennen Sie Champions in den Fachbereichen, geben Sie ihnen Zeit für Rückfragen, und machen Sie auch gescheiterte Versuche sichtbar. Vertrauen entsteht nicht durch die Behauptung, dass KI fehlerfrei arbeitet, sondern durch sichtbare Grenzen und schnelle Korrekturen.

Erfolg messen und KI nachhaltig verankern

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

Messen Sie deshalb drei Ebenen getrennt. Auf Prozessebene zählen Durchlaufzeit, manuelle Übergaben, Ausnahmequote und Datenvollständigkeit. Auf Qualitätsebene prüfen Sie fachliche Korrektheit, notwendige Nachbearbeitung und Freigabequote. Auf Betriebsebene beobachten Sie Fehlermeldungen, Berechtigungsverletzungen, Kosten und die Verfügbarkeit der angebundenen Systeme.

Ein umsetzbarer 90-Tage-Plan

Tage 1 bis 30: Wählen Sie einen Prozess, benennen Sie Owner und dokumentieren Sie den Ist-Ablauf. Klassifizieren Sie die Daten, definieren Sie Rollen, klären Sie die erlaubten Aktionen und legen Sie die Messgrößen fest.

Tage 31 bis 60: Bauen Sie den Connector, richten Sie die MCP-Schicht ein und lassen Sie den Agenten zunächst nur Entwürfe erstellen oder mit verpflichtender Freigabe arbeiten. Testen Sie Normalfälle, fehlende Daten, widersprüchliche Informationen und nicht verfügbare Systeme.

Tage 61 bis 90: Bewerten Sie die Ergebnisse mit Fachbereich, Legal, Datenschutz und IT. Entscheiden Sie anhand der Go-, Nachbesserungs- oder No-Go-Kriterien über den Ausbau. Dokumentieren Sie 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 die MCP-Schicht, Legal und Datenschutz die Kontrollanforderungen. Ein gemeinsames Review prüft Änderungen an Datenquellen, Modellen, Berechtigungen und Geschäftsregeln.

Wer jetzt nur weitere Chat-Lizenzen verteilt, vergrößert die Tool-Landschaft. Wer einen kontrollierten Prozess integriert, baut ein wiederverwendbares Fundament für Finance, CRM und Operations. Wie wir diesen Weg mit Unternehmen gehen, beschreibt unsere Seite zur KI-Implementierung in Wien.

Sprechen Sie mit uns

Wenn Sie KI aus dem Chat in einen produktiven Kernprozess bringen und dafür einen konkreten ersten Schritt planen wollen, sprechen Sie mit uns.