Wenn Workflows intelligent werden: KI schließt die Lücken der klassischen Automatisierung

Jeden Morgen dasselbe Bild: Im Posteingang liegen Auftragsbestätigungen als PDF – in Dutzenden unterschiedlichen Layouts, je nach Lieferant. Jemand prüft Preise, Mengen und Liefertermine von Hand gegen die eigene Bestellung. Nebenan schätzt der Kalkulator die Bearbeitungszeit für einen neuen Auftrag aus Erfahrung, weil die Betriebsdaten zwar seit Jahren erfasst, aber nie ausgewertet werden. Und zwischen dem ERP-System, dem Dokumentenmanagement und der Maschinensteuerung liegen keine Schnittstellen, sondern Menschen: Zahlen werden abgetippt, Belege per E-Mail weitergereicht, Listen in Excel gepflegt. Wer das kennt, kennt die eigentliche Baustelle der Digitalisierung im Mittelstand – und sie heißt nicht „fehlende Software", sondern: Systeme, die nicht miteinander sprechen, und Automatisierung, die genau dort endet, wo es interessant wird.

Das Erstaunliche daran: Das Werkzeug, um diese Lücken zu schließen, gibt es seit Jahren. Grafische Workflow-Engines wie Node-RED oder n8n verbinden Anwendungen miteinander – das ERP-System mit dem Dokumentenmanagement, Maschinen- und Betriebsdaten mit Auswertungen. Jeder Schritt ist ein sichtbarer Knoten in einem Flussdiagramm: transparent, änderbar, quelloffen. Genutzt haben das trotzdem viel zu wenige Betriebe. Nicht aus Desinteresse, sondern weil auch Workflow-Integration bislang Aufwand bedeutete: Schnittstellen verstehen, Datenformate abbilden, Sonderfälle behandeln – Arbeit, für die weder internes Personal noch Budget für externe Entwickler da war.

Der erste Hebel

Vernetzen in Tagen statt Monaten: Workflows, mit KI gebaut

Genau an dieser Stelle verändert KI die Rechnung – noch bevor sie im Prozess selbst mitläuft. Denn auch ganz gewöhnliche, statische Workflows – E-Mail abholen, Daten ins ERP übertragen, Beleg im Dokumentenmanagement ablegen, Rückmeldung verschicken – lassen sich heute mit KI-Unterstützung entwickeln: Die Schnittstellen-Dokumentation liest das Modell, den Integrationscode für einen Knoten schreibt es mit, Testfälle entstehen in Minuten. Was früher ein Integrationsprojekt über Monate war, ist heute oft in Tagen produktiv – und bleibt dabei ein gewöhnlicher, sichtbarer Workflow, den der Betrieb versteht und selbst anpassen kann.

Das ist der oft übersehene erste Nutzen von KI im Mittelstand: nicht der spektakuläre Chatbot, sondern drastisch gesunkene Kosten für das Vernetzen der Systeme, die man ohnehin hat. Gegenüber dem Bau einer eigenen Anwendung ist der Workflow-Ansatz dabei fast immer die bessere Wahl: schneller umgesetzt, leichter zu ändern, ohne Abhängigkeit von einem einzelnen Entwickler oder Anbieter. Die Hürde, an der Vernetzung jahrelang gescheitert ist, ist damit deutlich niedriger geworden.

Der zweite Hebel

Wo statische Workflows enden – und KI sie intelligent macht

So weit die Vernetzung. Doch auch der beste statische Workflow stößt an zwei Grenzen, an denen bisher zwangsläufig wieder der Mensch übernahm. Die erste: unstrukturierte Dokumente. Herkömmliche OCR arbeitet mit starren Templates. Solange jedes Dokument aussieht wie erwartet, geht das gut – ändert ein Lieferant sein Layout, reißt die Erkennung, und eine Fehlerkette beginnt, die bis ins ERP-System fortpflanzt. Die Pflege der Templates wird zum Dauerauftrag, und das Vertrauen in die Automatisierung sinkt mit jedem falsch erkannten Beleg.

