Segregation of Duties: Funktionstrennung in KI-gestützten Prozessen

Eine Rechnung kommt per E-Mail, ein Lieferant wird im ERP angelegt, ein Bot prüft Belege und eine Zahlung wartet auf Freigabe. Für das Team fühlt sich das effizient an, bis jemand feststellt, dass dieselbe Person oder derselbe digitale Agent mehrere Schritte hintereinander auslösen kann. Dann wird aus einem schnellen Prozess eine schwer prüfbare Kontrolllücke.

Segregation of Duties, auf Deutsch Funktionstrennung, soll genau dieses Problem verhindern. Die entscheidende, ausführende und kontrollierende Funktion werden so verteilt, dass Fehler auffallen, Manipulationen erschwert werden und Verantwortung nachvollziehbar bleibt. In KI-gestützten Abläufen reicht es allerdings nicht mehr, menschliche Jobtitel zu trennen. Auch Berechtigungen, Systemagenten, Tool-Aufrufe, Freigaben und Audit-Trails müssen zusammenpassen.

Wenn eine Person den ganzen Prozess steuert

Eine Sachbearbeiterin im Einkauf erhält Zugriff auf das ERP, weil sie Lieferanten betreuen und Bestellungen vorbereiten soll. Im Alltag übernimmt sie jedoch weit mehr. Sie legt einen neuen Lieferanten an, bestellt Ware, bestätigt den Wareneingang und bucht anschließend die Eingangsrechnung. Die Zahlung wird durch einen automatisierten Workflow ausgelöst, der ihren Datensatz als ausreichende Grundlage akzeptiert.

Der Ablauf lässt sich in einzelne Phasen zerlegen:

1. Antrag: Die Sachbearbeiterin erfasst einen neuen Lieferanten und legt eine Bestellung an.
2. Genehmigung: Sie bestätigt die Bestellung selbst oder nutzt einen Workflow, der ihre eigene Eingabe automatisch weiterleitet.
3. Durchführung: Die Ware wird im System als eingegangen markiert.
4. Buchung: Die Eingangsrechnung wird dem Lieferanten und dem Wareneingang zugeordnet.
5. Prüfung: Eine unabhängige Kontrolle findet nicht statt, weil der Prozess bereits als vollständig gilt.

Eine fingierte Lieferantenadresse kann dabei unbemerkt bleiben. Die Sachbearbeiterin könnte ein eigenes Konto hinterlegen, eine Bestellung für nicht gelieferte Ware erfassen und den Wareneingang im ERP bestätigen. Stimmen Bestellwert, Rechnung und Buchung technisch überein, kann die Zahlung freigegeben werden, obwohl keine unabhängige Person die wirtschaftliche Realität geprüft hat.

Das Problem liegt nicht erst bei der Auszahlung. Es beginnt bei der Stammdatenpflege. Wer einen Lieferanten anlegen, einen Auftrag auslösen, den Wareneingang bestätigen und die Rechnung buchen darf, kontrolliert die Beweiskette, die später die Zahlung rechtfertigt. Das System sieht mehrere Prozessschritte, tatsächlich stammen die entscheidenden Eingaben aber aus einer Hand.

Praktische Regel: Eine Person darf einen Prozess fachlich bearbeiten, sollte aber nicht Antrag, Genehmigung, Durchführung, Buchung und Prüfung allein beherrschen.

Ein klassisches Vier-Augen-Prinzip hätte in diesem Beispiel bereits geholfen. Eine zweite Person hätte die Lieferantenanlage, die Bestellung oder zumindest die Zahlung anhand unabhängiger Unterlagen geprüft. Der Rechnungshof beschreibt Funktionstrennung als Prinzip „keine Allein-Verantwortung für den gesamten Prozess“ und als konsequente Trennung von entscheidender, ausführender und kontrollierender Funktion (Leitfaden des Rechnungshofs zu Internem Kontrollsystem und Korruptionsbekämpfung).

Übersehen wurde also nicht nur eine fehlende Unterschrift. Übersehen wurde die Machtkonzentration über mehrere Prozessobjekte. Das Unternehmen hätte die kritischen Kombinationen beim Entwurf des Einkaufsprozesses festlegen und im ERP durch Rollen, Freigaben und unabhängige Prüfungen begrenzen müssen. Wie der Bestellprozess selbst aufgebaut sein sollte, beschreibt unser Beitrag zum Purchase-Order-Workflow.

Die Grundlogik der Funktionstrennung

