SOPs → Skills: So wandelst du Prozesse in KI-Workflows um

SOPs – Standard Operating Procedures – sind strukturierte Abläufe mit klaren Triggern, definierten Schritten und erwarteten Outputs. Das ist exakt das Format, das Agenten brauchen. Wer eine SOP schreiben kann, die ein neuer Mitarbeiter ohne Rückfragen ausführen kann, hat 80 Prozent der Arbeit für einen KI-Workflow bereits getan.

Das klingt einfacher, als es ist. In der Praxis steckt in SOPs oft mehr implizites Wissen, als auf den ersten Blick erkennbar ist – und genau das ist der erste Engpass bei der Transformation.

Was SOPs zu guten Vorlagen macht

Gut geschriebene SOPs haben drei Eigenschaften, die sie direkt anschlussfähig für Automatisierung machen: Sie beschreiben einen Trigger (wann startet der Prozess), eine Abfolge von Schritten (was passiert in welcher Reihenfolge) und einen definierten Output (was ist das Ergebnis).

Diese Struktur ist nicht zufällig deckungsgleich mit dem Aufbau eines Agenten-Workflows. Beide beschreiben, wie eine Aufgabe von einem Zustand A zu einem Zustand B gelangt – unabhängig davon, ob der Ausführende ein Mensch oder ein Modell ist.

Der entscheidende Vorteil von SOPs gegenüber improvisierten Prompts: Das Domänenwissen ist bereits dokumentiert. Ausnahmen, Sonderfälle, typische Fehler – all das steckt in einer reifen SOP. Beim direkten Prompting muss dieses Wissen oft mühsam rekonstruiert werden.

Welche SOPs sich eignen – und welche nicht

Nicht jeder Prozess lässt sich sinnvoll automatisieren. Der einfachste Test: Kann ein neuer Mitarbeiter diese SOP ohne einmaliges Nachfragen ausführen? Wenn ja, ist sie wahrscheinlich agent-ready. Wenn nicht, fehlt noch implizites Wissen, das erst externalisiert werden muss.

Gut geeignet:

• Repetitive Tasks mit klaren Inputs und erwartbaren Outputs: Rechnungsprüfung, Bestellprozesse, Berichterstellung
• Klassifikations- und Routing-Aufgaben: Support-Tickets kategorisieren, Anfragen zuordnen, Dokumente einordnen
• Monitoring mit definierten Schwellenwerten: Preisbeobachtung, Lagerbestandsprüfung, SLA-Überwachung
• Kommunikationsprozesse mit Standardstruktur: Auftragsbestätigungen, Statusupdates, Erinnerungen

Weniger geeignet:

• Prozesse, die auf Beziehung und Kontext beruhen: Eskalationsgespräche, Verhandlungen, Kundenbindung
• Aufgaben mit hoher Varianz und wenig Struktur: kreative Entscheidungen, strategische Bewertungen
• Alles, wo Haftung oder Vertraulichkeit direkten menschlichen Entscheid erfordert

Ein häufig gemachter Fehler: Prozesse automatisieren, die in der SOP zwar vollständig aussehen, in der Praxis aber stark von Kontextwissen abhängen, das nirgendwo dokumentiert ist. Das Ergebnis sind Agenten, die formal korrekt handeln und trotzdem in realen Situationen scheitern.

Die Transformation: von Prosatext zu Workflow

Der Transformationsprozess hat vier Schritte.

Schritt 1 – Struktur freilegen. Viele SOPs sind als Fließtext verfasst. Der erste Schritt besteht darin, die implizite Struktur explizit zu machen: Wo ist der Trigger? Wo sind bedingte Verzweigungen (if/else)? Wo sind Outputs? Oft ergibt sich dabei, dass eine SOP mehrere eigenständige Subprozesse enthält, die besser getrennt behandelt werden.

Schritt 2 – Implizites externalisieren. Jede Stelle, an der ein Mensch aus Erfahrung handeln würde, ohne dass es in der SOP steht, muss explizit gemacht werden. Typische Formulierungen, die auf implizites Wissen hinweisen: „falls nötig”, „nach eigenem Ermessen”, „wie üblich”. Diese müssen in konkrete Kriterien übersetzt werden.

