Logging als Ballast — wo ist die Wahrheit?

Der Wunsch von Manager:innen und Unternehmen ist es doch, dass wir durch AI komplexe menschliche Dynamiken unterstützen und Last wegnehmen - Dynamiken, die fehlerbehaftet sind und geführt werden müssen.

Und das tut sie auch mehr und mehr. Agentic Decision-Making steckt längst nicht mehr nur in Demos: Kundenservice-Agenten entscheiden und schließen Standardfälle Ende-zu-Ende (Klarna hat damit einen Großteil der Chats aus der menschlichen Warteschlange genommen — unabhängig davon, wie das bei Kund:innen ankommt). Banken lassen Agenten Kredit-, Compliance- und Deal-Vorarbeiten durchlaufen, statt Junioren stundenlang Folien und Memos zusammenzukratzen. Im Einkauf prüfen Agenten Bestellungen gegen Rahmenvertrag, Toleranz und Wareneingang und eskalieren nur noch die Ausnahmen. Die Messlatte ist klar: weniger menschliche Reibung, nachvollziehbare Entscheidung, weniger operativer Ballast. Weniger Fehler.

Dieselbe Messlatte gilt für die Systeme

Dieselbe Messlatte sollte auch bei den Softwaresystemen gelten, die unsere wichtigsten Geschäftsprozesse abbilden.

Warum wird also neben unsere Software, damit diese mit unseren Daten nachvollziehbar umgehen kann, ein Logging-System übergestülpt?

Warum trotzdem ein Log danebensteht

Compliance. Gerade jetzt mit dem 11. September 2026 und dem Cyber Resilience Act wird Compliance nicht NUR immer wichtiger. Regulierungen sind ein ständiger Begleiter, den man selbst bei Wunschdenken nicht loswird und auch nicht zu lange ignorieren sollte. Agieren, statt reagieren. Ab dem 11. September 2026 greifen die CRA-Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle — Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden. NIS2, DSGVO, der EU AI Act und im Finanzumfeld DORA ziehen in dieselbe Richtung: Wer hat wann was entschieden — und kannst du das belegen, ohne drei Wochen Excel und Zuruf?

Natürlich speichern wir unsere Daten regelmäßig ab und schätzen nach bestem Wissen und Gewissen, was wir nachvollziehen wollen.

Das Problem ist mehrfach

Wir haben einerseits den Code, also Wahrheit. Aber genauso ein Begleitwerk als Logging-System, das auch nicht vergessen werden darf, wenn zum Beispiel neue Schnittstellen hinzukommen. Der Auftrag wechselt den Status in der Fachlogik — und irgendwo daneben soll ein Log mitlaufen, das hoffentlich dieselbe Geschichte erzählt. Tut es oft nicht. Ein Feld fehlt, ein Event wird geschluckt, ein Adapter schreibt still in eine andere Tabelle. Und natürlich kann man von Anfang an möglichst professionell und mit Erfahrung an alles herangehen, aber in der Realität gilt: Mehr manuelle Arbeit, mehr Fehler.

Andererseits stört das Ratespiel, welche Spalten in ein paar Jahren denn nachvollzogen werden sollen. Heute reicht „Status" und „Betrag". In drei Jahren will der Fachbereich wissen, warum der Rabatt bei genau diesem Kunden durchging, welche Regelversion galt und ob ein Mensch oder ein Agent freigegeben hat. Technologie — und dadurch Tabellen und Spalten — soll der flexible Teil des Unternehmens sein und bleiben. Das Geschäftsfeld selbst liefert die Stabilität, auf die sich das Tool Software stützen soll.

Fachliche Tatsachen statt Zeilenupdates

Ein Auftrag, eine Schadensmeldung, eine Buchung, eine Freigabe: Das sind fachliche Tatsachen, keine Zeilenupdates. Diese überleben Schemawechsel:

• AuftragStorniert
• LimitUeberschritten
• PreisUebersteuert
• ZahlungEingegangen

updated_at und Spalte F17 tun das nicht.

Aus zwei mach eins

Wenn von Anfang an Code und Logging zusammenkommen würden — und im geschäftspraktischen Idealfall sollten die beiden gar nie getrennt sein — hätte das nicht nur Auswirkungen auf die Total Cost of Ownership. Weniger doppelte Pflege, weniger „haben wir das geloggt?", weniger Sonderprojekte vor jedem Audit.

Über Event Sourcing liefert die Historie mit dem Code die einzige Wahrheit. Aus Zwei, mach Eins.

Der aktuelle Stand ist nur die Summe der Ereignisse.

Gegenüber Regulierungen und Fachbereich sind Antworten dann fast ohne menschliche Fleißarbeit schnell und verlässlich möglich: nicht rekonstruieren, was wahrscheinlich passiert ist, sondern das Ereignis lesen, das passiert ist.

AI nimmt uns die Last der menschlichen Unschärfe. Unsere Kernprozesse sollten uns nicht anschließend eine zweite Unschärfe in Form eines Logs danebenstellen.

Wie belastbar Audit-Trail, Mandantentrennung und Rollenmodell heute sind, zeigt der Nachweis-Check in wenigen Minuten. Was das in einem echten System bedeutet, steht im Praxisbeispiel Wer hat was zugesagt? und in der Grundlage Revisionssicheres Logging.