Ein österreichischer Mittelständler hat drei KI-Chatbot-Piloten, ein Dokumenten-Extraktionsprojekt und weiterhin manuelle ERP-Buchungen. Die Mitarbeitenden kopieren Daten aus E-Mails in Excel, prüfen Rechnungen in mehreren Systemen und warten auf Freigaben, obwohl die KI daneben bereits Antworten formuliert. Das Problem ist nicht fehlende Begeisterung. Die KI wurde neben den Prozessen eingesetzt, nicht in ihnen.
Genau hier entscheidet sich, ob Prozessautomatisierung mit KI operative Wirkung erzeugt oder als weitere Einzellösung endet. Ein Chatbot kann Informationen liefern. Ein produktiver Agent muss dagegen Daten aus dem Postfach lesen, einen Beleg mit Bestellung und Wareneingang abgleichen, eine Freigabe vorbereiten, die richtige ERP-Aktion auslösen und jeden Schritt nachvollziehbar protokollieren. Dieser Artikel zeigt, wie österreichische Unternehmen vom Pilotprojekt zum kontrollierten Kernprozess kommen.
Inhaltsverzeichnis
- Warum KI neben der Arbeit nicht mehr reicht
- Was Prozessautomatisierung mit KI wirklich bedeutet
- Technische Bausteine einer produktiven KI-Automatisierung
- Anwendungsfälle in Finance, HR und Operations
- Risiken, Compliance und Auditierbarkeit richtig aufsetzen
- Fahrplan zur Einführung und Skalierung im Mittelstand
- Entscheidungshilfen und nächste Schritte für 2026
Warum KI neben der Arbeit nicht mehr reicht
Im beschriebenen Unternehmen war jeder Pilot für sich plausibel. Der erste Chatbot beantwortete interne Fragen, der zweite half beim Formulieren von Kundenantworten, der dritte fasste Dokumente zusammen. Das Extraktionsprojekt erkannte zwar Inhalte aus Rechnungen, übergab sie aber nicht zuverlässig an Buchhaltung und ERP. Am Ende blieb der entscheidende Arbeitsschritt beim Menschen: prüfen, übertragen, buchen und nachfassen.
Diese Situation wiederholt sich in vielen Betrieben. Teams kaufen oder entwickeln KI-Funktionen, ohne vorher festzulegen, welche Transaktion am Ende automatisch oder teilautomatisch stattfinden soll. Die Lösung sitzt dann im Browser, während die Wertschöpfung in BMD, SAP, Microsoft Dynamics, Salesforce, E-Mail-Postfächern und Freigabeprozessen liegt.