Schritt 3 – Als Skill formulieren. Die aufbereitete SOP wird in ein Format übertragen, das ein Modell direkt ausführen kann. Für Claude Code sind das skill.md-Dateien, für andere Umgebungen YAML-Konfigurationen oder Workflow-Definitionen in n8n oder Make.

Schritt 4 – Testfälle definieren. Vor dem produktiven Einsatz braucht jeder Workflow drei bis fünf reale Testfälle: ein Standardfall, ein Grenzfall, ein Fehlerfall. Wenn der Agent alle drei korrekt behandelt, ist die Grundlage solide.

Ein konkretes Beispiel

Eine typische SOP für Rechnungsprüfung in Prosaform:

„Eingehende Rechnungen werden auf vollständige Pflichtangaben geprüft: Rechnungsnummer, Datum, MwSt-Ausweis und Bankverbindung. Vollständige Rechnungen gehen an die Buchhaltung, unvollständige werden mit konkretem Hinweis an den Absender zurückgegeben.”

Als Skill formuliert:

# Rechnungsprüfung

## Trigger
Neue Rechnung als E-Mail-Anhang oder Datei-Upload

## Prüfkriterien
- Rechnungsnummer vorhanden
- Rechnungsdatum vorhanden
- MwSt-Ausweis (Satz oder Befreiungsgrund)
- IBAN oder Bankverbindung

## Output A – vollständig
Weiterleitung an buchhaltung@firma.de
Betreff: [Rechnungsnummer] freigegeben

## Output B – unvollständig
Antwort an Absender mit Liste der fehlenden Felder
Bitte um Korrektur und Wiedervorlage

Der Informationsgehalt ist identisch. Die Formulierung ist jetzt aber maschinenlesbar strukturiert statt prosaisch – und der Agent kann jeden Schritt ohne Interpretation ausführen.

Vom Skill zur Runtime

Ein Skill-Dokument beschreibt, was der Workflow tun soll. Wie er tatsächlich ausgeführt wird, ist eine separate Frage – und die technisch entscheidende.

Für produktive Umgebungen lässt sich der Rechnungsprüfungs-Skill als YAML-Workflow-Spezifikation formalisieren:

name: invoice_check
trigger:
  type: email_attachment
  mime: application/pdf

steps:
  - extract_text: pdf
  - classify: invoice
  - validate:
      required_fields:
        - invoice_number
        - date
        - vat
        - iban
      structured_output: true
      schema: invoice_validation_schema.json
  - route:
      if_valid:
        action: forward_email
        to: buchhaltung@firma.de
      if_invalid:
        action: reply_email
        template: missing_fields_template
      if_confidence_low:
        action: escalate_human
        threshold: 0.75

Die Kernelemente einer laufenden Agent-Runtime:

• LLM + Tooling: Das Modell (Claude, GPT-4o, Mistral) übernimmt Klassifikation und Extraktion; externe Tools (E-Mail-API, Buchhaltungs-Webhook) führen Actions aus
• Structured Outputs / JSON Schema: Statt Freitext gibt das Modell validierbares JSON zurück – das ist die einzige verlässliche Brücke zwischen Sprachmodell und nachgelagerten Systemen
• Orchestrierung: n8n oder Make für visuelle Workflows mit Systemintegrationen; Temporal oder ein custom Node.js Worker für komplexere, zustandsbehaftete Pipelines
• Confidence Threshold: Das Modell bewertet seine Sicherheit; unterhalb des Schwellenwerts wird zur menschlichen Prüfung eskaliert statt blind weitergeroutet

Wo Agenten in der Praxis scheitern

Das sind nicht die theoretischen Risiken – das sind die Probleme, die bei produktiven Deployments wiederholt auftreten.

Parsing-Probleme überlagern Logik-Fehler. Schlecht gescannte PDFs, uneinheitliche Encodings, fehlende OCR-Vorverarbeitung – die meisten Rechnungs-Workflows scheitern nicht an der Validierungslogik, sondern daran, dass die IBAN nie sauber extrahiert wird. Ohne Fallback (OCR-Konfidenz prüfen, bei Unsicherheit flaggen) produziert der Agent scheinbar valide, aber faktisch falsche Ergebnisse.

