Decision Layer – Was ist das und warum braucht jeder Enterprise AI Agent einen?

Das Problem: KI-Entscheidungen ohne Nachvollziehbarkeit

Wenn ein AI Agent eine Rechnung kontiert, eine Krankmeldung verarbeitet oder eine Compliance-Frage beantwortet, trifft er eine Entscheidung. Diese Entscheidung basiert auf einem Sprachmodell, das auf Wahrscheinlichkeiten arbeitet – nicht auf deterministischen Regeln.

Für einen internen Chatbot ist das akzeptabel. Für geschäftskritische Prozesse nicht. Wenn ein Agent eine Buchung vorschlägt, muss nachvollziehbar sein: Welche Regel wurde angewandt? In welcher Version? Mit welcher Konfidenz? Wurde ein Mensch einbezogen?

Ohne diese Nachvollziehbarkeit sind KI-Entscheidungen in regulierten Umgebungen nicht einsetzbar. Wirtschaftsprüfer können sie nicht prüfen. Betriebsräte können sie nicht bewerten. Revisionen können sie nicht nachvollziehen.

Der Decision Layer löst dieses Problem.

Was ist ein Decision Layer?

Der Decision Layer ist die zentrale Governance-Komponente zwischen AI Agent und Zielsystem. Er sitzt architektonisch zwischen dem Agenten, der eine Empfehlung ausspricht, und dem System, in dem die Entscheidung wirksam wird – etwa SAP, DATEV oder Workday.

Der Decision Layer ist kein nachträgliches Compliance-Add-on. Er ist ein Architekturprinzip. Jede Agenten-Entscheidung durchläuft den Decision Layer, bevor sie das Zielsystem erreicht.

Die vier Komponenten

1. Rules Engine

Fachliche Regelwerke, versioniert und nachvollziehbar. Tarifverträge, Betriebsvereinbarungen, Buchungslogik, Steuergesetzgebung, Compliance-Regeln. Jede Regel hat eine Version, ein Gültigkeitsdatum und einen Geltungsbereich.

Wenn sich eine Regel ändert – etwa ein neuer Tarifvertrag oder eine geänderte Buchungsrichtlinie – entsteht eine neue Regelversion. Die alte Version bleibt im System. Bei einer Prüfung ist nachvollziehbar, welche Regel in welcher Version zum Entscheidungszeitpunkt galt.

2. Confidence Routing

Nicht jede Agenten-Entscheidung hat die gleiche Sicherheit. Der Decision Layer bewertet jede Entscheidung automatisch:

• Hohe Konfidenz + niedriges Risiko = autonome Verarbeitung. Der Agent entscheidet, das Ergebnis geht ins Zielsystem.
• Niedrige Konfidenz oder hohes Risiko = Eskalation an einen Menschen. Der Workflow pausiert, ein Sachbearbeiter prüft und entscheidet.
• Ausnahmefall oder unbekanntes Muster = Blockierung. Kein Output, menschliche Klärung erforderlich.

Die Schwellenwerte für Konfidenz und Risiko sind konfigurierbar und mandantenspezifisch. Eine Wirtschaftsprüfungskanzlei wird andere Schwellenwerte setzen als ein internes Shared Service Center.

3. Human-in-the-Loop

Human-in-the-Loop ist im Decision Layer ein Architekturprinzip, nicht eine optionale Checkbox. Bei definierten Entscheidungstypen erzwingt die Architektur menschliche Prüfung:

• Entscheidungen mit Diskriminierungspotenzial
• Entscheidungen die Mitbestimmungsthemen berühren
• Entscheidungen oberhalb definierter Wertgrenzen
• Erstmalige Anwendung einer neuen Regel

Die Human-in-the-Loop-Anforderung ist technisch erzwungen, nicht organisatorisch. Ein Agent kann diese Prüfung nicht umgehen.

4. Audit Trail

Jede Entscheidung erzeugt einen vollständigen, unveränderlichen Entscheidungsdatensatz:

• Input: Was wurde dem Agenten übergeben?
• Modell: Welches Sprachmodell wurde verwendet?
• Regelwerk: Welche Regel in welcher Version wurde angewandt?
• Konfidenz: Wie sicher war der Agent?
• Routing: Wurde autonom entschieden oder eskaliert?
• Ergebnis: Was war die Entscheidung?
• Zeitstempel: Wann wurde entschieden?

Dieser Entscheidungsdatensatz ist das, was Prüfer im Auditor Portal sehen. Nicht eine nachträgliche Dokumentation, sondern der technische Beweis der Entscheidungsfindung.

Wie der Decision Layer in der Praxis funktioniert

Ein konkretes Beispiel aus der Belegverarbeitung:

Ein Beleg geht ein – eine Eingangsrechnung. Der Document Agent liest den Beleg, extrahiert die relevanten Informationen: Rechnungssteller, Betrag, Leistungsbeschreibung, Datum.

Der Agent erstellt einen Buchungsvorschlag: Konto, Kostenstelle, Vorsteuerabzug, AfA-Beginn. Dieser Vorschlag geht an den Decision Layer.

Der Decision Layer prüft: Ist der Buchungsvorschlag konsistent mit den versionierten Regelwerken? Stimmt die Kostenstelle? Ist der Vorsteuerabzug bei diesem Rechnungstyp korrekt? Liegt der Betrag innerhalb der Grenzen für autonome Verarbeitung?

Wenn ja: Buchungsvorschlag geht ins Zielsystem (DATEV, SAP). Der vollständige Entscheidungspfad wird im Audit Trail gespeichert.

Wenn nein: Rückfrage an den Sachbearbeiter. Der Workflow pausiert. Der Sachbearbeiter sieht den Vorschlag, die angewandte Regel, den Konfidenzwert und den Grund der Eskalation. Er entscheidet. Auch diese menschliche Entscheidung wird im Audit Trail dokumentiert.

Warum kein Agent ohne Decision Layer in Produktion gehen sollte

Ohne Decision Layer ist ein AI Agent eine Blackbox. Er produziert Ergebnisse, aber niemand kann nachvollziehen wie. Das hat konkrete Konsequenzen:

Prüfung: Wirtschaftsprüfer und interne Revision brauchen Nachvollziehbarkeit. Ohne Audit Trail ist jede Agenten-Entscheidung ein Prüfungsrisiko. Der Prüfer muss jeden einzelnen Fall manuell nachvollziehen – das ist aufwendiger als ohne Agent.

Mitbestimmung: Betriebsräte haben bei der Einführung von KI-Systemen Mitbestimmungsrechte. Ohne nachvollziehbare Entscheidungslogik können sie ihre Rolle nicht wahrnehmen. Der Decision Layer macht Betriebsvereinbarungen zu technischen Constraints.

Haftung: Wenn ein Agent eine fehlerhafte Buchung erzeugt und es keinen Entscheidungspfad gibt, ist unklar wer verantwortlich ist. Der Decision Layer dokumentiert die Verantwortungskette.

Skalierung: Ein Agent, der in einem Pilotprojekt funktioniert, muss nicht in Produktion funktionieren. Ohne Governance-Infrastruktur bleibt jeder Agent ein Einzelfall. Der Decision Layer ermöglicht konsistente Governance über alle Agenten hinweg.

Decision Layer und Cert-Ready by Design

Der Decision Layer ist die technische Grundlage für Cert-Ready by Design. Controls sind im Decision Layer First-Class-Datenobjekte mit definierten Attributen: Control_ID, Technical_Implementation, Rule_Version, Evidence_Generator, Evidence_History, Auditor_View.

Evidence wird automatisch erzeugt – nicht nachträglich zusammengestellt. Prüfer sehen im Auditor Portal den Live-Status aller Kontrollen, mit Drill-Down bis zur konkreten Regelimplementierung.

Das Framework-Mapping bildet die Controls auf etablierte Prüfungsstandards ab: ISA, PS 951, IDW, GoB/GoBD. Eine Betriebsprüfung oder Jahresabschlussprüfung kann auf Basis der automatisch erzeugten Evidence durchgeführt werden.

Mehr dazu: Cert-Ready by Design

Termin vereinbaren – Wir zeigen Ihnen, wie ein Decision Layer für Ihren konkreten Prozess aussieht.