Funktionstrennung klingt nach Finanzkontrolle, lässt sich aber leicht an einem Restaurant erklären. Der Gast entscheidet, welches Gericht bestellt wird. Die Küche führt die Entscheidung aus. Der Service bringt die Bestellung an den Tisch und kann prüfen, ob das richtige Gericht angekommen ist. Die Restaurantleitung kontrolliert Qualität, Kassa und Abläufe.

Im Unternehmen entspricht dieses Muster drei Ebenen:

• Entscheidend: Eine berechtigte Person oder Stelle entscheidet, ob ein Vorgang zulässig und wirtschaftlich ist.
• Ausführend: Eine andere Rolle setzt die Entscheidung um, etwa durch Bestellung, Zahlung oder Buchung.
• Kontrollierend: Eine unabhängige Rolle prüft, ob Entscheidung und Ausführung korrekt waren.

Für einen Einkaufsprozess können diese Ebenen weiter aufgeteilt werden. Die anfordernde Fachabteilung beschreibt den Bedarf. Eine zuständige Stelle genehmigt die Bestellung. Der Einkauf führt die Bestellung durch. Das Rechnungswesen erfasst die Rechnung. Eine unabhängige Kontrolle vergleicht Bestellung, Wareneingang und Rechnung. Die Zahlungsfunktion führt den Geldtransfer aus. Auch privatwirtschaftliche Kontrollrahmen wie das COSO-Rahmenwerk für interne Kontrollen behandeln die Trennung unvereinbarer Aufgaben als zentrale Kontrollaktivität.

Warum das Vier-Augen-Prinzip allein nicht genügt

Das Vier-Augen-Prinzip bedeutet nicht, dass irgendwo im Prozess eine zweite Person auf eine Schaltfläche klickt. Die zweite Person muss eine andere Funktion ausüben und ausreichende Informationen erhalten, um die Entscheidung wirklich beurteilen zu können. Eine formale Freigabe ohne Zugriff auf Lieferantenstammdaten, Bestellunterlagen oder Wareneingang ist keine wirksame Kontrolle.

Klassische IKS-Grundsätze trennen deshalb Genehmigung, Durchführung, Verwahrung, buchmäßige Erfassung und Überprüfung, gerade im Zahlungsverkehr. Die Logik ist technisch wichtig: Jeder Prozessschritt erhält eine verantwortliche Rolle, während kritische Kombinationen gesperrt oder kompensiert werden.

Die Berechtigung muss zum Zweck passen

Zugriffsrechte sollten auf das beschränkt sein, was eine Person für ihre Aufgabe braucht. Das Prinzip der Mindestinformation begrenzt zusätzlich die Informationen, die sie sehen kann. Der Rechnungshof nennt aufgaben- und verantwortungsadäquate Zugriffsberechtigungen und die Mindestinformation neben Funktionstrennung und Vier-Augen-Prinzip als zentrale Kontrollmechanismen in der Finanzverwaltung (Prinzipien des Internen Kontrollsystems in der Finanzverwaltung).

Segregation of Duties ist deshalb kein bürokratischer Selbstzweck. Sie schafft Gegenkontrollen gegen Fehlbuchungen, bewusste Manipulation und unklare Verantwortung. Bei jedem kritischen Prozess sollte klar sein, wer entscheidet, wer ausführt, wer bucht und wer prüft. Das verlangt nicht immer vier verschiedene Personen, aber es muss das Risiko einer unbemerkten End-to-End-Steuerung beherrschen.

Typische Risiken und Konfliktfelder

Historische Rollenmodelle funktionieren schlecht, wenn ein modernes ERP mehrere Geschäftsbereiche verbindet und Cloud-Dienste, RPA-Bots oder Self-Service-Portale direkt auf dieselben Daten zugreifen. Eine Person in der Buchhaltung kann heute zugleich Stammdaten bearbeiten, Workflows konfigurieren und Reports exportieren. Ein Administrator kann Berechtigungen vergeben und privilegierte Konten verwenden, ohne dass die SoD-Matrix diese Kombination sichtbar macht.

Die Konflikte entstehen nicht nur zwischen Personen. Sie entstehen zwischen Aktionen und Berechtigungen. Ein Bot mit einem weit gefassten technischen Benutzerkonto kann eine Rechnung prüfen, einen Auftrag erstellen und eine Buchung anstoßen. Ein Notfallzugang kann für eine Störung gedacht sein, bei fehlender Protokollierung aber auch Änderungen ermöglichen, die später niemand einer fachlichen Entscheidung zuordnen kann.

Für Finanzgeschäfte hält der Rechnungshof fest, dass Funktionstrennung eine konsequente Trennung von entscheidender, anordnender, verbuchender und zahlender Funktion erfordert. Für die Stadt Wien war zudem die personelle Trennung von „Treasury/Markt“ und „Risikomanagement/Marktfolge“ zu beachten, wie der Rechnungshof in seinem Bericht zum Schulden- und Veranlagungsmanagement beschreibt (Bericht zu Internem Kontrollsystem, Schulden- und Veranlagungsmanagement in Wien).

Was die SoD-Matrix abdecken muss

Eine belastbare Matrix darf deshalb nicht nur Jobtitel vergleichen. Sie muss konkrete Aktionen abbilden, etwa „Lieferant anlegen“, „IBAN ändern“, „Bestellung genehmigen“, „Wareneingang bestätigen“, „Rechnung buchen“, „Zahlung freigeben“ und „Rolle zuweisen“. Für jede Aktion braucht es den fachlichen Kontext, das verwendete System, die technische Berechtigung und den Nachweis einer Kontrolle.

Fehlt diese Präzision, bleiben Konflikte in Cloud- und ERP-Landschaften unsichtbar. Besonders kritisch ist die Kombination aus Berechtigungsvergabe und Nutzung privilegierter Konten, weil sie die Kontrollumgebung selbst verändern kann. Eine SoD-Matrix muss daher auch Konfiguration, Notfallzugänge, Schnittstellen und Automatisierungsidentitäten einbeziehen.

SoD-Matrix und Rollenmodell entwickeln

Eine SoD-Matrix wird brauchbar, wenn sie nicht jede Rollenüberschneidung gleich behandelt. Für den Einkauf sind drei Konfliktklassen sinnvoll. Verbotene Kombinationen dürfen grundsätzlich nicht gemeinsam vergeben werden. Sensible Kombinationen können bei geringem Risiko oder mit kompensierenden Kontrollen zulässig sein. Unkritische Kombinationen haben kein nennenswertes Manipulationspotenzial und müssen nicht künstlich getrennt werden.

Spalten mit klarer Bedeutung

Beginnen Sie mit dem Prozessschritt. Danach folgt die konkrete betroffene Aktion, nicht nur der Name eines Moduls. Die nächste Spalte nennt die konfliktträchtige Rolle. Ergänzen Sie einen Schweregrad, die erforderliche Kontrolle und eine mögliche zulässige Ausnahme.

Eine Ausnahme darf nicht „im Einzelfall“ enden. Sie braucht eine dokumentierte Begründung, eine verantwortliche Genehmigung, eine zeitliche Begrenzung und einen benannten Kontrollnachweis. Der Salzburger Landesrechnungshof hält fest, dass Funktionstrennung grundsätzlich auf organisatorischer Ebene erfolgen sollte und nur bei geringem Komplexitätsgrad oder Risiko auch auf personeller Ebene erfolgen kann (Bericht des Salzburger Landesrechnungshofs zum IKS).

Aus der Matrix entsteht anschließend das Rollenmodell. Jobrollen beschreiben die organisatorische Aufgabe, Berechtigungsrollen bündeln technische Aktionen und Kontextrollen begrenzen Zugriff nach Gesellschaft, Standort, Kostenstelle oder Prozess. Eine Rolle wie „Einkauf“ ist zu grob, wenn sie gleichzeitig Lieferantenanlage und Zahlungsfreigabe enthält.

Rollen sollten eindeutig benannt, fachlich dokumentiert und einer verantwortlichen Stelle zugeordnet werden. Für jede Rolle muss feststehen, wer sie vergeben darf, wer ihre Inhaber prüft und wann sie endet. Temporäre Rollen gehören mit Start, Zweck, Ablauf und nachträglicher Kontrolle in das Modell. So wird aus einer statischen Berechtigungsliste ein nachvollziehbares Kontrollsystem.

Funktionstrennung im Unternehmen umsetzen

Eine wirksame Einführung beginnt nicht mit einem Tool. Sie beginnt mit dem tatsächlichen Prozess, den Mitarbeitende, Systeme und Bots heute ausführen.

1. Prozessinventar erstellen: Finance, Einkauf, IT und die Prozess-Owner dokumentieren den Ablauf. Eine RACI-Darstellung zeigt, wer verantwortlich, rechenschaftspflichtig, beratend oder informiert ist. Stolperfallen entstehen, wenn Teams nur Soll-Prozesse aufnehmen und manuelle Nebenwege, E-Mail-Freigaben oder Excel-Listen auslassen.

2. Risiken bewerten: Ordnen Sie jeder Aktion eine Risikokategorie zu und stellen Sie Konflikte in einer Heatmap dar. Entscheidend sind Geldfluss, Datenkritikalität, privilegierter Zugriff, Automatisierungsgrad und die Möglichkeit einer nachträglichen Verschleierung. Kleine Organisationen sollten wenige, klar begründete Kernkonflikte priorisieren, statt eine unwartbare Matrix zu bauen.

3. Bestehende Rollen bereinigen: Im IAM-System werden überflüssige Gruppen, veraltete Konten und geerbte Berechtigungen entfernt. In großen Umgebungen können dafür SAP GRC oder eine vergleichbare IAM-Suite eingesetzt werden. Im Mittelstand reicht anfangs oft ein kontrolliertes Rollenregister mit nachvollziehbaren Freigaben, sofern es regelmäßig geprüft wird.

4. Freigaben technisch erzwingen: ERP-Workflows müssen Genehmigung, Durchführung, Buchung und Zahlung so verbinden, dass die kritischen Kombinationen blockiert werden. Für den Zahlungsverkehr nennt die Stadt St. Pölten Aufgabentrennung, Zugriffskontrollen, Revision, Vier-Augen-Prinzip, Passwortschutz und Berechtigungsmanagement als gängigste Kontrollverfahren (Kontrollmuster der Stadt St. Pölten für den Zahlungsverkehr).

5. Rezertifizieren und Änderungen kontrollieren: Der Joiner-Mover-Leaver-Prozess muss neue Mitarbeitende, Rollenwechsel und Austritte abdecken. Führungskräfte bestätigen nur jene Rechte, die weiterhin erforderlich sind. Ein Rollenwechsel darf keine alten Berechtigungen stillschweigend mitnehmen.

6. Kontinuierlich überwachen: Eine Übersicht zeigt kritische Konflikte, die Zeit bis zur Auflösung und den Abdeckungsgrad der Kontrollen. Diese Kennzahlen sind nur sinnvoll, wenn klar ist, wer einen Treffer bewertet, wer eine Ausnahme genehmigt und wann eine Korrektur abgeschlossen ist.

Ein Governance-Layer für ERP, CRM und KI kann Rollen, Integrationen und Freigaben zentraler steuern. Unser Beitrag zur KI-Governance für ERP, CRM und Agenten eignet sich als Architekturhilfe, bevor ein Team Berechtigungen in einzelnen Anwendungen neu verteilt.

KI-Agenten und sichere Integrationen kontrollieren

Ein KI-Agent kann eine Lieferantenrechnung lesen, Bestelldaten abgleichen, einen Bestellvorgang auslösen und die Buchung im ERP vorbereiten. Fachlich wirkt das wie ein einziger automatisierter Ablauf. Aus SoD-Sicht bündelt der Agent jedoch mehrere kritische Funktionen in einer Pipeline. Die klassische Frage „Welche Person hat welche Rolle?“ reicht dann nicht mehr.

Vier Leitlinien schaffen ein belastbares Modell:

• Dienstspezifische Scopes: Ein Agent erhält keine kumulierten Endbenutzerrechte. Er bekommt nur jene technischen Berechtigungen, die sein Dienst benötigt, etwa Lesen von Rechnungsdaten oder Erstellen eines Entwurfs. Eine direkte Zahlungsfreigabe bleibt eine eigene, separat kontrollierte Fähigkeit.

• Policy statt Vertrauen: Jede autonome Aktion wird durch eine Policy-Engine oder einen menschlichen Genehmiger geführt. Eine Policy legt fest, welche Datenkombinationen automatisch verarbeitet werden dürfen und wann ein Vorgang an eine verantwortliche Person eskaliert.

• Audit-Trail auf mehreren Ebenen: Das Protokoll speichert nicht nur den finalen ERP-Eintrag, sondern auch Token, Agent, Tool-Aufruf, Eingabedaten, Entscheidung, Ergebnis, Ausnahme und Genehmigung. Sonst bleibt unsichtbar, ob der Agent eine erlaubte Aktion ausgeführt oder eine Berechtigungskette unzulässig erweitert hat. Die Details beschreibt unser Beitrag zum Audit-Log-Management.

• Connectoren wie externe Systeme behandeln: Ein Connector-Layer zwischen Agent und ERP braucht eine eigene Berechtigungslogik, Quoten und einen Kill-Switch. Er darf nicht als unsichtbare Verlängerung eines menschlichen Kontos gelten. Bei einer Fehlkonfiguration muss der Prozess schnell gestoppt werden können, ohne die gesamte Systemlandschaft abzuschalten.

Aus unserer Sicht ist genau hier die offene Frage klassischer IKS-Modelle: Wenn Software oder Agenten die ausführende Funktion übernehmen, müssen Rollenmodell, Audit-Trail, Ausnahmebehandlung und Verantwortung weiterhin nachweisbar bleiben. Bestehende IKS-Richtlinien sind für menschliche Rollen geschrieben und sollten um Agentenidentitäten ergänzt werden.

Eine Verantwortungsmatrix verhindert, dass „die KI“ zum Verantwortlichen wird. Der Operator überwacht laufende Vorgänge und stoppt Ausnahmen. Die Entwicklung verantwortet Code, Tool-Definitionen und Änderungen. Der Prozess-Owner genehmigt fachliche Regeln und Risiken. Audit prüft unabhängige Nachweise und die Wirksamkeit der Kontrollen. Wie Sie die Risiken solcher automatisierten Abläufe bewerten, beschreibt der Abschnitt zur Risikobewertung für KI-Connectoren in unserem Governance-Beitrag.

Audit-Checks, Ausnahmen und Fazit

Ein Audit sollte nicht bei der Rollenbeschreibung stehen bleiben. Entscheidend ist, ob das Unternehmen beweisen kann, dass Funktionstrennung im Alltag funktioniert und nicht nur im Organigramm existiert.

Eine prüffähige Checkliste

• Rollenmodell: Sind Jobrollen, Berechtigungsrollen und Kontextrollen dokumentiert und einem Owner zugeordnet?
• Konfliktprüfung: Werden verbotene und sensible Kombinationen systematisch erkannt?
• Rezertifizierung: Gibt es nachvollziehbare Nachweise für regelmäßige Berechtigungsprüfungen?
• Änderungen: Sind Rollenvergaben, Entzüge und privilegierte Änderungen auswertbar?
• Vier Augen: Zeigen Workflow-Daten, dass Genehmiger und Ausführende getrennt waren?
• Kompensation: Wurde die Wirksamkeit einer Ersatzkontrolle tatsächlich getestet?
• KI-Aktionen: Enthält der Audit-Trail Agent, Token, Tool, Policy-Entscheidung und menschliche Freigabe?
• Konfiguration und Betrieb: Sind Personen, die Regeln oder Connectoren ändern, von deren operativer Nutzung getrennt?

IKS-Unterlagen sind nicht nur für den Moment der Prüfung relevant. Die IKS-Richtlinie der Wirtschaftsuniversität Wien legt die Aufbewahrung der IKS-Dokumentation, vor allem der Kontrollnachweise, nach UGB mit sieben Jahren fest (IKS-Richtlinie der Wirtschaftsuniversität Wien). Wer seine Nachweise nur in einzelnen E-Mails oder persönlichen Notizen ablegt, kann die Wirksamkeit später kaum geschlossen belegen.

Ausnahmen sind tragfähig, wenn sie zeitlich befristet, risikobewertet und von der zweiten Linie genehmigt sind. Zusätzlich braucht jede Ausnahme benannte Schlüsselkontrollen, einen verantwortlichen Owner und einen klaren Endpunkt. In kleinen Teams kann eine personelle statt organisatorische Trennung vertretbar sein, wenn Komplexität und Risiko gering sind oder eine unabhängige Ersatzkontrolle den Konflikt wirksam abdeckt.

Typische Befunde sind überlappende Berechtigungen, fehlende Sichtbarkeit agentischer Aktionen und eine unzureichende Trennung zwischen Konfiguration und Betrieb. Funktionstrennung bleibt im KI-Zeitalter wirksam, wenn Berechtigungen, Freigaben und Audit-Trails durchgängig gestaltet sind und menschliche Verantwortung jederzeit nachvollziehbar bleibt. Wenn Ihr Finanzteam den sicheren Umgang mit Agenten zuerst praktisch üben soll, bieten sich KI-Workshops für Finanzteams an.

Sprechen Sie mit uns

Wenn Sie Funktionstrennung in bestehenden Systemen prüfen und agentische Automatisierung mit klaren Berechtigungen, Freigaben und Nachweisen umsetzen möchten, sprechen Sie mit uns.