Warum klassische RPA-Lösungen an Grenzen stoßen
Klassische Robotic Process Automation, kurz RPA, arbeitet mit festen Abläufen. Ein Bot klickt Felder an, kopiert Werte und wartet auf bestimmte Bildschirme. Das funktioniert bei stabilen Oberflächen und klaren Regeln. Sobald ein ERP-Release ein Feld verschiebt, ein Lieferantenportal sein Layout ändert oder ein Beleg anders strukturiert ist, bricht die Annahme hinter dem Skript.
KI ersetzt RPA dabei nicht automatisch. Für deterministische Schritte bleibt eine klassische Regel oft zuverlässiger, günstiger und leichter prüfbar. Der Unterschied liegt in der Orchestrierung: Ein KI-Agent kann Inhalte interpretieren, Unsicherheit erkennen und den nächsten erlaubten Schritt auswählen. Die eigentliche Buchung sollte danach über eine kontrollierte Schnittstelle erfolgen, nicht über einen unkontrollierten Mausklick.
Praktische Regel: Automatisiere keine Antwort, wenn eigentlich eine Transaktion gebraucht wird.
Der Engpass liegt deshalb selten nur bei der Modellqualität. Er liegt in fehlenden Verbindungen zu Buchhaltung, CRM, HR und Legacy-Systemen, in unklaren Berechtigungen sowie in fehlenden Audit-Trails. Der österreichische KI-Einsatz wächst deutlich, aber die Umsetzung bleibt oft punktuell. Laut Statistik Austria nutzten 2025 30 % der Unternehmen mit mindestens zehn Beschäftigten KI-Technologien, nach 20 % im Jahr 2024, 11 % im Jahr 2023 und 9 % im Jahr 2021. Innerhalb von vier Jahren hat sich die Nutzung damit mehr als verdreifacht.
Der nächste Reifegrad entsteht erst, wenn Agenten Freigaben vorbereiten, Transaktionen auslösen und Kontrollspuren schreiben. Das Ziel ist kein intelligenter Bildschirm neben der Arbeit. Das Ziel ist ein belastbarer Ablauf von der eingehenden Information bis zur geprüften Aktion im Kernsystem.
Was Prozessautomatisierung mit KI wirklich bedeutet
Prozessautomatisierung mit KI besteht aus drei Schichten. Erstens nimmt ein Modell Informationen wahr, etwa eine E-Mail, einen Vertrag, eine Rechnung oder eine freie Anfrage. Zweitens entscheidet ein Agent anhand von Ziel, Kontext, Regeln und Berechtigungen, welcher nächste Schritt zulässig ist. Drittens führt ein Connector oder ein strukturiertes Tool die Aktion in einem Zielsystem aus.
Diese Definition trennt drei Dinge, die im Markt ständig vermischt werden:
| Merkmal | RPA | Chatbot / Copilot | Prozessautomatisierung mit KI |
|---|---|---|---|
| Primäre Funktion | Feste Klick- und Datenfolgen | Antworten, Zusammenfassen, Generieren | Zielorientierte Ausführung über mehrere Systeme |
| Umgang mit unstrukturierten Daten | Begrenzt | Stark bei Text und Sprache | Interpretation plus kontrollierte Folgeaktion |
| Systemzugriff | Meist UI-basiert | Oft nur lesend oder indirekt | APIs, MCP-Tools und definierte Aktionen |
| Fehlerbehandlung | Skript stoppt oder folgt Regel | Nutzer entscheidet manuell | Eskalation, Freigabe oder alternative Route |
| Kontrolle | Technisches Log des Bots | Chatverlauf | Versionierte Entscheidungen, Tool-Logs und ERP-Nachweis |
| Ergebnis | Klicks werden schneller | Information wird schneller verfügbar | Prozessschritt wird abgeschlossen oder sauber übergeben |
Ein Chat ist damit eine Oberfläche, keine Automatisierung. Wenn ein Copilot eine Rechnung erklärt, aber keine Bestellung abruft, keinen Wareneingang prüft und keine Freigabe vorbereitet, ist der Informationsschritt verbessert. Der Finanzprozess läuft trotzdem weiter wie zuvor.
Die österreichischen Daten zeigen, warum diese Unterscheidung wichtig ist. 2024 verwendeten laut Statistik Austria 32 % der KI-nutzenden Unternehmen KI für Prozessautomatisierung oder assistierte Entscheidungsunterstützung. Gleichzeitig lag Text Mining bei 65 % der KI-Nutzer. Der typische Weg ist sinnvoll: Unstrukturierte Dokumente, E-Mails und Belege werden zuerst klassifiziert, danach in einen Workflow überführt. Der Workflow darf aber nicht bei der Klassifizierung enden.
Das eigentliche Schlachtfeld liegt im Backoffice
ERP, CRM und Buchhaltung enthalten die Vorgänge, die Geld bewegen, Verpflichtungen erzeugen und Prüfungen auslösen. Dort entstehen Bestellungen, Rechnungen, Personalakten, Servicefälle und Lieferantenentscheidungen. Genau deshalb muss der Automatisierungsentwurf vom Geschäftsergebnis zurück zum Modell führen.
Die passende Arbeitsdefinition lautet:
KI-Prozessautomatisierung ist die kontrollierte Ausführung eines Geschäftsziels über mehrere Systeme, bei der KI unstrukturierte Informationen verarbeitet, Regeln und Kontext berücksichtigt und jede kritische Aktion nachvollziehbar ausführt oder zur Freigabe vorlegt.
Wer den Einstieg vertiefen will, findet bei Stay Digital einen praxisnahen Leitfaden zum Schritt für Schritt automatisieren. Entscheidend bleibt aber die Reihenfolge: erst Prozess, Datenanker und Zielaktion klären, dann Modell und Agent auswählen.
Technische Bausteine einer produktiven KI-Automatisierung
Eine produktive Architektur ähnelt einem Nervensystem. Konnektoren sind die Sinnesorgane, die Daten lesen und Aktionen schreiben. MCP ist das Rückenmark, das Tools und Kontext standardisiert. Interne Agenten bilden das Gehirn, das Ziele in Schritte übersetzt. Governance wirkt wie ein Immunsystem, das riskante Aktionen blockiert, Zuständigkeiten prüft und Spuren hinterlässt.
Konnektoren lösen den Schnittstellenbruch
Ein Connector verbindet den Agenten mit SAP, BMD, Salesforce, DATEV-ähnlichen Systemen, Microsoft Dynamics, E-Mail-Postfächern oder OCR-Pipelines. Er definiert nicht nur, wie Daten gelesen werden, sondern auch, welche Schreibaktionen erlaubt sind. Ein guter Connector liefert strukturierte Antworten, prüft Berechtigungen und gibt Fehler an die Orchestrierung zurück.
Der häufigste Architekturfehler ist, mit dem LLM zu beginnen. Beginne mit einer Schnittstellenkarte:
- Datenquellen: Wo entsteht die Information?
- Datenanker: Welche ID verbindet E-Mail, Auftrag, Rechnung und Buchung?
- Aktionen: Welche Schreibvorgänge sind erlaubt?
- Berechtigungen: Wer darf lesen, vorbereiten, freigeben oder buchen?
- Ausnahmen: Wann muss ein Mensch übernehmen?
MCP beendet das Tool-Chaos
Eine MCP-Schicht stellt Werkzeuge und Kontext in einer standardisierten Form bereit. Der Agent muss dann nicht für jeden Prozess ad hoc mit individuellen Funktionsaufrufen umgehen. Ein Tool kann etwa „Bestellung abrufen“, „Wareneingang prüfen“ oder „Zahlungslauf zur Freigabe vorlegen“ anbieten, jeweils mit klaren Parametern und Rückgabewerten.
MCP ist kein Freibrief für Agenten. Es schafft eine kontrollierte Vermittlung zwischen Modell und Unternehmenssystem. Die Tool-Schicht sollte nur Aktionen exponieren, die fachlich beschrieben, technisch abgesichert und organisatorisch verantwortet sind.
Agenten orchestrieren Ziele statt Klickfolgen
Ein interner Agent erhält ein Ziel, Kontext und Grenzen. Er kann eine eingehende Rechnung klassifizieren, fehlende Daten anfordern, einen Abgleich durchführen und bei Abweichungen eskalieren. Er sollte jedoch nicht selbstständig neue Zahlungsbedingungen erfinden oder eine ungeprüfte Buchung durchführen.
Typische Stacks im österreichischen Mittelstand kombinieren Microsoft und Azure mit n8n, bestehenden ERP-APIs und eigenen Python-Services. Auch eine Plattform wie Specialty Tokens Enterprise Automation Platform kann als Referenz für eine zentral verwaltete Integrations- und Agentenschicht dienen. Die Auswahl richtet sich nach Hosting, Datenresidenz, vorhandenen Systemen und dem gewünschten Grad an Eigenbetrieb.

