Agent für kontinuierliche Compliance und Kontrollüberwachung

Compliance wird oft noch einmal im Jahr nachgewiesen: Screenshots, Tabellen und stichprobenartig gezogene Tickets werden in der Hektik vor der Prüfung zusammengetragen. Ein Agent für kontinuierliche Kontrollüberwachung (Continuous Controls Monitoring, CCM) befragt stattdessen laufend die führenden Systeme, testet jede Kontrolle, legt Nachweise mit Zeitstempel ab und eröffnet Maßnahmenaufgaben, sobald etwas abweicht. LLM-Agenten ergänzen, was Regelwerke bisher schlecht konnten: Richtlinien und Tickets lesen, einen Nachweis mehreren Regelwerken zuordnen und die Nachverfolgung entwerfen. Risikoakzeptanz und Freigabe bleiben bei den Menschen.

Problem & Nutzen

• Heute: Kontrollverantwortliche sammeln Nachweise manuell für ISO/IEC 27001, SOC 2, NIS2, DORA, SOX/ICFR oder interne Kontrollsysteme. Tests erfolgen stichprobenartig, die Nachweise sind am Prüfungstag veraltet, und eine Kontrolle wird für jedes Regelwerk gesondert dokumentiert.
• KI-Nutzen: (1) die gesamte Grundgesamtheit statt einer Stichprobe testen, (2) Nachweise aktuell und mit Zeitstempel halten, (3) eine Kontrolle mehreren Anforderungen zuordnen, (4) Fehler einordnen und Verantwortliche nachfassen, (5) regulatorische Änderungen gegen die Kontrollbibliothek zusammenfassen.
• Regulatorischer Sog in der EU: NIS2 verlangt Risikomanagementmaßnahmen und Meldung von Sicherheitsvorfällen für wesentliche und wichtige Einrichtungen [2]; DORA verlangt IKT-Risikomanagement, Meldung von Vorfällen und die Aufsicht über Dritte für Finanzunternehmen und gilt seit dem 17. Januar 2025 [1]. Beide belohnen Nachweise, die kontinuierlich und reproduzierbar statt jährlich sind.
• Belege für den Nutzen: Anbieter behaupten große Aufwandssenkungen bei der Prüfungsvorbereitung, doch es gibt keine unabhängigen Vergleichswerte; messen Sie Ihre eigene Ausgangslage (Stunden für die Nachweissammlung pro Prüfzyklus), bevor Sie einer Zahl trauen.

Varianten

• SaaS-/Sicherheits-Compliance (SOC 2, ISO 27001): Prüfungen von Cloud, Identitäten, Endgeräten und Code-Repositories.
• Finanzdienstleistungen (DORA, BaFin/EBA-Auslagerung, MaRisk): Register der IKT-Drittanbieter, Fristen für die Meldung von Vorfällen, Nachweise zu Resilienztests.
• Betreiber kritischer Einrichtungen (NIS2): Lieferketten- und Sicherheitsmaßnahmen, Berichte an die Geschäftsleitung.
• Finanzen / ICFR im SOX-Stil: Zugriffskonflikte (Funktionstrennung), Buchungs- und Freigabekontrollen im ERP; Verbindung zu AGENT-006.
• Interne Revision & öffentlicher Sektor: laufende Prüfung von Verfahren und Regeleinhaltung.
• Compliance von KI-Systemen: Protokoll- und Dokumentationsnachweise für die eigenen KI-Systeme des Unternehmens (AGENT-025).

So funktioniert es

1. control library (OSCAL / GRC tool) + policies & regulations (RAG index)
2. scheduler / event triggers (config change, new user, new vendor)
3. evidence connectors (read-only APIs: cloud, IdP, MDM, ERP, ticketing, Git)
4. deterministic test (query/rule)
5. result + raw evidence snapshot (hash, timestamp)
6. LLM step: interpret unstructured evidence (tickets, policies, pull requests), map to requirements
7. exception triage (severity, owner, due date, similar past findings)
8. human review: control owner / compliance officer confirms, accepts risk or remediates
9. ticket + reminder + dashboard + audit export

