KI-Automatisierung & Agenten

Die 80/15/5-Regel

In beobachteten Anwendungsmustern sind ungefähr 80 % der nutzbringenden KI-Automatisierungen sind reine Workflows – vorab definierte Pfade, in denen das LLM einen klar umrissenen Schritt erledigt (Rechnungsvorbereitung, Lead-Qualifizierung, E-Mail-Triage). Weitere 15 % sind Hybrid: ein Workflow als Rückgrat, mit einem Agent-Node an einer abgegrenzten Stelle für die kreative oder urteilende Aufgabe. Nur etwa 5 % sind echte Agenten – LLMs, die in einer Schleife selbständig Werkzeuge wählen und reagieren, bis das Ziel erreicht ist.

Anthropic definiert echte Agenten als „LLMs autonomously using tools in a loop”. Alles davor ist Workflow – und das ist meistens auch genau richtig.

Wann Workflow, wann Agent

Workflow ist die richtige Wahl, wenn

• der Ablauf in einer 10-Schritte-Anleitung beschreibbar ist
• Input und Output strukturiert sind (Formular, CRM, erwartbare E-Mails)
• Compliance, Audit und Revisionspflicht wichtig sind
• hohe Laufzahlen pro Tag erwartet werden
• Fehler direkte Kosten erzeugen (falscher Versand, falsche Rechnung)

Agent ist die richtige Wahl, wenn

• der Weg zum Ziel vorab unbekannt ist
• die Eingabe unstrukturiert ist (Freitext, PDF, Gespräch)
• die Aufgabe Urteilsvermögen erfordert
• Mensch im Loop akzeptabel oder gewünscht ist

In der Praxis am produktivsten: Hybrid – n8n startet deterministisch (Trigger, Datenbeschaffung, Vorverarbeitung), an einem definierten Punkt übernimmt ein Agent die kreative Aufgabe, n8n übernimmt wieder (Routing, Persistierung, Logging). Stabilität im Routinebetrieb bei Intelligenz an den Stellen, wo es darauf ankommt.

KMU-Einstiegspfad in vier Phasen

1. Phase 1 (4 Wochen): Ein bis zwei klare Workflows in n8n live – Rechnungsvorbereitung, Lead-Qualifizierung, Mail-Triage.
2. Phase 2 (Monat 2–3): Einfacher interner RAG-Chatbot auf der Wissensbasis (→ Wissensbasis & RAG).
3. Phase 3 (ab Monat 4): Erster Hybrid-Workflow mit Agent-Node an einer klar abgegrenzten Stelle.
4. Phase 4 (später): Dedizierte Agenten – nur nach Workflow-Reife und sauberer Wissensbasis.

Was dieser Ansatz nicht verspricht

• „100 % autonom” – KI-Workflows brauchen Menschen-Review an den richtigen Stellen. Der Trick ist, wo genau der Mensch gefragt sein muss.
• Vollautonome Geld- oder Compliance-Aktionen ohne Mensch im Loop.
• Agenten auf chaotischer Datenbasis. Rund 80 % der KMU-Failures liegen am Datenchaos, nicht am Modell. Erst aufräumen, dann automatisieren. KI-Spielerei ist sichtbar, echte Entlastung ist spürbar – Letztere entsteht nur auf einem geklärten Ablauf.

Stack

Self-hostbar in der EU: n8n, Flowise, CrewAI, LangGraph. Modelle wahlweise lokal (Llama, Mistral, Qwen) oder via OpenRouter mit EU-Endpoints. Für agentische Anbindung an Firmensysteme ist MCP (Model Context Protocol) im go4ai-Stack als auditierbarer Kontextkanal gesetzt – Berechtigungen granular, Daten verlassen das Unternehmen nur zweckgebunden.

Ein wachsender Teil der Standard-Software (CRM, Buchhaltung, Projekttools) öffnet sich derzeit für genau diese Art der Anbindung – Anbieter bauen eigene Schnittstellen, über die ein Agent direkt auf strukturierte Daten zugreifen kann, statt Bildschirme zu simulieren. Für KMU ist das vor allem ein Auswahl- und Einkaufsthema: Bevor ein Wrapper selbst gebaut wird, lohnt der Blick, ob das eingesetzte Tool eine solche Anbindung nicht schon mitbringt oder gerade ankündigt.

Wie Agenten an Firmensysteme andocken: MCP in der Praxis

