Automatisierung in regulierten Branchen gestalten: Zwischen Compliance und Innovation balancieren

Die meisten Automatisierungslösungen sind darauf ausgelegt, die Leistung zu verbessern. Das bedeutet, dass Entwicklungsteams Prozesse optimieren müssen, um Daten schneller zu verarbeiten, manuelle Arbeitsschritte zu reduzieren und Fehlerquoten zu senken. In Branchen wie dem Finanzwesen, dem Gesundheitswesen, der Versicherungswirtschaft oder der Energiewirtschaft gilt dies ebenfalls.

In diesen Branchen führt ein Fehler bei einem Prozess innerhalb eines Kreditvergabesystems oder einer Pipeline zur Verarbeitung klinischer Daten jedoch nicht nur zu einer Fehlermeldung. Er kann auch dazu führen, dass Aufsichtsbehörden Verstöße feststellen, eine Datenschutzverletzung gemeldet werden muss oder ein Bußgeld verhängt wird. Genau hier wird die Automatisierung regulatorischer Compliance-Anforderungen zu einer Frage der Systemarchitektur und nicht nur des operativen Betriebs.

In den folgenden Abschnitten gehen wir auf strukturelle Muster ein, die bei der Gestaltung von Automatisierungslösungen für regulierte Branchen eine wichtige Rolle spielen. Wir teilen die Erfahrungen von Chudovo aus der Zusammenarbeit mit Teams, die für das Risikomanagement bei der Automatisierung verantwortlich sind, und erläutern, wie sie Themen wie Auditierbarkeit, die Durchsetzung von Richtlinien und die Entwicklung von Systemen angehen, deren Funktionsweise auch von Personen überprüft werden kann, die nicht an ihrer ursprünglichen Entwicklung beteiligt waren.

Was „Observability“ wirklich bedeutet

In der klassischen Systemarchitektur geht es bei „Observability“ in erster Linie darum, den Betrieb eines Systems sicherzustellen, und nicht darum, seine Aktionen zu erklären. Deshalb konzentrieren sich Logs in der Regel auf betriebliche Fragen:

• Ist der Dienst verfügbar?
• Liegen die Latenzzeiten im akzeptablen Bereich?
• Treten Fehler auf?

Bei der Automatisierung in regulierten Branchen sieht das etwas anders aus. Hier reichen Logs, die lediglich dokumentieren, was passiert ist, nicht aus. In diesen Branchen ist es noch wichtiger als der eigentliche Vorgang, nachvollziehen zu können, wer ihn autorisiert hat, auf Grundlage welcher Richtlinie dies geschah und ob diese Richtlinie zum Zeitpunkt der Entscheidung gültig war.

Diese Anforderungen lassen sich nicht ohne Weiteres in einer einzigen Ebene zusammenführen. Die eigentliche Herausforderung besteht darin, die jeweiligen Verantwortungsbereiche voneinander zu trennen und das richtige Gleichgewicht zwischen ihnen zu finden. Das ist in der Regel wichtiger, als einen der beiden Bereiche isoliert zu optimieren.

Governance bei der Unternehmensautomatisierung

In regulierten Systemen ist die Governance der Unternehmensautomatisierung unverzichtbar. Sie stellt sicher, dass Aktionen nur dann ausgeführt werden, wenn eine definierte Regel dies erlaubt. Dieser richtlinienbasierte Automatisierungsansatz setzt voraus, dass die Regeln versioniert, auditierbar und auch für Personen außerhalb des Entwicklungsteams verständlich sind.

Betrachten wir einen einfachen Genehmigungsworkflow im Finanzwesen. Ein automatisiertes System leitet Transaktionen anhand bestimmter Risikoschwellenwerte zur zusätzlichen Prüfung weiter. Sind diese Schwellenwerte direkt im Anwendungscode hinterlegt, erfordert jede Änderung ein neues Deployment. Dieses Deployment wird möglicherweise nicht so protokolliert, dass die Audit-Anforderungen erfüllt werden. Eine Aufsichtsbehörde, die das System überprüft, muss nachvollziehen können, welcher Schwellenwert an einem bestimmten Datum gültig war. Der Verweis auf die Git-Historie reicht in den meisten Audit-Szenarien nicht aus.

Wenn Entscheidungen auch außerhalb des Entwicklungsteams nachvollziehbar sein müssen, wird Governance bei der Unternehmensautomatisierung besonders wichtig.

Ein besser überprüfbares Governance-Modell lagert Richtlinien aus dem Anwendungscode aus. Schwellenwerte werden in einem separaten Richtlinienspeicher (Policy Store) verwaltet, beispielsweise mit Open Policy Agent oder einer speziell entwickelten Rules Engine. Bei jeder Regelauswertung wird die verwendete Richtlinienversion protokolliert. Die Automatisierung selbst fragt lediglich: „Ist diese Aktion erlaubt?“ und handelt entsprechend der Antwort. Auf diese Weise entsteht auf der Richtlinienebene eine überprüfbare Änderungshistorie, die unabhängig vom Deployment-Zyklus der Anwendung geführt wird.