Governance muss von Anfang an dazugehören. Eine Policy-Engine kann bestimmte Beträge, Personaldaten oder Lieferantenänderungen immer zur manuellen Freigabe schicken. Ein Audit-Log speichert Eingabe, Modellversion, verwendete Tools, Entscheidung, Nutzerfreigabe und Ergebnis. Ohne diese Ebene entsteht ein schneller, aber nicht belastbarer Prozess.
Wer die Architektur als Video nachvollziehen möchte, sollte auf die Reihenfolge von Systemzugriff, Tooling und Kontrollpunkten achten.
<iframe width="100%" style="aspect-ratio: 16 / 9;" src="https://www.youtube.com/embed/M-ilXR0B5BA" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>Anwendungsfälle in Finance, HR und Operations
Finance, HR und Operations brauchen nicht dieselbe Automatisierungslogik. In Finance zählt die Transaktionssicherheit, in HR die Nachvollziehbarkeit einer sensiblen Entscheidung, in Operations die Verbindung von Echtzeitdaten und praktischer Disposition. Ein guter Agent übernimmt deshalb nicht überall gleich viel.
Finance verlangt kontrollierte Transaktionen
Bei Eingangsrechnungen kann KI den Inhalt erfassen, Lieferant und Bestellbezug erkennen und Abweichungen markieren. Der klassische 3-Wege-Abgleich zwischen Bestellung, Wareneingang und Rechnung lässt sich mit strukturierten ERP-Daten verbinden. Die KI interpretiert unklare Dokumente, die Regel- und Connector-Schicht entscheidet über den nächsten Schritt.
Eine Zahlung sollte nicht allein wegen einer Modellantwort ausgelöst werden. Der Agent kann einen Zahlungslauf vorbereiten, fehlende Freigaben identifizieren und die zuständige Person benachrichtigen. Die finale Freigabe bleibt bei der definierten Rolle. Auch die Vorbereitung einer Umsatzsteuervoranmeldung in BMD oder SAP braucht Quellenbezug, Prüfschritte und eine dokumentierte Verantwortlichkeit.
Für Teams, die Finance nicht als Dokumentenprojekt, sondern als zusammenhängende Kontrollkette betrachten, bietet Finance Process Automation einen passenden thematischen Anknüpfungspunkt.
HR braucht Zurückhaltung bei Entscheidungen
In HR kann ein Agent Lebensläufe nach vorab definierten Kriterien strukturieren, fehlende Unterlagen anfordern, Vertragsentwürfe vorbereiten und Onboarding-Aufgaben an IT, Führungskraft und Personalverrechnung verteilen. Der Mensch prüft, ob Kriterien sachlich gerechtfertigt sind und ob die vorgeschlagene Behandlung zur Person und zum Kontext passt.
Vollautomatisierte Personalauswahl oder algorithmische Leistungsbewertung sind keine geeigneten Schnellgewinne. DSGVO, Gleichbehandlungsanforderungen, der EU AI Act und die Einbindung des Betriebsrats verlangen eine klare Zweckbindung, Transparenz und menschliche Kontrolle. Besonders wichtig ist, dass das System keine scheinbar objektiven Kriterien verwendet, die indirekt diskriminierende Merkmale abbilden.
Operations muss mit Ausnahmen umgehen können
In Operations kann KI Wartungshinweise aus Maschinendaten und Serviceberichten zusammenführen, Lieferantenrisiken strukturieren oder Außendiensttermine anhand von Fähigkeiten, Ort und Dringlichkeit vorschlagen. Die Automatisierung gewinnt an Qualität, wenn sie nicht nur einen Plan erstellt, sondern auch erkennt, wann Material fehlt, ein Termin nicht realistisch ist oder ein Lieferantendatensatz widersprüchlich ist.
Die technische Aktion kann dann in ERP, Field-Service-System oder CRM erfolgen. Der Mensch greift ein, wenn die Entscheidung finanzielle, sicherheitsrelevante oder arbeitsrechtliche Folgen hat.
| Funktion | Top-Anwendungsfall | Ziel-Automatisierungsgrad | Datenanker | Compliance-Grenze in AT/EU |
|---|---|---|---|---|
| Finance | Rechnung, Abgleich und Freigabevorbereitung | Hoher Anteil bei Erfassung und Routing, menschliche Freigabe bei kritischen Aktionen | Bestellung, Wareneingang, Rechnung, Lieferant | Nachvollziehbarkeit, Berechtigungen, Vier-Augen-Prinzip |
| HR | Bewerbungs- und Onboarding-Workflow | Strukturierung und Administration weitgehend automatisierbar | Bewerbungsakte, Vertrag, HR-Stammdaten | DSGVO, Gleichbehandlung, AI Act, Betriebsrat |
| Operations | Disposition, Wartung und Lieferantenprüfung | Vorschlag und Routing automatisierbar, Ausnahmen bleiben kontrolliert | Auftrag, Asset, Standort, Servicefall | Sicherheit, Haftung, Datenqualität und menschliche Entscheidung |
Risiken, Compliance und Auditierbarkeit richtig aufsetzen
Mehr KI erzeugt nicht automatisch mehr Automatisierung. Wenn Stammdaten widersprüchlich sind, Rollen fehlen und jede Ausnahme an eine Einzelperson geht, skaliert auch ein gutes Modell nicht. Laut Apptrade zur KI-Nutzung in Österreich berichten 61 % der österreichischen Unternehmen von minimalen bis keinen Produktivitätsgewinnen durch KI, während 63 % keine standardisierten Prozesse zur Sicherstellung konsistenter Daten haben. Das ist kein Modellproblem. Es ist ein Betriebs- und Kontrollproblem.