MCP ist eine standardisierte Schnittstelle zwischen einem KI-Modell und externen Werkzeugen – vergleichbar mit USB für Peripheriegeräte. Statt für jede Anbindung (E-Mail, CRM, Ablage, Ticketsystem) eine eigene, proprietäre Integration zu schreiben, spricht der Agent ein gemeinsames Protokoll, über das er Werkzeuge findet und kontrolliert aufruft. Seit Ende 2025 ist MCP kein reines Anthropic-Werkzeug mehr, sondern ein herstellerübergreifender Industriestandard mit eigener, unabhängiger Governance-Organisation – das senkt für KMU das Risiko, sich an einen einzelnen Anbieter zu binden.

Wichtig für die Einordnung: MCP ist der Zugang, nicht die Handlungsanweisung. Das Protokoll stellt einem Agenten zur Verfügung, was er ansteuern kann (Postfach, Datenbank, Kalender) – wie er damit in welcher Reihenfolge ein konkretes Geschäftsziel erreicht, bleibt eine separate Frage der Prozessgestaltung. Ein MCP-Anschluss allein macht aus einem Workflow noch keinen sinnvollen Agenten-Einsatz.

Rechtlich ist MCP neutral – wo die Daten liegen, wer Auftragsverarbeiter ist und wie eng die Zugriffsrechte geschnitten sind, entscheidet die konkrete Einbindung, nicht das Protokoll. Deshalb gilt für jeden MCP-Server dieselbe Prüfroutine wie für jede neue Software-Anbindung: Herkunft und Pflegezustand kennen, Auftragsverarbeitungsvertrag vorliegen haben, Zugriffsrechte auf das Nötigste begrenzen.

Warum Multi-Agent-Setups selten der erste Schritt sind

„Mehrere Agenten, die zusammenarbeiten” klingt nach dem nächsten logischen Ausbauschritt, sobald ein einzelner Agent läuft. In der Praxis ist das Gegenteil der Fall: Jeder zusätzliche Agent, der mit einem anderen koordiniert werden muss, bringt eigene Kosten mit – Abstimmungsaufwand, Fehlerquellen an den Übergaben, und die Frage, wann ein Zwischenergebnis „fertig genug” ist, um weitergereicht zu werden. Die einfachste tragfähige Form ist meist ein Leit-Agent, der klar abgegrenzte Teilaufgaben an Hilfs-Agenten delegiert und die Ergebnisse selbst zusammenführt – nicht ein Schwarm gleichberechtigter Agenten, die eigenständig untereinander kommunizieren. Komplexere Koordinationsformen (parallel arbeitende Agenten-Teams, ereignisgesteuerte Weiterleitung zwischen Agenten, gemeinsam genutzte Datenstände) lohnen sich erst, wenn der einfache Ansatz an einer konkreten, benannten Grenze scheitert – nicht vorsorglich. In den meisten KMU-Fällen aus der 80/15/5-Regel oben ist die Antwort ohnehin: ein Workflow mit höchstens einem eingebetteten Agenten reicht aus, eine Mehr-Agenten-Architektur wäre überdimensioniert.

Sicherheit gehört in den Entwurf, nicht als Nachgedanke

Mit jedem zusätzlichen Tool, das ein Agent ansteuern darf, wächst der Blast-Radius – der Schaden, den eine einzige falsch ausgelöste Aktion anrichten kann. Drei Prinzipien aus der Praxis:

• Least Agency: Der Agent bekommt nur die Tools, die er für genau diese Aufgabe braucht – und davon nur die Rechte, die diese Aufgabe wirklich erfordert. Ein Postfach-Zugriff etwa muss nicht zwingend Senderechte umfassen, wenn die Aufgabe nur „Anfragen lesen und einordnen” lautet. Schreibrechte, Löschrechte und die Reichweite (welche Ordner, welche Datensätze, wie oft) sind jeweils eine bewusste Entscheidung, kein Default. Die häufigste Falle im Mittelstand: ein einziges „KI-Bot”-Konto, das Lesezugriff, Versand und Datenbankschreibrechte gebündelt trägt – das ist das Gegenteil von Least Agency, selbst wenn jedes einzelne Recht für sich harmlos wirkt.
• MCP-Server gehören geprüft, nicht blind eingebunden. Prompt-Injection über fremde MCP-Tools – also eingeschleuste Anweisungen in Dokumenten oder Webseiten, die der Agent unbemerkt ausführt – ist eine der praxisrelevanten Angriffsklassen in diesem Bereich.
• Mensch im Loop an den richtigen Stellen. Geld-, Compliance- und Identitäts-Aktionen sind nie vollautonom.

Mehr zu den Sicherheitsaspekten von Agenten im Detail – Blast-Radius, Rechte-Architektur, Prompt-Injection-Schutz und wo der Mensch zwingend mitentscheidet: Agenten-Sicherheit →.

Konkrete Praxisbeispiele in der Use-Case-Bibliothek.