• Zuerst deterministisch: Wo eine Kontrolle per Abfrage getestet werden kann (MFA erzwungen, Datenträger verschlüsselt, Anzahl der Administratoren, Alter von Patches), nutzen Sie Code, nicht ein LLM. Das LLM interpretiert Text und entwirft, es entscheidet bei wichtigen Kontrollen nicht allein über bestanden/nicht bestanden.
• Agentenwerkzeuge: schreibgeschützte API-Werkzeuge über MCP oder Function Calling; Schreibzugriff nur zum Anlegen von Tickets und Kommentaren. Zugangsdaten sind eng gefasst, kurzlebig und protokolliert.
• Mensch-in-der-Schleife (Human-in-the-Loop): Die Compliance-Beauftragten geben neue Testlogik, Risikoakzeptanzen und alles frei, was Prüfern oder Aufsichtsbehörden gezeigt wird; Prüfer kontrollieren die Ergebnisse des Agenten stichprobenartig.

Datenaufbereitung

Die Daten stammen aus vielen Systemen: Cloud-Konten, Identitätsanbieter, MDM, Ticketsystem, HR, ERP und CI/CD (über schreibgeschützte APIs), dazu der Kontrollkatalog (oft eine Excel-Tabelle oder ein GRC-Werkzeug), Richtlinien im DMS oder auf Dateiablagen und frühere Prüfberichte als PDF. Typische Lücken: kein einheitlicher Kontrollkatalog, Kontrollen ohne benannte Verantwortliche, einander widersprechende Richtlinien, Nachweise als Screenshots in E-Mails oder auf privaten Laufwerken und zu weit gefasste Dienstkonten. Aus Systemen gesammelte Nachweise enthalten außerdem personenbezogene Daten (Benutzerlisten, Zugriffsprotokolle).

Schritte der Aufbereitung: (1) einen einheitlichen Kontrollkatalog mit ID, Verantwortlichem, Häufigkeit und Nachweisart aufbauen (PREP-019); (2) Systeme und verfügbare APIs inventarisieren (PREP-005, PREP-001); (3) Datenverantwortliche benennen (PREP-004); (4) schreibgeschützte Dienstkonten mit minimalen Rechten anlegen; (5) Richtlinien in durchsuchbaren Text umwandeln (PREP-013); (6) pseudonymisieren, wo vollständige Identitäten nicht gebraucht werden (PREP-022). Werkzeuge: Tabelle oder OSCAL für den Katalog, Konnektoren der gewählten Plattform. Grober Aufwandsanteil: 30-40 Prozent, vor allem Katalog und Zugriffseinrichtung.

Umsetzungswege

Welcher Weg für wen

• KMU: A. Compliance-Automatisierungsplattformen mit fertigen Kontrollbibliotheken für ISO 27001/SOC 2/NIS2 und Konnektoren sind ausgereift, und der Ablauf ist Standard.
• Großunternehmen: B. Eigene Kontrollkataloge, SOX/ICFR-Anforderungen und die Integration in hauseigene GRC-, ERP- und Identitätssysteme sprechen für einen Aufbau auf Cloud-KI-Diensten.
• Entwickler: B. Schreibgeschützte APIs plus eine LLM-Schnittstelle ermöglichen es, Kontrolltests schnell zu bauen; Selbstbetrieb lohnt sich selten.
• Öffentlicher Sektor: C. Prüfnachweise, Benutzer- und HR-Daten sowie Vergaberegeln sprechen für einen selbst betriebenen Stack auf souveräner Infrastruktur.

Weg A — Kaufen (Standardsoftware) (für die meisten KMU empfohlen)