Kontrollen gehören in den Prozess
Ein Wirtschaftsprüfer braucht nicht nur das Endergebnis. Er muss nachvollziehen können, welche Quelle verwendet wurde, welcher Regel die Entscheidung folgte und wer die Aktion freigegeben hat. Ein Betriebsrat braucht zusätzlich Klarheit darüber, welche Personaldaten verarbeitet werden, welche Entscheidungen das System beeinflusst und wo menschliche Kontrolle stattfindet.
Die technische Umsetzung sollte mindestens diese Kontrollpunkte enthalten:
- Versionierte Prompts und Tools: Jede relevante Modell- und Toolversion muss einer Ausführung zugeordnet werden können.
- Vollständige Audit-Logs: Eingabe, Datenquellen, Entscheidung, Tool-Aufruf, Freigabe und Ergebnis gehören in eine unveränderbare Prozessspur.
- Vier-Augen-Prinzip: Zahlungen, kritische Stammdatenänderungen und sensible HR-Entscheidungen brauchen eine getrennte Freigabe.
- Datenminimierung: Der Agent erhält nur jene personenbezogenen Daten, die für den konkreten Zweck erforderlich sind.
- Herkunftsdokumentation: Trainings-, Referenz- und Wissensdaten müssen fachlich eingeordnet und ihre Nutzung dokumentiert werden.
- KI-Verzeichnis: Für Hochrisiko-Systeme sollte ein internes Verzeichnis die Zuständigkeit, den Zweck, die Kontrollen und die Betriebsumgebung abbilden.
Die beste Human-in-the-loop-Integration ist kein pauschaler Freigabeknopf. Sie zeigt dem Menschen genau die Evidenz, die er für eine Entscheidung braucht.
Unternehmen sollten die Risikobewertung vor dem Agentenbau durchführen. Ein Risk Assessment Framework für Automatisierung kann dabei als Arbeitsstruktur dienen, ersetzt aber keine fachliche und rechtliche Prüfung. Für sprach- oder telefoniebasierte Systeme ist auch eine praxisnahe Einordnung der Voice-AI gesetzlichen Pflichten sinnvoll, bevor Datenflüsse und Nutzerinteraktionen produktiv geschaltet werden.
Die Governance darf nicht als spätes Freigabegremium auftreten. Sie muss im Connector, in den MCP-Tools und in den Ausnahmeregeln verankert sein. Dann lässt sich ein Prozess zurückrollen, prüfen und verbessern, ohne die gesamte Automatisierung stillzulegen.
Fahrplan zur Einführung und Skalierung im Mittelstand
Ein Pilot darf nicht nur zeigen, dass ein Modell Text versteht. Er muss beweisen, dass ein Prozess mit echten Daten, echten Rollen und einem definierten Rückfallweg funktioniert. Dafür eignet sich ein straffer Fahrplan von Discovery bis Produktion.
Woche 1 bis 2 mit Prozess-Mining und Scope
Startpunkt sind keine Tool-Demos, sondern reale Prozessspuren. Das Team analysiert, wo E-Mails, Excel, ERP und Freigaben heute zusammenlaufen. Danach wählt es drei hochvolumige Use-Cases mit klaren Datenankern, begrenztem Risiko und sichtbarer fachlicher Verantwortung.
Geeignet sind oft Rechnungseingang, interne Freigaberouten oder Serviceanfragen. Ungeeignet sind Prozesse, deren Ziel, Datenquelle und Entscheidungskriterien noch nicht geklärt sind. In dieser Phase gehören auch Betriebsrat, Datenschutz und Finance in den Raum, nicht erst vor dem Go-live.
Woche 3 bis 5 mit Connectoren und Governance
Jetzt baut das Team die Verbindungen zu ERP, HR- und Finance-Systemen. Jeder Connector braucht Lese- und Schreibrechte, Fehlerverhalten, Testdaten und eine verantwortliche Person. Parallel werden MCP-Tools definiert, etwa zum Abrufen einer Bestellung, zum Erstellen eines Buchungsvorschlags oder zum Starten einer Freigabe.
Die Training-Sprints laufen parallel. Führungskräfte lernen, welche Prozesse sich eignen und welche Kontrollen sie verlangen. Engineers arbeiten mit einem wiederverwendbaren Muster aus Tool-Schema, Berechtigungsprüfung, Audit-Log und Eskalation.
Woche 6 bis 10 mit begrenztem Pilotbetrieb
Der Agent arbeitet zunächst mit einem kleinen Nutzerkreis und einem klar abgegrenzten Datenbereich. Das Team misst nicht nur Antwortqualität, sondern auch Durchlaufzeit, manuelle Übergaben, Ausnahmequote, Freigabezeit und Fehlerkorrekturen gegen eine Baseline.
Ein Pilot ohne Baseline ist eine Demo. Die Fachabteilung muss vorab festhalten, wie der Prozess heute läuft und welche Abweichung akzeptabel ist. Jede kritische Aktion erhält einen Rollback- oder manuellen Ersatzweg.