Die zweite Grenze: Entscheidungen. Sobald ein Schritt Urteilsvermögen verlangte – gehört dieser Anhang zur Bestellung? Ist diese Abweichung relevant? Welcher Artikel ist hier gemeint? –, endete der Workflow zwangsläufig beim Menschen. Nicht, weil die Aufgabe schwer wäre, sondern weil sie sich nicht in starre Regeln fassen lässt.

Genau diese beiden Lücken schließt der neue KI-Baustein. Ein modernes Sprachmodell liest ein Dokument wie ein Mensch – ohne Template, unabhängig vom Layout – und beendet damit die typischen OCR-Fehlerketten. Und es kann Entscheidungen bis zu einem definierten Grad selbst treffen: zuordnen, bewerten, priorisieren. Das ist es, was Workflows intelligent macht – sie sind nicht mehr nur vernetzt, sondern innerhalb klarer Grenzen urteilsfähig. An der bewährten Workflow-Architektur ändert sich dabei nichts: Das Modell ist einfach ein weiterer Knoten im Flussdiagramm.

KI nur dort, wo Regeln nicht reichen

Der vielleicht wichtigste Unterschied zu vielen „KI-first"-Ansätzen: Das Sprachmodell wird so spät und so gezielt wie möglich eingesetzt. Alles, was sich deterministisch lösen lässt – Dateiformate erkennen, Anhänge vorfiltern, Nummernkreise abgleichen, Plausibilitätsgrenzen prüfen –, wird mit klassischen Regeln gelöst. Regeln sind kostenlos, schnell und irren sich nicht auf kreative Weise.

Das Modell übernimmt nur die Aufgaben, für die es tatsächlich gebraucht wird: unstrukturierte Dokumente verstehen, Freitexte interpretieren, Zuordnungen treffen, die sich nicht in Regeln fassen lassen. Und selbst dann bleibt es unter Aufsicht: Hinter jedem Modellaufruf sitzt eine nachgelagerte, deterministische Prüfschicht – ein „Gate" –, die das Ergebnis gegen harte Kriterien validiert, bevor es weiterverarbeitet wird. Formate, Wertebereiche, Abgleich mit Stammdaten. Was das Gate nicht passiert, landet nicht im ERP-System, sondern in einer Klärungsliste beim Menschen.

Das Sprachmodell ist nie die Anwendung. Es ist ein Baustein – umgeben von Regeln, Prüfungen und Menschen, die das letzte Wort haben.

Über Sprachmodelle hinaus

KI ist mehr als LLMs: spezialisierte Modelle für spezialisierte Aufgaben

Die öffentliche Debatte setzt KI fast durchgängig mit Sprachmodellen gleich. Für den produzierenden Betrieb greift das zu kurz. Viele der wertvollsten Aufgaben brauchen gar kein Modell, das Sprache versteht – sondern ein kleines neuronales Netz oder ein klassisches Machine-Learning-Verfahren, das eigenständig genau eine Aufgabe trainiert wurde, und zwar auf den eigenen Betriebsdaten.

Ein Beispiel: Prozesszeiten bestimmen. In den Betriebsdaten stecken Jahre an gemessenen Bearbeitungs-, Rüst- und Durchlaufzeiten. Verfahren wie Nächste-Nachbarn-Suche, Regression oder Gradient Boosting lernen daraus, wie lange ein Arbeitsgang für eine neue Auftragskonstellation voraussichtlich dauern wird – Material, Abmessungen, Losgröße, Maschine. Das macht Kalkulation und Feinplanung präziser, ohne dass irgendjemand Regeln pflegen muss. Nach demselben Muster lassen sich Werkzeugverschleiß aus Prozessdaten erkennen, Qualitätsabweichungen prognostizieren oder Bedarfe vorhersagen.

