KI-Prozessautomatisierung: Praktische Anleitung mit Make und Claude (2026)

KI-Prozessautomatisierung klingt groß. In Wirklichkeit fängt sie mit einem konkreten, repetitiven Prozess an, den du in ein paar Stunden automatisieren kannst. Dieser Artikel zeigt dir, wie.

Ich nehme dir den häufigsten Denkfehler gleich am Anfang weg. Du musst kein Modell trainieren. Du musst keine Agenten bauen, die “alles selbst entscheiden”. Du brauchst einen klaren Prozess, ein Workflow-Tool und ein Large Language Model als API. Das reicht für die ersten 80 Prozent dessen, was im Mittelstand und in KMU sinnvoll ist.

Dieser Leitfaden ist eine praktische Erste-Schritte-Anleitung. Keine Theorie, keine Marketing-Sprache. Drei konkrete Szenarien, die du direkt nachbauen kannst, plus Kosten, Stolpersteine und DSGVO-Hinweise für DACH-Teams.

Die Zielgruppe sind Mittelstand, KMU und interne Automatisierungs-Teams, die einen ersten produktiven KI-Workflow aufsetzen wollen, ohne vorher ein Machine-Learning-Team aufzubauen. Wenn du bereits eine Data-Science-Abteilung hast und Modelle trainierst, wirst du hier nichts Neues lernen. Wenn du Prozess-Owner, IT-Verantwortliche, Geschäftsführer oder einer von zwei Leuten im Team bist, der Automatisierung stemmen soll, bist du richtig.

Was KI-Prozessautomatisierung eigentlich ist

KI-Prozessautomatisierung ist die Kombination aus einem LLM und einem Workflow-Tool, die gemeinsam einen existierenden Prozess übernehmen oder beschleunigen. Das Workflow-Tool macht die Integration (E-Mail rein, Daten raus, in Systeme schreiben). Das LLM macht die Schritte, die klassische Regeln nicht abbilden können: Klassifikation, Zusammenfassung, Extraktion aus unstrukturiertem Text, Kategorisierung nach Kontext.

Was es nicht ist: kein selbst trainiertes neuronales Netz. Kein autonomer Agent, der frei entscheidet. Kein Ersatz für klare Prozesse. Wenn du den Prozess manuell nicht in drei Sätzen beschreiben kannst, wird KI ihn auch nicht retten.

Der Unterschied zu klassischer Zapier-artiger Automatisierung: klassische Automatisierung scheitert, sobald Eingaben unstrukturiert sind. Eine E-Mail mit “Könnt ihr mir bitte eine neue Rechnung für die letzte Bestellung schicken” ist für Regeln unlösbar. Für ein LLM ist es ein Zweizeiler.

Der Start-Stack für DACH-Teams

Für den Einstieg reichen drei Komponenten.

Make.com als Workflow-Orchestrator. UI auf Deutsch verfügbar, DSGVO-freundlich mit EU-Region, visueller Szenario-Editor, pro Operation abgerechnet statt pro Task. Gute Tiefe an Integrationen für typische DACH-Tools (DATEV-freundliche Exports, lexoffice, sevdesk, HubSpot, Gmail, Outlook). Mehr dazu im Make vs n8n Vergleich.

Claude API als LLM. Starke deutsche Textqualität ohne Anglizismen-Rauschen, EU-Routing verfügbar, Tool Use für strukturierte Ausgabe. Setup und Authentifizierung siehe Claude API Deutsch. Wenn du zwischen Claude und ChatGPT schwankst, hilft der ChatGPT vs Claude Vergleich bei der Einordnung.

Google Sheets, Airtable oder Notion als Datensenke. Für den Start reicht Sheets. Sobald Volumen steigt, migrierst du zu Airtable oder einem richtigen ERP-Anschluss.

Alternative: n8n, wenn du self-hosted arbeiten musst oder Operationen-Volumen oberhalb von 20.000 pro Monat hast. Setup in n8n selbst hosten.