Halluzinationen bei fehlenden Feldern. Wenn ein Pflichtfeld nicht vorhanden ist, neigen Modelle ohne Structured Output dazu, es zu „ergänzen” statt einen Fehler zu melden. JSON Schema mit required erzwingt explizite Null-Werte – das macht fehlende Daten sichtbar statt unsichtbar.

Schema Drift bei externen APIs. Buchhaltungs-APIs ändern ihr Format; CRM-Felder werden umbenannt. Ein Workflow, der vor sechs Monaten korrekt war, kann nach einem API-Update still falsch routen. Ohne Monitoring fällt das erst auf, wenn Rechnungen im Nirgendwo verschwinden.

Prompt Injection über E-Mail-Inputs. E-Mails können manipulierten Text enthalten, der versucht, Modell-Instruktionen zu überschreiben. Wer E-Mail-Inhalte ungefiltert in einen Prompt einbaut, hat eine Angriffsfläche. Gegenmittel: Input-Sanitization, klar getrennte System- und User-Prompts, keine Ausführung von Modell-Outputs als Code.

Inkonsistente Klassifikation bei Grenzfällen. Gutschriften, Proformarechnungen, Teilzahlungen – alles, was nicht der Standard-SOP entspricht, führt bei schwach definierten Klassifikationsregeln zu inkonsistenten Ergebnissen. Lösung: Grenzfälle explizit in der Skill-Definition benennen und eigene Routing-Pfade definieren.

Determinismus vs. Probabilistik

Klassische SOPs sind deterministisch: Bei gleichem Input kommt immer derselbe Output. LLM-Workflows sind es nicht.

Das ist kein Defekt – aber es erzwingt andere Sicherheitsmechanismen:

• Structured Outputs reduzieren Varianz bei Format und Struktur erheblich
• Temperature 0 für Klassifikations-Tasks, höhere Werte nur wo Kreativität gewünscht ist
• Confidence Scores machen Unsicherheit explizit statt sie zu verstecken
• Fallback-Pfade für alles, was nicht eindeutig klassifizierbar ist

Der Anspruch ist nicht, LLM-Workflows deterministisch zu machen – der Anspruch ist, ihre Unsicherheit kontrollierbar zu halten.

Observability und Debugging

Ein produktiver KI-Workflow braucht Sichtbarkeit über seinen eigenen Zustand. Ohne Logging ist jeder Fehler eine Blackbox.

Jeden Run als strukturierten Log-Eintrag speichern:

run_id: uuid
timestamp: ISO 8601
input:
  source: email_attachment
  filename: rechnung_2026-05-04.pdf
  raw_text: "..."
prompt_sent: "..."
model_output:
  raw: "..."
  parsed:
    invoice_number: "RE-2026-4891"
    date: "2026-05-04"
    vat: "19%"
    iban: "DE89..."
    confidence: 0.92
decision: valid
action_taken: forward_to_accounting
duration_ms: 1240

Wichtig: Personenbezogene Daten (IBAN, Name) entweder pseudonymisieren oder mit kurzer Retention-Policy (z. B. 7 Tage) speichern – nicht dauerhaft als Volltext.

Replay-Fähigkeit ist bei Agenten wichtiger als bei klassischer Software. Wenn ein Workflow unerwartet falsch routet, will man den genauen Input und Prompt nachspielen können – nicht rekonstruieren. Das setzt voraus, dass Inputs vor der LLM-Verarbeitung gespeichert werden, nicht nur die Outputs.

Versionierung von Skills wie Code

Ein Skill, der in Produktion ist, ist Code. Änderungen daran sind Breaking Changes.

# Rechnungsprüfung v2

Neu gegenüber v1: Gutschriften werden als eigener Typ klassifiziert
und an ein separates Postfach weitergeleitet (gutschriften@firma.de).

Was das in der Praxis bedeutet:

• Skills in Git verwalten – Änderungen sind damit nachvollziehbar, rollbackfähig und reviewbar
• Neue Validierungslogik gegen bestehende Testfälle prüfen, bevor sie produktiv geht
• Bei signifikanten Änderungen parallel betreiben: v1 weiter aktiv, v2 auf einem Subset der Eingaben testen (Canary Deployment)
• Nicht nur den Skill-Text versionieren, sondern auch das Modell: GPT-4o-2024-05 verhält sich anders als GPT-4o-2025-01

Sicherheit und DSGVO

Wo laufen die Daten – und welche dürfen da laufen?

Für viele Standardprozesse (interne Dokumente ohne Kundendaten) ist API-Betrieb mit EU-Datenresidenz und AVV ausreichend. Für Prozesse mit personenbezogenen Daten (Rechnungen mit Kundennamen, Personalauskünfte, Gesundheitsdaten) gilt: Datenklasse zuerst bestimmen, Architektur ableiten.

Konkrete Maßnahmen für produktive Workflows:

• PII vor der LLM-Übergabe maskieren, wenn das Modell die Rohdaten nicht braucht
• Self-hosted Modelle (Mistral via Ollama/vLLM) für hochsensible Daten, die das Netzwerk nicht verlassen dürfen
• Zugriffskontrollen für Workflow-Konfigurationen und Logs – nicht jeder, der die App nutzt, sollte Prompt-Texte lesen können
• Audit-Trail: Wer hat welchen Workflow wann mit welchen Daten ausgeführt?

Qualitätssicherung im laufenden Betrieb

Sampling statt vollständiger Prüfung. Wer jeden Output manuell prüft, hebelt den Automatisierungsgewinn aus. Sinnvoller: Stichproben in festem Rhythmus (10 Prozent der Outputs wöchentlich), plus vollständige Prüfung bei erkennbaren Anomalien (ungewöhnliche Output-Längen, hohe Eskalationsraten).

Mensch in der Schleife bei definierten Schwellen. Nicht jede Ausnahme muss vollautomatisch behandelt werden. Workflows können so gestaltet sein, dass sie bei Unsicherheit (niedrige Modell-Konfidenz, unbekannte Input-Formate) automatisch zur menschlichen Prüfung eskalieren.

Aus der Praxis: Ein Rechnungsworkflow, der für 60 Rechnungen pro Woche gebaut wurde, lief nach drei Monaten bei 150 Rechnungen – und die durchschnittliche Konfidenz war gesunken, weil neue Lieferanten andere Rechnungsformate mitbrachten. Ohne Monitoring-Dashboard wäre das nicht aufgefallen. Mit: eine Woche nach Einführung des Dashboards wurde das neue Format ergänzt, Konfidenz stieg wieder auf über 0,90.

Institutionelles Wissen absichern

Jenseits der Automatisierungsgewinne hat die Transformation von SOPs in Skills einen strategischen Nebeneffekt: Sie erzwingt, implizites Wissen zu explizieren.

Viele KMU haben Abläufe, die nur in den Köpfen einzelner Mitarbeiter existieren. Diese Abläufe überleben Kündigungen, Elternzeiten und Urlaube nicht schadlos. Die Arbeit, eine SOP agent-ready zu machen, produziert als Nebenprodukt eine vollständige, ausführbare Dokumentation dieses Wissens.

Wer einen Prozess so präzise dokumentiert hat, dass ein Modell ihn ausführen kann, hat auch sichergestellt, dass ein neuer Mitarbeiter ihn ohne langen Einarbeitungsaufwand übernehmen kann.

Einordnung

Alles, was man per Handbuch anlernen kann, kann man Agenten beibringen – aber nur dann, wenn das Handbuch wirklich vollständig ist. Die meisten SOPs sind es nicht.

Der Wert des Transformationsprozesses liegt deshalb nicht nur in der Automatisierung selbst, sondern in der Arbeit davor: Prozesse so zu durchdenken, dass sie ohne implizites Wissen funktionieren. Was dabei entsteht, ist robuster als ein Prompt – es ist ausführbare, versionierte Unternehmensdokumentation.