Diese spezialisierten Modelle haben handfeste Vorzüge: Sie sind winzig im Vergleich zu Sprachmodellen, laufen auf gewöhnlicher Hardware ohne Grafikkarte, antworten in Millisekunden – und sie arbeiten naturgemäß vollständig lokal, denn trainiert wird ausschließlich auf den eigenen Daten. Ihre Qualität ist zudem exakt messbar: Ein Zeitmodell hat einen bezifferbaren Prognosefehler, den man kennt, bevor man ihm vertraut. Und der entscheidende Punkt für die Praxis: Auch diese Modelle werden als ganz normaler Knoten in dieselben Workflows eingebettet. Das ERP-System fragt an, das Modell liefert eine Zeit oder einen Kennwert zurück, das Prüf-Gate kontrolliert die Plausibilität, und Ausreißer landen beim Menschen – exakt dieselbe Architektur wie beim Sprachmodell, nur mit einem anderen Baustein in der Mitte.

Werkstattbericht

Was wir beim Einsatz lokaler Modelle gelernt haben

Wer Sprachmodelle produktiv einsetzen will – zumal kompakte, lokal betriebene –, muss anders arbeiten als mit einem Chat-Fenster. Einige Erkenntnisse aus unseren Messreihen und A/B-Tests, die sich verallgemeinern lassen:

Die Standortfrage

Und der Datenschutz? Eine Architekturfrage – keine Bremse

Spätestens hier kommt in jedem Mittelstandsgespräch die berechtigte Frage: „Und wo laufen diese Modelle – was passiert mit unseren Daten?" Die gute Nachricht: Das ist heute keine Grundsatzfrage mehr, die ein Projekt stoppt, sondern eine Architekturentscheidung, die man pro Anwendungsfall einmal trifft. In der Praxis lassen sich fast alle Vorhaben in drei Stufen einordnen.

Stufe 1

Unkritische Daten – große Anbieter

z. B. öffentliche Texte, Marketing, Recherche, anonymisierte Inhalte

Hier spielen die großen Frontier-Modelle ihre Stärken aus: höchste Qualität bei Sprache, Analyse und Code. Einsatz über API mit Geschäftskundenvertrag, EU-Datenregion und Auftragsverarbeitungsvertrag – nicht über private Consumer-Konten.

Stufe 2

Interne Geschäftsdaten – europäische GPU-Infrastruktur

z. B. Angebote, Bestellungen, E-Mail-Verkehr, ERP-Auszüge

Offene Modelle (etwa aus den Familien Qwen, Mistral oder Gemma) laufen auf GPU-Servern bei europäischen Betreibern – unter eigener Kontrolle, ohne Training auf Kundendaten, mit klarer vertraglicher Grundlage nach DSGVO.

Stufe 3

Hochsensible Daten – Inferenz im eigenen Haus

z. B. Konstruktionsdaten, Kalkulationen, Personal, NDA-Material

Das Modell läuft auf Hardware beim Kunden selbst – als kompakte Inferenz-„Appliance" im Serverraum. Kein Byte verlässt das Unternehmensnetz. Moderne Workstation- und Mini-Server-Hardware macht das heute zu vertretbaren Kosten möglich.

geringes SchutzniveauDatensouveränität nimmt zu →maximales Schutzniveau

Diese Stufen schließen einander nicht aus, sondern existieren im selben Unternehmen nebeneinander. Derselbe Betrieb kann seine Website-Texte mit einem großen Cloud-Modell überarbeiten lassen (Stufe 1), eingehende Bestellungen auf einem europäischen GPU-Server prüfen (Stufe 2) und Kalkulationsdaten ausschließlich auf einer lokalen Maschine verarbeiten (Stufe 3). Die Einstufung erfolgt einmal pro Anwendungsfall – gemeinsam mit dem Datenschutzbeauftragten – und wird dann technisch fest verdrahtet. Kein Mitarbeiter muss im Alltag darüber nachdenken.