• Automatisierung von Sicherheitsstandards: Vanta, Drata, Sprinto, Secureframe, Scrut — Integrationen für Cloud, Identitätsanbieter und HR, mit KI-Agenten für Fragebögen und die Prüfung von Nachweisen. Anbieter nennen Hunderte automatisierter Tests; prüfen Sie das unabhängig [4][5].
• Enterprise-GRC / CCM: Archer, OneTrust, ServiceNow IRM, SAP GRC, Diligent, MetricStream, SureCloud; Optionen aus Europa sind u. a. Secfix, DataGuard (DE) und Proliance (DE) — Funktionsumfang und Hosting prüfen.
• Finanzkontrollen: SAP GRC / Process Control, BlackLine, Workiva, Fastpath (Zugriffsanalysen).
• A wählen, wenn: die Regelwerke Standard sind, der Stack gängige SaaS-/Cloud-Software ist und ein Prüfer das Nachweisformat des Werkzeugs bereits akzeptiert. EU-Datenresidenz und AVV prüfen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Modelle: ein Reasoning-LLM (Claude, GPT, Gemini, Mistral — EU-Region oder EU-Anbieter, wo erforderlich) für Zuordnung, Interpretation und Entwurf; ein kleines Modell zur Klassifikation von Tickets/Nachweisen.
• Orchestrierung: ein Agenten-Framework oder n8n/Power Automate (AGENT-002); Werkzeuge über MCP-Server für AWS, Azure, Google Cloud, Entra ID/Okta, GitHub und Ticketsysteme.
• Native Cloud-Posture-Quellen: AWS Config und Security Hub, Azure Policy und Defender for Cloud, Google Security Command Center liefern die rohen Kontrollsignale.
• Ablage: Kontrollbibliothek als OSCAL-JSON/YAML [3], Nachweise in einmal beschreibbarem Objektspeicher mit Hashwerten, Vektorindex für Richtlinien und Regulierungstexte.
• B wählen, wenn: Sie eigene Kontrollen (z. B. interne Prozesskontrollen) oder eine Zuordnung über mehrere Regelwerke benötigen, die Standardwerkzeuge nicht abdecken.

Weg C — Selbst betreiben (Open Source)

• Kontrollwerkzeuge: NIST-OSCAL-Werkzeuge und quelloffenes Policy-as-Code (Open Policy Agent, Cloud Custodian, Steampipe mit Compliance-Modulen, Prowler, Wazuh) sowie quelloffene NIS2-/ISMS-Werkzeuge.
• Modelle: Open-Weight-Reasoning-/Instruktionsmodelle (z. B. Qwen3, Llama, Mistral-Familien, gpt-oss), betrieben mit vLLM oder Ollama; Embeddings und Reranker für den Richtlinienindex.
• Hardware: HW3 für ein Modell mit 30–120 Mrd. Parametern und guter Zuordnungsqualität; HW2 funktioniert, wenn das LLM nur entwirft und die Tests deterministisch sind.
• Betriebsaufwand: hoch — Konnektoren, Umgang mit Geheimnissen und Aufbewahrung der Nachweise liegen bei Ihnen.

Weg D — Eigenes Training

Selten nötig. Einen kleinen Klassifikator für die Zuordnung von Nachweisen zu Kontrollen oder für die Ticket- Einordnung nur feintunen, wenn Sie über Tausende gelabelte frühere Feststellungen verfügen. Anomaliemodelle für Zugriffs- oder Buchungsdaten können Mehrwert bringen, gehören aber zu den ANOM-/PRED-Anwendungsfällen.

Stand der Technik (2026)