Woche 11 bis 13 mit Betriebsübergabe
Vor dem Produktivstart prüft das Team Monitoring, Berechtigungen, Kosten, Datenresidenz, Support und Incident-Prozess. Lizenzmodelle können sich verändern, Hosting-Vorgaben können einen anderen Modellanbieter verlangen und Betriebsratsvereinbarungen können zusätzliche Informations- oder Kontrollrechte definieren.
Am Ende steht nicht die Übergabe eines Dashboards, sondern ein betriebsfähiger Dienst. Dazu gehören technische Dokumentation, Runbooks, Eskalationsregeln, ein Rollback-Plan und eine benannte Eigentümerschaft im Fachbereich. Für österreichische Unternehmen ist die Datenresidenz besonders früh zu klären, ebenso die Abhängigkeit von einzelnen Plattform- und Connector-Anbietern.
Entscheidungshilfen und nächste Schritte für 2026
Ein KI-Automatisierungsprogramm ist reif für den nächsten Schritt, wenn fünf Bedingungen erfüllt sind:
- Prozessklarheit: Drei priorisierte Abläufe haben einen definierten Start, ein fachliches Ergebnis und einen dokumentierten Ausnahmeweg.
- Systemzugriff: ERP, Finance und relevante Postfächer sind über getestete Connectoren erreichbar, ohne unsichere Schattenkopien.
- Kontrollfähigkeit: Jede kritische Aktion erzeugt einen Audit-Eintrag und kann durch eine zuständige Person freigegeben oder zurückgerollt werden.
- Messbarkeit: Der Pilot vergleicht Durchlaufzeit, manuelle Übergaben, Ausnahmequote, Korrekturaufwand und Akzeptanz mit der Baseline.
- Betriebsfähigkeit: Hosting, Datenresidenz, Lizenzierung, Support und Betriebsratsabstimmung sind vor dem Roll-out geklärt.
Ein Go entsteht, wenn der Agent einen klar abgegrenzten Finance-Approval-Prozess sicher vorbereitet und die Fachabteilung die Ergebnisse anhand der gespeicherten Evidenz prüfen kann. Ein No-Go bleibt richtig, wenn Datenanker fehlen, Rollen ungeklärt sind oder der Anbieter keinen belastbaren Export der Logs ermöglicht.
Die Reihenfolge für österreichische Mittelständler ist eindeutig: Finance-Approval starten, Connector-Inventur durchführen, MCP-PoC bauen, Audit-Logging etablieren und erst danach HR und Operations erweitern. Wer mit drei Chatbots beginnt, bekommt drei Chatbots. Wer mit einem kontrollierten Kernprozess beginnt, baut eine Plattform, die weitere Abläufe tragen kann.
Specialty Tokens unterstützt Unternehmen mit Training-Sprints, System- und Daten-Audits, individuellen ERP- und Accounting-Connectoren, einer verwalteten MCP-Schicht und internen Agenten für produktive Backoffice-Workflows. Besuchen Sie Specialty Tokens, wenn Sie einen konkreten Finance- oder ERP-Prozess von der Discovery bis zum kontrollierten Produktivbetrieb bringen wollen.