Das Team von Chudovo beobachtet bei Governance-Strategien für die Unternehmensautomatisierung häufig ein Muster wie das folgende. Es muss nicht besonders komplex sein, sollte aber etwas ausdrücklich abbilden, das im Anwendungscode meist tief in der Programmlogik verborgen bleibt.

async function evaluateAction(actionType, context) {
  const response = await fetch("http://policy-engine/v1/data/finance/approve", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ input: { action: actionType, context } }),
  });

// In regulated contexts, a failed policy check must never default to permissive.
  // Fail closed: if the engine is unreachable or returns an error, deny the action.

  if (!response.ok) {
    logAuditEvent({ action: actionType, decision: false, policyVersion: null, context });
    throw new Error(`Policy engine returned ${response.status}. Action denied.`);
  }

  const result = await response.json();

  // Log policy version for audit trail
  logAuditEvent({
    action: actionType,
    decision: result.result,
    policyVersion: result.policyVersion ?? null,
    context,
  });

  return result.result;
}

Das obige Beispiel ist nicht für den direkten Einsatz in einer Produktionsumgebung gedacht. Die Version einer Richtlinie wird nicht immer automatisch von der Policy Engine zurückgegeben und muss häufig explizit hinzugefügt werden. Bei OPA-Bundle-Deployments steht dafür eine Bundle-Version zur Verfügung, die sich gut für diesen Zweck eignet. Technisch gesehen sind auch Commit-Hashes eine Option, allerdings sind sie für Auditoren schwer verständlich. Eine Versionskennung ist für ein Audit nur dann hilfreich, wenn das Compliance-Team sie nachvollziehen kann, ohne dafür ein Terminal öffnen zu müssen.

Nach der Implementierung sieht der vollständige Ablauf wie folgt aus:

Auditierbarkeit in automatisierten Systemen

Wenn IT-Teams nach den Audit-Trails ihrer Systeme gefragt werden, lautet die erste Antwort häufig: „Wir haben Logs.“ Auch wenn das in manchen Fällen ausreichen mag, muss die Auditierbarkeit in regulierten Branchen von Anfang an als zentrale Anforderung bei der Systementwicklung berücksichtigt werden.

Eine wirksame Automatisierung regulatorischer Compliance-Anforderungen setzt voraus, dass das System nicht nur nachvollziehen kann, welche Aktion wann ausgeführt wurde, sondern auch, welcher Systemzustand sie ausgelöst hat und welche Regel sie autorisiert hat. Darüber hinaus muss in den meisten Fällen festgestellt werden können, ob die Daten zum Zeitpunkt der Entscheidung korrekt waren und wer oder was die Ereigniskette ausgelöst hat.

Während Logs die erste Frage beantworten können, erfordern die übrigen Aspekte eine gezielte Berücksichtigung bei der Systementwicklung. Die folgende Tabelle zeigt einen groben Vergleich zwischen betrieblicher Observability und Audit-Trails, die regulatorische Compliance-Anforderungen erfüllen:

Es gibt verschiedene Möglichkeiten, diese Informationen zu erfassen. Ein häufig verwendeter Ansatz ist die ereignisbasierte Protokollierung an der Schnittstelle der Automatisierung. Dabei erzeugt das System vor und nach jeder Transaktion ein strukturiertes Ereignis. Dieses Ereignis erfasst alle relevanten Informationen, die für den Aufbau eines Audit-Trails erforderlich sind: den Zustand der Eingabedaten, die verwendete Richtlinienversion, die Identität des Auslösers (Benutzer, Servicekonto oder geplanter Job) und das Ergebnis.

// Structured audit event emitted at the automation boundary
function logAuditEvent({ action, decision, policyVersion, context }) {
  const event = {
    eventId: crypto.randomUUID(),
    timestamp: new Date().toISOString(),
    actor: context.serviceAccount ?? context.userId,
    action,
    decision,
    policyVersion: policyVersion ?? "unknown",

    inputHash: hashPayload(context),     // tamper detection only
    // inputSnapshot: context,                  // full reconstruction -- store separately if required
  };

  auditStore.append(event); // append-only
}

in Ansatz, den das Team von Chudovo häufig verwendet, besteht darin, einen Event Builder zu implementieren, der jedes Mal aufgerufen werden kann, wenn ein solches Ereignis erzeugt werden muss.

Dieser Ansatz ermöglicht es, Abläufe nachträglich zu rekonstruieren, anstatt sie lediglich zu protokollieren. Damit bildet er die Grundlage für echte automatisierte Audit-Trails.

