Segregation of Duties 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.

Inhaltsverzeichnis

• Wenn eine Person den ganzen Prozess steuert
• Die Grundlogik der Funktionstrennung
  • Warum das Vier-Augen-Prinzip allein nicht genügt
  • Die Berechtigung muss zum Zweck passen
• Typische Risiken und Konfliktfelder
  • Was die SoD-Matrix abdecken muss
• SoD-Matrix und Rollenmodell entwickeln
  • Spalten mit klarer Bedeutung
• Funktionstrennung in Unternehmen implementieren
• KI-Agenten und sichere Integrationen kontrollieren
• Audit-Checks Ausnahmen und Praxisfazit
  • Eine prüffähige Checkliste

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 dann 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 in Österreich als konsequente Trennung von entscheidender, ausführender und kontrollierender Funktion, damit keine Person für den gesamten Prozess allein verantwortlich ist (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 bereits beim Entwurf des Einkaufsprozesses festlegen und im ERP durch Rollen, Freigaben und unabhängige Prüfungen begrenzen müssen.

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. Der Koch führt die Entscheidung aus und bereitet das Essen zu. Der Servierer bringt die Bestellung an den Tisch und kann prüfen, ob das richtige Gericht angekommen ist. Die Restaurantleitung kontrolliert Qualität, Kasse 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.

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.

Österreichische IKS-Richtlinien beschreiben die Trennung von Genehmigung, Durchführung, Verwahrung, buchmäßiger Erfassung und Überprüfung als Schutz für Zahlungsverkehr und vergleichbare Kernprozesse (Bericht des Landesrechnungshofs Kärnten zum Internen Kontrollsystem). 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

Das Prinzip der minimalen Berechtigung beschränkt Zugriffsrechte auf das, was eine Person für ihre Aufgabe unbedingt braucht. Das Prinzip der Mindestinformation begrenzt zusätzlich die Informationen, die sie sehen kann. Der Rechnungshof nennt beide Prinzipien neben der Funktionstrennung als zentrale Kontrollmechaniken 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 Verantwortlichkeit. Bei jedem kritischen Prozess sollte klar sein, wer entscheidet, wer ausführt, wer bucht und wer prüft. Diese Zuordnung muss nicht immer vier verschiedene Personen verlangen, aber sie 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. Ein „Buchhalter“ 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, aber bei fehlender Protokollierung auch Änderungen ermöglichen, die später niemand einer fachlichen Entscheidung zuordnen kann.

Die österreichische Praxis fordert für Finanzgeschäfte eine klare Trennung der anordnenden, verbuchenden und zahlenden Funktion. In Wien wird zudem die personelle Trennung von Treasury beziehungsweise Markt und Risikomanagement beziehungsweise Marktfolge im Vier-Augen-Prinzip verlangt, 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

Beginne 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änze 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 lässt eine personelle statt organisatorische Trennung nur bei geringem Komplexitätsgrad oder geringem Risiko als Ausnahme zu und trennt im Haushaltsvollzug entscheidende, anordnende, buchende und zahlende Funktionen (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 in Unternehmen implementieren

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 Prozessowner dokumentieren den Ablauf. Eine RACI-Visualisierung 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: Ordne jeder Aktion eine Risikokategorie zu und visualisiere Konflikte in einer Heatmap. 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 einer Enterprise-Umgebung 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 beschreibt die Stadt St. Pölten außerdem Zugriffskontrollen, Revision, Vier-Augen-Prinzip, Passwortschutz und Berechtigungsmanagement als zentrale Sicherungsmechaniken (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. Manager bestätigen nur jene Rechte, die weiterhin erforderlich sind. Ein Rollenwechsel darf keine alten Berechtigungen stillschweigend mitnehmen.

6. Kontinuierlich überwachen: Ein Dashboard 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. Einen Überblick über solche Sicherheits- und Governance-Frameworks für integrierte Systeme kann ein Team als Architekturhilfe verwenden, bevor es 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 kumulativen Endbenutzerrechte. Er bekommt nur jene technischen Berechtigungen, die sein Dienst benötigt, etwa Lesen von Rechnungsdaten oder Erstellen eines Entwurfs. Eine direkte Zahlungsfreigabe sollte eine eigene, separat kontrollierte Fähigkeit bleiben.

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

• Audit-Trail auf mehreren Ebenen: Das Protokoll muss nicht nur den finalen ERP-Eintrag speichern. Es sollte auch Token, Agent, Tool-Aufruf, Eingabedaten, Entscheidung, Ergebnis, Ausnahme und Genehmigung erfassen. Sonst bleibt unsichtbar, ob der Agent eine erlaubte Aktion ausgeführt oder eine Berechtigungskette unzulässig erweitert hat.

• Connectoren wie externe Systeme behandeln: Ein Supercenter-Connector 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.

Die österreichische IKS-Literatur beschreibt genau hier eine offene Frage: Wenn Software oder Agenten die ausführende Funktion übernehmen, müssen Rollenmodell, Audit-Trail, Ausnahmebehandlung und Verantwortlichkeit weiterhin nachweisbar bleiben (IKS-Richtlinie der TU Graz).

Eine Verantwortungsmatrix verhindert, dass „die KI“ zum Verantwortlichen wird. Der Operator überwacht laufende Vorgänge und stoppt Ausnahmen. Der Entwickler verantwortet Code, Tool-Definitionen und Änderungen. Der Prozessowner genehmigt fachliche Regeln und Risiken. Audit prüft unabhängige Nachweise und die Wirksamkeit der Kontrollen. Für die Bewertung der Risiken in solchen automatisierten Abläufen bietet sich ein dokumentiertes Risk-Assessment-Framework für KI-Integrationen als Arbeitsgrundlage an.

Audit-Checks Ausnahmen und Praxisfazit

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. Eine österreichische Hochschul-IKS-Richtlinie sieht für Kontrollnachweise eine Aufbewahrung nach UGB von sieben Jahren vor und betont zugleich das Verbot der Selbstprüfung (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. Für eine strukturierte Protokollierung von System- und Agentenereignissen ist ein Audit-Log-Management für nachvollziehbare Aktionen ein wichtiger Baustein.

Ausnahmen sind tragfähig, wenn sie zeitlich befristet, risikobewertet und von der zweiten Linie genehmigt sind. Zusätzlich braucht jede Ausnahme benannte Key-Controls, 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.

Specialty Tokens unterstützt Unternehmen mit Trainingssprints, technischen Audits, sicheren ERP- und CRM-Connectoren sowie eingebetteten KI-Agenten für kontrollierte Backoffice-Workflows. Besuchen Sie Specialty Tokens, wenn Sie Funktionstrennung in bestehenden Systemen prüfen und agentische Automatisierung mit klaren Berechtigungen, Freigaben und Nachweisen umsetzen möchten.