• Agentisches CCM ist der Trend bei den Anbietern: Agenten befragen Systeme, führen Kontrolltests aus, prüfen Nachweise und entwerfen Feststellungen; Praxisleitfäden sagen, dass sie sich für Nachweissammlung, laufende Überwachung, Fragebögen, Verfolgung regulatorischer Änderungen und Verfolgung von Bestätigungen eignen, nicht aber für regulatorische Auslegung, Risikoakzeptanz oder die abschließende Freigabe [6].
• Maschinenlesbare Kontrollen: NIST OSCAL wird zum Austauschformat für Kontrollkataloge, Prüfpläne und Ergebnisse; die Forschung erweitert es auf Nachweise im KI-Lebenszyklus [3][7].
• Konnektoren im MCP-Stil vereinheitlichen den schreibgeschützten Systemzugriff für Agenten; das Sicherheitsrisiko der Konnektoren selbst (Prompt Injection über Ticket-Text, überprivilegierte Tokens) ist das zentrale Entwurfsthema.
• Grenzen und Fehlerbilder: LLMs bewerten schwache Nachweise möglicherweise als ausreichend; ein Nachweis der Ausgestaltung ist kein Nachweis der Wirksamkeit im Betrieb; Agenten sehen nur angebundene Systeme, sodass Lücken im Geltungsbereich unsichtbar bleiben; Prüfer akzeptieren KI-erzeugte Schlussfolgerungen möglicherweise nicht ohne eigene Nachprüfung; Anbieterangaben zur Zahl „automatisierter Tests" sagen nichts über die Testqualität.

Gemeinsame Bausteine & Kombinationen

• Gemeinsame Fähigkeiten (agent-framework, workflow-automation, vector-db, guardrails): AGENT-002 Workflow-Automatisierung, AGENT-016 IT-Service-Management, AGENT-025 Agenten-Governance und Observability.
• Naheliegende Kombinationen: KNOW-009 (Fragen und Antworten zu Regulierung/Normen als RAG-Schicht für Richtlinien), DOC-016 (automatisierte Prüfung von Dokument gegen Regel), AGENT-006 (Kontrollen im Finanzabschluss), PRED-028 (risikobasierte Auswahl von Prüffeldern), ANOM-006 (auffällige Transaktionen als Kontrollsignal).
• Ein selbst betriebener LLM-Server (HW3) kann diesen und die übrigen Compliance-/Wissens-Anwendungsfälle bedienen.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bis zu den ersten überwachten Kontrollen; Abonnement, üblicherweise nach Regelwerk und Unternehmensgröße bepreist; die Prüferhonorare bleiben unverändert.
• Weg B: 3–6 Monate für ein erstes Regelwerk mit ca. 10 Konnektoren; Kosten entstehen durch Konnektoren, Entwicklung, Tokens (gering, wenn Tests deterministisch sind) und Nachweisspeicher.
• Weg C: 6+ Monate und ein Plattformteam.
• Kennzahlen: Anteil automatisch getesteter Kontrollen, Aktualität der Nachweise (Median des Alters), mittlere Zeit bis zur Erkennung und Behebung eines Kontrollversagens, eingesparte Stunden bei der Prüfungsvorbereitung, Prüfungsfeststellungen pro Zyklus, Rate falsch positiver Meldungen, Anteil der Schlussfolgerungen des Agenten, die Menschen revidieren.

Menschen & Veränderung

Beginnen Sie mit der Geschäftsleitung (Mandat, Umfang, welche Regelwerke) und der Compliance- oder Revisionsleitung als Prozessverantwortlicher. IT und IT-Sicherheit müssen schreibgeschützten Zugriff gewähren und den Agenten selbst prüfen, da er weitreichende Zugangsdaten hält (GUIDE-013). Kontrollverantwortliche in Finanzen, HR und Betrieb müssen verstehen, dass ihre Systeme laufend getestet werden und Feststellungen als Tickets bei ihnen landen. Binden Sie die(den) Datenschutzbeauftragte(n) früh ein: Die Nachweise enthalten Benutzer-, Zugriffs- und HR-Daten, daher kann eine DSFA nötig sein, und ein AVV mit dem Plattformanbieter ist erforderlich (GUIDE-005).

Betriebsrat: in der Praxis ja. Die kontinuierliche Prüfung von Zugriffs- und Aktivitätsprotokollen ist eine technische Einrichtung, die zur Verhaltensüberwachung geeignet ist, daher greift § 87 Abs. 1 Nr. 6 BetrVG (nach dem BAG genügt die objektive Eignung); ebenso gelten § 90 Abs. 1 Nr. 3 und, falls nötig, ein Sachverständiger nach § 80 Abs. 3 (GUIDE-004). Eine Betriebsvereinbarung sollte die individuelle Leistungsbewertung ausschließen. Öffentliche Stellen beteiligen den Personalrat.