Fall 1: E-Mail-Klassifizierung mit Weiterleitung

Das klassische Einsteiger-Szenario. Ein Team bekommt 50 bis 100 Support-E-Mails pro Tag, die manuell gelesen und zugeordnet werden.

Das Problem: Erste Sichtung, Kategorie vergeben, Priorität setzen, an die richtige Person weiterleiten. Pro E-Mail etwa zwei Minuten. Macht bei 80 E-Mails pro Tag etwa 2,5 Stunden im Team.

Make-Szenario:

Gmail-Trigger (neue E-Mail)
  > HTTP-Modul (Claude API mit Tool Use)
  > Router (nach Kategorie)
  > Gmail-Modul (Weiterleitung an Zuständigen)
  > Notion (Log-Eintrag)

Claude-Prompt (Tool Use mit JSON-Schema):

{
  "name": "klassifiziere_email",
  "description": "Klassifiziere eine eingehende Support-E-Mail",
  "input_schema": {
    "type": "object",
    "properties": {
      "kategorie": {
        "type": "string",
        "enum": ["Support", "Vertrieb", "Rechnung", "Sonstiges"]
      },
      "prioritaet": {
        "type": "string",
        "enum": ["hoch", "normal", "niedrig"]
      },
      "sprache": {"type": "string", "enum": ["de", "en"]},
      "zusammenfassung": {
        "type": "string",
        "description": "Maximal 2 Sätze"
      }
    },
    "required": ["kategorie", "prioritaet", "sprache", "zusammenfassung"]
  }
}

Modell: Claude Haiku 4.5. Schnell, günstig, für Klassifikation völlig ausreichend.

Volumen und Kosten: 10 bis 15 Make-Operationen pro E-Mail. Bei 500 E-Mails pro Monat ergibt das 7.500 Operationen, passt in den Core-Tarif. Claude Haiku liegt bei solchen Volumen typischerweise bei 10 bis 20 Euro pro Monat.

Warum Tool Use statt freier Text: ohne Tool Use bekommst du gelegentlich “Ich würde sagen, das ist eher ein Support-Fall” statt “Support”. Das bricht jeden Router. Mit Tool Use erzwingst du das Schema. Details im Artikel zu strukturierter Ausgabe.

Praktische Erweiterung nach zwei Wochen: sobald das Grundszenario läuft, erweiterst du Schritt für Schritt. Automatische Antwort-Vorschläge für Standard-Anfragen, Anreicherung mit CRM-Daten über ein zusätzliches HTTP-Modul (Lookup nach E-Mail-Adresse), und ein wöchentlicher Digest an die Teamleitung mit den zehn häufigsten Anfragen. Jede Erweiterung ist ein zusätzliches Modul in Make, keine neue Infrastruktur.

Fall 2: PDF-Rechnungs-Extraktion

Eingangsrechnungen landen per E-Mail, jemand öffnet sie, tippt Lieferant, Nummer, Betrag und Datum ins Buchhaltungssystem. Bei 40 Rechnungen pro Monat etwa 5 bis 8 Stunden Handarbeit.

Make-Szenario:

IMAP-Trigger (Posteingang Buchhaltung)
  > Filter (nur PDFs im Anhang)
  > PDF-Parser
  > HTTP-Modul (Claude API mit Tool Use)
  > Konfidenz-Check (Router)
  > Google Sheets oder ERP-Webhook (bei hoher Konfidenz)
  > Slack-Alert (bei niedriger Konfidenz, manuelle Prüfung)

Claude-Prompt: strukturierte Extraktion mit Tool Use, Pflichtfelder sind Lieferant, Rechnungsnummer, Rechnungsdatum, Fälligkeitsdatum, Nettobetrag, Umsatzsteuer, Bruttobetrag, Währung und optional die Positionen als Array. Ein Feld konfidenz mit Werten hoch/mittel/niedrig, damit der Router entscheiden kann.

Modell: Claude Sonnet 4.6. Haiku ist für freie Textklassifikation gut, bei Zahlen aus PDFs machst du aber regelmäßig Fehler. Sonnet ist robuster und die Mehrkosten sind bei 40 Rechnungen pro Monat vernachlässigbar.

Fehlerpfad: jede Rechnung, bei der Claude konfidenz: "niedrig" zurückgibt oder bei der Brutto ungleich Netto plus Steuer ist, landet in einem Review-Queue. Das ist die wichtigste Lektion bei Rechnungs-Extraktion. Kein Produktiv-Einsatz ohne manuelle Prüfspur.

Ergebnis: Bei 40 bis 60 Rechnungen pro Monat spart dir das etwa 6 bis 8 Stunden im Monat. Setup-Aufwand liegt bei etwa 6 bis 10 Stunden, du hast die Investition also nach zwei Monaten wieder drin.

Ein Hinweis zu Scans und OCR. Viele Eingangsrechnungen sind bereits native PDFs mit Textebene, die lassen sich direkt per PDF-Parser auslesen. Bei gescannten Rechnungen brauchst du einen OCR-Schritt davor. Make hat ein OCR-Modul, alternativ lädst du die PDF-Seite direkt als Bild an Claude hoch und nutzt die Vision-Fähigkeit. Das funktioniert für Einzelrechnungen gut, wird bei Volumen aber teurer als klassisches OCR plus Text-Extraktion.

Absicherung für die Buchhaltung. Jeder automatisch verarbeitete Datensatz bekommt ein Feld quelle: "automatisch" und einen Link zur Original-PDF im Google Drive. Deine Steuerberatung will im Zweifel zum Buchungssatz die Quelle sehen, das sparst du dir bei späteren Prüfungen.

Fall 3: Wöchentlicher Management-Report

Marketing oder Geschäftsführung braucht jeden Montag einen Report über die Vorwoche. Daten liegen in Google Analytics, Stripe, Intercom und einer internen Datenbank. Jemand kopiert Zahlen zusammen, schreibt einen Kommentar, verschickt per E-Mail.

Make-Szenario:

Scheduler (Montag 08:00 Europe/Berlin)
  > Google Analytics 4 (Sessions, Conversions letzte Woche)
  > Stripe (MRR, neue Kunden, Churn)
  > Intercom (offene Tickets, Antwortzeiten)
  > Aggregator
  > HTTP-Modul (Claude API, Zusammenfassung)
  > E-Mail-Modul + Slack

Claude-Prompt: Claude bekommt die aggregierten Zahlen und den letzten Report als Kontext. System-Prompt etwa so:

Du schreibst wöchentliche Management-Reports für die Geschäftsführung. Schreibe knapp, zahlen-basiert, keine Floskeln. Struktur: Highlights (was ist besser als Vorwoche), Probleme (was ist schlechter), Empfehlung (eine konkrete Aktion). Auf Deutsch, Sie-Form.

Modell: Sonnet 4.6. Haiku schreibt zu mechanisch, die Management-Ebene merkt den Unterschied.

Zeitersparnis: 2 bis 3 Stunden pro Woche, etwa 100 Stunden im Jahr.

Versionierung des Reports. Speichere jeden generierten Report in Notion oder Google Docs mit Datum. Drei Vorteile: Geschäftsführung kann zurückblättern, du trainierst dich selbst auf der Qualität der Reports (und siehst Muster), und bei Prompt-Änderungen hast du einen direkten Vorher-Nachher-Vergleich.

Wichtig bei Scheduler-Szenarien: Make startet den Scheduler nach deiner Account-Zeitzone. Stelle die Organisation auf Europe/Berlin, sonst bekommst du den Report am Sonntagabend statt Montagmorgen. Das ist ein häufiger Grund für Bug-Reports bei DACH-Kunden.

Deine ersten Schritte konkret

Die pragmatische Roadmap für deine ersten 30 Tage.

1. Prozess auswählen. Er muss repetitiv sein, hohe Frequenz haben (mindestens zehn Mal pro Woche), regelbasiert grundsätzlich lösbar sein, aber einen Schritt enthalten, der Textverständnis braucht. Kandidaten: E-Mail-Routing, Lead-Qualifizierung, Feedback-Klassifikation, Eingangsrechnungen, Status-Reports.
2. Make-Account erstellen. Free-Plan reicht für den Test, für Produktiv-Einsatz brauchst du Core (10,59 Euro pro Monat, 10.000 Operationen).
3. Anthropic-Account erstellen. API-Key holen, Nutzungsbudget auf 50 Euro pro Monat begrenzen. Das verhindert böse Überraschungen bei Schleifen-Bugs.
4. HTTP-Modul für Claude API einrichten. Header: x-api-key, anthropic-version: 2023-06-01, content-type: application/json. Body mit model, max_tokens, messages, tools. Als Test eine einzelne Nachricht mit Tool Use schicken und die Antwort parsen.
5. Tool Use Pattern testen. Claude soll strukturierte Ausgabe liefern, Make parst das JSON aus content[0].input. Das ist der wichtigste Schritt. Wenn das funktioniert, ist der Rest Fleißarbeit.
6. Pilot laufen lassen. Zwei Wochen parallel zum manuellen Prozess, Ergebnisse abgleichen, iterieren. Erst dann abschalten.

Die typischen Fallstricke

Ich sehe diese Fehler immer wieder.

Prompts zu lang. Der erste Reflex ist, fünfhundert Wörter Kontext mitzugeben. Falsch. Starte mit 50 bis 100 Wörtern System-Prompt und erweitere nur, wenn du einen konkreten Fehler ausgleichen musst. Lange Prompts bedeuten höhere Kosten, längere Latenz und mehr Ablenkung für das Modell.

Freies JSON statt Tool Use. Viele Tutorials zeigen “gib mir ein JSON zurück” im Prompt. Das funktioniert zu 90 Prozent und fällt bei Rand-Fällen auseinander. Investiere zehn Minuten in Tool Use und spare Stunden an Parsing-Fehlern.

Keine Fehler-Routes in Make. Jedes Szenario braucht einen Error-Handler. Bei API-Timeouts, 429-Rate-Limits oder ungültigen JSON-Antworten muss eine Slack-Nachricht oder ein Log-Eintrag rausgehen. Sonst läufst du zwei Wochen blind.

Kein Kosten-Monitoring. Claude gibt in jeder Antwort usage.input_tokens und usage.output_tokens zurück. Schreibe sie in Google Sheets oder eine Tabelle, summiere pro Tag. Wenn du das nicht tust, wirst du bei der ersten Rechnung überrascht.

Kein Versionierungs-Plan. Make-Blueprints solltest du exportieren, sobald ein Szenario produktiv ist. Speichere sie in Git oder einem Cloud-Ordner mit Datum. Wenn dir jemand das Szenario versehentlich kaputtmacht, sparst du dir einen Nachmittag Rekonstruktion.

Keine Test-Umgebung. Make erlaubt geklonte Szenarien. Produktiv-Szenario klonen, “TEST” ins Label, an Test-Postfach anschließen, dort iterieren. Produktiv-Änderungen erst nach Freigabe. Viele DACH-Teams überspringen diesen Schritt und überschreiben den laufenden Prozess, während gerade echte E-Mails reinkommen.

Halluzinierte Felder. Wenn du Claude nach “Bestellnummer” fragst und die E-Mail keine enthält, erfindet ein schwaches Modell eine. Tool Use mit optional-Markierung im Schema plus eine explizite Anweisung im Prompt (“Lass das Feld leer, wenn nicht vorhanden, erfinde nichts”) verhindert das zuverlässig.

DSGVO in der Praxis