Wie die folgende Tabelle zeigt, fehlen in herkömmlichen Logs häufig Informationen, die für einen Audit-Trail erforderlich sind, der regulatorische Compliance-Anforderungen erfüllt. Allerdings kann die Implementierung einiger der in der rechten Spalte aufgeführten Funktionen kostspielig sein. Vieles hängt davon ab, welche Informationen protokolliert werden sollen, und nicht davon, ob in eine spezialisierte Infrastruktur investiert wird.

Frameworks zur Compliance-Automatisierung und automatisierte Compliance-Überwachung: Optionen und Abwägungen

Verschiedene Ansätze zur Automatisierung regulatorischer Compliance-Anforderungen bringen unterschiedliche Vor- und Nachteile hinsichtlich Flexibilität, Auditierbarkeit und betrieblicher Komplexität mit sich. Die Wahl geeigneter Frameworks zur Compliance-Automatisierung, die häufig dem Bereich Regulatory Technology (RegTech) zugeordnet werden, hängt vom regulatorischen Umfeld, den bereits eingesetzten Tools und davon ab, wie häufig sich die Compliance-Anforderungen ändern.

Regelbasierte Engines (Drools, OpenL Tablets, benutzerdefinierte DSLs) ermöglichen es Compliance-Teams, Regeln zu definieren, ohne den Anwendungscode ändern zu müssen. Sie eignen sich besonders dann, wenn sich Geschäftsregeln häufig ändern und von Personen außerhalb des Entwicklungsteams überprüft werden müssen. Allerdings können solche Regelsysteme schnell an Komplexität gewinnen. Das systematische Testen von Wechselwirkungen zwischen Regeln ist schwieriger, als es zunächst erscheint.

Open Policy Agent und Cedar gehören zu den Lösungen, die Richtlinien als eigenständige Softwarekomponenten behandeln (Policy-as-Code). Richtlinien werden versionskontrolliert und können getestet werden. Dieser Ansatz eignet sich für Entwicklungsteams, die damit vertraut sind, Richtliniencode mit derselben Sorgfalt wie Anwendungscode zu pflegen. Der Nachteil besteht darin, dass diese Disziplin tatsächlich vorhanden sein muss. Werden Richtliniendateien lediglich wie gewöhnliche Konfigurationsdateien behandelt, geht der eigentliche Vorteil dieses Ansatzes verloren.

Die automatisierte Compliance-Überwachung setzt als Bestandteil umfassenderer Compliance-Monitoring-Systeme auf einer anderen Ebene an. Anstatt Regeln zum Zeitpunkt der Ausführung durchzusetzen, überprüft sie, ob der aktuelle Systemzustand den festgelegten Anforderungen entspricht. Dazu gehören Cloud-native-Lösungen wie AWS Config und Azure Policy sowie individuell entwickelte Monitoring-Jobs, die den Systemzustand abfragen und Abweichungen melden. Diese Tools arbeiten hauptsächlich auf der Infrastruktur- und Konfigurationsebene und nicht auf der Ebene der Geschäftslogik. Dieser Ansatz ist reaktiv statt präventiv, bietet jedoch einen praktikablen Ausgangspunkt, wenn die technische Durchsetzung von Richtlinien noch nicht umgesetzt wurde.

Die meisten Architekturen kombinieren alle drei Ansätze: präventive Kontrollen zum Zeitpunkt der Ausführung, aufdeckende Kontrollen zur Erkennung von Abweichungen und Policy-as-Code für Bereiche, in denen eine lückenlose, auditierbare Nachvollziehbarkeit erforderlich ist.

Wie sich Compliance und Innovation in Einklang bringen lassen

Compliance-Anforderungen verlangsamen bestimmte Prozesse tatsächlich. Die korrekte Implementierung von Funktionen zur Auditierbarkeit benötigt Zeit. Prüf- und Freigabeprozesse für Richtlinien führen zu zusätzlichen Verzögerungen. Änderungen an der Infrastruktur erfordern weitere Genehmigungen. Bei bereits laufenden Systemen, in denen nachträglich Compliance-Prozesse eingeführt werden müssen, wird die Situation noch schwieriger. Das bedeutet, in zentrale Datenflüsse einzugreifen, Middleware hinzuzufügen, die ursprünglich nicht für diese Aufgabe entwickelt wurde, und darauf zu hoffen, dass die vorhandenen Logs ausreichen. In der Regel ist das nicht der Fall.

Um Compliance und Innovation bei der Automatisierung in Einklang zu bringen, geht es weniger darum, Kompromisse einzugehen, sondern vielmehr darum, Architekturentscheidungen in der richtigen Reihenfolge zu treffen. Ein produktiverer Ansatz besteht darin, die Governance-Ebene als eigenständiges Produkt mit eigenen Nutzern zu betrachten. Der Audit-Trail hat verschiedene Nutzer: Auditoren, Compliance-Beauftragte und Aufsichtsbehörden. Ihre Anforderungen lassen sich genauso berücksichtigen wie die Anforderungen anderer Nutzer. Auch die Richtlinienebene hat ihre eigenen Nutzer.

Teams, die diesen Ansatz verfolgen, berichten von einem langsameren Start, aber einer schnelleren und effizienteren Arbeitsweise im laufenden Betrieb. Die Investition in die Governance-Infrastruktur zahlt sich aus, sobald die nächste regulatorische Änderung ansteht. Anstatt mühsam rekonstruieren zu müssen, was das System vor sechs Monaten getan hat, genügt es, die entsprechende Richtlinie zu aktualisieren und einen Testlauf durchzuführen.

Governance-Modelle für die Automatisierung: Typische Fehlerquellen und ihre Ursachen

Automatisierte Systeme in regulierten Branchen scheitern häufig an wiederkehrenden Problemen. Vier davon treten besonders häufig auf.

Konfigurationsabweichungen (Configuration Drift)

In manchen Fällen erfüllte das System bei seiner Einführung alle Compliance-Anforderungen. Im Laufe der Zeit wurden jedoch Schwellenwerte ohne formelle Abstimmung angepasst. Änderungen an der Systemumgebung häuften sich. Wenn schließlich ein Audit ansteht, stimmt das tatsächliche Systemverhalten nicht mehr mit der Dokumentation überein.

Nicht nachvollziehbare Auslöserketten

Ein automatisierter Job wird über ein gemeinsam genutztes Servicekonto ausgeführt. Mehrere Workflows verwenden dasselbe Konto. Im Nachhinein lässt sich nicht mehr feststellen, welcher Workflow eine bestimmte Aktion ausgelöst hat.

Verzögerte Anpassung von Richtlinien (Policy Lag)

Wenn sich regulatorische Anforderungen ändern, muss der Anwendungscode aktualisiert werden. Dasselbe gilt für die Dokumentation. Kümmert sich das Entwicklungsteam nur um einen dieser Bereiche, beschreibt das System und seine Dokumentation letztlich unterschiedliche Sachverhalte.

Fehlende Datensnapshots

Dieses Problem kann auftreten, wenn ein Log zwar dokumentiert, dass eine Entscheidung getroffen wurde, aber nicht, auf welchen Daten sie beruhte. Haben sich die zugrunde liegenden Daten inzwischen geändert, lässt sich die Entscheidung nicht mehr rekonstruieren.

Die folgende Grafik fasst die oben beschriebenen Probleme kurz zusammen:

Praktische erste Schritte

In den vorherigen Abschnitten haben wir einige Architekturmuster vorgestellt, die bei der Automatisierung in regulierten Branchen eingesetzt werden können. Diese stellen keine vollständige Lösung dar, sondern eine Reihe von Entscheidungen, die zukünftige Handlungsmöglichkeiten offenhalten.

Für Teams, die mit dieser Arbeit beginnen, hat sich folgende Vorgehensweise bewährt:

Behalten Sie Folgendes im Blick: Ihr Hauptziel besteht darin, ein System zu entwickeln, dessen Funktionsweise vom ersten Tag an nachvollziehbar ist und das klare Möglichkeiten zur Weiterentwicklung bietet. Es geht nicht darum, eine vollständige Compliance-Architektur aufzubauen, bevor die erste Version bereitgestellt wird. Für Teams, die Forward Deployed Engineering (FDE) in regulierten Produktionssystemen einsetzen, liegt der Ausgangspunkt nicht bei der Auswahl der Tools, sondern bei der Festlegung klarer Grenzen für Auditierbarkeit und Governance. Teams, die Governance erst in einer zweiten Projektphase berücksichtigen, müssen später dafür bezahlen, meist zum ungünstigsten Zeitpunkt.

Die Anforderungen in regulierten Branchen werden nicht einfacher. Der Umfang regulatorischer Anforderungen nimmt tendenziell zu, statt abzunehmen. Ein System, bei dessen Entwicklung die Auditierbarkeit von Anfang an als zentrale Anforderung berücksichtigt wurde, kann mit dieser Entwicklung anders umgehen als ein System, in dem Compliance-Funktionen nachträglich ergänzt wurden. Der Unterschied zeigt sich nicht im normalen Betrieb, sondern in entscheidenden Situationen: bei einem Audit, einem Sicherheitsvorfall oder einer regulatorischen Änderung, die an einem Freitagnachmittag in Kraft tritt. Entwickeln Sie Ihre Systeme so, dass sie auch auf solche Situationen vorbereitet sind.