Starten Sie mit einem Regelwerk oder zehn Kontrollen. Typische Sorgen: „Wir werden überwacht" und „Der Agent entscheidet über Feststellungen." Begegnen Sie ihnen mit transparentem Umfang, menschlicher Prüfung jeder fehlgeschlagenen Kontrolle vor der Eskalation und Maßnahmen zur KI-Kompetenz für Kontrollverantwortliche (GUIDE-006).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko — ein Überwachungswerkzeug für Systeme und Prozesse, nicht Anhang III. Sensibel wird es, wenn es Beschäftigte überwacht (z. B. Bewertung einzelnen Verhaltens, Beurteilung der Arbeitsleistung): dann können die Hochrisiko-Regeln für Beschäftigung nach Anhang III gelten, und Emotionserkennung am Arbeitsplatz ist verboten (Art. 5) [8]. Die KI-Kompetenz (Art. 4) gilt für die Betreiber.
• DSGVO: Nachweise umfassen Benutzerkonten, Zugriffsprotokolle, HR- und E-Mail-Metadaten; Zweckbindung und Datenminimierung beachten, Hashwerte oder geschwärzte Schnappschüsse speichern, die Mitbestimmung des Betriebsrats (BetrVG § 87) und die Notwendigkeit einer DSFA prüfen, wenn Mitarbeiteraktivitäten analysiert werden.
• Branchenregeln: DORA und NIS2 verpflichten die Einrichtungen, auch bei Dienstleistern für das IKT-Risikomanagement verantwortlich zu bleiben [1][2]; Prüfer (ISAE 3000/3402, SOX) beurteilen, inwieweit man sich auf automatisierte Nachweise stützen kann.
• Sicherheit: der Agent hat weitreichenden Lesezugriff; Prinzip der minimalen Rechte, kein Schreibzugriff auf Produktivsysteme, Schutz vor Prompt Injection über Ticket- oder Dokumenttext und unveränderliche Protokolle jeder Agentenaktion.
• Gegenmaßnahmen: deterministische Tests für wichtige Kontrollen, menschliche Freigabe, regelmäßige Nachprüfung durch die interne Revision, versionierte Testlogik, Tests bei Modellwechsel.

Erste Schritte

1. Ein Regelwerk und 15–25 besonders wertvolle Kontrollen wählen (Zugriff, MFA, Backups, Patching, Lieferantenregister).
2. Prüfen, welche per API testbar sind; schreibgeschützte Konnektoren und Dienstkonten inventarisieren.
3. 2–3 Werkzeuge nach Weg A auf Ihrem echten Stack erproben oder drei deterministische Tests plus eine LLM-Zusammenfassung der Nachweise als Prototyp bauen.
4. Mit Ihrem Prüfer vereinbaren, welche automatisierten Nachweise er in welchem Format akzeptiert.
5. Ein Quartal im Schattenbetrieb laufen lassen; die Ergebnisse des Agenten mit manuellen Tests vergleichen, bevor Sie umstellen.

Quellen

1. Regulation (EU) 2022/2554 (DORA) — https://eur-lex.europa.eu/eli/reg/2022/2554/oj
2. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
3. NIST OSCAL — https://pages.nist.gov/OSCAL/
4. Vanta — compliance software for enterprise — https://www.vanta.com/resources/best-compliance-software-for-enterprise
5. Archer — future of continuous controls monitoring 2026 — https://www.archerirm.com/post/the-future-of-continuous-controls-monitoring-trends-and-insights-for-2026
6. SureCloud — agentic AI compliance tasks that work in 2026 — https://www.surecloud.com/blog-hub/agentic-ai-compliance-tasks
7. arXiv — Making AI Compliance Evidence Machine-Readable — https://arxiv.org/html/2604.13767v1
8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj