KI vs. RPA: RPA für vorhersehbare Regeln, KI für unklare Inputs – meistens beides für funktionierende Lösungen

Die kurze Antwort

RPA (Robotic Process Automation) ist regelbasiert: wenn X, dann Y, jedes Mal. Es ist zuverlässig, schnell – und versagt in dem Moment, in dem der Input nicht zur Regel passt. KI – speziell LLM-basierte Automatisierung – bewältigt unklare, variable Inputs, die kein Regelwerk abdecken kann: eine eingehende E-Mail in beliebigem Tonfall, ein gescanntes Formular mit Handschrift, eine Frage, die auf fünf Arten formuliert ist.

Wir nutzen beides, oft im selben Workflow auf n8n: RPA für die deterministischen Schritte, ein LLM für den Urteils-Schritt, und verpflichtende menschliche Prüfung für alles, was das System verlässt.

Der sachliche Vergleich

Wann reines RPA ausreicht (ohne KI)

Es gibt Fälle, in denen KI Kosten und Risiken hinzufügt, ohne Mehrwert zu liefern. Wenn das Eingabeformat vollständig festgelegt ist – ein strukturierter Export aus einem ERP-System (Warenwirtschaft), ein standardisiertes Formular, ein geplanter Datenbankjob – ist RPA allein schneller, günstiger und besser auditierbar. Die Regel deckt jeden echten Fall ab; es gibt nichts für ein LLM zu interpretieren.

KI nur dann einsetzen, wenn der Input wirklich variabel ist oder der erforderliche Output ein Urteilsvermögen erfordert, das sich nicht als Regel ausdrücken lässt.

Was wir in der Praxis tun

Der Sweet Spot ist, beides im selben Workflow zu nutzen.

Der E-Mail-Agent, den wir für innatura gebaut haben, zeigt die Aufteilung klar. Die deterministische RPA-Schicht übernimmt alles, was kein Urteilsvermögen erfordert: das Postfach lesen, Absender und Betreff parsen, prüfen ob der Absender ein bekannter Partner ist, relevante Bestandsdaten aus der Datenbank ziehen. Die KI-Schicht übernimmt das, was RPA nicht kann: den E-Mail-Inhalt lesen, den Anfragetyp klassifizieren (Angebot, Bedarfsanfrage, Logistikfrage oder sonstiges) und eine Antwort auf Basis des abgerufenen Kontexts entwerfen. Ein Mensch prüft den Entwurf, bevor irgendetwas versendet wird.

Jede Schicht tut, was sie am besten kann. Die RPA-Schritte sind günstig und haben hohes Volumen; der KI-Schritt ist eng und folgenreich. Keine versucht, den Job der anderen zu machen.

Für den öffentlichen Sektor und regulierte Branchen ist dieser Hybrid die einzige ehrliche Antwort. Reines RPA bewältigt die natürlichsprachlichen Inputs nicht, die echte Nutzer:innen senden. Reine KI liefert nicht den Audit-Trail, den Compliance-Teams brauchen. Die Kombination – RPA für Regeln, KI für Urteil, Mensch im Loop für Outbound – ist das, was wirklich in Produktion geht.

Warum N3XTCODER

Wir bringen ein Jahrzehnt Impact-Tech-Erfahrung und über 160 KI-Projekte seit 2019 mit. n8n ist unsere Standard-Orchestrierungsschicht genau deshalb, weil sie sowohl RPA-ähnliche deterministische Nodes als auch LLM-Nodes im selben Workflow verarbeitet.

• innatura – KI-E-Mail-Agent auf n8n + Azure OpenAI, der Spendenangebote, Bedarfsanfragen und Logistikanfragen klassifiziert; Antwortentwürfe mit verpflichtender menschlicher Prüfung. Das produktive Beispiel für RPA + KI in einem einzigen Workflow.
• GDV (Gesamtverband der Deutschen Versicherungswirtschaft) – Wissensassistent über zehntausende Policy-Dokumente. Die Retrieval-Schicht ist deterministisch; die KI-Schicht verarbeitet natürlichsprachliche Anfragen.
• Kompetenzz – RAG-Chatbot für 1.000+ HumHub-Mitglieder auf n8n + Qdrant + GPT-4 via Microsoft EU, betrieben von einem Team ohne Entwickler:innen.
• Civic Coding – KI-Beratung über 100 Sozial-Impact-Projekte, einschließlich Lieferkettentransparenz-Initiativen mit Volkswagen, Zalando, adidas und Deutsche Bahn.
• Standard-Stack: n8n in Berlin, Qdrant in der EU, Azure OpenAI via Microsoft EU Sovereignty. n8n-Konnektoren decken die meisten gängigen Unternehmenssysteme ab (CRM, ERP, Postfach).

Ehrliche Grenzen

Menschliche Prüfung muss echt sein. Wenn Prüfer:innen Entwürfe absegnen, ohne sie zu lesen, ist der Oversight-Nutzen eliminiert, während die Haftung bestehen bleibt. Den Prüfschritt so gestalten, dass er schnell genug ist, dass Prüfer:innen sich wirklich damit befassen – ein gut strukturierter Entwurf mit der zentralen Entscheidung hervorgehoben braucht zehn Sekunden zur Prüfung.

LLM-Kosten summieren sich bei großem Volumen. Bei niedrigem E-Mail-Volumen sind Inferenzkosten vernachlässigbar. Bei 50.000 E-Mails im Monat sind sie eine echte Budgetzeile. Wir erfassen die Token-Nutzung ab Sprint eins und legen sie offen. Wenn das Volumen die Kosten nicht rechtfertigt, sagen wir das.

Workflow-Ausfälle sind einzuplanen. n8n ist der Kleber zwischen Postfach, Datenbank und LLM. Wenn ein API-Endpunkt sich ändert oder ein Dienst ausfällt, stoppt der Workflow. Fehlerbehandlung, Benachrichtigungen und Dead-Letter-Queues sind in der Produktion nicht optional – ein Workflow, der stillschweigend Elemente fallen lässt, ist schlimmer als einer, der laut scheitert.

RPA-Schritte brauchen noch immer Fallback-Pfade. Ein Workflow, der für Bestellbestätigungen ausgelegt ist, bricht bei der ersten E-Mail, die wie eine Bestellung aussieht, es aber nicht ist. Der LLM-Schritt übernimmt die Klassifikation; die deterministischen Schritte brauchen trotzdem explizite Pfade für unerwartete Inputs.

Häufige Fragen

Weitere Services