Möglich macht das ein Entwicklungssprung, der leicht übersehen wird: Offene Modelle mit 20 bis 30 Milliarden Parametern erreichen heute bei klar umrissenen Aufgaben – Dokumente lesen, Positionen abgleichen, Felder extrahieren, E-Mails klassifizieren – Ergebnisse, die für den produktiven Einsatz vollkommen ausreichen. Wer Datensouveränität will, muss dafür keine Qualitätseinbußen mehr hinnehmen, die den Nutzen infrage stellen.

Kein Abschaltdatum: das Modell als Betriebsmittel

Für die Stufen 2 und 3 kommt ein Argument hinzu, das weit über den Datenschutz hinausgeht: Verfügbarkeit über die Zeit. Wer seine Automatisierung auf das Cloud-Modell eines großen Anbieters baut, akzeptiert dessen Produktzyklus. Modellversionen werden nach Monaten eingestellt, Schnittstellen und Nutzungsbedingungen ändern sich, Preise ebenso – und ein Nachfolgemodell verhält sich nie exakt gleich. Für eine sorgfältig eingemessene Automatisierung bedeutet jeder erzwungene Modellwechsel: neu testen, neu justieren, neu abnehmen.

Offene Modelle kennen dieses Risiko nicht. Die Modellgewichte liegen als Datei auf der eigenen Infrastruktur – ob auf einem europäischen GPU-Server oder im eigenen Serverraum. Niemand kann sie abschalten, umstellen oder verteuern. Ein einmal validierter Stand läuft unverändert weiter, solange der Betrieb es will – und kann trotzdem jederzeit kontrolliert auf eine neue Modellgeneration gehoben werden, wenn die eigene Messreihe den Fortschritt belegt. Das ist Investitionsschutz im ganz klassischen Sinne: Das Modell wird vom gemieteten Dienst zum Betriebsmittel, über dessen Lebenszyklus der Betrieb selbst entscheidet.

Vorgehen

Klein anfangen, im Betrieb wachsen

Zur flexiblen Architektur gehört ein flexibles Projektvorgehen. Statt eines Großprojekts beginnt jede Automatisierung mit einem eng umrissenen Pilotprozess: ein Prozess, ein messbares Ziel, wenige Wochen Laufzeit. Der Pilot läuft zunächst im Parallelbetrieb – die Automatisierung arbeitet mit, der Mensch entscheidet weiterhin. Erst wenn die gemessene Qualität über einen definierten Zeitraum stimmt, werden Schritte tatsächlich automatisiert. Und auch dann bleibt die Regel: Routinefälle laufen durch, Grenzfälle gehen an den Menschen.

Dieses Vorgehen hat einen angenehmen Nebeneffekt: Es baut Vertrauen auf. Die Mitarbeiter erleben die Automatisierung nicht als Blackbox, die ihnen Arbeit wegnimmt, sondern als Werkzeug, das ihnen die monotone Prüfarbeit abnimmt und die Ausnahmen sauber aufbereitet vorlegt. Ziel ist dabei nicht der Ersatz von Stellen, sondern freiwerdende Kapazität für die Aufgaben, die tatsächlich Erfahrung und Urteilsvermögen verlangen.

Fazit

Intelligente Workflows sind kein Zukunftsthema

Die Bausteine liegen bereit: ausgereifte, quelloffene Workflow-Engines – mit KI-Unterstützung schneller eingeführt, als je eine eigene Anwendung gebaut wäre. Sprachmodelle, die OCR-Fehlerketten beenden und begrenzt entscheiden können. Spezialisierte Modelle, die aus den eigenen Betriebsdaten Prozesszeiten und Prognosen gewinnen. Und Betriebsmodelle für jede Schutzklasse – bis hin zum Modell im eigenen Serverraum, das kein Anbieter je abschalten kann. Die richtige Reihenfolge ist: mit dem Prozess anfangen, der am meisten wehtut, das Betriebsmodell zur Datenklasse wählen und das Ganze in Workflows gießen, die transparent, prüfbar und jederzeit änderbar sind. Wer so vorgeht, bekommt Automatisierung, die die eigene IT nicht überfordert und mit dem Betrieb mitwächst, statt ihn in ein Korsett zu zwingen.