Kurz und konkret für DACH-Teams.

• Auftragsverarbeitungsvertrag mit Anthropic abschließen. Anthropic stellt einen Standard-AVV bereit, der für die meisten Fälle ausreicht.
• EU-Routing bei Anthropic aktivieren, wenn verfügbar. Das stellt sicher, dass Daten nicht in US-Rechenzentren landen.
• Keine direkten personenbezogenen Daten in Prompts. Namen, E-Mail-Adressen und Telefonnummern vorher pseudonymisieren, wo immer möglich. Für E-Mail-Klassifikation reicht oft der Betreff plus die ersten 200 Wörter ohne Signatur.
• Make.com EU-Region bei Konto-Erstellung wählen. Steht im Menü unter “Organization Region”.
• Logging der Verarbeitungen aufbewahren. Welche E-Mail wann klassifiziert wurde, welche Kategorie rauskam. Bei Auskunftsersuchen nach Art. 15 DSGVO brauchst du das.

Das ersetzt keine Rechtsberatung, deckt aber die 80 Prozent, die in der Praxis relevant sind.

Wann Make nicht mehr reicht

Drei klare Signale, dass du zu n8n oder einer Custom-Lösung wechseln solltest.

• Dein Volumen überschreitet 20.000 Operationen pro Monat dauerhaft. Dann wird Make teuer. Self-hosted n8n auf einem kleinen Server liegt bei 5 bis 15 Euro Infrastruktur.
• Du brauchst eigene Node-Logik, die über das Make-HTTP-Modul hinausgeht. n8n erlaubt echtes JavaScript im Code-Node, Make ist hier limitiert.
• Compliance oder interne Policy schreiben self-hosted vor. Details in n8n selbst hosten.

Für die ersten drei bis fünf Prozesse ist Make die richtige Wahl, weil der Einstieg schneller ist und die UI auf Deutsch verfügbar ist.

Kosten-Rahmen realistisch

Grobe Zahlen für die ersten drei Prozesse parallel betrieben.

• Make.com Core: 10,59 Euro pro Monat
• Claude API (Haiku plus Sonnet gemischt): 20 bis 80 Euro pro Monat bei typischen Mittelstands-Volumen
• Datensenken (Sheets, Airtable Free oder Plus): 0 bis 20 Euro pro Monat
• Eigene Zeit für Setup: etwa 20 Stunden für die drei Szenarien zusammen

Bei 40 Euro pro Stunde interner Arbeitskosten sind das etwa 800 Euro einmaliger Setup-Aufwand plus 40 bis 100 Euro laufend pro Monat.

Zeitersparnis bei den drei Szenarien zusammen liegt realistisch bei 10 bis 15 Stunden pro Monat, also 120 bis 180 Stunden pro Jahr. Selbst konservativ gerechnet refinanziert sich das im ersten Quartal.

Wann du einen Berater brauchst

Drei Konstellationen, in denen externe Begleitung den Setup-Aufwand rechtfertigt.

• Es ist dein erster KI-Pilot und die interne IT ist nicht technisch stark aufgestellt. Dann lohnt sich eine geführte Umsetzung, weil die Fehler am Anfang teuer sind.
• DSGVO-Komplexität ist hoch, weil du mit Gesundheitsdaten, Finanzdaten oder sehr sensiblen Kundendaten arbeitest. Hier brauchst du jemanden, der AVV, EU-Routing und Pseudonymisierung im Detail verstanden hat.
• Integration in bestehenden Stack ist aufwendig, etwa Anbindung an SAP, eine selbst gehostete Buchhaltungs-Software oder ein altes CRM. Sieh dir die Kriterien in KI-Automatisierung für den Mittelstand an.

Für die ersten Standard-Szenarien brauchst du keinen Berater. Die Anleitung oben reicht.

Related Reading

• Make vs n8n Vergleich
• Claude API Deutsch
• KI-Automatisierung für den Mittelstand